Google Gemma 4：把多模态、推理和端侧效率塞进一套模型

大模型的升级，常被简化成一场参数竞赛：更多参数、更高分数、更贵的推理。但 Gemma 4 技术报告给出的方向恰好相反——真正困难的，是让模型同时更会推理、更懂图像与声音，还能在不同硬件上跑得动。

论文名称： Gemma 4 Technical Report 论文链接：https://arxiv.org/abs/2607.02770

这次发布覆盖从有效参数量 2.3B 到 31B 的五种规格，既有稠密模型，也有总参数 26B、每次只激活约 3.8B 的混合专家模型。所有规格都支持文本、图像和音频，并加入了可开关的 thinking mode。

Gemma 4 的主线不是“把一个模型做大”，而是把能力、上下文与部署成本重新装进同一个系统设计里。

一套模型，先适配五种算力预算

Gemma 4 包含 E2B、E4B、12B、26B-A4B 和 31B。其中，E2B 与 E4B 使用逐层嵌入，虽然总参数分别约为 5B 和 8B，实际参与主要计算的有效参数量约为 2.3B 和 4.5B。

26B-A4B 则走另一条路：它拥有约 26B 总参数，却只激活约 3.8B。这让产品团队可以在稠密小模型、统一多模态模型和 MoE 之间，按设备内存、吞吐量与能力目标选择不同落点。

值得注意的是，这并非五个尺寸完全复制同一套结构。小模型保留独立的视觉、音频编码器；26B-A4B 与 31B 使用更大的视觉编码器；12B 则直接换了一种多模态范式。

这种“按尺寸改变结构”的做法，也说明 Gemma 4 更像一组面向不同部署边界的工程解，而不是把同一配方机械缩放。小模型重视现成编码器带来的能力密度，MoE 型号把总知识容量与单次激活成本拆开，31B 则保留稠密结构的简单性。

12B 的激进实验：扔掉独立编码器

传统多模态大模型往往像一支接力队：视觉编码器先把图像变成特征，音频编码器再处理声音，最后把结果交给语言模型。每多一种模态，就多一套权重、显存占用与运行时碎片。

Gemma 4 12B 从头训练了一套统一的 encoder-free 架构。图像被切成 48×48×3 的 RGB patch，再通过一个约 35M 参数的大矩阵投影进入语言模型嵌入空间；二维坐标位置嵌入负责保留空间关系。

音频路径更直接：16kHz 原始音频按 40ms 切片，每段形成 640 维向量，然后直接投影进语言模型。论文的意思并不是“模型不再需要任何前处理”，而是不再依赖独立、重型、冻结的视觉与音频编码器。

这项设计最有产品意味的地方，不只是少了几亿参数。它还可能减少多模块加载、跨设备放置和内存碎片。不过，“运行时一定更快”属于合理推断，论文并没有给出一组完整的 encoder-free 端到端消融来证明所有场景都获益。

长上下文，不靠全局注意力硬撑

上下文变长后，最先爆炸的往往不是模型参数，而是 KV cache。Gemma 4 没有让每一层都做昂贵的全局注意力，而是让局部滑动窗口与全局注意力交替出现：E2B 的比例是 4∶1，其余型号是 5∶1。

在全局层中，模型还使用 p-RoPE，其中 p＝0.25，并在多数型号里让 value 直接复用 key。论文称，这组设计可让全局 KV cache 占用最多降低 37.5%。它体现了一种很实用的取舍：大部分 token 只需要看近邻，少数全局层负责跨越长距离传递信息。

结果也显示长文本能力明显提升。在不启用 thinking mode 的 128k 上下文评测中，Gemma 4 31B 的 RULER 准确率为 96.4，Gemma 3 27B 为 66.0；LOFT Text Retrieval 的 Recall@k 则从 8.6 提升到 79.5。

速度与内存：把优化做到生成路径里

Gemma 4 随模型训练了一个小型自回归 MTP drafter，用于 speculative decoding。主模型先提供上一时刻的高层激活与 KV cache，drafter 再连续猜测未来 token；主模型一次验证多个候选，从而减少昂贵的完整解码步数。

对 E2B 和 E4B，drafter 还把输出投影从完整的 262k 词表，缩到经过聚类筛选的 4096 个候选。这不是让小模型代替主模型回答，而是用便宜的草稿换取更少的主模型调用。

另一条路线是量化感知训练。论文提供适合移动端的 int2、int4 混合权重量化，以及常见的 Q4_0 版本。以纯文本 32k 上下文为例，31B 权重从 64.0GB 降到 19.2GB，12B 从 24.0GB 降到 7.65GB；量化后的 int8 KV cache 仍需额外占用内存。

这些数字说明，模型权重被压缩，并不等于长上下文免费。 在端侧部署里，权重、KV cache、视觉或音频模块、运行时临时张量，都必须放进同一张内存账单。

Thinking mode：能力提升，也带来评测陷阱

Gemma 4 的指令模型可以通过控制 token 打开 thinking mode，先生成一段 reasoning trace，再给最终答案。论文把它用于数学、编程、科学问答等推理密集任务，并报告了显著提升。

例如，31B 在无工具的 AIME 2026 上得到 89.2，12B 得到 77.5；LiveCodeBench v6 上分别为 80.0 与 72.0。Arena 文本榜单的 2026 年 6 月 19 日快照中，31B 得分 1451，位列开放权重稠密模型首位。

但这里必须踩一下刹车。表格中的 Gemma 4 默认开启 thinking，而对照的 Gemma 3 27B 明确是 non-thinking。这能证明最终系统更强，却不能单独量化架构升级、训练数据与额外推理 token 各贡献了多少。 reasoning trace 也不应自动被视为模型内部推理的忠实解释。

多模态进步，不只发生在 12B

小型号仍使用独立音频编码器，但它从上一代的 680M 参数缩到 305M。量化后，编码器磁盘占用从 390MB 降到 87MB。与此同时，论文报告 E2B 与 E4B 的语音翻译相对提升分别为 12% 与 10%，转写相对提升分别为 17% 与 12%。

视觉侧则支持可变长宽比，并把最大视觉 token 数设为 70、140、280、560 或 1120。这意味着同一个模型可以在图像细节与推理成本之间选择档位，而不是把所有图片强行压成固定方形。

具体做法是先尽量保持原图比例，再把目标尺寸向下对齐到视觉 patch 与池化窗口的整数倍。视觉编码器处理 16×16 patch，随后以 3×3 池化，让送入语言模型的 soft token 不超过预设上限。对长截图、文档页和宽幅图来说，保住长宽比往往比统一裁成正方形更重要。

在最高 1120 视觉 token 设置下，31B 的 MMMU Pro 为 76.9，12B 为 69.1。不过，分辨率从 280 提高到 1120 会显著增加视觉计算量，真实产品仍需要按任务和时延预算选择。

一份技术报告没有回答的事

这份报告只有 17 页，核心贡献覆盖面很广，但可复现细节与消融并不充分。例如，论文没有公布预训练数据总规模，只说明数据截至 2025 年 1 月，并包含网页、代码、图像与音频；也没有系统拆解 thinking、训练配方和架构变化各自的收益。

量化内存表基于特定格式与 32k 上下文，端侧延迟数据也依赖具体硬件与推理引擎。Arena 是一个时间点上的人类偏好快照，不能替代稳定的任务级评估。开放权重可以降低研究和部署门槛，但风险控制仍然落在完整应用系统，而不是模型权重本身。

论文称所有型号都接受了自动化与人工安全评测，并在不加外部安全过滤器的条件下测试模型行为。但报告主要给出方向性结论，没有公开足够细的逐项结果供读者独立比较。因此，开发者仍需针对自己的语言、场景与工具权限做红队测试，不能把通用安全声明直接当成上线许可。

真正值得关注的，是设计重心变了

如果只看榜单，Gemma 4 的故事很容易被概括为“小参数追上大模型”。但更值得关注的是，Google 正在把模型设计从单一能力竞赛，推向一场系统级预算分配：哪些层看全局，哪些 token 值得保留，哪些模态需要独立编码器，哪些计算可以交给草稿模型。

进阶学习

如果你正在关注大模型 Agent、强化学习后训练、RLHF、DPO、GRPO、RLVR 等前沿方向，欢迎学习我最新上线的精品课程：

课程围绕 Agent 架构、强化学习基础、Reward 设计、策略优化、工具调用、多轮任务执行、Agentic Workflow 以及前沿论文与实战案例展开，帮助你建立从理论到应用的完整知识体系。

Agent RL 正在成为大模型能力提升与智能体系统演进中的重要方向。未来的 Agent 不只是会调用工具，而是要能规划任务、评估结果、修正策略，并在复杂环境中持续优化自己的行为。

现在系统学习 Agent RL，提前进入下一阶段 AI 应用开发的核心赛道。

🌟 关注“唐国梁TGLTommy”，一起持续追踪 AI 技术演进背后的长期趋势。