作者:方弦
https://zhuanlan.zhihu.com/p/2023880667814003300
2026年4月2日,Google DeepMind发布Gemma 4。31B参数的dense模型在AIME 2026上拿到89.2%,MoE变体26B-A4B以3.8B活跃参数在MMLU Pro上达到31B dense模型的97%。与此同时,Qwen3-235B的总参数量是31B的7.6倍,GLM-5更是达到744B总参数。
本文要拆解的是Gemma 4在架构和训练层面做出的每一项技术选择:K=V、p-RoPE、128小专家+ Dense MLP双路径、Per-Layer Embeddings——每一项单独看都不算非常独特,但叠加在一起的效果确实很强。
核心洞察
简单来说,Gemma 4证明了架构效率和训练质量可以在特定任务上大幅压缩参数需求——31B参数在数学推理和编程benchmark上追平甚至超越 200B+级别的模型,26B-A4B用 3.8B活跃参数达到31B dense的 97%(MMLU Pro)。
但是,这个效率增益不是无条件的。GLM-5 用744B参数在SWE-bench(77.8%)和Vending Bench 2等长周期agentic任务上取得近开源 SOTA,说明复杂规划能力的上限仍然与总参数量正相关。
所以,理解效率优化在哪里生效、在哪里失效,比单纯崇拜”小模型”更有价值。
一、架构篇
Gemma 4的基础仍然是decoder-only Transformer,但Google在几乎每一个组件上都做了有针对性的优化。注:具体的架构参数,参考了开源的配置和模型代码,如有错漏,请指正。
1.1 KV 共享与边缘模型优化
Transformer推理时,显存消耗的大头是KV Cache——每一层都要缓存所有历史token的Key和Value向量。对于 256K上下文的模型来说,这部分显存可以轻松超过模型权重本身。
Gemma 4在边缘模型(E2B、E4B)中采用了一种直接的做法:让最后N层直接复用前面同类型attention层的 KV 张量,不再自己计算K和V投影。 从开源的config.json 可以验证:E2B有 35 层,其中20层共享KV(num_kv_shared_layers=20);E4B 有42层,其中18层共享KV(num_kv_shared_layers=18)。这不是近似或压缩——复用的是精确计算过的KV。深层网络中,相邻层学到的KV表示往往高度相似,独立计算本质上是冗余工作。
但值得注意的是,31B和26B-A4B的 num_kv_shared_layers=0——发布版的大模型并未启用这一优化。这说明 Google认为在参数量较大的模型中,每层独立计算KV的信息增益值得保留,KV共享主要服务于算力受限的边缘设备场景。
1.2 Global Attention 的五重压缩
在混合注意力机制中,global attention层是最昂贵的——它们需要对整个上下文序列做全注意力计算。Gemma 4在global attention层上叠加了五重优化,形成一个完整的设计链:
起点是GQA——模型整体使用适度的分组(31B为32Q/16KV,26B-A4B 为16Q/8KV),但在global attention 层,KV head数量进一步压缩:31B 从16个降到4个(num_global_key_value_heads=4),26B-A4B从8个降到2个(num_global_key_value_heads=2),均达到GQA 8:1。但这显然会损失信息容量。Google的应对是 Key维度翻倍:global层的 head_dim从256翻倍到512(global_head_dim=512),更宽的KV向量能在更少的head数量下保留足够的信息。在这个基础上,进一步让 K=V(attention_k_eq_v=True)——直接让Key向量等于Value向量,KV Cache再减半。这强制模型在”检索”(Key 的角色)和”读取”(Value 的角色)之间使用同一套表示,降低了表示的自由度——共享表示约束了模型的拟合空间,客观上起到了正则化效果。
到这里,KV Cache已经被压缩到了最小。但还有一个问题需要解决:长上下文下的位置编码失真。标准RoPE对向量的所有维度都施加旋转,但在256K的距离上,低频维度的旋转极其微小,累积起来会在远距离token之间引入对齐误差,干扰语义匹配。Gemma 4的解决方案是p-RoPE:只对25%的高频维度施加旋转,低频维度纯粹保留语义信息,不被位置噪声污染。
最后,最后一层强制Global——无论interleaving pattern怎么排,最后一层一定是global attention,确保输出token能看到完整的输入上下文。
把这五层因果关系放在一起:GQA 8:1压缩 KV head数量→Key维度翻倍补偿信息损失→K=V进一步减半→p-RoPE解决长距离位置噪声→最后一层Global保证全局可见。设计哲学很清晰:global attention层的目标不是保留最多的信息,而是在保留足够信息的前提下,把开销压缩到最低。
1.3 双RoPE
1.2节提到的p-RoPE和标准RoPE的分工,从config.json可以看到完整的参数差异:sliding window层使用 rope_theta=10000,global层使用 partial_rotary_factor=0.25 + rope_theta=1000000。两者的上下文窗口也不同——边缘模型E2B/E4B的sliding window为512 token,31B/26B-A4B 为1024token。短窗口 + 标准RoPE,长窗口+p-RoPE,各取所需。
1.4 Per-Layer Embeddings
这是Gemma 4小模型(E2B、E4B)最独特的架构特征。
在标准Transformer中,每个token的embedding在所有层中是同一个。这意味着第一层的embedding需要预先编码这个 token在所有层次上可能需要的信息——对一个固定维度的向量来说这是不现实的约束。PLE的做法是为每一个 decoder 层维护一个独立的小型 embedding table,每个token 在每一层都会收到一个专属信号。
效果上,E2B的总参数是5.1B,但有效参数只有2.3B——另外 2.8B 是PLE的embedding table。这些参数在磁盘上占空间,但计算成本极低(只是embedding lookup + 小型投影),推理速度完全是一个2B模型的水平。用存储换计算,用参数空间换算力空间。 对于存储空间比算力便宜的边缘设备来说,这种trade-off非常合理。
1.5 MoE 128专家+Dense MLP混合架构
26B-A4B 是Gemma 4家族中最值得深入分析的模型。25.2B 总参数,每token激活约3.8B,性能达到31B dense模型的 97%(MMLU Pro 82.6% vs 85.2%),AIME 2026仅低 0.9 个百分点。
但它的MoE实现方式与其他模型有本质区别。从HuggingFace的模型实现代码(modeling_gemma4.py)可以确认,26B-A4B 每层包含两个并行的 FFN 路径:一个标准的 dense MLP(intermediate_size=2112)和一个 routed MoE block(128 个专家,每token选8个,每个专家 moe_intermediate_size=704)。两条路径的输出通过layer norm后相加合并。
这与Qwen3(纯 MoE,无dense MLP)和GLM-5(8 routed + 1 shared expert)的架构都不同。dense MLP充当了类似共享专家的角色,但它是一个独立的、不依赖路由的全量计算路径,提供了不依赖路由器决策的稳定基础信号。
128个专家已经不再是Gemma 4的独创——Qwen3-235B-A22B 和GLM-5都采用了类似设计。三者在专家配置上的差异值得深究:
| 配置项 | Gemma 4 31B | Gemma 4 26B-A4B | Qwen3-235B-A22B | GLM-5 |
|---|---|---|---|---|
| 总参数 | 30.7B | 25.2B | 235B | 744B |
| 专家总数 | — | 128 | 128 | 256 |
| 每token激活 | — | 8 MoE + dense MLP | 8(纯 MoE) | 8 + 1 共享 |
| 活跃参数 | 30.7B | 3.8B | 22B | 40B |
| 层数 | 60 | 30 | 94 | 78 |
| hidden_size | 5376 | 2816 | 4096 | 6144 |
| Q heads | 32 | 16 | 64 | 64(MLA 压缩) |
| KV heads | 16 | 8 | 4 | MLA(kv_lora_rank=512) |
| head_dim | 256 | 256 | 128 | 64(qk_head_dim=256) |
| sliding_window | 1024 | 1024 | 无 | 无(DSA 替代) |
| 上下文 | 256K | 256K | 256K(max) | 200K |
数据来源:Gemma 4 来自 HuggingFace config.json(31B、26B-A4B、E4B、E2B)和 transformers 源码。Qwen3 来自 HuggingFace config.json + 技术报告。GLM-5 来自 HuggingFace config.json(zai-org/GLM-5)和技术报告。
值得注意的是三者在 MoE 路由策略上的分歧。Qwen3采用纯MoE无 dense MLP,GLM-5用8 routed+1 shared expert,Gemma 4用dense MLP+routed MoE双路径。三种设计没有绝对的优劣——它们分别服务于不同的工程目标:Qwen3追求纯MoE的参数效率,GLM-5的共享专家确保基础表达能力,Gemma 4的dense MLP提供了一个不依赖路由的稳定基础通道。
128-256个小专家相比早期的8-16大专家,核心优势在于路由的粒度。路由器可以做更精细的分发——不是”这段文本归你”,而是”这个词的这种语义组合归这个专家”。更细的粒度意味着每个专家学习的模式更专注,参数利用率更高。Gemma 4每个 MoE 专家的intermediate_size仅704维(对比Qwen3的每个专家约12K维),路由粒度更细。
二、训练篇:蒸馏是共同选择,差异在执行
架构优化解释了Gemma 4的效率,但没有完全解释它为什么这么强。一个架构精良但训练数据平庸的31B模型,不可能追平训练充分的235B模型。
2.1 三个团队的蒸馏策略
蒸馏不是Gemma 4的独门武器——三个团队都在做,而且都明确承认蒸馏优于纯RL。
Qwen3 对小模型使用“strong-to-weak distillation”,利用旗舰模型235B-A22B作为teacher,通过off-policy和on-policy两种方式传递知识。
技术报告的原文是:”Distillation from advanced teacher models significantly outperforms reinforcement learning in performance and training efficiency.”
GLM-5在post-training的三个阶段(Reasoning RL→Agentic RL→General RL)中全程使用On-Policy Cross-Stage Distillation来防止灾难性遗忘,确保模型在获得新能力的同时保留推理基础。
Gemma 4的架构明确源自Gemini 3研究。Google没有公开完整的训练细节,但从已发表的Chain-of-Thought蒸馏研究来看,流程大致是:用Gemini 3对大量prompt生成推理链 → 过滤质量 → 用合成数据训练instruction-tuning阶段。
三个团队都在做蒸馏,关键差异在于 Teacher 模型的能力上限。Google拥有Gemini 3作为teacher。作为Gemini系列的第三代旗舰闭源模型,其能力在公开benchmark上显著优于任何开源模型,信息质量上限天然高于Qwen3-235B或 GLM-5自蒸馏。不过这只是基于公开信息的推断——Google暂时没有公开Gemma 4蒸馏数据的具体来源和规模。
2.2 训练管线对比:三阶段的殊途同归
三个模型的预训练都采用了三阶段策略,但侧重点不同。以下只讲训练流程和RL策略,架构层面的位置编码和注意力扩展技术见第三章。
Qwen3(36T tokens):
- 1.General Stage (S1):30T tokens,4K 上下文,建立语言基础
- 2.Reasoning Stage (S2):5T tokens,增加 STEM/代码/推理/合成数据比例
- 3.Long Context Stage:数千亿 tokens,4K→32K 上下文扩展,使用 ABF(base frequency 10K→5M)、YARN 和 Dual Chunk Attention (DCA)
GLM-5(28.5T tokens):
- 1.Base Model Training:27T tokens,优先代码和推理数据
- 2.Mid-training:4K→200K上下文渐进扩展,聚焦长上下文 agentic 数据
- 3.Post-Training:顺序RL管线——Reasoning RL→Agentic RL→General RL
GLM-5 最值得关注的是其RL基础设施。他们开发了 slime——一个异步RL框架,将生成和训练解耦,大幅提升GPU利用率和RL训练吞吐。这让他们能进行更细粒度的 post-training迭代,包括异步Agent RL算法,让模型从复杂的长周期交互中学习。这种RL工程投入直接反映在 GLM-5 在 agentic benchmark上的领先表现。
Gemma 4:Google 未公开训练数据量(TT)。
2.3 QAT:训练时就考虑量化
Gemma 4提供了Quantization-Aware Training (QAT) checkpoint——在训练阶段就引入量化噪声,让模型学会在低精度表示下保持输出质量。NVIDIA已发布Gemma-4-31B-IT-NVFP4,量化到4-bit浮点后精度损失极小。
Qwen3和GLM-5主要依赖后量化(GPTQ/AWQ),GLM-5额外提供了官方 FP8 权重。后量化的工具链更成熟、社区生态更丰富,但理论上 QAT 能做到更小的精度损失。
2.4 多模态
Gemma 4的多模态能力在预训练阶段就与文本一起训练。视觉编码器基于ViT,使用2D RoPE编码patch的二维空间位置,支持可变宽高比和可配置的soft token budget(70-1120 tokens)。音频编码器沿用Gemma-3n的USM-style conformer,从681M压缩到305M。
GLM-5走了不同路线——原生不处理图像/音频/视频,而是通过 tool-calling调用GLM家族的专用模型(GLM-Image、GLM-4.6V、GLM-Vision)。这种”模型即工具”的设计在 agentic场景下更灵活,但端到端延迟和一致性不如原生融合。
Qwen3的视觉能力由Qwen3-VL系列承担,基础语言模型本身不直接处理图像。
三、对比篇:三条不同的技术路线
3.1 Benchmark 对比
以下使用各模型技术报告或官方benchmark中可查证的数字。注意AIME 2024、2025、2026是不同的试卷,跨年数据不具备严格可比性:
| 模型 | 总参数 | 活跃参数 | AIME | MMLU Pro | SWE-bench |
|---|---|---|---|---|---|
| Gemma 4 31B | 30.7B | 30.7B | 89.2% (‘26) | 85.2% | — |
| Gemma 4 26B-A4B | 25.2B | 3.8B | 88.3% (‘26) | 82.6% | — |
| Qwen3-235B-A22B | 235B | 22B | 85.7% (‘24) / 81.5% (‘25) | — | — |
| GLM-5 | 744B | 40B | 93.3% (‘25) | 80.6% | 77.8% |
可以观察到:
- GLM-5在AIME 2025上表现最强(93.3%),超过了 Gemma 4在AIME 2026上的89.2%。虽然跨年比较不严谨,但GLM-5用RL工程在数学推理上取得的进步是实打实的。
- Gemma 4 26B-A4B在AIME 2026 上仅比 31B dense 低0.9个百分点,但活跃参数从30.7B降到3.8B——8倍的活跃参数差距只换来不到1%的性能损失。
- GLM-5在agentic benchmark上没有对手:SWE-bench77.8%、Vending Bench 2$4,432(开源#1)。这印证了我们的核心洞察——参数规模在复杂规划任务上仍然重要。回到开头的判断:Gemma 4 31B在推理和编程任务上确实逼近了 200B+级别的水平,但这个“逼近”有明确的适用边界。
3.2 注意力架构对比
这是三个模型在架构层面最本质的差异。
Gemma 4:Sliding Window + Global 交错注意力
层交替使用 local sliding window(1024 token)和 global full-context attention(5:1 交错比例,从 layer_types 验证),通过 K=V、GQA 8:1、p-RoPE 将 global 层开销压到最低。设计目标是在固定显存预算内最大化上下文长度。
Qwen3:标准 Full Attention + YARN/DCA 扩展
沿袭 Qwen2.5的标准Full Attention架构,94层,64Q/4KV的GQA。长上下文不是通过稀疏化实现,而是通过 RoPE base frequency 调整(ABF)+YARN 的距离衰减 + DCA的分块注意力来扩展。设计目标是架构简洁性和通用性,不改变注意力机制本身,只在位置编码和注意力模式上做适配。
GLM-5:MLA + DSA 双重压缩
这是三者中最激进的方案。GLM-5抛弃了传统KV Cache,改用 Multi-Head Latent Attention (MLA)——将 Key和Value投影到一个低维潜在空间中,推理时只需要缓存压缩后的潜在向量,大幅减少显存占用。
在此基础上叠加DeepSeek Sparse Attention (DSA):使用一个轻量级的 lightning indexer(index_n_heads=32, index_head_dim=128, index_topk=2048)为每个 token 动态选出最相关的 top-k 个历史 token,让注意力计算只在选中的子集上进行。MLA 解决了 KV Cache 的显存瓶颈,DSA 解决了注意力计算的算力瓶颈,两者叠加实现了 200K 上下文的高效处理。设计目标是长上下文 agentic 能力,MLA + DSA 的双重压缩天然适合多步工具调用中需要频繁回溯长历史记录的场景。
三条路线的选择反映了不同的工程优先级:
- Gemma 4 追求推理效率最大化,通过多层压缩降低单次注意力的开销
- Qwen3 追求架构简洁性和通用性,通过成熟组件的组合达到稳定效果
- GLM-5 追求长上下文 agentic 能力,MLA + DSA 的双重压缩天然适合多步工具调用中需要频繁回溯长历史记录的场景
3.3 量化策略对比
| 模型 | 量化方案 | 特点 |
|---|---|---|
| Gemma 4 | QAT checkpoint | NVIDIA 发布 NVFP4 版本,训练时感知量化 |
| Qwen3 | 后量化(GPTQ/AWQ) | 社区生态丰富,工具链成熟 |
| GLM-5 | 官方 FP8 + 后量化 | 专门提供 FP8 权重,适配 Hopper/Blackwell |
四、三个模型的定位还是有点差别
经过架构和训练两个层面的拆解,三者的差异化定位比较清晰:
Gemma 4:效率至上。 每一个架构选择都在压缩推理开销——K=V、p-RoPE、GQA 8:1 global 层、PLE、QAT。它不是最强的模型,但在给定算力预算下可能是性价比最高的。适合对推理成本敏感、需要广泛部署的场景。
Qwen3:通用均衡。 架构选择相对保守(标准 Full Attention + 成熟组件组合),通过规模(36T tokens、235B 参数)和扎实的数据工程达到 SOTA。开源生态最完善,社区支持最好。适合需要稳定可靠、生态丰富的通用场景。
GLM-5:Agentic 专精。 MLA + DSA 双重注意力压缩 + slime 异步 RL + Agent RL 算法,整个管线都在为 agentic 能力服务。SWE-bench 77.8%、Vending Bench 2 开源 #1、AIME 2025 93.3%。并提供了 Ascend NPU 的官方部署适配。适合面向中国市场、以 agentic coding 为核心的场景。
五、Takeaways
5.1 “小模型 + 大 Teacher” 范式的结构性天花板
Gemma 4 不是孤例——Microsoft Phi、Apple OpenELM 都在走类似路线,Qwen3 也明确承认蒸馏优于 RL。但这个范式有一个结构性问题:模型能力的上限由 Teacher 决定,而最强的 Teacher(Gemini 3、GPT-5)掌握在闭源团队手中。开源模型之间的竞争正从”谁的参数多”转向”谁的蒸馏策略好”,但竞争的天花板仍由闭源模型设定。
5.2 RL 工程投入拉开差距
GLM-5 的 slime 异步 RL 框架表明,RL 训练效率本身已成为模型竞争力的组成部分。GLM-5 在 AIME 2025 上 93.3% 和 SWE-bench 77.8% 很大程度上归功于 Reasoning RL + Agent RL 的深度投入。这对 RL 基础设施(veRL、OpenRLHF等)的开发者是明确的利好信号。
六、结论
Gemma 4的架构选择值得拆开来分析,但比单个技巧更重要的是整体思路:
在数学推理和编程任务上,参数效率的边界比我们想象的要远。 31B 参数可以达到过去需要 200B+ 参数才能达到的性能水平。Gemma 4 26B-A4B 用 3.8B 活跃参数只比 31B dense 低不到 1%,这是架构效率和训练质量叠加的结果。
但效率优化有明确的边界。 GLM-5 用 744B 参数在 SWE-bench(77.8%)和 Vending Bench 2 上取得的开源 SOTA,证明了复杂 agentic 规划能力仍然与总参数量正相关。Gemma 4 在这些任务上没有公布 comparable 数据。
蒸馏策略是当前最大的隐性变量。 三个团队都在做蒸馏,但 Teacher 模型的能力上限不同。不过Google 没有公开 Gemma 4 的蒸馏数据来源和规模,这让我们无法精确量化蒸馏在 Gemma 4 的成功中贡献了多少,这部分就无法脑补了,等其他大佬分析吧。
没有一种架构是”最优解”。 Gemma 4 的极致效率、Qwen3 的通用均衡、GLM-5 的 agentic 专精,分别服务于不同的场景和优先级。选择哪个模型,取决于你的部署约束、目标场景和生态系统偏好。
这意味着,对于做AI Infra和相关领域的同学来说:理解每种架构的效率特性,比单纯堆算力硬解更重要。
参考来源:
1.Google Blog: Gemma 4
https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/
2.HuggingFace Blog: Welcome Gemma 4
https://huggingface.co/blog/gemma4
3.A Visual Guide to Gemma 4 — Maarten Grootendorst
https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-gemma-4
4.VentureBeat: Google releases Gemma 4 under Apache 2.0
https://venturebeat.com/technology/google-releases-gemma-4-under-apache-2-0-and-that-license-change-may-matter
5.Qwen3 Technical Report (arXiv:2505.09388)
https://arxiv.org/html/2505.09388v1
6.GLM-5 Technical Report (arXiv:2602.15763)
https://arxiv.org/html/2602.15763v2
7.GLM-5 GitHub Repository
https://github.com/zai-org/GLM-5
8.Qwen3-235B-A22B on HuggingFace
https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507
9.NVIDIA: Gemma-4-31B-IT-NVFP4
https://huggingface.co/nvidia/Gemma-4-31B-IT-NVFP4
10.WaveSpeed: What Is Google Gemma 4?https://wavespeed.ai/blog/posts/what-is-google-gemma-4/
11.LayerLens: GLM-5 Benchmark Review (AIME 2025: 93.33%, SWE-bench: 77.8%)
https://layerlens.ai/
12.Sebastian Raschka: GLM-5 Architecture (256 experts, MLA)
https://www.linkedin.com/posts/sebastianraschka_on-an-llm-time-scale-it-has-been-a-while-activity-7427718512284012545-QH9
13.Xianbao QIAN: GLM-5 Deep Dive (MLA + DSA)
https://x.com/Xianbao_QIAN/status/2023199756009591250
14.HuggingFace transformers: Gemma 4 modeling source (MLP+MoE dual path)
https://github.com/huggingface/transformers/blob/main/src/transformers/models/gemma4/modeling_gemma4.py