摘要： 当模型量化导致准确率下降15个百分点时，上线还是不上线？本文基于真实踩坑经历，提出了一个分场景决策框架：核心功能谨慎量化、辅助功能可适度量化，但关键在于厘清"用户对不同功能的质量容忍度差异"。文末附可直接复用的量化上线决策清单，助你避开我踩过的坑。
那天我盯着测试报告坐了很久
量化测试完成了。数据很明确：大模型从fp16切换到INT8后，模型体积从14GB压缩到7GB，推理速度也有小幅提升。然而，准确率的测试通过率从90%下降到了75%左右，降幅接近15个百分点。
我盯着这份报告，思考了很久：这个性能损失，到底能不能接受？
说实话，这个问题没有标准答案。如果模型部署在服务器端，我或许可以说"损失在可接受范围内，先上线观察"。但端侧部署完全不同------用户的手机上没有兜底服务，量化后的错误会直接暴露在用户面前，无法事后补救。
一个思路：让用户投票
我的第一反应是：让用户自己来选择。
具体做法是设计一个A/B测试------将用户随机分为两组：一组使用fp16版本，另一组使用INT8量化版本，然后收集两边的使用数据：任务完成率、用户反馈评分、主动报错率等关键指标。
测试运行了两周，结果很有意思：
- fp16组：准确率更高，用户反馈"回答质量不错"的比例接近90%
- INT8组：准确率明显下降，但用户反馈并没有显著变差------"还行""差不多"的评价比例与fp16组基本持平
当时我几乎认为这个结果证明了"量化对用户体验影响不大"，差点就直接决定全量上线了。
后来一位资深同事看了我的数据，点出了一个关键问题：用户不会主动比较两个版本的质量差异，他们只会基于自己的预期来打分。 如果量化后的输出刚好落在他们的可接受范围内，评分就不会差。但如果某个用户遇到了一次明显的错误，他的评价可能会从"还行"直接跌到"太差了"。
也就是说，A/B测试只能反映平均表现，无法捕捉"最差的那一次"体验。
另一个思路：按场景分层
第二个方向是分层量化------不是所有功能都采用相同的量化等级。
我的思路是：将产品功能按照重要性分为两类。
一类是核心功能：用户使用产品的核心目的所在，一旦出错就是硬伤。比如TLDR Scholar中的论文摘要功能，用户期望它能准确概括论文核心内容，摘要错误等于功能失效。
另一类是辅助功能：用户对质量有一定容忍度。比如"猜你喜欢"、"相似论文推荐"这类功能，推荐不够精准时用户可能只是觉得"还行吧"，不会直接影响主要使用体验。
基于这个分类，我制定了以下分层量化方案：
| 功能类别 | 量化策略 | 预期准确率损失 | 验收标准 |
|---|---|---|---|
| 论文摘要（核心） | 不量化，保持fp16 | 无 | 与原版对比无感知差异 |
| 论文问答（核心） | INT8 + 质量门控 | ≤5% | 通过质量门控校验才返回结果 |
| 相似论文推荐（辅助） | INT8直接上线 | ≤15% | 推荐相关即可，不要求精确 |
| 关键词提取（辅助） | INT4量化 | ≤25% | 关键词基本命中即可 |
这个方案表面上看很合理------核心功能保持高精度，辅助功能大胆量化。然而上线后却意外翻车了。
翻车：辅助功能量化后出问题了
推荐功能量化上线后不久，有用户反馈"推荐结果太离谱了"。经过排查，确实如此------系统推荐了与用户当前阅读论文完全不相关的论文。
按理说推荐功能属于"辅助功能"，我设置了较大的准确率损失容忍度。但这次的问题不在于准确率下降，而在于错误模式的改变。
量化后的推荐模型出现了一种新的错误模式：它会推荐一些"词汇表面相关但语义无关"的论文。例如，用户正在阅读"神经网络的注意力机制"这篇论文，量化后的推荐模型却给出了"神经网络在图像处理中的应用"------表面上都包含"神经网络"这个关键词，但核心主题和关注点完全不同。
这种错误比"推荐不够精准"更严重，因为它会误导用户的阅读方向和研究思路。
进一步分析推荐日志发现，这类"表面相关"错误占到了推荐失败案例的近50%。这说明INT8量化不仅降低了推荐的准确率，更重要的是改变了模型判断"语义相关性"的内在机制。
根因：我对"用户容忍度"的判断错了
为了更直观地理解量化对错误模式的影响，我对比了量化前后两个典型功能的表现：
| 功能 | 量化前（fp16）的错误模式 | 量化后（INT8/INT4）的错误模式 | 核心差异 |
|---|---|---|---|
| 论文摘要 | 偶尔遗漏次要细节，但核心事实准确 | 出现事实性错误，如混淆作者、方法或结论 | 从"细节不准确"变为"事实错误" |
| 相似论文推荐 | 推荐相关性略低，但主题方向基本一致 | 推荐"词汇表面相关但语义无关"的论文 | 从"相关性低"变为"表面相关" |
这个对比揭示了一个关键问题：量化带来的不仅仅是准确率的线性下降，而是错误类型的质变。对于论文摘要，量化前用户最多觉得"概括不够全"，量化后却可能读到完全错误的信息；对于推荐功能，量化前用户觉得"推荐不太准"，量化后则可能被误导到不相关的研究方向。这两种质变，都远远超出了我最初对"准确率损失"的预期。
回头看这个坑，根因不在技术层面，而在一个认知层面。
我之前假设"用户对辅助功能的容忍度高"，但这个假设的前提是：用户知道自己用的是"辅助功能"。
实际情况是：用户打开产品的时候，不知道哪些是核心功能、哪些是辅助功能。他们只知道自己"用了一下"，然后觉得"结果不太对"。推荐功能虽然被我标为"辅助"，但在用户的感知里，它就是产品的一部分。
还有一个更深的原因：不同用户对质量的预期不一样。有些人对"推荐结果"的容忍度很高，觉得"差不多就行"；有些人对推荐结果很敏感，觉得"推不准就是不准"。我没有在产品设计上区分这两类用户，直接把所有人的推荐都量化了。
重新想清楚的决策框架
这次翻车之后，我把量化上线的决策流程重新整理了一遍。核心改动是一个点：
不要按功能类别分层，要按用户感知的"质量敏感度"分层。
具体做法是：
| 步骤 | 判断点 | 通过条件 |
|---|---|---|
| 第一步 | 用户能否意识到"这个功能质量下降了"？ | 不容易被感知，或有明确提示 |
| 第二步 | 错误是"回答不够好"还是"回答错方向"？ | 前者容忍度高，后者不能接受 |
| 第三步 | 有没有兜底手段在用户感知到错误之前拦下来？ | 有兜底且延迟可接受 |
基于这个思路，我重新调整了分层方案：
| 功能 | 质量敏感度 | 量化策略 | 判断依据 |
|---|---|---|---|
| 论文摘要 | 高------用户会逐字看 | 不量化 | 错误会被用户直接发现 |
| 论文问答 | 中高------用户会追问验证 | INT8 + 质量门 | 质量门可以在返回前拦截明显错误 |
| 相似论文推荐 | 中------用户只看标题 | INT8（谨慎） | 需要监控"表面相关"类错误的比例 |
| 关键词提取 | 低------用户只看几个词 | INT4 | 即使全错，用户也能从标题里获取信息 |
调整之后的一个关键变化是：推荐功能从"辅助功能随便量化"改成了"可以量化但需要监控"，并加了一个专门的监控指标------"表面相关错误率"，上线后每周看一次，超过阈值就回退。
决策流程图
为了更直观地理解量化上线的决策逻辑，我将上述 6 个检查项整理成一个流程图。你可以顺着这个流程，对每个待量化的功能逐一判断：
这个流程图把清单中的 6 个检查项串联成了一个完整的决策链路。每个节点都对应一个明确的判断条件，只有全部通过才能进入量化上线环节。实际使用时，你可以把它贴在团队的技术方案评审文档里，作为量化上线的标准检查流程。
量化上线决策清单
我把这一套经验整理成了一个决策清单，方便后续评估要不要对某个功能做量化：
| 检查项 | 问题 | 通过条件 |
|---|---|---|
| 功能定位 | 这个功能出问题会不会直接影响用户的核心体验？ | 不直接影响核心体验 |
| 错误类型 | 量化后的错误是"回答不够好"还是"回答错方向"？ | 前者可以接受，后者需要兜底 |
| 用户感知 | 用户能不能意识到这个功能的质量变化？ | 不容易被感知，或有明确提示 |
| 兜底方案 | 如果量化模型出错，有没有办法自动降级到更高精度版本？ | 有兜底且延迟可接受 |
| 监控指标 | 有没有办法实时或定期监控量化后的质量变化？ | 有监控且有明确的回退阈值 |
| 测试覆盖 | 测试集是否覆盖了该功能的所有典型任务类型？ | 覆盖且通过率满足验收标准 |
这个清单我后来用了两次，都避免了类似的翻车。尤其是"错误类型"那一栏------很多决策卡在"准确率掉了多少"，但其实"掉在哪种类型上"更重要。
回头看
量化本身没有问题，问题是我一开始用了一套太简单的判断逻辑------"核心功能不量化、辅助功能随便量化"。这个逻辑忽略了用户对质量的感知方式，也忽略了量化会改变模型错误模式而不仅仅是降低准确率。 快、准、小------量化能让你同时拿到两个。但第三个，你要知道它丢在了哪里、用户会不会在意。
参考链接：
- LLM 量化评测基准（HELM）：crfm.stanford.edu/helm/