一、项目背景

我们负责的大模型推理平台，流量有明显的潮汐特征。白天是业务调用高峰，下午到晚上还有一波，深夜反而空闲，常被拿去做批量训练和评测。原架构为了"保险"，按历史峰值常驻了一堆 GPU 实例，结果白天勉强够用，凌晨利用率掉到不到一成，账单却一分不少地付。

老板问过一句很扎心的话：半夜那些卡在干嘛？在空转烧钱。我们尝试过手动调，但人哪盯得住这种分钟级的起伏，调慢了白天卡顿、调早了半夜闲置，最后还是回到常驻峰值。加卡也填不满坑，因为瓶颈不是卡不够，是潮汐没被利用起来。

二、落地场景

我们做的第一件事是历史流量时序分析。把过去三个月的调用量按分钟级采样，画出一周七天的典型曲线，果然是早九晚八双峰、深夜谷底，且周末略低于工作日。潮汐预测是第二段，用周期性分解加近期趋势做短期预测，提前感知接下来的峰谷，而不是等流量到了才反应。弹性扩缩容策略放第三段，预测到峰来临前若干分钟预先扩容，谷来临前逐步缩容，缩容走优雅 drain，把在途请求处理完再回收实例。容量缓冲兜底，永远预留一部分余量应对 prediction 偏差和突发，不做满打满算的极致压缩。

案例片段（已脱敏）： 潮汐预测与扩缩容策略配置片段（示意）：scaling:  predict_horizon: 15min  target_util: 0.7  buffer_ratio: 0.2  scale_up_lead: 10min  scale_down:    drain_timeout: 120s    min_instances: 2上线后实例平均利用率从约 18% 提升到约 65%，扩容时延（预测触发到就绪）约 8 分钟，突发承载余量约 30%，单位推理成本下降约 52%（数据均为脱敏示意值）。

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

第一个坑是扩缩容的提前量。最早的策略是"流量到了阈值才扩"，结果扩容要拉镜像、加载权重、预热，等实例真就绪，峰值已经过去或用户已被卡顿劝退。我们改成预测驱动，提前十分钟开始扩，等流量真上来，实例早 warmed up 在那儿等着。这一步是降本不降质的关键。

第二个难点是缩容不能硬砍。推理实例加载慢、代价高，缩容时直接 kill 会把在途请求搞挂，用户侧表现为随机失败。我们给每个实例加了 drain 状态，收到缩容信号先停止接新请求，把手上活干完再退出，超时强制回收。这里有个权衡，drain 时间太长浪费钱、太短伤请求，按平均请求时长加缓冲调到合适值。

第三个点是预测偏差的兜底。预测不可能百分百准，突发活动一来就打脸。我们设了容量缓冲和实时利用率双保险，缓冲扛小偏差，实时指标在预测失准时立刻触发应急扩容，两层叠加才敢把常驻实例压到这么低。

四、效果数据

实例平均利用率从约 18% 升到约 65%，扩容时延约 8 分钟，突发承载余量约 30%，单位推理成本下降约 52%。账单出来那个月，财务第一次主动来问我们做了什么。我们复盘时发现，利用率提升带来的不只是省钱，还有故障面缩小，常驻实例少了，需要维护的节点也少了，运维反而轻松。

我们还把缩容记录接进了容量规划，哪些时段长期低位、哪些日子有异常尖峰，沉淀成下个季度的资源采购依据，从被动烧钱变成主动规划。

我们后来把缩容记录接进了容量规划，哪些时段长期低位、哪些日子有异常尖峰，沉淀成下个季度的资源采购依据，从被动烧钱变成主动规划，采购申请第一次有了扎实的数据支撑。还有一块是多模型共享潮汐，不同模型的高峰其实不完全重叠，我们把几个模型的流量聚合看，错峰调度让整体利用率又提了一截，比单模型各自扩容划算。预测模型本身也要复盘，遇到大促这类历史没见过的形态会失准，我们加了活动日历作为输入特征，大促前手动标注预期峰值，预测曲线贴合度明显改善，突发那层缓冲也能相应调小，进一步省下成本，整体账单又降了一轮。

提一个容易被忽略的点，是缩容时的在途请求监控。我们一开始只盯扩容时延，缩容偶尔把长请求掐断，用户侧表现为偶发超时，排查时还以为是模型慢。后来把 drain 期间的请求完成率和失败率也接进大盘，缩容策略才真正可控。这类问题隐蔽，不到一定调用量看不出来，等量大了再查就晚了，建议一开始就把在途指标埋好，别等线上抖了才补。

五、可复用经验总结

推理降本先看潮汐，常驻峰值实例是最贵的懒办法，把流量预测和弹性扩缩做准，同样 SLA 下算力账单能砍掉一大块，不该靠人盯着调。扩容提前量这事我们踩过坑，等阈值触发再扩永远慢半拍，预测驱动才是正解。我后来觉得，缩容的 drain 设计比扩容更重要，扩慢了顶多卡顿，缩错了是直接掉请求、伤用户体验，优先级反而更高。容量缓冲别省，预测失准时它是你唯一的体面。说到底，弹性扩缩不是技术炫技，是把钱花在真正被需要的那几分钟上。