New API 是什么？
简答：New API 是一个可自托管的 AI 网关：搭建者把已授权的模型渠道接入后台，再向客户端提供统一接口、模型路由、令牌权限、用量与成本管理。普通用户拿到的通常是该网关签发的 API Key，不是 OpenAI 或 Anthropic 的账号；配置时应以服务方给出的 Base URL、Key 和模型列表为准。
定义：New API 是面向应用、智能体、团队和企业私有部署的开源 AI API 网关与用量管理系统。
先看结论：New API 能做什么、普通用户拿到的是什么
从官方项目说明看，New API 的核心作用是连接多个上游模型服务，对客户端提供相对统一的 API 入口，并集中处理路由、访问权限、用量和成本管理。它可以用于个人使用、团队内部共享或企业私有部署，具体上游包括 OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、Vertex AI、DeepSeek、Qwen 等，实际可用范围取决于部署者配置的渠道和授权。
对普通用户来说，最重要的理解是：如果某个服务页面显示由 New API 提供支持，你通常是在使用该服务实例签发的令牌。官方快速开始流程要求管理员先添加上游渠道，再创建可访问相应分组和模型的 API Key，客户端随后使用这个 New API 签发的 Key。因此，它不是自动把你的个人模型账号转移到其他客户端，也不会凭空增加上游模型权限。相关流程可查看项目仓库中的快速开始说明。
| 组成 | 作用 | 普通用户能否直接决定 |
|---|---|---|
| 上游渠道 | 连接已授权的模型服务和 API Key | 通常不能，由部署者配置 |
| 模型与路由 | 决定请求使用哪个模型、渠道或备用渠道 | 只能使用服务方开放的模型 |
| API Key | 识别用户并控制分组、模型和额度 | 可以在服务方后台创建或申请 |
| Base URL | 客户端发送 API 请求的入口地址 | 必须使用服务方提供的地址 |
New API 和 One API 有什么区别？先看能核实的差异
二者都属于 AI API 管理与分发类项目，都能把多个模型服务放到统一入口下，但不能简单当作同一个项目的不同名称。当前 New API 官方文档把 One API 列为相关项目；两边仓库公开的许可证、接口范围和功能描述也存在差异。
| 对比项 | New API | One API |
|---|---|---|
| 项目定位 | AI 网关、模型聚合与分发，面向应用、智能体、团队和私有部署 | 通过统一 API 管理和分发多种大模型 |
| 协议与接口 | 官方 README 列出 OpenAI Chat Completions、Responses、Anthropic Messages、Gemini，以及 Embeddings 和 Rerank 等接口 | README 重点描述通过标准 OpenAI API 格式访问多种大模型 |
| 路由能力 | 支持模型映射、渠道优先级和权重、重试、渠道亲和性及多上游 Key | 支持多渠道负载均衡、模型映射和失败自动重试 |
| 管理能力 | 包含用户、分组、令牌限制、用量日志、成本和表达式计价等能力 | 包含令牌额度、IP 范围、模型访问、用户分组、倍率和额度明细等能力 |
| 许可 | 官方文档说明采用 GNU AGPLv3 | 仓库页面标注 MIT License |
| 公开功能亮点 | 官方功能说明列出全新界面、Midjourney-Proxy、Suno、Rerank、OpenAI Realtime、推理内容透传和模型限速等功能 | 官方 README 列出绘图接口、流式传输、多机部署、兑换码和自定义设置等功能 |
上表只列官方页面能够核实的项目差异，不代表某个版本一定适合所有场景。New API 的功能说明还特别提醒，部分协议字段能否转换取决于渠道、上游模型和转换路径；切换项目或升级版本前，应先查看对应版本的发布说明和部署文档。可进一步阅读官方功能说明、One API 官方仓库。
New API 的工作原理：从上游 Key 到客户端请求
- 管理员配置渠道：在后台填写已授权上游服务的连接信息、API Key、可用模型和分组，并执行渠道测试。
- 系统建立模型与路由：管理员设置模型名称、渠道优先级或权重，并根据需要配置重试、限速和访问范围。
- 创建网关令牌：后台创建用户或 API Key，并授予相应分组和模型权限。
- 客户端统一调用：Cursor、Dify、OpenWebUI 或自写程序填写网关提供的 Base URL、网关 Key 和已开放模型。
- 网关转发并记录：New API 将请求转换到对应上游，返回兼容格式的结果，并根据实例配置记录用量、额度或成本。
这意味着客户端通常只需要记住一个入口和一个 Key，但模型能力、上下文限制、流式响应、工具调用和计费规则仍可能受到上游渠道与网关配置影响。官方 API 文档将接口分为 AI Model APIs 与 Management APIs，并列出了模型列表、Chat、Embeddings、Rerank、图像、视频和任务等接口类别，详情见New API API Reference。
普通用户怎么使用 New API：Base URL、Key 和模型三步核对
如果你使用的是别人部署的 New API 实例，不需要先部署服务器。向服务提供方获取以下三项信息：Base URL、API Key、可用模型 ID。Base URL 是否需要带 /v1，必须按客户端说明和服务方文档填写；有些客户端会自动拼接路径，重复添加可能导致 404。
- 先列模型：将服务方提供的 Base URL 代入
BASE_URL，将网关令牌放入本地环境变量NEW_API_KEY。不要把真实 Key 写入 Git 仓库、截图或前端代码。 - 再做最小对话请求：从列模型结果中复制一个确实开放的模型 ID，不要凭记忆填写模型名。
- 最后接入客户端：在客户端的自定义 OpenAI 兼容接口中分别填写 Base URL、Key 和模型；如果客户端会自动补全
/v1，就按客户端提示决定是否省略。
列模型请求示例：
curl --fail-with-body "${BASE_URL}/models" \
-H "Authorization: Bearer ${NEW_API_KEY}"预期结果是返回 JSON 模型列表；如果这里已经出现 401、403、404 或连接错误，先不要继续测试聊天请求，应先核对 Key、Base URL 和网络连通性。
最小 Chat Completions 请求示例：
curl --fail-with-body "${BASE_URL}/chat/completions" \
-H "Authorization: Bearer ${NEW_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"model":"从 models 返回结果中复制的模型ID","messages":[{"role":"user","content":"Hello"}]}'Windows PowerShell 可使用：
$headers = @{ Authorization = "Bearer $env:NEW_API_KEY"; "Content-Type" = "application/json" }
$body = @{ model = "从 models 返回结果中复制的模型ID"; messages = @(@{ role = "user"; content = "Hello" }) } | ConvertTo-Json -Depth 5
Invoke-RestMethod -Uri "$env:BASE_URL/chat/completions" -Method Post -Headers $headers -Body $bodyNew API 官方快速开始示例使用 /v1/models 和 /v1/responses，但不同客户端和渠道对 Responses 的支持可能不同。为了先验证最广泛的兼容面，本文示例采用 Chat Completions；实际接口以当前部署版本和服务方文档为准。
自己搭建还是直接使用现成服务？按角色选择
New API 的官方文档同时提供 Docker 单容器、Docker Compose、面板、集群和本地开发部署方式。单容器适合快速试用，Compose 文档则默认包含 New API、PostgreSQL 和 Redis，更适合需要持久化与多组件管理的部署者。官方仓库还提醒，生产环境应使用 HTTPS、持久化并备份数据库，升级前固定镜像版本并阅读升级说明。
| 维度 | 自己搭建 New API | 直接使用现成服务 |
|---|---|---|
| 适合人群 | 需要掌控渠道、权限、日志和路由的开发者或团队 | 只想在客户端或应用中调用模型的普通用户 |
| 前置工作 | 准备服务器、域名或内网地址、数据库、备份和安全配置 | 获取服务方提供的 Base URL、Key 和模型列表 |
| 控制范围 | 可自行管理上游渠道、分组、模型和令牌 | 能否使用某个模型取决于服务方开放范围 |
| 维护责任 | 自行处理升级、证书、日志、限速、故障和数据备份 | 由服务方承担其服务端维护，但仍需核验服务条款和 Key 使用范围 |
| 成本判断 | 需要考虑服务器、数据库、运维时间以及上游模型费用 | 以服务方公开的计费、额度和使用规则为准，本文不对未核实价格作判断 |
如果你只是想把一个兼容接口接入客户端，先完成“列模型—复制模型 ID—最小请求”三步即可；如果你需要团队共享、多个上游路由、权限控制或成本统计，再考虑自建。部署时可先阅读官方安装与部署文档，并按当前版本仓库的 docker-compose.yml 和升级说明操作。
使用 New API 前的核对清单
- 确认拿到的是网关 Key，而不是误把上游服务 Key 粘贴到客户端。
- 从
/models返回结果复制模型 ID，不要自行猜测大小写、日期或后缀。 - 确认 Base URL 是否已经包含
/v1，避免客户端再次拼接。 - 先用 Chat Completions 做最小请求，再测试流式、工具调用、图像或推理字段。
- 遇到 401 先查认证，403 查权限或额度，404 查路径和模型，429 查限速或额度；具体状态码还要结合网关返回体和服务方文档判断。
- 自建实例不要使用默认密码，生产环境启用 HTTPS，保存数据库和配置备份。
- 检查项目许可证和上游服务条款；如果向公众提供服务，还要自行确认所在地区的合规要求。
本文只讨论合法授权的 AI API 网关、模型管理和客户端接入；上游账号、模型权限和公开服务责任仍由实际部署者或服务提供方承担。
常见问题
New API 是模型吗？不是。它是连接模型服务的网关和管理系统，本身不等于某个具体模型，也不会自动提供模型额度。
普通用户需要自己部署 New API 吗？不一定。如果你已有服务方提供的 Base URL、Key 和模型列表，可以直接按兼容接口配置客户端；只有需要自主管理渠道、权限、日志或路由时，才通常考虑自建。
为什么 Base URL 填对了仍然返回 404？优先检查路径是否重复拼接 /v1，再检查请求端点是否与当前接口一致。先请求 /models，如果列模型也失败，就不要先排查模型参数。
New API 和 One API 是同一个项目吗？不能直接这样判断。当前官方资料将 One API 列为相关项目；两者的公开功能清单、许可证和接口描述不同，迁移前应按实际版本文档核对兼容性。
New API 支持哪些模型？官方项目说明列出多个上游服务，但某个实例最终能用哪些模型，取决于管理员配置的渠道、权限、模型映射和上游授权。最可靠的做法是使用该实例的 /models 接口核对。
参考资料
本文事实依据主要来自 New API 项目仓库、官方文档和 One API 项目仓库：New API GitHub 仓库、New API 项目介绍、New API 功能说明、New API 安装与部署文档、New API API Reference、One API GitHub 仓库。
常见问题
New API 是模型吗？
不是。它是连接模型服务的网关和管理系统，本身不等于某个具体模型，也不会自动提供模型额度。
普通用户需要自己部署 New API 吗？
不一定。如果服务方已经提供 Base URL、Key 和模型列表，可以直接配置兼容客户端；需要自主管理渠道、权限、日志或路由时，再考虑自建。
为什么 Base URL 填对了仍然返回 404？
先检查是否重复拼接了 /v1，再检查请求端点是否与当前接口一致。建议先请求 /models，确认入口和认证正常后再测试聊天请求。
New API 和 One API 是同一个项目吗？
不能直接这样判断。官方资料将 One API 列为相关项目；两者的公开功能清单、许可证和接口描述不同，迁移前应按实际版本文档核对。
New API 支持哪些模型？
某个实例能用哪些模型，取决于管理员配置的渠道、权限、模型映射和上游授权。最可靠的做法是调用该实例的 /models 接口核对。
相关阅读
参考资料
- New API GitHub 官方仓库
- New API 官方文档：项目介绍（docs.newapi.ai）
- New API 官方文档：功能说明（docs.newapi.ai）
- New API 官方文档：安装与部署（docs.newapi.ai）
- New API 官方文档：API Reference（docs.newapi.ai）