一、项目背景

我们运维的这个模型服务平台，早期图省事，按历史峰值常驻了一堆副本，每张卡都占着显存。结果白天忙的时候也只用到六成，半夜更是掉到两成不到，算下来一大半显存是空转烧电。可一到业务做活动、流量突增，常驻的又顶不住，临时拉副本要好几分钟，那几分钟里请求要么排队要么超时，投诉就来了。

这个问题本质上是扩缩容靠人工拍脑袋，没有跟着真实负载走。我们决定在模型服务化层把弹性伸缩做起来，同时把夜里空出来的显存真正收回来复用，而不是让它们干躺着。底层是 vLLM 这类推理框架加自研的调度层。

二、落地场景

落地围绕三件事。按负载自动扩缩副本，我们盯队列深度和请求延迟两个信号，超过阈值就加副本，长时间低位就缩。空闲显存回收与重排，缩容释放出来的显存，调度层重新整理，把小模型能塞的塞进去，避免整张卡被一个半占的实例卡死。异构卡混部，不同精度的模型分到不同代次的卡上，贵的卡留给真需要的，便宜的卡跑轻量任务。

试点先在一个中等规模的推理集群上跑，十几张卡，跑三四个模型。真正费劲的是缩容时不能把正在跑的请求砍了，这块我们设计了优雅退场。

三、关键技术挑战与解决思路

第一个挑战是扩缩容的判定。单纯看 CPU 或显存利用率会误判，因为推理空闲时显存也占着。我们改用队列里等待的请求数和 P99 延迟做主信号，副本数按这两条反推，比看利用率准得多。

第二个是缩容不丢请求。直接杀进程正在生成的请求就废了。我们让副本进入 draining 状态，不再接新请求，把手上这批跑完再退出，配合网关侧把流量切走，缩容期间用户无感。

第三个是显存碎片。一张卡上几个实例各占一块，中间缝缝补补凑不出连续显存给新模型。我们做了周期性的碎片整理，低峰时把实例迁移重排，腾出连续空间，代价是一次短暂的重调度，放在深夜做影响最小。

案例片段（已脱敏）： 弹性伸缩配置片段（YAML 示意）：autoscale:  min_replicas: 2  max_replicas: 8  scale_up:   {queue_wait: 16, p99_ms: 800}  scale_down: {queue_wait: 2,  idle_min: 20}  drain_sec: 60监控日志一例：某日晚间 23:10 队列等待降至 2、空闲超 20 分钟，副本由 6 缩至 3，draining 60 秒内在途请求全部完成；次日 09:30 活动流量来袭，队列等待冲到 18，2 分钟内扩回 8，P99 未破 800 毫秒。

四、效果数据

集群跑了一个月弹性策略，我们算了笔账。GPU 平均利用率从约 22% 提到约 58%，主要是夜里不再空转，显存被小模型填上了。副本伸缩时效，扩容从原来人工十几分钟压到约两分钟，缩容是优雅退场平均不到一分钟。显存碎片率，整理前高峰能到约 35%，周期重排后压到约 12%。请求丢弃率，活动期间基本为零，因为扩容跟得上。

说实话利用率没到特别高，因为我们用的是保守阈值，宁可多留点余量也不敢把卡打满，毕竟推理偶发长请求会瞬时吃显存，留余量是怕 OOM。后续想再紧一点，得先把长请求隔离机制做扎实。

五、可复用经验总结

弹性伸缩别看利用率，推理服务显存常占着，看队列和延迟才靠谱，我们一开始盯显存吃了亏。缩容一定要 draining，正在生成的请求比省那点显存重要，砍进程是最蠢的省法。碎片要主动整理，不然卡看着有空位就是塞不进新模型，低峰做一次重排值回票价。阈值保守点没坏处，留余量防 OOM 比榨干每一兆显存稳妥，这是运维的老经验。

现在他们在把这套伸缩策略和网关限流信号联动，流量一涨网关先限一波尖峰，伸缩跟上，算力和流量终于能一起动。

附：弹性之外的人力账

伸缩策略上线后，最明显的变化是半夜不用有人盯着了。以前低峰怕资源浪费、高峰怕顶不住，运维轮班盯监控，现在策略自己调，人只在异常时介入。我们还在调度层加了预算保护，给每个模型设月度显存预算上限，超过就优先缩容低优任务，避免某个实验性模型把整池卡占满。异构混部也值得说，贵卡跑大模型、便宜卡跑小模型和测试，同样一沓账单，利用率上来了成本反而下去。不过弹性不是万能，遇到突发大流量，扩容再快也有分钟级延迟，这种尖峰我们交给网关先限流削峰，伸缩跟上，算力和流量终于能一起动，而不是各管各的。

缩容的优雅退场我们当时调了挺久，draining 时间定太短会强行打断长请求，定太长又释放慢省不着。最后按模型平均生成时长加缓冲来定，不同模型不同值。还有预算保护那块，我们和财务对过账，显存预算不是拍脑袋，是按卡时成本倒推的，超了就真金白银烧钱，所以这个上限老板很在意。异构混部初期我们犯过一个错，把延迟敏感的大模型也塞进便宜卡，首字明显变慢，后来严格按模型档位分卡，贵的卡只跑该跑的。调度这层，分清楚谁该上什么卡，比堆数量重要。