vLLM v0.32.0 GLM-5.3 서빙: 16대 H200에서 PCP, DCP, 하이브리드 HiSparse

16대 H200에서 긴 에이전트 컨텍스트로 GLM-5.3을 서빙하려면 표준 텐서 병렬 처리와 데이터 병렬 처리가 제공할 수 없는 두 가지 메커니즘이 필요합니다: 각 프롬프트를 토큰 단위로 GPU에 분할하는 프리필 컨텍스트 병렬 처리(PCP)와 KV 캐시를 분할하여 100만 토큰 컨텍스트가 맞도록 하는 디코드 컨텍스트 병렬 처리(DCP)입니다. 하이브리드 HiSparse 디코딩과 결합된 이 vLLM 배포(vLLM v0.32.0 이상)는 AgentX 벤치마크에서 동일한 처리량으로 데이터 병렬 배포보다 사용자당 상호작용성이 1.7~3.2배 향상되며, 작성자가 테스트한 구성 중 100만 토큰 요청을 전혀 서빙할 수 있는 유일한 구성입니다.

이 글은 vLLM의 GLM-5.3 최적화 시리즈의 2부입니다. 1부에서는 단일 8x H200 노드에서 집계 배포의 하이브리드 HiSparse를 다루었습니다. 2부에서는 두 개의 8x H200 노드에 걸친 프리필/디코드 분리를 다룹니다.

발표 내용

vLLM은 16대 H200을 하나의 프리필 노드와 하나의 디코드 노드로 분할하여 GLM-5.3 장기 컨텍스트 에이전트 워크로드를 서빙하는 방법을 설명하는 기술 문서를 게시했습니다. 이 게시물은 세 가지 구성 요소를 소개하고 이들이 어떻게 구성되는지 보여줍니다:

  • 프리필 컨텍스트 병렬 처리(PCP) 는 각 프롬프트를 어텐션 헤드가 아닌 토큰 단위로 GPU에 분할하여 GLM-5.3의 희소 어텐션에 텐서 병렬 처리보다 더 적합합니다.
  • 디코드 컨텍스트 병렬 처리(DCP) 는 프리필 엔진의 KV 캐시를 토큰 단위로 분할하여 100만 토큰 컨텍스트가 프리필 노드에 맞도록 합니다.
  • 하이브리드 HiSparse 는 디코드 엔진이 KV를 호스트 메모리에 유지할 수 있게 하여 100만 토큰 요청이 디코드 측에 맞도록 합니다.

SemiAnalysis AgentX 벤치마크에서 PCP8과 DCP8 프리필 및 하이브리드 HiSparse 디코드는 동일한 처리량에서 데이터 병렬(DP8) 배포보다 사용자당 속도가 1.73.2배 향상되었고, 중간 첫 토큰 시간(TTFT)을 1.55.2초에서 0.8~0.9초로 줄였습니다.

H200에서 긴 에이전트 컨텍스트가 표준 병렬 처리를 깨뜨리는 이유

에이전트 워크로드는 매 턴마다 증가하는 긴 컨텍스트를 가지며, 이는 GPU 메모리와 프리필 처리량 모두에 부담을 줍니다. H200에서 GLM-5.3의 가중치는 각 GPU 메모리의 대부분을 차지하므로 긴 컨텍스트의 KV 캐시를 위한 공간이 거의 없습니다. 모든 턴이 프리필에 더 많은 도구 출력과 파일 내용을 추가하므로, 부하가 걸리면 프리필 엔진이 전체 배포의 병목이 될 수 있습니다. 프리필/디코드 분리만으로는 이 문제를 해결할 수 없습니다.

DP8과 TP8이 부족한 이유

8x H200 노드에서 GLM-5.3 프리필을 실행하는 두 가지 표준 방법은 데이터 병렬(DP8)과 텐서 병렬(TP8)이며, 둘 다 서로 다른 이유로 실패합니다:

  • DP8 은 각 프롬프트를 단일 GPU에 할당하므로 어텐션이 나머지 7개를 사용할 수 없습니다. 이는 긴 프롬프트의 첫 토큰 시간을 제한하고, 프롬프트의 KV 캐시가 해당 GPU 메모리에 맞아야 합니다.
  • TP8 은 어텐션 헤드를 GPU에 분할합니다. MLA의 잠재 KV가 64개 헤드 모두에 공유되므로 모든 GPU가 전체 캐시를 저장하지만 8개 헤드만 서빙하기 위해 읽습니다. 희소 MLA가 어텐션하는 2,048개 토큰을 선택하기 위해 모든 이전 토큰을 점수화하는 인덱서는 전혀 분할되지 않으므로 이차 비용이 모든 GPU에서 반복됩니다.

두 방식 모두 하나의 긴 프롬프트의 어텐션 작업을 8개 GPU에 분산하면서도 서빙하는 각 GPU에 전체 KV 캐시를 유지하지 않습니다. PCP는 쿼리 측을 해결하고 DCP는 KV 측을 해결합니다.

PCP: 헤드가 아닌 토큰 분할

프리필 컨텍스트 병렬 처리는 각 프롬프트를 토큰 단위로 8개 GPU에 분할합니다: 각 GPU는 64개 헤드를 모두 사용하여 프롬프트의 1/8에 대한 쿼리를 계산합니다. 인과 어텐션에서 토큰은 이전의 모든 토큰에 어텐션하므로 프롬프트 끝을 보유한 GPU가 시작 부분을 보유한 GPU보다 훨씬 많은 작업을 수행하게 되어 순진한 분할은 불균형합니다. PCP는 대신 프롬프트를 16개 청크로 자르고 쌍을 이루어 GPU g가 앞에서 청크 g를, 뒤에서 청크 15 - g를 가져와 모든 GPU가 저렴한 토큰과 비싼 토큰을 동일하게 혼합하도록 합니다. 이는 "Context Parallelism for Scalable Million-Token Inference"(arXiv 2411.01783) 논문의 부하 균형 분할입니다. 각 GPU의 새 KV는 모든 쿼리가 전체 컨텍스트에 어텐션할 수 있도록 전체 수집됩니다.

산술 강도에 대한 효과가 핵심 수치입니다. PCP에서 각 GPU는 자체 토큰만 인덱싱하므로 각 GPU는 인덱서 작업의 1/8을 수행하고 전체를 복제하지 않습니다. 그리고 메모리에서 읽는 각 KV 행은 8개 헤드 대신 64개 헤드에 서빙되어 희소 MLA를 이동 바이트당 약 26에서 약 191 FLOPs로 높입니다. H200의 BF16 리지 포인트는 바이트당 206 FLOPs이므로 PCP는 희소 MLA를 계산 집약에 가깝게 만듭니다.

인덱서를 복제하지 않는 것은 긴 프리필에서 가장 중요합니다. 인덱서의 비용은 프롬프트 길이에 따라 이차적으로 증가하는 반면, 희소 MLA는 각 쿼리가 고정된 2,048개 토큰에 어텐션하므로 선형적으로만 증가합니다. 처음부터 프리필의 FLOPs를 계산하면 TP8에서 프롬프트가 약 32K 토큰에 도달하면 인덱서가 희소 MLA를 추월합니다. PCP8에서는 어떤 GPU도 복제하지 않으므로 교차 지점이 약 256K 토큰으로 이동합니다.

PCP에는 두 가지 남은 비용이 있습니다. 각 GPU는 모든 어텐션 가중치를 보유해야 하지만 MoE 전문가는 EP8로 8개 GPU에 분할된 상태로 유지됩니다. 그리고 새 KV가 매 레이어 전체 수집되므로 모든 GPU는 여전히 전체 KV 캐시를 저장합니다. 복제된 캐시는 계산이 아니라 컨텍스트 길이를 제한하며, DCP가 제거하는 것입니다.

DCP: KV 캐시도 분할

디코드 컨텍스트 병렬 처리는 KV 캐시 자체를 분할합니다. 100만 토큰 GLM-5.3 요청은 53.4 GiB의 FP8 KV가 필요하지만 각 GPU에는 약 15 GiB만 저장할 수 있습니다. DCP는 토큰을 8개 GPU에 라운드 로빈으로 분배하므로 각 GPU는 8번째 토큰마다 저장하고 동일한 요청은 GPU당 6.7 GiB(53.4 / 8)만 필요합니다.

이름은 역사적이며 현재 배포를 설명하지 않습니다. DCP는 각 요청에 단일 쿼리 토큰이 있고 KV 캐시가 분할할 유일한 것인 디코드를 위해 구축되었습니다. PCP는 프롬프트의 많은 쿼리 토큰이 작업인 프리필을 위해 구축되었습니다. 이 배포는 둘 다 프리필 엔진 내부에서 실행되며, PCP는 쿼리를 분할하고 DCP는 KV를 분할합니다.

DCP가 캐시를 분할하므로 각 GPU의 쿼리가 필요한 KV의 대부분은 이제 다른 GPU에 있습니다. 디코드에서 DCP는 쿼리를 KV로 보냅니다: 각 GPU는 자체 샤드에 대해 어텐션하고 부분 결과는 로그-섬-지수로 병합됩니다. 이 프리필 엔진에서는 방향이 반대입니다: 매 레이어 각 GPU는 샤드를 임시 전체 컨텍스트 복사본으로 전체 수집하고 자체 쿼리에 대해 어텐션한 다음 복사본을 해제합니다. 영구 캐시만 8로 나뉩니다.

두 레이아웃은 정렬되지 않습니다. GPU는 8번째 토큰마다 저장하지만 청크 g와 15 - g의 쿼리를 계산하므로 매 레이어 전체 수집이 필요한 이유입니다.

전체 수집 비용

전체 수집은 무료가 아닙니다: 매 레이어 전체 캐시된 컨텍스트를 다시 보내므로 비용이 컨텍스트 길이에 따라 증가합니다. 동일한 2K 토큰 프리필 청크를 동일한 캐시된 컨텍스트에서 DCP8 유무에 따라 하나의 PCP8 노드에서 실행하여 효과를 분리하면 DCP8은 64K 토큰 컨텍스트까지 단계당 약 6%를 추가하고 248K 토큰에서 15%로 증가합니다. 이는 8배 더 큰 KV 풀의 가격입니다. 작성자는 각 레이어의 전체 수집을 이전 레이어의 계산과 겹쳐 오버헤드를 줄일 수 있다고 말하며, 현재 작업 중인 최적화입니다.

약 250K 토큰을 넘으면 PCP8만으로는 KV 캐시를 보유할 수 없으므로 DCP는 오버헤드가 아니라 긴 프롬프트를 가능하게 하는 요소가 됩니다. 함께 PCP8과 DCP8은 프리필 엔진에 속도와 공간을 모두 제공합니다.

배포: 16대 H200에서 프리필/디코드 분리

배포는 두 개의 8x H200 노드에서 프리필/디코드(P/D) 분리 설정입니다. 두 엔진 모두 FP8 KV 캐시와 3개의 드래프트 토큰(MTP3)을 사용한 MTP 추측 디코딩을 사용합니다.

  • 프리필: 512 GiB CPU KV 오프로드가 있는 하나의 PCP8 x DCP8 x EP8 엔진으로, 이후 턴이 접두사를 재사용할 수 있습니다.
  • 디코드: 1부의 하이브리드 HiSparse(랭크당 48 GiB 호스트 풀 및 16 GiB 오프로드)가 있는 8개의 DP 랭크로, 디코드 동시성은 HBM이 아닌 호스트 메모리에 의해 제한됩니다.

접두사 인식 llm-d 라우터는 각 요청을 프리필 엔진으로 보내고, NIXL 커넥터는 KV 캐시를 디코드 랭크로 이동하며, 디코드 랭크는 토큰을 다시 스트리밍합니다.

비교 기준은 동일한 하드웨어와 동일한 총 메모리를 사용합니다: PCP8 x DCP8 프리필은 DP8 프리필(각각 64 GiB CPU KV 오프로드가 있는 8개의 DP 랭크, 총 512 GiB)과 비교되고, 하이브리드 HiSparse는 디코드 노드의 일반 CPU KV 오프로딩과 비교되며, 어느 쪽이든 512 GiB 호스트 메모리를 사용합니다. 모든 구성은 동일한 16개 GPU, 호스트 메모리 및 vLLM 빌드를 실행합니다.

AgentX 결과

벤치마크는 SemiAnalysis AgentX입니다: 접두사 재사용으로 재생된 Claude Code 트레이스, 동시성마다 새 서버, 1시간 실행, 합성 수락 길이가 2.99로 고정된 MTP3으로 모든 구성이 동일한 추측 속도 향상을 얻습니다. 처리량은 캐시된 토큰을 포함한 GPU당 논리 토큰/초로 측정됩니다 - 입력 및 출력 토큰, 접두사 캐시된 입력 포함, 16개 GPU 모두에 걸쳐. 상호작용성은 AgentX의 P90 종단 간 정규화된 사용자당 출력 토큰/초입니다.

측정은 두 가지 컨텍스트 제한에서 수행되었습니다: c8c64는 142K, c8c32는 1M입니다.

c32까지 배포는 대부분 프리필 바운드이므로 프리필러가 더 큰 차이를 만듭니다. 두 설정 모두 HiSparse 디코드를 사용할 때 PCP8 x DCP8 프리필은 동일한 처리량에서 DP8보다 상호작용성이 1.73.2배 높고 중간 TTFT를 1.55.2초에서 0.8~0.9초로 줄입니다. 이 부하에서 디코더는 거의 차이가 없습니다: c8과 c16에서 두 PCP8 x DCP8 구성은 서로 몇 퍼센트 차이이며, 오프로드 전용 디코드는 c8에서 약간 앞섭니다.

c32부터 배포는 더 디코드 바운드가 되고 HiSparse 디코드가 앞서 나갑니다. c64에서 처리량이 거의 두 배로 증가하여 사용자당 29.6 토큰/초에서 GPU당 8,340 논리 토큰/초에 도달하는 반면, 다른 모든 구성은 사용자당 1~2 토큰/초로 떨어집니다.

1M 컨텍스트에서 배포는 두 메커니즘이 모두 필요합니다. DP8 프리필 랭크는 100만 토큰 요청 하나를 보유할 수 없고 오프로드 전용 디코드 랭크도 마찬가지입니다. 이것이 결합 구성이 100만 토큰 컨텍스트를 서빙하는 유일한 테스트 구성인 이유입니다.

기능 구성

어려운 엔지니어링 작업은 PCP, DCP, 하이브리드 HiSparse와 같은 기능을 구성하는 것입니다. 각 기능이 KV 캐시의 레이아웃, 스케줄링 또는 이동을 변경하고 모든 조합이 정확하고 빠르게 유지되어야 하기 때문입니다.

프리필/디코드 분리의 경우 KV는 두 엔진 간에 레이아웃을 변경해야 합니다. 프리필 엔진은 각 요청의 KV를 8개 GPU에 토큰 단위로 분할하는 반면, 각 디코드 랭크는 MTP 레이어를 포함한 전체 KV를 자체 페이지 레이아웃으로 필요로 합니다. NIXL 커넥터는 두 노드 간에 이 재조립을 수행하며, CPU 오프로드의 접두사 재사용도 함께 계속 작동해야 합니다.

게시물의 모든 구성은 vLLM의 새로운 모듈식 코어인 Model Runner V2에서 실행되며, 모델별 상태를 공통 실행 경로에서 분리하고 CPU-GPU 동기화 없이 추측 디코딩을 실행합니다. 하이브리드 HiSparse는 이를 기반으로 구축되었습니다.

재현 방법 및 필수 플래그

게시물의 모든 내용은 vLLM v0.32.0 이상에서 vllm/vllm-openai:v0.32.0 이미지를 사용하여 실행됩니다. 보고된 결과는 커밋 9e38b4111a의 vLLM main에서 측정되었으며, 재현 gist는 커밋 2537629eb2를 고정합니다.

프리필 엔진의 주요 플래그는 다음과 같습니다:

--prefill-context-parallel-size 8 \
--decode-context-parallel-size 8 \
--dcp-comm-backend ag_rs \
--enable-expert-parallel \
--attention-config '{"sparse_mla_force_mqa":true}'

한 가지 플래그는 설명이 필요합니다. sparse_mla_force_mqa가 없으면 프롬프트가 2,048 토큰 top-k에 맞는 프리필 배치는 밀집 MHA 경로를 사용합니다. 이 플래그는 희소 MLA(MQA) 커널에서도 유지하여 모든 KV 행이 모든 헤드에 서빙되도록 합니다.

숫자가 맞는 이유

메모리와 계산에 대한 게시물의 주장을 뒷받침하는 세 가지 각주 계산이 있습니다. 희소 MLA는 각각 660바이트(FlashMLA의 fp8_ds_mla 형식의 656바이트 FP8 KV 및 4바이트 인덱스)인 2,048개 선택된 KV 행을 읽으며, 쿼리당 약 1.35MB입니다. 각 헤드는 BF16 쿼리 및 출력에 2,176바이트를 추가하고 행당 2,176 FLOPs(QK 576차원, PV 512차원)를 수행합니다. 따라서 8개 헤드는 1.37MB에 대해 35.7 MFLOPs, 약 26 FLOPs/바이트를 수행하고, 64개 헤드는 1.49MB에 대해 285 MFLOPs, 약 191 FLOPs/바이트를 수행합니다.

H200 SXM의 경우 BF16 리지 포인트는 4.8 TB/s 대역폭에서 989 밀집 BF16 TFLOP/s, 즉 바이트당 206 FLOPs입니다. 데이터시트의 1,979 TFLOP/s 수치는 2:4 희소성을 가정합니다.

53.4 GiB 수치는 토큰당 KV 계산에서 비롯됩니다: 78개 레이어 x 656바이트 MLA KV, 21개 인덱서 레이어 x 132바이트 인덱서 키(128 FP8 값 및 4바이트 스케일), MTP 레이어의 788바이트, 총 54,728바이트. N = 1,048,576 토큰의 경우 54,728 MiB, 약 53.4 GiB입니다.

작업 수행자

이 작업은 Red Hat의 Roberto L. Castro, Simon Veitner, Matthew Bonanni, Lucas Wilkinson과 Mistral의 Nicolo Lucchesi가 수행했습니다. Red Hat의 Maroon Ayoub와 Robert Shaw는 배포 스트레스 테스트, 오류 보고 및 버그 수정에 기여한 것으로 인정받았습니다.

Sources