Google 6 月 5 日发布了一批 Gemma 4 QAT 检查点。

最抓人的数字是：在面向移动端的新量化格式下，Gemma 4 E2B 的内存占用可降至约 1GB。若是文本-only，并且不包含 Per-Layer Embeddings，占用还可以低于 1GB。

但这件事不能理解成“Gemma 4 变聪明了”。

QAT 解决的不是模型能力上限，而是本地运行成本。它要做的是在压缩之后尽量少掉质量，让小模型更现实地跑进手机、笔记本和消费级 GPU。

这才是端侧 AI 现在最硬的一道坎：模型已经有了，设备未必扛得住。

Google 这次给了什么：Q4_0 和移动端专用格式

这批 Gemma 4 QAT 检查点主要面向本地推理和端侧部署。

发布内容里有两条线。一条是常见的 Q4_0 格式，方便接入桌面本地推理生态。另一条是面向移动端的新量化格式，重点照顾 E2B、E4B 这类 edge models。

简单放在一张表里看：

发布内容具体指向对开发者的直接影响
Q4_0 检查点常见本地推理格式更容易进入 llama.cpp、Ollama、LM Studio 这类桌面工具
移动端量化格式面向 E2B、E4B 等 edge models降低手机、平板、轻量设备的内存压力
E2B 内存占用移动格式下约 1GB；文本-only 且不含 Per-Layer Embeddings 时低于 1GB端侧小模型实验更接近可用，而不是只停在演示
工具链支持Hugging Face、llama.cpp、Ollama、LM Studio、LiteRT-LM、Transformers.js、SGLang、vLLM、MLX、Unsloth 等少一些格式转换、运行时适配和环境折腾

工具链这部分很关键。

很多本地模型不是死在模型本身，而是死在“怎么跑起来”。格式不兼容、运行时不支持、转换链路太长，都会消耗开发者时间。

Google 这次把 QAT 检查点和主流工具链一起铺开，说明端侧部署已经不是模型发布后的社区补丁，而是交付时就要考虑的部分。

对本地部署大模型的开发者，动作会很具体：如果原来在等 GGUF、等 Ollama、等 LM Studio 支持，现在可以更早把 Gemma 4 QAT 放进测试队列。团队不一定立刻迁移，但可以少做一轮自制量化和格式转换。

对关注端侧 AI 和消费级硬件推理的人，也不是立刻换设备。更现实的判断是：Apple Silicon 笔记本、消费级 GPU、小内存设备上的可试范围变大了，采购或升级硬件的决定可以往后放一放，先看 QAT 版本在自己场景里的稳定性。

为什么 QAT 重要：它不是训练后再压一遍

QAT 是 Quantization-Aware Training，量化感知训练。

它和 PTQ 的差别在时机。PTQ 是模型训练完之后再压缩。QAT 则是在训练过程中模拟量化，让模型提前适应低精度表示。

这不是一个包装词。压缩约束进入训练过程，模型就有机会学会和量化误差相处。

路线做法优点现实限制
PTQ训练后量化快，适合后处理和社区适配压得狠时质量更容易掉
QAT训练中模拟量化压缩后通常更有机会保住质量需要在训练阶段就纳入设计

所以，QAT 的价值是“少损失”，不是“白送性能”。

参数从高精度压到 4-bit、2-bit 后，显存和存储会下降，推理也可能受益。但质量、延迟、发热、长上下文稳定性，不会因为量化两个字自动变好。

Google 这次移动端方案里还包含几项底层取舍：静态激活、channel-wise 量化、部分 2-bit 量化，以及 Embedding 和 KV cache 优化。

其中 KV cache 值得单独看一眼。对话越长，它吃内存越多。端侧设备内存本来就紧，KV cache 如果不处理，模型参数压小了，运行时照样可能顶不住。

这也是我更在意的地方：端侧部署不是只看模型文件大小。真正上设备时，参数、激活、KV cache、运行时和硬件调度，都会一起算账。

影响在哪里：小模型更近了，但边界也更清楚

这次受影响最大的，不是拿手机随便问两句的普通用户，而是两类人。

一类是本地部署大模型的开发者。他们关心的是能不能少占显存、少踩工具链坑、少为适配花时间。Q4_0、GGUF、Ollama、LM Studio、vLLM、MLX 这些支持，直接影响实验能不能快速开始。

另一类是做端侧 AI 应用的人。他们关心的是 App、浏览器、离线功能能不能装下一个小模型。LiteRT-LM 和 Transformers.js 这类路径，给的是更靠近产品侧的入口。

但边界必须讲清。

Gemma 4 QAT 不等于所有 Gemma 4 模型都能在手机上流畅运行。原文重点放在 E2B、E4B 这类 edge models。约 1GB 也不是所有模态、所有配置下的固定占用。

文本-only、不包含 Per-Layer Embeddings，这些条件不能省。视觉和音频编码器在一些场景可以不部署，内存数字才会继续往下走。换句话说，能省，是因为只带需要的部分。

和 Llama、Qwen、Phi 等模型生态相比，这条路线并不陌生。开源社区早就在围绕 GGUF、AWQ、GPTQ、bitsandbytes 等方案做压缩和本地推理。

区别在于，不少方案是模型发布后由社区补齐。Google 这次把 QAT 检查点和工具链支持一起给出来，至少表明它把端侧交付放到了更前面的位置。

接下来最该看的不是发布页上的单个内存数字，而是三个变量：

  • 长上下文下，输出质量是否稳定；
  • 移动芯片上，实际延迟和发热能不能接受；
  • 加入多模态组件后，内存占用是否还在目标设备承受范围内。

如果这三项过不了，1GB 只是好看的入口数字。若能过，E2B、E4B 这类小模型才有机会从开发者 Demo 走向更常见的离线功能。

这也是本文的主线：QAT 没有抬高模型天花板，它是在压低落地门槛。门槛低一点，端侧 AI 才少一点纸上谈兵。