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

# vLLMのKimi K3デコード経路、特定のGB300テストで毎秒842トークンに到達

> vLLMは、特定のDSpark構成で16基のGB300 GPUを使ったKimi K3の総デコード処理量が毎秒842トークン、標準版では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リクエスト、16基のGB300 GPUによるテンソル並列、7個のドラフトトークンを使うDSpark投機的デコード、合成受理長6、入力1トークン、出力1000トークンという構成である。この値はプリフィル後の総デコード処理量を測るもので、ユーザーのリクエスト全体が完了する速さを測ったものではない。

この経路を評価すべきか判断するエンジニアにとって有用な進展は、大きなデコード性能の結果と、適用範囲の比較的明確な説明がそろったことだ。[マージされた実装](https://github.com/vllm-project/vllm/pull/61867)は`decode_backend: latency_specialized`で明示的に有効化する。既定の`auto`設定は従来のデコードを引き続き使用する。vLLMによると、この専用経路は単一のNVLinkドメインに8基または16基のGPUを持つ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のドラフト生成器を変更しない。そのため、推論提供チームは周辺の使い慣れたスタックを維持しながらデコード実装の変更を比較できる。ただし、推論提供のあらゆる部分が高速化されるわけではない。

## 2つのベンチマーク表は別々に読む

842対488という結果では、**16基のGB300 GPUで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トークンだったと報告した。最適化した結果は**16基のGB300 GPU**で実行されたが、以前の比較は**8基**だった。実装と同時にGPU数も変わるため、この1.8×比較からデコード経路の改善だけを切り分けることはできない。AgentXには長いコンテキスト、対話ターン、休止、キャッシュ再利用も含まれるため、その指標は純粋なデコードベンチマークとは異なる問いに答える。

公開投稿と、以前の[プルリクエストの性能表](https://github.com/vllm-project/vllm/pull/61867)には小さな食い違いがある。後者はTP16、バッチ1、DSpark DL7、合成受理6で毎秒838対489トークンと記している。本稿の1.73×という値の出典は、投稿の842対488という比較だ。以前の表も類似した実行の有用な証拠だが、2組の数字を混ぜてはいけない。vLLMはコードと独自の検証を公開している。BIG CHANGEは、どちらの実行も再現していない。

## 評価に必要なもの

意味のあるローカル比較は、[マージされたPRと明記された構成](https://github.com/vllm-project/vllm/pull/61867)から始めることになる。同じKimi K3モデル提供元の重み、単一のNVLinkドメインに16基のGPUを持つGB300システム、TP16、キャッシュ形式、主要テストと同一のDSpark構成が必要だ。標準の`auto`と、明示的に選ぶ`latency_specialized`を同じワークロードで実行し、デコード処理量をプリフィル、最初のトークンまでの時間、出力処理量、リクエスト単位の遅延と分けて記録する。ワークステーションや小規模なGPUプールでは、16基のGB300による主要結果を直接再現できない。投稿はこの構成のレンタル費用を示していない。

この[PRの検証説明](https://github.com/vllm-project/vllm/pull/61867)は、数値検査と、AIME25、GPQA-Diamond、長いコンテキストのMRCRテストを含むモデル評価を報告している。開発中に見つかった同期エラーや長い出力のテストのばらつきも説明する。これらの検査は速度グラフ以上の検討材料を与えるが、実装者自身による証拠であることに変わりはない。推論提供チームが判断すべきなのは、実際のハードウェア、バッチ処理、コンテキスト長、投機的受理の挙動が、独自トラフィックでこの任意の経路を測定する価値があるほど対応構成に近いかどうかだ。

## 大きな変化

vLLMにマージされたKimi K3経路により、文書化されたベンチマークと検証記録を備えた、専用の任意選択型GPUデコード実装が利用できる。公開された最も目立つ主要結果は、**16基のGB300 GPUで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「vLLMのKimi K3を徹底最適化：速く、責任を持って進める」（2026-10-16）](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — 当事者による技術説明で、842/488、1.73×という結果の出典。16基のGB300 GPUで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数も変わっている。