4B 모델을 훈련하여 PostgreSQL 쿼리 계획을 81% 더 빠르게 생성하기

TL;DR

GPT-6 Astra에서 비정책적 분산 학습을 거친 40억 파라미터 오픈웨이트 모델과 몇 에포크의 강화 학습 후, PostgreSQL이 조인 순서 벤치마크를 평균적으로 81% 더 빠르게 실행하도록 하는 pg_hint_plan 힌트를 생성할 수 있으며, 전체 작업 부하 지연 시간을 44.7% 줄일 수 있다.

왜 쿼리 최적화기들은 여전히 뒤처지는가

  • Leis 등 (2015, 2025)은 PostgreSQL 최적화기가 조인 순서와 같은 NP-완전 문제에서 상당한 성능을 놓치고 있음을 보여주었다.
  • 최적화기는 대략적인 통계와 균일 분포 가정에 의존하며, 하나의 잘못된 카디널리티 추정이 크게 비효율적인 계획으로 이어질 수 있다.
  • 계획 품질을 검증하는 것은 간단하다 – 실행 시간은 단일 관측 가능한 지표이므로, 이 문제는 강화 학습에 매우 적합하다.

문제 정의

목표: 작은 모델을 훈련시켜 PostgreSQL의 기본 비용 기반 최적화기보다 더 빠른 계획을 유도하는 pg_hint_plan 주석을 생성하게 하기.

핵심 통찰: 반복적으로 실행되는 분석 작업 부하에서는 더 나은 계획의 누적 이점이 힌트 생성의 일회성 비용을 초과한다.

실험 플랫폼

구성 요소 세부 사항
데이터베이스 IMDb 데이터셋의 일부를 사용한 PostgreSQL 15 (디스크에 8.5GB).
하드웨어 개발용 머신 "FLOPper" – 2× RTX 3090, 16개 CPU 코어, 64GB RAM.
훈련 GPU Lambda에서 렌탈한 2× H100 SXM (각각 80GB VRAM), 약 95시간.
벤치마크 조인 순서 벤치마크 (JOB – 113개 쿼리, 33개 조인 그래프 구조).
보조 벤치마크 카디널리티 추정 벤치마크 (CEB – 약 13.6k개 쿼리)는 훈련 데이터로 사용.

측정 노이즈 감소

  • 캘리브레이션 장치: 4개의 도커화된 PostgreSQL 컨테이너, 각각 4개의 CPU 코어와 8GB RAM에 고정되어 공유 큐에서 쿼리를 가져옴.
  • 워밍업 정책: shared_buffers 히트 및 읽기 블록 카운터가 두 번의 연속 실행에서 2% 이내로 안정화될 때까지 쿼리를 실행.
  • 노이즈 지표: 시뮬레이션된 "노옵" 보상(후보 = 기본값)은 shared_buffers = 128MB일 때 평균 오차율 5%와 최악의 경우(p90) 13%~20%를 보였다.
  • 튜닝: shared_buffers를 2GB로 상향 조정하여 대부분의 노이즈를 제거(평균 오차 ≈ 1.5%, p90 ≈ 0%)했으며, JOB 전체 실행 시간을 95초에서 60초로 단축했다.

모델과 하이브리드

  • 기본 모델: empero-ai/Qwen3.8-4B-Distill (2.4T의 교사 모델에서 훈련된 Qwen 3.8 4B).
  • 에이전트 하이브리드 (qo-agent): 여섯 가지 도구(inspect_relation, get_column_stats, get_plan, evaluate_candidate, keep_default, finish) 제공.
  • 상호작용 형식: 모델은 PlanAction JSON을 출력하며, 하이브리드는 이를 pg_hint_plan 주석으로 변환하고 실행 시간을 측정.

비정책적 분산 학습 (지도 미세조정)

  1. 교사 트래잭션: 무작위 CEB 쿼리에서 120개의 GPT-6 Astra 롤아웃(각각 5개 후보), 추론 요약 포함.
  2. 렌더링 및 손실 마스킹: OpenAI 응답 JSON을 Qwen 토큰 스트림으로 변환; 시스템/사용자 프롬프트 및 도구 출력 토큰 마스킹.
  3. LoRA 어댑터: 42.5MB(21.2M 학습 가능한 파라미터), 4B 기반 모델 가중치를 동결하여 단일 RTX 3090에서 훈련 가능하게 함.
  4. 훈련 스케줄: 100개의 Astra 트래잭션에서 1에포크 → 소폭 향상(기하평균 0.72×). 2에포크 → 1.08× 기하평균 속도 향상; 3에포크 → 과적합 및 성능 저하.
  5. 데이터 확장: 300개의 Astra 트래잭션 추가(단순한 "기본 유지" 실행 제외). 2개의 추가 에포크로 기하평균을 1.10×로 끌어올리고 전체 작업 부하 속도 향상을 1.05×로 끌어올림.

에이전트 기반 강화 학습

  • 보상 설계:
    • 속도 향상 = 중앙값(기본) / 중앙값(후보).
    • [0.1, 10] 범위로 비율 클리핑하고, 노이즈를 무시하기 위해 0.05 소프트 임계값 적용.
    • 유효하지 않은 계획에 대해 벌점(-0.1), 중복 기본 계획에 대해(-0.02), 유효한 후보가 없는 트래잭션에 대해(-0.1) 벌점 부과.
  • 우수성 추정기: 그룹 평균을 빼고 각 롤아웃의 부호를 적용하는 맞춤형 "앵커링" GRPO로, 진정으로 더 빠른 계획만 양의 우수성을 받도록 보장.
  • 훈련 하이퍼파라미터: LR = 1e-5, 배치 = 16, 쿼리당 8개 롤아웃, 단계당 600번 최적화 업데이트.
  • 병렬화 기술: PostgreSQL 컨테이너를 측정 단계에서만 임대하여 20개의 동시 롤아웃을 가능하게 하며, vLLM 추론을 완전히 포화 상태로 유지.

결과

단계 유효한 후보 쿼리 수 점수된 작업 수 기하평균 속도 향상 전체 작업 부하 속도 향상 승리(≥5% 빠름) 회귀(≥5% 느림)
미훈련 4B 14/113 15/113 0.85× 0.85× 3 1
SFT 후 (1에포크) 48/113 44/113 0.72× 0.76× 5 16
SFT 후 (2에포크, 300개 추가 트래잭션) 77/113 101/113 1.10× 1.05× 29 13
RL 600 업데이트 99/113 113/113 1.35× 1.16× 34 0
RL 1,200 업데이트 101/113 112/113 1.41× 1.29× 38 2
RL 1,200 + 쿼리당 3개 롤아웃 (최고의 15개 중 선택) 113/113 339/339 1.81× 1.81× 68 0
  • 최종 체크포인트는 쿼리당 최대 15개의 샘플된 계획 중에서 가장 좋은 후보를 선택할 때 기하평균 1.81×의 속도 향상(전체 지연 시간 44.7% 감소)을 달성했다.

모델이 실제로 학습한 내용

  • 빈번한 동작: Leading 트리 힌트(917회 사용), 스캔 힌트(1,141회), Parallel 힌트(572회).
  • 조인 방법 선호: 해시 조인보다는 네스티드 루프 조인을 강제하는 경우가 많았음.
  • 스캔 선호: 비트맵 또는 순차 스캔보다 인덱스 스캔을 선호.
  • 구성 변경: 자주 enable_sort=off와 random_page_cost=1.1을 설정하여, 모델이 비용 모델의 민감성을 활용하고 있음을 시사.
  • 성공적인 패턴: Leading을 통해 조인 순서 재정렬, 단일로 더 선택적인 스캔 추가, 병렬화 활성화를 함께 적용하는 것이 대부분의 속도 향상의 원인.

비용 분석

항목 비용
Lambda 2× H100 렌탈(약 95시간) ~$800
OpenAI API를 통한 Astra 트래잭션(약 40만 토큰) ~$400
FLOPper 전력 비용(지속적인 GPU 사용) ~$9/일 (무시 가능)
합계 ~$1,200

커뮤니티 반응 (선택된 HN 댓글)

"8GB 데이터셋에 대해 메모리에 완전히 들어가는 환경에서 쿼리 계획이 81% 더 빠르다…" – refibrillator (과적합과 확장성에 대한 우려). "선도적 지능은 매우 강력하다; Astra 트래잭션에서 수행한 분산 학습은 대규모 모델이 사라지지 않을 것임을 입증한다" – devsda (오픈웨이트 분산 학습의 광범위한 의미를 지적). "PostgreSQL보다 3배 이상 더 나은 성능을 내는 것은 어렵지 않다; 모델이 필요하지 않다" – huahaiy (수동으로 튜닝한 힌트도 큰 성능 향상을 낼 수 있음을 지적). "모델은 자주 enable_sort=off와 random_page_cost=1.1을 사용했다 – 이는 성능 향상의 원인일 수 있다" – zacmps (가능한 혼동 요인인 구성 변경을 강조). "반복적인 분석 쿼리에 대해 자동으로 힌트를 생성해주는 제품을 원한다" – ashley95 (실용적인 SaaS 방향 제안).

학습점

  1. LLM은 효과적인 최적화 힌트를 생성할 수 있다. 단순히 큰 교사 모델에서 분산된 4B 모델이라도, 실제 실행 피드백을 통한 강화 학습을 거치면 현실적인 분석 벤치마크에서 PostgreSQL의 내장 최적화기보다 뛰어난 성능을 보인다.
  2. 노이즈 인식 측정이 필수적이다. 적절한 캐시 크기(shared_buffers = 2GB)와 세 쌍의 중앙값 중앙값 평가로, 부정확한 보상 신호를 5% 미만에서 거의 0에 가깝게 줄였다.
  3. 비정책적 분산 학습은 SFT를 가속화한다. 수백 개의 교사 트래잭션은 모델이 하이브리드 언어와 기본 힌트 구문을 학습하는 데 충분한 토큰 수준의 지도를 제공했다.
  4. 보상 설계는 알고리즘의 혁신보다 중요하다. 초기 GRPO 변형은 중복 기본 계획을 강화했으며, 맞춤형 앵커링 GRPO와 클리핑된 속도 향상 보상이 안정적인 RL 진행에 필수적이었다.
  5. 작은 모델은 도메인 특화 작업에 비용 효율적이다. 훈련 비용 ≈ $1.2k, 단일 RTX 3090에서 추론 비용은 무시 가능하지만, 반복 가능한 작업 부하에서는 80% 이상의 속도 향상을 제공한다.

미래 작업

  • 구조화된 힌트 스위핑 (예: Bao) vs. LLM 생성 힌트.
  • 정책적 분산 학습을 통해 샘플 효율성 비교.
  • 트레이스 역전을 통한 풍부한 추론 토큰 지도.
  • 더 큰 데이터셋(TB 규모)과 혼합 OLTP/OLAP 작업 부하로 확장.
  • 자동 힌트 캐싱 서비스 – 생산 쿼리 로그를 지속적으로 재훈련.

코드 및 인용

@article{bansal2026qorl,
  title = {Training a 4B model to produce 81% faster query plans than Postgres},
  author = {Bansal, Rohan},
  journal = {rohanbansal.com},
  year = {2026},
  month = {September},
  url = {https://rohanbansal.com/qorl}
}

Sources

관련