从 0.4.6.11.4 到 1.0.0，New-API 终于理清了自己的版本号
近日，开源多模型中转管理工具 New-API（QuantumNous/new-api）正式推出了 v1.0.0 版本。对于一个在 GitHub 上拥有超过 28,000 Star、232 位贡献者、累计发布了 481 个 Release 的项目来说，这个「1.0」来得不算早，但确实来得很有必要。
如果你自建过 AI API 网关，大概率听过甚至用过 New-API。它做的事情不复杂：把 OpenAI、Anthropic、Google、DeepSeek 等各家大模型的 API 统一封装成兼容 OpenAI 格式的接口，再加上渠道管理、Token 计费、负载均衡、用户权限这些运营层面的能力。简单说，就是一个自托管的模型中转网关。
但在 1.0 之前，这个项目的版本号堪称「行为艺术」。
版本号的混乱，是项目成长的代价
翻一下 New-API 的 Release 页面，你会看到一段相当魔幻的版本演进史：
- 早期是
v0.0.4、v0.0.5这样的常规小版本 - 中间跳到了
v0.9.x、v0.10.x，一路推进到v0.12.x、v0.13.x - 同时还存在
0.4.6.11.1、0.4.6.11.2、0.4.6.11.3、0.4.6.11.4这种四段式版本号 - 再加上
nightly-20260409这样的每日构建 - 最后是
0.1.0-alpha.1→v1.0.0-rc.1→v1.0.0-rc.2→v1.0.0的正式发布线
多条版本线并行，四段版本号和三段版本号混用——这在社区开源项目里不算罕见，但确实给使用者带来了困扰：到底该跟哪个版本？哪个是稳定的？升级会不会炸？
v1.0.0 的发布，本质上是在回答这些问题：我们现在有一条明确的主线了，语义化版本，正式维护。
v1.0.0 带来了什么
从 rc.1 到 rc.2 再到正式版，v1.0.0 的核心变化集中在几个方面：
新旧前端自由切换
v1.0.0-rc.2 开始正式支持在新版前端和经典前端之间自由切换。这不是一个花哨的功能，而是解决了一个实际痛点——New-API 重新设计了前端 UI，但很多老用户的工作流已经和旧界面深度绑定。直接砍掉旧前端太激进，同时维护两套又不现实。
现在的方案是让用户自己选：想试新 UI 就切过去，发现不顺手随时切回来。这种「渐进式迁移」的思路比强制升级友好得多。对于自建中转站的运营者来说，前端界面直接影响用户体验，能平滑过渡是刚需。
架构层面的稳定性承诺
1.0 版本号在开源社区有明确的含义：API 稳定，不会随意做破坏性变更。 这对 New-API 的用户群体尤其重要。
想想 New-API 的典型使用场景：你搭了一个中转站，下游可能挂着几十个用户、几个应用、若干自动化脚本。如果上游的 New-API 每次升级都可能改接口、改配置格式、改数据库结构，你根本不敢升级。而不升级又意味着拿不到新模型的支持、安全补丁。
1.0 就是在说：从现在开始，升级不会让你的系统炸掉。 至少在 1.x 的生命周期内，向后兼容是有保障的。
版本管理的正规化
从 Release 历史可以看出，项目团队在 1.0 之前做了一次版本线的整理：
0.1.0-alpha.1：新架构的首个预览v1.0.0-rc.1：候选版本，功能冻结v1.0.0-rc.2：修复 rc.1 的问题，开放前端切换v1.0.0：正式发布
这是一个标准的软件发布流程。对于一个之前版本号比较随意的项目来说，这本身就是成熟的信号。
New-API 在解决什么问题
如果你还没接触过 New-API，简单梳理一下它的定位。
大模型 API 的生态现在是碎片化的。OpenAI 用自己的格式，Anthropic 的 Messages API 又是另一套，Google Gemini 走的是 Google Cloud 的风格，国内的 DeepSeek、智谱、通义千问各有各的接口规范。如果你的应用需要调用多家模型——比如用 GPT-4o 做主力、Claude 做备份、DeepSeek 跑性价比场景——你就得在代码里适配多套 SDK，处理不同的鉴权方式、不同的请求格式、不同的错误码。
New-API 做的就是把这些差异抹平。它在中间加一层代理，对外统一暴露 OpenAI 兼容的接口，对内去适配各家的原生 API。你的应用只需要对接一个 endpoint，换模型只是改一个参数的事。
在此基础上，New-API 还提供了一整套运营能力：
- 渠道管理：配置多个上游 API 供应商，设置优先级和权重
- 负载均衡与故障转移：某个渠道挂了自动切到备用渠道
- Token 计费：按模型、按用户统计用量，支持额度控制
- 用户与权限：多用户管理，API Key 分发，适合团队或商业化场景
- 支付集成：支持对接支付系统，可以直接拿来做付费中转站
用一句话概括：New-API 是一个自托管的 AI API 网关 + 运营后台。
谁在用，怎么用
从 GitHub 的数据看，28.2k Star、5.9k Fork，这个体量在同类项目中属于头部。559 个 Open Issue 和 117 个 Pull Request 也说明社区活跃度不低。
典型的使用者大致分几类：
个人开发者：手上有多家 API Key，想统一管理，顺便做个用量统计。部署一个 New-API 实例，把所有 Key 配进去，自己用或者给朋友用。
中转站运营者：这是 New-API 最核心的用户群。国内访问海外 API 有网络障碍，中转站通过在海外部署节点来解决连通性问题，New-API 就是这类服务最常用的后端。v1.0.0 的稳定性承诺对这个群体意义最大——他们的用户是付费的，服务不能随便挂。
企业内部平台：一些公司内部搭建 AI 能力平台，用 New-API 做统一的模型网关，控制成本、管理权限、审计用量。
AI 应用开发团队：在开发阶段频繁切换模型做对比测试，New-API 的统一接口省去了反复改代码的麻烦。
部署方式也很直接，官方推荐 Docker Compose：
git clone https://github.com/QuantumNous/new-api.git
cd new-api
docker compose up -d
项目主要用 Go 写后端（占比 52.2%），JavaScript 写前端（占比 47.7%），技术栈比较主流，二次开发的门槛不高。
同类工具的竞争格局
New-API 并不是唯一的选择。在多模型中转这个赛道上，开源和商业方案都不少：
One-API：New-API 的上游项目，也是最早一批做这件事的开源工具。New-API 在 One-API 的基础上做了大量扩展，功能更丰富，但也更重。如果你只需要基础的中转能力，One-API 可能更轻量。
商业中转服务：比如 OpenAI Hub 这类平台，提供托管的多模型聚合服务，一个 Key 调所有主流模型，不需要自己部署和运维。对于不想折腾基础设施的开发者来说，这类服务省心得多。
LiteLLM：Python 生态的模型代理工具，侧重于代码层面的接口统一，和 New-API 这种独立部署的网关思路不同。
All API Hub：社区里出现的浏览器扩展，定位是管理多个 New-API 实例的「管理器」——余额看板、价格比对、自动签到。它的存在本身就说明 New-API 的生态已经大到需要专门的管理工具了。
New-API 的优势在于功能全面和社区庞大。劣势也很明显：自托管意味着你得自己搞定服务器、域名、SSL、数据库备份、版本升级这些运维工作。对于个人开发者来说，这些成本不低。
1.0 之后，值得关注什么
版本号到了 1.0，项目进入了一个新阶段。有几个方向值得关注：
新前端的成熟度。目前新旧前端并存，但长期来看旧前端一定会被淘汰。新前端的体验能不能让老用户满意，决定了这次 UI 重构的成败。
插件和扩展机制。随着大模型能力的快速迭代——多模态、Function Calling、长上下文、实时语音——中转层需要跟进的东西越来越多。如果每次都要改核心代码才能支持新特性，维护成本会越来越高。一个好的插件机制能让社区分担这个压力。
安全性。中转站本质上是一个代理服务，所有的 API Key 和请求内容都经过它。559 个 Open Issue 里有多少是安全相关的？项目的 Security Policy 执行得怎么样？这些问题在 1.0 之后会被更多人审视。
与上游 One-API 的关系。New-API fork 自 One-API，两个项目目前各自发展。随着 New-API 的架构在 1.0 中稳定下来，两个项目的差异会越来越大，合并的可能性也越来越小。这对用户来说意味着选择更明确了，但也意味着社区力量的分散。
一点看法
坦率地说，v1.0.0 的发布更多是一个「项目治理」层面的里程碑，而不是一个「功能爆炸」的大版本。它解决的核心问题是版本混乱和升级信心，而不是带来什么颠覆性的新能力。
但这恰恰是 New-API 当前最需要的。一个被几千个中转站依赖的基础设施项目，稳定性和可预测性比花哨的新功能重要得多。你不会希望自己的中转站在凌晨三点因为一次「小版本升级」挂掉。
从更大的视角看，New-API 的 1.0 也折射出整个 AI 中间件生态的成熟。两年前，大家还在为「怎么调通 OpenAI 的 API」发愁；现在，围绕多模型管理、成本优化、流量调度已经形成了一个完整的工具链。New-API、One-API、LiteLLM、各种商业中转服务，加上 All API Hub 这样的周边工具，生态的丰富程度已经今非昔比。
对于开发者来说，选择也更清晰了：想要完全掌控，自己部署 New-API；想要省心省力，用托管的聚合服务。两条路都走得通，关键看你的场景和运维能力。
最近确实有不少开源项目扎堆发 1.0——正如 Linux.do 社区里有人感慨的，「最近好多项目发 1.0 版本啊」。这或许说明，经过过去两年的野蛮生长，AI 工具链正在集体进入稳定期。对于整个生态来说，这是好事。
参考来源
- Linux.do - New API 正式推出 v1.0.0 版本讨论帖：社区对 New-API v1.0.0 发布的讨论
- GitHub - QuantumNous/new-api Releases：New-API 完整的版本发布历史
- GitHub - QuantumNous/new-api：New-API 项目主页，包含文档和部署指南
- 知乎 - New API 工具对比、私有化部署与企业级网关架构解析：New-API 在企业场景下的架构分析
- GitHub - All API Hub：New-API 生态的浏览器扩展管理工具