Gemma 4 QAT：在消费级显卡和1GB手机上跑31B大模型

Gemma 4 QAT 全家桶：五款模型，各显神通

本次共有五个参数规模的模型获得了 QAT 版本，每个版本都配备了用于推测解码的配套模型。下表清晰展示了它们从 BF16 到 QAT 4-bit 的巨大内存变化 ：

这些内存数据来源于谷歌官方模型概览和 Unsloth 文档，其中 Q4_0 采用的就是社区中极为流行的 GGUF 量化级别 。E2B 约 1GB 的移动端指标最为吸睛——谷歌专门为其打造了一种混合精度模式，包括针对性的 2-bit 解码层和优化的 KV 缓存，才能达到这个效果 。如果去掉嵌入层，纯文本模型的占用甚至能降到 1GB 以下 。

26B A4B 模型尤其值得关注。它是一种混合专家架构，尽管总参数量高达 260 亿，但在处理每个 token 时只激活约 38 亿个参数。这意味着它跑起来像个小得多的模型，但智能程度却能媲美大得多的密集模型 。在 4-bit 版下，它完全能装进 12-16 GB 显存的显卡——这是很多开发者现在手里就有的装备 。

四种部署格式，选对了才能保住性能

谷歌这次放出了四种官方格式的 QAT 检查点，选哪种会直接影响最终效果 ：

• Compressed-tensors (W4A16)：用于 vLLM 推理的官方格式，采用 4 位整型权重和 16 位激活 (group_size=32)。如果你想确保模型性能在谷歌测试的质量范围内，这是首选 。
• GGUF / Q4_0：目前 llama.cpp、Ollama 等生态工具中使用最广的格式。所有五款模型的即用型 GGUF 文件都已发布 。
• 移动端优化格式：谷歌专为手机硬件设计的一种混合精度模式，只在 E2B 和 E4B 上提供。正是它实现了 E2B 仅 1GB 的内存占用 。
• 未量化的 QAT 检查点：从 QAT 流程中提取的半精度权重。这是为那些想自己动手进行定制量化或编译的研究者准备的 。

最重要的一点警告：千万别瞎转格式。据 Unsloth 的文档显示，如果不加特殊处理，直接将 QAT 权重简单地转换成 Q4_0，26B 模型的 Top-1 准确率会暴跌到约 70.2% 。而他们自家的动态量化方法能达到 85.6%，提升了惊人的 15.4 个百分点。这个例子充分说明，格式选择和转换方法对于保住 QAT 应得的性能至关重要 。

对多数用户来说，直接使用官方的压缩张量或 GGUF 文件是最安全稳妥的。

这模型，我手里的硬件真能跑？

QAT 不只是减少了内存，它彻底重塑了本地 AI 推理的硬件版图。过去需要数据中心显卡的模型，现在消费级设备和手机都能驾驭了。

智能手机和边缘设备：E2B 就是为移动端而生的。通过谷歌的 LiteRT-LM 框架，用 2 位和 4 位量化，它可以在内存占用低于 1.5GB 的手机上流畅运行。谷歌自家的 AI Edge Gallery 应用甚至已经上架 Play Store，可以直接选 E2B 或 E4B 完全在设备上离线运行 。这两款模型都支持文本、图像和音频输入，意味着实时语音翻译、视觉问答这样的应用，现在都能不依赖云端，直接在手机上实现了 。

8GB 显存显卡：QAT 部署的甜点区。E2B (~3.2 GB)、E4B (~5 GB) 和 12B 模型 (~7 GB) 在 Q4_0 量化下，都能舒舒服服地躺在 8GB 显存里 。也就是说，现在一台带移动版 4060 的中端笔记本，或是一块老旧的 RTX 2070 显卡，就能在本地跑一个拥有 256K 上下文窗口的统一多模态模型，这在 16 位精度时代不配个 24GB 以上的显卡根本不敢想。

12–16 GB 显存显卡：26B A4B MoE 模型在这里找到了用武之地，Q4_0 版本约占 15GB 显存，能轻松装入 RTX 3080、4070 Ti 或 4080 等显卡 。它的 MoE 架构也意味着推理延迟比其他类似体积的密集模型更低，因为每个 token 只激活一小部分参数 。

20–24 GB 显存显卡：31B 的满血密集模型在 Q4_0 下大约需要 17–18 GB，这让 RTX 3090 和 4090 的拥有者们有了用武之地，还能留出一些空间给 KV 缓存和批处理 。毕竟在满血 16 位精度下，这家伙可要吃掉将近 60GB 显存，对消费级显卡来说完全是天方夜谭。QAT，真正让这个最大的 Gemma 4 模型在单块发烧级显卡上落了地。

必须重视的“内存陷阱”：上面讨论的都是模型权重的内存占用，不是最终完整的显存消耗。运行时开销，尤其是长上下文窗口所需的 KV 缓存，会在基础占用上再增加几个 GB。有社区反馈显示，31B 模型配合 256K 上下文，总需求可能会超过 20GB 。部署的时候，请务必给系统多留些余量。

性能保住了多少？优势和局限在哪？

QAT 的核心承诺，就是以极低的内存代价换取近乎原始的性能。各种跑分基本也验证了这点。谷歌官方文档用“性能接近原始”来形容，并且内存降低了约 72%。社区基准测试也显示，Q4 量化对比 BF16，性能损失大概在 3% 到 5% 这个范围 。

但就像前面警告的，这里面的水很深。从 Unsloth 揭露的那个案例——26B 模型从直接转换的 70.2% 准确率，到经特殊优化的 85.6%——就能看出，最终成果的质量，严重依赖于你如何处理和部署这些 QAT 权重 。别想当然地以为随便拉个 QAT 检查点，往标准 GGUF 转换器里一扔，就能得到应有的效果。

在生产环境中，最稳妥的做法是用谷歌官方的 QAT 检查点，直接部署它提供的压缩张量格式（用于 vLLM）或官方 Hugging Face 上的 GGUF 文件 。如果你需要超出谷歌官方提供的定制量化，那务必留出充分的测试和性能调优时间，因为 QAT 权重对转换方法比一般的量化权重要敏感得多。

这次发布，到底解锁了什么？

从实际应用的角度，这次发布彻底改变了“这模型我能在本地跑吗？”这个问题背后的默认答案。一个主流的开放权重模型家族，首次将 QAT 检查点作为一等公民提供，而非事后补救。其影响在以下几个方向上迅速展开：

强隐私需求场景：医疗、法律和个人助理这些原本必须依赖云 API 的应用，现在完全可以在手机或笔记本上离线运行，而且 QAT 保证的性能足以让本地推理变得真正可用 。

离线与边缘部署：野外调研、灾害响应、没有可靠网络的工业场景，现在都可以用普通硬件部署强大的多模态模型。E2B 的音频支持配上 1GB 的移动端量化，让在中端手机上实现实时语音翻译变得触手可及 。

开发者工具与 IDE：12B 和 26B 模型正好能装进开发者手头的硬件里，让代码补全、重构、文档生成能完全在本地跑，没有延迟焦虑，也不用担心 API 费用。谷歌官方将量化版定位为“IDE、代码助手和智能体工作流的理想之选” 。

研究与微调实验：那些买不起 A100 或 H100 集群的小型研究团队和个人开发者，现在终于可以在消费级硬件上直接摆弄 12B 到 31B 这些级别的大模型，进行定制和特定领域的微调了。门槛被极大地拉低了。

所有这些模型都以 Apache 2.0 许可发布，已经可以从 Hugging Face 下载全部五个尺寸 。