谷歌Gemma 4以小博大：把31B模型塞进手机，端侧模型迎来分水岭

Gemma 4：一次“小而精”的突袭，开源格局再添变数

发布才几个小时，Gemma 4 就已经把开发者社区的情绪拉满了。

北京时间 4 月 3 日凌晨，Google 推出了新一代开源模型 Gemma 4，包括 E2B、E4B、26B（MoE）、31B 「一门四杰」。其中，E2B、E4B 两个较小模型直接可以在手机、树莓派等设备上部署运行，而 26B、31B 两个较大模型也只需要一张消费级显卡就能跑起来。

不同于闭源的 Gemini 大模型走的是「力大砖飞」路线，Google 在 Gemma 开源模型的思路上，一直坚持「小而精」。

但 Gemma 4 给人的第一印象，还是有点不按剧本来。参数规模没有膨胀，结构也谈不上碘伏，可是在一系列 benchmark 里，Gemma 4 却能逼近甚至超越更大一档规模的模型。其 26B、31B 版本在 AI 竞技场（人工对话打分）已经比肩一众国产开源模型，甚至超越了 685B 的 DeepSeek V3.2 以及 397B 的 Qwen 3.5。

这比国产模型还要卷。

过去在这个战场上，Qwen 几乎就是「小而精」模型的代名词，但 Gemma 4 这次的进步确实太大了。不只是在 AI 竞技场这种偏「AI 聊天」的真实场景测试中有惊艳的表现，Gemma 4 还是少有从一开始就面向本地 Agent 工作流设计的模型，也支持多模态。

在这么小的模型规模下，Gemma 4 却做到了超预期的性能和能力，也难怪 AI 研究工程师 Sebastian Raschka 在 X 上说，「Gemma 4 是一个巨大的跨越。」

但很多人忽略的一个关键，还在于开源协议的切换。这次 Google 终于想通了，放弃了自家那套备受诟病的 Gemma 开源协议，Gemma 4 全系换上了主流的 Apache 2.0 协议。这意味着，从个人开发者到企业用户，都可以放心地商用和再分发。

开源 AI 模型的格局，难道又要再变一次？

免费、无 API，大模型不大但好用

先从 26B 和 31B 这两个模型说起。

按照过去两年的直觉，这个参数规模几乎不在第一梯队。开源世界里，动辄就是百亿、千亿，甚至像 DeepSeek V3.2 这种 600B+ 级别的模型，才有资格谈「对标闭源」。但 Gemma 4 的这两个模型，上来就把这套逻辑打乱了。

26B 和 31B 的表现，不只是「能打」，而是已经开始稳定贴近甚至超过更大体量的模型。Google DeepMind 创始人兼 CEO Demis Hassabis 就说得很直白，Gemma 4 就是「同级别（参数规模）最好的开源模型」。

需要一提的是，Gemma 4（26B）采用的是 MoE 架构，总参数 26B，但实际激活规模要小得多。这种设计带来的直接结果不是纸面参数的好看，而是一个更现实的变化：在很多任务里，它用小模型的成本，打出了接近更大模型的效果。

图片来源：英伟达

事实上，Gemma 4 的优势，不在绝对能力，而在「智能密度」，或者说是每个参数的效率最大化。

26B 和 31B 就是最直观的例子，在实际测试里就能感受到这种密度和效率。在一些开发者的早期测试中，它反而比更大的模型更「好用」，因为它不只是能做，还能稳定、快速地做。简言之，能够承担更复杂的任务和带来更好的表现。

Gemma 4 推出后，X 上就有独立开发者就在 RTX 5090 上本地部署了 31B，不仅能快速完成代码生成、多模态理解任务，整体表现已经相当可用。至于 Gemma 4（26B），在 Mac mini（M4 16GB）上就能很好地部署运行 。

更重要的是，Hacker News 社区还有人指出，测试将 Gemma 4 接入 code-agent harness（30K+ 上下文）的表现很好，明显快于 Qwen 同级模型。

免费、无需 API。Gemma 4 的 26B 和 31B，并不是最强的开源模型，但已经足够强，同时又足够「轻」，甚至可以真正在本地做事，用极低的使用成本在本地处理一系列低复杂度的 Agent 任务。

这也是为什么很多开发者在讨论 Gemma 4 时，很少再纠结它和 GPT、Claude 的差距，而是开始讨论另一件事：这样体量的模型，能不能成为本地 Agent 的核心。因为一旦这个问题的答案变成「可以」，那整个开源模型的价值，就不再只是替代 API，而是开始接管一部分真实的工作流。接下来一段时间，相信这也是 Gemma 4 的重点。

联手高通、联发科，小模型引发本地 Agent 浪潮？

但这一代 Gemma 4，不只看 26B、31B，把视角往下拉到 E2B、E4B，会发现 Google 还想更进一步把端侧 AI 塞进手机等边缘设备。

先说一点。这两个模型不是可以在端侧跑，而是从一开始就是为端侧设计的。Google 在最新描述里就强调，E2B 和 E4B 的目标是「重新定义端侧实用性」，优先考虑的是低延迟、多模态和系统级集成，而不是参数规模。这句话背后其实很明确，它们不是缩小版的大模型，而是另一类产品。

这类产品最关键的一点，是把「本地 AI」从概念变成了一个可以落地的工程路径。E2B 在量化之后可以压到 1.5GB 以内，在树莓派 5 上也能跑出可用的推理速度，prefill 可以到 100 tokens/s 以上 。这意味着一个不依赖云、不走 API 的 AI 系统，开始可以在极其有限的硬件上运行。

手机上就能本地部署，图片来源：Google

更重要的是，这件事并不是 Google 一家在做。为了让这两个模型真的跑起来，Google 这次是把整条硬件链路一起拉进来了，从 Pixel 团队，到高通、联发科，再到 ARM、NVIDIA，都参与了优化 。换句话说，这还是一次面向手机和边缘设备的系统级协同。

这也解释了为什么 E2B 和 E4B 的意义，和过去的小模型完全不一样。以前的小模型，本质是「能力不够，只能在端侧跑」。现在这两个模型更像是「能力刚好够，而且专门为端侧优化」。它们不仅支持文本，还原生支持图像、音频输入，甚至可以直接参与多步 Agent 工作流 ，支持 Skill。

可以安装 App 使用，图片来源：Google

真正的变化在这里开始显现。过去讨论手机上的 AI，大多还停留在「调用云端模型」，本地只负责做一些简单推理。但 Gemma 4 这一步，相当于是把更完整的 AI 能力，直接搬进手机等设备里，甚至是脱离网络在本地运行 Agent 。尤其是在豆包手机助手引发云端 AI Agent 的隐私安全顾虑之后，这对手机意味着什么，其实不难想象。

而当模型可以直接运行在 SoC 的 NPU 上，当系统级组件可以调用本地模型完成推理、生成、甚至多步任务执行，AI 也会更进一步变成操作系统的一部分。所以 E2B 和 E4B 真正让人兴奋的地方，不是它们的性能，而是让人看到端侧 AI 的潜力还有巨大的挖掘空间。而这条路径，一旦跑通，影响的就不只是模型本身，而是整个终端生态。

开源 AI 模型，在 Agent 时代重新洗牌

最早，Meta 用 Llama 奠定了开源模型生态的方式，但很快，从 Qwen、DeepSeek 到去年 Kimi、MiniMax 的相继开源，中国公司已经主导了全球开源 AI 的大模型格局，也在性能、成本和落地能力上同时逼近甚至反超闭源模型。

也正是在这个背景下，再看 Google 的动作，就不只是一次模型更新了。

Gemma 过去一直处在一个略显尴尬的位置，名义上开源，但协议并不彻底，企业用起来有顾虑，开发者也很难放心做二次分发和深度定制。这一次，Gemma 4 直接换成 Apache 2.0，本质上是把最后一道门槛拆掉了，从「可以用」变成「可以放心用」。

图片来源：安卓

这一步的意义，比模型本身更大。因为它等于明确了一件事，Google 不只是要做模型，还要重新进入开源生态。这也让它的整体策略变得更清晰了。一边是 Gemini，继续对标 GPT 和 Claude，守住能力上限和商业化；另一边是 Gemma，面向开发者、面向本地部署、面向生态扩展。闭源和开源，不再是取舍，而是分工。

过去几个月，真正把行业注意力拉走的，是 Agent。无论是 Anthropic 推出的 Claude Code，还是开源社区围绕 OpenClaw 搭起来的一整套工具链，大家讨论的焦点已经不再是对话、多模态，而是「干活」。

图片来源：OpenClaw

在这波变化里，Gemini 的存在感其实不算强。能力依然在第一梯队，但在开发者心智里，它并没有成为 Agent 的首选底座。这也是为什么你会看到越来越多开发者开始转向开源模型，哪怕能力略逊一筹，也更愿意换取可控性和可部署性。

Gemma 4 出现在这个时间点，就显得很微妙了。

一方面，它补上了 Google 在开源上的短板，尤其是协议问题解决之后，开发者终于可以真正把它当作基础设施来用。另一方面，它又刚好踩在「本地 Agent」这个新需求上，无论是 26B、31B，还是 E2B、E4B，都在试图回答同一个问题：能不能把一部分 AI 能力，直接搬到设备上运行。这未必是最激进的一步，但很可能是最现实的一步。

开源模型的竞争，正在从「谁更强」，变成「谁更能被用起来」。而在这个新的牌桌上，Google 终于重新坐了下来，只是这一次，它不再是发牌的人，而是必须重新争夺筹码的玩家。