81%는 모델 단독 성능이 아니다 — 4B로 Postgres 플랜 고르기

개인이 1,200달러로 4B 모델을 훈련해 Postgres 쿼리 플랜을 고르게 했고, JOB 벤치마크 113개에서 기하평균 1.81배를 냈다. 제목에 붙은 81%가 이 숫자다.

그런데 이건 모델이 혼자 낸 성적이 아니다. 모델이 직접 고른 계획의 기하평균은 1.40배고, 1.81배는 롤아웃 3개를 뽑아 그중 가장 빠른 것을 고른 값이다. 후보를 실제로 실행해봐야 나오는 숫자다.

확인된 것

Rohan Bansal의 qorl 실험 기준이다.

• JOB 벤치마크 113개 쿼리 / 33개 템플릿(IMDb 기반). 최종 평가는 쿼리당 롤아웃 3개.
• 모델 단독 1.40배 / 3롤아웃 중 최선 1.81배. 113개 전체 지연 시간은 44.7% 감소.
• 방식: Postgres를 대체하는 게 아니라 pg_hint_plan 힌트로 조인 순서와 스캔 방식을 바꾸고 실제 실행 시간을 비교한다.
• 기반 모델은 empero-ai/Qwen3.8-4B-Distill, LoRA 어댑터(학습 파라미터 2,120만). SFT는 Astra 궤적 120개로 2 에포크, 이어서 anchored GRPO 변형으로 RL 1,200 업데이트.
• 비용 총 $1,200 — Lambda 2×H100 95시간 약 $800, 궤적 생성용 OpenAI API 약 $400.
• 코드 전체 공개(github.com/polyphilz/qorl).

측정 잡음을 다룬 부분이 따로 있다.

• shared_buffers를 128MB → 2GB로 올리자 no-op 오차율이 5.0%/5.4% → 1.7%/1.3%, p90 쿼리 기준으로는 13%/20% → 0%/0% 로 떨어졌다. job-13b 쿼리의 변동계수는 10.3% → 0.9%.
• 학습량과 회귀: SFT 1 에포크에서 회귀 16개, 2 에포크 8개, 3 에포크 15개(과적합). RL 최종 체크포인트는 38승 2회귀.

일반화에 대해서는 저자가 전제를 밝혀뒀다.

"Given our problem formulation, if this agent is continually getting used for a company's analytic workloads across its specific databases, we need not generalize to all databases."

내 판단

1. 1.40과 1.81을 같은 숫자로 쓰면 안 된다.

1.81배를 얻으려면 후보를 여러 개 만들어 실제로 실행해보고 고르는 단계가 필요하다. 그 탐색 비용은 공짜가 아니다. 저자가 전제를 정직하게 적어놨듯 이 설정은 같은 형태의 분석 쿼리가 반복해서 도는 환경을 가정한다. 한 번 최적화해두면 이후 실행에서 계속 회수되니까.

일회성 쿼리나 형태가 매번 달라지는 워크로드에는 이 계산이 성립하지 않는다. 그런 환경에서 기대할 수 있는 건 1.40배 쪽이고, 그마저도 모델 추론 시간을 빼야 한다.

2. 진짜 소식은 배수가 아니라 $1,200이다.

좁은 작업 하나에 대해 개인이 4B 모델을 맞추는 일이 주말 프로젝트 예산 안으로 들어왔다. 코드도 공개돼 있다.

다만 숫자를 정확히 옮겨야 한다. 훈련은 2×H100에서 95시간 돌았다. 저자의 로컬 장비(2×RTX 3090)는 측정용이지 훈련용이 아니다. 이걸 뭉뚱그리면 "3090 두 장이면 된다"는 잘못된 예산 추정이 나온다.

어제 쓴 Jev 글과 같은 방향의 다른 선택지다. 거기서는 좁은 작업용 모델을 사서 쓰는 이야기였고, 여기서는 직접 만드는 쪽이다. 내 작업이 충분히 좁고 반복적이라면 후자의 진입 비용이 생각보다 낮다.

3. 결과보다 측정 방법 쪽이 가져갈 게 많다.

shared_buffers 조정 전에는 p90 쿼리에서 같은 계획을 다시 재도 13~20% 차이가 났다. 그 상태로 "1.4배 빨라졌다"를 측정했으면 절반은 노이즈였을 수 있다.

여기서 나오는 규칙 하나. 가속을 주장하기 전에 아무것도 바꾸지 않은 상태로 두 번 재서 편차부터 확인한다. 그 편차보다 작은 개선은 개선이 아니라 측정 오차다. 성능 작업에서 흔히 건너뛰는 단계이고, 이 실험이 잘한 부분이다.

4. 과적합 구간이 좁다는 것도 정보다.

SFT 에포크를 1 → 2 → 3으로 올렸을 때 회귀 쿼리 수가 16 → 8 → 15로 움직였다. 더 학습하면 나아지는 구간이 2 에포크에서 끝났다는 뜻이다. 좁은 작업에 소형 모델을 맞출 때 "일단 오래 돌리자"가 통하지 않는다는 구체적 사례다.

모르는 것

• LoRA 어댑터나 모델 가중치의 공개 여부는 원문에서 확인하지 못했다. 공개된 것으로 확인한 건 코드다.
• IMDb 데이터셋에 특화해 훈련했고 저자도 다른 DB로의 일반화는 목표가 아니라고 명시했다. 내 스키마에서 재현될지는 별개 문제다.
• 읽기 전용 분석 쿼리 환경이다. 쓰기가 섞이거나 캐시에 안 들어가는 크기의 데이터에서 어떻게 되는지는 이 실험 범위 밖이다.
• 한국어로 도는 요약 중에 "RTX 3090 2장으로 재현 가능"으로 읽히는 서술이 있는데, 원문 기준으로 3090은 측정 장비다. 위 내용은 원문 기준으로 썼다.