| 模型 | 架构 | 活跃参数量 | BF16 内存占用 | QAT 4-bit 内存占用 | 最适合的硬件 |
|---|---|---|---|---|---|
| E2B | 密集 + PLE | 有效 ~2.3B (含嵌入 5.1B) | ~9.6 GB | ~3.2 GB (Q4_0); 约 1 GB (移动端格式) | 智能手机、边缘设备、浏览器 |
| E4B | 密集 + PLE | 有效 ~4.5B (含嵌入 8B) | ~15 GB | ~5 GB (Q4_0) | 中端显卡、大内存移动设备 |
| 12B | 密集,无编码器统一多模态 | 11.95B | ~24 GB | ~7 GB (Q4_0) | 8GB 显存显卡、带独显的笔记本 |
| 26B A4B | 混合专家 (MoE) | 活跃 ~3.8B (总计 26B) | ~48 GB | ~15 GB (Q4_0) | 12–16 GB 显存显卡、高端工作站 |
| 31B | 密集 | 30.7B | ~58 GB | ~17–18 GB (Q4_0) | 24 GB 显存显卡 (RTX 3090/4090) |
这些内存数据来源于谷歌官方模型概览和 Unsloth 文档,其中 Q4_0 采用的就是社区中极为流行的 GGUF 量化级别 。E2B 约 1GB 的移动端指标最为吸睛——谷歌专门为其打造了一种混合精度模式,包括针对性的 2-bit 解码层和优化的 KV 缓存,才能达到这个效果
。如果去掉嵌入层,纯文本模型的占用甚至能降到 1GB 以下
。
26B A4B 模型尤其值得关注。它是一种混合专家架构,尽管总参数量高达 260 亿,但在处理每个 token 时只激活约 38 亿个参数。这意味着它跑起来像个小得多的模型,但智能程度却能媲美大得多的密集模型 。在 4-bit 版下,它完全能装进 12-16 GB 显存的显卡——这是很多开发者现在手里就有的装备
。
最重要的一点警告:千万别瞎转格式。据 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 检查点作为一等公民提供,而非事后补救。其影响在以下几个方向上迅速展开:
开发者工具与 IDE:12B 和 26B 模型正好能装进开发者手头的硬件里,让代码补全、重构、文档生成能完全在本地跑,没有延迟焦虑,也不用担心 API 费用。谷歌官方将量化版定位为“IDE、代码助手和智能体工作流的理想之选” 。
研究与微调实验:那些买不起 A100 或 H100 集群的小型研究团队和个人开发者,现在终于可以在消费级硬件上直接摆弄 12B 到 31B 这些级别的大模型,进行定制和特定领域的微调了。门槛被极大地拉低了。
Comments
0 comments