428B 的模型被压到 93GB：社区十天的量化实录

开放权重模型 MiniMax M3.1 Flash（428B）发布后十天内，社区开发者把它从 252.4GB 压到 93GB，MiniMax 公开致谢并点名。这个模型采用量化感知训练与稀疏注意力，面向 Coding 与 Agent 任务，上下文最高可达 100 万 token。

另一组可作参考的数字：Liquid AI 的 LFM3-1.7B 量化报告显示，近乎无损的版本只占 3.6GB 显存，2.2GB 版本有轻微性能衰退。

显存怎么估

权重显存约等于参数量乘以每参数字节数：BF16 是 2 字节，Q8 约 1 字节，Q4 约 0.5 字节。然后留 15% 到 30% 给 KV cache 与运行时开销。长上下文场景下这个比例要上调，因为 KV cache 随序列长度线性增长。

选档位的正确顺序

先定上下文长度，它决定 KV cache 的量级；再定并发数，它决定 KV cache 要乘几份；最后才挑量化精度。反过来做，经常是上线三天后发现显存不够。

验收别只看困惑度

用你自己的任务集跑一遍，重点看三项：格式遵循（结构化输出有没有坏）、工具调用成功率、长上下文召回。量化损失在不同任务上分布极不均匀，有些任务几乎无损，有些会明显退化。

工程上的两个技巧

一是分层量化，注意力层用高精度、前馈层用低精度；二是把系统提示词与工具定义固定在缓存里，避免每轮重算。

一个常识

社区能在十天内压掉 60% 的体积，说明原版的冗余留得比较多。这不是缺陷，是给下游留的余地。

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

显存估算那段很有用，但 KV cache 常常被忽略。我们上次按权重算够用，结果长上下文一开就爆。建议再加一条：先压并发，再谈精度。

252G 压到 93G 大概是 4bit 加稀疏的量级。真正决定能不能用的是 batch size 和 KV cache，权重只是入场券，100 万上下文下 KV 比权重还吃显存。我们本地 70B 做 4bit 时，长上下文一开就得靠 PagedAttention 省，否则两张 80G 都撑不住。