弹性调度：推理算力如何应对业务波峰波谷

弹性调度解决的核心问题是"按峰值配置"与"按均值负载"之间的结构性错配：推理负载天然带有昼夜节律与脉冲尖峰，静态配置要么在低谷期大量闲置，要么在高峰期击穿容量。成熟的弹性调度把算力供给拆成卡内切分、实例内并发、横向伸缩、资源池扩缩四个可调节层次，可将扩容响应从分钟级压缩到秒级。本文逐层拆解其机制与成本账。

波峰波谷：推理负载的结构性特征

推理负载的波动不是随机噪声，而是可预测的结构化曲线。客服与对话类应用呈昼夜节律：工作日9至12点、14至18点为高峰，凌晨跌入谷底，峰谷比普遍在3比1以上；内容生成类应用受工作周期驱动，周一与月末出现尖峰；电商客服则叠加促销脉冲，大促时段的瞬时请求量可达日均的5倍甚至更高（峰谷比因行业与活动节奏差异较大，此处为常见场景的经验区间，企业应以自身监控数据为准）。

推理负载与传统Web负载的关键差异在于资源粒度：一个Web请求消耗的是毫秒级CPU时间，而一个推理请求要独占GPU显存中的模型权重与KV Cache空间，扩容的基本单元是"整卡"而非"线程"。粒度越粗，弹性调度的设计越重要——扩容慢一步，高峰期就会出现排队与超时；缩容快一步，低谷期就能省下真金白银。

负载的可预测性是弹性调度的前提。昼夜节律型负载适合基于时间表的预扩容，脉冲型负载依赖队列深度的实时触发，两者的调度策略截然不同，混用会导致要么扩容滞后、要么资源空转。

弹性调度的四个技术层次

实例内并发是成本效益比高的一层。连续批处理技术让推理引擎把不同请求的解码步骤合并到同一次GPU计算中：据vLLM团队官方技术博客（2023年），相比静态批处理，吞吐可提升至24倍。这意味着同一张卡在延迟不超标的前提下能同时服务数十个请求，大量"软扩容"在引擎层就完成了。

横向伸缩是昼夜峰谷的主力机制。Kubernetes HPA按GPU利用率指标扩缩，KEDA则支持按请求队列深度、外部指标等更贴近业务的信号触发。实践中的关键参数是扩缩阈值与冷却时间：扩容阈值设得过低会频繁抖动，过高则高峰已至而容量未到位；冷却时间过短会导致缩容震荡。

资源池扩缩应对的是脉冲流量。竞价实例（Spot Instance）是这一层的成本杠杆：公有云文档显示，竞价实例价格通常为按量付费的10%至50%（据阿里云等公有云平台文档，2025年），代价是可能被回收——适合与预热池配合，承担可中断的弹性部分。

冷启动与预热池工程

弹性调度的工程难点不在"扩"，而在"扩得快"。一个新推理实例从零到可服务，要经过调度分配、镜像拉取、模型权重加载、引擎预热四个环节。以70B级FP16模型为例，仅权重就约140GB，在3.35TB/s显存带宽的H100上加载约需40余秒，叠加镜像拉取与算子预热，冷启动耗时普遍在分钟级。

预热池（Warm Pool）是应对冷启动的标准工程方案：提前保留一批已加载模型、处于待机状态的实例，流量到来时直接接管请求，把扩容响应从分钟级压缩到秒级（据CSDN云原生AI推理工程实践文章，2026年）。其本质是用少量闲置成本交换响应确定性——预热池的规模设定，取决于业务对"高峰首分钟体验"的容忍度。

折中方案是分级预热：核心模型保留常驻预热实例，长尾模型允许冷启动；或者用轻量模型在扩容窗口内兜底，为重模型预热争取时间。冷启动时间的长短还与模型存储位置有关——权重放在本地高速盘或共享缓存，比每次从对象存储拉取快一个量级。

弹性调度的成本账：削峰填谷如何改变TCO

以一个峰谷比3比1的客服场景为例做透明测算。假设：日均负载需要8卡产能，高峰4小时需要24卡，其余20小时维持8卡。

测算假设扩容在高峰到来前完成、缩容无延迟，实际会因冷启动与冷却时间打折扣，但数量级结论不变：峰谷比越大，弹性调度的成本收益越显著。当峰谷比接近1比1（负载平稳）时，弹性收益趋近于零，此时应转向提升实例内并发与卡内利用率。

对中小企业而言，这套工程体系的现实意义在于：如果直接使用Token API，上述调度全部由供给方内化，企业面对的是"按Token付费、峰谷无感"的结果；只有自建或长租GPU时，才需要自己搭建预热池与伸缩策略。MELFOR明晟云服的推理算力服务将弹性调度内置于平台层，企业按实际消耗获取算力，无需为峰值预留硬件预算；明晟云服的算力服务线支持按业务量动态扩缩，波峰波谷的成本差异由平台调度消化。