模型量化在测试集上通过，并不代表上线后不会出问题。真实输入可能超出校准范围，某个算子在生产硬件上退回 CPU，运行时升级也可能改变低精度内核行为。
应急响应的目标不是在故障时临时研究量化原理，而是用最短时间限制影响、恢复已知可用版本，再保留足够证据定位原因。
## 先定义什么算量化事故
第一类是质量事故：关键类别召回下降、结构化输出漂移或异常分数集中。第二类是性能事故：尾延迟、内存、功耗或超时突然上升。
第三类是可用性事故，例如模型加载失败、设备不支持某算子、推理进程崩溃。第四类是静默事故：服务返回 200，却因为数值饱和或预处理不一致持续给出错误结果。
不同事故使用不同告警。只监控接口错误率，发现不了静默质量回退；只监控准确率，又看不到热降频和队列堆积。
## 上线前必须准备两条路
保留经过验证的浮点或上一量化版本，并确保它能在当前基础设施上快速加载。回滚资产不能只是仓库里的旧文件，还要包含运行时、驱动、预处理、阈值和配置。
量化版本与基线版本应使用相同请求协议和输出模式，路由层才能切换。若回滚需要临时改客户端，恢复时间会被放大。
为每个制品记录模型哈希、量化方法、校准集版本、算子排除清单、运行时和目标硬件。事故发生时，先确认实际运行的组合，而不是相信部署单上的名称。
## 告警要同时观察系统与模型
系统指标包括请求量、错误率、各分位延迟、队列长度、内存、设备利用率、功耗和温度。模型指标包括输入范围、输出分布、置信度、关键类别比例和人工复核结果。
量化模型容易出现输入分布超出校准区间。可以监控关键张量前的输入统计，或用业务代理指标发现漂移，例如某类缺陷突然接近零。
告警阈值要比较候选版本与控制版本。整个服务共同遭遇流量高峰时，量化版本延迟上升未必是本次发布造成；只有分组指标才能减少误判。
## 事故发生后的前十五分钟
第一步停止继续放量，冻结模型、运行时和配置变更。第二步判断是否正在影响用户或设备控制；若影响明确，优先把流量回切到已知良好版本。
第三步记录开始时间、受影响版本、硬件池、请求类型和首个异常指标。第四步保留少量脱敏失败样本、执行日志和设备状态，避免回滚后证据消失。
不要在生产故障中连续尝试多个量化参数。每次热修都改变现场，既延长影响，也让根因难以还原。
## 回滚还是向前修复
若旧版本仍可加载且容量足够，回滚通常最快。若接口或数据格式已经不兼容，可以暂时禁用量化执行路径，或把敏感算子恢复为浮点，形成最小向前修复。
容量是关键约束。浮点模型可能占用更多显存，直接把全部流量切回会触发新的资源故障。预案应提前计算回滚容量，并允许限流、降级非关键功能或分批回切。
Google SRE 的金丝雀发布方法强调候选组与控制组并行比较，并把影响限制在少量流量。对模型量化同样适用：先影子运行，再小比例承载，逐步扩大。
## 用浮点对照定位质量问题
将相同失败输入同时送入浮点与量化模型，比较最终输出和中间激活。若从某一层开始差异显著，就检查该层的缩放、零点、位宽和是否使用逐通道量化。
ONNX Runtime 的量化调试接口可以匹配浮点与量化模型的权重和激活，帮助找到差异最大的张量。图优化最好与量化步骤分开，避免计算图变化后难以对应。
若问题只出现在某类真实输入，重新检查校准集是否覆盖对应光线、长度、设备或异常范围。不要直接把事故样本全部塞回校准集，还要用独立回归集确认没有转移问题。
## 性能变差先看执行图
量化模型不一定更快。目标硬件若缺少低精度指令，或者部分算子在 CPU、GPU 与 NPU 之间来回切换，格式转换和内存复制会吞掉收益。
检查每个算子由哪个后端执行，记录量化和反量化节点数量，再对照线程、批次和动态形状。延迟只在高并发上异常时，还要查看队列与内存分配。
持续运行后才出现问题，可能与温度、功率限制或内存泄漏有关。短基准无法替代数小时的稳定性测试。
## 版本路由让恢复更可靠
推理服务应能同时加载两个模型版本并显式控制流量。KServe 的金丝雀部署思路就是让候选与基线并行，逐步转移并在异常时快速回退。
模型仓库还要保存依赖关系。NVIDIA Triton 等推理服务支持版本化模型仓库与显式加载机制，但运维团队仍需验证目标版本是否真的处于就绪状态。
回滚按钮必须定期演练。没有演练过的回滚，只是一份愿望清单。
## 复盘要回答五个问题
触发故障的输入或环境是什么？为什么测试没有覆盖？哪个指标最先变化？从告警到止损用了多久？为什么回滚成功或失败？
根因可能位于数据、量化参数、导出图、运行时、驱动、硬件或流量路由。复盘不要把“INT8 精度不足”当成终点，而要定位到可修正的环节。
修复后增加一个能复现事故的测试，并更新校准覆盖、发布门槛和自动回滚条件。若只是重新导出模型而不改变流程，同类事故很可能再次发生。
## 每季度做一次故障演练
演练可以人为制造关键类别召回下降、量化算子回退、模型加载失败和回滚容量不足。值班人员按预案执行，记录告警是否清楚、权限是否可用、证据是否完整。
演练的成功标准不是“最终修好了”，而是能在规定时间内停止放量、恢复服务，并保留足以定位原因的数据。
模型量化应急预案的本质，是把数值风险当作普通生产变更管理。版本可识别、指标可比较、流量可切换、回滚经过演练，团队才有资格享受低精度带来的效率收益。
## 参考资料