OOM 없이 vLLM 확장하기

Jamba 계열 모델의 GRPO 온라인 RL에서 여러 training job이 LLM-as-a-Judge(JLM) 배포를 공유하면 GPU 유휴 시간을 줄일 수 있지만, 동시에 예측 불가능한 버스트 트래픽에 노출된다. 이를 해결하기 위해 단일 노드 성능 최적화와 멀티 노드 스케일링을 함께 적용했다.

단일 노드에서는 Auto-Tune vLLM을 사용해 설정을 튜닝했다. GuideLLM으로 벤치마크하고 Optuna의 NSGA-II로 파라미터 공간을 탐색했으며, 워크로드 분석, 최적화 파라미터 설정, 300회 trial 실행, Pareto-optimal 구성 선택의 순서로 진행했다.

벤치마크는 2K input tokens(최대 8K), 100~1K output tokens, 2k concurrent requests, 5-minute timeout 조건으로 돌렸고, 목표는 다음 5가지였다.

• Output tokens/second 최대화
• Requests/second 최대화
• Request latency 최소화
• Time-to-first-token 최소화
• TPOT(inter-token latency) 최소화

300회 trial 중 125개가 성공했고, 나머지는 OOM 또는 timeout으로 종료됐지만 프레임워크가 이를 정상적으로 처리했다. 그 결과 24개 Pareto-optimal configuration이 남았고, 총 처리량을 가장 중시해 최고 token throughput 구성을 선택했다. 대상 모델은 32B dense attention model, 하드웨어는 H100 SXM 80GB였다.

비교 결과는 단순한 버전 업그레이드 효과와 설정 튜닝 효과를 분리해서 봐야 했다. vLLM v0.8.5 → v0.11.0으로 올리기만 해도 같은 설정에서 약 15% throughput 향상과 5% latency 감소가 있었지만, 진짜 개선은 튜닝에서 나왔다. 같은 4 GPUs 기준으로 새 vLLM에서 튜닝한 설정은 기존 설정 대비 대략 2배 throughput, 2배 낮은 latency를 만들었다.

핵심은 배포 단위에서의 비교였다. num_instances = total_gpus / tensor_parallel_size로 환산해 8 GPUs 기준으로 맞춰보면, tp=4가 가장 좋은 균형을 보였고, 결과적으로 2개의 4-GPU instance가 8개의 1-GPU instance, 4개의 2-GPU instance, 1개의 8-GPU instance보다 더 나았다. 추정상 tp=1은 KV cache 메모리가 부족하고, tp=8은 통신 오버헤드가 커져 효율이 떨어진다.

멀티 노드에서는 HPA의 기준을 신중하게 골랐다. GPU utilization은 잘 쓰고 있는 상태와 과부하를 구분하지 못하고, throughput 지표도 saturation 이후엔 backlog를 드러내지 못한다. 대신 vLLM의 큐 상태를 나타내는 **vllm:num_requests_waiting**과 **vllm:request_queue_time_seconds**를 봤고, 그중 더 직관적인 average queue size를 autoscaling metric으로 채택했다.

HPA 설정은 평균 대기 요청 수가 임계치를 넘으면 스케일아웃하는 방식이었다.

• minReplicas: 2
• maxReplicas: 10
• target queue size: 1000

임계치 1,000 pending requests per pod는 queue wait time이 training job timeout에 영향을 주기 시작하는 지점에 맞춰 실험적으로 잡았다. 다만 새 JLM instance가 준비되기까지 약 3분이 걸리기 때문에, 스케일업은 빨라도 인스턴스 기동은 느리다는 점을 전제로 threshold를 설정해야 했다. 스케일다운은 15분 stabilization window로 보수적으로 운영해 thrash를 막았다.