凌晨两点四十，监控告警群开始刷屏。我们给一家做跨境电商客服系统的团队做技术支撑，他们的智能客服API超时率从日常的0.3%一路飙到27%，持续了将近一个小时。用户侧的表现是：客服机器人半天不回话，坐席那边只能临时切回人工。
事后复盘，问题不在我们的代码，而在上游——单一模型厂商的推理集群在那个时段出现了区域性限流。我们所有请求都打在同一家上，没有任何退路。这篇文章把那次故障和后来的改造方案完整摊开讲，给正在做企业AI接入的同行参考。
单点依赖的三个坑，我们全踩了一遍
很多人以为接大模型API就是填个Key、发个HTTP请求。真到生产环境，坑集中在三处。
第一是限流。厂商的QPS配额是按账号维度给的，大促期间客服会话量翻三倍，配额瞬间打满，返回429。我们当时没做请求排队和退避，重试逻辑写得又太激进，反而放大了压力。
第二是超时。流式接口（SSE）一旦上游卡住，连接会长时间挂着不返回，客户端只能干等。我们那次故障里，有相当一部分请求不是失败，而是「假活着」——TCP连接还在，但一个token都没吐出来。
第三是协议差异。不同厂商在流式返回格式、结束标记、错误码定义上都不一样。GPT-4o API和Claude API的SSE事件结构不同，国产的通义千问API、DeepSeek API又各有各的字段。业务代码里如果直接对接多家，等于给自己埋了一堆if-else。
多模型路由方案：分级、降级、归一化、归集
故障之后我们做了一轮改造，核心思路是引入一层模型网关，把「调哪家模型」这件事从业务代码里抽出来。
请求分级是第一步。我们把请求按业务重要性分成三档：实时对话类（客服、坐席助手）要求P99延迟低于2秒；批量生成类（商品描述、邮件草稿）可以容忍分钟级；离线任务类（数据标注、报表摘要）完全异步。分级之后，路由策略才有依据。
故障自动降级是第二步。每个模型配置健康检查，连续失败或超时超过阈值就自动摘除，流量切到备用模型。我们设的阈值是滑动窗口内错误率超过5%触发，恢复探测间隔30秒。这里要提醒一句：降级不是无脑切，得看任务类型——客服场景切到能力相近的模型可以接受，但涉及复杂推理的任务，降级后要打标记，事后人工复核。
SSE协议归一化是第三步，也是最费功夫的。我们在网关层统一了流式输出格式，业务侧只认一种事件结构，底层对接哪家由网关翻译。这样换模型不用改业务代码。
用量归集是第四步。多模型调用之后，Token计费和用量统计必须统一口径，否则月底对账会疯。网关按租户、按模型、按任务类型三个维度归集，输出统一的账单。
我们后来把路由策略升级成了「按任务自动选最优模型」——简单问答走便宜的小模型，复杂推理走能力强的模型，代码生成走专门的模型。这套逻辑跑下来，整体调用成本降了，响应也更稳。这背后其实依赖算力侧的调度能力，绿色算力调度、GPU按需弹性这类机制，能让高峰期的推理资源不至于排队排到天荒地老。
关于路由策略的边界，说点实在的
不是所有团队都需要多模型多活。如果你每天调用量只有几万次、业务对延迟不敏感、预算也宽裕，那老老实实接一家、把重试和超时做好就够了，多活带来的复杂度反而拖累迭代速度。
多模型路由真正的价值场景是：调用量大到会被限流、业务对可用性有硬要求、或者需要在成本和质量之间做动态平衡。判断标准很简单——你的API超时率是否曾经影响到终端用户？如果是，那这层网关就值得建。
我们项目里也用过token8341大模型API聚合平台做多模型统一接入，一个Key就能调GPT-4o、Claude、Gemini、DeepSeek、通义、文心、豆包这些主流模型，兼容OpenAI SDK，改一行base_url就能切换。它解决的核心就是上面说的协议归一化和用量归集问题，省掉了自己维护多家SDK的麻烦。对于不想从零搭网关的团队，token8341这类AI API聚合方案是个可选项。
最后补一句：token8341大模型API聚合平台在国产模型覆盖上做得比较全，盘古、DeepSeek、通义、文心、豆包、星火都有，做信创合规的项目会省心一些。但工具终归是工具，路由策略怎么设计、降级阈值怎么定，还是得结合你自己的业务数据来调。那次凌晨故障教会我们最实在的一课是：可用性不是买来的，是一层层设计出来的。
作者：孙浩然
发布日期：2026年11月12日