new-api：自托管AI网关深度评测

new-api 是一个统一的 AI 模型网关，用于聚合和分发 LLM，将不同提供商跨转换为 OpenAI、Claude 或 Gemini 兼容 API。

在 saas.pet 后端将其作为模型路由器运行了 21 天，以下是关于通道管理、token 计费和 AGPL 许可证权衡的真实经历。

new-api 实际上是什么

new-api 是一个用 Go 编写的自托管 AI 模型网关。它聚合模型提供商——DeepSeek、GLM、Qwen、OpenAI、Claude、Gemini、MiniMax，以及任何有 API 的提供商——然后通过 OpenAI 兼容、Claude 兼容和 Gemini 兼容的端点重新暴露它们。你的应用代码从不直接与提供商通信。它只与 new-api 通信，而 new-api 根据通道优先级、模型可用性和回退规则将请求路由到正确的上游。该项目由 Qwen 开源模型的团队 QuantumNous 维护，它是事实上的 one-api 继任者——后者已停止积极开发。截至 2026 年 8 月，它拥有 45,733 颗星，采用 AGPL-3.0 许可证，最新版本是 2026-08-18 的 v1.0.0-rc.25。它仍在发布候选版本，这表明 API 表面正在稳定但尚未冻结。功能集包括通道管理、每通道速率限制、基于 token 的用户计费系统、带成本核算的使用日志、每通道模型列表过滤，以及中英文 Web 仪表板。

我为什么运行它：一个统一的基础 URL

saas.pet 的后端为不同任务调用多个模型：MiniMax 用于搜索 API，DeepSeek 用于内容生成，还有一些其他模型用于特定功能。在 new-api 之前，每个服务都有自己的提供商 SDK、自己的 API 密钥和自己的错误处理，当提供商中断时，我只能修改环境变量并重新部署。使用 new-api 后，每个服务都指向一个带有一个密钥的基础 URL。路由层决定哪个上游实际处理请求。添加提供商只需在仪表板上填写表单，无需修改代码。上周 MiniMax API 出现故障时，我才真正理解了它的价值：搜索端点持续返回 5xx 错误，但由于我已将 DeepSeek 配置为同一模型别名的回退通道，new-api 自动进行了故障转移。我在事后查看使用日志时才发现这个问题，而不是被报警叫醒。这一事件足以证明这次迁移的价值。

通道管理与模型别名

new-api 的核心工作流程是通道和模型别名。一个通道是一个上游提供商，配有一个或多个 API 密钥。模型别名将逻辑模型名称（如 gpt-4o 或 deepseek-chat）映射到一个或多个通道。当请求到达时，new-api 按优先级选择通道，如果配置了测试则先测试，失败时则回退到下一个通道。这就是聚合价值的所在。我为 DeepSeek 运行两个通道（主密钥和备用密钥），为 MiniMax 运行一个通道。仪表板显示每个通道的延迟、错误率和 token 使用量——这是当提供商直接从应用代码调用时永远无法获得的可视性。模型列表功能允许你隐藏不想暴露的上游模型，如果你向其他人提供网关，这很重要。速率限制是按通道和按 token 设定的，我设置为测试脚本中的失控循环无法在一小时内消耗一个月的配额。

Token 计费与用户系统

new-api 提供完整的 token 和用户系统：创建用户、发放 API token、设置配额和过期时间，以及按 token 按模型追踪支出。这是聚合和分发的分发部分，也是 new-api（而非 LiteLLM）在中国开发者生态中成为流行选择的原因。许多部署用它来内部转售 API 访问或向团队转售，并强制执行配额。我用的是更轻量的版本：每个服务一个独立的 token，搜索服务有自己的配额，内容生成服务有自己的配额，仪表板一目了然地显示每个服务的每月支出。账目以 token 和美元计算，换算率可按模型配置。作为个人运营者，用户系统对我来说超出需求，但按 token 的配额和日志恰好适合控制模型成本。如果你曾收到过意外的提供商账单，仅这一点就足以证明这套设置的必要性。

与 one-api、LiteLLM 和云网关的比较

与其前身 one-api 相比，new-api 绝对更好：相同的架构、积极维护、更多提供商、更好的仪表板，社区已经迁移过来。留在 one-api 的唯一原因是如果你有一个深度定制的分支。与 LiteLLM 相比，比较的关键在于受众。LiteLLM 是一个 Python 库和代理，面向需要细粒度控制和大提供商目录的开发者；它很出色，但配置即代码，开箱即没有计费或用户系统。new-api 是一个带有 Web 仪表板、配额和用户的应用。如果你是生活在配置文件中的开发者，LiteLLM 感觉很自然。如果你想要一个带有账务功能的自包含网关，new-api 胜出。与 Vercel AI Gateway（云选项）相比，new-api 在数据控制和成本上胜出，它可以免费自托管，缺点是零维护。对于 VPS 上的个人项目，自托管 new-api 是正确的选择。

部署与维护成本

new-api 是一个单一的 Go 二进制文件加一个数据库。我在与其他服务相同的 VPS 上使用 SQLite 运行它，没有使用 Docker，尽管提供了 Docker 镜像。二进制文件约 60MB，内存使用约 150MB，启动是即时的。升级是下载新的二进制文件，重启服务，完成，仪表板显示当前版本并可一键检查更新。在我使用的三周里，版本升级时的数据库迁移很顺利，包括 RC 版本的跳跃。主要的运营成本是关注 GitHub releases 页面以获取 RC 更新，因为该项目处于 1.0 之前的阶段。我锁定版本并在升级前阅读更新日志。每月总维护时间：不到一小时。你花时间的地方是 Web 仪表板：检查通道健康状况、审查使用情况，偶尔在密钥轮换时重新添加提供商密钥。

AGPL-3.0 许可证是真正的限制

new-api 采用 AGPL-3.0，这是你在采用之前而不是之后需要做的决定。AGPL 是强大的著佐权许可证：如果你修改代码并将其作为网络服务运行，你必须按照 AGPL 发布你的修改。对于 saas.pet，以未修改的形式将 new-api 作为单独服务运行不会感染我的代码库，网关是一个独立的组件，通过 HTTP 与我的后端通信。这是标准解释，适合我的用例。不可行的是：将 new-api 的代码嵌入闭源商业产品，或在修改后的分支上构建专有的转售平台。如果你的计划是其中之一，请查看 MIT 许可的替代方案或商业路线。实用的建议：将 new-api 保持为单独的进程，不要 fork 它，许可证就不是问题。我也在每次升级时检查许可证文件，因为项目许可证有被更改的情况。

局限性与最终评判

诚实的局限性：1.0 之前的发布候选版本意味着偶尔会有破坏性变更，文档假设你知道 one-api 的历史，UI 以中文为主英文为辅，高级路由策略（如成本感知路由或基于延迟的负载均衡）不如云网关丰富。模型目录取决于社区贡献的提供商，因此一个不知名的提供商可能需要手动配置通道。谁应该跳过 new-api：如果你只从一个提供商调用一个模型，网关就是纯开销。如果你需要企业级路由并且可以接受供应商锁定，请使用云网关。对于在生产环境中运行两个或更多模型的人来说，聚合、故障转移和计费可见性在第一次中断或第一张意外账单时就收回成本。我给它打 4 分（满分 5 分），扣掉的一点是 1.0 之前的粗糙性。当它发布 1.0 稳定版时，这就是 5 分。

• 每个提供商一个 OpenAI 兼容端点，应用代码中零提供商 SDK
• 自动通道故障转移，在真实的 MiniMax 中断中得到验证
• 仪表板中的按 token 配额、使用日志和成本核算
• 单个 Go 二进制文件，约 150MB 内存，升级只是二进制文件替换
• 活跃维护：每周发布，45k 星
• 支持 OpenAI、Claude 和 Gemini 兼容的响应格式
• AGPL-3.0 著佐权：不可嵌入闭源商业产品
• 1.0 之前的发布候选版本，可能有破坏性变更
• UI 以中文为主，英文翻译不完整
• 高级路由策略比云网关更薄
• 文档假设你了解 one-api 的历史
• 如果你使用单一提供商的单一模型，则过于复杂

本评测最初发布在 saas.pet——我用用自己的钱测试 AI 工具，写的都是真正有效的东西。