大模型推理服务预热探针与探活实例剔除自愈治理落地

日期:2026-08-23

一、项目背景

这个推理服务项目一开始用最朴素的健康检查:探活接口只看端口通不通。新实例拉起来,端口一 listen,负载均衡就把流量灌进去,但模型权重还在从磁盘往显存搬,首请求要等十几秒,用户侧直接超时。更要命的是,运行期某个实例显存慢泄漏,端口照样通,可推理越来越慢,探活却一直绿,直到整批请求超时告警才有人发现。

客户找我们时,最头疼的是「看起来活着其实不能服务」,以及新实例上线那几分钟必有一波超时投诉,运维被叫醒的频率高得离谱。

二、落地场景

实例启动后不直接接流,先跑预热探针:加载权重、warmup 若干次探测请求,全部通过后标记就绪,负载均衡才把流量切过来。运行期持续探活,不只看端口,而是发一个轻量探测请求看真实响应时间和显存水位。异常实例自动从可用池剔除,触发重建,重建完再走一遍预热才回池,整个过程业务方无感。

三、关键技术挑战与解决思路

就绪态判定是核心。早期只看 TCP 端口,等于把「进程起来了」当成「能服务了」,两者差着一次权重加载和若干次 warmup。我们把就绪探针改成真正跑通一次探测请求,且探测要覆盖真实输入路径,否则 warmup 用空输入会掩盖真实问题,比如 tokenizer 没预热、KV cache 没分配,首请求照样慢。

运行期探活要带业务语义。纯端口探活对显存慢泄漏完全失明,我们让探活请求返回显存占用和最近 N 次推理耗时,超过阈值就标记为亚健康,连续几次才剔除,避免偶发抖动误杀,否则高峰期一点波动就把实例摘了,反而雪崩。

自愈靠「剔除即重建」。剔除的实例不直接重启原地复活,而是从负载池摘掉,调度器起一个新实例走完整预热再回池,老实例回收,这样不会把带病的实例又塞回来。

案例片段(已脱敏): 就绪探针配置(示意):readiness:  probe: warmup_infer  warmup_prompts: 3  expect_latency_ms: 2000  # 必须跑通探测且延迟达标才就绪 liveness:  check: [port, vram_watermark, p99_latency]  vram_threshold: 0.92  unhealthy_streak: 3  action: evict_and_rebuild一次新版本发布,warmup 第三次探测延迟 4.1 秒超标,探针拦下该实例,没让它接流,避免了一次上线即超时。一次运行期实例显存水位到 0.95,连续三次探活超标后被摘除重建,用户侧无感知。

四、效果数据

首请求超时率从上线前的约 6% 降到 0.3% 以下,新实例上线那几分钟不再有投诉,运维被叫醒的次数从每周好几回降到偶尔。实例就绪耗时稳定在 25 到 40 秒,因为预热探针明确了「好了再放」,不用业务方自己猜。探活误剔率控制在每月不到 1 次,靠的是亚健康连续判定而非单次超标,高峰期没再出现摘光实例的雪崩。自愈恢复时长从人工介入的平均 15 分钟压到 2 分钟以内,调度器自动补位,半夜基本不用人管。

五、可复用经验总结

端口通和能服务是两件事,推理服务的就绪探针必须真跑一次探测请求才算数,warmup 用空输入是自欺欺人,它掩盖的恰恰是首请求最慢的那段。运行期探活要把显存水位和真实延迟拉进来,纯端口检查对慢泄漏等于零能见度,等告警出来用户已经超时一片了。自愈别在原地重启带病实例,从池里摘掉再起新的走完整预热,比重启更干净。我们当时图省事原地重启,结果同一个显存碎片问题几小时反复出现,后来改成摘掉重建才彻底断根,这块踩的坑够写一页故障报告。

结语

探针和自愈上线后,这套推理服务的可用性从「看运气」变成了可预期,运维终于敢在白天发版。有个我们后来补的改进,是把预热探针的探测请求也纳入指标监控,早期只关心它过没过,没关心耗时趋势,结果有一次预热悄悄变慢,上线后首请求延迟还是偏高,靠监控趋势才定位。教训是探针本身也要被观测,不然它慢了你也不知道。如果再往前走,我会把实例的冷启动成本摊到调度里,让弹性缩容不会因为频繁冷启而抖动,这块目前还是拍阈值,不够聪明。

回头看,探针和自愈最大的隐性收益是让发版这件事从惊心动魄变成日常操作,团队敢迭代了,模型升级频率自然就上来了。我们也补过一个细活,是把自愈事件本身也接入告警分级,早期实例被摘除重建是静默的,有次短时间内频繁摘除,没人注意到底层调度压力在涨,后来加了单位时间自愈次数的告警,频繁自愈本身就成了故障信号。经验是,自愈机制再省心,它的动作也要被监控,否则它会悄悄掩盖底层问题。系统的可观测性永远要领先于自动化,自动化跑得越快,看不见的地方越容易出事。

把这套经验说透,推理服务的稳定性八成在启动和退出这两个最容易被忽略的瞬间,中间的推理反而最稳。我们后来把预热和 draining 当成服务契约的硬性部分写进交付标准,任何新模型上线前先过这两关,上线事故率直接下来了。稳定性的功夫,往往花在大家看不见的地方。