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 + 自定义前端，是经过验证的组合

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

维度	One API	New API	自建
上手时间	10分钟	10分钟	1-3天
渠道数量	50+	50+	自建多少有多少
用户管理	✅ 完整	✅ 完整	❌
定价系统	✅ 基础	✅ 阶梯	❌
调用日志	✅	✅	❌
熔断重试	✅	✅	自建
自定义UI	✅（可改前端）	✅（界面好看些）	✅（随便改）
社区支持	34.6k stars	活跃fork	靠自己
维护成本	低	低	高
灵活度	中	中	高