대규모 DeepSeek-V4.1-Flash 서빙: vLLM이 DeepInfer와 동등한 성능을 달성하고 GB300 NVL72로 확장

요약: 하나의 NVIDIA GB300 NVL72 랙에서 vLLM은 P/D 분리(disaggregation)와 Wide-EP를 적용해 SemiAnalysis AgentX에서 DeepSeek-V4.1-Flash를 서빙합니다. GPU당 954K tokens/s 사용자당 196 tokens/s의 P90에서, 7.9× 우리의 단일 노드 결과는 다음에서 가져왔으며, 첫 글 그리고 GPU시간당 38.96달러 DeepSeek의 비수기 가격에. 특수화된 디코드 경로는 다음에 도달합니다 초당 826 토큰(tokens/s) 단일 사용자 기준입니다. DeepSeek의 자체 엔진인 DeepInfer와 비교하면, vLLM의 디코드 처리량은 6% 배치 크기 8–256 전 범위에서 동일하며, prefill은 DeepInfer의 공개된 곡선을 따릅니다.

이러한 효율성은 vLLM이 이미 보유한 구성 요소들에 대해 의도적으로 수행한 엔지니어링에서 나온 것으로, DeepSeek이 오픈소스로 공개한 커널을 기반으로 합니다. 이 글에서는 우리의 성능 연구 과정을 소개하고, 각 최적화 기법을 하나씩 살펴보며, 우리가 얻은 교훈을 공유합니다:

• 범용 엔진도 모델 전용 엔진에 필적할 수 있다
• 최적화하기 전에 모델을 이해하십시오.
• 소규모 DEP 인스턴스는 프리필(prefill)에 가장 적합합니다¹
• Wide-EP 디코드는 EPLB와 함께 우수한 확장성을 보입니다
• NVL72 규모에서는 CPU 오버헤드가 중요한 요소가 됩니다
• 특화된 디코드 경로가 낮은 지연 시간을 실현합니다

성능 개요

그림 1: NVIDIA GB300 NVL72에서의 SemiAnalysis AgentX: P/D 분리(disaggregation)와 Wide-EP를 적용한 vLLM(금색)은 이전 글의 단일 노드 집계 결과 대비 추가로 7.9배의 처리량 증가를 달성합니다. 첫 번째 글. 처리량은 캐시된 입력, 캐시되지 않은 입력 및 출력 토큰을 모두 포함합니다 (소스).

DeepInfer와의 비교

DeepInfer 는 DeepSeek이 DeepSeek-V4.1-Flash를 위해 자체 개발한 추론 엔진으로, 이번 주에 사전(prefill) 및 디코드 곡선이 공개된 오프라인 엔진으로 출시되었습니다. 이 모델과 가장 관련성이 높은 참조 대상이므로, 우리의 최적화 내용을 살펴보기에 앞서 vLLM이 이 엔진과 비교하여 어느 수준에 있는지 보여드립니다.

디코드. DeepSeek의 디코드 구성(131K 컨텍스트, nextn=3)에서 GB200의 vLLM은 배치 크기 8에서 256까지의 범위에서 DeepInfer의 공개된 결과와 6% 이내의 처리량 차이를 보입니다 (그림 2).

Figure 2: GPU당 디코드 출력 처리량 vs. 131K 컨텍스트, nextn=3에서의 배치 크기. GB200의 vLLM 대비 DeepInfer의 공개 결과, 해당 README의 차트에서 읽음 (source).

Prefill. DeepInfer의 공개 prefill 곡선은 32개의 중복 전문가(redundant experts)와 140토큰 bounded replay를 갖춘 EP4DP4를 사용하며, 하드웨어는 차트에 명시되어 있지 않고 우리는 차트에서 값을 읽었다. 우리의 실행은 GB300에서 중복 전문가 없이 DEP2, 128토큰 replay, 그리고 자체 프롬프트를 사용했다. 설정이 다르기 때문에 두 곡선 사이의 격차를 엔진 대 엔진 속도 향상으로 해석하지 않는다. Figure 3이 보여주는 것은 vLLM의 DEP2 prefill이 그들이 공개한 범위 전반에서 DeepSeek 자체 엔진의 성능을 따라간다는 점이다.

Figure 3: Prefill 처리량 vs. 새 토큰 수. GB300의 vLLM DEP2 대비 DeepInfer의 공개 곡선 (EP4DP4, 32개 중복 전문가, 140토큰 replay, 하드웨어 미명시), 해당 README의 차트에서 읽음 (source).

두 엔진이 근접한 결과를 보이는 이유는 양방향으로 계보를 공유하기 때문이다. DeepInfer는 원래 vLLM 기반으로 구축되었고, vLLM 역시 MegaAttn, MegaMoE, Mega-mHC를 포함한 DeepSeek의 라이브러리들에서 커널을 지속적으로 통합해 왔으며 나머지 스택을 이들 중심으로 광범위하게 최적화했다. DeepInfer는 오프라인 모드에서 단일 모델을 대상으로 하는 반면, 동일한 vLLM 빌드는 온라인에서 P/D 분리(disaggregation)와 전체 NVL72 랙에 걸친 Wide-EP로 이 모델을 서빙하며, 이 게시물의 나머지 부분에서 측정하는 것이 바로 이 구성이다. 이어지는 섹션에서 해당 작업을 설명한다.

내부 구조: 속도가 나오는 원리

먼저 모델을 측정하라

튜닝 전에 우리는 DeepSeek-V4.1-Flash의 효율적인 아키텍처 설계를 정량화하는 것부터 시작했다:

• 작은 KV 캐시 사용량. cross-layer KV 공유와 FP4 압축 덕분에 글로벌 KV 캐시가 토큰당 단 890바이트 (참조: DeepSeek-V4.1-Flash Technical Report).
• 경량 어텐션. 레이어 2, 8, 14는 전체 컨텍스트 인덱싱에 2× 압축을 사용한다. bounded replay를 통해 레이어 20은 모든 토큰에 대해 글로벌 KV를 기록하지만 인덱싱과 어텐션은 마지막 128개 토큰에 대해서만 수행한다; 레이어 21–39는 해당 토큰들만 처리한다.
• 긴 컨텍스트에서도 디코드는 MoE에 병목이 있다. 아래 Figure 5 참조. 128K 컨텍스트에서 랭크당 64개 요청으로 DEP4 디코딩 시, MoE가 대상 스텝의 62%를 차지하는 반면 어텐션과 인덱서를 합쳐도 13%에 불과하다.

아래 표는 GB300에서 DEP32, 랭크당 16개 요청, 요청당 6개 토큰(토큰 1개와 DSpark 초안 토큰 5개), 모든 요청이 동일한 컨텍스트 길이를 가질 때 타겟 모델의 순전파 시간을 보여줍니다. 128K에서 855K로 갈 때, 6.7배의 컨텍스트 증가는 타겟 모델 디코드 지연 시간에 0.6 ms(+7%)만 추가합니다.

이러한 특성이 이후의 최적화 전략의 방향을 결정합니다:

• 프리필은 작은 DEP 크기로 실행해야 합니다. B300이나 GB300의 DEP2 인스턴스조차도 모델 가중치와 여러 동시 세션을 위한 KV 캐시를 모두 담을 수 있습니다. 더 작은 world size는 DP/EP 로드 밸런싱을 크게 단순화합니다.
• KV 용량은 배치 크기를 제한하는 경우가 드뭅니다. KV 캐시는 HBM에 충분히 들어가므로, KV 용량을 우회할 필요 없이 각 연산을 컴퓨트 또는 메모리 대역폭 한계에 가깝게 밀어붙일 수 있습니다. 이는 또한 스윕이 선점이나 KV 캐시 압박 없이 일관되고 낮은 노이즈를 유지하게 합니다.
• Wide-EP는 디코드에 효과적입니다. MegaMoE 디코드는 가중치 읽기에 의해 병목이 발생하며, Wide-EP는 이 지배적인 MoE 비용을 직접적으로 줄입니다.
• 디코드 DP 로드 밸런싱이 더 단순합니다. 이 모델의 디코드 스텝 시간은 컨텍스트 길이에 따라 거의 변하지 않으므로, DP 로드 밸런싱을 랭크당 요청 수 기준의 최소 부하 방식으로 단순화할 수 있습니다.
• 합성 워크로드도 디코드에 있어 여전히 대표성을 유지합니다. 평균 입력 및 출력 길이를 사용하면 전체 에이전트 트레이스를 재생하지 않고도 성능을 잘 추정할 수 있습니다.

측정 방법

방법론을 지나치게 복잡하게 만들지 않으면서 성능을 정확하게 측정하는 것은 쉽지 않습니다. 우리는 이것을 두 가지 질문으로 나눕니다: 프리필 또는 디코드 스텝의 비용은 얼마여야 하며, DP와 EP 불균형으로 인한 추가 오버헤드는 얼마나 되는가?

• 프리필 및 디코드 스텝 시간. vllm bench forward (#61339)는 실제 execute_model 경로를 통해 DP 및 EP 랭크 전반에서 정확한 프리필 또는 디코드 배치에 대한 모델 순전파 시간을 측정합니다. 이것은 GPU 시간만 측정하며 깔끔한 트레이스를 제공합니다. 또한 vLLM의 DecodeBenchConnector 는 주어진 동시성에서 엔진 수준의 엔드투엔드 디코드 성능을 측정합니다. GPU 전용 시간과 서빙 스텝 시간 사이의 격차는 예상치 못한 오버헤드를 드러냅니다.
• 프리필 DP 불균형: 미러 대 지연 재생. 에이전트 트레이스는 실행마다 달라지므로 DP 불균형을 분리하기 어렵습니다. 따라서 우리는 모든 DP 랭크에서 동일한 요청을 재생합니다. 미러(mirror) 실행에서는 모든 랭크가 동시에 요청을 받습니다. 지연(lag) 실행에서는 랭크 r 동일한 요청을 받음 r × 5 s 후에 동일한 요청을 받으므로, 랭크들의 순서는 어긋나지만 총 작업량은 같습니다. 두 실행 간의 차이가 DP 불균형의 비용입니다.
• Decode EP 불균형: 실제 라우팅 vs. 균등 라우팅. 각 MoE 레이어에 대해, 우리는 balancedness를 랭크 부하의 평균을 최대 랭크 부하로 나눈 값으로 정의하며, 이를 스텝별 및 EPLB의 윈도우에 걸쳐 계산합니다. 균형 잡힌 기준으로서, 동일한 decode 배치를 토큰이 무작위로 균등하게 라우팅되도록 하여 실행합니다. 이 기준에도 샘플링 노이즈가 존재합니다: DEP32에서 GPU당 72개의 요청이 있을 때, 균등 라우팅은 타겟(top-6 routing)에 대해 약 0.96, 드래프트(top-3)에 대해 0.94의 balancedness에 도달합니다. 실제 라우팅과 균등 라우팅 간의 격차가 전문가 밸런싱이 회복할 수 있는 최대치이며, EPLB 실행은 그 격차의 실제 회복량을 보여줍니다.

Prefill: DEP2가 가장 효과적

위에서 논의했듯이, 작은 DEP 크기는 prefill에 매력적입니다. 동시성 256에서의 AgentX prefill 전용 실행에서 DEP4는 DEP2의 GPU당 처리량의 83%만을 기록했습니다(53.3K vs. 64.4K tokens/s). prefix 캐싱을 끈 상태의 미러 및 지연(lag) 리플레이는 DP 불균형을 가리킵니다: 랭크들의 순서가 어긋나면 DEP4는 처리량의 13.6%를 잃습니다.² 이 때문에 우리는 DEP2를 간단한 기본값으로 삼습니다.

트레이스 뒤에 숨겨진 최적화

우리의 첫 번째 게시물 광범위한 프리필 최적화를 다루었습니다. 더 깔끔한 트레이스 덕분에 남아 있는 병목 지점들, 특히 컨텍스트 길이에 따라 증가하는 병목들을 파악할 수 있었습니다. 예를 들어, GB300 GPU 2개에서 8K 토큰 프리필에는 사전 맥락이 없는 경우 87.9 ms,", 그러나" 캐시된 512K 컨텍스트 기준 189.4 ms. 우리는 세 가지 추가 병목 현상을 해결했습니다:

SWA bounded replay는 이미 21–39 레이어를 마지막 128 토큰으로 제한하고 있습니다. 이전에는 20번 레이어가 여전히 모든 새 토큰에 대해 인덱서 계산을 수행했습니다. 이제는 모든 새 토큰에 대해 KV를 기록하지만, 나머지 계산은 128 토큰 리플레이 배치에 대해서만 실행합니다. 이를 통해 프리필 처리량이 다음과 같이 향상됩니다. 32K 새 토큰에서 19.9%, 성능 향상이 4K에서는 10.1%였다가 64K에서는 23.1%로 증가합니다.

Engram은 DP 랭크들 간에 공유되는 호스트 테이블로부터 랜덤 읽기를 수행합니다. 이전 /dev/shm 매핑이 64 KB GPU 페이지를 사용하여 잦은 GPU TLB 미스가 발생했습니다. 테이블을 호스트-NUMA cuMem 할당으로 옮기면 2 MB GPU 페이지를 사용할 수 있게 되어 프리필 처리량이 추가로 향상됩니다 32K 새 토큰에서 2.8%.

프리필 인덱서가 이제 DeepSelect를 사용하여 후보 블록의 순위를 매겨 디코드 경로와 일치하도록 했습니다. 그 효과는 순위가 매겨지는 키의 수가 많아질수록 커지며, 프리필 처리량을 추가로 32K 신규 토큰에서 15.6% , 64K에서 15.2% 향상시킵니다.

이러한 변경 사항을 모두 합치면, 신규 토큰 프리필 처리량이 35.6–43.9% 향상되며, 이는 128K 캐시된 프리픽스 위에서 4K–64K 신규 토큰 범위에 적용됩니다. 32K에서의 결합된 이득은 42.5%이며, 64K에서는 처리량이 71.2K에서 102.5K tokens/s/GPU로 증가합니다 (+43.9%).

그림 4: 128K 캐시 히트 후 DEP2에서 GPU당 신규 토큰 프리필 처리량 — 레이어 20 리플레이, Engram 2 MB 페이지, DeepSelect top-k를 하나씩 순서대로 추가한 결과입니다.

디코드: EPLB로 Wide-EP 확장 및 전문가 밸런싱

디코드 측면에서 EPLB를 사용하는 Wide-EP는 확립된 관행으로, 다음 문서에서 설명됩니다. DeepSeek의 추론 시스템 개요. vLLM은 두 가지를 모두 한동안 지원해 왔습니다(우리의 대규모 서빙 포스트참조). 그리고 우리는 이들이 여전히 잘 작동한다는 것을 발견했습니다. 이 섹션에서는 새로운 발견과 실증적 교훈에 초점을 맞춥니다.

Wide-EP의 스케일링

우리는 128K 컨텍스트에서 GPU당 64개 요청 조건으로(EPLB 활성화; 다음 섹션 참조) DEP4에서 DEP32까지의 디코드 스케일링을 측정했습니다. 각 랭크가 더 적은 수의 전문가를 담당하게 됨에 따라 타겟 MegaMoE 시간은 13.4ms에서 6.0ms로 감소한 반면, 나머지 작업은 약 10ms 수준에 머물렀습니다. 그 결과, GPU당 처리량 증가는 점차 줄어들었습니다. DEP32에서는 드래프트의 통신 오버헤드가 더 넓은 병렬화의 이점을 상쇄하기 시작했습니다.

그림 5: NVIDIA GB200에서 128K 컨텍스트 및 GPU당 64개 요청 조건의 DEP4부터 DEP32까지 랭크별 디코드 스텝 시간, 그리고 GPU당 출력 처리량.

EPLB

우리는 EPLB가 이전 1,000스텝의 부하를 기반으로 3,000스텝마다 전문가를 재배치하도록 했습니다. EPLB는 타겟의 균형도를 0.35에서 0.94로, 드래프트를 0.21에서 0.89로 끌어올려 균등 라우팅과의 격차의 약 97%와 93%를 회복했습니다.

그림 6: GB300 NVL72에서 EPLB 끔, 타겟 모델에만 EPLB 적용, 타겟과 DSpark 드래프트 모두에 EPLB 적용 시의 디코드. 탭에는 스텝별 균형, DEP32에서의 스텝별 시간 분해, 그리고 처리량(3회 실행 평균; 막대는 범위 표시)이 나와 있습니다.

이를 가능하게 만든 두 가지 변경 사항이 있습니다. #62009 는 NVLink 기반의 symm_mem 백엔드를 도입하여 디코드를 중단하지 않고 1초 이내에 DEP32 전체를 리밸런스하고, EPLB의 복제본 매핑과 부하 기록을 MegaMoE 커널에 융합하여(스텝당 약 0.2ms 절감) 디코드 루프에서 호스트 동기화를 제거합니다. #61395 는 이기종 타겟 및 드래프트 모델을 갖는 EPLB를 지원합니다. DSpark 드래프트는 top-3 라우팅으로 128개의 라우티드 전문가를 가지며 타겟은 top-6으로 384개를 가지므로, EPLB는 모델별로 전문가 배치와 부하를 별도로 추적하고 둘 모두를 리밸런스합니다.

빠른 대규모 디코드에서 CPU 오버헤드 극복

Wide-EP 디코드는 모든 레이어에서 모든 랭크를 동기화하므로, 하나의 느린 랭크가 인스턴스 전체를 지연시킵니다. 비동기 스케줄링은 소규모에서는 CPU 오버헤드를 잘 숨기지만, 랭크 수가 많아지면 두 가지 방식으로 이것이 더 어려워집니다: GPU 스텝이 짧아져 CPU 작업을 위한 여유가 줄어들고, 하나의 랭크가 뒤처질 가능성이 높아집니다.

실제로 우리는 최적화되지 않은 DEP32가 GPU 실행은 1.1ms 더 빨랐음에도 DEP16보다 느리게 실행되는 것을 관찰했습니다(스텝당 17.57ms 대 13.84ms). 아래 표는 우리가 발견한 모든 원인을 영향 순으로 나열한 것입니다. 영향은 서로 다른 설정에서 나온 것이므로 각 행은 자체적인

낮은 지연 시간: 소규모 배치를 위한 특화된 디코드 경로

또한 DeepSeek-V4.1-Flash(#61868 및 #61869)에 대한 저지연 커널 지원을 확장하여, 우리의 이전 게시물의 노력을 이어갔습니다. 실제 AgentX 세션에서 특화된 디코드 경로는 4개의 B300 GPU에서 단일 사용자에 대해 P90 826 tokens/s를 달성하며, 표준 디코드 경로(575)보다 44% 높습니다.

그림 7: 동시성 1, 8, 16에서 4개의 B300 GPU를 사용한 SemiAnalysis AgentX with TP4, 특화된 디코드 경로로 전환하기 전과 후 InferenceX #4332 이 특화된 디코드 경로로 전환했습니다.

감사의 글

우리는 DeepSeek 에게 DeepSeek-V4.1-Flash와 그 최적화된 커널을 오픈소스로 공개하고 공유해 주신 점, 이 작업의 기반이 되어 주신 점, 그리고 학습하고 비교할 수 있는 훌륭한 참고 자료가 되어 준 DeepInfer와 그 성능 결과를 발행해 주신 점에 감사드립니다. 또한 SemiAnalysis 에게 AgentX 벤치마크 플랫폼과 모든 도움에 감사드립니다.

우리는 특히 다음 분들께 감사드립니다 페이 리(Pei Li), 한지에 추(Hanjie Qiu), 리사 왕(Lisa Wang), 야오야오 딩(Yaoyao Ding), 로힛 나그라지(Rohit Nagraj), 신 리(Xin Li) 출처 NVIDIA 성능 최적화를 위한 긴밀한 협업, vLLM과 Dynamo 전반에 걸친 지속적인 지원, 그리고 AgentX 제출물에 대한 도움에 감사드립니다. 또한 다음 분들께 감사드립니다. Canlin Guo 다음 출처에서 vLLM 커뮤니티 그의 귀중한 프리필 최적화에 감사드립니다.

이 연구는 다음 인물이 주도했습니다: Inferact.

각주

1. DEPn 는 데이터 병렬 어텐션에 전문가 병렬성(expert parallelism)을 결합한 것으로, n GPU. Target forward는 각 디코딩 단계에서 메인 모델의 전체 포워드 패스로, 드래프트 토큰을 검증하고 출력을 생성합니다. draft forward는 DSpark 드래프트 모델의 전체 포워드 패스로, 다음 단계를 위한 토큰을 제안합니다. ↩

2. 이전 빌드 기준으로 측정되었으며, 불균형 비용은 커널이 아닌 DEP 크기의 속성입니다. ↩