Gemma 4 与千问 3.6 根本不在一条赛道

开放权重模型一多，围观者就习惯把它们摆成一场赛马：谁排名靠前谁就该用，落后的那个自动被归为“慢”或者“不能用”。How-To Geek 编辑 Jorge A. Aguilar 在 8 月 9 日发表的一篇文章里指出，这套逻辑一旦落到真实使用场景中就会立刻散架——因为有些模型压根不是为同一份工作而生的。

谷歌 DeepMind 的 Gemma 4 和阿里巴巴的通义千问 3.6，恰好是最典型的一对例子。

一个装进设备，一个住在云上

Gemma 4 的设计目标是在尽可能多的终端上高效运行：手机、笔记本、台式机。它的 12B 变体可以直接吃进原始音频和图像数据，不需要额外挂载独立的编码器模型。

千问 3.6 则是奔着云端基础设施和长链条分析任务去的。它采用混合注意力结构，能在不撑爆内存的前提下吞下巨量文本。用一句话概括这组差异：前者想当一个快速、私密、跑在本机上的助手；后者想当一个坐在云端、有耐心跟难题死磕的工程师。

两个模型的档位划分也印证了各自的取向。Gemma 4 于 4 月 2 日发布，提供从端侧优化的 E2B、E4B，到 12B、26B 混合专家、31B 稠密模型在内的多个尺寸。千问 3.6 的开放权重版本走的是另一条路线：35B-A3B 混合专家模型每个词元只激活约 30 亿参数，另有一款 27B 稠密模型，原生上下文达到 262144 个词元。两个家族目前都采用 Apache 2.0 许可，这一项上并不构成差异。

上下文窗口决定了能干什么活

真正把两者拉开距离的，是上下文容量和推理方式。

云端的千问 3.6 Plus 拥有 100 万词元的上下文窗口，并且搭配一个常驻运行的推理模式——模型会先把问题想一遍再作答。在部分会话中它还会启用思考保留模式，记住此前几轮的推演过程，从上一次的结论继续往下走，而不是每次都从零开始、重复踩同一个坑。

这个能力在特定场景里价值极高。调试一个庞大的代码库时，100 万词元的窗口可以一次性装下整个仓库、接口文档和错误日志，让模型在几百个文件之间追踪同一个缺陷而不丢线索。

Gemma 4 的上下文上限则视变体而定，落在 128K 到 256K 之间，装不下那么多东西。在较长的会话里，它还容易丢失被指定的角色设定，陷入需要整段重启才能跳出的重复循环。

成本与隐私的账要分开算

许可与账单的差异同样值得留意。千问 3.6 的部分本地变体以免费开放许可发布，企业可以自行部署而无需申请授权；但更高端的云端版本跑在付费租用的算力上，用得越狠账单越长。

Gemma 4 走的是相反的路径：拿到一份副本部署在自己的硬件上，一次配置完成后没有持续开销，输入的任何内容都不必离开本机——对隐私敏感的场景，这一点的分量远大于跑分。想先试一试的用户可以在 AI Studio 上体验 Gemma 4，本地部署则通常经由 Ollama 完成。Gemma 早期版本曾附带较多使用限制，如今这一层顾虑已经解除，小团队和独立开发者不必再为许可条款专门请教律师。

别再评“史上最强”了

Aguilar 在文章结尾给出了一个明确判断：把 Gemma 4 和千问 3.6 当成争夺同一顶王冠的对手，本身就理解错了题目。依据排行榜名次或品牌认知度二选一，大概率会选错——因为它们要解决的根本是两类问题。同样的道理也适用于 ChatGPT、DeepSeek 背后的模型。

会不会有一天出现一个足够大的模型，把端侧任务和深度仓库分析统统吃下？他认为这个设想并不离谱，但短期内看不到。一个能在 100 万词元的代码里做推理的模型，放到本地跑必然带来明显延迟；能撑起这种上下文窗口的云端模型，背后需要真金白银的服务器集群，还要面对网络延迟、隐私顾虑和运维成本——对普通用户来说很难承受。

所以结论不是“哪个更好”，而是“哪个不适合当前这项任务”。把它们当成两把用途不同的工具对待，两者都会变得更好用。

来源：How-To Geek