一、项目背景

我们的 AI 网关给各调用方分配固定配额，平时风平浪静。一到大促或者对方做活动，调用量翻倍，临时加配额手忙脚乱，网关被冲得抖动，别的调用方也跟着遭殃，群里同时炸好几拨人。平时配额又闲着，算力白费，财务看着利用率报表直皱眉。跨租户互相影响，谁都跑不顺，关键业务一度被长尾调用方拖慢。运营每次大促前都在群里喊"快加配额"，我们想把这个从救火变成自动，别再靠人盯着，人也盯不过来，半夜被叫起来加配额不是一次两次。我们算过一笔账，一年大促加零散活动加起来几十次，每次人工扩容平均半小时，运维半夜出勤的成本比多买的算力还贵，这事必须自动化。

二、落地场景

我们在网关的计量层加了配额预测。每个调用方按历史流量建曲线，结合活动日历，提前预判冲量时段。大促前自动弹性预扩配额，活动过后自动回收，不用人工点按钮。闲置的配额释放回公共池，供其他调用方突发借用，资源不浪费。超额的走熔断兜底，不该用的请求拦在门外，保护整体。整套预测和扩缩对调用方透明，他们只感觉大促不卡了，后台悄悄把事办了，接入方式没变，调用方无感，只知道大促稳了，连运维都不用上线盯着，值班的人只要看一眼看板确认数字正常。调用方后来把促销计划通过接口自动推给网关，不用运营手动填日历，预测因子实时更新，大促前的预扩更准。公共池的闲置配额我们加了借用记账，谁借了多少、什么时候还都有记录，月底能跟调用方算清账，扯皮少了。我们还给关键业务留了保底不回收标记，这类调用方的配额再闲也不进公共池，宁可空着也不冒险，业务方知道了心里踏实，大促期间从没再被共享配额拖慢过，这部分多花的算力在账单里单列，财务也认可。

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

配额预测精度是第一个难点。光看历史均值不够，我们叠了活动日历因子，对方有促销计划就提前抬曲线，预测才准。弹性预扩时机要准，扩太早浪费，扩太晚来不及，我们用预测置信区间触发，临近冲量窗口再动手，既不空等也不冒进。闲置回收不能太狠，刚收回又被借爆会抖动，我们设了回收冷却，给系统缓冲。超额兜底用熔断，但熔断误伤要低，按调用方维度而不是全局一刀切，不然一个调用方作死全平台跟着断。这里走过弯路，第一版预测偏保守，只吃历史均值，峰值还是被打满，后来把活动日历和对方历史冲量都喂进去才准，预测这种事数据越全越稳，少一个因子就少一分准头，我们还特地把对方的促销计划同步接口接进来而不是靠人填表。

案例片段（已脱敏）： 租户配额预测与弹性预扩配置（示意）： quota.forecast: true forecast.factors: [history, calendar] pre_expand.lead_min: 30 recycle.cooldown_min: 10 burst.limit_per_tenant: true 某大促日网关大促承载能力提升约 2.5 倍，平峰配额闲置率下降约四成，扩容从人工 30 分钟压到自动分钟级。

四、效果数据

我们主要看大促承载、配额闲置率、扩容时效和熔断误伤。大促承载能力提升约两倍半，峰值冲量接住了；平峰配额闲置率下降约四成，算力不再白闲，财务的利用率报表好看了；扩容时效从人工半小时压到自动分钟级，运营不用再半夜爬起来点按钮；熔断误伤维持在很低水平，没误伤正常业务。我们给调用方做了配额使用的周报，谁平时闲着、谁大促冲猛一目了然，运营拿着周报去跟调用方聊资源规划，从救火变成了顾问，关系也好了。财务那边最满意的是闲置率下降后，整体算力账单没涨反降，因为预扩只在大促窗口生效、平时该收就收，弹性真正落到了成本上，不是嘴上说说。

文中数据为项目复盘口径，实际值随活动规模波动，仅作趋势参考。运营最大的变化是大促前不用再在群里喊人，系统自己把配额涨上去了，人只要看一眼看板确认，彻底从救火变值班，过年大促也能踏实吃顿饭，不再担心半夜被电话叫醒。

五、可复用经验总结

网关配额不能拍脑袋给固定值，尤其大促这种可预期的冲量，预测加预扩比临时救火强太多，救火永远慢半拍还容易出错，人手也顶不住。预测别只信历史，活动日历这种外部因子很关键，我们就是吃了保守的亏才补上的，历史不会告诉你明天搞促销。闲置回收要留冷却，别刚收又借爆，系统也要喘口气，抖起来更费资源。我现在的判断是，配额弹性本质是把"平均"换成"按需"，做网关的人先把每个调用方的流量脾气摸清，再谈弹性，不然扩错了方向更糟，弹性不是无脑放大，是把算力放在对的时间给对的调用方。