One API vs New API vs 自建：AI 模型网关选型指南

一、为什么要用模型网关？

做 AI 应用开发的朋友，大概率遇到过这样的场景：

• 项目里调了 DeepSeek、通义千问、GLM 三家 API，代码里写了三套不同的鉴权和请求逻辑
• 团队要切换模型，得改代码、重新部署
• 某个渠道挂了，服务直接降级
• 月底对账，各平台账单格式不一样，一个个算

这些问题，一个**模型网关**就能解决。

市面上主流的方案有三条路：**One API**、**New API**、**自建网关**。这篇文章从实战角度做个横向对比，帮选型的朋友少走弯路。

所有观点来自真实生产环境的踩坑经验，不吹不黑。

二、One API

GitHub 34.6k stars 的开源项目，目前最流行的 AI API 网关方案。

核心优势

1. 开箱即用

下载二进制 → 启动 → 配渠道 → 上线。前后十几分钟的事。

渠道支持非常全：DeepSeek、OpenAI、Claude、通义千问、智谱GLM、百度文心、讯飞星火、豆包火山方舟、硅基流动、API2D 等 50+ 渠道。每家的鉴权、请求格式差异都已经封装好了，用户侧只需要一个 OpenAI 兼容接口。

2. 多模型路由

同样的模型可以配多个上游渠道，支持：

• **优先级路由**：哪个渠道先用
• **权重分发**：按比例分流，比如 DeepSeek 官方 70% + 硅基流动 30%
• **分组隔离**：不同用户群体走不同渠道

3. 完整的运营体系

• 用户管理（角色、配额、分组）
• Token 管理（额度、过期时间、限模型）
• 调用日志
• 自动重试和熔断
• Redis 缓存加速
• 自定义定价（ModelRatio）

不足之处

• 控制台 UI 风格比较朴素（但这可以用前端代码自定义）
• 渠道配置界面比较简略，大部分配置要直接改数据库
• 普通用户调不了 `/api/option/` 等管理 API，需要前端做 fallback 适配
• 各种渠道的 type 编号从 iota 0 开始，文档里没明确说明，配新渠道需要看源码

适用场景

• **个人开发者**：快速搭建，省时省力
• **小团队**：需要基本的用户管理和权限控制
• **想卖 API Key 的创业者**：这套运营体系就是为这个场景设计的

三、New API

One API 的一个活跃 Fork，在社区里也有不少用户。本质上是同源的，但有一些不同的取舍。

核心差异

1. 定价更灵活

One API 支持 ModelRatio 定价，New API 在此基础上加了阶梯定价、按量折扣等商业定价能力，对卖 API Key 的场景更友好。

2. 界面优化

部分 UI 做了改进，更现代化一些。

不足之处

• 因为是 Fork，One API 合并新特性后需要等一段时间才能同步过来
• 社区规模小一些
• 文档方面和 One API 类似

适用场景

• 对阶梯定价有刚需的场景
• 主要在海外市场

四、自建网关

部分大团队会选择自己写一个简单的网关层。一般就是在 API 前面加一个转发+鉴权的中间层，几十到几百行代码搞定。

为什么有人自建

1. 完全可控

想怎么改怎么改，没有框架约束。团队有 Go/Node.js 能力的话，搞个简单的反向代理层一天能搞定。

2. 极致精简

不需要用户管理、不需要计费、不需要日志——就一个透明转发。One API 那套太重了。

3. 性能可调

可以针对自己的业务场景定制缓存策略、重试逻辑、限流算法。

为什么不推荐自建

**踩过的坑：**

• **渠道适配工作量**：接第一个渠道半天，第二个半天，第三个半天……等你接到第10个渠道时，One API 已经把它 50+ 渠道的适配都帮你做好了
• **鉴权格式不统一**：DeepSeek 用 Bearer Token，通义千问用 API Key，GLM 用 API Secret——每个渠道的请求格式、错误处理都不一样。踩一个坑排查半天
• **缺乏降级策略**：渠道断连时怎么优雅降级？重试次数？熔断阈值？这些看似简单的逻辑，写起来全是细节
• **没有运营后台**：没有用户管理、没有调用记录、出了错只能看 Nginx 日志
• **成本控制缺失**：没有用量统计、没有配额限制、用户超量调用你只能月底对账才知道亏了

适用场景

• 团队有 2-3 个渠道且长期不变
• 不需要用户管理和计费
• 有足够的运维人力兜底

五、横向对比

六、我们的选择

我们自己的平台（api-aiapi.cn）最终选了 **One API + 自定义前端** 的方案。

原因很简单：

• 生产环境需要快速上线，One API 的开箱即用是最大优势

2. 自定义前端接管了控制台的品牌体验——改前端代码比改后端源码容易得多

3. 成本低——一台 2核2G 的轻量服务器就够了

七、一点踩坑记录

如果选了 One API，这几个坑可以先避开：

1. 渠道 type 编号从 0 开始

添加渠道时，type 值是 0、1、2 这样的数字，每种渠道有自己的编号。文档没明确列出来，建议直接看源码里的 channel_type.go 文件。

2. base_url 不要带 /v1

配渠道时 base_url 写 `https://api.deepseek.com` 就可以，不要加 `/v1`，One API 会自己拼接。

3. ability 表必须有记录

渠道配好之后，ability 表里要写入对应模型的能力记录，否则渠道不可用。

4. 定价是在 options 表的 JSON 字段里

ModelRatio 不在独立的 model_ratios 表里，而是存在 options 表的一个 JSON 字符串字段中。改价格直接更新这个 JSON 就行。

5. 控制台前端可以独立部署

One API 自己的前端和 API 是绑定在一套服务里的，但你可以把前端文件（console 目录）独立出来，Nginx 直出静态文件，API 走代理转发。这样前端可以自由定制，不会影响后端升级。

八、总结

• **一个人或者小团队想快速上线** → One API，十分钟搞定
• **需要阶梯定价，主要在海外** → New API
• **团队大、渠道少、有运维能力** → 可以考虑自建
• **想靠卖 API Key 做点副业** → One API + 自定义前端，是经过验证的组合

没有最好的方案，只有最合适的。