推理服务为什么一上健康检查就开始误杀正常实例：从 Probe 设计到优雅降级的工程实战

一、健康检查为什么成了杀手在 Kubernetes 集群部署大模型推理服务后实例正常处理请求却频繁被 kubelet 重启。事件日志原因出奇一致——Liveness probe failed。大模型推理负载与常规 Web 服务截然不同。一次 Prefill 可能持续数秒高并发下 GPU 被持续占满。kubelet 的 /healthz 请求进入队列后若前面排了多个推理任务探针响应很容易超过 1s 超时。许多团队直接照搬微服务探针配置连续三次超时即触发重启。对加载 70B 模型需数分钟的 Pod这是自杀配置。⚠️ 核心误区是把进程存活等同于服务健康。推理服务健康是多维度的。图 1Kubernetes 事件流中频繁出现的探针失败与容器重启二、从误杀根因到 Probe 分级误杀来自三个层面错配。探针类型错配最常见Liveness 本意检测死锁团队却常把就绪逻辑塞进去。队列繁忙时 Liveness 失败直接重启容器而非摘流。超时参数错配同样致命P99 延迟 5 到 10 秒探针超时却设 1 秒。优雅终止缺失雪上加霜请求断开、KV Cache 丢失、客户端收 502形成死亡螺旋。 正确做法是建立探针分级。Startup 确认模型加载完成Liveness 只做存活检查Readiness 反映能否接收新请求需检查队列深度与 GPU 显存。探针类型检查目标失败后果建议配置Startup Probe模型加载完成、服务可访问不标记为 ReadyfailureThreshold30, periodSeconds10Liveness Probe进程未死锁、主线程存活重启容器极简 HTTP 200timeoutSeconds5Readiness Probe是否还能接收新请求从 Endpoints 摘除检查队列深度与 GPU 显存 Readiness 失败只摘流量不杀容器Liveness 失败才重启。把负载检查放到 Readiness 是第一原则。[外链图片转存中…(img-7BrQXAbJ-1779153757152)]图 2Probe 分级体系与流量控制关系三、自定义就绪检查实战Readiness Probe 不能只做简单 ping。生产就绪端点需暴露真实负载状态排队请求数或 GPU 显存超阈值时返回 503让负载均衡器把流量切走。以下是基于 FastAPI 的实现框架。核心逻辑是维护运行时指标在就绪端点按阈值返回状态。fromfastapiimportFastAPI appFastAPI()queue_depth0max_queue_depth16gpu_memory_percent0.0max_gpu_memory_percent0.92app.get(/health/ready)asyncdefreadiness_probe():ifqueue_depthmax_queue_depth:return{status:unready,reason:queue_full},503ifgpu_memory_percentmax_gpu_memory_percent:return{status:unready,reason:gpu_memory_high},503return{status:ready}app.get(/health/live)asyncdefliveness_probe():return{status:alive} 不要把就绪检查做成同步推理。若就绪端点需访问 GPU 状态确保不进入主推理队列。[外链图片转存中…(img-UVix0X4i-1779153757153)]图 3自定义就绪检查端点的核心逻辑实现四、优雅终止别让重启变成事故即使探针配置正确实例升级或缩容时仍需终止 Pod。Kubernetes 发送 SIGTERM 后给 Pod 宽限期默认 30 秒。推理服务须在此窗口内停收新请求并尽量让进行中的推理跑完。importsignalimportsysimporttimefromfastapiimportRequest shutting_downFalsedefhandle_sigterm(signum,frame):globalshutting_down shutting_downTruetime.sleep(15)sys.exit(0)signal.signal(signal.SIGTERM,handle_sigterm)app.middleware(http)asyncdefshutdown_guard(request:Request,call_next):ifshutting_downandrequest.url.path!/health/live:return{status:shutting_down},503returnawaitcall_next(request)⚙️ 生产环境更稳妥的做法是收到 SIGTERM 后立即将 Readiness 设为 false等待活跃请求归零再退出。terminationGracePeriodSeconds 建议 120 秒以上必须大于最长单请求推理时间。️ 关键参数是 terminationGracePeriodSeconds 必须大于最长单请求推理时间。五、深度思考与趋势判断当前主流推理框架的健康端点普遍偏简单多数只提供 /health 返回 200在生产规模化部署时显得不足。笔者认为推理服务健康模型正从二元存活向多维状态机演进。未来会出现三个趋势按模型维度拆分健康状态服务网格与自定义探针深度集成推理框架内置过载保护动态就绪反馈替代静态限流。 核心判断是推理服务的 SRE 体系不能照搬微服务经验。探针设计的本质是负载感知而非心跳检测。总结推理服务被健康检查误杀根源在探针逻辑与负载特征不匹配。通过建立三级探针体系、自定义就绪检查与优雅终止机制可将重启频率从每小时数次降到每周数次。你在部署大模型推理服务时是否遇到过探针误杀问题欢迎分享经验。 别忘了点赞收藏后续持续更新 AI 推理优化的深度解析与实战干货。关注我带你玩转 AI。