推理服务的弹性伸缩：冷启动、预热与 KPA 的伸缩艺术

为什么推理服务的伸缩难：三个结构性难题

普通 Web 服务的弹性伸缩（HPA 按 CPU 加副本）在 LLM 推理上水土不服，三个结构性难题。难题一：冷启动是分钟级的。普通服务起副本秒级（镜像拉取 + 进程启动），推理副本要加载几十 GB 的模型权重（从存储拉权重 5–15 分钟 + 加载进显存数十秒）——等副本起来，用户的请求早就超时了。难题二：显存的硬约束。副本数受显存总量硬性限制（每副本几十 GB 权重 + KV Cache），「想加就加」的空间很小——扩容的前提是集群里还有带 GPU 的空节点，而 GPU 节点的云上供应本身也是稀缺资源。难题三：流量的尖峰型。LLM 应用的流量不是均匀的——上班时间的企业助手高峰、事件驱动的突发——尖峰要的副本数是低谷的十倍，按峰值常备的成本不可接受。三个难题决定了推理服务需要专门的伸缩策略，而不是套用通用 HPA。

对策一：消灭冷启动的三板斧

板斧一：模型权重的本地化与预热。权重放在本地 NVMe 或节点本地盘（避免每次从对象存储拉——拉权重是冷启动的最大头）、节点预热（GPU 节点池常备「已下载常用模型」的镜像层或本地缓存——模型分发的镜像化，本库模型分发篇的方案）。板斧二：快速加载技术。模型的加载加速（safetensors 的零拷贝 mmap 加载、权重的分片并行加载）、以及推理引擎的启动优化（vLLM 等引擎的启动时间从分钟压到数十秒的持续优化）。板斧三：备而不用的暖副本。最低副本数不为零（低谷期也保持 1–2 个暖副本——「冷启动消灭」的暴力但有效方案，代价是低谷的空转成本）、以及副本的「休眠」技术（空闲副本释放算力但保留显存中的权重——weights 常驻、KV 释放，唤醒只需重建会话——比冷启动快一个量级）。三板斧的组合让「分钟级冷启动」压到「数十秒可接受」，但根治要靠预测性的扩容（下节的 KPA）。

对策二：KPA——按并发与队列深度的智能伸缩

KPA（Knative Pod Autoscaler）是 Knative 针对「请求型负载」的伸缩器，它的指标不是 CPU 而是并发请求数与队列深度——这正是推理服务的正确指标：推理服务的容量单位是「并发会话 × KV 显存」而非 CPU。KPA 的关键能力：基于并发数的伸缩（每个副本的并发目标配额——超过即扩容，本库 vLLM 篇的并发容量公式直接对接）、缩容到零与快速扩容的组合（低谷缩到零省成本、尖峰快速拉起——配合冷启动的预热手段才有意义）、以及稳定窗口与 panic 模式（流量突刺时的快速反应 vs 平稳期的防抖——伸缩的「阻尼」设计防止震荡）。与 HPA 的对比：HPA 按 CPU/GPU 利用率伸缩——推理服务的 GPU 利用率高 ≠ 需要扩容（GPU 满载可能只是批次在跑、排队不严重），按「排队深度」伸缩才对准了痛点。K8s 生态的落点：Knative Serving 或 KServe（模型服务的专用平台——内建 KPA 与灰度）是推理服务伸缩的标准底座（本库 K8s GPU 篇的调度之上）。

对策三：运营手段——预热、错峰与降级

伸缩技术之外，三个运营手段处理「尖峰的现实」。手段一：预测性预热。基于历史流量的尖峰预测（企业助手的工作时间尖峰、营销活动的已知流量）——尖峰前 15 分钟提前扩容（KPA 的反应式扩容追不上分钟级冷启动，预测性扩容是必需品）。手段二：错峰的资源安排。批处理任务（离线评测、数据标注）调度到低谷跑（本库 Kueue 篇的队列与抢占——批任务给在线服务让路的抢占式调度）、训推的资源错峰（本库训推一体篇的主题）。手段三：降级与限流的预案。尖峰超过容量的兜底——限流排队（公平排队而非丢弃）、模型的降级（旗舰换轻量——本库推理经济学篇的分级）、以及「排队告知」的用户体验（「当前繁忙，预计等待 X 分钟」——诚实的等待比超时好）。运营手段的定位：技术伸缩解决「正常波动的自动化」，运营手段解决「极端尖峰的生存」——两者互补缺一不可。

弹性伸缩的进阶话题：多级伸缩与预测的工程

推理伸缩（正文 KPA）的进阶话题：多级伸缩与预测性伸缩的工程实现。多级伸缩的设计。伸缩不止一层：层一：副本内的动态 batch（引擎的 continuous batching——秒级的容量弹性，本库 vLLM 篇——第一批伸缩：不加资源消化波动）。层二：副本数的伸缩（KPA 的按并发伸缩——分钟级）。层三：节点的伸缩（GPU 节点池的扩容——节点级的弹性：云上的节点池自动扩容、冷启动含节点 provision 的时间）。三层的协同设计：波动的吸收顺序（层一吸收秒级波动 → 层二吸收分钟级 → 层三吸收小时级——每一层的时间常数不同，协同避免「下层还没起作用上层就动作」的震荡）、以及各层的触发指标分层（层一看 batch 满载率、层二看排队深度、层三看副本池的水位——指标的分层让每层只对自己的时间尺度负责）。预测性伸缩的工程。预测的输入：历史流量的周期模式（日/周曲线）、已知的事件（营销活动、工作日节律）、趋势的外推。预测的执行：提前 N 分钟扩容（N = 冷启动时间 + 安全余量——预测性扩容的核心参数）、预测错误的兜底（反应式伸缩做保底——预测是主、反应是兜底的双保险）。预测性伸缩的收束：推理流量的尖峰是可以预测的（企业流量的节律性强）——预测性扩容把「分钟级冷启动」从体验问题变成「提前准备」的运营问题；多级伸缩让每一层的资源在正确的时间尺度上工作。

推理伸缩的成本视角：伸缩的经济性与容量底线

推理伸缩（正文）的成本视角：伸缩的经济性与容量底线——伸缩不只是技术，是成本工程。伸缩的经济账。伸缩的收益：低谷缩容省的钱（缩到零 vs 常备的差价：低谷期常备 10 副本的成本是显著的——KPA 缩到零的收益直观）。伸缩的成本：冷启动的浪费（扩容过程中的算力空转）、伸缩的震荡成本（扩了又缩缩了又扩——抖动流量的反复伸缩）、以及管理成本（伸缩策略的设计与调优）。伸缩的经济平衡点：「伸缩的净收益 > 0」的流量条件——波动越大、峰谷比越大，伸缩的收益越高；流量平稳的服务伸缩是负收益（常备更便宜）。容量底线的设计。底线的组成：最低副本数（暖副本——本库正文的三板斧）的显存常驻、SLO 的保护容量（本库 SLA 篇的冗余——底线容量是「SLO 的物理保障」）、以及新版本灰度的预留（灰度期的双倍容量需求，本库灰度篇）。底线的纪律：底线的容量不许被批任务占用（本库训推一体篇的在线优先）、底线的监控与告警（跌破底线 = 立即扩容的硬触发）。成本视角的收束：推理伸缩的终极问题不是「能不能伸缩」，是「伸缩的收益能不能覆盖它的复杂度」——流量平稳的小服务常备更理性，峰谷比大的服务伸缩是刚需；经济账算清楚，技术方案才有依据。

弹性伸缩的进阶：基于预测的扩容实现

推理伸缩（正文预测预热）的进阶：预测性扩容的实现——基于历史流量的预测式扩容工程。预测的数据基础。历史流量的存储（每小时/每 5 分钟的请求量时序——Prometheus 的历史数据）、流量的周期性分析（日周期：上班高峰；周周期：工作日 vs 周末；季节性与事件性：产品发布、营销活动的流量尖峰）。预测的实现。简单版：规则的预测（「工作日 9:00 前扩容到 20 副本」的规则——cron 触发的定时扩容，覆盖 80% 的常规场景）。进阶版：模型的预测——用历史数据训练预测模型（时序预测——简单 ARIMA 或 ML 模型），预测未来 30–60 分钟的流量、按预测值提前扩容。预测的精度管理：预测偏高（浪费资源但不影响体验）vs 预测偏低（体验受影响）——预测的误差容忍度按 SLA 的等级设定。预测性伸缩的收束：反应式伸缩（KPA）是保底，预测性扩容是提前量——两者的组合（预测为主、反应为辅）才能实现「尖峰无感」的伸缩体验。

弹性伸缩的检查清单

推理伸缩的上线前检查清单，六项确认：权重预热确认（目标节点的本地缓存是否已有模型权重——冷启动的消除前提）、KPA 的指标确认（并发指标的采集正确——不是 CPU 是并发请求数）、最低副本确认（暖副本的数量设置——不为零的最低副本）、扩容的时间预算（冷启动时间的实测——分钟级冷启动是否已压缩到可接受）、降级预案确认（尖峰超容量的降级路径——限流排队与模型降级）、容量的水位确认（当前容量与峰值流量的余量——30% 的冗余）。六项确认做完，弹性伸缩才算能上生产——伸缩的技术实现只是开始，上线的确认才是真正的保障。

小结

推理服务伸缩的三大难题（分钟级冷启动、显存硬约束、尖峰流量）各有对策：冷启动三板斧（权重本地化、快速加载、暖副本）、KPA 的按并发伸缩（推理的正确容量指标是排队深度而非 GPU 利用率）、运营三手段（预测性预热、错峰调度、降级预案）。推理伸缩的核心认知转换：从「加副本」到「管理并发与队列」——GPU 服务的伸缩器读的不是 CPU，是排队深度；扩的不是 pod，是显存里的会话容量。