一、项目背景

我们自研的私有化底座里跑着一个客服问答模型，原始是 16 位浮点，显存和吞吐都吃紧。团队想省成本，把它量化到 8 位上线，压测里吞吐确实翻倍，大家很开心就推了全量。结果两周后业务方反馈，某些优惠类问题答错率明显涨了，我们才慌忙回滚。那次教训很贵，量化带来的精度损失不是均匀分布的，有些长尾场景掉得很隐蔽，光看平均指标发现不了。从那以后我们定了个规矩，量化版本上线前必须先过精度门禁，不准拍脑袋放行。

二、落地场景

现在每次出量化版本，流水线会自动拉一套固定评测集跑两遍，一遍全精度、一遍量化后，把关键指标逐项比对。比对结果进一个回归卡点系统，里面沉淀了我们历次踩坑攒下来的 badcase，比如某些带否定词的问法、某些含糊的退换货场景。卡点会看量化版本在这些 badcase 上是不是比全精度掉太多，掉超阈值就直接卡住，不许进发布环节。量化版本和全精度版本在灰度期并行跑，按比例分流，我们能实时看两边答得是不是一致。

三、关键技术挑战与解决思路

首先要解决的是精度指标怎么量化才不骗人。平均准确率太粗，我们改成分维度看，意图识别、实体抽取、答案一致性各看各的，长尾类目单独拉出来盯。接着要解决的是回归集覆盖度，badcase 不是一次攒够的，我们把它做成会随着线上错误回流不断长的活集子，新踩的坑自动进集。还有一块难啃的是门禁误杀，太严了正常版本也过不去，我们在阈值上留了缓冲带，掉了但没超线的给黄灯预警，超线的才红灯硬卡，运维能看见黄灯决定要不要人工放行。

案例片段（已脱敏）： 回归卡点配置片段（指标示意）：gate:  baseline: fp16  candidate: int8  metrics:    intent_acc: drop <= 0.5%    answer_consistency: drop <= 1.0%    longtail_acc: drop <= 2.0%   # 长尾类目容忍更低  badcase_set: regression_v3   # 随线上错误回流增长  action: drop>threshold -> BLOCK一次拦截：某 int8 版本 longtail_acc 掉了 3.1%，红灯卡住，复查发现是某批带方言的退换货样本量化后语义偏移，回退该批量化配置后通过。

四、效果数据

量化版本发布回滚次数从上线的两三次降到几乎为零，因为门禁把明显掉点的版本挡在了发布前。回归 badcase 拦截数累计抓到二十多起，覆盖意图、一致性、长尾几类典型掉点。量化带来的吞吐提升稳定在约一倍，显存占用降了四成多，成本账算得过来。灰度期并行对照让我们有信心逐步放量，不再靠上线后业务方投诉来发现问题。要坦白，最早那版门禁我们只看平均准确率，放了几个长尾掉点的版本过去，后来才补了分维度。

五、可复用经验总结

量化这事我现在的体会是，省成本是真省，但精度风险也是真风险，两者不能拆开看。门禁和回归集这套，在我们做其他模型的压缩时也都照搬了，核心是别信平均指标，长尾掉点才是量化最阴的地方。badcase 集一定要做成活的，靠一次人工攒的集子撑不了多久。阈值留缓冲带这个细节，是我被误杀两次之后加的，卡太死团队会偷偷绕门禁，那比没有门禁还糟。

结语

量化发布这套现在是我们模型上线的标准动作，回过头看，当初那次回滚代价太大，根子是没人拦住掉点的版本。门禁最难的不是写，是定指标，平均准确率会骗人，必须分维度看，长尾类目要单独盯，因为量化损失往往藏在长尾里。回归 badcase 集我们做成活的，随线上错误回流增长，这才让它一直有用，靠一次人工攒的集子撑不了多久。阈值留缓冲带这个细节，是我被误杀两次之后加的，卡太死团队会偷偷绕门禁，那比没有门禁还糟。我们早期那版门禁只看平均准确率，放了几个长尾掉点的版本过去，后来才补了分维度，这一步补上后线上再没被业务方投诉过精度。我现在的体会是，量化省成本是真，但精度风险也是真，两者不能拆开看，门禁就是把这层关系钉进流程里。另外我们后来把全精度和量化版本在灰度期并行分流对照，不再靠业务方投诉发现差异，这一步让我们有底气逐步放量。badcase 集现在每次线上错误都自动回流，规模从几十增长到几百，覆盖的面越来越全。灰度比例我们从百分之五起步，观察两天没异常再翻到二十，这样即使门禁漏了也有最后一道闸。量化不是终点，是把成本腾出来去做更多模型，这条账我们算清楚了，也踩过回滚的坑才信。门禁的缓冲带我们设成黄灯预警，运维看得到，偶尔手动放行，比红灯硬卡灵活。全精度和量化并行那段，我们专门做了对比看板，两边答得不一就人工介入，这层人盯让我们敢放量。量化发布现在是我们新模型上线必过的首关，没有它我们不敢轻易动量化，每次上线前先把门禁跑一遍，心里才踏实。