推理服务故障排查与SLO实践

2025-11-20 | 阅读：次

没有SLO就只能吵感觉

没有可算的数时，快慢只能靠感觉判断。在线聊天至少定这几条：可用性（非 5xx、非超时）、p95 TTFT、流式完整结束比例。不同模型档位阈值不同，7B 和 70B 别共用一个标准。

错误预算有了之后，变更节奏也好谈：预算紧就先别玩新量化；预算宽才敢把新版本流量放大。

先看症状，再下钻，不急着重启。

同一次请求用 request_id 把网关和引擎日志串起来，比盯着平均延迟猜高效得多。

OOM。 并发被悄悄调高、max_model_len 太大、新接了长文档业务。临时手段是降并发、拒超长请求；治本还是分池和限流。

TTFT 突然高。 按顺序看：队列 → GPU/显存 → 是不是流量打到了更慢的新版本 → 前缀缓存命中是否掉了 → 有没有在加载大模型文件。

流式中断。 查网关读超时、反代有没有把 SSE 缓冲起来、上游是不是中途挂了。也有客户端取消被当成故障，对数时看清是谁先断开。

Agent 工具失败。 先确认模型 function calling 稳不稳、工具 schema 有没有变、HTTP 超时是否过紧，以及 Dify 节点错误有没有被吞掉。

以前写过很长的文档，没人看。现在一页纸：

标题：p95 TTFT 超阈值
判定：连续 15 分钟超 SLO，常伴队列上涨
立刻：确认模型与集群 → 新版本流量切回稳定版 → 临时降 QPM → 通知值班
再查：半小时内变更单、慢请求 prompt 长度、GPU 是否降频
恢复：p95 回到线内并稳住一段时间，错误率不恶化

降级可以很土：大模型切小模型、关掉贵的工具调用、缩短 max_tokens、低优先租户先排队。土，但有效。

复盘固定写：影响面、发现方式、根因、为何没更早发现、临时措施、永久修复、谁跟进。能脚本化的就脚本化——按 request_id 拉链路、一键切 stable——这些最适合平时攒着，出事当救命绳。