推理服务的运营止损边界
推理服务返回健康状态，不代表它能继续为用户完成请求。进程、端口和基本接口可能仍然可用，但排队过长、KV cache 压力、模型 worker 卡住或下游工具超时，都会让用户在等待后失败。运营止损要关注真实请求路径的表现，并把“发现异常”“减少影响”“恢复服务”分成可审查的步骤，而不是让一次探针失败直接触发不可逆动作。
区分存活、就绪与服务质量
存活检查回答进程是否还在；就绪检查回答它能否接收新流量；服务质量则需要结合排队时间、首 token 时间、完整响应时间、错误类型和资源余量判断。不同模型、上下文长度和并发策略下的正常范围并不相同，阈值应来自受控压测和运行记录，而不是照抄某个固定数字。探针请求也应小、低频且有资源预算，不能因为巡检本身占满并发槽位。
观测数据至少按节点、模型版本、请求类型和时间窗口区分。只看 GPU 利用率或显存占用容易误判：高利用率可能是正常繁忙，低利用率也可能是上游没有流量。将这些信号与队列积压、超时和错误比例关联，才能判断是节点问题、入口限流、依赖异常还是流量结构变化。
异常信号 → 复核影响范围 → 停止分配新流量 → 观察存量请求 → 恢复或人工处置这个流程需要明确状态和责任。例如节点进入观察状态后，只减少新请求，不立刻杀掉正在生成的任务；若问题持续，再进入摘流状态。状态变更应写入审计记录，包含触发信号、当前版本和操作者或自动规则。恢复前也要通过连续检查和冷却窗口确认，避免在短暂波动中反复进出流量池。
自动动作必须有边界
自动化适合做低风险、可回退的事情：暂停向单节点分发新请求、创建告警、保留脱敏诊断材料，或降低非关键任务并发。重启 worker、清理缓存、扩大资源或修改路由权重会影响更大范围，应有权限、频率限制和回退方式。若多个节点同时异常，自动系统不应逐个把它们全部摘除，至少保留集群容量保护和人工确认路径。
失败计数也要谨慎设计。连续失败可触发进一步检查，但一次网络抖动、探针自身故障或发布窗口都不应被直接解释成节点失效。将探针失败、真实请求错误和资源告警分开记录，并在规则中说明它们如何组合。对于有状态或流式请求，摘流后要等待合理的完成时间，超时中断时应向用户返回可理解的状态，而不是静默断开。
排查与恢复要能复现
出现堆积时，固定模型版本、上下文长度、并发设置和流量样本，分别记录排队、首 token 和完整响应耗时。没有可比对的条件，就不能把某次调整描述成吞吐提升。可从队列、调度器、显存分配、工具调用和网络依赖逐层缩小范围，避免一发现延迟就盲目调大并发或重启所有实例。
诊断材料需要最小化和脱敏。不要把完整 prompt、用户标识或访问令牌写入常规日志；profile 与 trace 应存到受控位置并设置保留期限。修复后补充相应的压测、故障演练或回归检查，验证状态转换、摘流、恢复和用户提示是否符合预期。
止损不是为了让系统看起来“全自动”。它的价值在于限制故障扩散，同时保留足够证据让人作出正确判断。把自动化限定在可恢复的范围内，才能在推理服务的负载波动中既减少用户影响，也避免巡检系统制造新的事故。
