大規模言語モデルの推論が「待たされる」とき、ボトルネックは賢さではなく出力の作り方にある。トークンを1個生成するたびにモデル全体を1回走らせる。長い返答になるほどこの往復が積み上がり、しかも1回あたりGPUはほとんど遊んでいる。DeepSeekが6月27日にGitHubで公開したDeepSpecと、その中核アルゴリズムDSparkは、ここを狙い撃ちにした。モデルの重みも賢さも一切変えずに、同じ出力をより速く吐かせる話だ。
なぜ1トークンずつだと遅いのか
自己回帰生成（autoregressive、前のトークンを見て次の1個を決める仕組み）では、1回の順伝播で進むのは1トークン。問題は、この処理がGPUの計算力ではなくメモリ帯域で詰まる点にある。少人数に配信しているサーバーほど演算ユニットが空き、それでも待ち時間は長い。DeepSeekは社内研究で、この逐次出力を「AIの提供における第一のボトルネック」と表現している（South China Morning Post）。
打開策として知られるのが投機的デコーディング（speculative decoding）だ。安価な「下書きモデル」に次のkトークンをまとめて推測させ、本体（target）モデルがそのk個を1回の並列順伝播でまとめて検証する。先頭から本体の答えと一致する分だけ採用し、外れた所で打ち切る。採用されたトークンは本体が自分で生成した場合と数学的に同一になるので、品質は落ちない。1回の高コストな順伝播で複数トークン進めるぶんだけ速くなる、という理屈である。速さの指標は「採択長」（accepted length、検証1回あたり平均何トークン通るか）で、これが伸びるほど速い。
DSparkがEagle3やDFlashと違うところ
下書きモデルには既に有力なやり方がいくつもあり、DeepSpecはそれらを同じ土俵に載せている。リポジトリにはDSparkに加え、現行の代表格であるEagle3と、DeepSeek自身の先行手法DFlashが実装されている。両者の弱点は対照的だ。
| 下書きの作り方 | 特徴 | 弱点 |
|---|---|---|
| Eagle3 | トークンを逐次に下書き | 精度は高いが下書き自体が遅い |
| DFlash | ブロック全体を一括並列生成 | 速いが各トークンが互いを無視し、後半が外れやすい |
| DSpark | 並列でブロック生成＋隣接依存だけ補う | 速さと採択長を両立 |
DSparkの肝は、ブロックを並列で一気に出しつつ、その上にMarkovヘッド（既定でランク256）またはRNNヘッドという軽量なヘッドを1枚載せ、隣り合うトークン同士の遷移確率だけを明示的に持たせる点にある。一括生成の速さを残したまま、「後ろのトークンが前を無視してちぐはぐになる」破綻を抑える、という発想だ。Markovヘッドは短い系列・高スループット向き、RNNヘッドは長い系列でやや有利、と使い分ける。さらに各候補トークンに「本体に採択される確率」を見積もるconfidenceヘッドが付く。
この設計の差は数字に出ている。DeepSeekの計測では、採択長がEagle3比で26.7〜30.9%、DFlash比で16.3〜18.4%伸びた（MarkTechPost）。比較の基準になっている「MTP-1」は、DeepSeek-V3で導入されたMulti-Token Predictionヘッドを下書き1段として使う構成を指す。
採択長だけでは終わらせない設計
個人的に面白いと思ったのは、オフラインの採択長で勝っても本番のスループットに直結するとは限らない、という現実をDSparkが正面から扱っている点だ。検証は本体モデルを動かすので、無闇に長く下書きを検証すれば本番では逆に詰まる。
そこでDSparkは、GPUクラスタの同時負荷・候補トークンのconfidence分布・推論エンジンのスループット曲線を見て、リクエストごとに検証するトークン長を動的に決める負荷対応スケジューラを持つ。GPUが空いていれば多く検証し、混んでいれば控える。DeepSeekはこれを「計算需要に応じて検証量を動的に調整する」仕組みと説明している。本番V4での主張値は、1ユーザーあたりの生成がMTP-1基準でV4-Flashが60〜85%、V4-Proが57〜78%高速化、混雑時の集約スループットは最大約400%増、というものだ。狙いは速度だけでなく、「より大きく強力なチップへの依存を減らす」コスト面にもあると同社は述べている。
公開されたものと、主張のままのもの
ここは冷静に切り分けたい。MITライセンスで公開されたDeepSpecは、データ準備・複数GPUでの下書き学習・評価までを通す本物のコードベースで、実際に再現できるのはQwen3（4B/8B/14B）とGemma-4 12Bを本体に据えた構成だ。評価はgsm8k、math500、aime25、humaneval、mbpp、livecodebench、mt-bench、alpaca、arena-hard-v2の9本で回る。一方、見出しを飾るV4の60〜85%という production 値はDeepSeekの論文・運用に基づく主張で、公開リポジトリからそのまま追試できる部分ではない。チェックポイントDeepSeek-V4-Pro-DSpark等は既存V4の重みに下書きモジュールを足したものとされる。本稿執筆時点で、これらの数値に対する第三者の独立検証は確認できていない。
自前でQwenやGemmaをホストしている側からすると、ありがたいのは本体を再学習せず下書きだけ足せる点だ。手順自体は素直で、README記載のコマンドはこの程度に収まる。
git clone https://github.com/deepseek-ai/DeepSpec
cd DeepSpec
python -m pip install -r requirements.txt
bash train.sh # 下書きモデルの学習
bash eval.sh # 9ベンチでの評価
新モデルでも巨大文脈でもなく、地味な「サービングの最適化」だ。それでも、賢さ競争が一段落して各社が推論コストとGPU逼迫に頭を抱えている今、重みを触らず同じ品質のまま速くなる手が、しかも他社のオープンモデルにも効く形でMITで出てきた意味は小さくない。再現可能なのがQwen/Gemma側である以上、まず手元のオープンモデルで採択長がどれだけ伸びるかを測るのが、この公開のいちばん健全な使い方だろう。