本地跑模型时，你多半会卡在同一个岔路口：同一个模型，社区里有满血的原版权重，也有各种压缩过的量化版本，选哪个？选大的怕显存爆，选小的又怕答得变笨。这篇不讲原理课本，只把精度、显存、速度三件事的取舍关系摆清楚，再给你一套按显卡、按任务、按能不能接受返工的决策顺序，照着对自己的机器过一遍就行。
本地跑模型时，同一个权重在社区里往往有好几个版本：一份是满血的原版权重，另外几份是各种压缩过的量化版本。选哪个不是看哪个新、哪个火，而是看你的卡能塞下什么、你的任务能容忍多少误差。这篇不讲量化原理课本，只把精度、显存、速度这三件事的取舍关系摆清楚，再给你一套照着机器过一遍的决策顺序。
先说清一个常见误区：很多人以为换个量化版本就能把显存占用砍掉一大半。实际上权重只是显存开销的一部分，还有激活值、KV 缓存和框架本身的固定开销，这部分该占还是占。所以量化能省多少，要按模型结构和你的使用方式来算，不能拿一个比例一刀切。
差别到底出在哪：一句话说清
非量化模型保留训练完成时的高精度权重，数值表示范围大、细节丰富；量化模型把权重压到更低位宽，用更少的比特存同一个参数，相当于给每个数做了一次粗粒度的四舍五入。所以差别不是「模型变笨了」这种定性说法，而是三层同时发生：权重体积变小、精度有损、计算路径变短。三者往往同向变化，但不是线性关系，不能简单按位宽比例去推结果。
- 权重体积
- 直接由位宽决定，是量化最确定、最可预期的一项收益。
- 精度损失
- 不同任务敏感度差别很大，必须拿真实输入测，不能靠感觉。
- 计算路径
- 是否提速取决于硬件是否原生支持该位宽，方向不固定。
- 固定开销
- 激活值、KV 缓存、框架开销不随权重位宽等比下降。
想看具体数字口径和换算方式，到「/tools/vram-calc」那一栏按你的模型和卡过一遍，比在群里问别人截图靠谱。同一张卡、同一个模型，别人能跑不代表你能跑，因为上下文长度、并发数和框架版本都会影响最终占用。
精度：什么任务能忍，什么任务不能忍
低比特量化最先伤到的是长链条推理和精确复现类任务：多步数学推导、结构化输出、代码里对符号和缩进的严格一致性，这类活一旦某一步出错就是整段重来，容错空间很小。相对钝感的是短问答、摘要转写、闲聊和分类打标，答案本来就允许有措辞波动，量化带来的抖动不容易被用户察觉。
| 任务类型 | 对量化的容忍度 | 原因 |
|---|---|---|
| 多步推理、数学推导 | 低 | 一步错导致整条链错，误差会累积 |
| 结构化输出、代码生成 | 低 | 符号、缩进、字段名必须严格一致 |
| 摘要、转写、改写 | 中 | 允许措辞波动，语义对即可 |
| 分类、打标、短问答 | 高 | 输出空间小，抖动不易外显 |
| 多轮长对话 | 中偏低 | 上下文越长，累积偏差越明显 |
判断方法不是猜，而是拿你真实任务的一小批输入，跑一遍满血版和量化版，人工比对差异。对比表至少覆盖「完全正确 / 可用但需微调 / 不可用」三档，只看一两个样本很容易得出错误结论。想了解不同位宽档位之间的差别，可以先翻「/guides/quantization-levels」那篇，再回来做自己的对照。
什么情况下不适用：如果你的任务输出要给下游程序消费，比如解析成 JSON 再入库，别只看人眼读着顺不顺，要看字段解析失败率。人觉得没问题的输出，程序可能直接解析炸掉，这两种失败方式要分开统计。
显存和速度：省下来的到底是什么
显存方面，量化直接压缩权重体积，让原本装不下的模型能塞进你的卡，或者让同一张卡能同时开更多并发。这是量化最实在的价值，也是它被广泛使用的主因。如果你的非量化版本本来就装不下，那量化不是「要不要」的问题，而是「能不能用」的问题。
速度方面要分两种卡看：在支持对应低位宽计算的硬件上，量化往往能提速；在不支持的硬件上，权重解压反而可能带来额外开销，甚至比原版更慢。所以「量化一定更快」是错的。真实结论取决于你的卡、推理框架版本和批量大小，必须实测，用「/tools/speed-test」先量出你自己的延迟基线，再对比两种版本，别信别人的截图。
- 装得下原版：优先考虑不量化，省去精度损失和兼容性排查
- 装不下但只差一点：优先试中等位宽，而不是直接跳到最低档
- 装得下但想要更高并发：量化换吞吐，但要接受精度抖动
- 硬件不支持该位宽：量化可能不提速，先测再决定
- 任务对精度极敏感：宁可降模型规模，也别硬上低比特量化
想知道按你的卡算出来的上限大概在哪，可以直接用「/tools/vram-calc」里的按参数量和量化方式的算法套一遍，把结果和实测对比，差得多说明还有别的开销没算进去。更细的按卡估算法，见「/guides/4090-model-size」那篇。
动手前照这个顺序过一遍
- 定显存红线先确认非量化版本能不能装下，装得下就别急着量化。算的时候把上下文长度和并发数一起带进去，别只按模型大小估。
- 定任务容错把你要跑的任务按「错了重来代价大 / 无所谓」分两堆，代价大的那堆优先保精度，代价小的那堆可以往低位宽走。
- 小样本回归两版各跑同一批输入，记录正确率、字段解析率和响应时间三项，别只记录一项。三项里有一项明显劣化就要重新权衡。
- 留回退把满血权重和当前启动参数单独存一份，量化版出问题时能切回去。别把原版删了，重下权重的时间和带宽成本不低。
- 上线后盯复现率同一问题多问几次，看答案是否稳定。量化版更容易在边界样本上抖动，这项在长对话和结构化输出里尤其重要。
这套顺序的核心是先排除、再取舍：显存够就先别量化，任务敏感就宁可换小模型。把这两条守住，剩下的都是调参问题，不是方向问题。具体到你的卡和模型能跑哪几档，到「/rankings」和价格追踪页核对当时的数字，别拿几个月前的结论当现在的事实。
常见问题
量化模型是不是一定比原版差？
不一定。在低比特压缩幅度较大时，长链条推理和严谨结构化任务的质量下降会比较明显；但压缩幅度较小时，短问答、摘要这类任务人眼几乎看不出区别。关键是你得用自己的任务样本实测，而不是听「量化必翻车」或者「量化无损」这两种极端说法。
为什么我换成量化版，显存没省多少？
因为权重只是显存占用的一部分。长上下文推理时，KV 缓存和激活值会占掉相当一块，这部分不受权重量化影响。如果你的场景是长文本、大并发，先把这两块的占用算清楚，再决定量化的收益值不值得。
量化版比原版还慢，是我装错了？
不一定是装错。低位宽计算需要硬件和推理框架同时支持，缺少对应支持时，框架要先把权重解压再做计算，反而增加开销。换框架版本、换批量大小、换卡都可能是变量，建议固定其他条件只改一个因素，用测速工具逐项对比。
