开放模型量化怎么选版本：从 252GB 压到 93GB 的案例说起

社区把 MiniMax M3.1 Flash（428B）在十天内从 252.4GB 压到 93GB，压缩比接近 2.7 倍，官方公开致谢。借这个案例讲清楚量化版本该怎么选。

压缩靠什么

不是简单调低比特。核心是混合精度分配：不同层对精度的敏感度差很多。注意力层、路由层、嵌入层通常要保精度，FFN 层可以更激进。逐层测敏感度、分别定比特宽度，是这类工作的通用方法。

93GB 的意义

这个体积能放进单机多卡或八卡消费级服务器，不需要集群。对一个 428B 的 MoE 来说，是从「只有大厂能跑」到「中型团队能试」的跨越。

选版本的三条硬标准

一，看是谁做的。有公开评测方法、有对比数据的，可信度高。只说「精度几乎无损」不给指标的，直接跳过。

二，看长上下文与工具调用是否保留。量化最容易坏的就是这两项：长上下文的位置编码对精度敏感，工具调用依赖结构化输出的稳定性。很多量化版本在短问答上看不出问题，一上 Agent 流程就崩。

三，自己在真实任务上抽测。准备五十条你业务里的典型请求，对比量化版与原版的输出。重点看格式合规率与拒答率，这两个指标比 BLEU 之类的相似度更能反映可用性。

常见误区

同一模型有五六个量化版本，每个的精度损失点不一样。看到别人说某个版本好用就照搬，很可能在你的任务上翻车。

部署建议

先小流量灰度，把量化版与原版并行跑一周，比对线上指标。别一次性全量切换，回滚成本很高。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

混合精度分配是正路，注意力和路由层保精度，FFN 可以激进。最容易被量化搞坏的是长上下文和工具调用的结构化输出，短问答上根本测不出来。

逐层测敏感度这件事门槛比听起来高，需要一套能复现的评测集，否则压完发现某类任务掉点，根本定位不到是哪一层。我们踩过的坑是把嵌入层也一起压了，长文本检索召回直接掉一截，后来把嵌入和路由层锁在 8bit 才恢复。