NewAPI 是什么？自建中转网关能解决什么问题

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

NewAPI 是一套你自己部署的大模型网关：它把多家模型厂商的接口聚合成一套 OpenAI 兼容的格式，对外只暴露一个地址和一套令牌，同时把用量、配额和权限都记在自己的数据库里。 官方文档在功能指南开头对它的描述是「统一的 LLM 网关平台，把多个 AI 供应商的 API 聚合成标准的 OpenAI 兼容接口，让你通过单一端点访问模型」。而在合规政策一章里，官方把适用场景写得更收敛：面向合法授权场景的 AI API 网关与用量管理系统，主要用于自用、团队内部使用和企业私有化部署。这两句话合起来才是它的真实定位——它解决的是「钥匙散在各处、账算不清、格式对不齐、人多了管不住」这四个工程问题，不是「上哪儿弄到更便宜的额度」。

它站在你的应用和厂商之间做了什么

把请求路径拆开看，NewAPI 插在中间只干三件事：认令牌、选渠道、转格式。

认令牌这一层对应的是 API 令牌（API Tokens）。官方的令牌管理一节写明，令牌可以配置额度上限、模型限制和 IP 允许列表。也就是说，同一个部署里发出去的每把钥匙，都可以单独限定它能花多少、能调哪些模型、能从哪些地址来。

选渠道这一层对应渠道（Channels）。渠道是上游厂商账号在网关里的映射，官方在渠道页给出了明确的合规前置条件：上游渠道必须是部署方合法拥有或获得授权的账号、API Key、模型服务或企业合同；负载均衡、自动故障转移、加权随机、多 Key 管理这些能力，是为高可用和企业多账号管理准备的。README 的智能路由一节列的三项能力也对得上：渠道加权随机、失败自动重试、用户级别模型限流。

渠道之间怎么排队，官方 FAQ 讲得很直白：优先级（Priority）数值越大越优先，会被先用；同一优先级内部再按权重（Weight）分配请求。所以「优先级」决定的是先后，「权重」决定的是同一档里怎么分摊，两个参数管的不是一回事，配的时候别混。

转格式这一层是 NewAPI 比较独特的部分。README 的格式转换一节列出的方向包括：OpenAI Compatible 与 Claude Messages 双向互转、OpenAI Compatible 转 Google Gemini、Google Gemini 转 OpenAI Compatible，以及思考转内容功能。其中 Gemini 转 OpenAI 兼容格式这一条官方特别标注了限制——仅支持文本，暂不支持函数调用；OpenAI Compatible 与 OpenAI Responses 的互转标的是开发中。这类限定条件比能力清单本身更值得记，因为它直接决定你的工具调用逻辑能不能透传过去。

第三个核心对象是分组，它才是账目的关键

渠道和令牌都好理解，容易被忽略的是用户分组（Group）。官方在管理员指南里对分组的描述是：创建用户分组以实现差异化计费与渠道分配，具体动作包括创建用户组、配置分组倍率、分配渠道。

分组之所以重要，是因为它直接进了计费公式。官方 FAQ 里给出的配额公式逐字是这样的：

Quota = Group Ratio * Model Ratio * (Prompt Token Count + Completion Token Count * Completion Ratio)

读法是：分组倍率乘以模型倍率，再乘以「输入 token 数加上输出 token 数乘补全倍率」。三个倍率各管一件事——分组倍率区分不同用户群的价目，模型倍率区分不同模型的贵贱，补全倍率单独作用在输出 token 上。为什么输出要单独乘一个系数？官方给的解释是，非流式模式下上游返回的是消耗的总 token 数，但输入和输出的消耗比例本来就不一样，所以要拆开算。

这个公式里的具体倍率值由每个部署方自己在后台设定，不存在一个通用答案，倍率的配置入口官方写的是「系统设置 → 运营设置 → 模型倍率设置」。想把这条链路吃透，可以往下看分组倍率的计费机制。

还有一个反直觉的设计值得单独拎出来：令牌额度和账户额度是两套独立的数。官方 FAQ 专门有一条问「账户额度明明够，为什么提示额度不足」，答案是令牌额度只用来设置该令牌的使用上限，用户可以自由设定，遇到这个提示应该先去检查令牌自己的额度够不够。很多人第一次撞上这个报错会去查钱包，方向就找错了。

自建网关到底解决了哪几类问题

对照官方合规政策一章列出的核心能力，自建网关的价值可以归成四条，每条都对应一个具体的痛点。

第一是统一鉴权与多模型路由。 应用侧只认一个端点和一把令牌，换上游厂商不需要动业务代码。官方的 API 参考把接口分成 AI 模型接口和管理接口两大类，前者兼容 OpenAI 格式，覆盖模型列表、对话、补全、嵌入、重排序、内容审核、音频、实时语音、图像、视频等类别。

第二是组织内的用量统计与访问控制。 日志被拆成三类：用量日志（Usage Logs）、任务日志（Task Logs）、绘图日志（Drawing Log）。用量日志里能看到每次调用的令牌分组、模型和消耗，且普通用户只能看自己的日志，管理员才能看别人的。这就是「谁花的钱」这个问题的答案所在。

第三是成本分摊与企业客户账户管理。 这也是分组倍率、令牌额度、兑换码这一整套东西存在的理由。官方对兑换码的用途限定得很死：仅用于内部测试、授权客户交付、活动赠送或账户调整。

第四是私有化部署与开发测试。 数据落在自己的库里，配套还有 Playground 可以直接在后台发起对话做测试。

权限侧，官方把角色分成三层：普通用户（注册后的默认角色，可以创建令牌、调用 API、查看用量、充值订阅）、管理员（由 Root 提升，额外能管渠道、用户、兑换码、日志、模型和分组）、Root 超级管理员（额外拥有系统设置、自定义 OAuth 和性能监控）。管理接口本身也是分级的，官方鉴权说明里写的层级是 Public / User / Admin / Root，认证方式二选一：走登录接口拿 Session，或者在请求头里带 Authorization: Bearer {token}，部分接口还要求额外带一个 New-Api-User: {user_id} 请求头，且该 user_id 必须与当前登录用户一致。

令牌一多，钥匙本身的管理就成了新问题，这部分可以参考通用的 API Key 安全管理。

部署形态：门槛比想象中低，但坑在默认值上

官方给出的部署方式是六选一：Docker Compose（适合生产环境）、Docker 单容器（适合个人或小规模）、1Panel、宝塔面板（后两者面向不熟悉命令行的用户）、集群部署（多节点高可用与横向扩展）、本地开发部署（贡献代码与二次开发）。

数据库方面，官方在环境变量文档里给了明确的偏好顺序：生产环境优先 PostgreSQL，MySQL 仍是兼容选项，未设置 SQL_DSN 时用的 SQLite 更适合本地开发与测试。运行环境要求里还有一条容易被忽略的硬限制——仅支持 64 位系统（amd64 / arm64），不支持 32 位。

真正会咬人的是默认值。官方的 Docker Compose 配置文件里有一行醒目提示，原文是 ⚠️ IMPORTANT: Change all default passwords before deploying to production!——上生产之前必须改掉所有默认密码。示例配置里的数据库口令是明摆着的占位值，照抄上线等于把库门敞开。另外官方对 SESSION_SECRET 有一条硬校验：它不能被设成 random_string 这个字面值，否则程序会拒绝启动。

多机部署还有两条前置条件，官方用警告框标出来：所有节点必须使用同一个主数据库并设置相同的 SESSION_SECRET，否则访问令牌、刷新会话和临时鉴权流程无法一致校验；连接同一个 Redis 的节点还必须设置相同的 CRYPTO_SECRET，否则各节点生成的缓存键摘要不一致，缓存共享不了。Redis 的三种拓扑（全节点共享、每节点独立、干脆不用）在会话传播和限流语义上表现不同，官方给了一张对照表，多节点上线前值得先读一遍。完整步骤可以看部署教程。

它明确不解决的问题，以及合规边界

这一节是本文最需要认真读的部分，也是官方文档里态度最强硬的部分。

官方合规政策写明：使用者必须合法取得上游 API Key、账号、模型服务或接口权限，并遵守上游服务条款及适用法律法规。多 Key 管理、负载均衡、故障转移这些能力，官方限定其用途是高可用与企业多账号管理。

如果你打算把它作为面向公众的生成式 AI 服务或 API 转售服务来运营，README 用警告框列出了必须先完成的义务：备案、内容安全、实名、日志留存、税务、支付和上游授权等合规义务，并直接引用了《生成式人工智能服务管理暂行办法》。官方在合规章节里把这句话说得更彻底——本项目主要面向自用、团队内部使用和企业私有化部署场景，对外提供服务相关的合规义务由部署方承担。

支付相关的能力也有同样的限定：充值、兑换码、邀请这些功能仅适用于合法授权场景下的内部结算、企业客户账户或合规服务费；税务、开票、消费者保护、支付风控等义务由收款主体自行承担。内容审核接口官方也说了，它是合规工具之一，不替代部署方自身的安全治理义务。

最后，项目采用 AGPLv3 许可证，官方明确表示软件按现状提供，不附带任何形式的保证，维护者只对合法合规的使用场景提供技术讨论与社区支持。

什么情况下不值得自建

装一套网关本身不难，难的是它从此变成你链路上的一个新的单点。数据库、Redis、会话密钥、渠道密钥、日志表，全都成了你要维护的东西；官方文档里那些关于会话陈旧窗口、缓存键摘要、限流语义随拓扑变化的说明，本质上都是自建带来的新复杂度。

判断标准可以简单一点：如果你只是一个人调一两个模型，直接用厂商官方端点更省事；当出现了「多个人共用同一批上游账号」「需要按人或按项目分摊成本」「需要在不改业务代码的前提下切换上游」这三种情况中的任意一种，网关才开始真正划算。至于花出去的钱怎么持续盯住，可以配合通用的 API 成本监控 一起做。

下一步的动作也很清楚：先在本地用单容器跑通，把渠道、令牌、分组这三个对象的关系摸熟，再决定要不要按生产标准换数据库、上 Redis、做多节点。顺序反过来，最容易在默认密码和密钥不一致这两个坑上栽跟头。