先算账：16GB 到底能装下什么
显存不是只装权重。除了模型本身，还要留出 KV 缓存、激活值、框架开销。一个粗略的分配是：权重占大头，KV 缓存随上下文长度和并发线性增长，框架与碎片留一到两个 GB。很多人卡住不是权重装不下，而是开了长上下文之后 KV 缓存把剩下那点空间吃光了。
- 权重：由参数量与每参数位数决定，低比特量化主要省的就是这一块
- KV 缓存：跟上下文长度、并发数、层数、头维度有关，是长上下文场景里最容易被低估的一项
- 框架与碎片：留 1-2GB 余量，别把显存算满
- 先定「要多长上下文、几个人同时用」，再倒推权重的位数预算，顺序不要反
再选方案：量化不是越狠越好
同样是低比特，做法差别很大：有的是对所有权重一刀切，有的是按层、按通道判断敏感度再决定精度。后者的好处是把宝贵的精度额度留给真正敏感的层，代价是实现更复杂、可选的方案更少。选的时候先看两件事——它保不保留你需要的功能（工具调用、思考模式、视觉输入），以及有没有可复现的对齐指标。
- 先确认功能没被砍掉：有的量化版会丢掉视觉塔或多模态部分
- 看它给了什么对齐指标：困惑度、token 一致率、KL 散度都只能作参考，不能当结论
- 注意上下文是否被缩短：有些版本为了省显存会砍上下文长度
困惑度差 0.02% 不等于你的任务差 0.02%——平均分几乎不动，长尾可能已经在掉。
最后验收：用自己的数据做对照
这是整套流程里最容易被跳过、也最不能跳过的一步。量化最典型的失效方式是「看起来都对」：常规问答没问题，但让它逐字复述一段长文本、严格按格式输出 JSON、或者在信息不足时拒绝回答，错误就开始出现。这些只有在你自己的任务上才看得出来。
- 准备一份 20-50 条的验收集，覆盖真实任务里最容易出错的三四类
- 同一组输入，量化版和原版各跑一遍，逐条对照，而不是看总分
- 重点看三类失败：格式破坏、长尾事实错误、该拒绝时没拒绝
- 记录下每个方案的显存占用、首 token 延迟、每秒输出，把「能跑」和「能服务」分开评估
上线之后：把量化方案当成会变的变量
量化方案更新得很快，同一个模型的更好版本可能几周后就出现。把验收集和对照脚本留下来，换方案时重跑一遍即可，不必重新设计评估。这也是把「能不能用」变成一条可重复执行的判断，而不是每次靠感觉重来。