推理服务的运营止损边界

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