Gemma 4 的 QAT 权重：端侧推理的瓶颈从「能不能跑」换成了「省不省电」
Google 给 Gemma 4 放出量化感知训练（QAT）的权重，把 E2B 的内存占用压到 1GB，能在手机和消费级显卡上跑。真正的转折不是「能跑了」，而是它把矛盾从「装不装得下」推到了功耗、隐私边界和质量损失到底有多大。
概述
6 月 5 日，Google 给 Gemma 4 这一系列开放模型放出了一批用量化感知训练（quantization-aware training，下称 QAT）做出来的权重。一句话讲清楚它干了什么：同一批模型，换了一种「带着量化一起练」的训练方式重新出炉，结果是内存占用大幅下降，可以直接跑在手机和消费级显卡这类日常硬件上。其中边缘小模型 Gemma 4 E2B 的内存占用被压到了 1GB。
但这条消息真正值得记住的，不是「Gemma 4 现在能在手机上跑了」这句宣传话。能在手机上勉强加载一个模型，过去两年各家都演示过。值得记的是它把端侧推理的核心矛盾换了一个。从前是「装不装得下」这种二元问题，现在挪到了几个连续的、需要工程权衡的问题上：跑起来费不费电，本地处理换来多大的隐私边界，压缩之后质量到底掉了多少。当「能跑」不再是门槛，剩下的这几件事才是决定一个端侧功能能不能从演示走进产品的真东西。这篇就沿这条线读。
发生了什么
先把事实摆清楚。这次发布的是一批新的权重检查点（checkpoint），不是新模型。Gemma 4 本体两个月前就发了，期间 Google 还陆续加过多 token 预测（multi-token prediction，MTP，一次预测多个 token 来加速推理），又补了一个 12B 模型去填 E4B 和 26B MOE 之间的空档。这次的主角是量化：用 QAT 的方式把已有模型重新压一遍。
具体给了两种量化格式。一种是社区里用得最广的 Q4_0（大致是把权重压到 4 比特），QAT 这套配方被套用到所有模型上；另一种是专门为移动端场景新设计的量化格式，只用在两个边缘模型 E2B 和 E4B 上。靠这个移动格式，Gemma 4 E2B 的内存占用被压到了 1GB。官方还补了一句，如果只要文本、不要音频和视觉编码器、并去掉逐层嵌入（Per-Layer Embeddings），E2B 纯文本版连 1GB 都不到。
QAT 本身不是新概念，但这里的判断点在于 Google 把它当成默认交付物，而不是给极客的可选项。它的原理是在训练过程中就模拟量化带来的精度损失，让模型在训练时就「知道」自己最终会被压到低比特，从而提前把权重调整到对量化更鲁棒的状态。这跟传统训练后量化（post-training quantization，PTQ，先正常训练、训练完再压）是两条路。官方的说法很克制：PTQ 已经能较好地保住质量，但他们的 QAT 结果相比标准 PTQ 基线，整体质量更高。注意这里没有给出任何具体数字，它没说「质量损失从百分之几降到百分之几」，只给了方向。这一点后面会再提。
落地配套也一并给齐了：权重直接放在 Hugging Face 上，GGUF 格式对接 llama.cpp，压缩张量对接 vLLM，桌面端可以用 Ollama、LM Studio 直接拉来跑，端侧有 Google 自家的轻量运行时 LiteRT-LM，浏览器里能用 Transformers.js，Apple Silicon 上有 MLX，微调走 Hugging Face Transformers 和 Unsloth。这套清单本身就是个信号：Google 没打算自己造一个端侧运行时去圈人，而是把权重铺进了开发者已经在用的每一个工具里。
这条消息在 Hacker News 上有讨论，但热度明显低于上一代「Gemma 3 QAT」发布时。热度回落本身不奇怪。QAT 从惊喜变成了预期动作，这恰恰说明端侧量化已经从「新闻」沉淀成了「基础设施」。
为何重要
把模型压进消费级硬件这件事，过去的叙事一直停在「内存」这一个维度：显存够不够大、装不装得下。这次发布值得重视，是因为它基本上把这个维度解决掉了。E2B 压到 1GB，意味着一台稍微像样的手机就能常驻一个能用的语言模型。一旦「装得下」不再是问题，真正的瓶颈就浮上来，而它们一个比一个难。
第一个是功耗。手机不是显卡，跑模型时每一次解码都在烧电池、在发热。量化的好处不只是省内存，还能加速解码（decode），这点官方明确提了，量化在缩小内存占用的同时也加快了解码速度。但更快的解码不等于更省电，端侧产品里「能跑」和「能一直跑而不烫手、不掉电」是两件事。这次的移动专用格式里有几个动作正是冲着这个去的：把激活值的缩放参数在训练时就预先算好（静态激活），省掉运行时反复计算的开销；按通道做量化（channel-wise），让数据结构贴合移动加速器的设计，使手机能原生跑而不必走慢速的兼容路径。这些都不是为了再省点内存，而是为了让芯片少干活、少发热。瓶颈已经从容量挪到了能耗。
第二个是隐私边界，这才是端侧真正值钱的地方。模型在本地跑，数据不出设备，这是云端 API 给不了的属性。但「数据不出设备」是个需要严格界定的承诺，不是一句营销话：哪些计算在本地，哪些功能仍要回连云端，模型更新走什么通道，每一条都是边界。把模型做到能装进 1GB，只是让这个边界有可能成立；要让它真的成立并且站得住，是产品设计和工程的活，不是量化本身能给的。这次发布把这扇门推开了，门后的路还得自己走。
第三个，也是最该警惕的，是质量损失到底有多大。官方说 QAT 比标准 PTQ 质量更高，方向上完全可信，这正是 QAT 这套方法存在的理由。但「更高」是个相对词。它相对的是 PTQ，而不是相对于原始的全精度模型。换句话说，QAT 是在「反正都要压」的前提下，把压缩造成的损失尽量做小，而不是消除损失。尤其那个移动格式里有一招很激进：把专门负责生成 token 的那部分参数压到 2 比特，同时把核心推理层保持在较高精度。这是一个明确的取舍，赌的是「生成层即使粗糙、推理层只要够准，模型整体就还够聪明」。这个赌注在多数日常任务上大概率成立，但在哪类任务上会先露馅，官方没说，得你自己测。
对建设者的影响
如果你在做端侧或本地优先（local-first）的功能，这批权重值得直接拉下来试，但有几个附加条件。
门槛是真的降了。E2B 在 1GB 量级、配合 llama.cpp / Ollama / LM Studio / LiteRT-LM 这套现成工具链，意味着你不用再为「跑得起来」写一堆基础设施代码。这件事的实际价值是：把端侧从一个需要专门团队啃的硬骨头，变成一个普通后端工程师一下午能验证可行性的选项。但「能跑通 demo」和「能交付产品」之间，隔着上面说的功耗和质量两道坎，别把前者当成后者。
QAT 权重应当成为你的默认起点，而不是自己拿全精度模型去做 PTQ。逻辑很简单：既然 Google 已经用 QAT 把质量损失做到比 PTQ 更小、还直接给了 Q4_0 的 GGUF 和给 vLLM 的压缩张量，你自己再去做一遍 PTQ 多半是花力气得到更差的结果。MTP 也有对应的 QAT 检查点，也就是说推理加速和量化压缩可以叠着用，不是二选一。
按需裁剪模态是个被低估的杠杆。Gemma 4 是多模态的，但音频和视觉编码器在很多场景根本用不上。官方明确说你可以只部署需要的模态来进一步压内存，E2B 纯文本版（去掉逐层嵌入）连 1GB 都不到。如果你的功能只处理文本，把这两个编码器砍掉是几乎零成本的内存收益，没理由不做。
最该投入的精力，是建立你自己的质量评测。官方只给了「QAT 优于 PTQ」这个方向性结论，没给任何能让你直接照搬的数字。你的产品质量门不能建在别人的相对结论上，必须拿你自己的真实任务、真实输入去测 QAT 版相对全精度版掉了多少，尤其要盯那个 2 比特的生成层在你的场景里有没有副作用。这步绕不过去。
该忽略什么
忽略「现在能在手机上跑大模型了」这种把它当成里程碑的叙事。能在手机上跑模型不是新闻，跑得省电、隐私边界清楚、质量够用才是。把注意力放在那三个连续问题上，别停在「能跑」这个二元结论里。
忽略一切关于「质量损失只有 X%」「几乎无损」的精确说法，除非它能溯源到你自己的测试。源里没有给出任何具体的质量损失数字，也没给出各模型确切的内存需求表数值（官方有这张 VRAM 表，但只说是「近似」值，且具体数字本文无法核实）。任何在外面流传的精确百分比，要么是别人在特定任务上测的、不一定适配你的场景，要么干脆是编的。
也别把这次发布解读成 Google 要自建端侧生态去跟谁圈地。它把权重铺进了 llama.cpp、Ollama、LM Studio、vLLM、MLX、Transformers.js 这一长串别人家的工具里，LiteRT-LM 只是其中一个选项。这是「让权重无处不在」的开放打法，不是平台锁定。读这条消息时，重点是这批权重能进你的栈，而不是 Google 又推了什么运行时。
技术要点
移动专用量化格式里有四个动作值得单独记，因为它们解释了为什么这次不只是又一轮 PTQ。静态激活，把数据缩放的参数在训练阶段预先算好，省掉移动芯片运行时反复计算的开销，响应更快。按通道量化，把压缩后的数据结构对齐移动加速器的设计，让手机能原生计算、不走慢速兼容路径。定向 2 比特量化，只把负责生成 token 的那部分参数重压到 2 比特，核心推理层保持较高精度，省存储而尽量不掉智商。嵌入与 KV 缓存优化，把压缩重点放在模型的词表和短期记忆（KV 缓存）上，大幅压低活跃内存占用，让长对话不至于爆内存。这四点合起来是一句话：QAT 不是训练完再压，而是为移动芯片的硬件特性，在训练时就把模型塑形成它喜欢的样子。这也是它和训练后量化在工程上的真正分界。