很多人卡在同一个地方：模型能跑起来，但一上并发就爆显存，或者量化之后回答变傻、代码跑不通，却说不清是档位选错还是别的问题。这篇不聊原理科普，只给动手流程——先判断你的场景该不该量化、按什么顺序试档位、显存和并发怎么估、跑完怎么验证、出问题按什么顺序排查。数字都去站内对应页面看当时的口径。
很多人卡在同一个地方：模型能跑起来，但一上并发就爆显存；或者量化之后回答变傻、代码跑不通，却说不清是档位选错还是别的问题。这篇不聊原理科普，只给动手流程——先判断你的场景该不该量化、按什么顺序试档位、显存和并发怎么估、跑完怎么验证、出问题按什么顺序排查。
所有涉及具体数字的地方，都请你到站内对应页面看当时的口径，不要照搬别人博客里的旧数据。下面按动手顺序一节一节来。
先判断：你这个场景到底该不该量化
- 量化换的是「装得下」和「跑得快」，代价是精度。先问自己卡在哪一头：是根本装不下、还是装得下但慢、还是装得下也够快只是想省钱。三种情况处理方式不一样。
- 适合动手量化的信号：单卡显存贴着模型权重走、只能靠 CPU 卸载硬撑、并发一上来就排队。
- 不适合的信号：任务本身对细粒度数值、长链条推理、结构化输出格式极敏感，这时候降档位往往得不偿失。
- 先做一个不量化的基线：同一批真实任务跑一遍，把回答质量、单条延迟、能撑住的并发记下来，后面所有档位都跟这个基线比，而不是跟别人的跑分比。
拿不准自己属于哪类，先到部署测算页面按参数量和卡型对一遍，再决定要不要动量化。基线没做就开量，后面掉点你连归因都做不了。
下一步去部署测算页面按你的卡型和参数量先跑一遍估算，确认瓶颈到底在显存还是延迟，再决定量化是不是你的主路径。→档位不是越狠越好：按顺序试，每档留证据
从损失最小的档位往下走，每降一档就跑一次同一批任务，记录三类证据：格式是否还合规、关键事实有没有变、长输出有没有中途崩。不要一次跳两档，跳档后出问题你根本不知道是哪一档引入的。
| 观察项 | 合规表现 | 危险信号 |
|---|---|---|
| 输出格式 | JSON/函数调用能稳定解析 | 字段丢失、括号不闭合 |
| 关键事实 | 抽检事实性问题答案一致 | 数字、日期、单位被改写 |
| 长输出 | 能完整收尾不中断 | 中途重复、突然截断 |
| 推理链条 | 步骤数基本不变 | 步骤跳步、结论前置 |
不同量化格式的取舍点不一样：有的偏通用兼容、有的偏吞吐、有的偏部署方便。判断依据是「你的推理框架认不认这种权重」，而不是哪个名字听起来更先进。格式对照去模型底层概念随手对照页面查，别凭印象选。
- 量化不是唯一省显存手段。很多时候先做上下文控制和批大小调整，效果比降档位更好、代价更小。
- 这条要跟量化一起排进候选清单，按成本从低到高试。
- 如果模型是你自己微调过再量化的，微调权重的分布和基座不同，掉点可能比公开结论更明显，必须单独验。
显存与并发：按模型+档位+上下文一起估，别只算权重
估算要拆成四块：权重、KV 缓存、框架自身开销、临时峰值。只算权重是新手最常见的翻车点，长上下文一来 KV 缓存能吃掉一大截。
| 组成项 | 跟什么变 | 估算时怎么处理 |
|---|---|---|
| 权重 | 参数量、量化档位 | 按档位折算，别用原始精度 |
| KV 缓存 | 上下文长度、并发数 | 按典型输入输出长度乘并发 |
| 框架开销 | 推理框架、批策略 | 留固定余量 |
| 临时峰值 | 首次加载、长请求 | 单独留出一块余量 |
把上下文长度当成一等变量：同一个模型同一个档位，上下文翻倍，能支撑的并发往往要打折。所以估算表里必须带上「典型输入输出长度」这一列，不能只写个平均值。
- 确定典型长度从真实日志里取输入和输出的长度分布，别拿理想值。
- 按四块加总权重、KV 缓存、框架开销、峰值余量逐项写下来。
- 留峰值余量别把显存卡到满格，上线后实测复核再加卡或调批。
- 复核口径到几张卡够用页面按它的口径复算一遍，看差多少。
不适用的情况：多模型混布在同一张卡上、或者带视觉/语音输入的应用，峰值特征完全不同，要单独压测，不能套纯文本的估算。
下一步去几张卡够用页面按你的模型和典型上下文长度重算一遍，把估算表落成一张纸，再决定加卡还是调批。→上线前后的验证与排查顺序
上线前：固定一批任务做回归，比对量化前后的差异清单。上线后：盯延迟分布和显存曲线，而不是只看平均值，长尾抖动才是用户能感知到的部分。
- 先看显存确认是不是被占满，是不是 OOM 或频繁卸载。
- 再看上下文是不是上下文太长导致缓存膨胀，检查输入长度分布。
- 然后看批与并发怀疑批大小和并发排队，降批跑一遍对比。
- 最后怀疑档位前三步都排除后，才回退量化档位，一次退一档。
如果质量掉得明显但显存还宽裕，先回退一档位而不是去改提示词。把变量分开，否则你永远不知道是哪个改动起的作用。验证工具与口径参考质量检测页面，把「什么叫通过」提前定义好，事后补救成本高得多。
量化不是一锤子买卖，是一组可控的试验，每档都要留下能对比的证据。下一步去工具目录的质量检测页把回归清单定下来，再动手降档位，这样每一步都有据可查。→
常见问题
量化之后模型明显变笨了，是不是档位选太狠？
有可能，但别急着下结论。先分开验证：把上下文缩短、批大小降到 1 再跑同样几条任务，如果质量回来了，说明是并发和上下文在拖后腿，不是量化本身。真的怀疑档位，就回退一档重跑同一批任务做对照，逐档留证据，别一次跳两档，否则你根本定位不到是哪一步掉的。
不量化是不是就不能上线，量化是不是必做步骤？
不是。如果显存够、并发要求不高、任务又对输出细节敏感，不量化反而更省心。量化的价值在于让本来装不下的模型装得下、让吞吐上去，它是手段不是目标。判断标准就是先跑一个不量化基线，看瓶颈到底在显存、在延迟还是在成本，哪一块最疼就先动哪一块，别为了量化而量化。
自己微调过的模型再量化，要注意什么？
重点是别直接套用基座的公开结论。微调后的权重分布和基座不一样，掉点幅度通常更大，而且不同微调方式的影响也不同。稳妥做法是：保留未量化的微调版本作为回退，量化后跑同一批垂直领域真实任务做对照，重点看格式稳定性和领域术语是否还准，别只看通用问答的观感。
