LocalLLaMAベンチマーク: Gemma 4のspeculative decodingで平均29%高速化を報告

LocalLLaMA投稿が測定した内容

r/LocalLLaMA の投稿は、Gemma 4 31B に Gemma 4 E2B をdraft modelとして組み合わせた speculative decoding ベンチマークを共有した。今回のクロールで使ったスレッドスナップショットでは、この投稿は 257アップボート、コメント 88件 だった。環境も具体的で、RTX 5090 と 32GB VRAM、Windows 11、TurboQuant KV cache入りの llama.cpp フォーク、128K context、Flash Attention、そして --draft-max 8 --draft-min 1 が使われている。

報告されたスループット改善

投稿者は baseline 平均を 57.17 t/s、speculative decoding 平均を 73.73 t/s とし、全体で +29.0% の改善を報告した。最も伸びたのは構造化出力で、数学説明は 57.45 から 85.86 t/s、コード生成は 57.15 から 86.05 t/s と、どちらも約 +50% だった。半構造の説明は約 +24%、翻訳と分析も acceptance rate が 42.2% と低めでも +10.7% の改善になったという。

重要だったのは失敗パターン

運用上もっとも参考になるのは、最高性能よりも失敗要因だ。投稿者はモデルを再ダウンロードする前、draft経路が 7.31 t/s まで落ちたと説明している。原因は llama.cpp が target と draft の vocabulary 非互換を警告したことだった。投稿では、その理由を add_bos_token メタデータの不一致だとしている。2026年4月初旬の Gemma 4 31B GGUF は false、後で取得した E2B draft は true で、この差が token translation を強制し、本来の加速効果を消してしまったという。

実運用で効く設定上の注意

投稿は、この構成では --parallel 1 が実質必須だと主張する。自動 parallel は draft KV allocation を複数倍に増やし、VRAM を食って性能を壊すからだという。また Q4 draft で十分であり、このスタックでは speculative decoding と multimodal vision は併用できず、追加VRAMは約 2.3GB。総使用量は 128K context で約 23.4GB、256K で約 25.5GB とされている。

ローカルLLM運用者への示唆

より大きな教訓は、speculative decoding の効果が単に小さなdraft modelを付ければ得られるものではなく、workloadの形と tokenizer 互換性に強く依存するという点だ。投稿内の sweep では draft-max 8 が混合workloadで最良の平均を示し、16 は数学性能をさらに押し上げた一方で creative タスクでは一部を失った。ローカルLLM運用者にとっては、まず vocab 互換性を確認し、そのうえで自分の出力パターンに合わせて draft 長を調整するべきだという実務メモとして価値がある。

Reddit議論スレッド