vLLMのDecode Context Parallelで、Kimi-K3のKVキャッシュ容量がGPU1台あたり10倍に

3行まとめ

• Kimi-K3向けDCP（Decode Context Parallel）実装PRの実測では、TP8からDCP8への切り替えでGPU1台あたりのKVキャッシュ容量が1.933Mトークンから19.752Mトークンへ約10.2倍に増え、TPOTも同時実行数1で約24%短縮した。
• Kimi-K3自体は2.8兆パラメータ・896エキスパート中16個が活性化するMoEモデルで、1Mトークンのコンテキスト窓とネイティブ視覚入力を持つ（vLLM公式ブログ実測）。推奨構成はNVIDIA B300またはAMD MI355X×8基。
• vLLMは2026年7月27日時点のブログ記事で、DCPのプロトタイプが「選択的なワークロードでTP8比40%高いスループット」と予告していた。8月10日にマージされたPR本文が実際に示したのはTPOTとKVキャッシュ容量の数字で、スループット自体の40%という数字と直接比較できる形では書かれていない。

Kimi-K3のようなMoEモデルを長いコンテキストで動かす際、ボトルネックになりやすいのがKVキャッシュ（会話の履歴を保持するメモリ）だ。推論サーバーvLLMのv0.28.0（2026年8月26日公開）のリリースノートには「Kimi-K3 performance push」という項目があり、その中にこう書かれている。

Kimi-K3 performance push: a major optimization effort for Kimi-K3 across the stack — Decode Context Parallel (DCP) support (#50484) ...

（Kimi-K3のパフォーマンス強化：スタック全体にわたるKimi-K3向けの大規模な最適化——Decode Context Parallel（DCP）対応を含む）

このDCPを実装したマージ済みPR #50484の本文を読むと、リリースノートの1行以上に具体的な数字が並んでいた。

KVキャッシュ容量が約10倍に

PR本文の「Performance」欄には、120k規模の回帰ワークロード（共有プレフィックス114k・接尾辞6k・出力400トークン、Mooncake無効）でのHBM（GPUメモリ）使用量の比較表がある。

HBM KV capacity per GPU:

• TP8: 1.933M tokens / 25.12 GiB
• DCP8: 19.752M tokens / 34.28 GiB

（GPU1台あたりのHBM KV容量：TP8は1.933Mトークン／25.12GiB、DCP8は19.752Mトークン／34.28GiB）

Tensor Parallel（TP、モデル自体を8分割）からDecode Context Parallel（DCP、コンテキストを8分割）に切り替えると、使用メモリは25.12GiBから34.28GiBへと増えるものの、そこに収まるトークン数は1.933Mから19.752Mへと約10.2倍に伸びる、という計算になる。同じメモリの使い方でも、コンテキスト側を分割する設計のほうがトークンあたりの効率が大きく上回るということだ。

レイテンシも短縮

同じワークロードでのTPOT（トークンあたりの出力時間）はこうなっている。

同時実行数1（c1）ではp50で約24%、同時実行数2（c2）でも約27%、DCP8のほうがTPOTが短い。さらにPR本文は「4台のGB200上、Kimi-K3の構成に合わせたところ、直接最終先クエリパスによってクエリ交換のレイテンシが10.4%〜29.9%改善した」とも書いている。

精度は「誤差レベルで改善」

GSM8Kでの精度比較（.buildkite/kimi-k3/rack5/gsm8k.yaml）も掲載されていた。

DCP8のほうがわずかに高いが、この差はサンプル数1,319件に対して10件の正解差であり、DCP自体が推論精度を有意に改善する設計だとは書かれていない。PR本文もこの数字を「Accuracy」という中立的な見出しでしか示しておらず、優位性の主張はしていない。

何を実装したか

PR本文の「Summary」によれば、このPRは以前のPR #50000のフォローアップで、直接的な対称メモリ方式のDCP A2A出力／LSE削減（空のKVシャードのマスキングを含む）、Kimi-K3の融合MLA層向けDCP対応、NVLSマルチキャストによる直接クエリ収集とマルチメムのチャンク化コンテキストKV収集、クエリシャードを消費側の最終バッファへ直接発行する仕組みを追加したとされている。この設計面の詳細（対称メモリやLSE削減の内部実装）は専門的すぎるため本記事では数字の紹介にとどめ、深追いはしていない。PR本文の末尾には「AI assistance was used to diagnose, implement, and validate this follow-up fix」（この追随修正の診断・実装・検証にAIの支援を使った）という一文もあった。

Kimi-K3自体の規模──2.8兆パラメータ、16-of-896エキスパート

DCPが対象とするKimi-K3がどんなモデルかは、PR #50000本文とvLLM公式ブログ（2026年7月27日付「Kimi K3 Is Here」）から確認できる。ブログはKimi-K3を「Kimi Delta Attention（KDA）とAttention Residuals（AttnRes）の上に構築された2.8兆パラメータのMixture-of-Expertsモデルで、トークンごとに896個中16個のエキスパートが活性化し、1Mトークンのコンテキスト窓とネイティブな視覚入力を持つ」と説明している。

出典: vllm.ai/blog/2026-07-27-k3

「予告40%」と「実測10倍」は別の指標

このブログ記事は末尾のロードマップで、DCPについて「プロトタイプは良好な高速化を示しており、まもなくupstream（本体への統合）する。初期実験では選択的なワークロードにおいてTP8比40%高いスループットを示している」と予告していた。この予告から2週間ほど後の8月10日にマージされたPR #50484の本文は、しかしスループットという単一の指標ではなく、KVキャッシュ容量（約10.2倍）とTPOT（約24〜27%短縮）という別の切り口の数字を報告している。どちらも「DCP8のほうが優れている」という方向は一致しているが、予告段階の「40%」という数字とPRの実測数字を、同じ土俵で直接比較できる記載は本文になかった。

MoEモデルの実運用に近い数字が公開PRから読める例

vLLMのようなOSSの推論サーバーでは、Kimi-K3のような大規模MoEモデルの最適化PRがマージされるたびに、こうした実測ベンチマークが本文にそのまま残る。企業のベンチマーク発表とは違い、TP8とDCP8のどちらが有利かという判断材料が、公開PRの本文だけから追える点は、この記事を書きながら確認できた収穫だった。

Mooncake有効時や他モデルでの数字は書かれていなかった

本記事はPR #50484・PR #50000の本文とvLLM公式ブログに記載された数字を情報源としている。PR #50484の測定は「Mooncake disabled」という条件付きで行われており、Mooncake（KVキャッシュの分散管理レイヤー）を有効にした場合の数字は本文に記載がなかった。また、Kimi-K3以外のMoEモデルでも同様の10倍規模の容量改善が出るかどうかは、このPR本文の範囲では判断できない。ブログが予告していた「40%高いスループット」の測定条件（どのワークロードを「選択的」と呼んでいるか、GPU構成やモデルサイズ）もブログ本文には具体的な記載がなく、PR側の数字とどう対応するのかは追えなかった。自分の手元でDCPを実際に有効化して動かす検証は行っていない。

関連記事: Kimi K3の重みが公開された / コンテキストウィンドウとRAM使用量の計算式 / ローカルLLM入門ガイド

感想・指摘はコメント欄へ。