一、项目背景

客户在一个私有化客服问答场景用了一版微调过的七B模型，推理成本偏高，我们建议做 INT8 量化压缩显存和时延。但他们团队图快，直接拿训练好的模型上了后训练量化，跑完精度评测掉了两个点，线上客服开始答非所问，业务方当场叫停，量化方案被打回。这件事给我们提了个醒：量化不是部署前一步转换那么简单，尤其客服这种对准确度敏感的场景，掉点就会被用户感知到。

我们后来重做，把量化前移到训练阶段，也就是量化感知训练，再配合推理侧校准，才把精度拉回来。

二、落地场景

整体分成训练和推理两条线。训练侧，我们在微调流程里插入伪量化节点，让模型在训练时就习惯低精度表示，前向用量化值、反向用全精度梯度，避免部署时精度塌方。推理侧，对敏感层保留全精度或混合精度，并做动态量化的激活校准，用一小批代表数据统计缩放因子。最后用业务侧的问答准确率做回归门禁，不达标不许上线。

我们把这套流程做成可复用脚本，接进他们既有的微调工具链，后续每次迭代模型都自动跑一遍量化校验。

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

量化感知训练稳定性是第一道关。伪量化节点加进去后，学习率要调小，否则早期梯度噪声把模型带偏。我们的经验是先用全精度训到收敛附近，再开量化感知训练微调几轮，而不是直接从零来。

敏感层识别靠逐层评估，不是拍脑袋。我们把每一层量化后单独测业务指标，掉点明显的层（通常是注意力输出和最后分类头）保留全精度，其余层量化，这就是混合精度。

量化后回归评测必须贴近真实分布。我们用线上真实业务样本做测试集，而不是公开 benchmark，因为业务术语和句式差异很大，公开集过了不代表线上稳。

推理框架兼容是个现实问题。他们用的推理引擎对自定义量化算子的支持不完全，部分层我们退回到框架原生量化路径，牺牲一点压缩比换稳定性。

四、效果数据

文中数据为项目复盘口径，已脱敏。量化感知训练方案上线后，精度损失控制在约 0.3 个百分点以内，业务方肉眼基本无感，比之前后训练量化掉两个点好太多。推理时延下降约 38%，显存占用下降约 42%，单卡能多承载近一倍的并发。吞吐提升约 1.8 倍，同样的硬件多撑了将近一倍的坐席。

案例片段（已脱敏）：敏感层识别时，我们把注意力输出层单独量化测了一次，准确率掉了 1.1 个点，果断改回全精度：[layer] qkv_proj=int8, attn_out=fp16(keep), cls_head=fp16(keep)acc_drop: qkv_only=0.2%, attn_out_quantized=1.1% -> revert attn_out to fp16

五、可复用经验总结

量化这件事，教训很直接：别在训练完才想起来做，精度塌了再救成本更高。我们那次后训练量化翻车，根子就是训练阶段完全没考虑低精度，等于让模型裸考。

我现在会建议所有要量化的团队，先把哪几层敏感摸清楚，混合精度比一刀切全量化稳得多。还有，回归评测一定用自己业务的真实样本，公开 benchmark 的分数好看没用，线上用户不认。

附：规模化落地与工程细节

这套量化流程我们踩过的最大的坑，是推理框架对自定义量化算子支持不全，部分层被迫退回原生路径，压缩比没达到预期。后来我们改了策略，只在框架原生支持好的层做量化，敏感层一律保精度，虽然省下的显存少一点，但稳定性好太多，业务方才愿意常态化用。

训练侧还有个细节，伪量化节点加进去后，如果学习率不降，前几轮 loss 会抖，我们一度以为是代码错了，浪费两天排查。所以量化感知训练的配方里，学习率调度和伪量化开启时机要一起调。回归评测我们坚持用线上真实业务样本，曾经有次公开 benchmark 全过、线上掉点，根因是业务术语分布偏移，从此再不敢省这一步。

给后来者的话，量化别追求极限压缩比，稳和准比省那点显存重要。客服这类对准确度敏感的场景，掉零点几个点用户就能感知，别为了成本牺牲体验。

上线后我们给业务方做了个对比开关，同一个问题分别走量化模型和原模型，让他们自己看差在哪。这招比任何汇报都管用，疑虑一下就消了。这也说明，精度补偿这种事，信任比指标更难建立，能让人亲眼对比，推广就顺了。我们把这个对比能力做成了日常巡检的一部分，每周抽一批真实问答做双模型评测，一旦差距变大立刻告警，量化模型才敢长期常态化跑，而不是上线一次就再没人敢动。

另一个容易被忽略的点是，量化之后推理框架的版本也要锁。我们出过一次问题，框架小版本升级改了量化算子实现，同样的模型精度悄悄掉了零点几个点，幸好有回归门禁拦住。所以量化模型的上线清单里，框架版本和校准参数是必查项，不是可选项。给做私有化交付的团队提醒，交付物要连环境一起锁，客户自己升级推理引擎很可能把你的精度优化弄没，这种锅我们背过一次就不想背第二次。