大促流量一来，推理集群崩了；流量低谷时，GPU 却常年空转烧钱。问题多半出在伸缩策略上：把无状态微服务那套"CPU 到 80% 就扩容"直接搬到 LLM 推理集群，结果要么浪费要么崩。根因是传统指标在推理场景下全部失真，本文拆解失真原因，给出以 KV Cache 状态为核心的前瞻式伸缩方案。
为什么 GPU 利用率不能用
显存指标恒定满格。 vLLM 启动时为避免频繁调用显存分配器，会把九成以上空闲显存一次性预分配成物理块池。监控里看到的显存占用永远是 95% 上下，传统水位告警完全失去区分度——这个数字反映的是引擎的设计，不是负载。
核心利用率与排队时延脱钩。 推理分两个阶段：首字计算阶段是矩阵乘法，短时间吃满算力；逐字解码阶段是访存密集型，要把模型权重和 KV Cache 反复读进片上缓存，核心利用率只有三到五成——但此刻显存带宽可能已经打满、请求正在排队，服务濒临超时。看利用率做决策，方向都是反的。
KV Cache 耗尽是断崖式的。 长上下文请求总量超过物理块承载上限时，引擎只能抢占：强停正在生成的序列，把缓存换出到内存甚至丢弃重算。几百毫秒内吞吐断崖下跌，尾延迟爆炸。
该看什么指标
三维特征向量：
- KV 物理块使用率与增长斜率。使用率本身有滞后性，关键是一阶导数——过去十五秒内使用率的增长速度。大批长文本请求注入时，斜率突破阈值就能在显存见顶前提前约三十秒发起扩容。
- 等待队列与换出数。
num_requests_waiting是因块不足在排队阻塞的请求数；num_requests_swapped是被换出到 CPU 内存的序列数。后者一旦大于 0，服务质量已实质降级，属于灾难前兆。 - 首字时延与字间时延的 SLA 偏离。P95 首字时延反映排队压力，P95 字间时延反映带宽竞争饱和度，相对基准的偏离百分比作为伸缩的动态惩罚项。
双轨扩容决策
模型冷启动极慢——七十亿级以上参数的权重加载、计算图编译、通信初始化要数分钟，被动式扩容来不及救火。控制器跑两条轨道：
- 快速响应轨：任一实例等待队列数大于 3 持续超过 5 秒，或 KV 使用率破 85% 且斜率持续为正，绕过一切平滑窗口立即紧急扩容。
- 预测响应轨：用时序模型预测未来三分钟请求到达率，结合历史平均 Prompt 长度，在虚拟空间推演 KV Cache 消耗曲线。推演显示两分钟后跨越 75% 警戒线，就提前调度预热实例。
架构上是常规组合：网关分发到带指标导出的推理 Pod，Prometheus 采集，控制器做预测与仿真，执行层用 KEDA 或自定义 HPA。
缩容比扩容更危险
错误缩容的代价是数分钟冷启动外加二次振荡扩容。三条防抖规则必须写死：
- 扩容动作后 10 分钟内禁止缩容；单次缩容不超过集群算力的 10%；每次缩容后强制 15 分钟静默期。
- 目标实例先在网关标记排空状态，停止分派新请求，等运行中序列全部生成完毕、缓存块归零，才允许销毁。直接发终止信号等于杀掉用户的半截回答。
- 缩容决策同样要过预测轨——低峰判断错了，下一波流量来了没有温热池可接。
落地验收清单
上线前逐项验证：显存指标在压测下是否恒定（证明预分配生效，排除它当伸缩依据）；制造一批长文本请求，确认斜率触发点早于等待队列出现；手动把 swapped 打成大于 0，验证告警链路；缩容演练确认排空逻辑完整、无中断的生成序列。算力账要算两头的——高峰扛住的 P95 时延，和低峰退让省下的 GPU 租赁成本，两者加起来才是这套方案的收益。
评论0