AI 推理服务探针：健康检查不能只看端口通不通

AI 推理服务探针：健康检查不能只看端口通不通

一、端口通不代表模型可用

Kubernetes 里给服务加 liveness 和 readiness 很常见。但 AI 推理服务的健康状态比普通 HTTP 服务复杂。端口能响应，不代表模型加载完成、GPU 可用、队列没堵、依赖存储可读、Tokenizer 正常。

如果探针只检查/healthz返回 200，流量可能过早打到尚未准备好的 Pod。

二、探针要分阶段

flowchart TD A[容器启动] --> B[进程存活] B --> C[模型加载] C --> D[GPU 初始化] D --> E[依赖检查] E --> F[接收流量]

liveness 只判断进程是否需要重启，readiness 判断是否能接流量，startupProbe 判断初始化是否完成。三者不能混用。

模型加载时间可能很长，startupProbe 要给足时间；readiness 则要更严格，确认模型和关键依赖都可用。

三、健康状态要结构化

type InferenceHealth = { process: "ok" | "failed" modelLoaded: boolean gpuReady: boolean queueAccepting: boolean storageReady: boolean }

探针内部可以检查多个子状态，但对 Kubernetes 返回时要明确。比如模型未加载完成时 readiness 失败，但 liveness 不失败，避免容器被反复杀掉。

probe_policy: startup_allow_model_load_minutes: 15 readiness_check_queue: true readiness_check_gpu: true liveness_avoid_model_probe: true

liveness 不要做重型模型推理，否则探针本身会增加负载。

四、探针失败要能解释

Pod NotReady 时，平台要能看到原因。是模型下载慢、GPU 初始化失败、对象存储不可用，还是队列背压。只显示 readiness failed 不够。

还要注意探针超时。AI 服务启动时 CPU 和 IO 压力大，探针超时过短会误杀。探针配置需要按模型大小和节点性能调。

探针还要避免触发真实推理。有人会用一次小 prompt 作为 readiness 检查，这看似准确，但会消耗 GPU、污染队列，还可能在高峰期放大负载。更好的方式是检查模型状态、GPU runtime 和队列接收状态。

inference_probe: liveness_path: /livez readiness_path: /readyz startup_path: /startupz readiness_timeout_seconds: 2 no_real_generation: true

如果模型服务支持多模型，readiness 还要按模型维度返回。某个模型加载失败，不一定代表整个 Pod 不能服务其他模型。网关需要知道哪些模型可用，才能正确路由。

探针失败还应进入事件和日志。Kubernetes Event 里写清具体子状态，值班人员才能从kubectl describe pod直接看到线索，而不是再进容器翻日志。

上线前可以做启动演练：清空缓存、模拟对象存储慢、模拟 GPU 初始化失败，观察探针是否给出正确状态。探针只有在坏场景里验证过，才算可靠。

五、总结

AI 推理服务探针要区分启动、存活和就绪，检查模型、GPU、队列和依赖状态。

端口通不代表模型可用。健康检查越贴近真实服务能力，流量切入越安全。