DeepSeekの推論エンジン：5つの思い込みを検証

DeepSeekが本番用のLLM推論エンジンをApache 2.0ライセンスでGitHubに公開したところ、リポジトリは数時間で数千のスターを集めました。それ自体は驚くことではありません。驚くべきは中身です。DeepInferは研究用のおもちゃでも機能を削ったデモでもありません。DeepSeek自身の説明によれば、DeepSeek-V4.1-Flashを、クラスタ1つあたり1日155兆トークンという規模で提供しているエンジンです。オフピーク料金でGPU1時間あたり約38ドルの収益になるとも述べられています。これらの数字が大まかにでも正しいなら、業界の多くが都市伝説扱いしてきたエンジニアリング上の判断が背後にあることになります。そこで、新しくオープンソース化された本番システムに対していつもやるように、READMEを懐疑的に読み、推論エンジンに関する一般的な思い込みをそれと照らし合わせて検証してみましょう。

思い込み1：推論エンジンは単に高速なフォワードパスだ

よくある素朴なモデルはこうです。モデルがモデルであり、エンジンはカーネルを呼び出すだけの薄いラッパーにすぎず、性能はより速いGPUを買えば得られる、というもの。しかしDeepInferの機能一覧を見ると、この考えは崩れます。出荷対象として挙げられているのは、「ゼロオーバーヘッドのバッチスケジューラ」を備えた非同期スケジューリング、信頼度ベースの検証を伴う投機的デコーディング、スライディングウィンドウ注意の有界リプレイ、バッチ不変推論、決定論的サンプリング、そして正規表現・JSONスキーマ・EBNF文法で制約される構造化出力です。これはスケジューラ、メモリマネージャ、検証システム、制約コンパイラの集合体です。カーネルは一覧の中でほとんど付け足し程度にしか見えません。

これは現場の人が何度も再確認している事実と一致します。フォワードパスは簡単な部分で、FlashAttentionや優れたGEMMライブラリ以来、ほぼ解決済みです。難しいのはGPUにデータを供給し続けることです。CPUがどのリクエストを受け入れるか、どのKVブロックを退避させるか、どの下書きトークンを検証するかを決めている間にSMがアイドル状態になれば、その1ミリ秒ごとに金が溶けていきます。DeepInferの非同期スケジューラは、まさにCPUでのスケジューリングとデバイス実行を重ねるために存在し、GPUがPythonを待つことがないようにしています。もしあなたの推論基盤がまだ同期的にスケジューリングしているなら、その一点の変更は、計画していたどのカーネル差し替えよりも価値がある可能性が高いです。

READMEには、率直な一文もあります。完全な推論サービスには、さらにKVキャッシュシステム、prefill/decodeの分離、データ並列レプリカ間のロードバランシングが必要だが、それらはこのリリースに含まれていない、というものです。つまり、エンジン自体も本当のシステムの一層にすぎません。本番の推論は、機械学習の衣をまとった分散システムの問題なのです。これは以前にもLLMエージェントが分散システムによく似ていると指摘したことですが、スタックを一層下りても同じように当てはまります。

思い込み2：バッチは大きいほど良い

連続バッチング（他のリクエストが終わるとすぐに新しいリクエストをバッチに投入し、バッチ全体の完了を待たない方式）は今では必須の機能で、DeepInferももちろん対応しています。しかし検証すべきより興味深い思い込みは雑な版、「スループットはバッチサイズに比例するのだから、バッチを最大化せよ」です。DeepInferには、まさにこれが間違いだからこそ存在する機能が2つあります。

1つ目はバッチ不変推論（DEEPINFER_BATCH_INVARIANT=1）です。通常、リクエストの出力は同じバッチに何が入っているかによってずれることがあります。カーネル内の縮約順序がバッチの構成によって変わり、浮動小数点の加算は結合法則を満たさないからです。DeepSeekは、バッチの構成に関係なく結果が一致するようにするためにエンジニアリングの労力を払う価値があると判断しました。なぜか。大規模に提供すると、同じプロンプトが日によって違うトークンを返すと、顧客や評価パイプラインがそれに気づくからです。バッチサイズを最大化することが非決定性を受け入れることを意味するなら、DeepSeekはスループットを使って決定性を買い戻す道を選んだわけです。これは、真に最適化すべき目的関数は生のトークン毎秒ではなく、信頼できるトークン毎秒だということを示しています。

2つ目は投機的デコーディングのための信頼度ベースの検証スケジューリングです。エンジンは下書きトークンを生成し（デフォルトの最大下書き長は5）、信頼度の推定値を使って、どれだけの検証作業をスケジュールするかを決めます。素朴な方法は毎ステップ固定長の下書きを検証しますが、賢い方法は、最適な投機的作業量はリクエストごと、ステップごとに変わることを認めます。信頼度が正当化する以上にバッチ処理すると、捨てることになるトークンに計算資源を浪費します。逆に少なすぎると、高速化の機会を逃します。このスケジューラは、単にリクエストを詰め込んでいるのではなく、ステップごとに最適化問題を解いているのです。

• バッチサイズはスループットを上げるが、レイテンシも上げる。prefillのバッチが大きくなるにつれ、最初のトークンまでの時間は悪化する。
• バッチの構成が数値計算結果を変える。バッチ不変カーネルのコストを払わない限り、出力はずれる。
• 投機的な作業には逓減がある。下書きの採用率は下書き長とともに下がるため、固定スケジュールはFLOPsを無駄にする。
• KVキャッシュこそが本当の上限。メモリに収まる量を超えてバッチは大きくできない。だからバッチ方針よりもメモリのレイアウトのほうが重要になる。

思い込み3：KVキャッシュ管理はもう解決済みだ

PagedAttentionは、OSのような手法を広めました。KVキャッシュを固定サイズのページで割り当て、仮想メモリのように払い出し、断片化を防ぎます。vLLMがこの方式の有効性を示し、DeepInferもその謝辞によれば、もともと主にvLLM上に構築されていました。ではページ式KVキャッシュは完成しているはずですよね？ そう単純ではありません。DeepInferのREADMEは、さらに踏み込んだ設計目標にさりげなく触れています。本番システムの設計目標の1つは、KVキャッシュを72時間以上保持することでした。

その意味を考えてみてください。最大級のGPUでもHBMは数百GB単位ですが、混雑したクラスタ全体で72時間分のキャッシュは数PBの状態になります。デバイス上に保持することはできません。HBM、ホストDRAM、NVMe、場合によってはリモートストレージからなる階層型KVシステムが必要です。しかも、古いプレフィックスを引き戻してもレイテンシSLOを壊さないよう、退避とプリフェッチのポリシーが十分に賢くなければなりません。READMEが、リリースに含まれていないものとして「KVキャッシュシステム」を挙げているのはこのためです。それは独立した、本格的なインフラです。KVキャッシュをGPU内のページング問題として扱ってきたなら、最前線はそれをストレージシステムとして扱うことに移っています。より小規模な版の苦労については、GPUのVRAMが足りなくなったときの対処法で取り上げましたが、これはデータセンター規模の同じ問題です。

また、真似する価値のある細かいKVの工夫が1つあります。SWAの有界リプレイです。デコーダのスライディングウィンドウ注意層では、prefill時にプロンプト全体をリプレイする必要はありません。注意ウィンドウと最大バックトラック長を覆う有界な末尾部分だけで足ります（デフォルトでは140トークンを保持）。これは長いコンテキストでprefillの計算量を直接減らすもので、prefillのFLOPsがどこで消費されているかをプロファイリングして初めて見つかるような最適化です。汎用エンジンは、これを安全に行えません。モデルの注意アーキテクチャを深く知っている必要があるからです。ここでもモデル特化型エンジンが勝ちます。

思い込み4：投機的デコーディングは無料のスループット向上だ

投機的デコーディングには、ほとんど魔法のような売り文句があります。安価な下書きを使って1回のフォワードパスで複数トークンを生成し、並列に検証して、一致するものを残す、というものです。ベンチマークでは重宝されます。しかし、DeepInferがこれをどうデプロイしているかを読むと、「無料だ」という思い込みは崩れます。フラグがそれを物語っています。有効化するにはDEEPINFER_ENABLE_MTP_VARLEN=1、下書き長を制限するにはDEEPINFER_USE_NEXTN_DECODE、さらにその上に独立した信頼度スケジューリングの層があります。本当に無料なら、これらは不要で、常に下書きすればいいだけのはずです。

経済性は次のように働きます。下書きと検証は毎ステップ余分なFLOPsを消費します。採用率が十分高く、トークン数/ステップの増加が追加コストを上回ったときにのみ得をします。採用率は、下書きの仕組み、ドメイン（コードは上手く下書きできますが、とりとめのない散文はそれほどでもありません）、そして何より、バッチの負荷によって変わります。バッチサイズが大きいとGPUはすでに計算律速になっているので、余分な検証のFLOPsがそのまま実際の処理を押しのけます。投機的デコーディングはレイテンシ律速の領域で輝きますが、スループット律速の領域では逆効果になることもあります。両方の領域を扱う本番エンジンは、それを適応的にスケジュールする必要があり、まさに信頼度ベースの検証スケジューリングがそれを行っています。

私の意見です。投機的デコーディングを既存の推論基盤に後付けするチームを見てきた経験から言うと、これはスループットの機能ではなく、レイテンシの機能として扱うべきです。高い稼働率でのトークン単価がボトルネックなら、まずスケジューラとKVのレイアウトを直してください。中程度の負荷で、対話型ユーザーのp99レイテンシがボトルネックなら、投機的デコーディングは利用できる最良のツールの1つです。そして、それをどう制御するかについて、DeepInferは実戦で鍛えられた参照実装を提供しています。

思い込み5：大規模に提供するにはNVIDIAのお墨付きだけで十分だ

DeepInferは、対応するハードウェアとしてNVIDIA SM100 GPUとHuawei Ascend 950 NPUの2つだけをサポートしています。プラットフォームごとに別々の要件ファイル（requirements-nvidia.txt、requirements-ascend.txt）を用意し、それに応じて機能を制限しています。たとえばバッチ不変推論はNVIDIA専用です。これは控えめですが重要なメッセージです。トップクラスの本番エンジンは、非NVIDIAのアクセラレータを一級市民として扱い、同じモデル、同じスケジューラ、同じ提供アーキテクチャを使わせているのです。

誤解のないように言うと、これは何を意味し、何を意味しないのか。Ascendの経路が成熟しているわけではありませんし、CUDAの堀が一夜にして消えるわけでもありません。同じREADMEにあるCUDA専用の機能こそ、エコシステムの差が現実にあることの証拠です。意味するのは、推論の移植性における最も難しいソフトウェア問題（エンジン、スケジューラ、並列化戦略）が、今やオープンでApacheライセンスの下にあり、最初から2つのターゲットに対応する設計になっている、ということです。小規模な研究室やハードウェアベンダーにとって、それは真似すべき壁ではなく、築くための土台です。フラッシュ級の市場の動向を見ている人なら、経済性がこの点にどれほどかかっているか知っているでしょう。以前にもフラッシュ級モデルこそが本当の推論効率の話だと書きましたが、ハードウェアの多様性はその話をさらに強めます。

並列化の設計にも触れておきましょう。注意層はバランス型コンテキスト並列を伴うデータ並列、MoE層はexpert-parallelと、expert-parallelのロードバランサの組み合わせです。これは、DeepSeekが説明している展開、つまりprefill用に少数のGPUとdecode用に数十のGPUを分離して使う構成に的確に合わせられています。decodeが重い分離構成は、大規模サービングのフリートで標準的なアーキテクチャになりつつあります。理由は単純な計算です。prefillは計算律速、decodeはメモリ帯域律速なので、両者を同居させると、どちらにも最適でないハードウェアを買う羽目になります。

思い込み6：これをそのまま持ってきて動かせばよい

最後に、この週末にスタックへ組み込もうと計画してリポジトリにスターを付けた人たちに向けて、もう1つの思い込みを崩しておきます。DeepInferが現在サポートしているモデルファミリーは、DeepSeek-V4.1-Flashの1つだけです。動作にはLinux、GCC 13以上、Python 3.12、CUDA 13、そしてSM100ハードウェアが必要です。SM100はBlackwell世代で、多くの人が手元に持っていないものです。ベンチマークは、1つのscale-upドメイン内でprefillに4基、decodeに64基のGPUを使って測定されています。そして、実際のサービスに必要な3つのもの、つまりKVキャッシュシステム、分離用の配管、レプリカのロードバランシングは、明示的に対象外です。これはエンジンであって、車ではありません。

ただ、使えないと切り捨てるのは要点を外しています。ここからは意見を述べます。このリリースの価値は、導入すべきソフトウェアというより、本番品質とは実際に何を意味するのかの仕様にあります。第一級のフラグとしてのバッチ不変推論。再現性のために固定のseq_seedを使う決定論的サンプリング。リトライで後付けするのではなく、サンプラに組み込まれた構造化出力。信頼度ベースの投機。実験ではなくデフォルトとしての非同期スケジューリング。推論スタックを作るにせよ買うにせよ、このREADMEはチェックリストとして使えます。自分で大規模モデルを動かしているなら、小規模側については自前のハードウェアでLLMを動かす実践ガイドもありますが、同じ優先順位が規模を変えて当てはまります。第一にスケジューラ、第二にメモリのレイアウト、第三にカーネルです。

フォワードパスは簡単な部分です。本番の推論とは、スケジューラ、メモリマネージャ、そしてたまたまカーネルを呼び出す検証システムのことなのです。

地政学的なタイミング（米連邦政府の除外命令の数時間後に公開され、コメント欄では贈り物だとか妨害工作だとかさまざまに言われている）は、見出しを独占するでしょう。それはそれで構いません。しかし、ドラマを取り除いても、エンジニアリング上の結論は自立しています。推論エンジンについて私たちが信じてきたことの多くは、一世代前のものだったのです。面白い仕事は、もはやカーネルの中にはありません。その周囲すべてにあります。