vLLMにおけるKimi K3のパフォーマンス最適化
vLLMは、Kimi K3に対して包括的な一連のパフォーマンス最適化を実装し、最大2.8倍のスループット向上と、Time to First Token (TTFT) の最大85%削減を達成しました。これらの改善は、KDA recurrent state、LatentMoE、MXFP4 expert kernels、およびspeculative decodingを含む、サービングスタック全体にわたるボトルネックに対処することで実現されました。
サービングパフォーマンスの向上
B300ノード (CUDA 13.3) を使用し、TP8および8トークンのDSpark speculationを用いた8K/1Kワークロードで測定された最適化の結果、vLLM v0.27.1と9月13日のmainコミット (82a85dc1) を比較すると、大幅な向上が見られます。
| Concurrency | v0.27.1 Avg Latency (s) | 0913 main Avg Latency (s) | v0.27.1 Throughput (tok/s) | 0913 main Throughput (tok/s) | v0.27.1 Avg TTFT (ms) | 0913 main Avg TTFT (ms) |
|---|---|---|---|---|---|---|
| 1 | 12.37 | 5.30 (−57.2%) | 83.3 | 183.3 (+120.0%) | 2262.9 | 376.3 (−83.4%) |
| 4 | 23.67 | 10.50 (−55.6%) | 166.7 | 416.7 (+150.0%) | 2314.9 | 640.5 (−72.3%) |
| 16 | 55.90 | 22.17 (−60.3%) | 258.3 | 725.0 (+180.6%) | 7601.1 | 1121.0 (−85.3%) |
主要な技術的最適化
Adaptive Scheduling Budget
リクエスト数が少ない場合に max_num_batched_tokens が使用されないまま残るのを防ぐため、vLLMはadaptive scheduled-token budgetを導入しました。この戦略により、リクエスト数が少ない場合に単一のリクエストが複数のforward callsに分割されるのを防ぎ、8K/1KワークロードにおいてTTFTを55%–65%削減し、スループットを最大41.5%向上させます。
Internal KDA Prefix Checkpoints
以前は、Mambaスタイルのprefix cache splitは、短いサフィックスに対して2回目のフルモデルパスが必要でした。vLLMは現在、単一のprefill pass内でチェックポイントのエクスポートをサポートしています。8Kの入力に対して、これにより1回のFlashKDA callで全8,000トークンを処理し、同じ再帰（recurrence）内でトークン7,680でチェックポイント状態をエクスポートすることが可能になり、attention、MoE、routing、およびTP collectivesを介した2回目のパスを回避できます。これにより、TTFTが9%–25%削減されました。
Zero-Copy Mixed KDA Batches
Speculativeおよびnon-speculativeトークンを含む混合バッチは、以前はレイヤーごとに複数の index_select および index_copy_ 操作が必要でした。vLLMは、連続的なzero-copy slicesと直接的な出力書き込みを実装することで、concurrency 4および16においてスループットを5.2%–7.7%向上させました。
Deferred MXFP4 Finalization
MXFP4 top-k finalizationをlatent-tail kernelに融合（fusing）させることで、vLLMはカーネル起動を1回削減し、中間テンソルの書き込みと再読み込みの必要性を回避することで、エンドツーエンドのレイテンシを約5%削減しました。
高度なメモリおよび状態管理
ReplaySSM for State Reconstruction
Speculative decodingは、通常、ロールバックを可能にするために、各draft positionでKDA recurrent stateを書き込む必要があります。ReplaySSMは、最近のSSM入力をバッファリングし、コミットポイントでのみ承認された状態を再構成することで、これを最適化します。Model Runner V2上のKimi K3において、これはTP8環境下で精度に影響を与えることなく、実効的なキャッシュ容量を10.97%増加させました。
Prefill/Decode Disaggregation and Hybrid State Offload
vLLM vLLMは現在、Kimi K3に対してPD disaggregationとキャッシュオフロードをサポートしており、これにはMLA KVおよびKDA stateの転送が必要です。KDA stateはheadとdimensionによってシャード化されています。また、Mamba align block tablesは疎（sparse）で可変（mutable）であるため、vLLMはMooncakeを利用して、スケジューラによって選択された境界状態を保存し、各rankにおける非同期書き込みが完了するまでそれらをピン留めします。
Decode Context Parallelism (DCP)
Tensor Parallelism (TP)はMLA latent KVを各rankに複製するため、KV-cache容量を増加させません。Decode Context Parallelism (DCP)は、KV-cacheをシーケンス次元に沿ってシャード化します。Kimi K3のfused MLA pathにおいて、DCPは、出力/LSE reductionのためにSymmetric-memory A2Aを使用し、query gatheringのためにNVLS multicastを使用します。
120k-tokenワークロード（114k shared prefix, 6k suffix, 6k suffix, 400 output tokens）において、KV-cache容量は1.93Mから19.75Mトークンに増加し、TPOT p50はconcurrency 1において13.8 msから10.5 msに低下しました。
幅広い実装の取り組み
パフォーマンスの改善は、メモリレイアウト、シーケンスおよびパイプライン並列化、KDA prefill、およびスモールバッチGPUパスの強化を含む、より広範な取り組みの結果です。これには、GitHub issue #50587で追跡されているように、DeepEPv2とDeepGEMM MXFP4およびシーケンス並列GEMMパスの統合が含まれます。