谷歌把 Gemma 4 端上桌：模型更能打了，但真正的大动作是“松绑”许可证

谷歌又一次把“开放模型”这张牌翻了出来。

这次的主角是 Gemma 4。表面上看，它是一组更强、更轻、更适合本地运行的新模型；但如果你把新闻再往里读一层，会发现真正让开发者眼前一亮的，未必是 31B、26B 这些参数数字，而是谷歌终于把过去那套让人皱眉的自定义许可证扔进了历史回收站，改用 Apache 2.0。

说得直接一点：Gemma 4 的升级当然重要，但许可证的变化，才是这条新闻里最像“行业信号弹”的部分。

谷歌终于明白，开放模型不能只开放一半

过去一年，谷歌的 Gemini 闭源模型进步很快，能力肉眼可见地提升，推理、代码、视觉理解都一路猛冲。但问题也很现实：你能用 Gemini，多半得按谷歌的规则来。模型跑在谁的云上、数据怎么处理、部署边界在哪儿，主动权并不完全在开发者手里。

Gemma 诞生的意义，本来就是给开发者另一种选择：我不一定非要把数据送去云端，我也不一定愿意被平台锁死，我想在自己的机器、自己的产品、自己的业务流程里，安安静静地把模型跑起来。这个愿望，在企业客户那里尤其强烈。医疗、金融、政务、制造业这些行业，对“数据别出门”有一种几乎本能的执念。

可惜，之前几代 Gemma 虽然叫“开放权重”，许可证却总让人心里发毛。谷歌此前的自定义条款里，有一套禁止用途规则，而且谷歌可以单方面更新；更麻烦的是，开发者还得把这些规则继续传导到所有基于 Gemma 的项目里。对很多团队来说，这就像你租了个挺好的房子，结果房东告诉你：以后怎么装修、谁能进门、家具摆哪儿，我都保留随时改规则的权利。房子再好，也住得不踏实。

现在切到 Apache 2.0，气氛一下子就不一样了。这个许可证是开源世界的“通用语言”之一，开发者熟，法务也熟，商业使用边界清晰，不会今天一个说法明天一个说法。你可以说，谷歌终于意识到，所谓开放，不是把模型权重放出来就算完事，而是要让人真敢拿去做产品、做服务、做生意。

Gemma 4 不只是变大，也在认真变“能落地”

回到模型本身，Gemma 4 这次给了四个版本：偏大的 26B MoE 和 31B Dense，以及面向移动和边缘设备的 E2B、E4B。这个组合很像谷歌在说：我不只想做实验室里的模型，我还想覆盖手机、单卡工作站、企业本地部署，甚至树莓派和 Jetson Nano 这种边缘设备。

26B MoE 的思路很有代表性。它总参数 260 亿，但推理时只激活 38 亿参数，这就是混合专家模型最讨巧的地方：看上去块头不小，真正干活时却尽量节省成本。对本地推理而言，这一点非常重要。毕竟大家喜欢“端侧 AI”这个词，不代表大家真的人均一块 H100。谷歌当然提到它能在单张 80GB H100 上以 bfloat16 运行，但这话多少有点像在说“这车挺省油的，只要你先买得起车库”。真正关键的是，量化之后它能更好地落到消费级显卡上，这才是开发者会认真计算的现实账本。

31B Dense 则更像是追求质量的版本，谷歌的意思也很明确：它不是一味拼速度，而是给那些愿意做微调、愿意针对场景打磨模型的团队准备的。这里能看出谷歌的产品思路正在变得更务实——不是拿一个大一统模型包打天下，而是承认不同设备、不同场景需要不同权衡。

小模型这边更有意思。E2B 和 E4B 被设计给手机和轻量边缘设备使用，主打低内存、低功耗和接近零延迟。谷歌还特意提到 Pixel 团队和高通、联发科一起做了优化，这不是一句随口的合作宣传，它透露的是另一层现实：端侧 AI 的竞争，早就不只是模型公司之间的竞争，而是模型、芯片、系统、工具链一起卷。模型再聪明，落不到 NPU 上、跑不稳、耗电大，用户也只会觉得“AI 又卡又烫”。

本地 AI 的吸引力，不只是省钱，更是“数据别乱跑”

Gemma 4 这次强调了几个能力方向：推理、数学、遵循指令、代码生成、视觉理解、语音识别，以及对 agent 工作流的支持，比如原生函数调用、结构化 JSON 输出、工具/API 指令。这些词最近你在几乎所有大模型发布会上都会听到，听多了甚至会有点审美疲劳。

但放到本地运行这件事上，它们就有了不一样的分量。

举个最实际的例子：如果一个企业想做内部知识库问答、合同解析、发票 OCR、图表理解，或者让模型调用内部 API 自动处理报销、库存、审批，它往往不只关心模型答得好不好，还关心数据能不能完全留在内网。云上大模型确实省心，能力也普遍更强，但只要涉及隐私、合规或商业机密，本地部署就会从“备选项”变成“硬要求”。

这也是为什么 Gemma 4 的上下文窗口、视觉处理和代码能力都显得格外关键。边缘版本 128k，上位版本 256k，在本地模型里算得上相当体面，虽然还远不及云端 Gemini 动辄 100 万 token 的上下文，但对于很多文档分析、代码仓阅读和工作流代理任务，已经够用了。谷歌实际上是在押注一个趋势：不是所有 AI 都会回到浏览器标签页里的聊天框，越来越多 AI 会藏进企业软件、手机功能和离线设备里，悄悄工作，不露脸，但天天被用。

从这个角度看，Gemma 4 更像是一套“AI 基础零件”，而不只是一个拿来聊天的模型。

和 OpenAI、Meta 比，谷歌这一步来得不算早，但很关键

如果把时间轴拉长，你会发现谷歌在开放模型这件事上一直有点别扭。它既想参与开源生态，又始终保留着大公司的谨慎和控制欲。相比之下，Meta 的 Llama 虽然也常因“到底算不算真正开源”引发争议，但至少在生态扩散上很激进；Mistral 则更像欧洲创业公司的典型打法，靠轻快、开放和高性价比抢开发者；中国厂商如智谱、月之暗面等也在快速推进开源或开放权重路线，想在推理成本和中文场景里拿下更多地盘。

在这种局面下，谷歌如果继续拿一套“开放但不完全开放”的规则来推 Gemma，其实会越来越尴尬。开发者不是只看榜单，也不是只看 ELO 分数。模型再强，如果法务审核过不去，或者后续商用风险不明确，项目负责人也不会拍板。尤其在今天，企业做 AI 已经从“试试看”进入“要上线、要交付、要担责”的阶段，许可证不再是页脚小字，而是采购和部署会议上的核心议题。

所以，Gemma 4 切换到 Apache 2.0，我愿意把它看作谷歌的一次战略纠偏。它不一定能立刻让 Gemma 成为最火的开放模型，但至少拆掉了原来那道最劝退人的门槛。

当然，争议不会因此消失。一个值得思考的问题是：当越来越多高质量模型以更宽松的方式开放，行业究竟会更繁荣，还是会更碎片化？开发者的选择变多了是好事，但模型、框架、推理引擎、芯片适配都在分叉，未来会不会出现新的兼容性混乱？这是开放生态必然要付出的代价之一。

谷歌已经把下一步写在手机上了

这条新闻里还有一个容易被忽视、但很有后劲的信号：Gemini Nano 4 要来了，而且会直接基于 Gemma 4 的 E2B 和 E4B。

这意味着 Gemma 不再只是一个给开发者“试用”和“二次开发”的开放系列，它其实也是谷歌手机端 AI 的底层母体。过去 Pixel 手机上的本地 AI 功能，比如诈骗电话识别、短信风险提示、通话摘要、笔记总结，已经让用户尝到一点“AI 不上云也能干活”的甜头。现在谷歌把 Gemma 4 的轻量版本与下一代 Nano 直接打通，本质上是在做一件很聪明的事：先用开放生态帮自己打磨模型，再把成熟能力回灌到消费级产品里。

这和苹果、三星接下来会走的方向也很像。未来手机 AI 的胜负手，未必是谁家云模型最会聊天，而是谁能把端侧能力做得更稳定、更省电、更像系统原生功能。用户不会天天夸一个模型有 256k 上下文，但会马上感知“这台手机怎么总结语音这么快、识别诈骗这么准、而且不用联网”。

如果说前两年 AI 行业都在拼“谁更像一个无所不能的超级助理”，那么 2026 年开始，另一条路线正在浮出水面：谁能把 AI 变成一种不打扰人的基础设施。Gemma 4，恰好站在这条路线的路口上。

谷歌已经把模型放到了 AI Studio、AI Edge Gallery、Hugging Face、Kaggle 和 Ollama 上，姿态很明确：你要自己跑，可以；你要去 Google Cloud 付费托管，也欢迎。这套打法很谷歌——一边讲开放，一边也没忘记给自家云业务留好入口。

这倒也不虚伪，反而很真实。今天的大模型世界，没有谁真的只靠情怀做开放。问题从来不是公司有没有商业算盘，而是它在打算盘的时候，愿不愿意给开发者足够的自由。Gemma 4 至少在这一步上，走对了。