量化模型怎么选

本地部署最常卡在同一个地方：模型下载下来，显存装不下，于是到处找「4bit 版」，装完发现答非所问，或者速度慢到没法用。量化等级不是越低越好，也不是越高越保险，它是一道按你的卡和任务来算的取舍题。这篇给一套可执行的判断顺序：先量显存天花板，再按任务定精度底线，最后用小样本对比验证，顺便说清什么情况下量化根本不该背锅。

本地部署最常卡在同一个地方：模型下载下来，显存装不下，于是到处找「4bit 版」，装完发现答非所问，或者速度慢到没法用。量化等级不是越低越好，也不是越高越保险，它是一道按你的卡和任务来算的取舍题。

这篇给一套可执行的判断顺序：先量显存天花板，再按任务定精度底线，最后用小样本对比验证，顺便说清什么情况下量化根本不该背锅。整套流程走下来花不了多少时间，但能避免你反复下载几十 GB 权重又删掉的循环。

先算显存天花板，再谈量化档位

顺序不能反。先挑量化等级再去迁就显存，等于先买鞋再量脚。把可用显存扣掉系统占用、KV Cache 和框架开销，剩下的才是权重真正能用的预算。空载时的数字看着宽松，一旦跑长上下文，KV Cache 会吃掉一大块，按空载估算往往在真实任务里当场爆显存。

一个粗略换算：权重占用约等于参数量乘以每参数字节数。同参数量下，不同量化等级对应的字节数差别很大，从接近原始精度到压到很低都有。手算容易漏掉嵌入层和额外缓冲，建议用站内工具直接出结果，比拿计算器敲靠谱。

权重预算

总显存减去系统、KV Cache 和框架开销后真正留给模型参数的那部分

KV Cache

推理时缓存注意力键值占用的显存，随上下文长度和并发数增长

每参数字节数

量化等级的直接体现，越大越接近原始精度，占用也越高

1. 登记卡型先确认单卡或几张卡的实际可用显存，别用标称值，跑一下空载占用。
2. 输入模型规格到 /models/deploy 填卡型和模型规模，看它给出的分档测算结果。
3. 对照多卡结论到 /compute/sizing 看同规模下几张卡够用的结论，判断是否需要加卡而不是继续压量化。
4. 定边界策略如果显存刚好卡在边界，先问自己的任务是不是长文档。短问答缩上下文更划算，长文档才考虑降量化等级。

按任务定精度底线，而不是按喜好

不同任务对量化的敏感度不一样。开放式写作、闲聊这类没有唯一答案的场景，对低比特更宽容；结构化抽取、代码补全、数学推理步骤、JSON 输出对齐，低比特容易把误差放大成硬伤——格式崩了、字段少了、指令不跟了。

判断方法很朴素：拿同一批真实输入，在两个相邻量化档各跑一遍，只比对最终产物能不能用，不要比对措辞像不像。措辞差异是正常波动，产物不可用才是越线。

如果低档位出现格式崩坏、重复输出、指令不跟这类硬伤，说明已经越过底线，不是「调调提示词」能救的。这种时候要么升一档量化，要么换更适配的模型，别在同一条路上反复折腾。

拿不准概念的时候，先到 /ai-dict/category/tech 把量化相关术语对齐，避免把「模型本身不行」误判成「量化损失」。一个模型在原生精度下就答不好某类问题，量化只是让它更差，不是问题的源头。

• 先列出手上任务里最怕出错的那一两项，作为底线测试点
• 同一批输入跑两档，只看产物可用率，不比文字相似度
• 出现格式崩坏、字段缺失、指令不跟，直接判越线
• 拿不准概念先对齐术语，别把模型短板算到量化头上

选完之后的验证清单与回退方案

选定一个量化等级不等于这件事结束了。真正的省心来自一份固定的小测试集：覆盖你的真实任务类型，逐档记录可用率，而不是只跑一两条看感觉。测试集不用大，十几条能覆盖主要场景就够，关键是每次换档都用同一份。

不同量化等级对吞吐的影响也不一样，别只盯着显存。到 /tools/speed-test 先量出延迟基线，再决定要不要为了省显存牺牲速度。有时候升一档占多一点显存，但速度快一截，整体反而更划算。

1. 固定测试集整理十几条真实输入，覆盖主要任务类型，每次换档都用同一份。
2. 逐档记录每档跑完记下可用率，不求精确到小数，能分辨好坏即可。
3. 量延迟基线到 /tools/speed-test 测不同档位的响应延迟，把速度也纳入决策。
4. 留回退路保留原始高精度权重和上一档的产物对照，线上发现质量下滑能快速退回上一档。
5. 记录选型把卡型、上下文长度、并发数和最终量化等级记一笔，下次换卡换模型直接沿用这套框架。

还有一种常见误判：把所有问题都归到量化头上。模型本身能力不够、提示词写法有问题、上下文给得太少，都会表现为「答得差」。验证时先拿高精度档做一次对照，如果高精度也不行，那量化就不是主因。