「高速化機能を有効にしたのだから、当然速くなる」
ローカルLLMを触っていると、ついそう考えたくなります。しかし、2026年7月21日のarXiv新着に掲載された研究では、LLMを高速化する投機的デコーディングを家庭用ノートPCで試したところ、5種類の構成のうち3種類が通常推論より遅くなりました。
一方、条件が合った構成は最大1.61倍まで高速化しています。
同じアルゴリズムなのに、ある構成では速くなり、別の構成では大幅に遅くなる。違いを生んだのは、AIモデルの賢さではなく、モデル同士の速度差と実行バックエンドでした。
今回取り上げるのは、Param Chordiya氏による論文「Lossless but Not Free: An Empirical Anatomy of Speculative Decoding on Consumer Hardware」です。
投機的デコーディングとは何か
通常のLLMは、文章を一文字ずつ書くように、次のトークンを一つ生成するたびにモデル全体を動かします。次のトークンは前の結果が決まるまで計算できないため、処理を単純に横へ並べることができません。
投機的デコーディングでは、ここに小さな「ドラフトモデル」を加えます。
- 小さなモデルが、次に続きそうなトークンを複数個まとめて提案する
- 大きな本命モデルが、その候補を一度に検証する
- 正しい確率規則に従って候補を採用または却下する
たとえるなら、アシスタントが文章を数語先まで下書きし、編集長がまとめて確認する方式です。下書きが多く採用されれば、編集長が一語ずつ書くより早く進みます。
重要なのは、この手法が単なる近似ではない点です。棄却サンプリングを正しく実装すれば、ドラフトモデルの文章へ置き換えるのではなく、本命モデル単独と同じ出力分布を保ったまま高速化できます。
論文では、実モデルで通常方式と投機方式からそれぞれ約9,200トークンを生成して比較しました。統計検定はχ²=162.5、自由度200、p=0.976で、検出可能な分布差は確認されませんでした。貪欲生成では系列の完全一致も確認しています。
最大1.61倍。しかし過半数の構成は遅くなった
実験環境は、M3クラスのApple Siliconと18GBユニファイドメモリを搭載した一般向けノートPCです。CUDAサーバーではなく、MPSやMetal、量子化モデルを組み合わせた、ローカルLLM利用者に近い環境です。
最も良かった構成では、ドラフトが6トークンを先読みするK=6で、通常推論の1.61倍の速度を記録しました。K=4の測定でも、通常の16.00 tok/sに対して投機方式は25.07 tok/sとなり、1.57倍でした。
ところが、5構成中3構成は、先読み数を変えても通常推論を超えられませんでした。ある構成では、通常73.46 tok/sに対し投機方式は24.44 tok/sまで落ち、約0.33倍になっています。
高速化機能をオンにした結果、3倍近く遅くなる。なかなか景気の悪い「高速化」です。
原因1：下書き担当の方が仕事を増やしてしまう
投機的デコーディングでは、ドラフトモデルが本命モデルより十分速くなければなりません。
しかし本命モデルがもともと小さく高速な場合、ドラフトモデルを呼び出すフレームワークのオーバーヘッドだけで、本命モデルの1ステップより時間がかかることがあります。これでは、編集長が自分で書いた方が速いのに、毎回アシスタントへ下書きを依頼している状態です。
採択率が高くても、ドラフトを作る時点で時間を使いすぎれば全体は速くなりません。
原因2：「まとめて確認」が内部では直列処理だった
もう一つの原因は、量子化Metalバックエンドの挙動でした。
投機的デコーディングの利点は、本命モデルが複数候補を一度に検証できることです。ところが今回の一部構成では、小さいバッチを渡しても検証処理が十分に並列化されず、実質的に直列処理されていました。
見かけ上は「6トークンをまとめて検証」と指定していても、内部で一つずつ処理していれば高速化の前提が崩れます。論文が示した大事な点は、手法の理論が正しくても、実際の速度はランタイム実装で逆転するということです。
著者はこれを「保証は無料だが、高速化はシステムの性質である」とまとめています。
ローカルLLM利用者が確認すべき3項目
llama.cppなどに投機的デコーディング機能が追加されても、「対応した」という表示だけで有効化を決めない方がよさそうです。最低でも次を測る必要があります。
1. 通常推論と有効化後のtok/s
同じプロンプト、生成長、温度、モデルで比較します。理論値や他人のGPU結果ではなく、自分のマシンでの実時間が基準です。
2. ドラフトとターゲットの1ステップ遅延比
ドラフトモデルが本命モデルよりどの程度速いかを確認します。差が小さければ、先読みの準備費用を回収できません。
3. 検証バッチを増やしたときの伸び方
候補数を2、4、6と増やした際、検証時間がほぼ一定なのか、候補数に比例して増えるのかを確認します。後者なら、バックエンドが投機的デコーディングの利点を生かせていない可能性があります。
採択率だけを見るのは不十分です。今回の研究でも、採択率はK=1の69.7%から、最速だったK=6では37.8%へ低下しています。それでもK=6が速かったのは、採択率以外の実行コストが全体を左右するからです。
CodexやOpenCodeのローカル推論環境への意味
この論文はCodexやOpenCodeそのものを評価した研究ではありません。ただし、両者の接続先としてローカルLLMを使う場合には、直接的な判断材料になります。
コード生成では応答時間が作業感を大きく左右しますが、モデルの量子化率やパラメータ数だけでは速度を予測できません。ドラフトモデル、ターゲットモデル、バックエンド、ハードウェアを一つのシステムとして測る必要があります。
新しい高速化機能が登場したときも、機能名を紹介するだけでは足りません。「どの構成で速くなり、どの構成で遅くなったか」をセットで確認する方が、実際の導入判断には役立ちます。
この研究の限界
結果をすべての環境へそのまま当てはめることはできません。
- 実験機はApple SiliconノートPC一台
- 単一ストリーム、バッチサイズ1の測定
- 特定のドラフト／ターゲットモデルの組み合わせ
- MPS・Metalの特定バージョンに依存
- サーバー側の連続バッチ処理やCUDA環境は未検証
したがって「投機的デコーディングは遅い」という研究ではありません。正確には、「速くなる条件を満たしているか測らずに有効化すると、逆効果になり得る」という研究です。
結論
投機的デコーディングは、出力品質を変えずにLLMを高速化できる強力な方法です。しかし、高速化はアルゴリズム名に付属してくるものではありません。
今回の実験では、最良構成は1.61倍になった一方、5構成中3構成が遅くなりました。その差を作ったのは、ドラフトモデルの実行コストと、検証バックエンドが本当に並列化されているかどうかです。
ローカルLLMの新機能は、オンにする前より、オンにした後の方が遅いことがある。だから最後に信用すべきなのは機能名ではなく、自分の環境で測った数字です。
参考
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能