AI開発の現場では、経営層やプロジェクトリーダーから次のような悩みをよく耳にします。
「我々のAIチャットボットは賢い。でも、亀のように遅い。ユーザーが回答を待てずにブラウザを閉じてしまう。やはり、もっと高価なGPUを買い足すしかないのだろうか？」
しかし、ハードウェアの増強に頼る前に、ソフトウェアの工夫で解決できるアプローチが存在します。それは、メインのAIモデルに優秀な「アシスタント」をつけるという手法です。
多くのプロダクトマネージャーやエンジニアが、LLM（大規模言語モデル）のレイテンシ（応答遅延）という壁に直面しています。しかし、解決策は必ずしも計算リソースの暴力的な投入だけではありません。経営的視点からも、既存リソースを最大限に活かすアーキテクチャ設計が求められます。
今回は、既存のモデル構成を少し工夫するだけで、推論速度を1.5倍から2倍、場合によってはそれ以上に引き上げる技術、「推測デコーディング（Speculative Decoding）」と、その鍵を握る「ドラフトモデル」の選び方について解説します。数式は使いません。代わりに、直感的なイメージとロジックで、この技術の正体を解き明かしていきましょう。
なぜあなたのAIアプリケーションは「待たせる」のか
まず、敵を知ることから始めましょう。なぜ、最新のGPUを使っても、AIは人間のようにスラスラと話してくれないことがあるのでしょうか。
トークン生成の仕組みと「待ち時間」の正体
ChatGPTの旧モデルが廃止され、より高度な推論能力を持つ最新モデルへと移行が進む現在、AIの機能は飛躍的な進化を遂げています。Claudeの最新モデルに見られるように、タスクの複雑さに応じて思考の深さを自動調整する「Adaptive Thinking」や、MCP（Model Context Protocol）を利用した外部ツールからのデータ取得など、背後で行われる処理は高度化する一方です。
しかし、どんなに賢くなっても、私たちが普段接しているLLMの根本的な仕組みは「自己回帰（Auto-regressive）モデル」のままです。この言葉だけ聞くと難しそうですが、やっていることは単純です。「これまでの文脈を見て、次に来る確率が最も高い1単語（トークン）を予測する」。これだけです。
問題は、このプロセスが完全に「逐次処理」であるという点です。
- 「昔々、」を出力する。
- 「昔々、」を見て、「ある」を予測する。
- 「昔々、ある」を見て、「ところに」を予測する。
どんなに高性能な並列処理能力を持つGPUであっても、この「前の言葉が決まらないと次の言葉が決められない」という順序の制約からは逃れられません。これは、100人の優秀な数学者がいても、リレー小説を書くなら一人ずつ順番にペンを持つしかないのと同じです。さらに最新モデルでは、回答を生成する前の「思考（Thinking）」プロセスや、外部データとの連携処理が加わるため、ユーザーが体感する「待ち時間」の要因はより複雑化しています。
ユーザー体験を損なう「3秒の壁」とは
Webパフォーマンスの世界には「3秒の壁」という言葉がありますが、対話型AIにおいても応答速度はUX（ユーザー体験）の生命線です。
人間が「対話している」と感じる自然なリズムがあります。質問を投げかけてから最初の文字が表示されるまでの時間（TTFT: Time To First Token）と、その後の生成速度（Tokens Per Second）が遅いと、ユーザーは「深く思考している」のではなく「システムがフリーズした」あるいは「処理能力が低い」と判断してしまいます。
特に、生成速度が人間の読書速度（一般的に秒間5〜10トークン程度）を下回ると、ストレスは急激に増大します。多くの商用LLMアプリケーションが目指すべきは、ユーザーが読む速度よりも速く、かつ待たされていると感じさせないリズムでテキストを紡ぎ出すことです。
GPUを増強しても解決しきれないボトルネック
「じゃあ、もっと速いGPUを買えばいい」と考えるのは自然な発想です。しかし、ここには「メモリ帯域幅（Memory Bandwidth）」という落とし穴があります。
LLMの推論処理、特に一度に1人のユーザー（バッチサイズ1）を相手にする場合、計算能力（Compute）よりも、GPUのメモリからデータを読み出す速度（Memory）がボトルネックになることがほとんどです（Memory Boundと呼ばれます）。
最新モデルでは長大な文脈を扱うことも珍しくなく、巨大なモデルパラメータをメモリから読み込んで、たった1つの単語を計算する負荷は計り知れません。次の単語のために、また巨大なパラメータを読み込む。これは、トラックで砂を一粒ずつ運んでいるようなものです。どんなにエンジンの馬力が高いトラック（高性能GPU）を使っても、積み下ろしの手間（メモリ転送）がかかる限り、全体の速度は劇的には上がりません。
ここで発想の転換が必要です。「トラックを速くする」のではなく、「一度に運ぶ砂の量を増やす」ことはできないか？ それを実現するのが、これから解説するアプローチです。
「巨人の肩に乗る小人」：ドラフトモデルの仕組みを直感的に理解する
専門用語では「推測デコーディング（Speculative Decoding）」と呼ばれますが、これは「速記者と校正者のペア」に例えると理解しやすいでしょう。
推測デコーディング（Speculative Decoding）とは何か
通常、巨大で賢いモデル（メインモデル）は、すべての単語を自分一人で慎重に選びます。これは確実ですが、先ほど述べたように遅い作業です。
推測デコーディングでは、ここに「小さくて速いモデル（ドラフトモデル）」を相棒として連れてきます。この相棒の役割は、メインモデルよりも遥かに高速に、しかし少し雑に、「たぶん次はこう言うだろう」という下書き（ドラフト）を数単語分まとめて作ってしまうことです。
「下書き担当」と「清書担当」の役割分担
具体的な流れを見てみましょう。
速記者（ドラフトモデル）の暴走:
「昔々、あるところに、おじいさんと」まで、一瞬で5トークンほど予測して書きます。小さいモデルなので計算が速く、メモリ転送の負担も軽いです。校正者（メインモデル）の一括チェック:
メインモデルは、この「昔々、あるところに、おじいさんと」という5つの単語を一度に受け取り、並列でチェックします。「うん、合ってる」「合ってる」「合ってる」「...いや、ここは『おばあさん』の方が確率が高いな」と判定します。採用と修正:
もし5つともメインモデルの基準でOKなら、本来5回分のメモリ読み込みが必要だったプロセスが、たった1回の処理で完了します。これが高速化のトリックです。
なぜ2つのモデルを動かすのに逆に速くなるのか
「モデルを2つも動かしたら、余計に遅くなるのでは？」
鋭い質問です。しかし、ここにはGPUの特性が関係しています。GPUは「大量のデータを一度に処理する」のが得意です。1つの単語をチェックするのも、5つの単語をまとめてチェックするのも、メインモデルにとっては負荷（実行時間）があまり変わりません。
つまり、ドラフトモデルが作った下書きを作るコスト（微小）と、メインモデルがそれをまとめてチェックするコスト（通常とほぼ同じ）を足しても、5回別々に生成するより圧倒的に速いのです。
もしドラフトが全部間違っていたら？ その時はドラフト生成にかかった時間分だけ損をします。しかし、適切なドラフトモデルを選べば、多くのケースで予測は的中し、トータルでは大幅な「時間の貯金」が生まれます。
この「適切なドラフトモデルを選ぶ」という点こそが、プロジェクトの成否を分ける最大のポイントです。
失敗しないドラフトモデル選定の3つの黄金律
「とりあえず小さいモデルを使えばいい」と安易に選んでしまうと、エラーで動かなかったり、かえって処理が遅くなったりするケースは珍しくありません。多くのプロジェクトで目安とされている、失敗を防ぐための3つの選定ルールをまとめました。
【ルール1】トークナイザの一致：共通言語で話す
これは絶対条件と言えます。
LLMは言葉を「トークン」という数値IDに変換して処理します。モデルによって、この変換ルール（トークナイザ）は異なります。例えば、「Apple」という単語を、モデルAは「101」と解釈し、モデルBは「552」と解釈するかもしれません。
メインモデルとドラフトモデルが異なるトークナイザを使っている場合、ドラフトモデルが作成した下書き（ID列）をメインモデルはそのまま理解できません。その都度、テキストへの変換（デコード）と再数値化（エンコード）を行う必要が生じ、その処理負荷によって高速化のメリットが完全に失われてしまいます。
- 鉄則: メインモデルと同じファミリーから小さいモデルを選ぶのが最も確実です。例えば、Llamaモデルの最新版は1Bから405Bまで幅広いパラメータサイズが展開されており、同じファミリー内でメインモデル（大型）とドラフトモデル（小型）の組み合わせが非常に容易になっています。また、日本語の精度を重視してQwenモデルなどをメインに据える場合も、必ず同系統の小型モデルをドラフトとして選定してください。
【ルール2】サイズバランス：1/10〜1/100の法則
ドラフトモデルは「十分に小さく」なければなりません。メインモデルとサイズが近すぎると、下書きを作成するのに時間がかかりすぎて本末転倒です。
経験則として、ドラフトモデルのパラメータサイズはメインモデルの1/10から1/100程度が理想的な目安になります。
- 70Bクラスのモデルを加速させたい場合: 7B〜1B程度のモデルを探す。
- 7Bクラスのモデルを加速させたい場合: 1B〜100Mクラスの極小モデルを探す。
「小さければ小さいほど速い」のは事実ですが、極端に小さすぎると次のルールに抵触してしまいます。
【ルール3】精度と速度のトレードオフ：賢すぎず、愚かすぎず
ここが最も調整の腕が問われる部分です。
ドラフトモデルが賢すぎると（＝サイズが大きいと）、生成そのものに時間がかかります。
逆に、愚かすぎると（＝サイズが小さすぎる、または学習不足だと）、予測がことごとく外れます。メインモデルによる「却下（Reject）」が連発すると、せっかくの下書きが無駄になり、単に無駄な処理負荷だけがかかる結果に終わります。
専門用語で「受容率（Acceptance Rate）」と呼びますが、ドラフトモデルが作った予測がどれくらいメインモデルに採用されるか、という指標が極めて重要です。一般的に、受容率が40%〜60%を超えてくると、目に見えて速度の向上が体感できます。
参考リンク
ケーススタディ：Llamaモデル系モデルでの選定シミュレーション
では、現在（執筆時点）世界中で広く使われているMeta社の「Llamaモデル」を例に、具体的な選定シミュレーションを行ってみましょう。
メインモデル：Llama-3-70Bを使用する場合
あなたは高精度な推論が必要で、Llama-3-70B（700億パラメータ）をメインモデルに採用したとします。しかし、応答速度が遅いのが悩みです。
適切なドラフト候補：Llama-3-8Bとその理由
ここで最有力候補となるのが、同じファミリーの弟分である「Llama-3-8B」です。
- トークナイザの一致: どちらもLlamaモデルファミリーなので、完全に同じトークナイザを使用しています。変換ロスはゼロです。
- サイズバランス: 70Bに対して8Bは、約1/9のサイズです。理想的な1/10〜1/100よりわずかに大きいですが、最近のGPU（A100やH100）であれば8Bの推論は十分に高速です。
- 精度（受容率）: Llama-3-8Bは、8Bクラスとしては驚異的な性能を持っています。つまり、兄である70Bの思考をかなり高い精度で模倣できます。高い受容率が期待でき、結果として全体の速度は1.5倍〜2倍程度になることが多くのベンチマークで示されています。
不適切な組み合わせ例とその挙動
逆に、ここで「もっと速くしたいから」といって、古い「Llama-2-7B」や、全く別の「Mistral-7B」をドラフトに選ぶとどうなるでしょうか。
- Mistral-7Bの場合: トークナイザが異なります。実装が非常に複雑になるか、そもそも動きません。
- 極端に小さな100Mモデル（自作）の場合: トークナイザを合わせたとしても、70Bの高度な文脈理解についていけず、予測をことごとく外す可能性があります。結果、70B単体で動かすのと変わらないか、むしろ遅くなるという悲しい結末を迎えます。
導入前に知っておくべき「品質」への懸念と回答
新しい技術を導入する際、PMやステークホルダーが最も気にするのは「品質への影響」です。ここでの懸念に、技術的な観点から明確に答えておきましょう。
「小さいモデルを使うと回答の質が落ちませんか？」
これが最大の誤解です。答えはNOです。
推測デコーディングは、数学的に「ロスレス（Lossless）」なアルゴリズムです。最終的に出力されるテキストは、メインモデルが単独で生成した場合と完全に同じ確率分布に従います。
ドラフトモデルはあくまで「提案」をするだけです。その提案がメインモデルの基準を満たさない場合、即座に却下され、メインモデル自身が正しい単語を生成し直します。つまり、最終的な決定権（品質担保）は常にメインモデルにあるのです。
ユーザーから見れば、回答の内容（賢さ）は変わらず、ただ表示されるスピードだけが速くなったように見えます。これは魔法ではなく、厳密なロジックによるものです。
「実装は複雑になりますか？」
一昔前までは、自分で推論ループを書く必要があり大変でした。しかし現在は、主要な推論ライブラリがこの機能を標準サポートしています。
- vLLM: 設定ファイルや引数でドラフトモデルを指定するだけ。
- Hugging Face TGI (Text Generation Inference): こちらも対応済み。
- NVIDIA TensorRT-LLM: 最適化された実装が提供されています。
多くの場合、コードを数行書き換えるか、起動コマンドにオプションを追加するだけで済みます。
コストへの影響はどう考えるべきか
ドラフトモデルをロードするために、VRAM（ビデオメモリ）の使用量は若干増えます（Llama-3-8Bなら16GB程度）。しかし、推論速度が2倍になれば、同じハードウェアで処理できるリクエスト数（スループット）も向上します。
結果として、GPUインスタンスの稼働時間を短縮できたり、より少ないGPU数で同じトラフィックを捌けたりするため、トータルコストは下がる傾向にあります。
次のステップ：あなたのシステムでドラフトモデルを試すために
ここまで読んで、「これは試さない手はない」と思っていただけたなら、目的は半分達成されました。最後に、明日から始められる具体的なステップをお伝えします。プロトタイプ思考で、まずは動くものを作って検証することが重要です。
対応している推論フレームワークの確認
まず、現在使用している推論サーバーやライブラリが推測デコーディング（Speculative Decoding）をサポートしているか確認してください。もしvLLMを使用しているなら、最も手軽に試すことができます。
まずは手元の環境でベンチマークを取ろう
いきなり本番環境に入れるのではなく、開発環境でベンチマークを取りましょう。以下の指標を計測してください。
- Tokens Per Second (TPS): 生成速度。これがどれくらい向上したか。
- Latency: 最初のトークンが出るまでの時間と、完了までの時間。
- GPU VRAM Usage: メモリが溢れていないか。
もし手元にLlama-3-70Bを動かす環境がなければ、もっと小さなモデル（例: Llama-3-8Bをメインにし、さらに小さなLlama-3系の量子化モデルや、専用のドラフトモデルを試す）で実験するのも良いでしょう。
継続的な学習リソースの紹介
AI技術は日進月歩です。推測デコーディング以外にも、「Medusa」のようなマルチヘッド構造を用いた技術や、「Lookahead Decoding」といったドラフトモデル不要の手法も登場しています。
しかし、基本となる「予測して、検証する」という考え方は共通しています。まずは基本の推測デコーディングをマスターすることで、将来的な技術トレンドにもついていきやすくなるはずです。
AIのパフォーマンスチューニングは、車のエンジンの調整に似ています。ちょっとしたパラメータの違いや、モデルの相性診断で、結果が劇的に変わることがあります。技術の本質を見極め、ビジネス価値への最短距離を描くために、まずは小さなプロトタイプから検証を始めてみてはいかがでしょうか。
コメント