别再为 AI 调用超支头疼：Credits 配额，让每一笔消耗都透明可控

AI网关最近搞了个新功能——Credits配额，简单理解就是给大模型用量上了个计量表。之前大家管大模型消耗，基本是睁一只眼闭一只眼，账算不清、额度看个大概，月底对账单的时候都挺头疼。现在好了，Credits一出，模糊变清晰，账单焦虑这事儿终于有了解药。

核心要解决的问题其实就三个：大模型调用怎么度量、模型信息怎么管、配额怎么精细化控制。下面一个个展开说。

01. 大模型调用的度量为什么难

传统API网关管的是流量红绿灯——请求来了放行，超限了拦下。AI网关可不一样，它得给每一次调用打上可度量的刻度。大模型和普通API比起来，每次调用消耗的资源天差地别：一次问答动辄几千上万Token，输入、输出、缓存三档消耗差异很大，不同模型之间还没个统一的可比口径。业务方跑一段时间下来，最常问的三个问题也就那么几个：总共花了多少？谁花的？能不能给某个消费者定个上限，超了直接拦下来？

Token虽然是可度量的最小单位，但直接暴露给业务方并不友好。不同模型、不同档位的Token权重完全不同，光看Token数根本看不出资源占用的真实差异。AI网关Credits计量能力要解决的，就是引入一个跨模型、跨供应商可横向对比的统一度量刻度——Credits，并围绕它把“归属”和“约束”两件事补齐。

02. 本次上线的三部分能力

能力	解决什么问题
模型元信息管理	维护实例内模型清单及其 Credits 单价、能力、Token 上限等规格信息，便于在 Model API 和路由中快速选择模型名称，并按模型统计 Credits 消耗。
供应商管理	让每个服务与模型都能明确挂到一个供应商名下，按供应商维度管理和查看资源。
Credits 维度配额	让配额规则从“Token”维度进化到“Credits”维度

下面一块块拆开讲。

03. 模型元信息：给每个模型建一张“规格档案”

3.1 它是什么

在此之前，一个模型对AI网关来说只是一个字符串（比如qwen-max、gpt-4o）。要做Credits计量的时候，网关根本不知道这个字符串对应的输入、输出、缓存单价分别是多少。AI网关新增了一类资源——模型元信息，简单说就是给每个模型建了一张“规格档案”。一张档案上有：基础信息（模型名称、绑定的供应商）、Credits信息（输入/输出/缓存三档Credits/1M tokens单价）、能力与性能（最大输入Token、总Token上限、支持哪些模态、是否支持函数调用、流式输出、推理模式等能力开关）、可用路径（这个模型走/v1/chat/completions还是别的路径，OpenAI兼容还是Anthropic兼容）。

3.2 举个具体的例子

假设你在网关里维护了一条模型元信息：

名称：qwen-max供应商：阿里云百炼输入 Token 消耗：8   Credits / 1M tokens输出 Token 消耗：24  Credits / 1M tokens缓存 Token 消耗：2   Credits / 1M tokens

现在有一次调用，用掉了100万输入Token、20万输出Token、5万缓存Token，网关会在请求发生的那一刻这样算：

输入 Credits = 100 万 / 100 万 × 8  = 8    credits输出 Credits = 20  万 / 100 万 × 24 = 4.8  credits缓存 Credits = 5   万 / 100 万 × 2  = 0.1  credits────────────────────────────────本次总消耗                 ≈ 12.9 credits

04. 供应商资源：从“标签”进化成“归属维度”

4.1 之前为什么不够用

在之前版本的AI网关里，服务的高级设置里有一个“大模型供应商”字段，本质是一个协议模版（openai兼容/anthropic兼容）——它只告诉网关“用什么协议对接”，并不代表“这次调用的用量归口到哪个供应商”。举个反例：你可以有两个“OpenAI兼容”的服务，一个真是走OpenAI，一个走DeepSeek。它们的协议一样，但属于两家不同的供应商。老字段区分不出来。

4.2 新能力：独立供应商资源

现在AI网关把“供应商”独立成了实例内的资源对象，同时给原有字段改了名，避免混淆：

概念	新名字	用途
原“大模型供应商”字段	改名为 供应商配置模版	只描述对接协议
新增的资源	供应商（Provider）	承载用量归属维度

两个概念完全解耦，互不筛选、互不继承。这样一来：一个供应商可以关联多个服务（1:N）；一个服务在同一时刻只能归属一个供应商（避免统计口径打架）；服务与供应商之间形成了明确的绑定关系，方便管理员按供应商维度管理和查看资源。

05. 配额单位扩展：从“卡Token”到“卡Credits”

这是最核心的能力升级。

5.1 一句话理解它的价值

老规则：给消费者A定“每天1000万Token”——但A用的是轻量模型还是大模型？消耗强度差异说不清。新规则：给消费者A定“每天500 credits”——直接约束的是统一度量刻度，轻量模型能多跑几次，大模型自然次数就少。

5.2 创建配额规则的UI变化

在原有创建流程的基础上，新增「限额单位」选择，支持配置Credits维度的配额：

字段	类型	说明
规则名称	文本	沿用
限额单位	单选token/credits，默认token	新增
限额值	数值，后缀随单位联动展示Tokens/credits	沿用
周期类型	单选 + 参数（自然日/周/月 或 自定义 1~60 天）	沿用
时区	下拉，默认 UTC+8	沿用

06. 把三块能力串起来看：一次真实的调用会发生什么

以一个具体场景走一遍闭环。

背景：消费者“内部推理平台”每月配额 = 10000 credits（自然月 + credits）。网关内已配置好：供应商“阿里云百炼”；模型元信息“qwen-max”（绑定阿里云百炼，输入 8 / 输出 24 / 缓存 2 credits per 1M tokens）；服务“qwen-service”（关联到阿里云百炼这个供应商）。

消费者带着API Key打过来，网关识别出他是“内部推理平台”，本月已消耗 9987 credits。

本次请求还没执行，配额剩余13 credits，够不够？先放行。

调用 qwen-max 消耗了5万输入、10万输出、2万缓存Token。

input  =  5 万 / 100 万 × 8  = 0.4  creditsoutput = 10 万 / 100 万 × 24 = 2.4  creditscache  =  2 万 / 100 万 × 2  = 0.04 credits────────────────────────共计约 2.84 credits

消费者内部推理平台本月累计消耗更新为 9989.84 credits，剩余 10.16 credits。

再来一次预估20 credits的调用——剩余 10.16 不够扣，网关直接返回429，一次超额都不允许。

07. 能力速览

关注点	AI 网关给出的答案
一次调用消耗多少 Credits？	请求时刻按模型元信息里的 Credits 单价实时折算
服务归属哪家供应商？	服务与供应商之间建立明确绑定关系，一个供应商可关联多个服务
消费者用量如何约束？	配额规则支持 Token / Credits 双单位，管理员可灵活选择

Credits计量与配额能力已上线，欢迎体验并留下你的用量治理需求与反馈。