Gemma 4 QAT 来了：把 31B 模型塞进消费级显卡

6 月 5 日，Google DeepMind 发布 Gemma 4 系列的 QAT（量化感知训练）检查点。这是继 4 月初 Gemma 4 主线发布之后落下的第二只靴子——主线版本解决"能不能用"，QAT 解决"能不能在你自己的机器上跑"。

发布日 Hugging Face 上同步上线了两个 collection：Gemma 4 QAT Q4_0 和 Gemma 4 QAT Mobile。前者面向桌面级 GPU 和笔记本，后者直接瞄准手机和边缘设备。许可证依然是 Apache 2.0，商用限制几乎没有。

如果你还记得去年 Gemma 3 QAT 把 27B 模型塞进单张 24GB 消费卡那一波，这次要做的事差不多，只是模型更大、覆盖更全。Gemma 4 主线有四个尺寸——E2B、E4B、26B A4B、31B——QAT 这次一次性把它们全覆盖了。

QAT 到底解决了什么问题

业界做模型压缩通常有两条路：训练后量化（PTQ）和量化感知训练（QAT）。

PTQ 简单粗暴——模型训完之后直接把权重从 BF16 砍到 INT4，省事但代价不小。一旦量化精度往低了走，模型在长尾任务上的表现会肉眼可见地塌方，尤其是数学推理和长上下文这种本来就吃精度的活。开发者社区里那种"Q4 能用、Q3 就废"的体感就是这么来的。

QAT 走的是另一条路：把量化的"误差"在训练阶段就模拟进去，让模型在低精度噪声下学习如何保留有用的表征。说白了，是让模型提前知道自己将来要"瘦身"，于是在训练时就做好准备。Google 在博客里给的说法是"显著降低显存需求的同时保持模型质量"——这话听着像套话，但放在 31B 模型上含义就具体了：BF16 满血权重大概要 62GB，Q4_0 之后压到 17GB 上下，一张 4090 或 5090 就能跑起来。

更关键的是，QAT 不是单纯的"量化方法"，它更像是一份官方钦定的量化检查点。社区里 GGUF 量化版本一直都有，但质量参差不齐——有人用 imatrix，有人不用，校准集各家一套。Google 自己出 QAT 等于把"参考实现"这个位置占了。

Q4_0 和 Mobile，两套各打各的场景

这次发布的两个 collection 定位很清楚。

Q4_0 是给桌面端用的。Q4_0 是 GGUF 生态里最经典的 4-bit 量化格式——结构简单、推理快、几乎所有 llama.cpp 派生的运行时都支持（Ollama、LM Studio、KoboldCpp、text-generation-webui 一整套）。Google 直接发 Q4_0 等于绕过了"等社区量化"这一步，开发者拉下来就能用。

按 Gemma 4 主线给出的尺寸算：

• E2B（2B 级别）：QAT 之后大约 1.5GB 显存，集显笔记本能跑
• E4B（4B 级别）：3GB 上下，主流移动 GPU 全覆盖
• 26B A4B（MoE 架构，激活 4B 参数）：单张 16GB 卡可以塞下
• 31B（密集架构）：17GB 左右，24GB 卡舒服跑，16GB 卡靠卸载也能跑

Mobile 这个 collection 更激进，针对的是 Android 和 iOS 设备。它和 Gemini Nano 4 共享一套底座——Google 在 Google I/O '26 上提过，Gemma 4 就是新一代 Gemini Nano 的基础模型。Mobile 版本会针对 ARM 架构做更细的算子调优，不只是把权重压小，还要让 NPU 和移动 GPU 能吃得下。

两条路线同时铺，意味着 Google 想把"开源模型本地跑"这件事的下限拉到手机，上限定在工作站。中间那一段——也就是大多数开发者真正会用的部分——靠 Q4_0 兜住。

性能：量化损失到底有多少

主线 Gemma 4 的 benchmark 已经公开过：

| 模型 | MMLU Pro | AIME 2026（无工具） | MATH-Vision | |------|---------|-------------------|-------------| | Gemma 4 31B | 85.2% | 89.2% | 85.6% | | Gemma 4 26B A4B | 82.6% | 88.3% | 82.4% | | Gemma 4 E4B | 69.4% | 42.5% | 59.5% | | Gemma 4 E2B | 60.0% | 37.5% | 52.4% | | Gemma 3 27B（无思考） | 67.6% | 20.8% | 46.0% |

值得拉出来说一句的是 AIME 2026 那一栏——31B 拿到 89.2%，比 Gemma 3 27B 翻了四倍多。这说明 Gemma 4 在数学推理上的提升不是边际改进，是结构性变化。

QAT 版本的官方完整数字 Google 还没全部放出，但参考 Gemma 3 QAT 当时的数据，Q4_0 量化在 MMLU Pro 这类基准上的损失通常在 1-2 个百分点以内，远小于社区 PTQ 量化常见的 3-5 个百分点。对 31B 这种本来就在能力线之上的模型来说，损失 1 个点换 4 倍显存压缩，几乎没有理由不切。

256K 上下文加多模态，怎么办

Gemma 4 中型模型（26B A4B、31B）的上下文窗口是 256K，小型模型 128K。这两个数字在量化之后都不会缩水——上下文长度跟权重精度无关，跟 KV cache 的内存占用有关。

但这里有个隐藏坑：256K KV cache 在 BF16 下大概要吃 30-40GB（取决于注意力头配置），就算权重压到 17GB，跑满上下文你照样要 50GB+ 总显存。Google 这次 QAT 没有顺便处理 KV cache 量化，所以长上下文场景下，显存大头依然是 cache 而不是权重。这一点开发者部署时心里要有数。

多模态那边稍微好一些。Gemma 4 的视觉编码器小型模型 ~1.5 亿参数，中型 ~5.5 亿，相比 LLM 主体小得多，量化之后基本可以忽略不计。E2B 还支持音频输入，Mobile 版本对这一点优化得比较积极——直接对应到手机端的语音助理场景。

对开发者意味着什么

把 QAT 这件事单独拎出来发，Google 的意图不难看出：

第一层，巩固 Gemma 在"开源本地模型"这个赛道的位置。Llama 4、Qwen 3、DeepSeek 这些都在卷云端能力，本地部署这一块卷的人反而少。Google 借 Android 生态和 Gemini Nano 的协同，往设备端打很顺。

第二层，把"官方量化"这个心智占下来。社区量化版本一直都有，但开发者部署到生产时，还是会优先选官方权重——出了问题至少有个 baseline。Gemma 3 QAT 当时就靠这个心智吃下了一波 Ollama 和 LM Studio 用户。

第三层，给端侧 Agent 铺路。Gemma 4 主线特别强调智能体工作流和多步规划，而 Agent 应用最大的痛点之一是延迟——本地跑一个 4B 的 Agent，比走 API 调一个 70B 模型在某些场景下体验更好。QAT 让这件事的硬件门槛进一步往下走。

如果你是 Ollama 或 llama.cpp 用户，今天就能拉到权重直接跑：

# Ollama 一行拉起
ollama pull gemma4:31b-qat-q4_0
ollama run gemma4:31b-qat-q4_0

# llama.cpp 直接加载 GGUF
./llama-cli -m gemma-4-31b-it-qat-q4_0.gguf \
  -c 32768 -ngl 99 \
  -p "解释一下 QAT 和 PTQ 的区别"

需要云端调用 Gemma 4 满血版本做对比测试的开发者，OpenAI Hub 这边已经接入了 Gemma 4 系列，一个 Key 走 OpenAI 兼容格式就能在 Gemma、GPT、Claude、Gemini 之间切来切去做 A/B 评测，省去了本地部署和云端各配一套 SDK 的麻烦。

一点判断

QAT 这种工程优化看起来不性感，但它是把开源模型从"benchmark 玩具"推到"生产可用"的关键一步。Google 这次 Q4_0 和 Mobile 双线发布，节奏比 Gemma 3 时代更紧凑——主线发布两个月就把官方量化跟上来，覆盖范围还更全。

对竞争对手也是个压力。Llama 系列至今没有官方 QAT 检查点，Qwen 那边主要靠社区 GGUF。如果 Gemma 4 QAT 实测损失真的能控制在 1-2% 以内，本地部署这条赛道的默认选项可能要换人了。

下周等社区跑完完整 benchmark，应该能看到更细的对比数据。值得关注的几个点：QAT 在 256K 长上下文上的退化幅度、Mobile 版本在骁龙 8 Gen 4 和 A18 Pro 上的实际 token/s、以及 26B A4B 这个 MoE 配置在量化后的路由稳定性——MoE 量化历来比密集模型麻烦，Google 这次怎么处理，会是后续值得抠的细节。

参考来源

• Gemma 4 QAT 模型已发布讨论帖 - linux.do：社区第一时间的发布讨论，包含下载链接和初步上手反馈
• Gemma 4 QAT Q4_0 Collection - Hugging Face：Google 官方上传的桌面级 Q4_0 量化权重，覆盖 E2B 到 31B 全尺寸
• Gemma 4 QAT Mobile Collection - Hugging Face：面向移动设备的优化版本，针对 ARM 架构做了算子调优