 | 前回の Gemma 4 31B ベンチマーク投稿の続きとして、ドラフトモデルに Gemma 4 E2B（4.65B）を用いて speculative decoding を試しました。 結果は予想以上に良かったので、いくつかの管理されたベンチマーク数値を共有したいと思います。 セットアップ
ベンチマーク結果両方でサーバー設定は同一、max_tokens=500、temp=0.7、計測前のウォームアップクエリは破棄しました。
受理率が 42% でも、speculative decoding は依然として +10% 速いです。ボキャブラリが互換であれば、トークン翻訳のオーバーヘッドがゼロだからです。 GGUF バージョンの落とし穴最初はひどい結果になりました。ドラフトモデルは、そもそもドラフトなしの場合よりも 遅い という状態でした（7.31 t/s vs ベースライン 57 t/s）。ドラフトモデルの組み合わせを変えるたびに、この警告が出ました：
31B GGUF を再ダウンロード（Unsloth が最近、修正を入れてすべての Gemma 4 GGUF を再量子化）したら、警告が消え、完全な +29% のスピードアップが解放されました。 TL;DR：2026 年 4 月上旬に Gemma 4 の GGUF をダウンロードしたなら、再ダウンロードしてください。トークナイザーのメタデータが修正されています。 実用的なヒント既存の llama-server コマンドに以下のフラグを追加してください： 注意点：
コンテンツ依存のスピードアップ得られる効果は、出力がどれだけ予測可能かに比例します：
最悪の場合でも純増（プラス）であることが重要なポイントです。互換でないボキャブラリの場合は、受理率 65% でもゼロの向上に終わるため、ここが大きな違いです。 draft-max のスイープ提案してくれたu/Odd-Ordinary-5922 に感謝します。同じベンチマークセットアップで、
draft-max 8 は最適なポイントで、混在ワークロードに適しています。16 だと数学は 99 t/s まで伸びる一方、創作/翻訳では悪化して、結局平均はほぼ同じになります。創作のテキストは draft-max に関係なくほぼ横ばい（約 62 t/s）で、そこではボトルネックがドラフトの長さではなく受理率だからです。 [リンク] [コメント] |
Speculative Decoding は、E2B ドラフトを使う Gemma 4 31B で非常にうまく機能（平均 +29%、コードで +50%）
Reddit r/LocalLLaMA / 2026/4/12
💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research
要点
- この投稿では、Gemma 4 E2B をドラフトモデルとして speculative decoding を行うことで、Gemma 4 31B のメインモデルにおける推論速度を大幅に向上できることを示す、制御されたベンチマーク結果を報告している。
- 同じサーバ設定（RTX 5090 32GB、TurboQuant KV キャッシュ付きの llama.cpp fork、128K コンテキスト、parallel=1）で、著者はスループットを 57.17 t/s から 73.73 t/s へ平均増加させ、+29% と報告している。
- 加速率はタスクによって異なり、コード生成では約 +50%（+50.5%）まで到達している。観測された accept rate はおよそ ~60.7%。
- ベンチマーク設定には、speculative decoding の具体的なパラメータ（--draft-max 8 --draft-min 1）が含まれており、計測の前にウォームアップ実行を破棄している。
- 結果は、小型の E2B ドラフトモデルをより大きい 31B モデルと組み合わせることが、ローカル LLM 導入におけるレイテンシ／スループット改善の有効な実践戦略であることを示唆している。
