一手間かけたほうが速い：DSpark で DeepSeek V4 の単一ユーザー生成速度が 85% 向上
- DeepSeek が DSpark を発表、DeepSeek-V4 専用に設計された投機的デコードの高速化フレームワーク
- 本番環境で既に使われている MTP-1 ベースラインと比べ、単一ユーザー生成速度が 60–85% 向上（DeepSeek の自己評価値）
- 中核の仕組み：軽量なドラフトモジュールが先回りして複数の語を推測し、メインモデルが一括検証、当たればすべて採用
- 鍵となる改良：ドラフト生成とメインモデル検証の二段階をパイプライン化して並行実行し、直列の待ち時間を消す
- 純粋に推論側のシステム最適化で、モデルの重みは変えず、既存の DeepSeek-V4 デプロイにそのまま組み込める
DeepSeek は何を発表し、どれだけ速くなったのか
DeepSeek は先日 DSpark を発表した。DeepSeek-V4 向けの投機的デコード高速化フレームワークで、既存の MTP-1 ベースラインの上で単一ユーザー生成速度をさらに 60–85% 引き上げる。
本当の見どころは「どのベースラインの上で速いのか」だ。「何の高速化もない状態」と比べているのではなく、DeepSeek-V4 の本番環境ですでに動いている MTP-1 投機的デコードと比べている。つまり、すでに高速化済みの方式の上で、さらに 60–85% を絞り出している。これは工学システムのレベルでの二段階目の高速化で、DeepSeek は V4 の本番サービスで既に使用していると述べている。
大規模モデルはなぜ一文字ずつしか出せないのか
大規模モデルが文章を生成するのは、一つの語に続いて次の語を吐き出していく作業だ。語を一つ吐くたびに、モデル全体を頭から末尾まで一度計算し（一回のフォワードパス）、その語を得てから、ようやく次の語を計算できる。
語と語の間には厳密な前後関係がある。後の語は前の語に依存し、飛ばして計算することはできない。どれだけ計算力が強くても、あなた一人のこの一文は救えない。GPU を積めばモデルはより多くの人を同時にさばけるが、一人のユーザーに対しては、やはり一歩ずつ進むしかない。一文が百語なら、頭から末尾までの計算が百回、列に並んで待つことになる。
だがここに、つけ込めるすき間が隠れている。モデルに、すでに書かれた何個かの語を「検証」させるのと、新しい語を一つ「生成」させるのとでは、かかる計算力はほぼ同じだ。生成は一歩ずつの依存に縛られるが、検証は一度にまとめて一気に並列で照合できる。
前の語が出るのを必ず待たねばならず、一度の完全なフォワードで語が一つ返るだけ。高くつき、しかも直列でしか進めない。
このひとまとまりを一度に投入して並列で照合、計算力 ≈ 一度のフォワード。一気に一連を全部チェックする。
投機的デコードは、このすき間から入り込む手法だ。
先にひとまとめに推測し、まとめて一度に確認
投機的デコードの発想は直感に反する。大規模モデルに律儀に一つずつ書かせるより、足の速い「下書き係」を雇って、後ろの数語を一気に推測させ、その上で大規模モデルにこのひとまとまりが当たっているかをまとめて検証させたほうがいい、というものだ。
K 個の語を検証するコスト ≈ 語を 1 個生成。だから下書き係の推測さえ十分に当たれば、メインモデルは検証を一度するごとに、一気に数語を確定できる。何歩かを一歩にまとめたようなものだ。「推測」という一工程が増えたのに、合計時間はかえって短くなる。
下書き係とは誰で、推測の精度はどう測るのか
この「下書き係」は別途用意した小さなモデルではなく、DeepSeek モデルの学習時にあらかじめ取り付けてある付加モジュールで、MTP（マルチトークン予測）ヘッドと呼ばれる。とても軽く、次に来る数語の確率を同時に予測でき、メインモデルよりずっと速く動く。生まれつき「素早く下書きする」仕事に向いている。
下書き係が推測した語が、メインモデルに認められる割合を受理率ドラフトヘッドが推測した語が、メインモデルの検証を経て認められる割合。ドラフトヘッドとメインモデルの分布がどれだけ近いかで決まり、受理率が高いほど、毎回正味で稼げる有効な語が増える。と呼ぶ。受理率が高いほど、検証 1 回ごとに正味で稼げる語が増え、速度の向上も大きくなる。これは下書き係とメインモデルが「同じことを思いつく」度合いで決まる。
採点は出題より速い。一度にまとめて K 問を出題し、先生がまとめて採点するほうが、1 問出して採点し終えてから次を出すより、ずっと効率がいい。投機的デコードは、速い下書き係に問題をまとめて「出題」させ、大規模モデルに一度で「採点」させるのと同じだ。
MTP-1 はもう使われている、DSpark はどこで速いのか
MTP-1 は DeepSeek-V4 の本番環境ですでに動いている方式で、毎回一歩しか推測しない。一つ推測してメインモデルの検証を待ち、また次を推測する。DSpark はそれをベースに二か所へ手を入れた。
ドラフトヘッドが一度に先の語を数個多く探り、1 回の検証で確定できる語が増える。
「推測」と「検証」を順番待ちからパイプラインに変え、前のバッチを検証している間に、次のバッチをもう推測している。
60–85% の向上は、主に二つ目の手によるものだ。MTP-1 では「推測し終えて検証を待ち、検証し終えてまた推測する」の間に、何もせず空く時間の窓があり、二つの流れが交互に遊んでいた。DSpark はこの窓を埋めた。ドラフトの流れと検証の流れが、時間軸上で重なって走り、互いに待たない。
自動車の生産ライン。前の一台にタイヤを付けている間、次の一台のシャシーはもう塗装に入っている。前の一台が全部終わるのを待ってから次に取りかかったりしない。DSpark は GPU にも同じことをさせる。前のバッチを検証している間に、次のバッチはもう推測を始めていて、マシンは空転しない。
推論の一周、推測から確定まで
ここまでをつなぎ合わせると、DSpark の完全な一周はこう回る。
検証は頭から後ろへ照合する。連続して当たった語はすべて採用し、最初に外れた語に当たった瞬間、そこで打ち切る。誤った位置で、メインモデルはついでに自分が正しいと考える語を一つ与える（この一つもタダで手に入る）。誤った語の後ろで下書き係が推測し続けた部分はすべて破棄し、次の周はこの位置から改めて始める。
この周：当たった語 4 個 ＋ メインモデルがその場で修正した語 1 個で、正味 5 個の語を稼ぎ、かかったのは検証 1 回分のコストだけ。下書き係の推測が正確なほど、緑が増えて破棄が減り、全体はより速くなる。
高速化は結局どれくらいか
あの数字に戻ろう。すでに高速化済みの MTP-1 というベースラインの上で、DSpark は単一ユーザー生成速度をさらに 60〜85% 引き上げた。
この数値は DeepSeek の自己評価で、DeepSeek-V4 の本番環境向け。注意したいのは、比較する両端ともすでに「高速化済み」の状態で、この区間自体が MTP-1 の上にさらに積み上げた増分だという点だ。
これは誰の役に立つのか
これは推論側のシステム最適化で、その価値は二方向に分かれる。ユーザーと、サービス提供側だ。
ユーザーにとって。あなたが目にするのはストリーミング出力で、返答が一文字ずつ飛び出してくる。生成速度が上がれば、一文字ずつ表示されるのを待つ感覚も軽くなる。これは直接体感できる体験の差だ。
サービス提供側にとって。DSpark はモデルの重みを変えないので、既存の DeepSeek-V4 デプロイにそのまま組み込め、移行コストが低い。同じ GPU 群で、より高い同時実行をさばくか、より少ないハードで元のサービス水準を達成できる。
DeepSeek Releases DSpark, a Speculative Decoding Framework That Accelerates DeepSeek-V4 Per-User Generation 60–85% Over MTP-1. 原題 · MarkTechPost / DeepSeek