48,699 颗星、v1.0.0-rc.40：new-api 想把「跑多家大模型」这件事收拢成一个 OpenAI 接口

如果你同时开着 Claude、Gemini、DeepSeek 和几个国产模型的 API Key，多半已经体会过那种混乱：四套 SDK、四套计费口径、四套密钥轮换流程，前端代码里到处是 if provider == "anthropic"。new-api 这个项目想做的，就是把这条路重新收窄成一句话——”对外只暴露一个 OpenAI 兼容接口，剩下的路由、格式转换、计费、配额，全在网关里解决”。

它目前在 GitHub 上有 48,699 stars、11,699 forks，用 Go 写成，AGPL-3.0 协议，最新版本已经推进到 v1.0.0-rc.40。这不是新项目，但值得现在重新看，因为它的定位刚发生了一次比较明显的迁移。

它到底是什么，又明确不是什么

new-api 的前身是 songquanpeng/one-api（MIT 协议），由 QuantumNous 团队分叉后做了大规模重写。最关键的差别在 README 的自我描述里：现在它不再自称”Token 中转站”，而是 “a self-hosted AI gateway for applications, agents, and teams”（面向应用、Agent 与团队的自托管 AI 网关）。上游覆盖也扩了：OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、Vertex AI、DeepSeek、Qwen 等兼容服务。

边界必须说清楚：

• 它是网关和资产管理层，不生产模型，也不改变模型本身的能力。Claude 的 function calling schema 在转换成 OpenAI 格式后可能无法完美往返，官方 README 明确提醒”具体场景要先测再承诺”。
• 它不是开箱即用的商业服务。默认部署的 Web 控制台没有鉴权，你必须自己套反向代理加认证，或者启用内置用户系统。
• AGPL-3.0 带”网络条款”：如果你改了代码又把它作为网络服务对外提供，必须同协议开源。公司内部自用不受此约束；想做闭源套壳，就得换 MIT 的 LiteLLM 或联系官方买商业授权（support@quantumnous.com）。

它真正解决的问题

三个能力是它的招牌。

一是跨格式转换。 内部用 RelayKit 做 OpenAI Chat/Responses、Anthropic Messages、Gemini 四套文本协议之间的请求、响应、流式转换。业务代码只写 OpenAI 兼容调用，网关翻译成目标 provider 的原生 schema。官网文档列出的接口已经相当全：/v1/chat/completions、/v1/responses、/v1/messages、/v1beta/models/{model}:generateContent、Realtime WebSocket、以及 images/audio/embeddings/rerank。

二是路由与容错。 支持模型映射、渠道优先级与权重、失败重试、渠道亲和、多上游 Key。典型用法就是”Claude 限速就自动 fallback 到 Gemini”，或者把低优先级任务甩给便宜渠道。

三是把 AI 调用变成可运营的资产。 内置用户、分组、配额、订阅、用量日志、缓存计费、按表达式定价；权限粒度包括 API Key 限制、OAuth/OIDC、passkey、二次验证。非工程师（运维、财务）可以在 Web 控制台里管渠道、看审计日志、跑 playground，界面支持中英日法俄越等 8 种语言。

最新的一个动向值得注意：v1.0.0-rc.40 引入了任务插件（Task Plugins）机制，用 JavaScript 插件把图像、视频等异步任务 API 挂进网关——已经能吃 OpenAI Images 的 /v1/images/generations 与 /v1/images/edits，阿里云百炼万相、豆包 Seedream 也已接入。换句话说，它正在从”文本模型网关”往”多模态任务总线”延伸。

真实使用门槛

• 部署：官方推荐 Docker Compose，默认拉起 new-api + PostgreSQL + Redis 三件套。单机试玩用 SQLite 一条 docker run 就能起。
• 多机部署有硬要求：SESSION_SECRET 必须设置，否则登录状态会不一致；共享 Redis 时必须设 CRYPTO_SECRET，否则数据无法解密。
• 数据库：SQLite / MySQL ≥ 5.7.8 / PostgreSQL ≥ 9.6；日志可另接 ClickHouse。
• 运维责任在你：provider 的 API Key 存在网关数据库里，加密与访问控制由你自己负责。官方反复提醒”只从官方仓库和官方 Docker 镜像安装”，市面上存在 new-api-pro、newapi-enterprise 之类的非官方分叉。
• 合规：README 有醒目警告——若作为面向公众的生成式 AI 服务或 API 转售服务运营，须先完成备案、许可、内容安全、实名、日志留存、税务和上游授权等义务。

适合谁，不适合谁

适合：同时接 3 家以上模型、需要统一计费和配额的团队；要把”模型切换”对客户端透明化的产品；有私有化与审计合规要求的组织；想搭一个内部多模型分发控制台的运维。

不适合：只用一个模型、一个人用、且不想维护任何服务的场景——这时直接调官方 API 链路最短，或者用 LiteLLM 更轻。也不需要它来”解决哪个模型更好用”，它解决的是”怎么让所有模型都用得像同一个”。

下一步建议

1. 本地十分钟验证价值：git clone 仓库后 docker compose up -d，进 http://localhost:3000 走完初始化向导，加一个上游渠道，用 README 里的 curl /v1/responses 打一发，确认跨格式转换在你的实际模型上能跑通。
2. 先测边界场景：重点验证你依赖的 function calling、结构化输出、图片工具结果往返是否符合预期，别等到上线才发现协议转换有损。
3. 生产前把鉴权补齐：控制台套 HTTPS 反向代理 + 认证，设好 SESSION_SECRET/CRYPTO_SECRET，并规划好数据库备份。
4. 法务前置：如果要对外提供网络服务，先读清 AGPL-3.0 附加条款，评估是保持原样内部使用，还是切换许可方案。

参考资料：GitHub 仓库、官方文档、Docker 镜像、发行版列表、HelloGitHub 收录、One API 与 New API 对比（API7）、X-CMD 一键部署说明。