大規模モデルはなぜ一文字ずつしか吐き出せないのか

大規模モデルが文章を生成するとき、単語を1つずつ順番に吐き出していく。1つの単語を吐き出すたびに、モデル全体を最初から最後まで1回計算しなければならない(1回のフォワードパス)。その単語を得て初めて、次の単語を計算できる。

単語同士は厳密な前後関係にあり、後の単語は前の単語に依存していて、飛ばして計算することはできない。計算力がどれだけ強くても、あなた1人分のこの一文は救えない。GPUを積み増せばモデルが同時によりの多くの人にサービスできるようになるが、単一ユーザーに対しては、やはり一歩ずつ進むしかない。一文が100単語なら、それは最初から最後までの計算を100回、並んで待つということだ。

だが、ここに得をできる隙間が隠れている。モデルに「すでに書かれた複数の単語」を検証させるのと、「新しい単語」を1つ生成させるのとでは、必要な計算力はほぼ同じなのだ。生成は一歩ずつの依存関係に縛られているが、検証は一気に一括で複数を並列に照合できる。

投機的デコーディングとは、まさにこの隙間から入り込む手法だ。

先にひとまとめ推測し、あとで一度に確認する

投機的デコーディングの発想は常識に反する。大規模モデルにきちんと1つずつ書かせるのではなく、まず高速に走れる「草稿係」を用意し、一気に後続の複数の単語を推測させ、それから大規模モデルにこのバッチをまとめて検証させて、当たっているかどうかを一度に確認させるのだ。

「草稿係」とは何者か、その精度はどう測るか

この「草稿係」は別に用意した小型モデルではなく、DeepSeekモデルの訓練時にあらかじめ組み込まれている追加モジュールで、MTP(Multi-Token Prediction、複数トークン予測)ヘッドと呼ばれる。とても軽量で、後続の複数の単語の確率を同時に予測でき、主モデルよりずっと速く動くため、「素早い草稿作り」という仕事に生まれつき向いている。

草稿係が推測した単語のうち、主モデルに認められた割合を受理率草稿ヘッドが推測した単語が主モデルの検証を経て認められた割合。草稿ヘッドと主モデルの分布がどれだけ近いかによって決まり、受理率が高いほど各ラウンドで正味増える有効単語数が多くなる。と呼ぶ。受理率が高いほど、検証1回あたりで正味得られる単語が多くなり、速度向上も大きくなる。これは草稿係と主モデルが「同じことを考えている」度合いに左右される。

MTP-1はすでに使われているのに、DSparkはどこがさらに速いのか

MTP-1はDeepSeek-V4の本番環境ですでに稼働している方式で、各ラウンドで1ステップしか推測しない。1つ推測しては主モデルの検証を待ち、それから次を推測する。DSparkはこの方式に2つの手を加えた。

1回の推論、推測から確定まで

これまでの話をまとめると、DSparkの1つの完全なサイクルはこう回る。

検証は先頭から順に照合していく。連続して当たった単語はすべて採用し、最初に外れた単語に出会ったところで打ち切る。外れた位置では、主モデルがついでに自分が正しいと考える単語を1つ提示する(これも棚ぼたで手に入る)。外れた単語より後ろに草稿係が推測した部分はすべて破棄され、次のラウンドはこの位置からやり直しになる。

このラウンドでは、当たった4単語+主モデルがその場で訂正した1単語で、正味5単語を得られた。かかったのは検証1回分のコストのみ。草稿係が正確に推測できるほど緑が増え、破棄が減り、全体としてより速くなる。

高速化はどのくらいか

冒頭の数字に戻ろう。すでに高速化されているMTP-1というベースラインの上で、DSparkは単一ユーザーの生成速度をさらに60〜85%引き上げた。

この数値はDeepSeekの自己評価であり、DeepSeek-V4本番環境を対象としたものだ。注意すべきは、比較する両端がすでにどちらも「高速化済み」の状態であり、この区間自体がMTP-1の上にさらに積み増した増分だという点である。

これは誰にとって役立つのか

これは推論側のシステム最適化であり、実用面での価値はユーザーとサービス提供者の両方に分かれる。

ユーザーにとって。目に見えるのはストリーミング出力で、応答が一文字ずつ画面に浮かび上がる。生成速度が速くなれば、それに伴い一文字ずつ表示される際の待たされ感も軽くなる。これは直接体感できる違いだ。

サービス提供者にとって。DSparkはモデルの重みを変更しないため、既存のDeepSeek-V4デプロイにそのまま組み込める。移行コストが低い。同じGPU群で、より高い同時接続数を支えるか、より少ないハードウェアで従来と同水準のサービスを実現できる。

DSparkはモデル自体には手を加えず、「文字を吐き出す」やり方だけを変えて、単一ユーザーが応答を受け取る速度を60〜85%引き上げた。

肝心なのは「何と比べているか」をはっきり見ることだ。「高速化なし」と比べているのではなく、V4の本番環境ですでに稼働しているMTP-1(既存の高速化方式)と比べている。つまり、すでに高速化された土台の上で、さらに60〜85%を絞り出したということになる。

疑問が湧く：「推測」という工程を増やしたのに、なぜかえって速くなるのか?次の図でわかる。

コツは常識に反する事実に隠れている。大規模モデルに「すでに書かれた複数の単語」を検証させるのと、「新しい単語」を1つ生成させるのとでは、かかる労力がほぼ同じなのだ。そこで先に高速に動く「草稿係」にひとまとめ推測させ、大規模モデルが一気に検証して、当たったものを全部残す——この「先に推測、後で検証」というやり方を投機的デコーディングと呼ぶ。

草稿係は別に用意した小型モデルではなく、DeepSeekの訓練時にモデルにあらかじめ組み込まれている軽量な追加モジュールで、生まれつき高速に動き、草稿作りの仕事に特化している。検証は先頭から順に照合していき、連続して当たったものは全部採用、外れたものに出会ったところで打ち切り、次のラウンドはやり直す。草稿係が正確に推測するほど、残る単語が増え、速くなる。

「60〜85%速くなった」と言われても抽象的だ。同じ回答を2つの方式でそれぞれ何秒かかるかに置き換えてみると、実感がわく。

この数値はすべてDeepSeek社内テストによるもので、DeepSeek-V4本番環境を対象としており、第三者による独立再現は確認されていない。