One API vs New API：LLM聚合平台对比

当你想统一管理多个大模型 API、做用量统计和成本核算时，开源的 LLM 聚合平台是最务实的选择。在这个领域，One API 和 New API 是绕不开的两个名字——前者是这个赛道的开创者，后者则是基于前者演进而来、目前社区最活跃的继任项目。

很多人在选型时都会纠结：到底该用哪个？它们到底差在哪？这篇文章会从项目背景、功能、模型支持、性能、运维和适用场景几个维度做一次客观对比，帮你做出判断。

一、项目背景与关系

先厘清两者的关系，这是理解后续差异的基础。

One API 由 songquanpeng 发起，是最早一批把"多模型聚合 + OpenAI 兼容接口"做成开箱即用产品的开源项目。它确立了这套架构的基本范式：渠道（Channel）管理、令牌（Token）分发、按分组计费、用量日志。很多后来者的设计都借鉴了它。

New API 由 Calcium-Ion（QuantumNous）发起，是 One API 的二次开发分支。它的定位很明确：在完全兼容 One API 数据库的前提下，补齐新模型格式、补齐企业级功能、重做前端 UI。换句话说，New API 不是另起炉灶，而是站在 One API 肩膀上往前走。这也是为什么从 One API 迁移到 New API 几乎没有数据迁移成本——数据库结构兼容。

一句话概括：One API 是奠基者，New API 是积极演进的继承者。

二、核心功能对比

两者都具备聚合平台的基础能力：多渠道管理、令牌鉴权、用量统计、按模型/分组计费。差异主要体现在"新模型格式支持"和"工程化能力"上。

从表格能看出一个清晰的趋势：One API 覆盖了基础场景，New API 在新模型格式和企业功能上明显领先。如果你只需要对接 OpenAI 兼容的文本接口，两者都能胜任；但一旦涉及 Claude/Gemini 原生格式、实时语音、跨格式转换，基本只有 New API 能满足。

三、模型与接口格式支持

这是两者差距最大的地方，也是选型时最该关注的点。

One API 诞生较早，它的核心是 OpenAI 兼容格式——所有上游模型都被转成 OpenAI 的 /v1/chat/completions 格式对外暴露。这在 GPT 一家独大时是合理的，但随着 Claude、Gemini 各自原生格式的成熟，这种"统一转成 OpenAI 格式"的做法会丢失一些原生能力（比如 Claude 的 thinking、Gemini 的思考预算）。

New API 的思路是多格式并存 + 跨格式转换：

• 同时暴露 OpenAI、Claude Messages、Gemini 三种原生格式接口，客户端可以用任意一种格式调用。
• 支持 OpenAI ⇄ Claude、OpenAI → Gemini 的双向转换，意味着你用 OpenAI SDK 写的代码，后端可以路由到 Claude 模型，反之亦然。
• 支持 OpenAI Responses API 和 Realtime API，覆盖了 OpenAI 最新的接口形态。
• 对推理模型的 reasoning effort（如 o3-mini-high、Claude thinking、Gemini 思考预算）做了原生支持。

举个具体例子。如果你的应用已经用 Anthropic SDK 写好了，想接入 GPT 模型，用 One API 就得改客户端代码；而用 New API，可以直接把 Claude 格式的请求路由到 GPT 后端，客户端一行不用改。这种灵活性在多模型混合调度的场景下价值很大。

四、性能与稳定性

两者底层都是 Go 实现，单机性能都不弱。但在高并发和复杂调度场景下，New API 做了更多工程优化：

• 渠道加权随机与亲和性：New API 支持按权重在多个上游渠道间分流，还能做渠道亲和性缓存——同一会话尽量路由到同一渠道，减少上下文不一致问题。
• 失败自动重试：上游渠道报错时自动切换到备用渠道，对调用方透明，提升整体可用性。
• 用户级模型限流：可以针对单个用户或令牌限制特定模型的调用频率，防止单用户打满资源。
• 性能指标采集：内置 Prometheus 监控支持，可以观测每个渠道的延迟、成功率、吞吐量。

One API 也有基本的负载均衡和重试，但策略相对简单。如果你的 QPS 不高（比如个人项目或小团队），这点差距感知不强；但到了企业级用量，New API 的调度能力会更省心。

五、计费与成本管理

作为 API 网关，计费是核心功能。两者都支持按 token 计费、按模型设定倍率、分组管理用户额度。差异在于精细度：

• 缓存计费：New API 支持 OpenAI、Azure、DeepSeek、Claude、Qwen 等模型的缓存命中计费统计，能准确反映 prompt cache 带来的成本节省。
• 分层计费：New API 支持按用量阶梯定价，适合做企业客户的差异化报价。
• 支付集成：New API 集成了易支付、Stripe 等支付渠道，方便做面向客户的充值和订阅。
• 数据看板：New API 提供可视化的用量统计控制台，按模型、按用户、按时间维度分析成本。

对于只做内部网关的团队，One API 的计费能力够用；但如果你要把 API 作为产品对外销售，New API 的商业化能力明显更完整。

六、部署与运维

两者的部署方式高度一致，都支持 Docker 和 Docker Compose 一键部署。New API 的部署示例：

# 拉取镜像并启动（默认 SQLite）
docker run --name new-api -d --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v ./data:/data \
  calciumion/new-api:latest

# 使用 MySQL
docker run --name new-api -d --restart always \
  -p 3000:3000 \
  -e SQL_DSN="root:123456@tcp(localhost:3306)/oneapi" \
  -e TZ=Asia/Shanghai \
  -v ./data:/data \
  calciumion/new-api:latest

部署后访问 http://localhost:3000 即可使用。从 One API 迁移到 New API，通常只需要把数据库指向原来的库，启动 New API 容器即可，历史渠道、令牌、日志都会保留。

运维层面，两者都支持 SQLite（轻量）和 MySQL/PostgreSQL（生产）。New API 额外提供了更完善的备份脚本、日志轮转和健康检查配置。社区文档方面，New API 有独立的官方文档站（docs.newapi.pro），覆盖了安装、配置、API、FAQ，对新手更友好。

七、一个调用示例：两者对外接口一致

无论用 One API 还是 New API，对调用方而言接口都是 OpenAI 兼容格式。下面这段 cURL 在两个平台上都能跑（只需替换 base URL 和 Key）：

curl https://your-gateway.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-你的令牌" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "用一句话解释什么是API网关"}
    ]
  }'

这种接口一致性意味着：你的应用代码不绑定具体平台，今天用 One API，明天换 New API，客户端零改动。这也是开源聚合平台相对闭源 SaaS 的一大优势——可迁移性。

八、适用场景与选型建议

说了这么多差异，到底该怎么选？给几条明确的建议：

选 One API，如果：

• 你已经在用 One API 且运行稳定，没有新模型格式需求，没必要折腾迁移。
• 你的场景纯粹是 OpenAI 兼容文本接口的聚合，不需要 Claude/Gemini 原生格式。
• 你偏好更"原汁原味"、依赖更少的项目。

选 New API，如果：

• 你需要对接 Claude、Gemini 等模型的原生格式，或需要跨格式转换。
• 你需要 Realtime API、Responses API、Rerank 等较新的接口能力。
• 你在做面向客户的 API 转售，需要完善的计费、支付、看板。
• 你重视社区活跃度和持续迭代，希望跟上模型生态的快速变化。
• 你是新项目，没有历史包袱——直接上 New API 几乎没有理由选旧的。

一个简单的判断标准：如果你的需求里出现了"Claude 原生格式""实时语音""跨格式转换""对外售卖 API"中任何一条，直接选 New API。如果都没有，两者皆可，但 New API 是更面向未来的选择。

九、不想自己部署？托管方案

自建聚合平台虽然灵活，但也意味着你要承担运维、上游 Key 管理、合规备案、安全更新等持续成本。对于个人开发者或小团队，一个更省事的选择是直接用托管型聚合服务。

EnlyAI（https://enlyai.com）就是这样一个基于 New API 构建的托管平台。它把 New API 的能力以服务形式提供——你不需要自己部署服务器、不需要维护多个上游渠道，注册后拿到一个 API Key，base URL 指向 https://enlyai.com/v1，就能调用 GPT、Claude、Gemini 等数十种模型，接口完全兼容 OpenAI 格式。

这种托管方案的好处是：你享受了 New API 的全部能力（多格式、跨转换、用量看板），却不用碰运维。等用量大到值得自建时，再迁移到自部署的 New API 也只是换个 base URL 的事。

总结

One API 和 New API 不是对立关系，而是传承关系。One API 定义了 LLM 聚合平台的基本形态，New API 在此基础上补齐了新模型格式、企业级功能和现代化体验。对于 2026 年的新项目，New API 在功能完整度和社区活跃度上都更占优；而 One API 依然是稳定可靠的基础选择，尤其适合已经部署且无迁移动力的存量用户。

选型的核心不是"哪个更好"，而是"哪个更匹配你的需求"。想清楚你要对接哪些模型、是否需要原生格式、是否对外提供服务，答案自然就清晰了。