vLLM PD Serving의 Qwen3.8-2.4T가 GPU당 5K TPS 및 사용자당 180 gen tok/s 달성

요약 (TL;DR)

Qwen3.8-2.4T 모델에 대한 vLLM의 PD 서빙은 고처리량 모드에서 GPU당 총 5,000 토큰 처리량을, 저지연 모드에서 사용자당 180 생성 토큰을 달성하여 GB300 NVL72 클러스터에서 해당 모델에 대한 완전한 파레토 프론티어를 구축했습니다.

발표 개요

이 블로그 게시물은 vLLM이 8K/1K 워크로드를 사용하여 GB300 NVL72 클러스터에서 보고된 성능을 어떻게 달성했는지 자세히 설명합니다. 재현 가능한 srt-slurm 레시피, 단계별 튜닝 방법론, 그리고 총 토큰 처리량(TPS)과 사용자당 상호작용성(사용자당 gen TPS) 사이의 균형을 맞춘 전체 파레토 프론티어를 제공합니다. 이 방법론은 모든 모델에 적용할 수 있기 때문에 단순한 수치보다 더 가치 있는 것으로 제시됩니다.

처리량 극대화: 동시성 및 KV-캐시 제한

결론

GPU당 총 토큰 처리량은 주로 KV-캐시 용량에 의해 제한되며, 이는 다시 요청당 GDN 상태의 크기에 의해 결정됩니다.

기술적 세부 사항

  • 모델 아키텍처: Qwen3.8-2.4T는 92개의 레이어(69개 GDN, 23개 Full-Attn)와 레이어당 512개의 전문가(expert)를 가진 MoE 블록으로 구성됩니다.
  • 가중치 점유율: 91 GiB의 비전문가 가중치, 1,242 GiB의 전문가 가중치.
  • KV-캐시 구성:
    • Full-Attn 상태: 레이어당 토큰당 2 KiB.
    • GDN 상태(요청당): 4 MiB (SSM) + 120 KiB (conv) ≈ 4.216 MiB.
  • 블록 크기 조정: GDN 상태가 지배적이므로 2,112개의 토큰을 보유하는 블록으로 이어집니다(블록당 4.125 MiB).
  • GPU 메모리 기준: GB300은 279 GB를 제공하며, 드라이버, CUDA 컨텍스트 및 8%의 안전 예비 공간을 제외하면 가중치, 활성화, CUDA 그래프 및 KV-캐시를 위해 약 254 GiB가 남습니다.
  • 최대 활성화 메모리: 토폴로지별로 측정됨(예: 20개 시퀀스를 사용하는 TP8은 0.57 GiB, 272개 시퀀스를 사용하는 TP4DP4는 최대 2.24 GiB 사용).
  • CUDA 그래프 예약: 보수적으로 추정됨; 실제 사용량은 종종 더 낮지만, 예약은 OOM(메모리 부족)을 방지합니다.
  • KV-캐시 가용성: 비가중치 메모리(약 20 GiB)를 고려한 후, 남은 메모리가 동시 요청 수를 결정합니다. TP4DP4 토폴로지는 가장 많은 KV-캐시 공간을 제공하여 가장 높은 동시성을 가능하게 합니다.

프리필(Prefill) 성능 측정

결론

낮은 동시성에서는 TP4DP2+EP 토폴로지가 최고의 프리필 처리량을 산출하며, 높은 동시성에서는 TP2DP4+EP가 우세해집니다.

결과

프리필 처리량은 ISL/OSL = 8192/2로 측정되었습니다. 곡선은 동시성이 증가함에 따라 TP2DP4+EP가 TP4DP2+EP를 추월하는 명확한 교차점을 보여줍니다.

디코드(Decode) 성능 측정

결론

MTP(추측 디코딩)는 KV-캐시가 병목 현상이 될 때까지 디코드 처리량을 크게 향상시킵니다. 전체적으로 가장 좋은 디코드 토폴로지는 TEP8 with MTP이며, 매우 높은 동시성에서는 TP4DP4+EP가 그 뒤를 잇습니다.

결과

디코드 테스트는 ISL/OSL = 1/1000을 사용했습니다. 3개의 추측 토큰으로 MTP를 활성화하면 GPU당 처리량이 증가했으며, 그 이후에는 KV-캐시 제한에 도달할 때까지 TEP8 토폴로지(MTP 포함)가 앞서고, 그 이후에는 TP4DP4+EP가 선두를 차지합니다.

분산 파레토 프론티어

결론

최적의 프리필 및 디코드 구성을 결합하면 모델이 GPU당 5K 총 토큰 처리량과 사용자당 180 생성 토큰을 달성하는 최종 파레토 프론티어가 산출됩니다.

환경 및 재현성

  • 하드웨어: GB300 클러스터, NVLink72 인터커넥트.
  • 워크로드: ISL = 8192, OSL = 1024, 동시성 1–2560.
  • 모델: HuggingFace의 Inferact/Qwen3.8-2.4T-A95B-NVFP4.
  • 소프트웨어 스택:
    • vLLM Docker 이미지 vllm/vllm-openai:nightly-a9a17 (리비전 v0.26.1rc1.dev1177+ga9a17e709).
    • Dynamo 1.2.0.dev20260526.
    • srt-slurm v1.0.98.
    • AIPerf v0.12.0.
  • 레시피: 모든 실행 스크립트는 srt-slurm-recipes 저장소의 recipes/multi-node/Qwen3.8/GB300/8k1k/vllm/disagg에 있습니다.

정확도 검증

모든 구성은 GSM8K 벤치마크에서 검증되었으며 전반적으로 95%의 정확도를 달성하여 성능 향상이 모델 품질을 희생하지 않음을 확인했습니다.

성능 시각화

  • 그림 3 – 각 분산 구성에 대한 파레토 곡선(동시성에 대한 개별 스윕).
  • 그림 4 – 총 TPS와 사용자당 생성 속도 간의 최적의 절충안을 보여주는 결합된 파레토 프론티어.

실무자를 위한 시사점

결론

제시된 튜닝 워크플로우(KV-캐시 추정, 활성화 및 CUDA 그래프 오버헤드 측정, 워크로드별 토폴로지 선택)를 통해 실무자는 vLLM에서 모든 대규모 모델에 대해 프론티어 수준의 성능을 재현할 수 있습니다.

실무적 요점

  1. KV-캐시 크기 조정이 주요 제한 요소입니다; 최대 동시성을 추정하기 위해 요청당 GDN 상태를 정확하게 계산하십시오.
  2. 충분한 GPU 메모리를 예약하십시오(기본 8% 안전 마진). CUDA 그래프 추정 오류를 수용하기 위함입니다.
  3. KV-캐시 여유 공간에 따라 디코드 토폴로지를 선택하십시오: TP4DP4+EP는 캐시 공간을 최대화하고, TEP8은 캐시가 충분할 때 뛰어납니다.
  4. 디코드 워크로드에 MTP를 활성화하여 KV-캐시가 포화 상태가 될 때까지 처리량을 높이십시오.
  5. 제공된 srt-slurm 레시피를 사용하여 정확한 환경을 재현하고 자신의 클러스터에서 결과를 검증하십시오.

감사의 말

Artem Perevedentsev (NVIDIA), Vadim Gimpelson (NVIDIA), Xin Li (NVIDIA) 및 기여와 검토를 해주신 더 넓은 vLLM 커뮤니티에 감사드립니다.

Sources