LocalLLaMAベンチマーク、Gemma 4 speculative decodingで平均29%高速化

r/LocalLLaMAに投稿された新しいベンチマークは、speculative decodingがGemma 4のローカル推論でかなり現実的な高速化手段になりつつあることを示している。投稿者はWindows 11上のRTX 5090(32GB VRAM)で、Gemma 4 31B UD-Q4_K_XLをmain model、Gemma 4 E2B UD-Q4_K_XLをdraft modelとしてテストし、平均throughputが57.17 tokens/sから73.73 tokens/sへ、およそ29%向上したと報告した。code generationとmath explanationでは約50%の改善も出ている。

興味深いのは、最初はむしろ大幅に遅かったという点だ。投稿者によれば、初期テストではtarget modelとdraft modelのvocabularyが互換ではなく、llama.cppがtoken translation modeに入ってしまった。その原因を speculative.cpp まで追うと、4月初旬に取得したGemma 4 31B GGUFと、後から取得したE2Bモデルの add_bos_token metadataが一致していなかったという。これが期待していた高速化を消し、壊れた構成では7.31 tokens/s前後まで落ちたという説明だ。

修正済みtokenizer metadataを含む31B GGUFを再取得した後は、結果がかなり魅力的になった。codeとmathのpromptはおよそ50%高速化し、science explanationは約24%、translationのような予測しにくいタスクでも小さいながらプラスを維持した。さらに投稿では、混在workloadに対して --draft-max 8 が最もバランスが良く、--parallel 1 は事実上必須だったと述べている。parallelがauto(=4)だとdraft modelのKV cacheが4倍確保され、VRAMを圧迫して速度が崩れるという。

ローカル推論ユーザーにとって、このスレッドは性能最適化が単純に小さいdraft modelを選ぶ話ではなくなったことを示している。GGUF metadata、tokenizer compatibility、context length、KV cacheの挙動、multimodalの有無まで効いてくる。投稿者はQ4 draft構成で追加VRAMは約2.3GB程度と見積もっており、32GB級GPUユーザーには十分現実的だ。要するに、Gemma 4でbenchmarkを始める前にmodel artifactの整合性を確認すること自体が、もっとも安い最適化になり得る。

出典: r/LocalLLaMA benchmark post.