NewAPI 分组倍率是怎么算的？计费公式与配额扣费流程解读

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

先把结论说完：NewAPI 的分组倍率不是一张独立的价格表，而是三层倍率体系里的最外层乘数。官方公式把它写在整个括号的外面，也就是说，它对输入 token 和输出 token 一视同仁地放大或缩小，而补全倍率只作用在输出那一项上。 更关键的是，分组在 NewAPI 里身兼两职：既是计费系数的载体，也是渠道访问权限的隔离边界。改一个分组的倍率，改的是这批用户的账单；改一个分组的渠道归属，改的是他们能不能调到某个上游。很多人对不上账，就是因为只把分组当成价格档位，没意识到它同时是权限开关。

本文的公式、字段名和配置路径都来自项目官方文档站与官方仓库（QuantumNous/new-api），我们没有部署或运行过任何实例，行为以官方文档当前版本为准。倍率的具体取值是每个部署方自己设定的，写死任何数字都是错的，所以本文只讲机制。

官方计费公式长什么样

官方 FAQ 里给出的配额计算公式是这一行：

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

文档的倍率设置章节里还有一份等价的中文写法，把乘法顺序换了个位置，含义完全一样：

配额消耗 = (输入token数 + 输出token数 × 补全倍率) × 模型倍率 × 分组倍率

官方把这套东西明确称为「三层倍率体系」，三层各自的职责是这么划分的：

• 模型倍率（Model Ratio）：定义不同模型的基础计费系数，官方的说法是「相对于基础计费单位的乘数，体现模型之间的成本差异」。
• 补全倍率（Completion Ratio）：对输出 token 做额外的计费调整。官方给的解释是，某些模型的输出成本明显高于输入成本，需要靠这个系数来平衡。设为 1 表示输出和输入按同样标准计费，大于 1 表示输出计费更高，小于 1 则更低。
• 分组倍率（Group Ratio）：为不同用户分组设置有差异的计费乘数。

看括号的位置就能读出优先级关系：补全倍率被关在括号里，只乘输出 token；模型倍率和分组倍率在括号外，乘的是括号算完之后的整体结果。所以调分组倍率是一个「全局缩放」动作，它不会改变输入与输出之间的相对比例，只会把这个用户所有模型的账单一起按同一个系数推上去或拉下来。FAQ 里对这一点有一句很直白的总结：某个用户的实际倍率等于模型倍率乘以分组倍率。

配额（Quota）本身是系统内部的计费单位，官方说明所有 API 调用最终都会被换算成配额点数来扣减，用户余额和消费记录也都以配额点数为基础。配额点数与外部货币计价之间存在一个固定的换算单位，官方文档里写明了这个换算关系，本文按惯例不引用具体数值。

分组倍率之外，分组还管着渠道权限

官方的分组管理文档开篇就把分组的两个作用并列写了出来：分组用于隔离不同用户的渠道访问权限和计费倍率，不同分组的用户只能访问分配给自己分组的渠道。

分组名在三个地方出现，这三处必须对得上：

• 用户分组：在用户管理里编辑用户时给他指定一个分组。
• 令牌分组：创建令牌时指定这个令牌使用哪个渠道分组。
• 渠道分组：添加渠道时，在「分组」字段里填写允许使用该渠道的分组名。

官方在这里给了一个容易被忽略的提示：当令牌的分组被设成 auto 时，系统会按优先级自动选择一个可用的分组，适合跨分组故障转移的场景。这意味着一个走 auto 的令牌，实际结算时落在哪个分组上并不完全由你事先决定——这一点在后面讲重试计费时还会再出现一次。

分组倍率的配置形态是一份 JSON，键是分组名，值是该分组的系数。同一份配置里可以并存若干个分组；官方示例里出现的键名是 vip、premium、standard、trial 这类，具体怎么对应到你的业务口径由你自己定义。官方还给了一条明确的取值优先级：

1. 用户专属倍率——为某个具体用户单独设置的倍率；
2. 分组倍率——用户所属分组的倍率；
3. 默认倍率——系统默认值。

也就是说，给单个用户开的口子会盖过分组设置。排查「为什么这个人的账单跟同组其他人不一样」时，第一件事就是去看他有没有被单独设过专属倍率，而不是怀疑分组倍率算错了。

变更日志里还能看到一条与分组相关的衍生机制：倍率的展示会遵循配置好的「分组到分组」倍率设置。这说明分组之间的换算并不总是一个扁平的单层查表，具体行为以官方文档当前版本为准。

三种计费口径，参与相乘的因子并不一样

这是最容易被简化掉的一节。官方文档实际给出了三条公式，对应三类模型，参与相乘的因子并不相同。

按量计费（按 token 消耗） 就是前面那条，输入、输出、补全倍率、模型倍率、分组倍率全都参与。

按次计费（固定价格） 的形态完全不同：

配额消耗 = 模型固定价格 × 分组倍率 × 配额单位

注意这里只有分组倍率参与，模型倍率和补全倍率都不在式子里。原因也说得通：既然是按次固定计价，就不再有输入输出 token 的区分，模型之间的成本差异已经体现在固定价格本身里了。官方举的例子是绘图类模型这种按调用次数结算的场景。所以如果你的部署里同时跑着对话模型和绘图模型，调分组倍率对两者都生效，但调模型倍率只对前者生效。

音频模型 的公式最长，官方注明由系统内部自动处理：

配额消耗 = (文本输入token + 文本输出token × 补全倍率 + 音频输入token × 音频倍率 + 音频输出token × 音频倍率 × 音频补全倍率) × 模型倍率 × 分组倍率

音频这一路多出了「音频倍率」和「音频补全倍率」两个系数，且音频输出要连乘两次。但括号外面仍然是模型倍率乘分组倍率——三条公式里唯一一个从头贯穿到尾的因子，就是分组倍率。

预消费与后消费：余额为什么会先掉一块

NewAPI 采用的是官方称为「预消费与后消费」的双阶段计费机制，流程分三步：

1. 预消费阶段：API 调用发出之前，系统按预估 token 数算出配额消耗并预先扣除；
2. 后消费阶段：调用完成后，按实际 token 数重新计算配额消耗；
3. 差额调整：如果实际消耗与预消费不一致，系统会自动调整用户的配额余额。

对应的三行公式是：

预消费配额 = 预估token数 × 模型倍率 × 分组倍率
实际配额 = 实际token数 × 模型倍率 × 分组倍率
配额调整 = 实际配额 - 预消费配额

这里有两个值得留意的点。第一，预扣阶段就已经乘上了模型倍率和分组倍率，所以一个高倍率分组的用户在长请求发起的瞬间就会看到余额明显下降，之后才被差额调整拉回来——如果不知道有预扣这一步，这个中间状态看起来就像是多扣了。第二，预估 token 数怎么来的，官方文档没有展开说明；变更日志里有一条改进记录提到分层定价在预消费阶段改用了默认的 token 估算值，用以改善受影响定价规则的配额计算，说明这一步的估算策略本身是会演进的。

另一条更值得记住的变更记录是：分层重试的计费会按最终选中的分组来结算，包括发生了分组切换的重试。把它和前面那个 auto 分组连起来看就清楚了——一次请求如果在重试过程中换了分组，账最终算在落地的那个分组头上，而不是发起时的分组。做成本归因时，这个细节会直接影响你怎么解释某个分组的用量突然变多。

倍率没配会发生什么

官方专门写了「未设置倍率的模型」这一节，行为分三种情况：

• 自用模式（Self-use Mode）：套用一个系统内置的默认倍率，具体数值以官方文档为准；
• 计费模式：直接报错，提示倍率或价格未配置；
• 自动检测：管理界面里会把未配置倍率的模型单独列出来。

对应的报错在 FAQ 的渠道配置章节里也有：渠道测试时报「倍率或价格未配置，请联系管理员设置」，官方给的排查指引是去「系统设置 - 运营设置 - 模型倍率设置」里检查是否已配置倍率或价格，或者在系统设置的运营设置里启用自用模式。这条路径值得记下来，因为它是本文提到的几处配置里唯一一个在报错文案里被官方原样点名的位置。

变更日志显示，模型定价设置后来还加了一个「未设价模型」的页签，以及状态与同步筛选，用来更快找出没配价格的模型。如果你的部署是多人共用的，上线新模型之后先扫一遍这个列表，比等用户来报错要省事。

倍率的录入方式官方给了两条：直接编辑 JSON 配置，或者用可视化编辑器。可视化编辑器支持批量编辑模型倍率、实时预览倍率配置、冲突检测与提示，以及一键同步上游倍率。上游同步这一项官方的措辞很克制——只同步合法授权的上游公开或授权可用的价格与模型元数据，批量更新本地倍率配置，与上游价格保持同步，并且支持手动调整与覆盖。换句话说，同步是起点不是终点，同步完之后你的分组倍率仍然是自己那一层，不会被上游覆盖。

账对不上时去哪几个页面核

NewAPI 把计费信息散在几个不同的页面上，各看各的一段：

定价页（左侧栏的「定价」，或直接访问 /pricing）展示所有可用模型的计费倍率，官方注明无需登录即可查看，每一行给出模型名、输入价格和输出价格，页面顶部有搜索框可以按模型名关键词定位。官方在这一页给的换算口径是「实际消耗 = token 数 ÷ 1000 × 单价」，并且明确提示：不同分组的用户计费倍率可能不同，实际扣减以充值页上的余额变化为准。这句提示本身就说明定价页展示的是一个基准视角，不是你个人的最终账单。变更日志里另有一条相关改进——定价页支持了分组感知的动态计算，并且不再把仅供示例的特殊分组泄漏到页面上。

用量日志页面可以看到 API 调用记录，包括所用的令牌分组、模型和消耗。普通用户只能看自己的，管理员可以查看其他用户的。管理员视角的日志列表比普通用户多两列——「用户名」和「渠道名称」，筛选条件包括时间范围、用户名、模型、渠道和令牌名，页面顶部还有一块汇总统计区。要定位「某个分组这个月为什么多花了」，这个页面能同时给到分组、模型、渠道三个维度。

分组自查这条路径官方也留了口子：管理接口里有 /api/user/self/groups（需登录）用于获取当前用户所属分组，以及 /api/user/groups 用于获取用户分组列表。官方还提供了一套面向编辑器的命令工具，其中 /newapi groups 用于列出账户所属分组及其配额与倍率设置。需要提醒的是，官方明确标注该工具仍在活跃开发中，命令与功能可能随版本变化。

自建网关的成本监控思路和调用商业 API 是相通的，只是数据源换成了你自己的日志表，跨厂商的通用做法可以对照API 成本监控的通用机制那篇。

三个特别容易搞混的地方

令牌额度不等于账户额度。 FAQ 里有一条专门的问答：账户额度充足却提示额度不足，是因为令牌额度和账户额度是分开的两套——令牌额度只用来设置最大使用上限，用户可以自由设置，遇到这个提示应该先检查令牌额度够不够。这跟倍率没有关系，但它制造的现象和「倍率配高了导致扣超」非常像。

分组限流和分组倍率是两套配置。 官方的限流章节里，分组限流是在分组管理页面编辑分组时设置的，配置形态是一份 JSON，键为分组名，值是一个包含两个数字的数组，分别代表每分钟请求上限和每小时请求上限，设为 0 表示不限制，同一分组内的所有用户共享这份限流配置。它和分组倍率共用同一个分组名，但落在不同的配置面板里，改一个不会影响另一个。限流本身的通用概念可以参考RPM 与 TPM 到底限的是什么。

「当前分组负载已饱和」不是倍率问题。 FAQ 对这条错误的官方解释是：上游渠道返回了 429（请求过多）。同理，「无可用渠道」这条提示，官方给的检查顺序是三项——用户分组设置、渠道分组设置、渠道模型设置。这三条里没有一条和倍率有关，它们全是权限与匹配问题。别一看到分组两个字就去翻倍率配置。

最后：改倍率之前先想清楚三件事

第一，分组倍率是全局乘数，它一改就同时改变这个分组下所有模型、所有令牌的账单，包括按次计费的那些模型。要做单模型的精细调整，该动的是模型倍率或补全倍率。

第二，倍率字段支持小数录入——变更日志里有一条修复项，正是让分组倍率字段能够正常输入小数值。所以精细化的系数是可以配的，不必凑整。

第三，缓存命中是另一套计费口径。README 的用量与成本管理一节列出了按次、按量以及缓存命中的成本核算，并提到对多家厂商模型的缓存计费统计；变更日志里也有针对缓存写入 token 按缓存创建口径计费的调整。这部分不在三层倍率的公式里，跨厂商的通用规律见缓存计费机制。

如果你还没有把实例跑起来，倍率这一层可以先放一放——部署路线和上生产前的检查项见NewAPI 部署教程。等渠道和令牌都通了，再回来按本文的顺序把分组、倍率、限流三份配置对齐，比一边搭一边调要清楚得多。