108k tokens/s：Gemini 4 Argon 给 Gemma 提速 2.85 倍，但 token parity 还没服众

2026 年 10 月 26 日，Google Gemma 官方账号放出一个结果：Gemini 4 Argon 在 vLLM 里帮 gemma-4-E2B-it 做了一轮性能优化。单张 A100 上，吞吐从约 37,900 tokens/s 涨到 108,000+ tokens/s，2.85 倍。官方同步列出三个结论：100% token parity，零质量下降，改动只花几天而不是几个月。所有修改都公开在 vLLM 仓库，8 个 PR，作者是 collaborator lucianommartins。查看 8 个 PR

这批 PR 的优化思路很直白：把分散的算子融合成 Triton kernel，包括 QKV norm/RoPE、pre/post-FFN norms、MoE routing；给 MoE 模型调了 tuned config；加了 KV-sharing fast prefill，合并 MTP speculative decoding 层；多模态输入也没落下，批处理了 vision pooler，融合了 Gemma4Unified 2D posemb。顺带把 EmbeddingGemma2 的多模态 pooling 支持也合了进去。

推文里附了一段视频，展示测试负载的运行界面：batch size 64，输入 2048 token，输出 16 token，单张 A100 上持续吞吐超过 108k tokens/s。视频标注显示，TTF（首个 token 延迟）比基线快 3.17 倍，E2E 吞吐快 2.92 倍。

评论区最较真的，都在追问验证方法。

开发者 Michał Piszczek 问了一个具体问题：fused QKV kernel 的 PR 里，batch size 为 1 时输出 bit-exact，但 batch size 512 时只有 44-46% 的 token 完全精确，约 80% 落在 1 ULP 误差内。那官方说的 100% token parity，是在 batch 1 测的，还是在 108k tokens/s 的负载下测的？Daniel Priscu 补了一句：长上下文才能检验 parity，短 prompt 会掩盖问题。Aleksandar Janca 的态度更直接：token parity 是 agent 写 kernel 优化的生命线，输出对照环节做不扎实，速度越快越危险。

bemuuvi 关心小一点的 GPU 能不能吃到同样的加速。martin 直接开嘲：为什么要拿 A100 跑一个 2B 模型？再快也是小模型。Bowen thinking 问的是另一件事：这些优化会不会同步到 Gemma 26B-A4B？Google Cloud 什么时候能用上？他提到，Gemma 4 官方发布已经 208 天。配了一段火箭发射的动画。

这轮优化本身是个不错的样本：agent 在几天内完成 kernel 级优化，PR 全部公开，社区能逐行检查。但评论区这种怀疑情绪，也说明一件事：benchmark 数字越来越便宜，验证方法才是稀缺品。100% token parity 说出来很容易，难的是证明它。