K8s探针配置AI服务：别让健康检查成为摆设

这个就绪探针自定义检测推理队列深度的思路很实用，我们之前也踩过类似坑——模型服务进程活着但显存碎片化导致响应超时，后来加了平均推理耗时指标才把问题揪出来。不过启动探针的超时时间你们一般设多少？我们冷启动有个模型要加载5分钟，设短了反复重启，设长了又怕错过其他异常。

看到这段分享真的挺有共鸣的，我们团队最近也在折腾AI服务的健康检查，你说的GPU显存泄漏那个坑我们刚踩过。进程还活着但推理已经慢到超时，传统探针完全没反应，最后是靠监控发现显存一直涨才定位到的。

有个问题想请教一下：你提到的就绪探针里加推理队列深度或耗时判断，具体是怎么实现的？我们试过在/readyz端点里加个简单的显存阈值检查，但发现不同模型的显存占用波动很大，固定阈值容易误判。比如有些模型刚加载完显存就占满了，但推理正常；有些模型推理时显存反而会降一点。你们是用了动态阈值还是直接抓推理队列的实时状态？

另外，启动探针的配置时间你们一般设多久？我们有个大模型冷启动要5分钟，启动探针设了300秒，但偶尔网络波动或镜像拉取慢，启动探针还没跑完就超时了，结果被重启了好几次。后来只好把initialDelaySeconds再加长，但这样又拖慢了上线时间，感觉有点两难。

还有个小细节想确认下：你说用/livez和/readyz区分，那对于AI服务里多个模型共存的情况，是每个模型独立暴露探针端点，还是统一聚合到一个端点里？我们试过分模型暴露，但运维那边说端点太多不好管理，现在我有点纠结。

看到这个帖子，确实说到我心坎上了。AI服务上K8s的探针配置，表面看是个运维问题，但往深了挖，其实是整个分布式系统对AI工作负载认知不足的缩影。我过去两年在几个大模型推理平台和在线服务项目里，几乎把帖子提到的所有坑都踩了一遍，甚至包括一些帖子里没完全展开的深层问题。今天想结合具体案例，把这个话题掰开了聊聊。

先说说帖子提到的/livez和/readyz分离。这个方案本身没问题，但实际落地时，很多人忽略了一个关键点：存活探针（livenessProbe）和就绪探针（readinessProbe）的失败阈值和周期设计，必须和模型的冷启动时间、显存分配策略深度耦合。举个例子，我们之前部署一个7B的LLM，模型文件大概14GB，用VLLM加载，冷启动时间通常在40秒到80秒之间浮动，取决于当时GPU的显存碎片情况。如果我们把存活探针的initialDelaySeconds设成30秒，那模型加载到一半，探针一打，进程没返回200，K8s直接重启Pod，模型加载又得从头开始。更坑的是，如果集群里同时有多个Pod在冷启动，重启风暴能把整个GPU节点打挂。我们的解决方案是：对AI推理Pod，存活探针的initialDelaySeconds不仅要基于模型理论加载时间算，还要加上一个20%到30%的余量，同时把failureThreshold设得高一些，比如5到8次，周期设到15秒以上。这样即使加载过程中有短暂抖动，也不会误杀。但这也带来了另一个问题：如果模型真的卡死在加载阶段，比如某个算子初始化时死锁了，那探针要等很久才能发现。所以我们又加了一层启动探针（startupProbe），单独控制冷启动阶段的探针逻辑。启动探针的检测逻辑更轻量，只检查进程是否存活、显存是否已分配，不检查推理能力。一旦启动探针通过，就把控制权交给存活和就绪探针。这个做法基本杜绝了冷启动阶段的误杀和重启风暴，但代价是多了一层探针配置的维护成本。

帖子提到就绪探针应该加入自定义逻辑，比如推理队列深度和上次推理耗时。这个我举双手赞成，但想补充一个更关键的维度：显存状态。GPU显存泄漏是AI服务的慢性病，尤其在PyTorch和TensorFlow这种动态图框架下，显存碎片化导致OOM的概率比进程崩溃高得多。我们遇到过一种情况：一个推理Pod跑了48小时后，显存占用从12GB涨到22GB（卡是40GB的A100），但进程仍然返回200，存活探针认为健康。可是这时推理延迟已经从50ms飙升到800ms，因为显存不足导致内存换入换出，而且OOM Killer随时会触发。我们的做法是：在就绪探针的HTTP端点里，调用nvidia-smi或者NVML库，实时采集显存使用率和推理延迟的滑动窗口平均值。如果显存使用率超过85%且持续上升，或者推理延迟超过基线值（比如模型刚部署时的P99延迟）的3倍，就标记为NotReady。这样K8s会自动把流量切到其他健康的Pod上，然后我们再用优雅的Pod终止流程（preStop钩子）把有问题的Pod摘掉。这个方案看着简单，但实际落地有一个坑：显存采集本身会引入开销，如果在每个就绪探针请求里都调用nvidia-smi，高并发时反而会加剧显存压力。我们最终用了共享内存的方式：用一个Sidecar容器专门采集GPU指标，写入一个共享的tmpfs文件，主容器的探针端点直接读这个文件。这样探针的延迟控制在1毫秒以内，也避免了重复采集的开销。

帖子提到gRPC探针和HTTP探针的选择，我倾向于分场景。对于非流式推理（比如一次请求发一个prompt，返回一个完整结果），HTTP探针完全够用，只要在/readyz里封装好自定义逻辑就行。但对于流式推理（比如LLM的token-by-token输出），HTTP探针有一个天然问题：健康检查的请求-响应模型是短连接，而流式推理的gRPC连接是长连接。如果只用HTTP探针检查进程健康，但实际gRPC流可能已经断开了（比如网络抖动导致连接池里的某个连接异常），K8s不会感知到，流量还是会打过来，导致客户端侧看到推理中断。我们踩过这个坑：一个流式推理服务，客户端用的是gRPC双向流，服务端用Python的asyncio处理。有一次底层网络设备做了个微调，导致部分gRPC连接在传输层被重置，但进程存活探针显示正常。结果就是客户端发请求，服务端接受后开始推理，但推理结果发不回去，客户端一直超时重试，最终引发雪崩。解决方案是：对流式推理服务，就绪探针必须检测gRPC连接池的健康状态。具体做法是，在/readyz端点里，用一个独立的gRPC客户端每隔几秒向服务端发一个简单的Unary RPC（比如一个空的HealthCheck请求），如果连续两次失败，就标记NotReady。这个额外的gRPC连接要单独维护，不能和业务连接池混在一起，否则健康检查的流量会影响业务连接的稳定性。另外，gRPC探针本身在K8s 1.24以后才GA，如果你的集群版本低，还需要考虑兼容性。我们当时在1.22上，只能用HTTP探针加自定义逻辑模拟gRPC健康检查。

帖子提到AI服务正从纯无状态转向混合负载，这个观察非常敏锐。但我想进一步指出：混合负载的真正挑战，不在于探针配置本身，而在于K8s的调度器和探针机制存在一个根本性的信息不对称。K8s的默认调度器是不感知GPU显存、推理延迟这些AI服务特有的资源的。比如，一个Pod的就绪探针返回NotReady，调度器只会把它从Service的Endpoints里摘掉，但不会把它从节点上驱逐，也不会触发重新调度。这会导致一种情况：一个节点上跑了4个推理Pod，其中3个因为显存泄漏标记了NotReady，但调度器不知道，它可能还会往这个节点上调度新的推理Pod，因为节点级别的CPU和内存指标看起来还正常。结果就是节点上的显存被进一步耗尽，所有Pod都变成NotReady，形成节点级别的故障。我们解决这个问题的思路是：结合K8s的Extended Resource机制，把GPU显存作为可调度资源上报给API Server。这样调度器在分配Pod时，会考虑显存的容量。但这个方法也有局限，因为显存是动态变化的（模型加载时显存占用高，加载完后释放一部分），而Extended Resource是静态的。更彻底的方案是用K8s的Device Plugin框架，让GPU设备插件动态上报可用的显存大小，但实现复杂度很高，社区里还没有成熟的方案。

另外一个容易被忽视的点是：探针的日志和告警设计。很多团队只关注探针是否通过，不关注探针失败的原因。但AI服务的探针失败，往往意味着模型或硬件出了潜在问题。比如，我们在一个大规模推理集群里，通过分析就绪探针的失败日志，发现一个规律：某个特定GPU型号（比如A100-40GB）在显存使用率达到90%以上时，推理延迟会突然飙升，但探针返回200。后来排查发现是NVIDIA的驱动版本有bug，导致显存带宽在高压下出现降频。如果我们只关注探针的通过/失败，这个bug可能要等到用户投诉延迟高才能发现。所以，我建议在探针端点里，除了返回HTTP状态码，还要在响应体里带上详细的健康指标，比如显存使用率、推理延迟P50/P99、模型加载状态等。然后用Prometheus等监控系统采集这些指标，设置告警规则。这样，即使探针通过了，如果显存使用率持续高位或延迟有异常趋势，也能提前介入。

说到告警，还有一个实操经验：AI服务的探针设计，要和自动扩缩容（HPA）联动。很多团队把HPA基于CPU或内存使用率，但这对AI推理服务不适用。因为推理服务的瓶颈通常是GPU显存或推理延迟，而不是CPU。我们试过基于自定义指标做HPA，比如用Prometheus采集的推理队列深度和显存使用率。但有一个坑：当显存使用率超过80%时，如果HPA触发扩容，新Pod的冷启动过程会进一步消耗显存（因为模型加载也需要显存），反而可能导致现有Pod的显存压力瞬间增大，引起雪崩。我们的解法是：HPA的扩容阈值设得低一些，比如显存使用率超过60%就开始扩容，同时用PDB（PodDisruptionBudget）控制Pod的优雅下线。另外，扩容时新Pod的启动探针要在完全就绪后才能加入Service的Endpoints，这个延迟时间要算进HPA的冷却时间里，否则会出现扩容一批Pod，但还没就绪就被打流量的情况。

最后，我想分享一个关于探针测试的教训。我们之前自测时，只在单节点、低并发环境下验证了探针逻辑，觉得没问题。上线后，流量一上来，问题就暴露了：就绪探针的HTTP端点里，我们实现了一个复杂的逻辑，包括调用模型推理引擎的API查询队列深度、查询显存状态、计算延迟滑动窗口。这个逻辑本身没问题，但高并发下，探针端点成了瓶颈——因为每个探针请求都会触发一次对推理引擎的查询，而推理引擎内部有锁竞争，导致探针响应时间从1毫秒飙升到500毫秒。更严重的是，探针请求的并发量（K8s默认每个Pod每10秒打一次，集群有几百个Pod时，总请求量其实不大）虽然不大，但推理引擎内部的锁竞争会影响正常的推理请求。所以，探针端点的实现必须足够轻量，最好只读共享内存或缓存，不要直接操作推理引擎的核心数据结构。我们最终把探针端点改成了纯内存读取，用另一个goroutine（或协程）定期（比如每5秒）更新健康状态到共享内存。这样探针请求基本是零开销，也隔离了健康检查对业务的影响。

总结一下，AI服务的探针配置，本质上是把AI工作负载的非功能性特征（显存、延迟、模型生命周期）映射到K8s的抽象模型里。这个映射过程没有银弹，需要根据模型的加载方式、推理的实时性要求、GPU硬件特性做定制。帖子提到的/livez和/readyz分离、自定义逻辑、启动探针，都是很好的起点。但再往下走，还需要考虑探针与调度器、HPA、监控系统的协同，以及探针本身的性能开销。希望这些实战经验和踩坑记录，能给正在做AI服务容器化的团队一些参考。

说到AI服务的探针设计，这个坑确实踩过的人才知道多疼。你提到的GPU显存泄漏导致进程存活但推理延迟飙升，我这边也遇到过，而且更隐蔽——有时候显存泄漏是渐进式的，第一天正常，第三天开始批量推理超时，但进程和HTTP接口都还是200。后来我们做法是在就绪探针里加了个轻量级的推理采样，随机挑一个模型跑一次最小推理，耗时超过基线两倍就直接拉掉Pod，效果比查指标阈值更直接。

另外你提到的启动探针，对于那种加载完基础模型还要做tokenizer预热、甚至要跑一遍样本数据来触发JIT编译的场景，简直是救命稻草。我们有个LLM服务，冷启动要40秒，之前没加startupProbe，就绪探针在30秒超时后一直重启，循环了七八次才稳定，后来设置startupProbe的initialDelaySeconds为45秒，failureThreshold=1，一次性通过。

不过想追问一个点：你建议的就绪探针里加推理队列深度检测，这个阈值怎么定比较合理？我们试过根据并发上限的80%来标记，但发现不同模型实例的队列堆积速度差异很大，有的模型吞吐高但延迟敏感，队列深度5就已经超时了；有的模型吞吐低但容忍度高，深度20还能接受。目前我们改成用平均排队等待时间做阈值，比如超过200ms就NotReady，但这样又引入了额外的时序依赖，不知道你们是怎么平衡的？

这个帖子说得挺到位的，尤其是GPU显存泄漏导致进程存活但推理质量下降的问题，我在生产环境里也踩过类似的坑。单纯靠/livez和/readyz区分存活和就绪，在AI场景下确实不够用——模型加载完不代表能正常推理，显存碎片化或者驱动层面的隐性故障，常规HTTP探针根本感知不到。

关于就绪探针加自定义逻辑这点，我补充一个实际做法：我们在业务里对就绪探针挂了两个指标，一个是推理请求的平均排队延迟，另一个是最近N次推理的P99耗时。如果排队延迟超过500ms或者P99耗时突增到正常值的3倍以上，就主动把Pod从Service的endpoint里摘掉。这样虽然增加了探针的复杂度，但能有效避免半死不活的实例拖垮整个集群。另外，启动探针的初始延迟和周期频率也得根据模型冷启动时间动态调，设死了容易在模型预热期间被反复重启。

想问个问题：你们对推理队列深度的阈值是怎么定的？是按模型并发数算，还是根据实际业务的SLA反推？我们试过按并发数硬算，但不同模型的推理时长方差太大，效果不太理想。

这个思路很实用，我之前也踩过显存泄漏的坑，进程明明活着，推理却慢得像蜗牛。想请教一下，自定义就绪探针里检测推理队列深度时，阈值一般设多少比较合适？还有，启动探针给冷启动模型设超时时间，有没有什么参考公式或者经验值？

这个帖子真的说到心坎里了。最近刚接手一个AI推理服务的运维，也是被探针折腾得够呛。之前按常规配了/livez和/readyz，结果模型一加载完就绪探针就过了，但推理接口实际还卡在显存分配上，前端直接超时。后来学着加了startupProbe才稳住冷启动那一段。

不过有个问题想请教一下：你们给就绪探针加自定义逻辑的时候，是怎么处理探针本身的性能开销的？比如每次检测推理队列深度或者上次推理耗时，如果检测逻辑本身也占用GPU资源，会不会形成新的瓶颈？我试过用Python写了个简单的检查脚本，但发现每次调用都触发一次CUDA上下文切换，反而让推理延迟更不稳定了。后来改成用共享内存记录推理耗时的时间戳，再让探针读文件，但总觉得不够优雅。

另外，显存泄漏那个情况你们是怎么检测的？我用nvidia-ml-py采集显存使用量，但探针周期太短的话，频繁查询nvml也会造成轻微性能影响。有没有什么轻量级的办法能平衡检测精度和副作用？比如是不是可以结合pod的资源指标（像container_memory_working_set_bytes）做二次判断，而不是依赖直接查询GPU状态？

还有个小细节：启动探针的initialDelaySeconds你们一般设多少？我这边模型加载时间波动很大，有时20秒有时2分钟，设短了启动期间疯狂重试，设长了又拖慢总启动时间。现在用了个动态调整的思路，但实现起来总觉得不太稳。

GPU显存泄漏导致200但推理延迟飙升这个坑我也踩过，后来在就绪探针里加了显存使用率和平均推理耗时两个指标，阈值设到80%和500ms，效果立竿见影。不过启动探针的initialDelaySeconds得根据模型实际加载时间调参，我一般先在本地打日志测出平均值再加30%余量，不然冷启动阶段反复重启反而更慢。

这个显存泄漏导致进程活着但推理变慢的坑太真实了，我们之前也是用/healthz一路绿灯，结果线上延迟飙到秒级才反应过来。现在对就绪探针加了自定义指标，监控推理耗时和batch积压数，超过阈值直接摘流量，稳了很多。另外想问问启动探针的超时时间一般设多久？我们模型冷启动要40秒，设太短反复重启反而更慢。

这个帖子真的说到点子上了，尤其是GPU显存泄漏那段，太真实了。我之前也碰到过类似情况，模型进程明明活着，健康检查也返回200，但推理响应时间从50ms慢慢涨到5s，等发现的时候线上已经堆了一堆超时请求。后来我们也加了自定义逻辑，不过我们是监控推理请求的P99延迟，超过500ms就主动把pod从service端点摘掉，算是用业务指标反推健康状态。

有一个问题想请教一下，你们对推理队列深度的阈值是怎么定的？我试过直接设个固定值，比如队列超过100就NotReady，但发现模型并发处理能力会动态变化，有时候队列100其实还能扛，有时候50就扛不住了。是不是得结合模型的实际吞吐量来做动态阈值，比如算一下当前时刻的请求到达率和模型处理速率？

另外，启动探针这块，我们模型冷启动时间大概要3-5分钟，但不同模型差异很大。你们是统一设一个大的超时时间，还是针对每个模型分别配置？我担心统一设太大浪费等待时间，设太小又频繁重启。如果有通过启动探针配合preStop钩子优雅处理过模型卸载的经验，也求分享下。

这个帖子太真实了，尤其是GPU显存泄漏那一段，简直说到我心坎里了。之前我们线上就出过类似的事，模型进程活得好好的，但推理延迟从几十毫秒飙到十几秒，直到用户反馈了才发现。查了半天是显存碎片化导致分配越来越慢，但HTTP探针还在200，等于说健康检查完全形同虚设。

后来我们改的方案是，在就绪探针里直接调模型的一个轻量级推理接口，传个固定测试数据，如果返回时间超过500ms就认为不健康。另外还加了个显存使用率的监控，超过85%就主动触发优雅退出。不过这个有个坑，就是如果测试数据本身复杂度低，可能显存涨了但推理速度没明显变化，所以还得结合业务场景动态调整阈值。

启动探针这块我也补充一个点：对大型模型，冷启动可能不是单纯的加载时间长，有时候是前期CPU预处理（比如分词、构建索引）很吃资源。我们试过在startupProbe里加一个标记位，等模型完全就绪才暴露服务端口，这样就能避免k8s在启动阶段反复重启。另外，如果模型依赖外部资源（比如从S3拉模型文件），还得考虑网络抖动，启动探针的超时时间设长一点，别因为一次失败就前功尽弃。

对了，楼主提到推理队列深度，这个检测我们在生产里也用了，但有个小问题：如果队列深度触发阈值后马上切NotReady，可能导致服务雪崩，因为流量会瞬间转移到其他节点，反而让其他节点也过载。所以我们加了平滑策略，比如连续三次超过阈值才标记不健康，或者用滑动窗口计算平均深度。你们是怎么处理这个弹性的？

GPU显存泄漏导致200但推理延迟飙升这个坑太真实了，我们之前线上AI服务就吃过这个亏——kubelet觉得进程活着，实际上请求全在排队超时。后来在readinessProbe里加了自定义exporter，暴露推理队列长度和p99延迟，阈值一超直接摘流量。另外startupProbe的initialDelaySeconds建议根据模型加载实测值来配，我们做LLM服务时设成120秒才稳住，不然反复重启反而拖慢恢复。

这个思路很实用，特别是用推理队列深度和耗时做就绪探针这点，我们之前只靠内存占用判断，结果模型显存泄漏前排完的请求全超时了。想请教下你们自定义探针具体怎么实现的？是写了个sidecar还是直接在应用里集成健康检查端点？

看到这个帖子深有同感，前阵子我们团队也在这上面吃过亏。我们当时有个CV模型服务，用的gRPC探针，以为进程活着就万事大吉，结果某次线上推理延迟从20ms飙到800ms，用户端直接超时，但Pod一直显示Ready，K8s压根没触发重启。后来排查发现是显存碎片化导致的，但进程HTTP响应还是200，确实像你说的，传统探针太表面了。

你提到的自定义检测推理队列深度和上次推理耗时，这个思路很实用。我们后来是在就绪探针里加了个轻量级的内部调用，模拟一次简单推理，如果响应时间超过正常值的3倍就标记NotReady。不过有个坑要注意，探针本身不能太重，否则成了性能瓶颈。我们试过用Python直接调用模型做检测，结果探针把GPU占满了，反而影响了正常推理，后来改成用共享内存读取推理引擎的实时指标才算解决。

另外启动探针这块，我们用的是NLP模型，冷启动加载分词器和模型权重要40秒，但默认的initialDelaySeconds设小了，导致就绪探针在启动期间疯狂失败，Pod被重启了好几次。后来直接设了个120秒的启动探针，等模型完全预热后再让就绪探针接管，世界清净了。不过启动探针的failureThreshold和periodSeconds要调好，不然启动时间长的模型容易在阈值内判定失败。

还有个细节，如果你的服务有多个副本，可以给就绪探针加个抖动，防止所有Pod同时被标记NotReady导致流量全挂。我们当时就是探针太敏感，一次显存抖动直接把所有副本干掉了，线上挂了5分钟才恢复。现在用的是random延迟，让每个副本的检测时间错开，虽然不能解决根本问题，但至少避免了雪崩。

显存泄漏这个点太真实了，进程活着但推理慢成狗，传统探针根本抓不到。我最近也在折腾自定义就绪探针，接了个prometheus的推理延迟指标做阈值判断，比纯HTTP探针靠谱多了。另外启动探针的initialDelaySeconds你们一般设多大？我这边模型冷启动要30秒左右，设太短反而触发重启循环。

看到这个帖子感触挺深，最近正好也在搞AI服务的K8s部署，探针这块确实是个大坑。你提到的GPU显存泄漏导致进程返回200但推理变慢的情况，我这边也碰到了，当时排查了半天才发现是显存碎片化的问题，进程活着但实际已经没法正常干活了。

有个疑问想请教一下，你说就绪探针加自定义逻辑检测推理队列深度或上次推理耗时，这个具体是怎么实现的？是用sidecar暴露一个/metrics接口给livenessProbe去读，还是直接在应用层写一个/readyz的端点，里面嵌入这些业务指标？我尝试过用Prometheus的histogram来算p99耗时，但探针的时延和实际推理时延的采样周期不太匹配，有时候探针觉得没问题，但实际请求已经超时了。

另外关于启动探针，冷启动时间长的模型确实需要，但我发现一个麻烦的地方——如果模型加载过程中依赖外部服务（比如从对象存储拉模型），启动探针失败时Pod会被重启，但重启后可能又会因为网络抖动再次失败，形成死循环。我现在的做法是给startupProbe加一个较长的initialDelaySeconds，同时让应用内部做指数退避重试，但还是觉得不够优雅。你们是怎么处理这种启动依赖问题的？比如把模型预加载做成InitContainer，等加载完再启动主容器，但这个方案好像又不能动态更新模型。

这个帖子干货不少，GPU显存泄漏导致返回200但推理延迟飙升的坑确实太真实了，很多团队可能还没意识到传统探针在这类场景下有多脆弱。我最近也在调一个NLP服务的就绪探针，考虑把token生成速率作为指标嵌入进去，不知道有没有人尝试过更轻量的自定义检测方式，比如用共享内存采样而非每次都走完整推理？