Markdown 버전

AI-translated from English; not yet reviewed by a fluent editor.

# vLLM의 Kimi K3 디코드 경로, 특정 GB300 테스트에서 초당 842토큰 기록

> vLLM은 특정 DSpark 구성에서 GB300 GPU 16개로 실행한 Kimi K3의 전체 디코드 처리량이 초당 842토큰으로, 기본 vLLM의 488토큰보다 높았다고 보고했다. 프리필은 제외된다.

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

vLLM이 NVIDIA Blackwell GPU에서 Kimi K3에 사용할 수 있는 선택형 모델 전용 디코드 경로를 병합했다. 프로젝트는 [10월 16일 설명](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel)에서 기본 vLLM의 초당 488토큰에 비해 842토큰을 생성해 1.73× 향상됐다고 보고했다. 이 비교의 조건은 제한적이다. 한 번에 요청 1개, GB300 GPU 16개에 걸친 텐서 병렬화, 초안 토큰 7개를 사용하는 DSpark 추측 디코딩, 합성 수락 길이 6, 입력 1토큰, 출력 1000토큰이다. 이 수치는 프리필 이후의 전체 디코드 처리량을 측정한다. 사용자 요청 전체가 얼마나 빨리 완료되는지를 측정한 것은 아니다.

이 경로를 평가할지 결정하는 엔지니어에게 유용한 진전은 상당한 디코드 성능 결과와 적용 범위에 대한 비교적 명확한 설명이 함께 제공됐다는 점이다. [병합된 구현](https://github.com/vllm-project/vllm/pull/61867)은 `decode_backend: latency_specialized` 설정을 통해 선택적으로 활성화한다. 기본 `auto` 설정은 기존 디코딩을 계속 사용한다. vLLM에 따르면 이 특화 경로는 하나의 NVLink 도메인에 GPU 8개 또는 16개가 있는 GB300 배포를 대상으로 하며, 프리필, 혼합 배치 및 지원하지 않는 단계는 표준 모델 순전파 경로로 돌아간다.

## 시간은 어디에 쓰였나

Kimi K3는 [모델 카드](https://huggingface.co/moonshotai/Kimi-K3)에 따르면 대규모 전문가 혼합 모델이다. 디코딩 중 서빙 시스템은 다음 토큰을 생성하기 위해 어텐션을 실행하고, 전문가를 선택하고, GPU 간 데이터를 교환하는 작업을 반복한다. vLLM 팀은 예상하는 텐서 형태에 맞춰 이런 연산을 특화한 CuTe DSL 경로를 만들었다. 설명에는 작은 배치와 큰 배치에 서로 다른 어텐션 투영 커널을 사용하는 방식, 어텐션 출력 투영·GPU 간 리덕션·뒤따르는 잔차 연산을 융합하는 방식, 분할된 라우터 계산, 공유 전문가와 라우팅된 전문가의 연산 중첩, 통신 중 가중치 미리 가져오기가 포함된다. 게시물의 레이어별 추적에서는 특화 경로가 커널 13개와 69마이크로초를 사용하는 데 비해 기본 vLLM은 커널 23개와 130마이크로초를 사용한다. 이는 제시된 구성에서 보고된 추적 결과이며 애플리케이션 지연 시간 수치가 아니다.

커널 설계만큼 적용 범위도 중요하다. [풀 리퀘스트](https://github.com/vllm-project/vllm/pull/61867)는 TP8 및 TP16에서의 GB300 검증, 배치 64까지의 비추측 디코드, 초안 토큰 3\~7개를 사용하는 DSpark 검증 및 선택형 디코드 컨텍스트 병렬화를 설명한다. 성능 최적화 작업에는 FP8 KV 캐시, FP32 SSM 캐시 및 모델 제공자의 가중치를 사용했다고 명시한다. 이 경로는 모델 가중치, 스케줄링, 샘플링 및 DSpark 초안 생성기를 바꾸지 않는다. 따라서 서빙 팀은 익숙한 주변 스택을 유지한 채 변경된 디코드 구현을 비교할 수 있지만, 이 최적화가 서빙의 모든 부분을 가속하는 것은 아니라는 뜻이기도 하다.

## 두 벤치마크 표는 별도로 읽어야 한다

842 대 488 결과는 **GB300 GPU 16개에서 TP16, 배치 1, 초안 토큰 7개의 DSpark, 합성 수락 길이 6, DL=7, ISL=1 및 OSL=1k**를 사용한다. vLLM은 이 지표를 초당 전체 디코드 토큰 수라고 부르며 프리필을 제외한다. 합성 수락은 벤치마크가 제안된 토큰 중 몇 개를 수락할지 고정하는 것으로, 사용자 프롬프트에서 측정한 수락률이 아니다. 프롬프트, 수락 동작, 배치 크기 또는 입력 길이가 다른 배포에는 자체 측정이 필요하다.

게시물에는 [비추측 디코딩 표](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation)도 있다. 예를 들어 TP16에서는 배치 1에서 초당 256.4토큰, 배치 64에서 3606.1토큰을 보고하며, 각각의 기본 구성보다 1.88× 및 1.62× 향상됐다고 한다. 이는 추측 디코딩을 사용하지 않은 TP 그룹 전체의 결과다. 이를 DSpark 수치와 합쳐 배치 64에서 개별 사용자 경험이 더 빨라진다고 주장할 수는 없다.

게시물의 또 다른 수치는 [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx)에 관한 것이다. 이 워크로드는 합성 콘텐츠로 코딩 에이전트의 트래픽 패턴을 재생한다. vLLM은 동시성 1에서 사용자당 초당 토큰 수로 측정한 P90 상호작용 성능이 403.2 대 223.7이라고 보고했다. 최적화된 결과는 **GB300 GPU 16개**에서 실행됐지만, 이전 비교 결과는 **8개**에서 실행됐다. 구현과 함께 GPU 수도 바뀌므로 이 1.8× 비교는 디코드 경로 개선만을 분리해 보여주지 않는다. AgentX에는 더 긴 컨텍스트, 대화 턴, 일시 정지 및 캐시 재사용도 포함되므로, 해당 지표는 순수 디코드 벤치마크와 다른 질문에 답한다.

공개 게시물과 앞서 나온 [풀 리퀘스트 성능 표](https://github.com/vllm-project/vllm/pull/61867) 사이에는 작은 차이가 있다. 후자는 TP16, 배치 1, DSpark DL7 및 합성 수락 6에서 초당 838 대 489토큰을 제시한다. 여기서 사용하는 1.73× 수치는 게시물의 842 대 488 비교에서 나온 것이다. 앞선 표는 유사한 실행의 유용한 근거지만, 두 쌍의 수치를 서로 섞어서는 안 된다. vLLM은 코드와 자체 검증을 공개했으며 BIG CHANGE는 어느 실행도 재현하지 않았다.

## 평가에 필요한 것

의미 있는 로컬 비교는 [병합된 PR과 명시된 구성](https://github.com/vllm-project/vllm/pull/61867)에서 출발해야 한다. 같은 Kimi K3 모델 제공자 가중치, 하나의 NVLink 도메인에 GPU 16개가 있는 GB300 시스템, TP16, 캐시 형식 및 주요 테스트와 정확히 같은 DSpark 구성이다. 기본 `auto`와 선택형 `latency_specialized`를 같은 워크로드로 실행한 다음, 디코드 처리량을 프리필, 첫 토큰까지의 시간, 출력 처리량 및 요청 단위 지연 시간과 분리해 기록해야 한다. 워크스테이션이나 더 작은 GPU 풀로는 GB300 16개를 사용하는 주요 결과를 직접 재현할 수 없다. 게시물은 이 구성의 임대 비용을 제시하지 않는다.

해당 [PR의 검증 설명](https://github.com/vllm-project/vllm/pull/61867)은 수치 검사와 AIME25, GPQA-Diamond 및 긴 컨텍스트 MRCR 테스트를 포함한 모델 평가를 보고한다. 개발 중 발견한 동기화 오류와 긴 출력 테스트의 변동도 설명한다. 이런 검사는 속도 차트보다 더 많은 검토 자료를 제공하지만, 여전히 구현자가 제시한 근거다. 서빙 팀이 판단해야 할 것은 실제 하드웨어, 배치 처리, 컨텍스트 길이 및 추측 토큰 수락 동작이 지원 구성과 충분히 유사해, 자체 트래픽으로 이 선택형 경로를 측정할 가치가 있는지다.

## 핵심 변화

vLLM에 병합된 Kimi K3 경로는 문서화된 벤치마크와 검증 기록을 갖춘 특화된 선택형 GPU 디코드 구현을 제공한다. 공개된 가장 강력한 주요 결과는 **GB300 GPU 16개에서 TP16, 배치 1, DSpark 초안 토큰 7개 및 합성 수락 길이 6을 사용해 전체 디코드 처리량이 초당 842 대 488토큰, 즉 1.73×였다는 것**이다. 프리필은 제외된다. 특정 서비스가 개선되는지는 그 서비스의 하드웨어와 요청 전체의 워크로드에 달려 있다.

## 출처 및 추가 읽을거리

- [vLLM의 10월 16일 기술 게시물](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel)은 디코드 변경을 설명하고 842/488 구성, 비추측 디코딩 표 및 AgentX 비교를 제공한다. 이 결과는 프로젝트와 NVIDIA 기여자 Benjamin Chislett가 보고한 것이다.
- [병합된 vLLM 풀 리퀘스트 #61867](https://github.com/vllm-project/vllm/pull/61867)은 선택형 설정, 지원 구성, 구현 범위, 검증 및 앞선 838/489 DSpark 표를 문서화한다. 이는 코드와 결과의 기록이며 독립적인 재현이 아니다.
- [Moonshot AI의 Kimi K3 모델 카드](https://huggingface.co/moonshotai/Kimi-K3)는 구현에서 참조한 모델과 가중치를 명시한다.
- [AgentX 방법론](https://inferencex.semianalysis.com/agentx)은 별도로 제시된 상호작용 성능 비교의 기반인 트래픽 재생 워크로드를 설명한다.

## Sources

- [vLLM, Hyper Optimizing Kimi K3 in vLLM: Moving Fast and Responsibly (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — 당사자 기술 설명이자 842/488, 1.73× 결과의 출처다. GB300 GPU 16개에서 TP16, 배치 1, DSpark DL7, 합성 AL6, ISL1, OSL1k 및 프리필을 제외한 전체 디코드 TPS를 명시한다. 별도의 비추측 디코딩 결과와 AgentX 결과도 제공한다.
- [vLLM 풀 리퀘스트 #61867, Kimi K3 특화 디코드](https://github.com/vllm-project/vllm/pull/61867) — 병합된 구현과 작성자가 실행한 검증 기록이다. 최종 선택형 설정, 지원 구성 및 폴백을 문서화한다. 앞선 DSpark 표는 TP16 B1 합성 AL6에서 838/489라고 하므로, 이 수치는 블로그의 수치 쌍과 결합하지 않는다.
- [Moonshot AI, Kimi K3 모델 카드](https://huggingface.co/moonshotai/Kimi-K3) — 모델과 모델 제공자의 가중치를 명시하며, vLLM 성능을 독립적으로 입증하지는 않는다.
- [InferenceX, AgentX 방법론 및 데이터셋](https://inferencex.semianalysis.com/agentx) — 별도로 보고된 상호작용 성능 비교에 사용한 트래픽 재생 워크로드를 설명한다. vLLM의 비교에서는 GPU 수도 바뀐다.