Gemma 4 有四个版本，选对了用起来飞快，选错了要么卡得要死要么大材小用。这篇帮你搞清楚每个版本的定位，选出最适合你的那个。
四个模型一览
| 模型 | 总参数量 | 激活参数量 | 架构 | 最低内存 | 推荐内存 |
|---|---|---|---|---|---|
| E2B | 20 亿 | 20 亿 | Dense | 4 GB | 6 GB |
| E4B | 40 亿 | 40 亿 | Dense | 6 GB | 8 GB |
| 26B A4B | 260 亿 | 38 亿 | MoE | 8 GB | 16-18 GB |
| 31B Dense | 310 亿 | 310 亿 | Dense | 20 GB | 24-32 GB |
重点关注 26B 模型——它用的是**混合专家（MoE）**架构。虽然总参数有 260 亿，但每次推理只激活大约 38 亿参数。这意味着你能用小模型的速度享受大模型的质量。想深入了解 MoE 架构的优劣，看看 26B 和 31B 详细对比。
逐个拆解
E2B——口袋火箭
20 亿参数，约 4 GB 内存
最小的 Gemma 4 模型，专门为资源受限的场景设计。手机、树莓派、嵌入式设备，或者你需要极快响应不需要深度推理的场景。
ollama run gemma4:e2b擅长：
- 快速文本生成和摘要
- 简单问答
- 分类任务
- 在手机和边缘设备上运行
- 延迟敏感的场景
不足：
- 复杂多步推理会吃力
- 创意写作不够细腻
- 长对话可能丢失上下文
E4B——万金油（推荐大多数人用）
40 亿参数，约 6 GB 内存
如果你不知道该选哪个，选这个。E4B 在任何现代笔记本上都能流畅运行，质量好得超出预期。
ollama run gemma4:e4b擅长：
- 通用聊天和问答
- 代码生成和解释
- 内容写作和编辑
- 多模态任务（图片+文字）
- 日常本地 AI 使用
为什么推荐它：
- 最近 3-4 年的笔记本基本都能跑
- Apple Silicon 上轻松 20+ tokens/s，聊天很流畅
- 质量真的不错——远超你对 4B 模型的预期
- 资源占用低，跑着它还能正常用其他应用
26B A4B——效率之王
260 亿总参数，仅 38 亿激活（MoE 架构），约 8-18 GB 内存
这是整个阵容里最有意思的模型。Google 训练了 260 亿参数，但每次推理只激活 38 亿。你用小模型的算力，得到大模型的知识。
ollama run gemma4:26b擅长：
- 复杂推理和分析
- 多语言代码任务
- 长文生成
- 专业知识问答
- 整个系列中性价比最高
需要注意：
- 虽然激活参数少，但全部 260 亿参数都得加载到内存里
- GGUF Q4 量化后大概需要 8-16 GB，取决于上下文长度
- MoE 模型输出质量可能略有波动（不同输入激活不同专家）
谁该用这个： 如果你有 16 GB 以上内存和一块还行的 GPU（或者 Apple Silicon Mac），这可能是整个系列里最值的选择。接近 31B 的质量，E4B 的速度。
31B Dense——极限性能
310 亿参数，全密集，最低约 20 GB 内存
最大、最强的 Gemma 4 模型。每个 token 都经过全部 310 亿参数的处理。没有捷径，没有路由——纯粹的能力。
ollama run gemma4:31b擅长：
- 最有挑战性的推理任务
- 最高质量的创意写作
- 复杂代码生成和调试
- 研究和分析
- 质量是唯一考量的场景
硬件要求：
- 最少 20 GB 内存（推荐 24-32 GB）
- 强烈建议有独立 GPU 才能有可接受的速度
- Q4 量化后模型文件约 18 GB
GPU 用户：显存需求
按具体机型（MacBook、游戏 PC、云 GPU）看配置够不够，参考硬件配置要求详解。
| 模型 | Q4_K_M | Q5_K_M | Q8_0 | FP16 |
|---|---|---|---|---|
| E2B | ~1.5 GB | ~1.8 GB | ~2.5 GB | ~4 GB |
| E4B | ~3 GB | ~3.5 GB | ~5 GB | ~8 GB |
| 26B A4B | ~8 GB | ~10 GB | ~14 GB | ~52 GB |
| 31B Dense | ~18 GB | ~21 GB | ~30 GB | ~62 GB |
小贴士： Q4_K_M 量化对大多数人来说是最佳选择。质量损失微乎其微，内存节省巨大。
别忘了 KV Cache
很多人踩的坑：模型权重不是唯一吃内存的东西。KV cache（存储对话上下文的缓存）也很大，尤其是 Gemma 4 支持超长上下文窗口的情况下。
社区反馈 31B 模型在 262K 上下文窗口下，KV cache 单独就要吃掉约 22 GB 额外内存。这还是模型权重之外的。
实用建议：
- 内存不够就缩短上下文长度：
# 在 Ollama 里设置较小的上下文窗口 ollama run gemma4:31b --ctx-size 8192 - 26B 和 31B 模型可以开启 KV cache 量化（Q8 或 Q4）来大幅降低内存占用
- E2B 和 E4B 就好得多——即使上下文较长，KV cache 也很可控
决策树：看你有什么硬件
"我就一个手机或树莓派" → E2B，其他的塞不下。
"我有 8 GB 内存的笔记本" → E4B，跑起来很流畅，还有余量给其他应用。
"我有 16 GB 内存的笔记本/台式机" → 追求速度选 E4B，追求质量选 26B（量化版），愿意等一等的话。
"我有 24 GB 以上内存或 8 GB 以上显存的 GPU" → 26B 是最佳选择。说真的，性价比太高了。
"我有工作站，24 GB 以上显存" → 31B Dense，极致质量。算力够就上。
"我想在服务器/云上用" → 26B 或 31B，看预算和延迟要求。
性能基准对比
| 基准测试 | E2B | E4B | 26B A4B | 31B Dense |
|---|---|---|---|---|
| MMLU | 良好 | 较好 | 一流水平 | 最佳 |
| HumanEval（代码） | 可用 | 良好 | 很好 | 优秀 |
| GSM8K（数学） | 基础 | 良好 | 强 | 最强 |
| 多模态（视觉） | 基础 | 良好 | 强 | 最佳 |
| 速度（M3 tok/s） | ~60 | ~35 | ~25 | ~8 |
26B MoE 是亮点——质量分接近 31B，速度快将近 3 倍。MoE 架构确实很有用。
量化怎么选？
从 Hugging Face 下载 GGUF 文件时你会看到 Q4_K_M、Q5_K_M、Q8_0 等选项：
| 量化等级 | 质量损失 | 体积缩小 | 建议 |
|---|---|---|---|
| Q4_K_M | 极小 | 约 75% | 默认首选 |
| Q5_K_M | 很小 | 约 65% | 空间够就选这个 |
| Q8_0 | 几乎无 | 约 50% | 追求质量 |
| FP16 | 无 | 原始大小 | 仅用于微调 |
我的建议： 从 Q4_K_M 开始。如果在你的使用场景中发现质量不够，再换 Q5_K_M。说实话，大多数人真的分不出来。
模型下载方法看这里：Gemma 4 下载安装全攻略。
下一步
- 准备下载？ → Gemma 4 下载安装全攻略
- 检查硬件够不够 → Gemma 4 硬件要求
- 跑不起来？ → Gemma 4 常见问题排查
- 想和其他模型比较？ → Gemma 4 vs Llama 4 或 Gemma 4 vs Qwen 3
