团队先完成蒸馏，再把学生模型做了量化。模型文件变小了，测试报告里的平均分变化不大，业务试用却发现长文本和少数类别的结果变差。量化前后的失败样本放在一起后，退步集中在几类输入。
下面用一段假设性的压缩过程说明排查方法。具体项目需要使用自己的数据和环境复测，不能把这些步骤当成普遍效果承诺。
先保留三份模型
复盘时保留蒸馏前的原始模型、完成蒸馏的学生和完成量化的学生。三份模型使用同一批冻结样本，输入、输出限制和评分规则保持一致。若只留下最后一份量化模型，团队无法知道退步发生在蒸馏还是量化。
样本按任务、长度和风险切片。结构化抽取单独看金额、日期和主体，问答检查依据与拒答，长文档观察截断位置。平均分没有明显变化时，切片结果仍可能告诉我们问题集中在哪里。
退步先找原始输出
每条失败样本保存量化前后的模型输出、解析结果和人工判断。模型原始回答已经错，检查校准数据、量化范围和算子；原始回答正确，解析后变错，检查类型转换和后处理。错误在服务层产生时，继续训练只会浪费时间。
校准数据要覆盖线上长度和边界输入，且与最终测试分开。只用短文本校准，长文档可能出现新的激活范围。测试数据参与量化配置选择后，应转为开发或回归材料，下一轮最终判断换独立样本。
速度没有跟着文件变小
量化模型加载成功，不等于所有算子都走量化路径。推理框架不支持某些算子时，可能回退到浮点。目标硬件的支持范围也会改变结果。复盘时记录加载日志、首 token、完整响应、吞吐、峰值内存和超时。
输入长度和并发分组测试。短文本的固定开销可能掩盖差异，长文本才暴露上下文计算和截断。服务端的网络、排队、后处理与重试也要分段计时，不能把端到端延迟全部归给模型。
一次只改一个变量
团队先固定量化格式和推理框架，只替换校准数据；随后固定数据，只比较量化配置；最后才检查硬件和服务参数。每次同时运行原回归集、失败挑战集和新的验证样本。结果没有改善时，也要保留实验编号和失败原因。
蒸馏、量化和部署工具都会改变结果，多个变量一起改，复盘就无法回答谁造成了退步。保留未量化学生作为回退，可以让低风险试用继续进行，不必为了追求更小文件立即扩大风险。
把使用范围写清楚
如果量化模型在固定短文本中稳定，可以先限制输入格式和长度。长文档、少数类别和高风险判断转给人工或未量化学生。入口校验、人工接管和回退路径写进发布记录，超出测试范围的请求不要强行交给量化模型。
后续新来源和新表达通过回归以后，再考虑扩大职责。一次压缩成功不能证明所有任务都适合量化，某个硬件上的速度也不能直接推到另一套环境。项目负责人要根据自己的任务门槛和资源条件做决定。
复盘最后留下什么
报告保存三份模型版本、数据与校准来源、评测脚本、失败样本、资源数据和回退演练。平均分可以放在摘要位置，关键错误和未覆盖输入也要同页展示。这样下一轮换数据、换框架或换硬件时，团队仍然知道哪些结论可以沿用。
模型变小以后效果退步，未必意味着量化完全不可用。它可能说明校准数据不合适，某些算子没有得到支持，或学生本身已经接近任务下限。把原因拆开，先在已验证的范围使用，再用新证据决定是否继续压缩。
复盘时还要把输入预处理列入对照。分词器、最大长度、截断位置和输出解析器只要有一项变化，结果就可能和模型压缩混在一起。三份模型应使用同一套服务模板，并保留请求编号，方便把原始输入、模型输出和最终结果逐条对应。没有这层记录，团队很容易把服务改动误判为量化退步。
资源结果也要按冷启动、稳定运行和高并发分开保存。文件体积变小可能只改善加载时间，生成速度却没有变化。若算子回退到浮点，显存下降与延迟变化也可能不同步。复盘不必追求一个漂亮的总数字，把差异发生在哪类请求写清楚更有用。
当量化模型只在部分范围内稳定，可以给入口增加限制。长文本先转人工，少数类别使用未量化学生，低风险短请求继续观察。每次扩大范围前增加新的回归样本，出现严重错误就立即回退。这样留下的记录，能帮助下一轮判断应该改校准数据、改服务，还是放弃当前配置。
资料依据
- Hugging Face Optimum量化指南
- NVIDIA TensorRT文档
