一句话简介：影像AI的Pod一到门诊高峰就被OOM Kill，不是K8s的问题，是资源模型没设计好。这篇复盘怎么把内存/GPU/弹性伸缩一起调对。

---

最近在做某三甲医院影像AI推理集群的资源治理，遇到一个挺典型的坑：AI辅助诊断的Pods白天能跑，一到早高峰，dmesg里全是OOM Killer，Pod被反复重建，患者等片的延迟从"秒级"掉到"十几分钟"。作为医疗云原生架构师，我必须先说清楚——这不是K8s的问题，是我们把容器资源模型当成"填数字"来配的锅。

医疗影像AI应该是K8s承载里最"糙"的一类负载：3D影像一张2~4GB、模型加载就吃掉几G内存、GPU还得分大家一起抢。今天的复盘，就讲讲我在给影像AI推理集群做内存/GPU/弹性伸缩调优时，踩过的3个坑。

一、Requests/Limits不是"填个不报错的数"，而是"保命线"

复盘：最早我图省事，把内存的requests和limits设成一样、还都偏小，以为"够了就行"。结果AI模型加载时的瞬时峰值直接把Pod怼到OOM，K8s按limits把容器杀了——它以为你在保护它，其实是你的limits设得太紧。

可落地：

1. 内存limits要给足模型加载的"尖峰"，别按平均值配；我按模型大小×1.5预留，再留20%给推理进程的运行开销。

1. requests拉到下限、limits拉开空间，让调度器能塞进来、运行时又有余量，避免"能调度但一跑就死"。

1. 给关键推理Pod加preStop sleep做优雅退出，别让K8s在扩容缩容时把正在算的单硬掐断。

二、只做HPA横向扩容不够，还要VPA和GPU亲和一起来

复盘：影像AI是"内存型+GPU型"混合负载，光看CPU/内存的HPA根本测不准。早高峰扫描量涨3倍，CPU利用率没到阈值，可GPU显存早就抢满了，Pod还是一个个挂。用错伸缩指标，等于没装护栏。

可落地：

1. HPA不能只用CPU，要把队列长度（排队算的片子数）当成外部指标，队伍一长就提前扩容。

1. 配VPA（垂直Pod自动扩缩）让单Pod自己长内存，跟HPA横向叠加，一个管"加人"一个管"加量"。

1. GPU节点要有专门的亲和性和容忍度，别让CPU温柔的普通Pod把GPU算力宿主挤爆。

三、只看监控大屏会漏，信创环境下告警要把"因果"串起来

复盘：告警全是"CPU过高""网络丢包"这类表象，半夜手机狂震，爬起来发现根因是上游数据库慢查询带崩的连锁反应。尤其信创改造后，把Oracle换国产库、监控插件又采集不上来，系统直接变"黑盒"，看不见根因比故障本身更可怕。

可落地：

1. 运维底座本身就是信创且自研，能采国产OS、国产数据库、国产中间件，别让采集代理依赖国外组件（告警滞后半小时就是这类坑）。

1. 用AI根因分析，把历史数据喂进去建动态基线，识别"促销/高峰期的正常波动"，别拿固定阈值瞎报警。

1. 告警要能回溯关联路径（网络→数据库→应用→容器），几分钟定位到具体服务节点，别让团队靠肉眼切五套系统拼拓扑。

亮点 / 结论

影像AI容器治理其实是一套"护栏工程"：资源配额是"保命线"，弹性伸缩是"护栏"，链路告警是"眼睛"。三个缺一个，高峰期必现原形。建议信息科在国产化改造时，把这三件事提前写进验收清单——不是"能跑"，而是"高峰也跑得稳、出问题找得到根"。