LocalLLaMAユーザー、Gemma 4 26B A3Bでローカル tool calling が安定したと報告
Original: Gemma 4 26b A3B is mindblowingly good , if configured right View original →
注目を集めているLocalLLaMAの投稿は、整ったbenchmark表というより、ローカルagentを日常的に使おうとする実務ユーザーの現場レポートとして読まれている。投稿者はRTX 3090とLM Studio環境で複数のモデルやquantを数日試したが、ローカルモデルでありがちな失敗、つまりtool callingのloop、function callingの不安定さ、conversationが大きくなるにつれて悪化するprompt caching slowdownに悩まされたと書いている。
そのうえで、Gemma 4 26B A3Bは設定を詰めると違って見えたという。投稿によれば、flash attentionとq4系のquantを組み合わせることで長いcontextでも持ちこたえ、使っていたstackではprompt cachingも安定し、function callingも壊れにくくなった。好みの設定として、Unsloth q3k_m quant、temperature 1、top-k 40、さらにcustom system promptが挙げられている。
最も具体的なのはhardwareとworkflowの記述だ。投稿者は80〜110 tokens/s程度を見たとし、24 GBのRTX 3090なら最大260k context近くまで押し込めたと主張する。さらにOpenCodeと組み合わせ、約6時間かけて2.7 GB規模のrepositoryを読ませて構造を説明させても、かなり安定していたという。一方でVRAM消費は依然として重く、16 GB級カードでも一部用途は可能だとしても、agentic workflowやtool callingでは大きなworking contextが重要だとも述べている。
この投稿が目立つ理由
- leaderboard順位ではなく、stabilityとworkflow適合性を中心に語っている。
- base modelそのものと同じくらい、runtime stackやquantization選択が重要だと示している。
- 最も強い主張は実用面にある。ローカルのrepo navigationとtool useが継続利用できるほど安定したという点だ。
もちろん、これはcontrolled evaluationではなくcommunity reportであり、数値や印象は設定依存だ。それでも反応の大きさは、ローカルLLMに求められる価値が変わってきたことを示している。人々が欲しているのは抽象的なbenchmark勝利よりも、長いセッションを耐え、toolを正しく呼び、手元のhardwareで実在のrepositoryを扱えるモデルだ。
Related Articles
LocalLLaMAがこの投稿を評価したのは、『Gemma 4は何となく弱い』で終わらなかったからだ。nullableなJSON Schemaが空のtypeに潰れるという具体的な壊れ方を切り出し、小さなJinja修正でtool callingが戻るところまで持っていった。
LocalLLaMAの投稿は、最近の llama.cpp 修正により Gemma 4 GGUF を再取得する価値があると指摘し、ローカル推論利用者が見るべき変更点をまとめている。
LocalLLaMA の高スコア post は、llama.cpp PR #21534 の merge によって Gemma 4 の current master support が実用的な安定域に入ったと見た。ただし焦点は fix そのものより tokenizer correctness、chat template、memory flag、そして CUDA 13.2 を避けるべきだという運用条件にあった。