一、项目背景

我们的推理服务跑在私有化 GPU 底座上，承接新普MALL衍生的智能客服、商品生图、智能核单等多类智能体请求。流量特征很典型：白天是咨询与下单高峰，夜里骤降；大促期间瞬时并发能冲到平时的数倍，且峰值出现的时间点并不固定——往往是运营临时放量、直播间引流带来的突发洪峰，难以靠提前排班预测。

早先我们靠人工盯监控、手动调副本数，也试过按固定时刻表做定时扩缩，但业务洪峰与排班完全对不齐。问题很直接：人工响应永远滞后于流量，高峰来时 GPU 被打满、请求排队超时，智能客服首响从几百毫秒劣化到数秒，会员体感明显下降；低谷时大量显存空转，算力成本白烧。我们也看过某头部云厂商的弹性方案，但它的扩缩容信号来自自身 PaaS 层，和我们自研的网关、私有底座是两个体系，信号对不齐就谈不上联动。于是我们决定打通"网关限流信号 → 底座弹性扩缩容"这条链路，让流量自己驱动算力，把扩容缩容从运维的救火动作变成系统的本能反应。

二、落地场景

核心场景是算力—流量联动闭环：AI 网关实时感知每个模型实例的并发、队列深度与限流触发情况，把这些信号作为"压力探针"，周期性地推给底座的调度器；底座据此决定是拉起新副本还是回收空闲副本。

具体串起来是三步：网关在接入层统计各路由的实时 QPS 与限流拒绝数；当某模型被限流或队列持续超阈值，网关向底座发出"扩容信号"；当某实例持续低水位，网关发出"缩容信号"。底座收到后结合冷却时间与成本约束执行动作。整个闭环不依赖人工拍脑袋，而是让一线流量数据直接驱动资源决策。

我们把这条链路落到了新普MALL 的三个核心智能体：智能客服要求低延迟、必须优先保；智能核单为批量异步、可容忍排队；商品生图为长任务、对成本最敏感。网关按路由优先级把压力信号加权后上报，底座在扩缩容时自然向高优路由倾斜，既保住了体验红线，又守住了算力预算。

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

限流信号采集是第一道坎。网关必须给出"可决策"的信号，而不是原始日志。我们在网关路由层内置了滑动窗口计数，按模型维度聚合 QPS、平均延迟、队列深度与限流拒绝率，归一化成 0–100 的压力指数，再通过内部事件总线推给底座。这里的关键是把多源指标融合成一个可比较的标量，否则底座无法在"延迟高但 QPS 低"和"QPS 高但延迟正常"之间做权衡，容易误判。

案例片段（已脱敏）：网关→底座的扩缩容信号配置片段——yaml scaling_signal:  source: gateway_route  window: 30s  metrics:    qps: weight 0.4    queue_depth: weight 0.3    reject_rate: weight 0.3  pressure_index: "0.4*qps_norm + 0.3*queue_norm + 0.3*reject_norm"  publish_to: base_scheduler/events

扩缩容决策与冷却是第二道坎。压力指数高不代表要立刻猛扩，抖动会触发副本来回摇摆，既浪费调度开销又引发请求重新路由。我们设了双阈值 + 冷却时间：只有压力指数连续两个窗口超过扩容阈值才扩容，且扩容后冷却 N 分钟不再触发；缩容则设更保守的阈值与更长冷却，避免刚回收又爆。冷却窗口的设置直接决定了系统的稳定度。

案例片段（已脱敏）：扩缩容阈值与冷却时间配置——yaml policy:  scale_up:    pressure_threshold: 75    sustained_windows: 2      # 连续 2 个窗口    step: 2                   # 每次 +2 副本    cooldown_sec: 300  scale_down:    pressure_threshold: 25    sustained_windows: 6      # 更保守    step: 1    cooldown_sec: 600

缩容安全（排空在跑请求）是第三道坎。直接杀副本会切断正在推理的长请求（商品生图尤其耗时，单张图推理可能持续数十秒）。底座在缩容前先把目标副本标记为"摘流"，网关不再向它派新请求，同时等待在跑请求自然结束或优雅超时后再回收，杜绝中断。我们还在副本上挂了活跃请求计数，回收动作必须等计数归零，从机制上消除了"半路杀进程"的事故。

成本约束是第四道坎。我们不追求瞬时打满 SLA，而是给底座设日算力预算上限，扩容在预算内优先保核心路由（智能客服），非核心路由（商品生图）在预算紧张时降级批处理。预算用尽且仍处高峰时，网关侧对低优路由启用排队而非无限扩，把成本红线守在调度层之外，避免弹性变成无底洞。

四、效果数据

以某零售集团大促周为观测窗口（示意值）：

整体看，扩缩容从"事后救火"变成"事前随动"，GPU 不再大段空转，SLA 反而更稳，夜间低谷的显存占用也明显回落。更关键的是，运维同学终于从"半夜起来手动拉副本"的状态里解放出来，把精力投入到更值得做的容量规划上。

五、可复用经验总结

第一，让流量信号驱动算力，而不是拍脑袋。把网关的一线压力数据作为决策源，闭环天然对齐真实业务负载，比任何人工经验曲线都准，也更能应对临时洪峰。

第二，阈值与冷却必须双保险。单阈值必然抖动，缩容要更保守、冷却更长，这是避免副本摇摆的关键，也是新手最容易踩的坑。

第三，缩容先摘流再回收。长推理请求被中途切断是线上事故，优雅排空是底线，务必在副本上做活跃请求计数兜底，机制上消灭"半路杀进程"。

第四，把成本约束显式写进策略。弹性不是无限扩，预算上限 + 路由优先级让资源用在刀刃上，避免弹性变成无底洞。

第五，可观测要先于自动化。我们在闭环上线前，先把压力指数、扩缩容事件、副本活跃请求数全部接入看板，任何一次扩缩容都能回溯原因，出了问题也方便定位是信号失真还是决策出错，这一步是信任这套自动系统的前提。