DeepInferの制約: KV cache、PD、そして誰が動かせるのか

DeepInferはオフライン推論エンジンであり、ホスト型APIでもモデルでもない。完全なオンラインサービスに必要なKV cacheシステム、prefill/decode分離、データ並列ロードバランシングは、このリリースに含まれていない。対象はDeepSeek-V4.1-Flashであり、この欠落はREADME自身が挙げているリストだ。

欠けている3つの部品

1. KV cacheシステム

すべてのリクエストはKV cacheを構築する。モデルがプロンプトに対してすでに計算したキーと値のことだ。同じprefixが再び現れるなら——長いシステムプロンプト、マルチターンのエージェント履歴、共有ドキュメント——キャッシュを再利用して再計算を避けられる。規模が大きくなるほど、prefixキャッシュのヒット率はコストとTTFTを左右する最大のレバーの一つになる。

実際のKV cacheシステムは、GPUメモリ内の辞書ではない。次のものが必要だ。

• 退避とTTLを備えたストレージ階層（HBM、ホストメモリ、SSD）
• ローカルだけでなく、マシンをまたいでprefixを見つける仕組み
• 計算と重ねられる転送経路
• 障害耐性。計算ノードはストレージノードより頻繁に落ちる
• ロードバランサと衝突しないルーティング方針

DeepSeekの本番設計から規模感がわかる。専用の3FSクラスタに約100 PiBのSSD、10+2イレージャーコーディング、エージェントトラフィック向け3日・チャットボット向け7日のTTL、GPUあたり約14.4 TBの論理KV、8 GPUあたり約400 Gbpsのインターコネクト。どれもリリースには含まれていない。

2. VE / Prefill / Decodeの分離

リリースには「必要なエンジン機能のほとんどは実装済み」とあるが、分離の仕組み全体は含まれていない。本番では、ビジョンエンコーダ、prefillプール、decodeプールが別々のマシン上で、別々のスケーリング方針のもとで動く。難しいのは受け渡しだ。プール間でKV cacheを移動し、リクエストを適切なprefillエンジンに振り、decodeの稼働率の均衡を保ち続ける。

これがなくても、オフラインのバッチ実行はできる。DeepSeekのオンラインサービスの形を再現することはできない。

3. データ並列レプリカ間のロードバランシング

DeepSeekはprefill、decode、ビジョンエンコーダ、expert parallelismの4つに別々のバランサを使う。prefillバランサはリクエストをコンテキスト長でバケット分けし、残りの計算クォータで振り分ける。decodeバランサはリクエスト数とKV長の両方を見る。エキスパートバランサはホットなエキスパートをGPU間で移動させる。Q&Aによれば、その結果は完全に均衡したオフラインベンチマークのおよそ80%に達する。

この最後の数字は有用な現実確認だ。DeepSeekの本番システムでさえ、オフラインベンチマークのスループットの約80%にとどまる。単純なラウンドロビンのルータがそれ以上にできる見込みは薄い。

なぜこの位置に線が引かれているのか

2025年4月、DeepSeekは推論エンジン全体をオープンソース化しない理由を説明した。コードは旧版vLLMを大きく改変したフォークであり、社内のクラスタ管理と結合しており、チームには大規模なオープンソースプロジェクトを維持する余力がなかった。計画は、独立したライブラリを切り出し、最適化を上流に還元することだった。

DeepInferはその次の段階であり、方針転換ではない。計算とスケジューリングの経路——カーネル、並列化、投機、キャッシュ復元、構造化出力——を開き、社内インフラと最も強く結合した部分——ストレージシステム、マシンをまたぐ分離、本番用のロードバランサ——は手元に残している。

これは一貫した境界線だ。同時に、「本番エンジンをオープンソース化した」という枠組みには限定句が必要になる。エンジンは開いている。それを囲むサービスは開いていない。

実際に動かせるのは誰か

DeepInferはNVIDIA SM100 GPUとHuawei Ascend 950 NPUをサポートするが、DeepSeekが公開した性能チャートはNVIDIAハードウェアのみを対象としている。これはAscendが非サポートという意味ではなく、公の場で測定されていないという意味だ。

何を作る必要があるか

DeepInferをサービスにしたいなら、次のコストを見込んでおく。

• KV cacheサービス: prefixマッチング、階層ストレージ、マシン間転送、TTL/退避、障害耐性。
• prefill/decodeルーティング: プールの分離、KVの受け渡し、キャパシティプランニング、オートスケーリング。
• ロードバランシング: prefillは計算クォータとコンテキスト長で、decodeはリクエスト数とKV長で、さらにエキスパートの再割り当て。
• API層: Chat Completions / Responses / Messages、ストリーミング、ツール呼び出し、構造化出力、エラー処理。
• テナンシーと運用: 認証、クォータ、課金、レート制限、トレーシング、メトリクス、ログ、カナリアリリース。
• 評価: 実際のワークロード下での品質、レイテンシ、コストの回帰テスト。

DeepSeekのdeepseek-recipeはAPI層のうちプロトコル/トークナイズ部分を助ける。サーバー、認証、課金、KV cacheは提供しない。

代替手段、勝者なしで

目的がV4.1-Flashのサービングなら、DeepInferだけが道ではない。適切な選択は、すでに運用しているものと、どこを制御したいかで決まる。

ここで順位付けはしない。vLLMとSGLangにはすでにAPI層と広い採用実績がある。DeepInferにはDeepSeekの本番チューニングと、より狭い適用範囲がある。来週APIが必要なチームは、KV cacheサービスの構築から始めるべきではない。

判断ガイド

• DeepInferを使うべきなのは SM100またはAscend 950のハードウェアがあり、DeepSeekのサービング最適化を研究・再現したい場合。サービス層を作る覚悟も必要だ。
• vLLM/SGLangを使うべきなのは 今すぐAPIを提供したい、幅広いモデルサポートが要る、KV cacheとルーティングのスタックを自前で持ちたくない場合。
• 待つべきなのは Ascendの性能データ、本番同等性、DeepSeekによるサポート済みのオンラインサービング経路が必要な場合。
• 使うべきでないのは コンシューマーGPUしかない、他のモデルが必要、OpenAI互換のエンドポイントがすぐ手に入ると思っている場合。

次は本番環境との差の詳細、あるいは短い答えへ。