DeepSeek のモデルを動かすための推論フレームワーク「DeepInfer」が、GitHub で公開された。単なるサンプルコードではなく、DeepSeek が大規模な本番サービスで使ってきた仕組みを、オープンソースとして出した形だ。生成AIの話題は派手なモデル発表に目が行きがちだが、実際に大量のリクエストをさばく現場では、推論基盤の出来がそのまま体験を左右する。今回の公開は、その裏側をかなり具体的に見せた点で面白い。
DeepInfer は、DeepSeek の大規模な本番サービスを支えてきた高性能な推論フレームワークだと説明されている。今回の公開版は、少なくともこのリリース時点では「offline inference」に焦点を当てており、スケールした提供に必要な核心部分を含む一方で、完全な推論サービスそのものではないと明記されている。対応モデルとして挙げられているのは DeepSeek-V4.1-Flash で、README には対応ハードウェアとして NVIDIA SM100 GPU と Huawei Ascend 950 NPU が並ぶ。
機能面では、まず最適化された kernels、model runtime、sampler runtime がある。並列化については、Attention DP や balanced CP、MoE EP と EPLB が挙げられていて、MoE すなわち Mixture-of-Experts 系のモデルを大規模に回す前提が見える。さらに DSpark と confidence-scheduled verification、SWA bounded replay、asynchronous scheduling、batch-invariant inference、deterministic sampling、structured outputs といった機能が列挙されている。
README はそれぞれの中身も少し説明している。たとえば DSpark と confidence-scheduled verification は、draft token を使って decoding を速め、confidence estimate をもとに検証のタイミングを調整する仕組みだという。環境変数 DEEPINFER_ENABLE_MTP_VARLEN=1 を有効にし、DEEPINFER_USE_NEXTN_DECODE で draft length の上限を制御する。デフォルトは 5 らしい。Decoder SWA bounded replay は、prefill の作業を減らすために、再実行する範囲を末尾の一定長に絞る方法で、V4.1 の既定設定では DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact と DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140 を使う。ここでは保持する suffix が SWA window と最大 backtracking length をカバーしていなければならない。
asynchronous scheduling は、CPU 側のバッチスケジューリングとデバイス実行を重ねるもので、デフォルトで有効だ。batch-invariant inference は、バッチの組み合わせが変わっても結果を同一に保つ機能で、NVIDIA 向けに DEEPINFER_BATCH_INVARIANT=1 で有効化する。deterministic sampling は、同じ入力 token と sampling parameters なら同じ出力を返すことを狙うもので、こちらも NVIDIA 向けの設定として DEEPINFER_BATCH_INVARIANT=1、DEEPINFER_ENABLE_MTP_VARLEN=0 を使い、SamplingParams に固定の seq_seed を渡す。structured outputs は、regex、JSON schema、EBNF grammar に合わせて生成を縛る機能で、SamplingParams に so_args={"schema_type": ..., "schema": ...} を渡すと使える。
README には、推論サービスとしてはまだ別途必要なものも書かれている。KV cache system、VE/Prefill/Decode disaggregation、そして data-parallel replicas 間の load balancing は、このリリースには含まれていない。ただし「ほとんどの必要な engine 機能は実装済み」とされている。セットアップ要件としては Linux、GCC 13.0 以上、Python 3.12、NVIDIA 向けには CUDA 13、Ascend 向けには CANN 9.2 が必要だ。ビルド前に空の Python 3.12 環境を作り、NVIDIA の場合は export DEEPINFER_ACCELERATOR=nvidia を設定して ./build.sh を実行する手順が案内されている。
起動例もある。DeepSeek-V4.1-Flash-1017 の checkpoint は初回実行時に Hugging Face cache にダウンロードされ、ローカルコピーを使う場合は DEEPINFER_HF_MODEL_DIR=/path/to/DeepSeek-V4.1-Flash-1017 を指定する。python examples/offline_inference.py で動かせるという。性能ベンチマークは prefill と decode に分けて示されており、4 枚の SM100 GPU で prefill、64 枚で decode を測定したと書かれている。どちらも同じ scale-up domain 内での計測だ。再現は run_sweep.sh を参照するよう案内されている。ライセンスは Apache License 2.0。さらに、DeepInfer は元々 vLLM を主軸に作られ、SGLang と TensorRT-LLM からも着想を得たと謝辞が添えられている。
私は、DeepInfer の公開はモデルそのものの発表より、ずっと実務寄りの意味を持つと思う。大規模言語モデルの競争は、しばしばパラメータ数やベンチマークの数字で語られるが、実際の事業では「どう安定して、どれだけ速く、どれだけ安く回せるか」が勝負になる。DeepInfer はまさにその部分を切り出している。しかも、単なるラッパーではなく、kernel、scheduler、sampling、parallelism まで触っている。ここまで来ると、モデルの賢さと同じくらい、実装の設計力が差を作る領域だと分かる。
一方で、公開版が offline inference に寄っている点も重要だと思う。README は KV cache system や disaggregation、load balancing がまだ別途必要だと明言している。つまり、今すぐ「これを入れれば本番推論基盤が完成する」わけではない。ここを誤解すると期待値が上がりすぎる。ただ、その未完成さを隠さずに出しているのは好感が持てる。どこまでが既に実装済みで、どこから先がサービス全体の設計課題なのかが見えるからだ。開発者にとっては、採用可否を判断しやすい。
謝辞に vLLM、SGLang、TensorRT-LLM の名前があるのは、かなり示唆的だと思う。DeepInfer はゼロから完全新規に作られたというより、既存のオープンな推論スタックの流れを吸収しながら、DeepSeek のモデル特性に合わせて詰めたものに見える。これは自然な進化だし、むしろ現実的だ。大規模推論は、モデルごとに最適解が違う。MoE の扱い、SWA の replay、confidence を使った verification など、DeepSeek が自分たちのモデルに効く部分へ集中しているように読める。
特に気になったのは、batch-invariant inference と deterministic sampling をわざわざ分けて書いている点だ。これは、性能だけでなく再現性やデバッグ性をかなり気にしている証拠だと思う。大規模サービスでは、バッチの組み方が少し変わっただけで出力が揺れると、障害調査が難しくなる。研究用途でも、同じ入力なのに結果が変わると比較が崩れる。こうした機能は派手ではないが、現場での価値は大きい。DeepSeek は「速い」だけでなく、「運用しやすい推論」を意識しているのではないか。
ベンチマークに 4 枚の GPU で prefill、64 枚で decode という数字が出てくるのも印象的だ。これは、推論の負荷分布がいかに偏っているかを物語っている。prefill と decode は同じ生成処理でも性質が違い、必要な最適化も違う。そこを分けて測るのは当然だが、64 枚を使う decode 側の規模感を見ると、DeepSeek が想定している運用はかなり大きい。個人利用や小規模導入の話ではなく、基盤としての AI サービスの話だ。
ただ、この規模感はそのまま「誰でも使える」ことを意味しない。NVIDIA と Ascend の両対応は魅力的だが、前提としている環境はかなり先端的だし、GCC 13 や Python 3.12、CUDA 13、CANN 9.2 といった条件も軽くない。つまり、DeepInfer は普及向けの簡単な配布物ではなく、かなりはっきりと「大規模運用のための道具」だ。ここは評価が分かれるところだと思う。使いこなせる組織には強いが、そうでないところには敷居が高い。
最後に気になったのは structured outputs だ。regex、JSON schema、EBNF grammar に沿って生成を縛れる機能は、単なる「きれいな出力」以上の意味を持つ。LLM を実務で使うとき、欲しいのは長文の雄弁さではなく、後続システムがそのまま処理できる形だ。フォーム入力、ワークフロー、エージェントの中間表現。そういう場面では、自由生成よりも構造化された出力の方がずっと価値が高い。DeepInfer がここまで最初から入れているのは、推論基盤の競争が「速いモデルを回す」段階から「業務にそのまま差し込める出力を安定して返す」段階へ移っているからではないかと思う。
逆に言えば、DeepInfer の公開は、DeepSeek が自社モデルだけでなく、その周辺の実運用層でも存在感を出そうとしているサインにも見える。モデルを出すだけでは、ユーザー体験は完成しない。推論、検証、再現性、出力形式まで含めて一つの製品になる。DeepInfer は、その現実をかなり率直に示した公開だと受け取った。
