llama.cppでGemma 4 31Bに対してspeculative decodingがうまく機能する

Reddit r/LocalLLaMA / 2026/4/4

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

要点

  • この投稿では、llama.cppにおけるspeculative decodingで、下書き(draft)モデルにGemma 3 270B、本モデルにGemma 4 31Bを使うと、約~11%の速度向上が得られることが報告されています。
  • そのセットアップを再現するための具体的なllama-cliのコマンドラインフラグが示されており、`--no-mmproj`を使用し、下書きモデルは`-hfd`で指定します。
  • NVIDIA 3090 1台でのテストでは、生成スループットのトレードオフとともに、下書き受理率が約~0.44(受理820 / 生成1863)であることが測定されています。
  • speculative decodingを使わずに実行した場合と比べて、プロンプト処理レートは同程度〜やや改善していましたが、生成レートはやや低下していました。ただし著者の構成では、全体として性能は向上しています。
  • 著者は、このGemmaの組み合わせに対してspeculative decodingが特に有効であると示唆しており、下書きモデルのサイズや品質の調整が、ローカルLLMのレイテンシに実質的な影響を与えうることを示しています。

下書きモデルとしてGemma 3 270Bを使うと、~11%の速度向上が得られます。次を追加して試してください:

--no-mmproj -hfd unsloth/gemma-3-270m-it-GGUF:Q8_0 

(3090で)次をテストしました:

./build/bin/llama-cli -hf unsloth/gemma-4-31B-it-GGUF:Q4_1 --jinja --temp 1.0 --top-p 0.95 --top-k 64 -ngl 1000 -st -f prompt.txt --no-mmproj -hfd unsloth/gemma-3-270m-it-GGUF:Q8_0 

結果は:

[ Prompt: 607.3 t/s | Generation: 36.6 t/s ]
draft acceptance rate = 0.44015 ( 820 accepted / 1863 generated)

こちらの場合と比べて:

[ Prompt: 613.8 t/s | Generation: 32.9 t/s ]

投稿者 /u/Leopold_Boom
[link] [comments]