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、队列和依赖状态。
端口通不代表模型可用。健康检查越贴近真实服务能力，流量切入越安全。
