本地拉了个模型，目录里一堆名字相近的量化文件，不知道该下哪个；下完发现显存不够或者中文答得发飘，又得重来一遍。这篇按 llama.cpp 实际会碰到的格式讲清各自取舍，给一套从「先量显存」到「小样本验收」的操作顺序，以及什么情况下干脆别用量化。
本地拉了个模型，目录里一堆名字相近的量化文件，不知道该下哪个；下完发现显存不够或者中文答得发飘，又得重来一遍。这篇按 llama.cpp 实际会碰到的格式讲清各自取舍，给一套从「先量显存」到「小样本验收」的操作顺序，以及什么情况下干脆别用量化。不追求把每种缩写都背下来，重点是让你下次打开文件列表时，能在几分钟内做出不后悔的选择。
先说个前提：量化不是免费的午餐，它换的是体积和速度，付出的是精度。所以选型不是「越小越好」，而是「够用就行」。下面的顺序是先算预算、再定档位、最后比方法，别反过来先挑文件名里看着顺眼的。有任何数字类的问题，比如现在各家卡什么价、什么配置能跑多大，都去站内对应页面看当时的数字，这篇不写死。
先认清 llama.cpp 吃哪几种量化文件
llama.cpp 走的是 GGUF 这一支容器格式，一个文件里打包权重、词表和元信息。其它常见的量化容器不是不能转，但要多一道转换工序，别指望直接把别的格式喂进去就能跑。文件名里那串字母数字是量化方法加档位的缩写，同一个方法会分若干个粗细不同的档，看懂命名规律比背清单有用，因为方法一直在加。
- GGUF
- llama.cpp 直接加载的容器格式，权重、词表、元信息都在一个文件里
- K 类混合量化
- 对部分敏感层保留更高精度，同参数下体积略大但质量更稳
- 纯低比特量化
- 体积最小，适合塞进紧张显存，但精度损失也更明显
- 只压激活的路线
- 权重基本保持原样，占用降不了多少，可视为轻量化而非小体积方案
- 先确认手上的文件是不是 GGUF，别的格式要先转，转完再谈选档
- 看文件名里的方法前缀，判断属于混合量化还是纯低比特
- 看档位后缀，同一个方法下档位越细体积越大
- 留意有没有附带参数说明或校验值，对不上的别用
- 同一模型多个来源的包，优先官方或原作者发布的那个
选档顺序：先量预算，再定档位，最后才看方法
第一步不是挑文件，是算账。把可用显存和内存算清楚，同时留出上下文缓存的空间，别把显存全给权重。能跑多大模型的粗算思路可以对照 部署测算（/models/deploy）。很多人的翻车点就在这一步：权重刚好塞进去，上下文一拉长就爆。
- 量预算列出显卡显存、系统内存，再减去上下文缓存和运行时开销，得到一个真实可用额度
- 定档位按「放得下且留有余量」挑档，够宽裕取精度较高的一档，卡在临界就降一档，宁可小一号也别贴上限
- 比方法同样体积下优先挑社区验证多、口碑稳的那类，新方法先拿小模型试，别一上来全量替换
- 看任务写代码、结构化输出、长链路 agent 对精度损失更敏感；闲聊、摘要、打标签这类任务宽容得多
| 任务类型 | 精度敏感度 | 选档倾向 |
|---|---|---|
| 代码生成、结构化输出 | 高 | 尽量往高精度靠，必要时降模型尺寸而不是降档 |
| 长文档问答、摘要 | 中 | 中等档位可用，重点验收长上下文表现 |
| 闲聊、分类打标签 | 低 | 低比特档位基本够用，优先换吞吐 |
| 需要对齐评测的任务 | 很高 | 不建议用重量化版下结论，换原版或看现成口径 |
下载后别急着接业务，先做三件事验收
量化包的坑大多在长尾场景里暴露，短问答看着都正常。所以验收要有针对性：拿你自己任务里的真实输入去跑，而不是拿通用示例。下面这几步加起来花不了多少时间，但能省掉后面接进业务再回滚的麻烦。
- 挑一组真实问题，原版和量化版各跑一遍，对比关键字段有没有漏、格式有没有崩，别只看一句话顺不顺
- 把接近上限的长文档喂进去，观察是否出现重复、跑题或提前截断，这通常比短问答更早暴露损失
- 记录同一硬件下的吞吐和首字延迟，低比特常能换来更高速度，但收益不是线性的
- 确认文件来源和校验值，第三方转的重量化包要多留心，参数说明对不上的直接弃用
- 把验收结果记下来，下次换档位时有基线可比
想记录速度基线，可以借 接口测速（/tools/speed-test） 的方式先测一轮，把当时的数字存下来。这里要提醒一句：不同机器、不同上下文长度下测速结果没法直接比，自己前后对比才有意义。
这些情况不建议用量化顶上去
量化是有适用边界的。有些场景里，省下来的那点资源远不如一次错误结论的代价大。下面这几类情况，建议先想别的办法，而不是一路往最低档降。
- 要做效果对齐、评测打分的基准任务，量化版和原版存在系统性偏差，结论不好迁移，这类活去 AI 模型评测（/benchmarks） 看现成口径更省事
- 显存差得太多时，靠降到最低档硬塞，通常换来答非所问和频繁重跑，反而更费时间，先考虑换更小的模型或者走 算力从哪买（/compute/platforms） 的租卡路线
- 需要微调后再量化的链路要分开验证：先确认原精度下的训练效果，再逐档量化比对，别把训练问题和量化问题混在一起排查
- 对输出格式极其敏感的生产接口，量化后务必加一层校验与重试兜底，不要默认一次就出对的
最后补一句判断标准：如果你的验收里，量化版在真实输入上的失败率还在可接受范围内，且长上下文没有明显退化，那就可以用；一旦需要靠反复重试来兜底，说明档位压过头了，往回退一档往往比继续优化提示词更划算。
下一步把候选量化包和你的真实任务输入列成一张对照表，按上面的验收步骤跑一轮；需要看现成的模型清单和部署参考，直接从站内模型页开始。→常见问题
量化档位越低，跑得就越快吗？
不一定。体积和显存占用通常随档位下降，但速度还受内存带宽、CPU 卸载比例和上下文长度影响。低比特有时因为反量化开销在部分硬件上并不更快，建议用自己的机器和真实输入量一遍，别只看别人说的结论。
同一个模型，为什么不同人给的量化文件大小差很多？
量化方法、档位和是否保留部分层高精度都会影响体积，词表大小和上下文支持范围也会带来差异。同名文件不一定等价，下载前看清方法缩写和档位说明，必要时对照官方仓库的文件清单确认。
量化以后中文效果变差，是量化的问题还是模型的问题？
两者都可能。先用原版跑同一批问题做对照，如果原版也差，就是模型本身不适合这个任务；如果只有量化版崩，优先换高一档或换方法重测。中文、代码和长输出任务对精度损失更敏感，选档时要把这类任务单独拎出来验。
