DeepInferの本番ギャップ: KV cache、PD、ロードバランシング

DeepInferはDeepSeekのV4.1-Flash推論エンジンであり、完全なサービングスタックではない。READMEの「含まれないもの」リストは短い。KV cacheシステム、VE/Prefill/Decodeの分離、データ並列レプリカ間のロードバランシング。どれも機能フラグではなくサブシステムだ。3つを合わせたものが、モデルを動かすこととサービスを動かすことの差になる。

エンジンとサービス

エンジンは、トークン化されたリクエストのバッチを受け取り、生成トークンを返す。サービスは、多数のユーザーからHTTPリクエストを受け取り、認証し、ルーティングし、コンテキストを生かしたままにし、クォータを適用し、障害に対処し、課金する。エンジンは高価な計算であり、サービスは高価な運用だ。

DeepInferはエンジンだ。DeepSeekのQ&Aはその周囲のサービスを異例なほど詳しく説明しており、ギャップが見えやすくなっている。以下では最大の3つを順に見る。

KV cache: 長いコンテキストを現実的なコストにする記憶

モデルがプロンプトを読むとき、トークンとレイヤーごとにキーと値を保存する。このキャッシュがあるからこそ、decodeはプロンプト全体を読み直さずに次のトークンを生成できる。リクエスト間でprefixを再利用することは、サービングにおける最大のコストレバーの一つだ。長いシステムプロンプト、共有ドキュメント、マルチターンのエージェント履歴は、一度計算して何度も使い回せる。

素朴な版——GPUメモリに辞書を置く——は規模とともに破綻する。GPUメモリは需要に比べて小さく、キャッシュエントリは別のマシンから必要になることがあり、計算ノードはストレージノードより頻繁に落ちる。DeepSeekの本番設計は3つの層に分ける。

本番の数字は、問題の捉え方が変わるほど大きい。

• KV cache用のSSDが約100 PiB。
• GPUあたり約14.4 TBの論理KV。物理容量はさらに大きい。
• 8 GPUあたり約400 Gbpsのインターコネクト。
• 3FSは10+2のイレージャーコーディングで、各ECグループは2ノードの同時障害に耐える。
• ピークの集計読み出しは約10 TiB/s、書き込みは約850 GiB/s。

なぜローカルメモリや階層キャッシュではなく、専用のストレージクラスタなのか。Q&Aから3つの理由が挙げられている。

1. どのprefillマシンからも任意のprefixにヒットできる。 キャッシュがローカルなら、ルーティングにprefixアフィニティが必要になり、ロードバランシングと衝突する。
2. ストレージと計算を独立にスケールできる。 GPUを増やさずにキャッシュ容量を増やせ、その逆もできる。
3. 計算の障害でキャッシュが失われない。 DeepSeekによれば、計算ノードはストレージノードより1桁多く落ちる。

キャッシュヒットはマッチ、フェッチ、スワップインの3段階を経る。クリティカルパス上にあるのはマッチだけだ。3FSからホスト共有メモリへのフェッチは別プロセスで非同期に行われ、共有メモリからHBMへのスワップインはforward計算とレイヤー単位で重ねられる。DeepSeekはスワップインにGDR/RDMAを使う。CUDAのコピーエンジンは細かいKVブロックのコピーに向かないからだ。

これを自分で作るなら、prefixマッチング、メタデータサービス、分散ストア、退避/TTL、マシン間転送、障害耐性、そしてロードバランシングと協調するルーティング方針が必要になる。週末のプロジェクトではなく、ストレージチーム1つ分の仕事だ。

prefill/decode分離: 2つのワークロード、2つのプール

prefillとdecodeはボトルネックが違う。prefillは計算律速で、多数のプロンプトトークンを一度に処理し、大きな行列積の恩恵を受ける。decodeはメモリ帯域律速で、各ステップでリクエストあたり1トークンを生成し、KV cacheを読む。同じプールに置けば、ハードウェア、並列化、バッチサイズのすべてで妥協が強いられる。

分離はそれらを別々のプールに分ける。

• Prefillプール: 8 GPUマシン、EP2〜8 / DP2〜8。非キャッシュトークン数でサイズを決める。
• Decodeプール: 64〜128 GPUのスーパーノード、EP64〜128 / DP64〜128（Wide-EP）。実行中のリクエスト数でサイズを決める。
• ビジョンエンコーダ: 1インスタンス1 GPU。多くの場合より安いカード。
• ストレージ: 計算とは別の、KV cache専用ノード。

DeepSeekによればP:D比はおよそ1:1で、prefill 64 GPU + decode 64 GPUを効率的に動く最小単位と呼んでいる。1P + 1Dの構成もデプロイ可能だが、推奨されるdecode構成はEP64以上だ。

難しいのは受け渡しだ。リクエストが到着し、prefillされ、KV cacheを生成し、そのキャッシュが見えるdecodeエンジンへルーティングされなければならない。それには転送経路、キャッシュの所在を示すディレクトリ、キャッシュ位置とdecode負荷の両方を考慮するルーティング判断が要る。DeepSeekは8 GPUあたり約400 Gbpsのインターコネクトを見込み、PとDは隣接するデータセンターに置くこともできるとしつつ、信頼性の面で代償があるとしている。

リリースには分離について「必要なエンジン機能のほとんどは実装済み」とあるが、仕組み全体は含まれていない。本番と同じ形が欲しければ、オーケストレーション層を自分で作ることになる。

ロードバランシング: 2つの次元、4つのバランサ

DeepSeekは4つのバランサを挙げている。prefill、decode、ビジョンエンコーダ、expert-parallelだ。

Prefillロードバランサ

リクエストは合計コンテキスト長によって4つの階層にバケット分けされる。<16K、16〜64K、64〜256K、≥256Kだ。各階層に割り当てるエンジン数は、前ラウンドの計算クォータ需要に基づいて再配分される。DPグループ内では、各リクエストは現在のクォータ負荷が最も低いランクへ送られる。GPU内ではFIFOで取り出し、チャンクサイズは時間予算から、フィッティングした2次コストモデルで解く。

これはラウンドロビンより洗練されている。prefillのコストはリクエスト数に対して線形ではないからだ。256Kトークンのプロンプト1本が、短いリクエストのバッチを圧倒しうる。

Decodeロードバランサ

decodeのルーティングは2つの次元のバランスを取る。リクエスト数（ステップあたりのバッチサイズを決める）と、KV cacheの総長（attentionのコストを決める）だ。ヒューリスティックは、短いリクエストを並列度が低くKV長が大きいGPUへ、長いリクエストをKV長が小さいGPUへ送る。狙いはバッチとattentionの仕事の両方を釣り合わせることにある。

Expert-parallelロードバランサ

EPLBは冗長エキスパートを追加し、直近の負荷に基づいてエキスパートをGPUに定期的に再割り当てする。DeepSeekはdecodeのmoe_lbを約1.090と報告している。最も遅いランクは平均より約9%多く仕事をする。prefillの数値は英語版Q&Aと中国語記事で少し異なるが、仕組みは同じだ。

80%という現実確認

Q&Aで最も有用な一文はこれかもしれない。本番のロードバランシングは、完全に均衡したオフラインベンチマークのおよそ80%に達する。

つまり、独自のバランサとスタック全体の制御権を持つDeepSeekでさえ、オフラインベンチマークのスループットの約80%にとどまる。DeepInferに単純なルータを載せたチームがそれ以上を期待するべきではない。同時に、オフラインのParetoチャートは上限だということでもある。制御された環境で測定されたもので、本番のルーティングの偏りは含んでいない。

これは批判ではない。期待値を合わせるための話だ。分散サービングは乱雑で、最後の20%にこそ工学の多くが宿る。

作るか買うか

APIとして提供したいなら、大きく3つの道がある。

ほとんどのチームにとって、最初の道が現実的だ。DeepInferは、ハードウェア、ワークロード、そしてサービス層を自前で持てる工学力の3つが揃ったチーム向けだ。あるいはDeepSeekのやり方を学びたいエンジニア向けである。

戻るなら制約のページ、読むならエンジンの仕組みへ。