vLLMは、NVIDIA Blackwell GPU上のKimi K3向けに、任意で有効にできるモデル専用デコード経路をマージした。プロジェクトの10月16日の説明では、標準vLLMの毎秒488トークンに対し842トークンを生成し、1.73×向上したと報告している。ただし比較の条件は限定的だ。一度に1リクエスト、16基のGB300 GPUによるテンソル並列、7個のドラフトトークンを使うDSpark投機的デコード、合成受理長6、入力1トークン、出力1000トークンという構成である。この値はプリフィル後の総デコード処理量を測るもので、ユーザーのリクエスト全体が完了する速さを測ったものではない。

この経路を評価すべきか判断するエンジニアにとって有用な進展は、大きなデコード性能の結果と、適用範囲の比較的明確な説明がそろったことだ。マージされた実装はdecode_backend: latency_specializedで明示的に有効化する。既定のauto設定は従来のデコードを引き続き使用する。vLLMによると、この専用経路は単一のNVLinkドメインに8基または16基のGPUを持つGB300環境を対象とし、プリフィル、混在バッチ、非対応のステップは標準のモデル順伝播経路へフォールバックする。

時間はどこに使われていたのか

Kimi K3は、モデルカードによると大規模な混合エキスパートモデルだ。デコード中、推論提供システムはアテンションの実行、エキスパートの選択、GPU間のデータ交換を繰り返し、次のトークンを生成する。vLLMチームは、想定するテンソル形状に合わせてこれらの演算を特化させるCuTe DSL経路を構築した。説明には、小規模バッチと大規模バッチで異なるアテンション射影カーネル、アテンション出力射影・GPU間リダクション・後続の残差処理の融合、分割されたルーター計算、共有エキスパートとルーティング先エキスパートの処理の重なり、通信中の重みのプリフェッチが含まれる。投稿に示された層ごとのトレースでは、専用経路が13カーネル、69マイクロ秒を使うのに対し、標準vLLMは23カーネル、130マイクロ秒を使う。これは例示された構成についての報告であり、アプリケーションの遅延の値ではない。

カーネル設計と同じくらい適用範囲も重要だ。プルリクエストには、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はこの指標を毎秒の総デコードトークン数と呼び、プリフィルを除外する。合成受理は、提案されたトークンのうちベンチマークが何個を受理するかを固定するもので、ユーザーのプロンプトから測定した受理率ではない。プロンプト、受理の挙動、バッチサイズ、入力長が異なる環境では、独自の測定が必要になる。

投稿には非投機的デコードの表もある。例えばTP16では、バッチ1で毎秒256.4トークン、バッチ64で3606.1トークンと報告し、それぞれの標準構成に比べ1.88×、1.62×の向上としている。これらは投機的デコードを使わないTPグループ全体の結果だ。DSparkの数字と組み合わせて、バッチ64でユーザー当たりの体験が高速化すると主張することはできない。

投稿中の別の数字は、AgentXに関するものだ。これは合成コンテンツでコーディングエージェントのトラフィックパターンを再生するワークロードである。vLLMは、同時実行数1でP90の対話性能がユーザー当たり毎秒403.2対223.7トークンだったと報告した。最適化した結果は16基のGB300 GPUで実行されたが、以前の比較は8基だった。実装と同時にGPU数も変わるため、この1.8×比較からデコード経路の改善だけを切り分けることはできない。AgentXには長いコンテキスト、対話ターン、休止、キャッシュ再利用も含まれるため、その指標は純粋なデコードベンチマークとは異なる問いに答える。

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

評価に必要なもの

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

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

大きな変化

vLLMにマージされたKimi K3経路により、文書化されたベンチマークと検証記録を備えた、専用の任意選択型GPUデコード実装が利用できる。公開された最も目立つ主要結果は、16基のGB300 GPUでTP16、バッチ1、DSparkのドラフトトークン7個、合成受理長6を使い、総デコード速度が毎秒842対488トークン、つまり1.73×だったことだ。プリフィルは除外される。特定のサービスに効果があるかは、そのハードウェアとリクエスト全体のワークロードに依存する。

出典・参考資料

  • vLLMの10月16日の技術投稿は、デコードの変更を説明し、842/488の構成、非投機的デコード表、AgentX比較を示す。結果を報告しているのはプロジェクトとNVIDIA貢献者のBenjamin Chislettだ。
  • マージされたvLLMプルリクエスト#61867は、任意の設定、対応構成、実装の境界、検証、以前の838/489 DSpark表を文書化している。これはコードと結果の記録であり、独立した再現ではない。
  • Moonshot AIのKimi K3モデルカードは、実装が参照したモデルと重みを特定する。
  • AgentXの方法論は、別途示された対話性能比較の基礎となるトラフィック再生ワークロードを説明する。