1. 问题域与设计目标
1.1 推理流量的非线性特征
推理服务的QPS并非均匀分布，在线业务常呈现“潮汐峰”与“毛刺峰”并存的状态。潮汐峰可预测（如每日固定时段），毛刺峰则源于外部回调或运营活动。若仅依赖历史均值设定伸缩阈值，要么过度预留资源，要么在峰值时触发慢速扩容，导致SLA受损。
1.2 传统HPA在推理场景的局限性
标准HPA基于Pod级指标（如CPU）进行扩缩，但推理Pod的性能瓶颈通常在于GPU显存带宽和算子计算量，CPU利用率与QPS无线性关系。更关键的是，扩容出的新Pod需要从存储拉取模型文件、加载至显存，这一过程耗时从数秒到数分钟不等。在流量陡升时，这种“先扩容后加载”的串行模式使得响应滞后。
1.3 模型热加载的现有方案痛点
部分系统支持模型动态加载，即Pod运行期间按需下载并缓存模型。但这类方案缺乏与上层伸缩控制器的协同——伸缩决策者不知道当前已有Pod内是否还有剩余显存可加载新模型，热加载模块也不知道外部QPS的变化趋势，两套逻辑各自为政，容易产生“扩容过多但模型未就绪”或“模型已加载但实例数不足”的错配。
1.4 设计目标
-
以真实QPS为唯一伸缩主指标，剔除CPU/内存干扰，并引入滑动窗口平滑毛刺。
-
将模型加载动作视为伸缩策略的一等公民，扩容时优先尝试在现有Pod中热加载模型副本，仅当全局显存碎片不足时才触发Pod级扩容。
-
实现模型切换的“无感”效果：上层业务请求不感知模型所在的Pod变化，路由层保持统一入口，加载期间请求排队或重试，加载完成后无缝接管。
-
控制闭环：伸缩动作完成后，反馈实际可达QPS上限，用于后续阈值的自适应校准。
2. 整体联动架构
架构分为三层：流量感知层、伸缩决策层、执行代理层。
-
流量感知层：部署于网关侧，统计每个模型服务ID的真实QPS，并计算最近60秒的P95分位数，作为伸缩输入。同时采集每个Pod的当前已加载模型列表、显存占用量、每个模型的实时推理时延。
-
伸缩决策层：包含两个协同控制器——HPA控制器（负责Pod数量）和模型加载控制器（负责每个Pod内的模型实例管理）。两者共享一个状态缓存，记录全局“模型—Pod”映射关系。决策周期固定（如30秒），但模型加载控制器可被QPS突变事件提前唤醒。
-
执行代理层：每个推理Pod内驻留一个代理进程，接收加载/卸载指令，执行模型从共享存储到GPU显存的加载操作，并上报加载进度与显存余量。
联动机制的关键在于：HPA控制器不再孤立计算期望副本数，而是先向模型加载控制器询问“若增加N个QPS容量，当前Pod集群通过热加载能否满足”。模型加载控制器基于全局显存碎片状态，返回“可新增模型实例数”。若该数值大于等于需求增量，则只触发加载动作，不扩容Pod；若小于需求增量，则计算差额，HPA据此增加Pod副本，同时在新Pod启动后由加载控制器自动分配待加载的模型。
3. HPA基于真实QPS的决策改进
3.1 QPS指标采集与归一化
每个Pod的推理服务暴露/metrics接口，输出当前QPS（过去5秒均值）。上层聚合器按模型维度汇总，并除以当前该模型的Pod副本数，得到单Pod平均QPS。为避免短时抖动，采用指数加权移动平均（EWMA）进行平滑。同时记录每个模型的“单Pod极限QPS”——即在该模型当前配置（批大小、精度）下，时延满足SLA时的最大吞吐。该极限值通过离线压测预先获得，并在运行时根据实际时延动态修正。
3.2 伸缩阈值与步长
设定目标QPS利用率 = 当前单Pod平均QPS / 单Pod极限QPS。当利用率超过80%持续两个决策周期，触发扩容；低于40%持续四个周期，触发缩容。扩容步长采用“缺口比例+1”策略，即期望新增的QPS容量 = （当前总QPS - 当前总容量）/ 单Pod极限QPS，向上取整。缩容则按当前冗余容量计算可回收的Pod数，但每次最多缩容一个，防止震荡。
3.3 与模型加载控制器的协商接口
HPA在计算出期望新增Pod数N后，并不直接执行，而是调用模型加载控制器的EvaluateCapacity(deltaQPS)接口。该接口返回两个值：hotLoadable（可通过热加载新增的QPS容量）和podRequired（仍需新增的Pod数）。HPA最终扩容数量 = podRequired，并附带一个建议列表，指明每个新Pod应优先加载哪些模型。
4. 模型无感热加载机制
4.1 内存与显存资源视图
每个Pod的代理进程维护一张“显存池”表，记录已加载模型所占显存、空闲连续块大小、以及可被卸载的冷模型（若该模型的QPS长时间为零）。加载控制器全局汇总所有Pod的显存碎片，采用最佳适应算法判断能否容纳新模型。若单个Pod碎片不足以加载，但多个Pod碎片总和足够，则触发模型迁移——将某些冷模型从碎片较多的Pod卸载，集中到少数Pod，腾出连续空间。
4.2 热加载流程（不中断业务）
-
代理收到加载指令后，从共享存储下载模型权重（使用RDMA或预分片加速）。
-
下载期间，该模型的所有新请求被路由至其他已有该模型的Pod（若有），或进入内存队列等待。
-
权重加载至GPU显存后，执行预热推理（使用若干假数据），确保算子编译完成。
-
预热结束，代理向路由层注册该模型的新路由条目，并设置一个短暂的“灰度”权重（逐步引入流量），避免瞬时负载冲击。
-
加载全程对客户端暴露同一服务端点，路由层通过内部标签区分模型就绪状态，从而实现“无感”。
4.3 卸载与模型淘汰
当整体QPS下降，HPA决定缩容时，先由加载控制器评估缩容后剩余Pod能否容纳当前所有活跃模型。若不能，则优先卸载QPS最低且无预测上升趋势的模型。卸载前确保该模型的全部请求已迁移到其他Pod或已拒绝（通过断路器）。卸载动作释放显存后，若某个Pod内无任何活跃模型，则该Pod可被回收，对应于HPA的缩容。
5. 联动闭环与自适应校准
5.1 反馈回路
每次伸缩动作完成后，系统记录实际达到的总QPS与时延变化。若扩容后时延未降至预期，说明“单Pod极限QPS”设定值偏高，触发下降修正；若扩容后资源闲置严重，则上调极限值。该修正值乘以一个保守系数（0.9），逐步逼近真实性能。
5.2 应急模式
当QPS在单决策周期内飙升超过200%时，放弃协商，直接触发“紧急扩容”——同时启动Pod扩容和已存Pod的热加载，取两者并集，待峰值过后再合并冗余。此模式牺牲一定资源利用率，确保可用性优先。
5.3 模型版本更新场景
新模型版本上线时，不立即替换旧版本，而是先以低QPS灰度加载新版本，观测其单Pod极限QPS。待收集足够数据后，将流量逐步切换，旧版本进入冷状态并最终卸载。整个切换过程由加载控制器协调，HPA根据新旧版本的总QPS统一决策资源总量，避免版本过渡期出现双重资源浪费。
6. 实践效果与权衡
在实际部署中，该联动架构显著缩短了突发流量下的响应时间。纯Pod扩容需要平均45秒（含镜像拉取、启动、模型加载），而热加载链路仅需8-12秒（下载+预热）。通过优先热加载，约60%的扩容需求无需新增Pod，极大降低了GPU碎片化程度。同时，基于真实QPS的阈值使得缩容更果断，闲置资源回收时间平均提前3分钟。
但该设计也引入一定复杂度：显存碎片整理可能带来短暂的模型迁移开销，需要设计合理的迁移窗口（如低峰期）。此外，多模型共享同一Pod时，推理时延相互影响，我们在代理层引入公平调度器，按模型优先级分配算力，并动态调整批大小，使极限QPS的标定更加可靠。
结语
将HPA从“资源视角”提升到“吞吐视角”，并与模型热加载融合，形成以真实QPS为驱动的伸缩闭环，是推理服务弹性能力走向成熟的关键一步。该架构的核心价值不在于单个组件的优化，而在于建立“流量—容量—加载”三者的实时对话机制，让伸缩决策既考虑宏观副本数，也考虑微观显存布局。未来，我们将进一步探索基于QPS预测的预热加载，以及多模型混合部署下的自动拓扑优化，使弹性伸缩真正成为推理系统的内生能力，而非外部附加工具。
