谷歌这次把 Gemma 4 放开了（一）

Wed, 08 Apr 2026 23:48:20 +0800

首发当天我本来想干的事很简单，找一个和 Gemma 3 对应得上的升级版，先下下来跑。

结果一圈看下来，人先有点傻眼。以前熟的 4B / 12B / 27B 那套名字没了，冒出来的是 E4B、26B A4B、31B。怎么说呢，这次谷歌真正改的，不只是模型大小，而是连“你该怎么理解这批模型”都一起改了。

这组文章我拆成三篇。当前这一篇只把发布信息、型号和协议讲清楚；下一篇写谷歌这次把 Gemma 4 放开了（二）：3060 12GB 本地跑下来，26B A4B 才是更现实的那个；最后一篇收在谷歌这次把 Gemma 4 放开了（三）：显存不够为什么会断崖，Mac 为什么能兜底却快不起来。

先把这次到底发了什么说清楚

去年 Gemma 3 是 2025 年 3 月 12 日发布的，这次 Gemma 4 是 2026 年 4 月 2 日发布，确实差不多隔了一年。

但这次不能再按“27B 的下一代是谁”这种思路去找。官方给的四个主要尺寸，已经不是单纯按总参数分档了。

型号	结构	关键数字	典型场景
`E2B`	Dense	2.3B effective，5.1B 含 embeddings，128K context	设备侧、超轻量本地
`E4B`	Dense	4.5B effective，8B 含 embeddings，128K context	原来 4B 这条小模型主线
`26B A4B`	MoE	25.2B total，约 3.8B active，256K context	消费级显卡、本地部署、兼顾质量和速度
`31B`	Dense	30.7B dense，256K context	追求上限、榜单和更稳质量

如果只看表面，你会觉得这次名字更乱了。可实际不是乱，是谷歌在刻意把三种路线拆开：

小模型设备侧，给 E2B / E4B
本地玩家路线，给 26B A4B
质量和上限路线，给 31B

这也是为什么很多人首发第一感觉会是“以前熟的升级路径断了”。不是没给升级版，是谷歌不想再只按总参数一个维度来卖货。

`E` 和 `A` 这次不是装饰字母

这批名字里，最容易让人犯嘀咕的就是 E4B 和 A4B。

E2B、E4B 里的 E，官方给的是 effective parameters。因为这两个模型用了 Per-Layer Embeddings，所以总参数量和真正有效参数量不是一个口径。说白了，谷歌是在提醒你，这不是过去那种“一个朴素的 4B dense 模型”。

26B A4B 里的 A，就是 active parameters。总盘子是 25.2B，但每个 token 实际激活的大约是 3.8B。这就是 MoE 路线的关键，模型总量不小，但运行时真正参与计算的那部分小很多。

所以这两个名字看着都带个 4B，含义却完全不同：

E4B 是小模型主线
26B A4B 是大盘子 MoE，本地推理时更像“激活规模只有 4B 左右”

这个命名方式一开始确实别扭，但它比过去更接近真实部署体验。

如果你以前常用 Gemma 3，这次该怎么找对应关系

我觉得这一代最容易误判的地方，就是把它当成 Gemma 3 的线性升级。

如果按使用习惯去找，差不多可以这么理解：

以前盯着 4B 跑轻任务的人，现在先看 E4B
以前盯着 27B 看模型上限的人，现在看 31B
以前想在消费级显卡上找一个“够强但不至于完全跑不动”的平衡点，现在重点看 26B A4B

这一层不先理顺，后面本地部署很容易跑偏。你会一边吐槽“怎么没有熟悉的升级版”，一边又把真正适合自己的那个型号错过去。

这次最值钱的更新，其实不是参数

真正让我觉得这次发布像是“终于想通了”的，不是榜单，而是协议。

老版本 Gemma 那套 terms 不能说完全没法用，但一直有点别扭。尤其是你如果关心这些事：

再分发
做蒸馏或二次包装
把模型放进自己的产品链路
做商业部署

你总得回头看看条款里那些 notice、下游限制、附带协议到底要怎么处理。

Gemma 4 这次直接改成 Apache 2.0，事情一下子就干脆了很多。核心意思非常明确：

可以商用
可以修改
可以再分发
义务主要回到保留 license、notice、修改说明这些开源世界熟悉的东西

说白了，谷歌这次不是单纯把模型开源了点，而是把“大家到底敢不敢放心拿去用”这件事一起做顺了。

社区第一波评价，基本也是两条线

如果只看第一周口碑，大致就是两个声音。

第一条线是，31B 确实能打。

官方给出的成绩已经很猛了。Arena AI 文本榜单里，31B 发布时排到开源模型前列，LiveCodeBench v6 也明显比 Gemma 3 27B 上去了一大截。很多人看到的第一反应就是，这个尺寸能打成这样，挺超预期。

第二条线是，26B A4B 很像给本地玩家留的一条活路。

它不是那种一眼看上去最风光的门面型号，但特别现实。尤其是你不是在机房里跑，而是在消费级显卡、工作站、甚至老机器上折腾，本地体验反而更容易落到这条线。

当然，首发第一波口碑也有个很现实的前提，生态还在追版本。模板、量化、推理框架、前端工具，很多还没完全跟上。所以现阶段你看到的评论，最好分两层看：

模型本体，这次确实进步很大
本地体验，还会继续受工具链成熟度影响

我对第一篇的结论

如果你只是想知道这次谷歌到底发了什么，其实一句话就够了。

Gemma 4 不再是“从小到大一排 dense 模型”的老思路，而是把设备侧、本地部署、质量上限这三条路分开了。E4B、26B A4B、31B 看着名字怪，背后对应的却是很现实的部署分工。

但如果你问我这次最大的变化到底是什么，我还是那句判断：

不是参数，不是榜单，而是谷歌终于把 Gemma 4 放进了一个大家更敢真用的开源协议里。

这一步，比表上的数字更重要。

下一篇我就不继续讲发布会口径了，直接回到本地机器上。还是那张没升级的 RTX 3060 12GB，为什么我最后先盯上的不是 31B，而是 26B A4B。

参考资料

写作附记

原始提示词

$blog-writer 谷歌时隔一年，发布了 Gemma4 模型，老规矩，尝试本地部署，还是那台没升级的台式 3060 12GB 英伟达显卡。这次赶上了首发，但是没找到以前常用 Gemma3 的升级版本，但是多有个类似的版本 GemmaE4b，你先搜索介绍下，本次发布了的所有型号，里面的缩写字母什么意思，然后搜索下网上关于 Gemma4 的评价，关键是，本次谷歌更新该了模型的协议，大家用起来的限制更少了。最大的惊喜，我常用的测试题：写一段 C++ 代码，在控制台输出五角星，去年的小参数开源模型都没搞定这个问题，谷歌这次搞定了，第一版给出答案，完全超出我的意料，它知道了我的陷阱，控制台输出五角星很麻烦，它直接硬编码了一个五角星的字符串，控制台直接输出。这是原文：由于在纯文本的控制台（Console）中通过数学逻辑直接绘制一个具有精确几何结构的五角星非常复杂（涉及到坐标系转换和像素填充），最经典且视觉效果最好的方法是使用 ASCII Art（字符艺术）。在我去强制要求进行计算以后，它也搞定了，通过数学计算，成功的绘制了五角星。以前常用 Gemma4 进行本地的翻译任务，当前博客很多历史文章的多语言版本就是这样来的。本地测试用的：gemma-4-26b-a4b 模型，31b 版本属实太慢了。但是看测评 31b 效果很不错，排行榜的成绩很好。同时刷论坛，我认知到了，显存如果不够，模型参数上去了，生成 token 的速度会断崖式下降，你解释下为什么？Mac 不会有这个问题，它走的是统一内存，解释下技术原因。还有就是，如果需要速度，那还是 英伟达大显存的显卡才行。Mac 的方案能兜底，但是速度上不去。本次的内容很多，你评估下是否拆成系列文章。

写作思路摘要

第一篇只负责把“这次到底发了什么”和“协议为什么重要”讲清楚，不再抢本地体验的话题。
先把型号路线拆开，再解释字母含义，逻辑顺序比上一版更直。
协议部分保留了“这次真正放开的不是参数，是使用限制”这个判断。
社区评价只做收束，不再把太多本地体验提前写进来。

Apache on 向叔记事簿