vLLM의 Kimi K3: NVIDIA GB300에서 특화된 CuTe DSL 디코드가 초당 842 토큰 달성
vLLM은 Kimi K3를 위한 새로운 디코드 경로를 공개했습니다. 이 경로는 모델의 디코드 연산 거의 전체를 NVIDIA GB300에 맞게 튜닝된 맞춤형 CuTe DSL 커널로 대체하며, DSpark 추측 디코딩을 사용하여 16개의 GB300 GPU에서 배치 1 기준 초당 842 토큰을 달성합니다. 이는 동일한 설정의 기본 vLLM보다 1.73배 빠른 성능입니다. 이 게시물은 또한 이 작업 뒤에 있는 프로세스 변경 사항을 소개합니다: 제안된 "패스트트랙 모델 최적화 RFC"(vllm-project/vllm 이슈 #59665)는 줄 단위 인간 검토를 격리, 제한된 범위, 체계적인 정확성 검증, 재현 가능한 성능 증거로 대체합니다.
이 기여는 8개 또는 16개 GPU를 사용하는 NVIDIA Blackwell GPU, 1~64의 디코드 배치, 긴 컨텍스트를 위한 선택적 디코드 컨텍스트 병렬 처리를 대상으로 합니다. GPU는 멀티캐스트를 지원하는 하나의 NVLink 도메인을 공유합니다. Kimi K3 풀 리퀘스트는 vllm-project/vllm #61867입니다.
Kimi K3 디코드 경로: 레이어당 23개 대신 13개 커널
특화된 디코드 경로는 Kimi K3 디코드 단계의 거의 모든 연산을 맞춤형 CuTe DSL 커널로 융합하고 대체합니다. 레이어당 측정 기준, 기본 vLLM은 130마이크로초와 23개의 커널을 사용하는 반면, 특화된 디코드 경로는 69마이크로초와 13개의 커널을 사용합니다.
최적화 작업은 에이전트 지원으로 이루어졌습니다: 코딩 에이전트를 사용하여 복잡한 GPU 커널을 작성하고, 연산자 간 융합을 수행하고, 통신과 계산을 중첩시키고, 배치 크기와 GPU 구성에 따라 실행을 튜닝했습니다. 결과 경로는 8개 또는 16개 GPU에서 어텐션, MoE, 통신을 포함합니다.
1. 워크로드에 맞게 커널 형태 튜닝
디코드 배치 크기에 따라 다른 커널 선택이 필요합니다. 어텐션 입력 프로젝션의 경우, Kimi K3 경로는 배치 크기 1~2에서 특화된 소형 행렬 커널을 사용하고, 더 큰 배치에서는 split-K 커널을 사용하여 행렬 곱셈을 더 많은 GPU 워커에 분할합니다. 이러한 프로젝션은 GPU 리소스를 완전히 활용하고 메모리 읽기, 통신, 계산을 최대한 중첩할 수 있는 적절한 크기의 커널을 실행하도록 튜닝됩니다.
KDA는 또한 배치 크기와 각 GPU의 어텐션 헤드 수에 맞게 스케줄링이 조정된 최적화된 CuTe DSL 디코드 커널을 사용합니다.
긴 컨텍스트의 경우, 디코드 컨텍스트 병렬 처리(DCP)는 KV 캐시를 GPU 간에 분할합니다. 각 GPU는 로컬 부분에 대해 어텐션을 계산하고, 튜닝된 융합 커널이 부분 결과를 v-proj 및 게이팅과 결합합니다.
2. 계산과 통신 중첩
Kimi K3 경로는 어텐션 출력 프로젝션을 all-reduce 및 후속 어텐션-잔차 계산에 직접 융합합니다. GPU 커널은 부분 결과를 NVLink 접근 가능 버퍼에 게시하고, 수신 커널은 이를 결합하여 계산을 계속합니다. 일부 소형 배치 구성은 생산자와 소비자를 단일 커널로 융합합니다. 데이터 교환은 최소 오버헤드의 펜스 없는 접근 방식을 사용합니다.
더 큰 배치에서는 구현이 2단계 감소로 전환됩니다: GPU는 먼저 출력의 할당된 부분을 결합한 다음 결과를 분배합니다. 이는 GPU 간 데이터 이동을 줄입니다.
3. MoE 스케줄링 및 중첩 개선
전문가가 이미 텐서 병렬 처리를 사용하지만, 기준 구현은 모든 GPU에서 전체 라우터 점수와 잠재 입력 프로젝션을 계산합니다. Kimi K3 경로는 이러한 계산을 TP 랭크 간에 분할하고 각 랭크의 몫을 하나의 행렬 곱셈으로 결합합니다. GPU는 NVLink를 통해 결과를 교환합니다. 이는 전문가 실행이 시작되기 전에 반복 계산, 가중치 읽기, 커널 실행을 줄입니다.
공유 전문가는 별도의 스트림에서 실행됩니다. 그 작업은 구성에 따라 라우팅 또는 라우팅된 전문가 계산과 중첩됩니다. 스케줄은 각 연산이 사용하는 GPU 리소스 양을 제어하며, 경합 없이 병렬 처리를 균형 있게 유지하도록 튜닝됩니다. 구현 세부 사항은 experts_runtime.py에 있습니다.
4. 다음 가중치를 캐시에 프리페치
소형 배치 추론은 종종 메모리 바운드입니다: 메모리에서 가중치를 로드하는 속도에 의해 제한됩니다. 통신과 같은 일부 단계는 사용 가능한 메모리 대역폭을 완전히 활용하지 못할 수 있습니다. 통신이 실행되는 동안 사이드 스트림의 전용 커널이 다음 연산의 가중치를 프리페치하여, 통신이 완료될 때 해당 가중치의 캐시 적중률이 훨씬 높아집니다.
에이전트 최적화 추론 코드가 수동 검토를 능가하는 이유
에이전트 최적화 추론 코드는 vLLM의 검토 및 유지 관리 워크플로우를 능가하고 있습니다. 모든 커널의 모든 줄을 수동으로 이해하고, 잠재적 문제를 매핑하고, 지원되는 모든 구성을 테스트하는 것은 매우 시간이 많이 걸립니다. 이 작업을 건너뛰면 프로덕션에서 실패할 수 있는 버그가 있는 소프트웨어를 출시할 위험이 있습니다.
제안된 패스트트랙 RFC는 성능 작업을 구성하는 방식을 변경하여 이 문제를 해결합니다: 에이전트 최적화와 함께, vLLM은 안정성과 성능을 자동으로 검증하는 시스템과 설계상 격리 및 위험 최소화를 강제하는 구조화된 소프트웨어를 원합니다. 명시된 지침 원칙은 위험을 관리하면서 검토 부담을 줄이는 것입니다.
우리의 지침 원칙은 위험을 관리하면서 검토 부담을 줄이는 것입니다.
이 접근 방식은 네 가지 원칙에 기반합니다.
원칙 1: 변경 사항 격리
모델별 최적화는 모델의 코드 내에 유지됩니다. 이는 영향을 받는 경로를 식별하기 쉽게 만들고 검토자가 고려해야 할 폭발 반경을 줄입니다. 격리는 런타임에서도 유지되어야 합니다: 검토자는 최적화된 경로가 선택되는 시점, 변경하는 상태, 표준 경로로의 실행 복귀 방법을 추적할 수 있어야 합니다.
격리는 의도적으로 일부 최적화를 제외합니다. 입력 준비, 샘플링, KV 캐시 관리는 격리가 제외하는 오버헤드를 유발할 수 있습니다. 이는 대체로 의도적입니다: 이러한 구성 요소는 대부분의 vLLM 배포에서 공유되며, 특정 워크로드에 최적화하기 위해 변경하면 수십 개의 다른 안정적인 vLLM 구성이 손상될 위험이 있습니다. 이러한 구성 요소에 대한 작업은 패스트트랙이 허용하는 것보다 훨씬 더 핵심 유지 관리자와 긴밀하게 협력해야 합니다.
원칙 2: 범위를 제한하되 사용자 기능은 보존
최적화가 모든 배포를 개선할 필요는 없습니다. 특정 GPU, 병렬 처리 설정 또는 배치 크기 범위를 대상으로 할 수 있습니다. 명확한 경계는 작업을 튜닝하기 쉽게 만들고 검증할 구성 집합을 정의합니다.
Kimi K3의 경우, 초기 하드웨어 검증은 TP8 및 TP16을 사용한 GB300, 최대 64의 디코드 배치, 다양한 드래프트 길이를 사용한 추측 디코딩, 하나의 NVLink 도메인 내 디코드 컨텍스트 병렬 구성을 포함합니다.
이러한 경계는 최적화가 적용되는 위치를 설명하지만 기능 범위를 줄이지는 않습니다. 프로덕션 배포에는 엔드포인트를 유용하게 만드는 기본 기능이 필요합니다. 전체 컨텍스트 서빙, 온도 샘플링, 구조화된 출력과 같은 기능은 "최적화로 제거"되거나 "옵트아웃"될 수 없습니다. 이는 일급 서빙 기능이며 커널 형태 및 수치 검사와 함께 검증 계획에 속합니다.
원칙 3: 정확성 검증
커널 테스트와 모델 평가는 다른 질문에 답합니다. 커널 테스트는 형태와 입력 값에 걸쳐 수치 결과를 확인합니다. 모델 평가는 전체 실행 경로가 모델의 답변을 보존하는지 확인합니다. 둘 다 필요합니다.
테스트는 실제로 변경된 코드를 실행해야 합니다. 소형 배치 최적화는 소형 배치에서 평가가 필요합니다. 어텐션 커널 변경은 긴 컨텍스트 적용 범위가 필요합니다. 표준 경로를 조용히 사용하는 테스트는 최적화에 대한 증거를 거의 제공하지 않으며 일반적인 함정으로 설명됩니다.
Kimi K3 개발은 이것이 왜 중요한지 보여줍니다. 감사에서 컴파일러가 활성화 읽기를 동기화 대기보다 앞서 이동시킨 것을 발견했습니다. 수정은 해당 로드 유형을 정적 가중치로 제한했습니다. 이러한 오류는 간단한 기능 검사를 통과할 수 있으며 표적 조사가 필요합니다.
MRCR 및 AIME25와 같은 긴 컨텍스트 및 긴 생성 평가는 또한 독립형 커널 테스트에서 모의 입력 및/또는 일관된 실행 타이밍으로 재현할 수 없는 어텐션 및 통신 커널의 민감한 수치 문제를 표면화했습니다.
원칙 4: 성능을 광범위하게 확인
헤드라인 속도 향상은 시작점입니다. 검증은 변경 사항이 영향을 미치는 워크로드 전반에 걸쳐 어떻게 동작하는지 보여야 하며, 이는 배치 크기, 컨텍스트 길이, 지원되는 병렬 처리 구성을 훑는 것을 의미합니다. MoE 측정에는 실제 프롬프트가 포함되어야 합니다. 전문가 선택이 읽는 가중치와 재사용 가능한 작업량에 영향을 미치기 때문입니다. 순수 디코드 결과는 프리필과 디코드를 혼합한 워크로드와 구별되어야 합니다.
신뢰할 수 있는 검증에는 GPU 시간이 필요합니다. 관련 Bring-Your-Own-GPU 평가 RFC(vllm-project/vllm 이슈 #61698)는 기여자가 자신의 하드웨어에서 실행할 수 있는 표준 평가 이미지를 제안합니다. GitHub PR에 연결된 재현 가능한 결과 번들 및 제출물은 증거를 더 접근 가능하게 만들 것입니다. 다양한 평가 계층과 공유 커뮤니티 컴퓨팅은 GPU 수요를 관리하고 프로젝트 자금 지원 CI에 대한 압력을 줄이면서 적용 범위를 확장할 것입니다.
성능 결과
DSpark를 사용한 디코드 성능
DSpark를 사용하면 Kimi K3는 통제된 AL=6 벤치마크에서 16개의 NVIDIA GB300 GPU에서 초당 842 토큰에 도달합니다. 이는 동일한 추측 디코딩 설정에서 488 토큰/초를 측정한 기본 vLLM보다 1.73배 빠른 것입니다.
설정: TP16, 7개의 드래프트 토큰을 사용한 DSpark, 합성 수용 길이 6, DL=7, ISL=1, OSL=1k, 배치 크기 1. TPS는 총 디코드 처리량을 측정하며 프리필을 제외합니다.
추측 없이 디코드 성능
개선 사항은 테스트된 배치 범위에 걸쳐 있습니다. TP16은 배치 1664에서 **1.621.71배 이득**을 유지하고, TP8은 동일한 범위에서 1.31~1.43배를 제공합니다.
| 배치 크기 | TP8 토큰/초 | TP8 속도 향상 | TP16 토큰/초 | TP16 속도 향상 |
|---|---|---|---|---|
| 1 | 193.3 | 1.58배 | 256.4 | 1.88배 |
| 2 | 317.8 | 1.50배 | 436.7 | 1.92배 |
| 4 | 540.6 | 1.55배 | 702.5 | 1.81배 |
| 8 | 820.1 | 1.45배 | 1,157.9 | 1.79배 |
| 16 | 1,274.8 | 1.43배 | 1,758.3 | 1.71배 |
| 32 | 1,702.6 | 1.33배 | 2,550.9 | 1.64배 |
| 64 | 2,375.9 | 1.31배 | 3,606.1 | 1.62배 |
이 수치는 추측 디코딩 없이 측정된 것입니다. 처리량은 전체 TP 그룹에 대한 것입니다.
AgentX에서의 개선
최적화된 Kimi K3 구현은 AgentX에서 동시성 1에서 1.8배 더 높은 P90 상호작용성을 제공합니다: 403.2 대 223.7 토큰/초/사용자. 이는 16개의 GB300 GPU에서 최적화된 실행을 8개의 GB300 GPU에서의 이전 vLLM 결과와 비교한 것입니다.
AgentX는 긴 컨텍스트, 여러 대화 턴, 도구 일시 중지, 병렬 하위 에이전트, KV 캐시 재사용을 포함한 실제 코딩 에이전트 세션의 트래픽 패턴을 재생합니다. 개인 콘텐츠를 합성 텍스트로 대체하면서 이러한 워크로드 패턴을 보존하여 실제 에이전트 트래픽에서 서빙 시스템을 테스트합니다.
다음 단계
DeepSeek-V4.1-Flash
DeepSeek-V4.1-Flash(vllm-project/vllm PR #61868)는 Kimi K3 설계 패턴을 따릅니다. 동일한 옵트인 decode_backend: latency_specialized 스위치 뒤에서, 이 구현은 최대 64개의 동시 요청, 프리필 및 혼합 배치를 위한 원활한 폴백, 추측 디코딩을 지원합니다. 단일 핫스팟을 추적하는 대신, 이 실행기는 커널과 호스트 작업을 줄입니다: 모든 하위 레이어 경계에서 all-reduce + mHC를 융합하고, 대형 배치 MoE 및 GEMM을 저지연용으로 구축된 CuTe DSL 커널로 대체하고, 인덱서 작업을 중복 제거 및 샤딩하고, 기본 vLLM이 CPU에서 즉시 실행하는 단계별 작업을 CUDA 그래프로 재생합니다. DeepSeek AgentX 결과는 4개의 GB300 GPU에서 보고됩니다.
Muse Spark Open
Meta의 Muse Spark Open 출시 후 이틀 만에 vLLM의 초기 결과는 이미 7개의 드래프트 토큰(K=7)과 수용 길이 6(AL=6)으로 사용자당 초당 950 토큰을 초과했습니다. 더 많은 최적화가 진행 중입니다.
GLM5.3
vLLM은 또한 저동시성 시나리오에서 GLM5.3의 디코드 지연 시간을 최적화하는 유사한 메커니즘을 출시합니다. 최적화 세부 사항과 성능 결과는 별도의 게시물에서 제공될 예정입니다.
각 기여에 대해 vLLM은 구체적인 성능 이득, 프로덕션 기능 지원, 재현 가능한 정확성 및 성능 검사에 계속 초점을 맞출 것이라고 밝혔습니다.
감사의 말
vLLM은 이 작업에 기여한 Rohan Varma(NVIDIA)와 Alex Steiner(NVIDIA), 그리고 모델 리팩터링과 피드백 및 지원을 제공한 Woosuk Kwon(Inferact), Michael Goin, Lucas Wilkinson(Red Hat)에게 감사를 표했습니다.