当团队的 API Key 散落一地：New API 是怎么当那个「中间人」的

• 开源 LLM 网关
• 基于 One API 二次开发
• 多协议互转
• 密钥与额度管理
• 私有化部署
• Go 语言构建

一句话认识它：New API 是一个开源的 AI 大模型接口管理与分发系统，项目明确基于 One API 二次开发，定位为一层可私有部署的「AI 网关 / 资产中台」：管理员把合法取得的上游凭据配置成渠道，系统再把它们统一封装为 OpenAI 兼容（并支持 Claude、Gemini 兼容）格式对外服务，让调用方用同一套代码切换底层模型，无需为每家上游单独维护密钥、限流与计费逻辑。

下面这段对话，是我们在帮一个三人小团队接入多模型时反复讲过的内容。把它当成一份「白话版说明书」，你能更快判断自己到底需不需要它。

我直接用各家官方 SDK 不行吗？为什么非要在中间塞一个 New API？

能用，但代价是「碎片化」。OpenAI、Anthropic、Google 的鉴权方式、请求体、模型名、限流与计费口径都不一样。业务代码一旦直接绑定每一家上游，想换模型、做容灾、核算成本都会越来越复杂。New API 把这一切收拢成同一个 OpenAI 兼容入口，你的应用只记一套网关地址和一个令牌，模型怎么换、上游怎么变，全在管理端控制。换句话说，它卖的不是模型能力，而是「统一接入与治理」。

那它和 One API 是什么关系？我直接上 One API 不就完了？

New API 是 One API 的「实质重写与增强版」。两者同源，但 New API 在后面补了大量原版缺失的东西：更现代的 Web 管理界面、更丰富的模型覆盖、内置用户与计费、模型路由策略、跨格式协议转换，以及可视化看板。如果你只需要最基础的转发，One API 也能跑；但一旦涉及多用户、配额、付费与运维看板，New API 的完成度明显更高。

「多协议互转」到底转的是什么？我的代码要改吗？

转的是请求与响应体的格式。Claude 的 Messages 格式、Gemini 的原生 schema、Azure 的变体，在网关处被自动翻译成 OpenAI 兼容结构，你的业务代码只写 OpenAI 风格的调用，New API 再去适配各家原生协议。它还适配了 OpenAI Responses、Realtime 实时语音、Rerank 重排序、图像与音频等多种任务类型。对调用方而言，无论底层是 GPT、Claude 还是 DeepSeek，统一都是 OpenAI 格式的接口，切换模型往往只改一个 model 参数名。

密钥和额度是怎么管的？我给同事开子账号会不会乱套？

这是 New API 相对纯转发工具最核心的增值层。上游的真实 Key 只存在管理端数据库里，对外分发的则是按用户自动生成的令牌。你可以为每个用户设每日/每月调用限额、限定可用模型列表、做令牌分组，甚至按 Token 或按请求计费。这种「上游 Key 收口 + 下游令牌分发」的二层结构，既避免把主密钥直接散给每个人，也方便你对自己的用户做成本核算与转售。

如果某家上游宕机或者触限流，会直接报错给用户吗？

不会直接挂。New API 支持渠道加权随机、优先级路由与故障转移：当某个渠道报错或超时时，请求会自动切到下一个可用渠道，对调用方表现为「无感切换」。你还能配置重试次数、缓存（Redis 或内存）来进一步稳定服务质量。这也是它被称为「为生产负载做冗余」的原因。

部署麻烦吗？我一个不想碰 Kubernetes 的人能跑起来吗？

官方推荐 Docker Compose，三条命令就能起来；也提供单条 docker run 用 SQLite 跑（注意把 /data 挂到宿主机做持久化）。生产环境可换 MySQL（≥5.7.8）或 PostgreSQL（≥9.6）。多机部署时务必设置 SESSION_SECRET 与 CRYPTO_SECRET 环境变量，否则登录态与 Redis 缓存会出问题。整体门槛对会一点服务器的个人开发者很友好。

把「网关 + 资产中台」这件事拆开，New API 真正能落地的能力大致是下面这八块。不必全用，按团队阶段取需要的即可。

选型时最常拿来比的就是这三个。下面这张表把关键差异摆清楚——注意它们解决的是不同层级的问题，并非完全替代关系。