Gemma 4：Google的开源MoE模型，从树莓派到4090全覆盖

Apache 2.0无商业限制，4个型号覆盖手机到服务器，5亿+下载量——Gemma 4是Google给开源社区交出的最诚意答卷。

Gemma 4：Google终于把Gemini技术开源了

2026年3月31日，Google DeepMind发布了Gemma 4。如果你关注开源模型圈，这个时间点很有意思——正好卡在Qwen 3.6（4月15日）和DeepSeek V4（4月24日）之前。

Gemma 4不是Gemma 3的简单升级。它的底层架构直接继承了Gemini 3的技术路线，做了三件以前Google开源模型没做过的事：

1. MoE架构下放：26B版本用128个专家，激活8个+1个共享专家，有效参数3.8B
2. 多模态输入：不再是纯文本模型，支持图片输入
3. 真正的无限制开源：Apache 2.0许可证，没有MAU上限，没有可接受使用政策，商用随便用

数学基准的飞跃最能说明问题：从Gemma 3的”5道题对1道”到Gemma 4的”5道题对4.5道”——这不是渐进式改进，是质变。

5亿+总下载量、10万+自定义变体，这些数字说明开发者已经用脚投票了。

四个模型怎么选：从树莓派到RTX 4090

Gemma 4最聪明的地方是一次发布四个型号，覆盖从手机到服务器的全部硬件层级。选错型号，模型跑起来会”感觉坏了”——要么慢到没法用，要么直接OOM。

型号	有效参数	上下文	Q4最小内存	最佳硬件
E2B	~2.3B	128K	~1.5GB	手机、树莓派、IoT
E4B	~4.5B	128K	~5GB	Mac M系列8GB、笔记本
26B A4B	~3.8B	256K	~14-18GB	RTX 3090/4090、Mac 16GB+
31B Dense	~30.7B	256K	~20GB	RTX 4090 24GB、Mac 32GB+

关键理解：26B和E4B的有效参数差不多（3.8B vs 4.5B），但26B的MoE架构让它在复杂任务上表现更好——128个专家虽然只激活8个，但每次激活的专家组合不同，相当于”按需调配”不同的能力模块。

选型建议

• A7Z/树莓派：E2B，1.5GB内存轻松装下
• 8GB笔记本/Mac：E4B，日常对话和简单编程够用
• RTX 3090/4090：26B MoE，Agent编程的甜点
• 需要极致质量：31B Dense，近GPT-4级别的推理能力

E2B在A7Z上：真能跑

Gemma 4 E2B对我们这种全志A733 ARM64平台的用户来说是重大利好——2.3B有效参数，Q4量化后约1.5GB，A7Z的2GB内存完全能装下。

# Ollama一键拉取
ollama pull gemma4:2b

# 或者用llama.cpp
./llama-cli -m gemma-4-e2b-q4_k_m.gguf -c 8192 -ngl 0

在A7Z上实测E2B Q4_K_M：

• 内存占用：~1.4GB（含上下文）
• 推理速度：约5-8 tokens/s
• 128K上下文：A7Z跑不了那么长，4-8K上下文更实际

速度比Qwen2.5-1.5B稍快，因为有效参数虽然多但架构更高效。日常对话和简单问答完全够用，复杂编程还得靠更大的模型。

26B MoE：128个专家只激活8个

Gemma 4 26B是这代最值得玩味的型号。它的MoE设计思路和Qwen 3.6不太一样：

维度	Gemma 4 26B	Qwen 3.6-35B-A3B
总参数	26B	35B
活跃参数	~3.8B	~3B
专家数量	128小专家	较少大专家
每token激活	8+1共享	约3-4个
稀疏比	~6.5:1	~12:1
上下文	256K	200K

Gemma的思路是”多专家细粒度”——128个小专家，每个专注于不同的知识领域，按需激活8个。Qwen的思路是”少专家大容量”——更少的专家，但每个容量更大，稀疏比更高。

谁更好？ 实测中两者在Agent编程任务上咬得很紧。Qwen 3.6在SWE-bench上略高（73.4 vs 约68），但Gemma 4的多模态能力是Qwen目前没有的。对于需要看图理解的Agent任务（比如”帮我看看这个报错截图”），Gemma 4更合适。

本地部署实战：Ollama一键拉

Gemma 4的本地部署体验是目前开源模型里最好的之一，Ollama已经第一时间支持：

# 安装Ollama（如果还没装）
curl -fsSL https://ollama.com/install.sh | sh

# 拉取Gemma 4
ollama pull gemma4:2b     # E2B
ollama pull gemma4:4b     # E4B  
ollama pull gemma4:26b    # 26B MoE
ollama pull gemma4:31b    # 31B Dense

# 直接跑
ollama run gemma4:26b

如果你更喜欢llama.cpp的精细控制，GGUF量化文件也已经在HuggingFace上线：

# 下载Q4_K_M量化版
wget https://huggingface.co/google/gemma-4-26b-it-q4_k_m-GGUF/resolve/main/gemma-4-26b-it-q4_k_m.gguf

# 启动llama-server
llama-server -m gemma-4-26b-it-q4_k_m.gguf 
  --host 0.0.0.0 --port 8080 
  -c 16384 -ngl 99

RTX 3090/4090上26B MoE Q4_K_M的推理速度约60-80 tokens/s，31B Dense约30-40 tokens/s。对于Agent编程场景，26B MoE性价比更高——同样的硬件，速度翻倍，质量损失很小。

和Qwen 3.6对比：MoE对决

两者是目前3B活跃参数级别的两大MoE选手，选择取决于场景：

维度	Gemma 4 26B	Qwen 3.6-35B-A3B
编程Agent	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
多模态	⭐⭐⭐⭐⭐	⭐⭐⭐
长上下文	⭐⭐⭐⭐⭐ (256K)	⭐⭐⭐⭐ (200K)
思维保留	❌	✅ preserve_thinking
本地速度	⭐⭐⭐⭐ (~60 t/s)	⭐⭐⭐⭐⭐ (~80 t/s)
边缘设备	⭐⭐⭐⭐ (E2B/E4B)	⭐⭐⭐ (只有35B)
许可证	Apache 2.0	Apache 2.0

简单选法：

• 纯编程Agent → Qwen 3.6（思维保留+SWE-bench更高）
• 需要看图+编程 → Gemma 4 26B（多模态输入）
• A7Z/树莓派 → Gemma 4 E2B（Qwen没有小型号）
• 需要最高质量 → Gemma 4 31B Dense（稠密模型天花板）

我的实际方案：A7Z上跑Gemma 4 E2B做日常问答，API走Qwen 3.6-Flash做编程Agent。本地+API混合，覆盖全场景。

---

Google用Gemma 4证明了一件事：开源不是把模型丢出来就完事，而是要给不同硬件层级的人都能跑起来的选择。从树莓派上的E2B到4090上的31B Dense，从纯文本到多模态，从Apache 2.0无限制到Ollama一键部署——这才是开源应该有的样子。

---

by 数码罗记·godsun.pro