云原生 AI 推理弹性：GPU 扩容慢，要先设计预热池

云原生 AI 推理弹性：GPU 扩容慢，要先设计预热池

一、AI 推理扩容不能照搬普通 Web 服务

普通 Web 服务扩容时，新 Pod 启动、拉镜像、通过健康检查后就能接流量。AI 推理服务不一样。模型文件大，GPU 初始化慢，运行时还要加载权重、分配显存、预热算子。等 HPA 发现指标上涨再扩容，用户可能已经排队很久。

所以云原生 AI 推理弹性要承认一个现实：GPU 扩容很贵，也很慢。真正可用的策略不是“流量上来再创建”，而是提前准备可接管的预热容量。预热池不是浪费，它是用资源换响应确定性。

二、推理弹性链路要分成资源和模型两层

GPU 节点可用，不等于模型实例可用。节点、驱动、容器、模型、健康检查都要分别观察。

flowchart TD A[流量上涨] --> B[指标触发扩容] B --> C[GPU 节点是否充足] C -->|否| D[节点扩容] C -->|是| E[启动推理 Pod] D --> E E --> F[加载模型权重] F --> G[预热推理] G --> H[接入流量]

如果只看 Pod ready，就会误判。Pod ready 可能只是进程启动了，真正首个推理还没稳定。健康检查要覆盖模型加载和一次轻量推理。

三、预热池要有独立指标

下面是一个简单的容量判断结构。

type InferenceCapacity = { readyReplicas: number; warmingReplicas: number; queuedRequests: number; p95LatencyMs: number; }; function needWarmPool(cap: InferenceCapacity) { return cap.queuedRequests > 0 || cap.p95LatencyMs > 800; }

预热池不能只看副本数，还要看排队长度、GPU 利用率、显存余量和首 token 延迟。对于生成式模型，平均延迟没有太多意义，排队时间和首响应时间更能反映用户体验。

四、扩容策略要结合业务节奏

如果业务流量有明显周期，比如白天高峰、活动开始、定时任务触发，可以用预测扩容提前拉起预热实例。不要等指标报警后才行动。

还要考虑模型版本。新版本灰度时，旧版本和新版本可能同时占用 GPU。容量规划要把双版本共存算进去，否则灰度发布本身就会触发资源争抢。

降容也要谨慎。AI 推理实例释放后，下次再拉起成本很高。可以给低峰容量设置缓慢回收窗口，避免流量短暂回落就立刻释放，再被下一波流量打穿。

最后，预热池要和成本预算绑定。不是所有模型都需要同样的预热等级。核心在线模型可以保留热池，低频模型可以接受冷启动。弹性策略不是追求零等待，而是在体验和成本之间明确取舍。

推理服务还要把“可调度”和“可服务”分开监控。GPU 节点 Ready 只说明调度层有资源，模型实例 Ready 才说明业务能接请求。很多排障会卡在中间：节点有卡，Pod 也起来了，但显存碎片、驱动版本或模型文件校验让实例迟迟无法服务。

队列策略也很关键。流量超过热池容量时，是排队、拒绝、降级到小模型，还是返回稍后重试？这些策略要提前写进产品行为。没有队列上限的推理服务，最终会把延迟拖到所有用户都不可接受。

多模型平台还要做优先级。高价值在线模型和低优先级批处理模型不能平等抢 GPU。可以通过节点池、队列权重和抢占策略把关键服务保护起来。弹性不是谁先来谁占用，而是按业务价值分配稀缺资源。

五、总结

云原生 AI 推理弹性不能只照搬普通 HPA。GPU 节点扩容、模型加载、显存分配和预热推理都会拉长可用时间。预热池、预测扩容、版本容量和慢速降容，是生产推理服务稳定接流量的关键。