推理服务健康检查怎么做才能避免误杀？
推理服务的健康探针绝不能只看进程是否存活，必须构造带超时的真实推理请求，并以连续失败次数作为摘流依据，否则降级策略会把“慢”误判成“死”，最终引发雪崩。
进程级探针为什么不够用？
很多团队一开始用curl /healthz或者ps -ef来检测推理服务，误杀率极高，GPU卡显存被打满、CUDA上下文卡死、请求队列堆积时，主进程依然活着，HTTP接口也能返回200，但实际推理已经卡了十几秒，新请求全部排队。
这种现象在长上下文大模型推理中尤其明显,当输入token变长，预填充计算量呈二次方增长，一个请求就能把单卡算力耗尽，此时进程级探针会信誓旦旦地告诉你“服务正常”，而前端用户已经在转圈了。
业务级探针的设计要点：模拟一次真实推理请求
正确的做法是发送一个真正的推理请求,比如一个小型文本生成任务，然后测量从发出到收到第一个token的延迟，这个延迟能反映排队长度、显存带宽、算子是否异常。
具体探针请求要满足三个要求：
- 输入长度固定且很小：比如20个token，避免探针本身消耗过多算力。
- 打开流式输出：测量首token延迟（TTFT），比整体延迟更敏感。
- 使用独立的探针线程或进程：不要复用业务线程池，防止探针被业务任务饿死。
探针频率与超时设置实操
业内专家指出,探针参数设置需要平衡灵敏度与稳定性，参考以下经验值：
- 探针间隔：每10秒一次，太频繁会增加负载，太稀疏会响应迟钝。
- 单次超时：2秒或3倍P95延迟，取较大值，如果正常推理P95是1秒，超时设2秒；如果P95是800毫秒，超时也建议不低于2秒，避免抖动误判。
-
失败阈值：连续3次失败才标记不健康，单次失败可能是网络抖动，没必要触发摘流。
- 恢复条件：连续2次成功即恢复，恢复比失败判定更宽松，防止服务刚恢复就被再次打压。
探针返回的数据不只有健康状态,还应包括当前排队长度和平均TTFT，这些数据可以用于降级策略中的负载评估。
大模型推理降级策略对比：熔断与降级哪个优先？
很多架构师会把熔断和降级混为一谈,在推理服务场景里，降级是主动选择，熔断是被动保护，两者要协同，但顺序有讲究。
降级层次金字塔
当探针发现服务健康度下降时,不要直接拒绝所有请求，按下面的层次逐级降级：
- 第一层：缓存兜底，相同提示词和参数直接返回历史结果，命中率通常能吸收20%-30%流量。
- 第二层：缩短上下文，对超出4K的上下文按窗口截断，只保留最后2K token，降低预填充压力。
- 第三层：切换小模型，用7B模型替代70B模型处理非核心请求，比如摘要、分类任务。
- 第四层：拒绝低优先级任务，实时交互请求保留，后台批处理任务强制延迟。
- 第五层：熔断保护，如果上述措施后负载仍超80%，直接熔断，快速失败而非无限等待。
前四层是降级,最后才是熔断，原因很简单：大模型推理的可控性弱，主动降级能保住核心用户体验，被动熔断只能在边缘救火。
熔断器在推理场景的特殊性
普通RPC熔断器基于错误率,但推理服务失败率往往不高，而是延迟飙升，比如一个请求等15秒后返回成功，错误率是0，用户已经流失了。
因此推理熔断器应基于平均排队时间或TTFT的P99值，当P99 TTFT超过5秒时，触发熔断，熔断状态下的请求直接返回“服务繁忙”或进入降级路径，而不是继续堆积。
基于健康探针的自动摘流与恢复
健康探针和熔断器要联动,操作路径如下：
- 标记不健康：探针连续3次失败后，将实例从负载均衡中摘除，保留连接但不再转发新请求。
- 等待冷却：摘除的实例继续运行探针，待探针恢复后自动加回。
- 全组不健康时的逃生门：如果所有实例都被摘除，则强制保留第一个被摘除的实例继续接收流量，牺牲延迟换取可用性。
- 手动降级开关：每次版本发布前，检查降级开关是否处于自动模式。
推理服务降级策略落地的关键场景与成本考虑
多副本场景下探针权重调整
不同副本的GPU型号可能不同,比如A100和T4混部，统一探针阈值会误伤慢卡，这时应该给每类副本设置独立阈值，并根据其吞吐能力分配权重，例如T4副本的探针超时设为4秒，A100设为2秒，健康度评分采用加权平均，而不是少数服从多数。
自建推理服务与云上托管方案的成本与稳定性对比
很多团队纠结自建还是用云上托管,行业内常见的对比维度如下：
| 维度 | 自建GPU集群 | 云上推理服务托管 |
|---|---|---|
| 单次请求成本 | 低谷时段偏低 | 按量付费，高峰期溢价明显 |
| 扩缩容速度 | 需要采购和上架，数天 | 分钟级自动扩缩容 |
| 探针可定制性 | 完全可控 | 依赖平台暴露的接口 |
| 故障恢复保障 | 需自建多可用区冗余 | 平台负责硬件故障替换 |
据行业共识,中小团队优先选择云上托管，探针和降级策略直接调用平台API，大型团队在稳定业务上自建，但必须预留10%-20%的算力冗余，否则降级策略根本无处施展。
地域分布式部署时的探针网络分区问题
跨地域部署推理服务时,探针请求走公网，网络抖动会频繁误报，这时探针应部署在业务节点同一网络栈内，使用内网地址，控制面与数据面分离，探针数据通过独立通道上报，避免业务流量拥堵时探针报告也丢失。
地域调度要注意“邻近优先”策略：用户请求路由到最近节点，但降级时允许跨地域切换到健康节点，切换前要评估用户数据合规性，部分数据不能跨境传输。
Q&A：推理服务探针与降级常见问题
探针误报导致服务被摘流怎么办？
首先检查探针超时设置是否小于实际P99延迟,其次确认探针请求是否携带了不必要的采样参数，建议在探针模块中单独记录每次失败原因，区分“请求超时”和“连接拒绝”，如果大量超时但连接正常，很可能是探针参数过严，可临时将失败阈值从3次调整到5次，待业务高峰过后再改回。
降级后如何避免缓存穿透？
降级后大量相同请求会打到缓存层,如果缓存没有命中，穿透到原始模型会造成更大压力，解决方案是启用软缓存：即使没有精确命中，也返回相近提示词的结果，或者在缓存中保存所有请求的嵌入向量，用余弦相似度匹配，同时给缓存设置短过期时间，比如3-5分钟，避免降级期结束后脏数据长期残留。
单机GPU故障与整体过载如何区分？
单机GPU故障时,探针返回的错误通常是“CUDA error”或“显存OOM”，而过载时探针可以成功建立连接但响应超时，在探针代码中捕获错误类型，将“瞬时错误”和“超时错误”分开上报，整体过载时，所有实例平均延迟同步上升；单机故障时，只有故障实例延迟异常，健康实例P99基本不变，运维看板中同时展示这两个指标即可快速定位。