Gemma 4 26B A4Bは245K contextでも実用になるのか
Original: Gemma 4 26B A4B is still fully capable at 245283/262144 (94%) contex ! View original →
コミュニティが見たGemma 4の長いcontext
2026年4月12日時点でr/LocalLLaMAの161 score、71 commentsを集めたこの投稿は、Gemma 4 26B A4Bを262,144 context window近くまで押し込んだstress testを共有している。投稿者はReddit posts、documentation、llama.cppのraw filesを大量に入れてVRAM使用量と応答の一貫性を確認し、245,283 / 262,144、つまり約94%の地点でも特定ユーザーの発言を正しく取り出せたと述べている。
この投稿が面白いのは、成功例だけでなくfailure modeも書いているところだ。投稿者によれば、100K contextを超えるあたりからmodelが自己問答のloopに入り、結論を返さずに考え続けることがあった。そこでtemperatureを下げ、repeat penaltyを1.17から1.18に上げると安定性が改善し、巨大なcontextから関連発言を2秒から5秒ほどで引き戻せるようになったという。
共有された実用設定
- context sizeは262144、GPU layersは99。
top_p0.95、top_k40、min_p0.05、repeat_penalty1.17を使用。- batchとmicrobatchは512、cache RAMは2048 MBに設定。
- 当時の最新
llama.cppと最新のUnsloth GGUFを使っていたと記している。
どう受け止めるべきか
もちろんこれは再現性まで確認されたformal benchmarkではなく、個人環境でのcommunity reportにすぎない。それでも価値があるのは、long-context marketingでは見えない実務上の情報が詰まっているからだ。どこでbehaviorが崩れ始めるのか、どのtuning knobがloopを減らしたのか、最新buildがどれだけ重要か。こうした実装寄りのメモは、派手なheadline context数よりむしろ役に立つ。
原文: r/LocalLLaMA post.
Related Articles
LocalLLaMA では、Gemma 4 の初期トラブルの一部は model 自体ではなく llama.cpp runtime bugs や support lag に起因する可能性があるという指摘が出ている。複数の pull request と user report が、early benchmark を読み替える必要性を示している。
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 を避けるべきだという運用条件にあった。
Comments (0)
No comments yet. Be the first to comment!