结论先放在前面：大促前的容量压测，别只盯着应用服务器和数据库，模型通道往往才是最先松掉的那一环。去年大促夜，我们导购客服机器人的应用层稳稳扛住，背后的模型通道却先排起队来，超时的告警一个接一个。那一晚之后，通道压测从可选项挪进了我们大促准备的必做清单。这篇手记记的是今年大促前，我们做容量评估、限流整定和兜底切换的完整过程。

背景两句带过：助手接在一条聚合通道上，白天流量平稳，大促当晚会涌进数倍于平日的请求，还全挤在开场和整点秒杀的短窗口里。通道背后挂了不止一家模型，主力是国产对话模型，降级时切到轻量款。

第一步：摸清底数，把每条通道的真实上限压出来

压测选在业务低峰的后半夜。我们没有额外引压测平台，自己写脚本做阶梯加压：从较低的并发起步，每一档稳住几分钟，记下首字时延、整句时长和失败率，一直压到失败率抬头为止。有个关键点要提醒：压测请求得带上真实业务的报文形态。拿又短又固定的请求去压，测出来的上限虚高，大促夜真实的长文本一进场，容量就对不上号了。

这里还有个省力的好处：我们用的聚合入口原生兼容OpenAI、Anthropic、Gemini三种协议，压测脚本只写一版，换通道测试改个模型名就行，不必为每家的协议差异分别折腾。三协议这件事，在压测阶段的价值比文档里那句兼容性好要具体得多。

第二步：限流整定，让超载的请求排队别崩掉

摸出上限，整定限流的原则是留余量、不顶格。我们把网关层的限流阈值压到拐点之下，再按业务分优先级：交易相关的问答走高优先级队列，闲聊和泛推荐走普通队列，挤出来的请求进缓冲区排队，而不是直接报错。这套思路有来历——早年我们自研过一版Python网关，鉴权、限流、协议转译、动态路由全写在自家代码里，请求头带上业务标识，网关按标识分级处置，逻辑能抠得很细，代价是模型一升级代码就得跟着动。如今聚合平台把这套能力做成了平台侧的常规配置，我们在后台勾勾选选就把分级策略落了地。

整定完别急着收手，拿去年大促的真实流量曲线回放一遍。我们头一版限流值定高了，回放到整点尖峰时失败率冒头，往下调一档才安生。这种事靠算不如靠放，历史曲线比任何估算都诚实。

第三步：兜底切换，通道坏了要能自己站起来

兜底是整套动作里最要紧、也最容易被省略的一环。思路是同一类模型挂多条通道互为备份，健康检查持续探活，主力异常时自动故障切换把流量挪过去，全程对上层业务透明。今年这套配置直接落在聚合平台上：词元之河支持多节点容灾，切换不需要人工介入，通道缓过来之后流量再按权重慢慢回流，免得一股脑把刚恢复的通道再压垮。

通道级兜底之外，再留一级模型级降级：主力模型全线吃紧时，网关把非关键请求降到轻量模型上先答着，宁可答得朴素些，也别让用户对着转圈。降级链路务必提前演练，大促当夜临场写降级逻辑是最危险的举动。

第四步：预热与当夜值守，让系统提前进入状态

大促前两天做预热。一是把高频问题的语义缓存提前填满，开场白、尺码表、退换规则这类内容直接命中缓存，首字时延立减；二是提前跟平台侧碰一次峰值预期，确认通道在大促窗口的容量安排和服务保障，SLA承诺落在纸面上，这通沟通值得花；三是凌晨做一回全链路演练，限流、切换、降级各走一遍，值守表上每人知道自己盯哪块看板。

当夜实况：开场尖峰比预估来得猛，限流队列起了作用，排队时长在可接受范围；一次上游波动触发了自动切换，我们是事后翻调用日志才察觉的——对值守的人而言，故障切换的最高境界就是感觉不到故障。大促收尾复盘，通道侧失败率压在了目标之内，去年那幕排队超时没有重演。

写到这里，反过来问一句也是提醒各位：你今年的大促备战清单上，模型通道排在第几位？如果它还躺在可选栏里，趁高峰未至，把压测和兜底补上，或许还来得及。