刚开始做 AI 应用的时候，我图省事直接调某家官方接口，代码里到处是它的 SDK。两个月后就出问题了：限流、涨价，想换供应商得改一整个项目。后来我花了点时间在业务和上游之间加了一层轻量网关，把多家大模型聚在后面，才把这件事理顺。下面是我踩过的坑和最后落地的方案，准备接多模型的话可以直接照着走一遍。
为什么要先加一层网关
各家模型的接口风格完全不一样：鉴权头不一样，参数命名不一样，返回结构不一样，连错误码都是各说各话。流式输出更麻烦，事件名都要逐个对齐。如果每家单独写一套对接逻辑，代码里很快就是一堆 if-else，某个模型一涨价或者一限流，整个服务都得跟着改。
网关层做的事很朴素：业务只跟一种接口打交道，路由、重试、限流、记账都放在网关里。这样加模型、换渠道只改配置，业务代码不用动，也不用每次改规则就重新发版。
第一步：统一请求和响应
我用 OpenAI 兼容的 chat completions 格式做统一入口，因为团队里其他人已经用熟了。每家上游写一个 adapter，把请求参数和返回结果做映射。这一步看着简单，真正花时间的是细节：同一组采样参数在不同模型里的取值范围不同，流式响应的事件名也要逐个对齐。
适配层做完之后的好处是立刻能感觉到的 —— 业务层完全不用感知底层是谁，切换模型只是换一个配置项。
模型路由：按成本和难度分发
一开始我让用户自己选模型，后来发现大多数人根本不在乎用的是哪个，只在乎回答得好不好、贵不贵。于是改成按场景自动分发：
- 日常问答、闲聊、短文本处理，走便宜的轻量模型；
- 复杂推理、长文档处理，才路由到更强的模型；
- 长对话先做历史裁剪，只保留最近几轮和关键摘要，token 消耗马上降下来；
- 拿不准的请求，根据问题长度、关键词或历史表现决定走哪条路。
这套逻辑必须放在网关里，不能让业务代码去判断。实测下来账单会明显变好看，因为不再出现「不管什么问题都用顶配模型」的情况。
限流、熔断和重试
限流是所有接 API 的人都躲不开的。上游给的配额通常按分钟、按并发或者按 token 量算，业务一突增就是 429。我最初用固定窗口计数器，突发流量照样冲过去，后来换成令牌桶，按每个上游的速率限制单独配置，多余的请求排队或者转到备用通道。
熔断和 fallback 也要做。某家在高并发时段经常限流，主通道连续被限流几次之后，网关自动把请求转到备用模型。代价是回复质量会有一点波动，但可用率上来了。
重试要克制：只对幂等的请求重试，只在网络抖动和 5xx 时重试，避免重复扣费。另外流式响应要单独处理超时，加心跳检测，慢请求宁可尽快失败让用户换模型，也不要让连接一直挂着。
省钱的三个动作
- 语义缓存。很多请求其实是同一类问题，做一层带向量召回的缓存，命中就直接返回，不走上游。
- 对话裁剪。历史太长就先摘要再送，token 消耗能降一截。
- 记账复盘。每个请求记录渠道、模型、token 消耗、耗时和成本估算，结构化落库。月底一查就知道哪家便宜、哪家该换。这件事不做，连账都算不清。
自己写，还是直接用聚合平台
| 维度 | 自建网关 | 用现成聚合平台 |
|---|---|---|
| 初期投入 | 适配层加路由、限流，通常要按周算 | 拿到 Key 改 Base URL 就能跑 |
| 可控性 | 策略完全自己定 | 策略由平台提供，可调空间小一些 |
| 维护成本 | 上游改版本、加新模型都要自己跟 | 上游变化由平台消化 |
| 适合谁 | 有明确路由/合规诉求、愿意长期投入的团队 | 核心在产品本身、不想在接入上耗精力的开发者 |
我自己是混合用的：核心链路保留自研网关的一部分策略，另外一部分流量直接走聚合平台。像 寓守API（Base URL 配 https://api.yushou.xyz/v1）就是把主流模型聚在一个入口、一个 Key 调用，负载均衡和限流统计都由它做。对工具型站点来说，把省下来的时间放在业务功能上，通常更划算。
FAQ
网关和聚合 API 平台是一回事吗？
不完全一样。自建网关是你自己维护的转发加策略层；聚合平台是把多家上游聚合好、对外提供统一接口。两者可以叠加：网关负责你的业务策略，聚合平台负责上游适配和可用性。
一定要用 OpenAI 兼容格式做统一入口吗？
不一定，但它最省事。生态里的客户端、SDK 大都支持这种格式，接进来不用额外写代码。如果业务里 Anthropic 那种 Messages 结构用得更多，也可以做双入口，代价是适配层要多写一点。
限流应该放在网关还是业务里？
放网关。业务层一旦感知上游配额，规则一变就得改代码发版。放在网关，改配置就能生效。
只重试是不是就够了？
不够。重试只解决偶发抖动，上游持续限流必须靠熔断加备用通道，否则重试只是把 429 放大一遍。
成本怎么才能看得见？
每个请求都记录模型、token 和渠道，按天或按月做汇总。没有这层记账，优化成本基本是凭感觉。
多模型接入这事，难点不在调用本身，而在上游那一堆不一致和不确定性。网关的价值不是看起来技术炫，而是帮你兜住这些变化；如果连这层都不想维护，用现成的聚合方案也完全说得过去。先想清楚自己的核心是模型调用还是产品要解决的业务问题，再决定要不要造这个轮子。
同一个主题的其它指南
寓守API：一个 Key 调用 Claude / GPT / Gemini