Gemma 4 现在主要有四个本地部署尺寸：E2B、E4B、26B A4B 和 31B。 其中 E2B、E4B 面向轻量和边缘设备，26B A4B 是 MoE 架构，31B 是更大的稠密模型。

本地运行时，最容易混淆的是两个数字：

• GGUF 文件体积：模型权重文件本身有多大。
• 实际显存占用：模型权重、KV cache、运行时开销、上下文长度、是否加载多模态投影文件共同决定。

下面的表格按 GGUF 文件体积估算显存需求。 默认假设是 llama.cpp、LM Studio、Ollama 这类本地推理场景，主要跑文本，使用中短上下文。 如果要开长上下文、视觉/音频输入、并发请求，显存要继续往上留余量。

先看结论

如果只是想本地可用，优先从 E4B Q4_K_M 或 E2B Q4_K_M 开始。 如果有 24GB 显存，26B A4B Q4_K_M 和 31B Q4_K_M 才开始进入比较舒服的范围。

Gemma 4 E2B 显存表

E2B 是最轻量的版本，适合笔记本、迷你主机、移动端和低显存测试。 它的优势是容易跑，缺点是复杂推理、代码和长任务稳定性有限。

E2B 的 Q4_K_M 已经够日常体验。 如果只有 4GB 显存，可以尝试 2-bit 或 3-bit，但输出质量会更容易波动。

Gemma 4 E4B 显存表

E4B 是更实用的轻量版本。 它比 E2B 更适合日常写作、资料总结、轻量代码辅助和本地助手。

如果你的显卡是 8GB，E4B Q4_K_M 是很现实的起点。 如果是 12GB 或 16GB，E4B Q8_0 也可以考虑。

Gemma 4 26B A4B 显存表

26B A4B 是 MoE 版本，参数规模更大，但每次推理只激活其中一部分专家。 它适合更复杂的问答、代码、工具调用和 Agent 工作流。

24GB 显存是 26B A4B 比较舒服的分界线。 16GB 显卡可以尝试低比特版本，但上下文长度、并发和多模态都要收敛。

Gemma 4 31B 显存表

31B 是更大的稠密模型。 它的优点是综合能力更强，缺点是显存压力比 26B A4B 更直接。

31B 的低比特版本可以在 16GB 显卡上做实验，但如果想日常使用，最好从 24GB 显存起步。 Q4_K_M 是比较平衡的选择，Q5_K_M 往上更适合 32GB 以上显存。

为什么实际占用会比文件体积更高

GGUF 文件体积只是权重大小。 真正运行时还会增加这些开销：

• KV cache：上下文越长，占用越高。
• 批大小和并发：一次处理更多 token 或多用户并发，会增加显存。
• 多模态组件：图片、音频、视频输入通常还要加载 mmproj 或额外处理模块。
• 运行时后端：CUDA、Metal、ROCm、CPU/GPU 分层加载的占用不同。
• KV cache 量化：开启 q8_0、q4_0 等 KV cache 量化可以省显存，但可能影响细节。

所以表格里的“最低显存”只能理解为“能启动并短上下文运行”的门槛。 如果你要 32K、64K、128K 甚至 256K 上下文，显存需求会明显增加。

怎么选

如果只是想在本地体验 Gemma 4：

• 4GB 到 6GB 显存：选 E2B Q3_K_M 或 E2B Q4_K_M。
• 8GB 显存：优先选 E4B Q4_K_M，也可以跑 E2B Q8_0。
• 12GB 显存：选 E4B Q8_0，或者尝试 26B/31B 的低比特版本。
• 16GB 显存：可以尝试 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待长上下文很舒服。
• 24GB 显存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重点选择。
• 32GB 以上：可以考虑 Q5_K_M、Q6_K，或者更长上下文。

一般用户不需要追 BF16。 本地部署的核心不是文件越大越好，而是在显存、速度、上下文和输出质量之间找到平衡。

参考来源

• google/gemma-4-E2B-it - Hugging Face
• google/gemma-4-E4B-it - Hugging Face
• ggml-org/gemma-4-26B-A4B-it-GGUF - Hugging Face
• unsloth/gemma-4-E2B-it-GGUF - Hugging Face
• unsloth/gemma-4-E4B-it-GGUF - Hugging Face
• unsloth/gemma-4-26B-A4B-it-GGUF - Hugging Face
• unsloth/gemma-4-31B-it-GGUF - Hugging Face