Gemma 4 视觉
摘要
Gemma 4 的视觉表现受默认 token 预算过低拖累;在 llama.cpp 中将 --image-max-tokens 提到 2240,可解锁顶尖 OCR 与细节识别,代价是额外占用约 14 GB 显存。
很多人在 [Gemma 4 模型需求帖](https://www.reddit.com/r/LocalLLaMA/comments/1srgqk4/which_gemma_model_do_you_want_next/) 里呼吁下一版 Gemma 加强视觉能力,这说明大家根本没给 Gemma 4 开足视觉预算。Gemma 4 原生支持[可变图像分辨率](https://huggingface.co/google/gemma-4-31B-it#5-variable-image-resolution),但默认视觉预算只有 280(约 645 K 像素),远远不够。这种设置下,它连小字 OCR 都失败,在我眼里基本等于“半盲”。
在 llama.cpp 里,可以用两个参数控制 Gemma 4 的视觉预算:`--image-min-tokens` 和 `--image-max-tokens`,引擎会在这之间自适应分配。官方默认 40 / 280,实在太低。我习惯设成 560 / 2240,此时再模糊的细枝末节也能被它揪出来。为什么拉到 2240——不是官方上限 1120 的两倍吗?实测 2240 反而比 1120 效果更好,我怀疑是 llama.cpp 在 min-max 区间里做自适应缩放导致的。
此外,`--batch-size` 和 `--ubatch-size` 也必须大于等于你设的 `image-max-tokens`。我配 2240 时把这两项都开到 4096。显存直接飙车:q8_0 满上下文下,默认约 63 GB,拉高后约 77 GB。
如果你用 Ollama,在[这个 issue](https://github.com/ollama/ollama/issues/15626) 被解决前基本没戏。不过花这 14 GB 显存绝对值:预算给足后,Gemma 4 的视觉直接 SOTA,OCR 把 Qwen 3.5、Qwen 3.6、GLM OCR、Kimi K2.5 全打爆。Kimi K2.6 我还没测,云模型我拒绝碰。
相似文章
@analogalok: 在8GB显存上以20+ token/秒运行Gemma 4 26B MoE,支持250k上下文。如果你有8GB显存显卡,停下你正在做的事……
Alok演示了使用Unsloth的QAT量化以及llama.cpp中的-cmoe标志,在8GB显存上运行Gemma 4 26B MoE,实现了250k上下文下20 token/秒的速度,这标志着廉价本地AI的一个重要里程碑。
@leopardracer: GEMMA 4 26B 在 RTX 4060 上运行,拥有 248K Token 上下文窗口,每秒 20 个 Token,上下文窗口大得可以……
Gemma 4 26B 在 RTX 4060 上运行,通过 llama.cpp 和 Q4_K_XL 量化实现 248K Token 上下文和每秒 20 Token 的速度,从而在消费级硬件上本地处理整个代码库。
Gemma4-12B-QAT Uncensored Balanced 现已发布,支持 MTP(约 60% 速度提升)!
Gemma4-12B-QAT Uncensored Balanced 发布,这是一个经过微调的无审查模型,配备多 token 预测草案头,可实现约 60% 更快的推测解码,针对 llama.cpp 优化,并支持视觉功能。
在 500MB 内存上运行 Gemma 4
讨论了如何在仅有 500MB 内存的设备上运行 Gemma 4,可能通过量化或其他优化技术实现。
在12GB显存上使用Gemma 4 12B QAT MTP实现120 tok/s
Google的Gemma 4 12B QAT模型通过llama.cpp的多令牌预测(MTP)在12GB GPU上达到120 tok/s。本文提供分步指南以及无MTP的基准对比,显示速度提升2倍。