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: trueliveness 不要做重型模型推理否则探针本身会增加负载。四、探针失败要能解释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、队列和依赖状态。端口通不代表模型可用。健康检查越贴近真实服务能力流量切入越安全。