NVIDIA、推論速度向上のためのスペキュレーティブ・ディコーディング設計ガイドを公開

本記事は、AI モデルの共設計に関するシリーズの第 3 弾です。ここでは、精度を損なうことなく LLM（大規模言語モデル）の推論速度を向上させる手法として「スペキュレーティブ・ディコーディング」の活用方法と、パレート最適曲線上でドラフト長やドラフト機構を選択するための 5 つのガイドラインについて解説します。

精度を犠牲にせずスループットと対話性を両立させるためのモデル設計の選択については、「AI モデル共設計：ハードウェアフレンドリーな LLM デザイン」（第 1 回）をご覧ください。また、グループサイズ（KV ヘッドあたりのクエリヘッド数）、ヘッド次元、シーケンス長が密着アテンションのパフォーマンスにどう影響するかについては、「高速で対話的な長期コンテキスト推論のための AI モデルアテンションの共設計」（第 2 回）をご参照ください。

スペキュレーティブ・ディコーディングとは？

スペキュレーティブ・ディコーディングは、LLM の自己回帰的デコーディング段階を加速するための手法です。1 つのイテレーションで複数のトークンを予測することで処理速度を上げます。まず軽量なドラフトモデルが次に出現しそうなトークン群を複数予測します。その後、これら予測されたトークンは、大きなターゲットモデルを 1 回通すだけで並列に検証されます。

図 1. Speculative decoding を用いると、LLM の推論処理はより計算集約的な領域へと移行し、スループットとインタラクション性のパレートフロンティアを右上へシフトさせます。曲線の右側ほどインタラクション性が高まる一方でバッチサイズは減少し、実行時間のうち GEMMs（行列乗算）が占める割合が大きくなります。

この手法は、並列処理の増加を必要とせず、推論対象モデルの演算集約度を高めながら、デコーディング反復回数を削減します。対象モデルは提案されたトークンを順に受け入れ、最初の不一致を検出するまで処理を続けます。その位置から次の予測サイクルが再開されます。対象モデルによって承認されたトークンだけが保持されるため、承認基準をあえて緩和しない限り、スペキュレティブ・デコーディング（推測的デコーディング）は標準的なデコーディングと同じ出力シーケンスを生成します。図 2 はこのデコーディングフローを示しています。

ドラフト長（D）は、1 回のターゲットイテレーションで提案されるトークンの数を指します。一方、受容長（A L）は、そのイテレーションで実際に生成され、受け入れられたトークンの数です。

A_L は、ターゲットが受け入れられたドラフトトークンに加えて常に 1 つの新しい正解トークンを生成できるため、1 から 1 + D の範囲をとります。 （原文の技術表記: A L、1 plus D）

スペキュレーティブ・ディコーディングによる高速化は、ターゲットモデルが A L トークンを逐次生成するのにかかる時間と、D トークンの並列検証にかかる時間の比率として定量化できます。ただし、D トークンのドラフト作成に伴うレイテンシオーバーヘッドも考慮する必要があります。

speedup equals the fraction with numerator T sub verif of B times AL and denominator T sub verif of open paren B times open paren 1 plus D close paren close paren plus T sub draft of open paren B comma D close paren

ここで、B はバッチサイズ、T_sub verif of x は x トークンの目標検証時間、T_sub draft of (b, y) は時間です。 （原文の技術表記: T sub verif of x、T sub draft of open paren b comma y close paren）

バッチサイズ b のために長さ y のドラフトを生成するために必要です。

スピードアップを最大化するためには、最適な (D, AL, T_draft) の組み合わせを見つけることが不可欠です。 （原文の技術表記: open paren D comma A L comma T sub draft close paren）

最適なドラフト長の選定

単純化のため、ドラフトモデルの遅延を無視すれば、以下の条件で推論速度が向上します。

分子に検証時間 T_sub_verif、分母に B を持つ分数（B × (1 + D)）が A L より小さい場合。

検証時の計算量は (1 + D) に比例して増加しますが、メモリアクセスは一定のままです。そのため、目標は検証時間が一定になるまで D を増やすことであり、通常は検証がメモリアクセス制限から計算量制限へと移行する点まで行われます。 （原文の技術表記: 1 plus D close paren、T sub verif）

この最適な D の値は B に依存しており、パレートフロンティア全体で変動すると考えられます。これを念頭に置いて図 1 をご覧ください。

ドラフト長さと線形層の性能

推論を行う際、各ターゲットとなる線形層における行列積（GEMM）の計算量は、推測を行わない場合の M から M × (1 + D) へと増加します。ここで M は、推測を適用しない際の GEMM-M の値を表します。 （原文の技術表記: M times open paren 1 plus D close paren）

図3は、代表的なエキスパートGEMMサイズ6144×6144において、さまざまなドラフト長でバッチサイズに対する秒あたりテラフロップスのスケーリングを示しています。より長いドラフト長にすることで、有効バッチサイズが低い段階でもGEMMが最大性能を発揮できることが明らかです。

特筆すべきは、D equals 7 の場合、バッチサイズの 1/8 で計算リソースがボトルネックになる点です。Mixture-of-Experts（MoE）モデルがさらにスパース化し、長期コンテキスト処理の需要が高まって KV キャパシティへの負圧が増大する中、各エキスパートあたりの実効的な並行処理数が減少します。その結果、パレートフロンティア全体を通じて、より長いドラフト長を採用することが魅力的な選択肢となります。 （原文の技術表記: D equals 0）

図3：代表的なエキスパートGEMM（GEMM-N = 6,144、GEMM-K = 6,144）における、バッチサイズごとの推定長さに対する1秒あたりの正規化テラフロップス（D equals 0、バッチサイズ=1を基準）

ガイドライン1： KVキャッシュ容量への負荷を増やさずに計算集約型領域へ移行させるため、スペキュレーティブ・ディコーディングのドラフト長さを延長する。

ドラフト長さとアテンション性能

推論やエージェントワークロードにおいて、スループット重視の領域ではアテンションが実行時間の大部分を占める傾向があります。デコード時のアテンションは、1 つの KV ヘッドに対して共有されるクエリヘッドの数 G を用いると、演算集約度が約 2 倍 G となります（詳細は Co-Designing AI Model Attention for Fast, Interactive Long-Context Inference を参照）。 （原文の技術表記: 2 times G）

推測により、推定トークンが同じ KV キャッシュを再利用されるため、計算量は 2 * G * (1 + D) 倍に増加します。これに対し、有効なアテンション GEMM-M は G * (1 + D) です。 （原文の技術表記: 2 times G times open paren 1 plus D close paren、G times open paren 1 plus D close paren）

現在の GPU デバイスでは、アテンションカーネルは GEMM の M equals 128 で高いハードウェア利用率を達成するため、D equals 128 over G en dash 1 が最適なドラフト長となります。

図4は、32K と 128K の KVシーケンス長における D の増加に伴う正規化されたアテンションスループットを示しています。このグラフから、G=32 のバリアントの方がより低い値でスループットの飽和点に達することがわかります。スループットの飽和点を過ぎると、アテンション処理はもはやDRAM帯域幅に制約されなくなり、実行時間は D に比例して増加します。D は G に対して非線形（部分線形）に増大するため、この飽和点を超えて D をさらに大きくすると、アテンション処理が重いワークロードの全体速度はむしろ低下する可能性があります。

ガイドライン2: アテンション処理がデコード時間の大部分を占める場合は、G を大きく選択してください。

アテンションの実行時間はタイルサイズにも依存します。図5は、D がベンチマーク対象のアテンションカーネルのソフトウェアタイルサイズである128の倍数を超えると、実行時間がステップ状に増加することを示しています。もし D が2つのタイル境界の間にある場合、最後のタイルは部分的な利用率しか得られませんが、それでもフルタイルと同程度のコストがかかります。

ガイドライン3: k を選択する場合は、タイルの未利用を避けるため、k が128の倍数となる値を優先してください。

推奨動作点におけるFFN（フィードフォワードネットワーク）とアテンションの処理時間の割合に応じて、ガイドライン1の相対的な重みは、ガイドライン2および3と比較して変化します。通信コストも D が増加すると検証オーバーヘッドに加算されますが、計算と通信の並列実行によってこのオーバーヘッドを緩和できます。

パレート曲線の最右端におけるドラフト長

パレート曲線の最右端に近づくと、k は非常に小さくなります。ここでは、計算用カーネルおよび通信用カーネルの両方で、固定されたカーネルセットアップと後処理のオーバーヘッドが支配的になります。これらの固定コストは検証されるトークンの数に対して大幅には増加しないため、検証オーバーヘッドはドラフトトークンの数に対してほぼ不変となります。

MoE（Mixture of Experts）モデルでは、ドラフト長が増加すると活性化されるエキスパートの数も増えますが、モデルのシャード戦略とグループ化GEMM（General Matrix Multiplication）のような効率的なカーネルを組み合わせることで、このオーバーヘッドを低く抑えることができます。したがって、受け入れ率が十分に高い限り、より大きなドラフト長は低レイテンシ領域において有益となります。

非常に低いレイテンシでは、逐次的なカーネル起動の回数がワークロードのレイテンシを決定します。カーネル起動数は層数に比例して増えるため、ターゲットモデルと同様の層構造を持つ自己回帰型ドラフトモデルの場合、速度向上比は以下のように近似できます。

ここで、L_target と L_draft はそれぞれターゲットモデルとドラフトモデルの層数を表します。一定のドラフト深さ比率 r = L_draft / L_target を定義し、ドラフトオーバーヘッドを以下のように表すことができます。

つまり、ドラフトのオーバーヘッドを相殺できるだけの十分な利益が得られる場合のみ、このパラメータを増やすことが有効です。

ガイドライン 4: 非常に低いレイテンシ環境では、追加されるドラフトコストに見合う利益が生じる間だけ、この値を増加させてください。

ドラフトメカニズムの選定

どの程度のトークンを推測するかを決定する k の設定に加え、そのトークンをどのように生成して速度向上を最大化するかを決める必要があります。

これまでに多くの技術が提案されており、それぞれに学習コスト、パラメータ数、実行時のオーバーヘッドにおけるトレードオフが存在します。外部ドラフト方式では、小型の独立した LLM を使用します。一方、MTP、EAGLE-3、DFlash、DSpark は、ターゲットモデルからの情報を活用してトークンを予測するために補助層を組み合わせます。また、接尾辞（Suffix）や n-gram 方式はモデルに依存せず、すでにトークンストリーム内で確認されたパターンを再利用します。

表 1 では、主要なドラフト手法の比較を行っています。これにはトークンの生成方法、サービス時のメモリ使用量、そしてドラフトによるオーバーヘッドが含まれています。

表 1：入力、生成方法、トレーニングコスト、サービス時のメモリ使用量、ドラフトコストにおける一般的なドラフトメカニズムの比較

トレードオフを定量化するには、まず がどのように にスケールするかを観察することから始めます。

図 6 は、Qwen 3.5 122B A10B をターゲットモデルとした場合、SPEED-Bench 上で D（ドラフトトークン数）が増加した際の AL（平均受容率）の変化を示しています。SPEED-Bench は NVIDIA が開発した推論ベンチマークで、実際の生産環境でのワークロードを反映することを目的としています。コーディングや要約など複数のタスクドメインをカバーしており、入力シーケンス長が異なるさまざまなスプリットを用意しています。比較には SPEED-Bench の利用をお勧めします。

32K スプリットでは、Qwen 3.5 35B A3B は で AL が 6 に達しますが、4B ドラフトモデルは AL が 5 を超えます。MTP と DFlash の AL は、D が大きくなると頭打ちになります。一方、N-gram はこのワークロードでは受容率が低く、繰り返しトークンパターンを持つワークロードに適しています。

高い AL が必ずしも高速化につながるとは限りません。ドラフトを生成するコストも考慮する必要があります。

図6に示す通り、すべての外部ドラフト手法は、他のドラフト手法よりも高い性能を達成しています。Qwen 3.5 122B MTP は非常に小さく、パラメータ総数は 2.5B で、アクティブなパラメータも 1.5 億未満です。遅延が低い状況では、より大きな外部ドラフトモデルを採用しても追加コストに見合わない可能性があります。一方、遅延が高くなる局面では、その高い AL（Acceptance Length）によってコスト増が正当化される可能性があり、これは効率的なサービング戦略を前提とした場合の話です。

一方、DFlash の性能は比較的早く頭打ちになります。しかし、DFlash と DSpark はどちらもドラフトトークンを並列生成するため、遅延を低減できます。比較のために、最小遅延かつ特定の条件下で計算すると、1 層の MTP ヘッドでは 11 ステップが必要となり、一方、5 層の DFlash ヘッドならワンパスでドラフトを生成できるため、大幅な効率化が期待できます。

レイヤー数の多い大規模なターゲットモデルにおいては、両者のオーバーヘッドは無視できるほど小さいですが、遅延が低下するにつれてドラフト関連のオーバーヘッドは顕著になります。したがって、低遅延環境での小規模モデルでは、性能がやや劣っても DFlash や DSpark が最適な選択肢となり得ます。

性能とドラフト遅延のトレードオフを最適化するには、両方を正確にベンチマークすることが不可欠です。スペキュレーティブ・ディコーディング（推論加速技術）の文脈では、これは現実的なプロンプトを用いたベンチマークと、多様なタスクドメインへの対応を意味します。性能測定には SPEED-Bench を、ドラフト関連のオーバーヘッド定量化には NVIDIA TensorRT LLM などの高性能推論フレームワークの利用を推奨します。

推論性能だけでなく、ドラフトトレーニングの範囲とコストも考慮する必要があります。MTP はターゲットモデルと同時に共学習される必要がありますが、EAGLE、DFlash、DSpark は最終的なモデルチェックポイントに追加できます。同様に、外部ドラフトモデルの作成には幅広い選択肢が存在します。ゼロからトレーニングを行うか、ターゲットからの知識蒸留を行えば最も高い推論速度向上（AL）が得られますが、既存モデルをクロスモデル適応技術を用いて目的のターゲットに合わせて調整すれば、コストを大幅に削減できます。

ターゲットモデルをファインチューニングすると、その出力分布や隠れ表現が変化します。特定のターゲットチェックポイント向けに学習されたドラフト器は、ターゲットモデル自体が改善された場合でも、受け入れられなくなる可能性があります。ターゲットを変更した後は、代表的なワークロードで再測定を行う必要があります。必要な適応の程度は、使用するドラフトメカニズムによって異なります。

MTP はターゲットモデルの一部であり、ファインチューニング中も継続してトレーニングするか、専用の追従ステージで再整列させるべきです。EAGLE-3、DFlash、DSpark といったターゲットに付随するドラフト器はターゲットの隠れ状態を利用するため、追加のトレーニングによって更新されたチェックポイントに合わせて適応させる必要があります。

外部のドラフトモデルはターゲットの隠れ状態を消費しませんが、ターゲットの出力分布を近似するものであり、ファインチューニングや知識蒸留が必要になる場合があります。サフィックス法や n-gram 法には学習済みのドラフターが存在しないため再トレーニングは不要ですが、その効果はデプロイされたワークロードにおける反復パターンの多寡に依存します。

ガイドライン 5: ワークロードとハードウェアに対して最大のデコード速度向上をもたらすドラフトメカニズムを選択してください。これには、ドラフターの遅延や、トレーニング・展開にかかるコストも考慮する必要があります。

スペキュレーティブ・ディコーディングの共設計を始めるには、以下の 5 つのガイドラインをパレート最適曲線に沿ったドラフトモデルとドラフトメカニズムの選定チェックリストとして活用してください。

• KV キャッシュ容量への負荷を増やさない範囲で、スペキュレーティブ・ディコーディングのドラフト長を延長し、GEMM（行列乗算）を計算集約型の領域へ押し込みます。
• デコード時間の大部分がアテンション処理に占められる場合は、draft_model を起点として選択します。
• ドラフト長が大きくなる場合、アテンションカーネルのタイルサイズに合わせるため、draft_length の値は 128 の倍数になるように選定してください。
• 非常に低い遅延が求められる場合は、高速なドラフトメカニズムを採用し、追加されるドラフトコストに見合う速度向上が見込める範囲まで draft_length を増やします。
• ワークロードとハードウェアに応じて、draft_model とドラフトオーバーヘッドのバランスを考慮してドラフトメカニズムを選択してください。実際のサービング条件下でベンチマークを実施し、トレーニングおよび展開コストも併せて検討しましょう。

EAGLE-3、DFlash、DSpark 向けのポストトレーニング用ドラフターには、NVIDIA/Model-Optimizer リポジトリに実行可能なトレーニング例が用意されています。NVIDIA Nemotron 3.5 Lightning でどのように実装したかについては、まず fine-tune DSpark で微調整し、その後 FP8 または NVFP4 へ量子化する方法を確認してください。これらの例をスタート地点として活用し、自社のモデルやワークロード、ハードウェア環境で AL（Acceptance Length）とエンドツーエンドの速度を検証してください。

謝辞

本記事は NVIDIA の複数チームによる共同作業です。Bhargava Gopireddy、Ritika Borkar、Dor Tsur、Andrii Skliar、Benjamin Chislett、Yaniv Galron、Talor Abramovich、Yoav Miron、Rabeeh Karimi Mahabadi、Roger Waleffe、Udi Karpas、Ran Zilberstein、Brian Pharris、Eduardo Alvarez の皆様に多大なるご協力をいただきました。