아티클 목록으로
추론·배포

vLLM이 Qwen3.8-2.4T의 PD 서빙을 최적화한 방법

약 3분 소요

들어가며

Qwen3.8-2.4T는 대규모 MoE와 하이브리드 시퀀스 처리 구조를 함께 사용하는 모델입니다. 따라서 단순히 파라미터 수만으로 추론 서버의 용량과 병렬 구성을 결정하기 어렵습니다. vLLM은 이번에 GB300 NVL72 클러스터에서 Prefill-Decode 분리, 즉 PD 서빙을 평가하고 8K 입력·1K 출력 조건에서 처리량과 지연시간을 함께 분석했습니다.

처리량을 우선한 구성에서는 GPU당 약 5000 총 토큰 처리량을 보고했습니다. 상호작용성을 중시한 낮은 지연시간 구성에서는 사용자당 180 생성 토큰을 달성했습니다. 이 수치는 모든 서비스에 적용되는 단일 최적값이라기보다, 서로 다른 목표에 맞춰 측정한 성능 프런티어의 지점으로 이해해야 합니다.

핵심 내용

  • 동시성의 상한은 KV 캐시가 결정한다. 모델은 92개 레이어로 구성되며 69개는 GDN, 23개는 Full-Attention입니다. 모든 레이어에는 MoE 블록이 들어갑니다. Full-Attention 상태는 토큰 수에 따라 증가하지만 GDN 상태는 요청별로 저장되므로 메모리 계획에 큰 영향을 줍니다.
  • 블록 크기는 GDN 상태에 맞춰진다. 자료의 추산에 따르면 GDN 상태는 약 4.125MiB이며, 하나의 블록에는 2112개 토큰이 들어갑니다. 8K 입력과 1K 출력을 처리할 때 Full-Attention과 GDN은 서로 다른 방식으로 블록을 사용하고, 두 부분의 합이 요청별 캐시 사용량을 결정합니다.
  • 가중치 외 메모리도 고려해야 한다. 드라이버 오버헤드, CUDA 컨텍스트, NCCL 버퍼, 메모리 할당기, 최대 활성화 메모리, CUDA Graph가 모두 KV 캐시 공간을 줄입니다. gpu_memory_utilization 설정도 사전에 예측하기 어려운 피크를 위해 여유 공간을 남깁니다.
  • Prefill과 Decode의 전송 레이아웃은 호환되어야 한다. 두 엔진은 블록 크기를 독립적으로 계산할 수 있지만 KV 캐시를 옮기려면 크기가 맞아야 합니다. 맞지 않으면 --block-size를 수동으로 지정할 수 있으나, 일부 캐시 공간을 낭비할 수 있습니다.
  • 병렬 구성은 목표 지표에 따라 달라진다. 테스트는 TP8과 TP4DP4를 포함한 여러 구성을 서로 다른 동시 요청 수와 배치 상한에서 비교했습니다. 단순히 동시성을 늘리는 것이 아니라 활성화 메모리, CUDA Graph, KV 캐시의 제약을 함께 만족시켜야 합니다.

의미와 영향

이 분석에서 재사용할 가치가 가장 큰 부분은 최종 수치보다 튜닝 순서입니다. 먼저 요청 하나가 사용하는 상태를 계산하고, 모델 가중치와 런타임 예약 공간을 제외한 뒤, 활성화 메모리 피크를 측정합니다. 이후 동시성, 배치 상한, 병렬 구성을 바꿔 처리량과 지연시간의 프런티어를 구성합니다. 어텐션, 재귀 상태, MoE를 함께 사용하는 모델에서는 파라미터 수만으로 메모리와 처리 용량을 추정하는 방식이 충분하지 않을 수 있습니다.

PD 서빙 역시 단순히 Prefill과 Decode 연산을 분리하는 기술에 그치지 않습니다. 두 단계의 캐시 배치, 데이터 전송 호환성, 각 엔진의 메모리 관리가 실제 성능을 좌우합니다. vLLM은 특정 모델의 레시피만 제시한 것이 아니라 판단 과정을 함께 공개해, 사용자가 다른 모델이나 서비스 목표에도 같은 측정 절차를 적용할 수 있도록 했습니다.

출처: vLLM Blog

댓글

로그인 상태 확인 중…

댓글 불러오는 중…

관련 게시물

CCTest · Blog
Fathom, 질의별 KV 캐시 읽기 깊이로 장문맥 디코딩 최적화
추론·배포
cctest.ai
추론·배포

Fathom, 질의별 KV 캐시 읽기 깊이로 장문맥 디코딩 최적화

Fathom은 장문맥 KV 캐시가 호스트 메모리로 오프로드될 때 발생하는 인덱스 스캔 병목을 줄이는 방법입니다. 각 질의가 키 채널별 읽기 비트 수를 결정해 전송량을 낮추면서 희소 어텐션의 정확도를 유지합니다.

더 보기