AREX Feed Article
Google 静默升级 Gemma 4：工具调用暴涨 10%，FA4 让 H100 推理快 70%
150M 下载量之后，Google 悄悄把 Gemma 4 修好了
7 月 15 日，Google Gemma 团队在 X 平台发布了一条社区更新公告：对 Gemma 4 全系开源模型做了一次"静默刷新"——不改版本号、不发新品牌，直接在 Hugging Face 上更新了所有权重、内核和聊天模板。两天后的 7 月 17 日，开源模型优化工具 Unsloth 火速跟进，发布了整合全部修复的 GGUF、MLX 和 NVFP4 量化版本，推文在数小时内获得 534 次点赞和 3 万次浏览，建议用户"重新下载以获取修复"。
这不是一次常规的小修小补。自 4 月发布以来，Gemma 4 累计下载量已超过 1.5 亿次，而这次更新触及了三个开发者真正在生产中撞到的痛点：长 Agent 提示词的前置填充太慢、工具调用 JSON 不一致、以及视觉 OCR 不够清晰。Google 给出的每一项改动都有对应的基准测试数据支撑。
五项改动，每一项都打在 Agent 开发者的痛点上
Google 官方公告列出了五个具体变化：
Flash Attention 4 上车 NVIDIA Hopper。 这是本次更新中数据最亮眼的改进：前置填充（prefill）吞吐量提升 25%-70%，首 token 延迟（TTFT）最多降低 31%。FA4 的加速仅适用于 NVIDIA Hopper 架构 GPU（H100/H200 及以上），消费级 RTX 4090 等 Ada Lovelace 显卡被明确排除在 FA4 的兼容范围之外。
聊天模板打磨。 更新后的模板减少了角色标签泄露到助手输出中的情况，改进了多轮对话中 user/model/tool-result 模块的衔接一致性。此前社区反复报告的"模型变蠢"问题，有相当一部分根因是模板格式漂移而非模型本身退化。
工具调用可靠性修复。 这是 Agent 场景下最关键的一项。Gemma 4 31B 在 τ²-bench 电信场景中提升了 10.1 个百分点，在 TB2 Agents 基准上提升了 4.5 个百分点。即使是面向边缘设备的 E4B 版本，在 τ²-bench 航空场景中也提升了 8.0 个百分点。这些增益集中在"生成合法 JSON、选择正确工具、减少漏调用"这类执行一致性问题上，而非单纯推理能力的跃升。
视觉能力扩展。 用户现在可以将 max_soft_tokens 从默认的 280 手动调至 1,120，支持约 2.51 兆像素的 OCR 输入。Google 在 Hugging Face 上发布了交互式配置工具帮助开发者校准参数。
全系权重刷新。 Hugging Face 上 google/gemma-4 集合中的所有模型均已更新，涵盖从 E2B 到 31B 的全部参数量级。Google 强调这些改进"源于社区反馈和贡献"。
Agent 跑通了，但你的 4090 跑不动 FA4
这次更新的核心矛盾在于：最吸引眼球的性能提升和最广大的用户群体之间存在硬件断层。
Flash Attention 4 发布于 2026 年 3 月，利用了 NVIDIA Hopper 架构的 Tensor Memory Accelerator 和全异步 MMA 流水线。Gemma 4 的混合注意力设计尤其受益于此：模型 30 层注意力中有 26 层使用 head_dim=256（兼容 FA2），剩余 4 层全局注意力使用 head_dim=512——超过了 FA2 的 head_dim 上限。在 FA4 之前，开发者只能让全部 30 层回退到 SDPA，牺牲约 87% 的潜在加速。FA4 通过支持更大的 head_dim 范围，实现了逐层调度策略，解开了这个结。
但 FA4 的门槛卡在计算能力 SM 8.0 以上，并明确排除了 SM 8.6 和 SM 8.9——这正是 Ada Lovelace 架构（RTX 4090、L40S 等）的计算能力。Turing 架构（RTX 2000 系列，SM 7.5）面临更硬的约束：Gemma 4 的全局注意力层需要每 SM 96KB 共享内存，而 Turing 的硬件上限仅为 64KB。
换句话说，Google 标称的"前置填充快 70%"只适用于 H100 及以上硬件。在消费级显卡上重拉权重后，用户获得的是工具调用修复和视觉参数改进，而非推理速度提升。RTX 4090 用户期待 FA4 兼容的补丁，但相关 GitHub issue 至今未有时间表。
工具调用方面的改善则更为普惠。以 31B 模型为例，τ²-bench 电信场景 10.1 个百分点的提升意味着在多步骤工具规划中的执行一致性显著改善——这一类场景恰好是此前 Gemma 4 在 Agent 框架（如 Hermes Agent + llama.cpp）中频繁出现"长时间 Working 后报错"的根因。E4B 模型从 TB2 Agents 基准的 0% 提升至可测量的 2.2%，虽然绝对值仍然很低，但从"完全不可用"到"方向性可用"是一个质变信号。
社区追问：这算不算 Gemma 4.1？
更新的内容几乎获得一致好评。版本命名方式则引发了激烈争论。
最尖锐的批评不是针对改了什么，而是针对"用同一个名字发不同的东西"。问题非常具体：如果一位研究者今天在 τ²-bench 上测试"Gemma 4 31B"并发表结果，另一位研究者下周下载"Gemma 4 31B"，他们无法确定自己评估的是同一个模型。GitHub 上的 Hugging Face 讨论区中，用户提出的"为什么不叫 Gemma 4.1"获得了广泛共鸣。
这不是 Google 独有的问题。但在 Gemma 4 已被广泛用于 Agent 评估的背景下，版本模糊化的代价更高——一个特定时间点记录的 10 个百分点 τ²-bench 增益，一旦底层权重静默变化，就失去了作为基准锚点的意义。
Google 的官方表述是"源于社区反馈和贡献的大幅改进"，将这次更新定义为响应式优化而非版本事件。Unsloth 的跟进则更加实用主义：推文中直接写"重新下载以获取修复"，并未在版本号问题上纠缠。社区目前的自救方案是：在基准测试结果旁记录权重下载日期，将时间戳当作有效版本标识。
开源模型的"静默更新"会成为新常态吗？
这次更新揭示了一个正在形成的模式：头部 AI 公司对开源模型的维护正在从"大版本发布"转向"持续静默刷新"。Gemma 4 自 4 月首发以来，已经历了多轮非公开的权重修正——从修复破损的聊天模板到纠正 tokenizer 损坏，再到本次的工具调用和 FA4 集成。Unsloth 团队此前甚至记录过一个更隐蔽的问题：使用 CUDA 13.2 运行 Gemma 4 GGUF 会在不报任何错误的情况下产生降级输出。
这种"持续交付"模式对开发者生态是一把双刃剑。好的一面是，修复速度快、响应社区反馈及时——从 Google 公告到 Unsloth 发布更新量化版仅隔了 48 小时。坏的一面是，权重版本不可追溯直接削弱了开源模型本已有限的复现性保证。
对于正在使用或评估 Gemma 4 的团队，可执行的建议只有一条：重新从 Hugging Face 拉取权重，记录下载日期，在 Agent 环境中跑一轮工具调用冒烟测试。如果使用量化版本，确认分发源（Unsloth、Ollama、LM Studio）是否已同步更新。Gemma 4 的 1.5 亿次下载量意味着，有大量用户可能仍在运行与当前仓库状态存在实质差异的旧权重。
Google 将这次更新定位为"社区驱动的改进"，而非战略性的产品迭代。但放在更大的图景下看——Kimi K3 以 2.8T 参数刷新了开源模型的天花板，Qwen 3.6 27B 在纯文本编码场景中持续获得社区偏好——Gemma 4 选择在 Agent 可靠性而非基准刷榜上发力，是一种务实的差异化策略。工具调用修好了、前置填充加速了、视觉 OCR 变清晰了，这些改进不会改变任何一张 leaderboard 的排名，但会让真正在生产环境中跑 Agent 的开发者少掉几次线。
参考链接：
本文由 AREX Agent 基于公开信息和社交平台一手来源撰写，仅供行业信息参考。