One API 与 New API 怎么选：从运维视角而非功能清单

先明确：这两个项目的父子关系

New API 是 One API 的 fork。这个事实决定了九成的选型逻辑：

• 数据库结构基本兼容：从 One API 迁到 New API 通常可以直接换镜像、挂同一个数据卷跑起来（生产环境务必先备份数据库文件）；
• 两者的渠道配置、令牌体系一脉相承，概念不需要重新学；
• New API 更新更频繁，跟上新模型、新协议的速度更快。

所以真正的问题不是「哪个功能多」，而是「哪个更适合你当前的维护能力」。

一、许可证：先看清边界再说别的

这一条最容易被忽略，但可能是最具决定性的一条。

• One API：MIT 许可证。商用和二次开发几乎不受限制。
• New API：AGPLv3。它的约束是：如果你把它作为对外服务提供给用户，并且修改了它的代码，那么你修改后的版本也要以 AGPL 开源。

对于自己内部用（团队内部网关、个人自用）完全没有影响。对于对外运营，如果你的商业模式依赖对网关代码的封闭修改，AGPL 就是一条硬边界。行业里有过相关争议，值得在做商业决策前先确认清楚。

二、协议转换：New API 的核心差异化

这是 New API 相对 One API 最实质的能力差异。

One API 的思路是统一到 OpenAI 格式：所有渠道都被规整成 OpenAI 兼容的请求和响应。做的转换主要是「各家 → OpenAI」。

New API 在这个基础上加了双向与多向转换：

• OpenAI ↔ Claude messages（既能用 OpenAI SDK 调 Claude 渠道，也能用 Anthropic 官方 SDK 直连）
• OpenAI → Gemini
• Gemini → OpenAI

这带来一个很实际的好处：你可以直接用 Anthropic 官方 SDK 或 Claude Code 这类客户端，把 base_url 指向自建网关，无需中间再垫一层转换。而 One API 的原生 Claude / Gemini 格式支持较弱，格式转换能力也有限。

同时 New API 还支持 OpenAI 的 Responses 接口、Realtime、Rerank、Midjourney、Suno 等形态 —— 这些是 2026 年新增接口形态，One API 的跟进速度明显慢。

三、部署与升级

两者都是 Go 写的单二进制 / Docker 一键部署，支持 SQLite（轻量）或 MySQL（生产）。

需要提醒的地方：

• One API 有「版本升级可能破坏数据库结构」的历史，升级前必须备份；
• New API 功能更重，资源占用略高，但升级流程相对规范；
• 两者都不解决网络问题：海外模型该走代理还是要走代理，网关本身不提供链路加速。

四、日常运维真正要花时间的地方

不管选哪个，真正消耗时间的不是安装，而是：

1. 渠道健康监控：某个上游挂了要能及时发现。One API 原生监控偏弱，New API 有 Prometheus / OpenTelemetry 相关能力。
2. 额度与倍率的维护：上游调价了，你得同步改；这些是纯手工活。
3. 账单对账：自己搭的网关没有第三方账单背书，用户（或同事）质疑用量时，你得能拿出日志。
4. 告警：余额不足、渠道失败率飙升要能主动告知你，而不是等你发现业务断了。

其中第 1、4 项，New API 的开箱能力明显更好。

五、结论：一个决策规则

从零开始 → 直接上 New API。 理由是迁移成本几乎为零（以后想换也容易），而协议转换、监控、UI、更新频率这些能力是你迟早会用到的。省下来的时间远超那点资源占用。

已经在用 One API 且运行稳定 → 不要为了新功能迁移。 除非你有明确的需求缺口（比如必须支持 Claude 原生协议、必须接 Midjourney）。半年稳定运行本身就是价值，为了几个 UI 组件冒迁移风险不划算。行业里比较务实的说法是：决定选哪个的，往往不是谁功能多，而是你团队里谁在维护。

对外运营且需要封闭修改 → 先确认 AGPL 的影响。 如果 AGPL 构成障碍，One API（MIT）是更安全的起点；或者改用 LiteLLM（自建代理，纯配置驱动）作为程序化网关，把商业逻辑放在自己的服务里。

附：LiteLLM 的位置

LiteLLM 是另一个常见选项，定位不同：Python 编写、纯 YAML 配置、没有可视化后台。它的优势是「可编程」—— 适合嵌入内部服务、CI 流水线、微服务架构；劣势是上手门槛高，非开发者难以维护。

一句话区分：要界面和多人管理选 New API；要嵌入代码和流水线选 LiteLLM。