3行でいうと

  • 投機的デコードは、小さなモデルが数トークン（文章を数える単位）を先に予想し、大きなモデルがまとめて検算して速くする仕組み。
  • 予想が外れても本体が直すので、論文によれば出力の確率分布は本体だけで書いた場合と同じになる。
  • 予想の当たる率が高く、予想役が軽いほど速い。外れ続けたり、計算に余裕がなかったりすると速くならない。
  • Splashの倍率は自社測定。どの仕組みが何倍に効いたかは、公式ブログに書かれていない。

Splashのモデル構成には、本体（約14.1GiB）のほかに、約1.2GiBの小さな補助モデルが入っています。この補助モデルは何をしているのか。「投機的デコード」という仕組みを、論文と実装の資料が読めた範囲で説明します。

Splashの中にあるもの

Hugging Faceのincoai/Qwen3.8-27B-Splashのページには、ファイルの内訳が載っています。

部品 大きさ 説明（ページの記載）
本体 14.1 GiB Qwen3.8-27B、4ビット
補助モデル 1.2 GiB 「DFlash 2」という予想役のモデル
画像を読む部品 0.9 GiB 画像用のエンコーダー
文字の区切り方など 小さい トークナイザーと会話の型

補助モデルについて、ページには次の説明があります。5層の小さなモデルで、本体の途中の状態を読み取り、1回に7トークンを予想します。本体は、それを1回の処理でまとめて検算します。トークンとは、AIが文章を数える単位です。日本語では、おおよそ1〜2文字です。

投機的デコードとは

AIは、文章を1トークンずつ書いています。大きなモデルは、1トークンを出すたびに、数十GBの重みをメモリから読み出します。計算そのものより、読み出しの待ち時間が、速さを決めやすい作りです。

そこで、次のようにします。

  1. 小さなモデル（下書き役）が、先に数トークンを予想する。
  2. 大きなモデル（本体）が、予想された数トークンを、1回の処理でまとめて検算する。
  3. 合っているところまでは採用する。最初に外れたところで、本体が自分の答えに差し替える。
  4. そこから、また1に戻る。

例えるなら、先輩が書く文章を、新人が先回りして下書きします。先輩は、下書きをまとめて読み、合っていれば採用します。1語ずつ書くより速いのは、読むほうが、書くより一度にたくさんできるからです。

ここで大事なのは、検算が本体の仕事だという点です。下書きが外れても、本体が直します。下書きが下手だと、速くならないだけです。

論文では何が言われているか

最初の論文は、Googleの研究者による「Fast Inference from Transformers via Speculative Decoding」（Leviathanら、2022年11月、ICML 2023）です。ほぼ同じ時期に、DeepMindの研究者が、Chinchilla（700億パラメータ）を使って「Speculative Sampling」（Chenら、2023年2月）を出しています。

論文 試したモデル 論文の報告
Leviathanら T5-XXL 標準の実装の2〜3倍。出力は変わらない
Chenら Chinchilla（70B） 分散環境で2〜2.5倍。品質は損なわれない
EAGLE（Liら、2024年） LLaMA2-Chat 70B 2.7〜3.5倍。生成される文章の分布を保つ

いずれも、論文の著者自身の測定です。Leviathanらの論文では、翻訳（英独）で、温度0のとき3.4倍、温度1のとき2.6倍でした。温度とは、答えにばらつきを持たせる度合いです。ばらつきがあるほうが、少し効きにくくなっています。

なぜ「品質が変わらない」と説明されるのか

理由は、検算の決まりにあります。論文によると、下書きの1トークンごとに、本体の確率と見比べます。本体の確率が下書き以上なら、採用します。そうでなければ、一定の確率で却下して、本体の確率から計算した補正の分布で、引き直します。この決まりで、最終的な出力の確率分布が、本体だけで書いた場合と数学的に同じになる、と論文は証明しています。

つまり、「たまたま似た答えが出る」のではなく、「本体の答えと同じ確率で出る」ように作られています。Splashのページにも、速さは変わるが出力の分布は変わらない、という趣旨の記述があります。LM Studioの資料も、本体が「自分が出したはずのトークンだけ」を採用するので、品質は下がらないと説明しています。

注意点が2つあります。

どんなときに速くなるか

Leviathanらの論文には、速さを決める2つの数字があります。

  • 下書きの採用率（α）：下書きが本体と合う確率です。論文では、サイズが2桁違うモデルの組み合わせで、0.5〜0.9くらいと報告されています。
  • 下書きの費用（c）：下書き役が1回動く時間が、本体の何割かという比です。

1回の本体の処理で得られるトークン数の期待値は、(1−α^(γ+1))÷(1−α)です。γは、1回に下書きするトークン数です。数字を入れてみます。以下は筆者の計算です。

採用率α 下書きの数γ 本体1回あたりに進むトークン数
0.5 4 約1.9
0.8 4 約3.4
0.9 7 約5.7

採用率が高く、下書きが安いほど、速くなります。下書きに「ちょうどいい」賢さが必要なわけです。

次のような作業は、当たりやすいとされています。LM Studioの資料は、数学の問題のような答えが決まりやすい作業は効きやすく、物語のような創作は効きにくいと書いています。llama.cppの資料も、コードの書き直しのように繰り返しが多い作業で効く、としています。

どんなときに効かないか

読めた資料から、次の場合がまとめられます。

実装での扱い
ソフト 読めた範囲での扱い
llama.cpp 公式の資料に、下書きモデル方式のほか、EAGLE-3、DFlash、モデル内のマルチトークン予測（MTP）、n-gram（過去の文章のパターンを使う方式）が並ぶ。下書きの数は、標準で最大3
mlx-lm（MLX） 生成のコマンドに、--draft-model（下書きモデル）と--num-draft-tokens（標準で3）の引数がある
LM Studio 設定で下書きモデルを選ぶ方式。語彙が同じであることなどの条件を、資料で説明している
Splash 投機的デコードが標準の仕組みで、選択式ではない（公式ブログの記載）

llama.cppとMLXでは、投機的デコードは、使う側が下書きモデルを自分で選ぶ、後付けの機能のような扱いです。Splashは、モデルごとに専用の下書き役を付けて、最初から組み込んでいる点が違います。ただし、LM StudioのMLXとllama.cppのどちらで使えるかは、読んだ資料に書かれていませんでした。

MoEが速い理由

MoE（Mixture of Experts）は、投機的デコードとは別の速くする方法です。モデルの中に、多数の「専門家」を並べて、1トークンごとに一部だけを動かします。

Hugging Faceのページによると、Qwen3.6-35B-A3Bは、全体が350億パラメータで、実際に動くのは30億です。専門家は256個あり、1トークンで動くのは、選ばれた8個と、常に動く共通の1個です。

1トークンで読み出す重みが少なければ、読み出しの待ち時間も短くなります。ローカルの速さは、メモリの読み出しに左右されやすい、というのが前の記事の話でした。これは筆者の整理です。ただし、全体の重みは、メモリに置いておく必要があります。速くなるのは、動かす量で、置く量ではありません。

Splashの公式ブログには、MoEモデルの専門家向けの専用の計算部品（カーネル）があると書かれています。

Splashは何を説明しているか

公式ブログとHugging Faceのページから、読めた範囲だけを整理します。

一方、読めた範囲では、どの仕組みが何倍に効いたかは、公式ブログに書かれていません。投機的デコードだけで何倍、計算部品で何倍という分解は、載っていないのです。ここから推測はしません。公式のページに数字がない以上、「2倍のうち、半分が補助モデルのおかげ」のような言い方はできません。

また、DFlash 2が、どう学習され、どのくらい当たるのかも、ブログの本文には詳しい説明がありません。別のページ（incoai/Qwen3.8-27B-DFlash2）では、ブロック拡散という方式で、1回に1ブロックのトークンを予想する下書き役と説明されています。ただし、このページの大きさは20億パラメータ（BF16）で、Splashの1.2GiBとは表記が違います。両者の関係は、読んだ資料からは確かめられませんでした。

気をつけること

出典

更新履歴