服务没报错但突然变慢？我查到了一个没人动过的配置
某天，团队里用得好好的一个推理服务"突然变慢"了。
长提示词的首字延迟明显恶化，体验断崖式下滑。
监控大盘全绿。没有报错，没有告警。
服务"一切正常"，就是慢。
这篇是完整的排查复盘，以及它逼出来的一套防漂移巡检方法。
排查链：从最俗的可能性开始
性能排查最忌讳上来就怀疑玄学。我的顺序固定：
网络层——链路延迟有没有变？排除。
负载层——并发是不是涨了？排除，请求量持平。
资源层——GPU 利用率、显存、队列深度。发现线索：利用率没有异常升高，但每 token 延迟变高了——单位工作量的效率降低了。
配置层——服务配置和"上周正常时"比，有没有不一样？
这一层，抓到人了。
真凶：调优被静默回滚
之前我做过一项调优：把 vLLM 的 max-num-batched-tokens 从默认的 256 提到 4096。
实测收益：23K token 的提示词，首字延迟从 71.1 秒降到 43.1 秒，1.65 倍。
排查发现，这份调优在某次变更后被回滚了——参数回到 256，延迟自然回到 71 秒的水平。
更值得玩味的是第二个发现：回滚的来源是一次非人工的静默操作——托管平台的例行机制覆盖了手工配置。
没有任何通知，没有变更记录，服务照常重启。
大家在没有优化的状态下跑了好几天，没人知道。
沉淀三制度
配置每日快照 + 巡检 diff。所有关键服务的配置每天自动快照，巡检时比对相邻快照——任何无主变更直接暴露。每天几分钟机器时间，换"配置永远可知"。
性能基线 + 漂移告警。为一组标准请求录制性能基线，定期回放对比延迟分布。基线漂移超阈值就告警——哪怕所有监控都绿。要看分布不要只看均值：P50 正常而 P95 翻倍，就是这类问题的典型指纹。
变更日志强制化。任何参数调整必须留痕（谁、何时、为什么）。变更不可怕，无感知的变更才可怕。
PM 视角：这是需求评审的老朋友
把这次排查抽象一层，它是产品里经典问题的工程版："没人动过它，但它变了。"
转化率突然掉了，没人改过页面——真的吗？实验配置、投放参数、SDK 版本，都是"没人动过"的黑箱。
产品侧的解法和技术侧同构：配置快照（实验配置留痕）+ 性能基线（核心漏斗基准）+ 变更强制留痕（发布与实验日志）。
系统的当前状态必须永远可审计，否则你所有的判断都建立在"以为"之上。
那次修复本身只花了十分钟——把参数改回去。
真正值钱的从来不是那十分钟，是之后再也不用花的那无数个十分钟。
发现问题的方法论续篇（调优如何被守住）见 配置治理；归因框架见 慢的三层真相。