31B 的开源模型，凭什么能跟千亿 MoE 掰手腕？——Google Gemma 4 把"小而精"这件事做透了

  • 关联论文：2607.02770

你有没有想过一个问题：

  • 你手机里跑的 AI 助手，背后往往是一个几百 GB 的庞然大物；
  • 你在家用 RTX 4090 想本地跑一个"能推理、能看图、能听声音"的模型，结果发现显存一加就 24 GB 起步；
  • 你看到排行榜上前 50 名几乎都是千亿参数 MoE，开源小模型连名字都挤不进去。

但 Google DeepMind 2026 年 7 月发布的 Gemma 4 技术报告，把这件"以为不可能"的事做出来了：

31B 密集模型，在 Arena（人类盲评平台）上排到第 43 名、Elo 1451；端侧 4.5B 模型，量化后只要 2.3 GB 显存，就能在笔记本上跑出"上代 27B"的能力。

更狠的是——这一代开源、不限量下载、商业可用（Apache 2.0）。

今天这篇科普用 5 分钟把它讲透：开源 LLM 的"小而精"，为什么突然就追上来了？这次的关键技术到底是什么？

先抛结论：开源 LLM 的"代际差"被一口气抹平

Gemma 4 一口气发了五个尺寸：

型号 形态 量化后显存 适合场景
E2B（2.3B 激活 / 5B 总） 端侧密集 0.8 GB 手机、嵌入式
E4B（4.5B 激活 / 8B 总） 端侧密集 2.3 GB 笔记本 NPU、edge box
12B 数据中心密集（无独立视觉/音频编码器） 7.65 GB 单卡 GPU 推理
26B-A4B（3.8B 激活 / 26B 总） 数据中心 MoE 16.2 GB 中等推理集群
31B 数据中心密集 19.2 GB 自托管推理主力

五个档位，全部原生支持文本 + 图像 + 音频三模态，全部内置 thinking mode（推理模式）——模型可以先在脑子里"算一算"，再给你答案。

对比一下上一代 Gemma 3 27B：

  • Gemma 4 E4B（量化 2.3 GB）已经能在 AIME 2026（美国数学邀请赛模拟卷）上答对 42.5%，而 Gemma 3 27B 只有 20.8%；
  • 在 LiveCodeBench v6（真实代码竞赛题）上，E4B 是 52.0 vs 上一代 29.1；
  • 在 IFEval（指令遵循评测）上，E4B 是 96.7 vs 上一代 90.4。

小模型追平上代中模型——这件事在两年前是不可想象的。

为什么 31B 能跟千亿 MoE 掰手腕？三件事同时做到

第一件事：让 32K 上下文的显存"减半"——long context 不再是奢侈品

长上下文是当下所有 LLM 落地的头号拦路虎。一个 70B 模型开 128K 上下文，光是 KV cache（推理时为避免重复计算而缓存的中间数据）就能吃掉几十 GB 显存。

Gemma 4 的解法是三件套一起上：

  1. Local-to-global attention（局部-全局混合注意力） - 每 5 层（E2B 是 4 层）只有 1 层做"看全部上下文"的全局注意力，其余 4 层只看邻近 token； - 类比：你读一本书时，每 5 页只回看一次目录、其余 4 页只看当前章节细节。

  2. 全局层 keys 复用为 values - 正常 Transformer 每个全局层要存 keys 和 values 两份缓存； - Gemma 4 直接 values = keys，相当于只存一份； - 全局层 KV cache 占用降低最高 37.5%。

  3. KV cache sharing（局部层之间共享） - 局部层之间可以把前一层算过的 KV 借给后一层用； - 在 32K 上下文下，E2B 的 KV cache 占用只有 0.05 GB，E4B 是 0.14 GB——几乎不占显存。

工程意义很直接：

  • 你用 E4B 跑 32K 上下文，2.3 GB（模型）+ 0.14 GB（KV）= 2.44 GB，一张 RTX 4060 笔记本显卡就够了；
  • 你用 31B 跑 128K 上下文，KV 占用比传统方案省 30% 以上，意味着你能在单卡 H100 上同时服务更多用户。

第二件事：去掉独立视觉/音频编码器——12B 的"统一架构实验"

传统多模态模型是这样的"三段式"拼装：

[图像] → ViT 编码器 → 投影层 → LLM
[音频] → USM 编码器 → 投影层 → LLM
[文本] →                  → LLM

每多一个模态，就多一个独立模块，内存碎片化、量化棘手、加载流程长。

Gemma 4 的 12B 第一次做了encoder-free（无编码器）：

  • 视觉：48×48 像素的图像小块 → 单一 35M 参数的大矩阵投影 → 2D 位置编码 → 直接进 LLM embedding 空间；
  • 音频：16kHz 音频切成 40ms 小段 → 640 维向量 → 直接投影进 LLM embedding 空间。

收益：

  • 内存碎片少了一半——量化时不用单独给 ViT/USM 写量化脚本；
  • 加载链路短——少两段模型初始化；
  • 结构统一——以后扩展模态不用动架构。

代价：

  • 35M 视觉投影 vs 传统 550M ViT，参数差一个数量级；
  • 极细粒度视觉任务（OCR、文档细节、医学影像）的质量，目前还是开放问题。

这本质上是一次架构范式实验：下一代多模态 LLM 是不是应该把编码器"内化"进 LLM 本身？这条路如果走通，影响的是整个行业。

第三件事：MTP 草稿头 + token cluster——推理加速的"外挂"

Gemma 4 给每个模型配了一个多 token 预测草稿头（MTP drafter）：

  • 主模型每步只生成 1 个 token，太慢；
  • 草稿头是个 4 层 Transformer-block，能一次猜 4 个 token；
  • 主模型并行验证这 4 个 token，对就接受、错就回退。

这是 speculative decoding（推测解码） 的标准打法，但 Gemma 4 做了两件事让它真正能上生产：

  1. 草稿头独立可配 - 每个模型都有专属 drafter（E2B 是 76M 参数，31B 是 500M 参数）； - 部署时可以根据延迟预算选择"开 / 关 / 配多少层"。

  2. token cluster（词汇表压缩） - 端侧 E2B/E4B 的词汇表有 262k，但草稿头只需要在 4096 个高频 token 上做预测； - top-k + cluster 让草稿头推理速度翻倍，接受率几乎不掉。

工程意义：

  • 服务端：MTP drafter + 31B 主模型，吞吐量能涨 2-3 倍；
  • 端侧：E4B + 草稿头，token 生成延迟从 80ms 降到 30ms 以内；
  • 这套加速方案开源、模块化，其他 LLM 团队可以直接抄。

为什么这件事对 2026 年的 AI 工程至关重要

如果你是下面任一种角色，Gemma 4 几乎是必看：

  • AI 产品经理：31B 在 Arena 上 1451 Elo 意味着——你可以不花一分钱 API 费，自托管一个"接近 GPT-4o"的模型给中小规模业务用；
  • 端侧 AI 团队：E4B 量化 2.3 GB + 原生多模态 + thinking mode，手机、edge box、车机第一次有了"真·本地推理助手"的选项；
  • 推理服务工程师：MTP drafter + token cluster + local-global attention + QAT 量化，是当下最完整的开源推理优化模板；
  • 多模态研究者：12B encoder-free 是一次范式实验，值得跟读看后续是否扩展到 26B / 31B；
  • 企业 CTO：Apache 2.0 商用许可 + 自托管可控，意味着金融、医疗、政企场景第一次有了既能合规、又有能力的开源旗舰。

三处落地风险别踩

风险 1：encoder-free 12B 的细粒度视觉还没完全验证

35M 视觉投影对比 550M ViT 是数量级下降，在 OCR、文档细节、医学影像上的精度需要专项测试。不要直接把生产环境里的 LLaVA-style pipeline 替换成 12B encoder-free，先用 DocVQA / OCR 数据集做影子测试。

风险 2：MoE 仅一款 26B-A4B，缺乏中端数据点

26B-A4B 是 Gemma 4 唯一的 MoE，缺乏"50–100B 中端 MoE"的数据点。如果你想找"在更激进的 sparse 化下质量会不会掉"的证据，目前还看不到。

风险 3：262k 词表的 vocab efficiency 待第三方复现

相比 Llama 3（128k）/ Qwen 3（152k）词表，Gemma 4 用 262k。更大词表的多语言 / 代码收益是否真的更好，需要独立第三方复现，报告本身的 abstract 节没给出细节。

风险 4：thinking mode 的安全评估未公开

报告偏能力侧，thinking mode 下的越狱 / safety / hallucination 评估需要查正文。如果你的产品对 safety 敏感，先去读原报告第 6 节再上生产。

写在最后

Gemma 4 这一代最值得记住的不是某一个 benchmark 数字，而是它把"开源 LLM 的代际差"抹平了这件事：

  • 4.5B 端侧模型，能在 2.3 GB 显存上做出上代 27B 的事；
  • 31B 密集模型，能在 Arena 上跟千亿 MoE 同台而不落下风；
  • 12B 第一次做了"无独立视觉 / 音频编码器"的统一架构实验；
  • MTP 草稿头 + token cluster + local-global attention + QAT 量化，把"开源推理优化"打包成了一套可复制的工程模板。

这意味着 2026 年下半年，开源 LLM 落地的"部署门槛"、"能力门槛"、"推理成本门槛"——三件事同时被打下来。

下次再有人说"开源模型做不了生产"，你可以直接甩出 Gemma 4 的数字：

「E4B 量化 2.3 GB，Arena 接近 1470 Elo，Apache 2.0 商用许可，MTP 推理吞吐翻倍。要不要试试？」

——这是工程语言，不是营销话术。

延伸阅读 - 论文：arXiv 2607.02770（Google DeepMind Gemma 4 技术报告） - 模型下载：https://huggingface.co/google/gemma-4（开源、Apache 2.0） - 互补工作：Qwen 3.5（397B-A17B 同代对手，Arena 1444）/ DeepSeek V4 / Kimi K2.6（同代千亿 MoE 开源对手） - 工程模板：local-to-global attention + MTP drafter + QAT 量化三件套，是当下开源推理最强实用组合