AIの文章生成を、中身を変えずに約5倍速くする新手法「D3D」(arXiv:2611.06425)の図解。下書き係と検証係を同時に走らせる仕組みを、予備知識なしで読めるように動く図で追います。
この記事は、論文「D3D: Decoupled Diffusion Drafting for Asynchronous Speculative Decoding」(Baoyou Chen ほか、2026年11月、arXiv:2611.06425)を、予備知識なしで読めるように図解したものです。ひとことで言うと 「AIの文章生成を、中身を変えずに約5倍速くする方法」 の話です。
文章生成AI(LLM = 大規模言語モデル。大量の文章から「次に来る言葉」を学んだAI)は、文章を一気に書いているように見えて、実はトークン(単語や文字のかけら。AIが文章を扱う最小単位)を1つずつ順番に出しています。
図の左の箱が、答えを書く本番のモデルです。この記事ではターゲットモデルと呼びます。
1トークン出すたびに、巨大なモデル全体を1回計算します。この「前から1つずつ」の書き方を自己回帰(AR)と言います。
次のページで、続きのトークンが出てくる様子を見てみましょう。
6トークン書くには6回、1000トークンなら1000回の計算が必要です。しかも「前のトークンが決まらないと次が書けない」ので、計算を横に並べて同時に走らせることもできません。
モデルが大きいほど、1回の計算は重くなります。賢いモデルほど返事が遅いのはこのためです。
この論文のゴールは、出てくる文章を一切変えずに、この待ち時間を数分の1にすることです。
ここで使われるのが投機的デコーディング(speculative decoding。「たぶんこう続くだろう」と先読みして、あとから答え合わせをする高速化の手法)です。
登場人物が1人増えます。
図では、ドラフターが「今日」の続きを5トークン分まとめて予想しました。この時点ではまだ予想で、正式な出力ではありません。
ここが投機的デコーディングのいちばん大事なところなので、3ページかけてゆっくり見ます。
実は、LLMに文を入力すると、最後の位置だけでなく、すべての位置で「この次に来るトークン」の答えが同時に出てきます。 ふだんの生成では、いちばん右の答え1個しか使っていないだけです。
そこで検証では、確定済みの「今日」に下書きの5個をつなげて、6トークンをまとめてターゲットに渡します。計算は1回です。すると図の下の段のように、位置ごとの答えが並んで出てきます。
(最後の「よ」の位置にも答えは出ます。下書きが全部当たったときに使う、おまけの1個です。次のページからは省きます)
この時点では、まだ答えを並べただけです。下書きと合っているかどうかは、まだ見ていません。
なぜ1回の計算で、位置ごとに別々の答えが出せるのでしょうか。
LLMには、各位置は自分より左(前)のトークンしか見てはいけないという決まりが組み込まれています(因果マスクと呼ばれる目隠し。学習のときに、答えを先に見てしまうカンニングを防ぐための仕組みです)。
だから、6トークンをまとめて入力しても、中で起きているのは次の5つの計算です。
| 見ている範囲 | 出てくる答え |
|---|---|
| 今日 | は |
| 今日 は | いい |
| 今日 は いい | 天気 |
| 今日 は いい 天気 | です |
| 今日 は いい 天気 だ | ね |
図の水色の帯が「見ている範囲」、右端の青いトークンがその行の答えです。前のページで下に並んでいた答えが、それぞれの行の右端に移動しました。
ポイントは、どの行も「左にあるトークンが正しいとしたら、次は何か」という条件つきの答えだということです。
1トークンずつ5回計算するのと、中身はまったく同じです。同じ計算を、1回にまとめてやっているだけです。
答えが出そろったら、あとは見比べるだけです。図では、各行の答え(右端)が、対応する下書き(上の段)のちょうど真下に来ています。
上の行から順に見ていきます。
4行目の「です」は捨てません。この行が見ている「今日 は いい 天気」はすべて確定済みなので、「です」はターゲットの正式な答えです。これを「だ」の代わりに置きます。
5行目は違います。この行は、間違いだった「だ」を見て出した答えです。前提が崩れているので使えません。最初に外れた位置から後ろを全部捨てるのは、このためです。
結果、一致した3個とターゲットの「です」で、計算1回で4トークン進みました。
下書きがどこまで当たるかは、見比べるまで分かりません。当たった分だけ得をする、という仕組みです。
「5個ぶんをまとめて計算するなら、結局5倍の手間では？」と思った人は鋭いです。掛け算の総量は、たしかに5個ぶんに増えます。 増えないのは「かかる時間」のほうです。
図は、横幅が「かかる時間」、面積が「計算の量」を表しています。前のページの5行が、上の段では横に5回並び、下の段では1つの箱に縦に積まれています。
LLMの計算の正体は、巨大な数の表(行列)どうしの掛け算です。入力は「トークンの数 × 数千個の数値」の表になっていて、モデルの重み(学習で身につけた数値のかたまり)を全トークンにまとめて掛けます。5トークン入れれば、5個ぶんの答えが一度に出ます。GPUは、こういう並んだ計算を同時に処理するのが得意な部品です。
1個ずつ書くときにこれができないのは、2個目の入力が1個目の答えで決まるからです。順番に待つしかありません。検証では、下書きのおかげで入力が最初から全部そろっているので、並べて一気に計算できます。
ターゲットの重みは数十億個の数値で、データにすると十数GB以上あります。1回の計算のたびに、これを全部メモリから読み出します。1トークンだけ計算するとき、GPUの計算能力は余っていて、時間を決めているのは主にこの読み出しだと言われています(実際には、ほかの細かい待ち時間も混ざります)。
エレベーターにたとえると、1人ずつ5往復するか、5人まとめて1往復するかの違いです。
GPUの余力には限りがあります。あとのページに出てくる「ブロックを長くしすぎると、かえって遅くなる」「同時に処理する依頼が増えると、速度向上が小さくなる」は、この限界が見えている例です。
(このページは論文の外の一般的な補足です。参考：SARATHI の3章に、1トークンずつの生成ではGPUの計算能力が余ることの測定があります)
ここまでの答え合わせを検証と呼びます。ルールを整理すると3つです。
「は」「いい」「天気」が受理、「だ」が外れて「です」に差し替えられました。ターゲットの計算1回で4トークン進んでいます。1ラウンドで進んだトークン数を受理長(記号は τ、タウ)と呼びます。
大事なのは、最終的な文章がターゲットだけで書いた場合と変わらないことです(確率的に言葉を選ぶ設定でも、出力の確率分布が変わらないことが保証されています)。この性質をロスレス(品質を落とさない)と言います。下書きが外れても、損をするのは時間だけです。
速さを決めるのは3つ。受理長・下書きにかかる時間・検証にかかる時間です。この3つが、このあと何度も出てきます。
下書きの作り方にも種類があります。
(拡散モデル = ノイズや伏せ字で隠したデータを元に戻す練習をしたモデル。画像生成でおなじみの仕組みを文章に応用したものです)
拡散型の代表が DFlash です。DFlashは下書きの精度を上げるために、ターゲットモデルの隠れ状態(モデルが文を読みながら内部に作る数値のメモ。文脈の理解が詰まっている)を借りています。
ここに落とし穴があります。新しく確定したトークンの隠れ状態は、検証が終わるまで手に入りません。 そのため
下書き → 検証 → (隠れ状態が届く) → 下書き → 検証 → …
と、2つのモデルが交互に相手を待つことになります。図の紫の矢印がその「待ち」です。1ブロックの中は並列に書けても、ラウンド同士は一列に並んだままです。
D3D(Decoupled Diffusion Drafting = 切り離された拡散ドラフティング)は、この紫の矢印をなくします。
D3Dのドラフターが読むのは確定済みのトークン列だけです。ターゲットの隠れ状態は一切使わず、文脈の理解は自分でやります。こういう自立したドラフターを、論文はスタンドアロンと呼んでいます。
すると、ターゲットが検証している間に、ドラフターは次のブロックの下書きを進められます。図のオレンジの棒が青い棒の真下にもぐり込み、全体が左に詰まりました。この「相手を待たずに並行して進める」方式が非同期(asynchronous)です。
下書きの時間が検証の時間より短ければ、下書きのコストは検証の裏に完全に隠れます。
でも、疑問が残ります。検証の結果がまだ分からないのに、どこから次を書けばいいのでしょうか？
検証の結果は「何個目まで受理されたか」と「外れた位置にターゲットが何を置いたか」で決まります。パターンは限られているので、全部に対して続きを用意してしまおうというのがD3Dの作戦です(検証結果を先読みして下書きを準備しておく、という先行研究 SSD の考え方を受け継いでいます)。
1ブロックは16トークンです。先頭の1つはアンカー(すでに確定している、足がかりのトークン)で、残り15個が下書きです。
用意する続きは次のとおりです。
図では、外れる位置ごとに2本ずつのバーが階段のように並んでいます。
続きの22+1ブロックに、いま検証中のブロックを加えて、合計 24ブロック × 16 = 384トークン。これを1本の入力に詰め込み(パック)、ドラフターは1回の計算でまとめて処理します。
なぜ1回で済むのでしょうか。
(プロンプト = ユーザーがAIに渡した質問や指示の文)
階段状だったバーが、1つの束にまとまりました。ターゲットが左で検証している、まさにその間に、ドラフターは右でこの束を処理します。
検証が終わりました。例として「5個受理、6個目で外れ」だったとします。
ターゲットが6個目に置いたトークンが、用意しておいた候補のどちらかと一致すればヒットです。「6個目で外れた場合」の下書きがすでに手元にあるので、ドラフターを待たずに、すぐ次の検証を始められます。
使わなかった残りの下書きは捨てます。もったいなく見えますが、ターゲットが検証している間の「空き時間」に、別のGPUで作ったものです。全体の時間は延びません。
(GPU = AIの計算を担当する部品。D3DはターゲットとドラフターをGPU 1枚ずつに載せ、計2枚で同時に動かします)
用意が外れることもあります。
この場合はミスです。ドラフターが、確定した文から改めてブロックを書くのを待ちます。その回だけ、従来の「下書き → 検証」の順番待ちに戻るわけです。
論文の設定(外れ位置11か所 × 候補2つ)では、ヒット率は 71.3% でした(数学の難問を集めたベンチマーク AIME25 での測定。ベンチマーク = 性能を比べるための共通のテスト問題集)。
| 設定 | 用意するトークン | ヒット率 | 速度 |
|---|---|---|---|
| 外れ位置11か所 × 候補2つ | 384 | 71.3% | 約5.0倍(最良) |
| 外れ位置15か所 × 候補2つ | 512 | 78.3% | 下がる |
| 外れ位置11か所 × 候補5つ | 912 | 81.8% | 下がる |
用意を増やすとヒット率は上がります。でもパックが大きくなり、下書きそのものが遅くなって、検証の裏に隠れきれなくなります。「当たる確率」と「下書きの速さ」の綱引きです。
ここまで読んで、「まとめて計算できるなら、下書きもコードを書き換えて何行か同時に計算すれば済むのでは？」と思った人がいるかもしれません。
結論から言うと、下書きのほうは、それでは動きません。専用の学習が必要です。 3ページかけて理由を見ます。
まず、検証のときの計算をもう一度見てください(図)。
どの行も、矢印の左側の入力がすべて埋まっています。オレンジの「は」「いい」「天気」は、ドラフターが先に書いてくれたものです。入力がそろっているので、4行を並べて同時に計算できます。
これは計算の並べ方を工夫しているだけです。ターゲットモデルは、ふだんと同じ「左を見て、次の1個を当てる」仕事をしています。だから検証する側のモデルには、学習し直しは一切要りません。
同じことを、下書きを作る側でやろうとするとどうなるでしょうか。
手元にあるのは「今日」だけです。1行目は問題ありません。「今日」を見て「は」を出せます。
困るのは2行目からです。2行目の入力は「今日 は」のはずですが、その「は」は、いままさに1行目で計算している最中です。同時に計算したいのに、入力がまだ存在しません。
仕方がないので、空いている場所には伏せ字(「ここはまだ分からない」という印の特別なトークン。図の灰色の「？」)を入れて計算することになります。
ところが、ふつうのLLMは「本物のトークンが左に並んでいる状態で、次の1個を当てる」練習しかしていません。伏せ字が並んだ入力は一度も見たことがないので、コードだけ書き換えて同時に計算しても、2個目以降はでたらめが出ます。
足りないのは計算の速さではありません。「伏せ字の並びを見て、中身を当てる」という能力そのものです。
入力がないなら順番に作ればいい、という素直な方法です。小さいモデルが1個書き、それを入力に足して次の1個を書く。これを繰り返します。
「ふつうの投機的デコーディング」はこの形です。大きいモデルと、同じ系列の小さいモデルが手元にあれば、すぐに試せます。
伏せ字から中身を当てる練習を、専用にさせる方法です。これが拡散ドラフターで、D3Dもこちらです。
論文では、メインのドラフターの学習に約142万件の教材と、360GPU時間(高性能GPU 2枚)をかけています。「D3Dで5倍速くなる」のは、この学習を済ませたドラフターが手元にある場合の話です。
次のページから、その練習の中身(学習①・②)を見ていきます。
隠れ状態を借りないぶん、ドラフター自身が賢くなければいけません。そこでD3Dは、ターゲットモデルが実際に書いた回答(約142万件の質問に対するもの)を教材にして、ドラフターを鍛えます。
練習問題はこう作ります。
ブロックの中では、前後どちらの位置を見てもかまいません(双方向の注意。注意 = アテンション = どの位置の情報を参考にするかを決める仕組み)。
1つの回答からアンカーを128か所とり、まとめて練習します。本番の「パック」と同じ形です。
もう1つの工夫は出発点です。ドラフターをゼロから育てるのではなく、すでに言葉を知っている学習済みモデル(Qwen3)から始めます。ゼロから始めた場合と比べて、受理長は約4.5 → 約9.8と2倍以上になりました(算数の文章題ベンチマーク GSM8K での比較)。
検証のルールを思い出してください。最初に外れた位置から後ろは、全部捨てられます。 つまり1個目を外すと、2〜15個目がどれだけ正確でも無意味です。
そこでD3Dは、採点(損失 = 予想がどれだけ外れたかを表す点数。これが小さくなるように学習する)に、位置ごとの重みをつけます。
j は何個目の下書きか、\gamma は減り方のゆるさを決める定数です。図の紫の棒がその重みで、前ほど高く、後ろへ行くほど低くなります(棒の高さはイメージです)。
もう1つ、伏せ字にしていない回答に対して、ふつうのLLMと同じ「次のトークンを当てる」練習(AR損失)も同時に行います。
\mathcal{L}_{\mathrm{diff}} が伏せ字当ての損失、\mathcal{L}_{\mathrm{AR}} が次トークン当ての損失、\lambda は2つのバランスです。ターゲットの隠れ状態に頼らず、自分の力で文脈を読み取る力を保つための練習です。
| λ | 受理長(GSM8K) | 受理長(HumanEval) |
|---|---|---|
| 0(補助なし) | 7.89 | 5.86 |
| 0.5 | 8.05 | 6.02 |
| 1.0(採用) | 8.29 | 6.25 |
| 1.5 | 8.25 | 6.19 |
(小さめのドラフターで試した比較実験の値です)
D3Dのメインのドラフターは、約82億パラメータ(パラメータ = モデルが学習で調整する数値。多いほど賢いが、計算は重い)、36層(層 = 計算の段。入力はこの段を順番に通って処理される)。下書き係としてはかなり大きなモデルです。
大きいドラフターほど、下書きはよく当たります。
| ドラフター | パラメータ | 受理長(MATH-500) |
|---|---|---|
| DFlash(従来) | 23億 | 6.87 |
| D3D-1.7B | 20億 | 8.16 |
| D3D-4B | 44億 | 9.45 |
| D3D-8B | 82億 | 9.89 |
ふつう、大きいドラフターは遅くて使い物になりません。でも非同期なら、下書きが検証より先に終わりさえすれば、その重さは表に出ません。
裏を返すと、384トークンのパックを処理する時間が検証の時間を超えると、ヒットしても待ちが出てしまいます(図の下の棒。長さはイメージです)。
そこで最後の工夫です。当たりやすさをほとんど落とさずに、ドラフターを軽くします。
枝刈り(プルーニング = モデルの一部を取り除いて軽くすること)の手順はこうです。
先生が間違えている位置では、正解のほうが必ず少しだけ優勢になるように先生の答えを補正する、という細かい工夫も入っています。
一般的な「精度」ではなく、速さに直結する「受理長」を見ながら削るのがポイントです。
いよいよ成績です。棒の高さは「下書きなしで1トークンずつ書いた場合の、何倍速いか」。7種類のベンチマーク(数学3つ、プログラミング3つ、雑談1つ)の平均です。
| 手法 | 使うGPU | 平均の速度向上 | 平均の受理長 |
|---|---|---|---|
| SSD | 2枚 | 1.84倍 | 3.25 |
| EAGLE-3 | 1枚 | 2.88倍 | 4.56 |
| DFlash | 1枚 | 4.03倍 | 5.96 |
| PARD-2 | 2枚 | 4.08倍 | 5.62 |
| DSpark | 1枚 | 4.44倍 | 5.59 |
| D3D | 2枚 | 5.00倍 | 7.88 |
GPU 1枚の手法は「下書き → 検証」を交互に行う方式、2枚の手法はターゲットとドラフターを別々のGPUに載せる方式です。
受理長7.88は、「ターゲットの計算1回で、平均8トークン近く進む」という意味です。
| ベンチマーク | 種類 | 速度向上 | 受理長 |
|---|---|---|---|
| GSM8K | 数学 | 6.71倍 | 9.87 |
| MATH-500 | 数学 | 6.21倍 | 9.84 |
| AIME25 | 数学 | 5.11倍 | 7.98 |
| HumanEval | コード | 5.19倍 | 7.79 |
| MBPP | コード | 4.70倍 | 7.31 |
| LiveCodeBench-v6 | コード | 4.44倍 | 6.68 |
| MT-Bench | 雑談 | 2.68倍 | 5.71 |
数学のように次の展開が読みやすい文章ほどよく当たり、自由な雑談では伸びが小さくなります。7つのうち5つでD3Dが最速でしたが、LiveCodeBench は DSpark と同じ4.44倍、MT-Bench は DSpark(3.17倍)のほうが上でした。
ターゲットを4倍大きい Qwen3-32B に替えると、棒が伸びて差が開きます。
| 手法 | 平均の速度向上 | 平均の受理長 |
|---|---|---|
| EAGLE-3 | 3.46倍 | 5.08 |
| SSD | 3.54倍 | 4.22 |
| DFlash | 3.67倍 | 4.82 |
| PARD-2 | 3.88倍 | 5.38 |
| DSpark | 3.92倍 | 5.48 |
| D3D | 5.71倍 | 7.73 |
最高は GSM8K の 7.48倍。こちらは7つのベンチマークすべてでD3Dが最速でした(ただし MT-Bench は3.01倍で、DFlash の3.00倍とほぼ並んでいます)。
ターゲットが大きいほど検証に時間がかかるので、その裏で下書きを済ませる余裕が増える、と読めます(これは筆者の解釈です)。
実際のサービスでは、多数の依頼を同時に処理します。小さめのドラフター(D3D-1.7B)で試した結果です(MATH-500、ターゲットは Qwen3-32B)。
| 同時に処理する依頼の数 | 1秒あたりのトークン数 | 速度向上 |
|---|---|---|
| 1 | 154 | 6.1倍 |
| 4 | 470 | 4.8倍 |
| 8 | 745 | 3.9倍 |
| 16 | 864 | 2.7倍 |
全体の処理量は増えていきますが、1件あたりの速度向上は小さくなります。
これらを支えているのが、「前の位置ほど重く採点する」学習と、ふつうの次トークン予測を混ぜる補助の練習でした。
論文自身が挙げている制約です。
| ブロックの長さ | 速度向上(MATH-500) | 受理長 |
|---|---|---|
| 8 | 4.58倍 | 6.26 |
| 16(採用) | 5.55倍 | 9.89 |
| 32 | 3.16倍 | 12.39 |
長くするほど1回で進む量は増えますが、パックが重くなり、かえって遅くなります。
同じドラフターは、長いプロンプトの中から重要な部分だけを選んでターゲットに読ませる、という使い方もできるそうです(論文の付録)。
---
出典：Baoyou Chen, Ruiqiao Mei, Guancong Lin, Tao Song, Weihao Yuan, Qun Liu, Siyu Zhu「D3D: Decoupled Diffusion Drafting for Asynchronous Speculative Decoding」arXiv:2611.06425(2026年11月)
この記事の図(「今日はいい天気です」の例や棒の長さ)は説明のために作ったもので、論文の図そのものではありません。数値は論文の表から引いています。
