DeepSeek V4がDSparkで推理速度80%向上——投機的デコードの「工学的成熟」が意味すること

DeepSeekがまたも静かに、しかし重要なアップデートを出した。今回の主役はモデル能力の向上ではなく、推論インフラの刷新だ。

出典: 刚刚，DeepSeek V4更新DSpark，推理速度提升80%

要点 (事実のみ)

DeepSeek V4（Flash・Pro）に投機的デコード（Speculative Decoding）フレームワーク「DSpark」を導入。アーキテクチャ変更ではなく推論エンジン側の改善
既存の単一トークン生成ベースライン（MTP-1）比で、Flashモデルは60〜85%、Proモデルは57〜78%の生成速度向上を達成（総スループット同一条件）
Qwen3シリーズ（4B・8B・14B）での検証で、平均受理長がEagle3比26.7〜30.9%、DFlash比16.3〜18.4%向上
半自己回帰生成（Semi-Autoregressive Generation）と信頼度スケジューリング検証（Confidence-Scheduled Verification）の2機構が核心。高負荷時に受理確率の低いトークンを事前カットし算力を節約する
全スタックOSSライブラリ「DeepSpec」を同時公開。データ準備・訓練・評価の3フェーズで構成され、QwenおよびGemmaを対象モデルとしてサポート。デフォルトのQwen3-4B設定ではターゲットキャッシュが約38TBに達する点に注意

徐聖博の見解

今回のDSpark発表を読んで最初に感じたのは、「これはモデルの話ではなくインフラの話だ」という点への敬意だ。投機的デコード自体は既知の手法だが、実際に本番の高並列トラフィックに乗せてMTP-1比で60〜85%の速度向上を出すのは、アルゴリズムの正しさとは別次元の工学課題である。Indeed Japanで推薦システムの本番運用に携わっていた経験から言うと、研究環境で動くものを「高並列・低レイテンシ・無損失」の三拍子で本番に乗せることは、論文を書くことの数倍難しい。

特に注目したのは「信頼度スケジューリング」の設計思想だ。受理されないと分かっているトークンをそのまま検証に流すのは算力の無駄遣いであり、それをリアルタイムの信頼度スコアで動的カットする発想は、コスト管理の観点から非常に実用的だ。我々のようにLLM APIを使ったサービスを開発している立場では、レイテンシとスループットのトレードオフは常に設計の中心にある。DeepSeekがこのロジックをオープンソースのDeepSpecとして出してきたことは、自社でカスタム草稿モデルを育てたいエンジニアにとって実質的な参入コストを大きく下げる。

一方で、DeepSpecのデフォルト設定でターゲットキャッシュが38TBに達するという記述は見落とせない。研究用途や大手クラウドベンダーならともかく、中小規模の開発チームが自前でこのパイプラインを回すのは現時点では現実的ではない。PoC段階では「DeepSeekのAPIで速度恩恵を受ける」、プロダクション段階では「DeepSpecを使いこなせるインフラ規模かどうか」を冷静に評価することが先決だろう。DSparkの恩恵が最もダイレクトに届くのは、DeepSeek API経由でサービスを構築しているチームであり、それは今すぐ享受できる。

(編集レンズ: 実装・運用視点 / 発注側・中小企業への含意)

推論コストは、事業計画の変数である

技術記事として読むと「速くなった」で終わるが、AIを組み込んだサービスを事業として持っている側には、もう一段の意味がある。推論速度の改善は、そのまま粗利率の改善である。

LLMを使ったプロダクトの原価は、ほぼ推論コストで決まる。同じ処理が60〜85%速くなるということは、同じインフラで捌ける件数が増え、1リクエストあたりの単価が下がるということだ。これは値下げ余地にも、機能追加余地にもなる。

開発会社・SIerとして受託でAI機能を作る場合も同じで、見積もり時点で推論コストの前提を明示しているかが後で効いてくる。「月間◯件の想定で、モデルはA、1件あたり約◯円」と書いておかないと、利用が伸びたときに誰の負担かで揉める。ここは請負より準委任が向く領域でもある（要件定義は準委任契約が基本）。