推理服务的健康检查是怎么做的？

调用 AI 大模型服务时，平台状态页上一排排绿色圆点，来自推理服务的健康检查机制，它每时每刻都在替你探测服务是否正常。实例故障时，往往你还没发现问题，它已经先动手处理了。

可以把它想成值班人员定时巡房：看仪表读数、问一句运转如何，异常立刻报告。这个类比的失效之处在于，巡房有间隔，健康检查是高频自动轮询，几秒一轮，而且探测对象是机器状态而不是主观感受。带走一个判断：健康检查回答的是「活着吗」，不是「干得好吗」。

健康检查的两种探测方式

一种是轻量探测：只问服务进程在不在，响应快、开销小，用来判断实例死活。

一种是就绪探测：确认实例不仅能响应，还能真正接活——依赖的组件连通、缓存可用、模型加载完成。两种探测各有阈值，连续几次失败才判定异常，避免单次网络抖动引发误判。

探测通过不代表能正常回答

健康检查回答的是「实例活着吗」，不是「回答质量好吗」。探测通过但生成缓慢、输出异常的情况仍然存在，这类问题要靠请求侧的监控和策略兜底，速度维度的异常可对照首字时间和吞吐有什么区别？选型不再纠结观察。养成先看状态页再动手的习惯，能过滤掉一大半误判。流式场景下连接中断的体感也不同，见流式和非流式有什么区别？分界点在哪。

摘除和恢复：实例的进出

探测失败的实例会被摘出服务池，新请求不再派给它；恢复探测连续通过后，实例又被放回来承接流量。摘除和恢复都讲究渐进：摘除要等在途请求处理完，恢复要先小比例放量再逐步加满，避免一上来就被压垮。探测参数本身也有讲究：间隔太密，探测流量会占用实例资源；太稀，故障发现就慢，用户先于系统感知异常。失败阈值同样要平衡，一次失败就摘除，容易把网络抖动放大成服务震荡；连续多次才摘除，用户要陪着实例带病工作很久。成熟的平台会按业务档位分层配置这两组参数，关键业务用更密的探测和更低的阈值，普通业务反过来，用较小的探测开销换够用的反应速度。额度计数在实例切换时仍然延续，不受影响，见请求的限流计数是怎么清零的？每一步都讲透。

使用者能从健康状态读出什么

状态页绿点变黄变红时，调用失败的先别急着改代码，多数是平台侧正在处理；部分平台还提供各区域的细分状态，挑可用区域调用能避开局部波动。用量数据在实例异常时的呈现也可能滞后，对账时要留意，见服务端怎么记录 token 用量？账单的来源。豆包、讯飞星火这类面向大众的产品把状态页做得更友好，普通人也能看懂。另外，计划内的维护窗口通常提前公告，把批量任务安排在窗口外，能省掉不少无谓的失败重试。遇到「状态正常但我这里慢」的情况，先记录发生时间和请求特征再提交反馈，比一句「太慢了」更容易被定位，处理速度也快得多。

健康检查速查：

• 轻量探测：管死活，秒级轮询
• 就绪探测：管能不能接活
• 摘除恢复：渐进进出，避免震荡

三句话记住实例的进出规则。

关于健康检查的三个常问问题

• 探测会不会消耗我的额度？：不会，探测流量与用户请求分开计量。
• 状态正常为什么我还是调不通？：可能是账号级问题，如配额或权限，先查自己的用量页。
• 实例摘除时我在处理的请求会断吗？：在途请求一般会被处理完，新请求才转到其他实例。

绿点背后是一套默默运转的巡检体系，看懂它，故障时你比别人先一步找到原因。