上个月跟一个做智能客服的团队聊，他们有 8 个开发，接了三家大模型：一家做主力推理，一家做备用，一家专门跑长文本。听起来很稳健，实际上运维已经快崩了。
他们遇到的问题很典型：三家接口格式不同，每加一个功能要改三遍代码；某家突然限流，备用切换要人工介入；月底账单出来，说不清哪个业务线烧了多少钱；某家悄悄下线了一个模型版本，线上服务报错两小时才发现。
第一笔债：接口不统一
OpenAI 是 messages 结构，Claude 一套，国内几家各有各的参数命名。看似都是“发 prompt 收回复”，一旦要做流式输出、函数调用、多模态，差异会放大到每个功能都要写分支。
常见的应对是写一层薄封装。但薄封装很快变厚——参数映射、错误码映射、重试、超时、并发控制。半年后这层封装变成没人敢动的黑盒，新人看不懂，老手不敢改。
第二笔债：限流和降级各自为政
每家供应商的限流规则都不一样。有的按 RPM（每分钟请求数），有的按 TPM（每分钟 token 数），有的两者都算，还有的按组织维度叠加。你在 A 家做了令牌桶，B 家的规则又不适用。
更麻烦的是降级判断。什么时候该切备用？是连续失败三次，还是错误率超过 5%？切换后什么时候切回来？这些策略如果散落在业务代码里，每个业务线都会长出自己的版本。
第三笔债：Token 成本算不清
这是最容易被低估的一笔。一次对话请求，输入 token、输出 token、缓存命中、不同模型的单价都不一样。如果账单只按”调用次数”统计，你永远不知道钱花在哪。
见过一个团队，把客服问答和文档摘要都路由到同一个模型，后来发现文档摘要这类长文本任务占了 70% 的成本，而它对模型能力的要求其实不高。换成便宜模型后成本降到三分之一，效果几乎没变。但前提是——你得先看得见这笔钱是怎么花的。
第四笔债：版本变更没有预警
模型供应商下线旧版本、调整默认参数、修改上下文长度，通常只发一封邮件或公告。代码里硬编码模型名，这些变更就是线上事故。
解法是不要硬编码模型标识，而是在网关层做一层”能力标签”——业务代码只声明”我需要一个支持 32K 上下文、支持函数调用的模型”，由网关决定具体路由到哪个。这样供应商换版本时，改一处配置就行。
统一中转层该有的四个能力
如果上面这些你都中了，那需要的不是更多封装代码，是一个独立的中转层。它至少要能解决四件事：
- 协议统一：业务侧只对接一套接口，模型差异在网关内部消化
- 路由与降级：按能力标签选模型，失败自动切换，切换策略集中配置
- 用量可观测：按业务线、按模型、按任务类型拆分 token 消耗，能出账单
- 密钥隔离：真实 API Key 不下发到业务侧，避免泄露和滥用
这四件事自己写也能写出来，但要写扎实，通常是一个有经验的工程师两到三个月的活。而且写完还要持续跟进各家接口变更——这是个长期的维护成本，不是一次性投入。
自建还是买，看两条线
月调用量在十万次以下、只接一两家模型，自己写个薄封装就够了，没必要上中转层。
接了三家以上、或者调用量已经影响成本结构，就该认真考虑统一中转。这时候省下来的不只是开发时间，更是”账单能不能对上”这件事带来的决策依据。
判断是否有必要，有个简单的问题可以自问：如果明天主力模型涨价 50%，你能在一小时内把所有流量切到另一家吗？ 能，说明架构是健康的；不能，说明你的多模型只是个名义上的保险。
最后提醒一句，中转层不是万能药。它解决的是工程复杂度，不解决模型本身的幻觉和准确率问题。这两件事要分开对待，混在一起讨论，最后往往两个都做不好。