DeepInferとは何か？DeepSeekの推論エンジン、そして同社が提供しなかった部分

DeepInferは、DeepSeekが2026年10月16日にApache-2.0の下で公開した推論フレームワークであり、ただ1つのモデル、DeepSeek-V4.1-Flashを提供する。DeepSeek-V4.1-Flash-1017がデフォルトのチェックポイントである。この単一モデルという範囲は最初に理解すべき点である。なぜなら、それがリポジトリに関する他のほとんどすべてを説明するからだ。これは、たまたまDeepSeekの設定を含んでいる汎用のサービングフレームワークではない。これはDeepSeekが本番環境で実行しているコードパスを、一般化できる部分まで削ぎ落としたものであり、その削減について正直に述べている。README自身が挙げている、完全な推論サービスに必要なものと、このリリースに含まれないもののリストには、KVキャッシュシステム、VE/Prefill/Decodeの分離、データ並列レプリカ間の負荷分散が含まれている。得られるのは計算パス、すなわちカーネル、並列性、投機的デコード、スケジューリング、構造化出力である。得られないのは、計算パスを大規模に低コストで運用できるようにするストレージとルーティングの層である。DeepSeekはその理由をこう説明している。それらのコンポーネントは内部インフラストラクチャと密結合しているため、設計は公開された解説記事で説明される一方、コードは社内に留め置かれる。

リポジトリには実際に何が含まれているのか

公開されている機能一覧は、大規模なMixture-of-Expertsモデルを提供する際のボトルネックを巡るツアーのように読める。DeepSeekが以前公開したカーネルライブラリがある。アテンション用のFlashMLA、行列積用のDeepGEMM、エキスパート並列通信向けのDeepEP、さらにTileKernelsとDeepSelectだ。並列化スキームもある。アテンションはバランスの取れたコンテキスト並列を伴うデータ並列として実行され、MoE部分はエキスパート並列ロードバランサーを備えたエキスパート並列として実行される。投機的デコーディングスタックのDSparkもあり、検証長は固定ではなくスケジュールされる。SWA bounded replayもある。これは、スライディングウィンドウ・アテンションのキャッシュがキャッシュミスのたびに完全な再計算を強いるのを防ぐ仕組みだ。非同期バッチスケジューリング、決定論的サンプリングを伴うバッチ不変推論、正規表現、JSONスキーマ、EBNFで制約された構造化出力がある。

エントリーポイントは意図的に小さくされています。DEEPINFER_ACCELERATOR を nvidia または Ascend 相当に設定して build.sh を実行すると、リポジトリには examples/offline_inference.py が同梱されており、デフォルトのチェックポイントをエンドツーエンドで実行します。DEEPINFER_HF_MODEL_DIR は、別の重みディレクトリを指すようにします。公開ベンチマークは、prefill に 4 台の SM100 GPU、decode に 64 台の SM100 GPU で測定されており、これはこのエンジンが対象として書かれたデプロイ形態であり、ノートPC向けのデモではありません。

READMEにはコードの由来も記されており、それを読む前に知っておく価値がある。このエンジンは当初主にvLLM上に構築され、設計上の着想はSGLangとTensorRT-LLMから得ている。その系譜は構造に表れている。スケジューラ、ページドアテンションのインターフェース、サンプリング経路は、これらのプロジェクトを読んだことがある人なら見覚えがあるだろう。また、今回のリリースがゼロから書かれたアーキテクチャではなく、サービングスタックのフォークである理由も説明している。DeepSeekが追加したのは、自社モデル固有の部分である。分離型デプロイ、バランサを備えたワイドエキスパート並列、スライディングウィンドウ・リプレイ、そしてDSparkだ。

それが含まないもの、そしてなぜそれがより重要であるか

三つの欠けている部分は、小さな漏れではない。それぞれはエンジンが本番トラフィックを処理する前に存在していなければならないシステムであり、それぞれが異なる形で高くつく。

• KVキャッシュシステム。プレフィックスの再利用は、チャットワークロードにおいてコストの大部分を占める部分です。キャッシュヒットがプリフィルを置き換えるからです。キャッシュストアがなければ、すべてのリクエストがそのプロンプトを再計算します。DeepSeek自身の記述では、使用しているストアについて説明されています。ローカルホストのメモリではなく専用の3FSクラスタを使っており、それにより任意のプリフィルマシンがあらゆるプレフィックスにヒットでき、キャッシュ容量をコンピュートとは独立してスケールできるようにしています。

• VE/Prefill/Decodeの分離。READMEには、エンジン側の機能のほとんどはリリース内にすでに存在しており、欠けているのはデプロイメントであると記されています。ビジョンエンコーダー、プリフィル、デコードを分離すると、各ステージをそれぞれのボトルネックに合わせてサイズ設定でき、初回トークンまでの時間をトークン間の時間とは別に制御できます。これはインフラストラクチャの決定であり、フラグではありません。

• データ並列レプリカ間の負荷分散。DeepSeekはプリフィル、デコード、ビジョンエンコーダー、エキスパートパラレルの4つのバランサーを運用しており、解説記事ではその4つすべてについて説明している。ルーティングロジックはいずれも提供されていない。それがなければ、レプリカフリートの性能は手前に置くルーター次第であり、単純なラウンドロビン方式のルーターでは、このストアが守るために設計されたキャッシュヒット率を損なってしまう。

合わせて読むと、その省略から、これがどのような種類の成果物なのかが分かる。DeepInfer は計算パスの参照実装であり、カーネルとスケジューリングの作業内容を検証し再利用できるように公開されたものであって、インストールしてトラフィックを向けるための配布物ではない。

ハードウェアゲートこそが本当のフィルターです

DeepInferはNVIDIA SM100とHuawei Ascend 950を対象としています。AmpereパスもHopperパスも存在せず、これにより今日のほとんどのクラスタにあるGPUの大半が除外されます。ツールチェーンの残りも同様に限定的です。Linuxのみ、GCC 13以降、Python 3.12、NVIDIAにはCUDA 13、AscendにはCANN 9.2です。さらにリリースは一切ありません — 2026年10月21日に確認された時点で、リポジトリには公開リリースがゼロだったため、ダウンロードするものもピン留めするものもありません。クローンして、自分のツールチェーンに対してビルドします。

これだけ注目されるオープンソースのリリースとしてはその組み合わせは異例であり、見落としというより、スコープについての正確な説明と読むのが妥当だ。リポジトリ内のカーネルは特定の命令セットと特定のインターコネクト向けに書かれており、READMEの数値はそのハードウェアから得られたものだ。計算パスを1世代下へ移植するのは、コミュニティなら素早くやるが、エンジニアリング組織としては約束できない類の作業そのものだ。リリースから数日以内に、旧世代のNVIDIA製パーツを対象とするサードパーティ製の移植版がGitHubに現れた。これは需要についての有用なシグナルだが、公表されたスループット数値が移植後も維持されるかについてはまったく何も示すものではない。

DeepSeekが実際に運用しているデプロイ形態

アーキテクチャの記述は、リポジトリの前提が読み取れるようになる場所だ。システムは、ビジョンエンコーダ、プリフィル、デコード、さらに専用ストレージノードに分離されている。プリフィルは2〜8のエキスパート並列とそれに合わせたデータ並列を使用し、HBMが許す最小構成を選ぶ。デコードは逆方向で、64〜128のエキスパート並列とデータ並列を使用する。DeepSeekはこれをWide-EPと呼び、利用可能なGPUが許す最大構成を使う。テンソル並列とコンテキスト並列はまったく使用されない。ビジョンエンコーダはインスタンスごとに1つのGPUで実行され、より安価なGPUが推奨される。エンコーダはコストがかかるところではないからだ。

意味のある最小のデプロイ構成は、これらの数値から導かれる。prefill GPU 1台と decode GPU 1台が稼働し、実際には2つのプール間の比率はほぼ1対1になる。しかし、decode は expert-parallel の利点を得るために64台以上の GPU を必要とするため、最小の効率的な単位は prefill GPU 64台＋ decode GPU 64台になる。DeepInfer の効率に関するあらゆる主張を読むときは、この数値を覚えておくべきだ。その数字は128 GPU のデプロイ構成を表しており、その半分が1つのステージにあたる。

プリフィルとデコードをデータセンター間で分割することは技術的には可能です。なぜなら、DeepSeek-V4.1-FlashはKVキャッシュを大幅に圧縮しており、DeepSeek自身のデプロイでも推論ノードを異なるものの隣接するデータセンターに配置しているからです。予算は8GPUあたり約400 Gbpsのインターコネクトで、その記述は信頼性コストについて率直です — 建物間の光ファイバーは切断されやすいのです。

なぜデコードはそんなに広範囲に分散しているのですか

広範なエキスパート並列化は、設計において最も影響の大きい選択であり、スケーリングの小技と誤読されやすい。混合エキスパート層では、各トークンは少数のエキスパートにのみ触れるため、デコードステップのコストは演算強度よりも、エキスパートの重みとアクティベーションの移動によって支配される。エキスパートを64基または128基のGPUに分散すると、各GPUが寄与するステップあたりのメモリトラフィックが減少し、エキスパート間の負荷が均等に保たれるならば——これが条件だ——毎秒トークン数が向上する。エキスパート並列ロードバランサはそのためのものである。

DeepSeekの設定はコピーできるほど具体的だ。プリフィルでは、各GPUは自身が所有するエキスパートに加えて4つの冗長エキスパートを保持し、統計は100ステップのウィンドウで収集され、エキスパートは1,000ステップごとに再割り当てされ、重みはNVLink共有メモリを介してグループ内でシャッフルされる。測定された不均衡（最遅ランク÷平均）は、EP4/DP4構成で1.074、EP2/DP2構成で1.045だった。デコードでは設定がより長い間隔に広がる。GPUあたり1つの冗長エキスパート、1,000ステップの統計ウィンドウ、10,000ステップごとの再割り当てで、測定された不均衡は1.090だった。両者の違いが要点だ。プリフィルではバースト的で異種的な作業が発生するため高速な再バランスが必要だが、デコードでは安定した流れが続くため長いウィンドウを許容でき、再バランスはまれにしか行わず、その特権に対してほとんどコストを払わない。

ルーティング側も同じ特徴を持っています。プリフィルリクエストは総コンテキスト長によって4つの階層（16K未満、16～64K、64～256K、256K以上）に分類され、エンジンは前回ラウンドにおける各階層の計算需要のシェアに応じて各階層に割り当てられます。GPU内では、各プリフィルステップのチャンクサイズは固定ではありません。フィッティングされた二次コストモデルが、シーケンストークン数と既に計算済みのプレフィックスを前提に、1ステップにかかる時間を予測し、スケジューラは残り時間内で32,768トークンの予算に収まる最大のチャンクを解きます。デコードバランサーは、リクエスト数と総KVキャッシュ長という2つの次元を同時にバランスさせ、短いリクエストは同時実行数が低くキャッシュが長いGPUへ、長いリクエストはキャッシュが小さいGPUへ送ります。これら全体でどれだけの効果が得られるかについてのDeepSeek自身の要約は、完全にバランスの取れたオフラインベンチマークのおよそ80パーセントです。

キャッシュと、3日間という問い

KVキャッシュはローカルホストのメモリではなく、専用の3FSクラスタ上に存在し、この決定がストレージ設計の残りの部分を方向づけています。データは10+2のイレージャーコーディングで保存されるため、各コーディンググループは同時に2台のノード障害に耐えます。読み取りではグループ内の11台すべてのノードに要求を発行し、10台から応答が得られればデコードできます。ガベージコレクションワーカーはすべてのストレージノードで動作し、ウォーターマークを超えるとLRUに従って退避します。推奨サーバーは各30.73 TBのSSDを20台搭載し、少なくとも40 GB/sの読み取りと5 GB/sの書き込みを持続し、サーバーあたり約24時間分のデータを保持できるようにサイジングされています。実際には、クラスタはオンラインGPUあたり約14.4 TBの論理キャッシュで動作し、物理容量はそれより大きくなっています。

常駐性は、そのトレードオフが目に見える形になる場所だ。キャッシュ側には有効期限のロジックがなく、TTLはストレージ側で設定されている。エージェントトラフィックは3日、チャットボットトラフィックは7日で、約100ペタバイトのソリッドステートストレージを保持するクラスター上での話だ。この分割があるのは、チャットボットトラフィックのヒットにははるかに重いロングテールがあり、少量のキャッシュが何度も読まれるため、それを失うと、その容量から示唆される以上に全体的なヒット率を損なうからだ。DeepSeekが測定した、チャットボットの保持期間を3日に短縮するコストは、キャッシュヒット率の0.5～1パーセントである。これは小さな数字だが、たまたま大量の再計算プレフィルを表している。

スライディングウィンドウアテンションは、異なるルールを持つ別個のキャッシュを取得します。SWAキャッシュはページドブロックには入らず、各シーケンスはホストメモリ内の固定サイズのスロットを1つ占有し、DeepSeek-V4.1-Flashでは保存される層は最初の20層です。その領域だけが保持されます — 20層×134トークン×528バイトで、MXFP8形式のシーケンスあたり1,415,040バイトです。ストレージクラスタには何も送られず、生成したマシンのメモリに留まり、どのマシンが何を保持しているかを記録するインメモリディレクトリがあり、マシン間ヒット時は400 GbpsのVLAN経由で引き戻されます。

見出しの数字を生み出す2つの仕組み

有界リプレイは2つのうちより興味深いものです。なぜなら、上限のないコストを一定にしてしまうからです。通常、スライディングウィンドウのキャッシュミスはウィンドウを最初から再計算することを意味し、コストはコンテキスト長とレイヤ数に応じて増大します。DeepSeek は代わりに直近の128トークンのみを再計算し、アテンションウィンドウをそのセグメントに切り詰めることで、固定コストで近似 SWA キャッシュを生成します。エンコーダ側では、これによりプレフィックスキャッシュのヒット長を SWA キャッシュから完全に切り離します。SWA キャッシュがない場合、ヒットしたプレフィックスの最後の128トークンがリプレイされ、ブロックキャッシュはそのまま再利用されます。

削減幅が大きいのはデコーダ側だ。このアーキテクチャでは、デコーダ層のブロックキャッシュは最後のエンコーダ層の隠れ状態から射影されるため、層ごとに計算する必要があるのはデコーダのSWAキャッシュだけだ。それを正確に再構築しようとすると、プリフィルのたびに最後の2,560トークンを20個のデコーダ層に通すことになる。代わりに128トークンを再生し、その結果をプレフィックスキャッシュに入れずデコード専用に使うことで、プリフィルの総計算量はほぼ半減する。この一つの変更は、ほとんどのカーネル最適化よりも価値があり、モデルアーキテクチャを自社で所有するチームにしかできない類のことだ。

DSparkの貢献はより小さく、より従来的である。ドラフトトークンの受理確率はリクエストと位置によって異なるため、ステップごとに固定の5ドラフトを検証すると、却下されるトークンに計算資源を浪費することになる。信頼度ヘッドが各ドラフトトークンの受理率を予測し、スケジューラがドラフトを期待リターンで並べ替え、スループットを最大化するプレフィックスのみを検証する。本番環境ではドラフトモデルは依然としてステップごとに5トークンを生成するが、検証される数は5.00から3.2～4.4に減少し、約30パーセントの削減となる一方、受理長はほとんど変わらない——3.29対3.20である。EP64/DP64のベンチマークデータから読み取ると、レーンあたり約60の同時シーケンスで4～7パーセントのスループット向上になる。ちょうど60では、レーンあたりのスループットは毎秒13,730トークンから14,466トークンになる。約16同時シーケンスを下回ると、この手法は小さな純損失となる。低トラフィックのデプロイメントに採用する前に知っておく価値がある。

155兆という数字が何を意味するのか

今回の発表にまつわる最も引用される数字は、単一クラスタが1日あたり155兆トークンを処理し、バレー価格でGPU時間あたり38米ドルという全体売上を上げているというものです。両方ともベンダー報告によるものであり、どちらも再現可能なベンチマークではありませんが、だからといって興味深くないわけではありません。GPU時間あたりの売上高という数字は、スループットの数値とは本質的に異なる種類の主張です。なぜなら、稼働率、価格、キャッシュヒット率を1行に織り込んでいるからです。また、この数字は修飾条件なしで引用される可能性が最も高いものでもあるため、その修飾条件は書き留めておく価値があります。すなわち、単一クラスタ、バレー価格、コストではなく売上、そしてプレフィル、デコード、ビジョンエンコーダー全体の集計です。

より小さな2つの開示の方が、より直接的に役立つ。公開リポジトリにあるFlashMLAのデコードカーネルには、内部版が備えている手作業で調整されたアセンブリ最適化が1つ欠けており、単体では5～10％遅くなる。DeepSeekは、エンドツーエンドの性能差は最大5％だと述べている。また、投機的デコーディング用の内部ドラフトモデルは公開されているものより新しく、性能差は小さいと説明されている。どちらの記述も、第三者がコードをコピーすることで公開された性能のどこまでに到達できるかについての期待を示しており、その答えは、ハードウェアが一致していればその大部分に到達できる、というものだ。

現状のままのリポジトリ

上のキャプチャは2026年10月21日に取得されたもので、ページには16.3kスターと表示されています。同日にGitHub APIへ問い合わせたところ、16,590スター、1,649フォーク、176件のオープンIssueが返され、Issueは無効化され、議論は代わりにGitHub Discussionsへ振り分けられていました。スター数はその後も増え続けているため、ここにあるすべての数値はコードの属性ではなく、ある時点の記録として読むべきです。1週間足らずでこれほどのトラフィックがあったことは、コードの準備状況よりもDeepSeekのサービングスタックへの関心の高さを物語っており、リリース数がゼロであることが残りを説明しています。

自分で{{1}}それ{{/1}}を実行しようと考えているなら

正直にまとめると、DeepInferはじっくり読む価値がある一方で、運用が難しいということです。適しているかどうかは、4つの質問で判断できます。

• SM100 または Ascend 950 をお持ちですか？ツールチェーン内の他のすべては、この一点から決まります。適切なアクセラレータがなければ、公開されている数値はそのまま当てはまりません。また、コミュニティによる移植版は本番規模では検証されていません。

• 64台のデコードGPUを単一の通信ドメインで稼働させることはできますか？ワイドなエキスパート並列は、省略できる最適化ではありません。それはデコードパスが前提として設計されている構成です。その規模を下回ると、同じ名前の別のシステムを動かしていることになります。

• プレフィックスキャッシュはすでにお持ちですか？ お持ちでない場合、DeepInfer のコンピュートパスを、それを標準搭載している競合スタックと比較することになり、その比較結果は設計が本来受けるべき評価よりも悪く見えてしまいます。

• ルーティング層を書く余裕はありますか？プリフィルバケッティング、デコードバランシング、エキスパートの再割り当ては、再実装できる程度には十分詳しく説明されていますが、それらを再実装するには数週間の作業が必要であり、リポジトリが代わりにやってくれるわけではありません。

上記のいずれも所有されたくない場合は

ほとんどのチームにとって現実的な問いは、DeepSeek-V4.1-Flashをどうデプロイするかではなく、どこから呼び出すかです。このモデルは、128基のGPUクラスタを構築したりロードバランサーを再実装したりすることなく、互換APIを通じて利用できます。そしてそれは、本記事がこれまで説明してきたアーキテクチャを持つモデルそのものです。コンテキストの扱いも構造化出力の挙動も同じで、分離処理の作業は必要ありません。

行うべき比較は、抽象的にどちらのエンジンが速いかではありません。公開されている数値は、大半の読者が持っていないハードウェア上でのベンダー報告の測定値だからです。比較すべきは、そのワークロードが、3日間のキャッシュTTLと64-GPUのデコードプールによって価格が変わるものなのか、それとも数秒ごとのAPI経由のリクエストが、上記のどの操作よりも単純に安く済むものなのか、という点です。2つ目のケース——ほとんどのケースがこれに当たります——では、使うべきDeepInferの量はゼロであり、読むべき量はそのすべてです。始めるならDeepSeek V4.1 Flashモデルページからエンドポイントを確認してください。エンドポイントが何をしているかを知りたいなら、リポジトリのREADMEから始めてください。