AI 网关用量统计与配额管理：Token 计量实践

2026-07-29

多模型场景下，各服务商的 token 计费规则各不相同，用量数据分散在多个控制台。AI 网关的用量统计层把所有这些数据归拢到一处，按 Key、按模型、按时间维度呈现，并支持配额限制防止账单失控。

如果你还没吃过用量失控的亏，大概率是团队规模还小、调用量还没上来。我见过的真实场景是这样的：某团队接入了三个模型做 A/B 测试，前端埋了一个重试逻辑——请求超时就自动重发，最多重发 3 次。结果某天上游网络抖动，大量请求超时又都重发成功了，一天之内把原本能用一个月的额度打没了大半，而这个团队当时甚至不知道自己开了自动重试。用量统计不是”锦上添花的报表”，是能让你在出问题的当天而不是账单日发现问题的报警系统。

为什么用量统计是核心能力

没有统一用量统计时的典型困境：

月底才发现某个应用超支，无法定位是哪个功能、哪次调用造成的
多个团队共用一组 API key，无法内部分摊成本
某个用户/租户滥用，直到账单到来才察觉
不同服务商的 token 单位不统一（有的按词、有的按字符），难以横向对比
重试/failover 逻辑掩盖了真实请求量——你看到的”成功率 99%“背后可能藏着大量重复计费的失败请求

这五条里，最容易被忽视的是最后一条。很多团队把 failover 和重试当成”用户无感知的容错”，却没想过网关要不要把每一次重试都单独计入用量报表。我的建议是：重试产生的 token 消耗必须记录，但报表上要能按 request_id 把同一次业务请求的多次尝试聚合起来看，否则你算出来的”平均每次请求成本”会比实际偏高，容易误导后续的定价决策。

用量数据的完整记录结构

网关对每次 API 调用应记录：

{
  "request_id": "req_abc123",
  "timestamp": "2026-06-17T10:23:45Z",
  "key_id": "key_team_a",
  "model_requested": "gpt-4o",
  "model_actual": "gpt-4o",           // failover 时可能不同
  "upstream": "openai",
  "prompt_tokens": 512,
  "completion_tokens": 128,
  "total_tokens": 640,
  "latency_ms": 1240,
  "cost_usd": 0.00448,                // 按当前价格表换算
  "status": "success",
  "stream": true
}

关键字段说明：

model_actual：当发生 failover 时，实际使用的模型可能与请求的不同，需单独记录
cost_usd：网关侧按价格表换算，可能与服务商账单有小数点误差（主要用于内部参考）

再补几个容易被漏掉、但排查问题时非常关键的字段：

request_id：一定要在网关侧生成，而不是直接沿用上游返回的 id——上游超时或网络中断时可能压根拿不到 id，你自己生成的 id 才能保证每条记录都能追溯
stream：是否流式请求。流式和非流式的用量记录时机不同（下文会展开），报表里如果不区分这个字段，你会很难判断某次 token 数异常是不是因为流式响应中途断开导致的
建议再加一个 retry_of 字段，指向本次请求所重试的原始 request_id。没有这个字段，你几乎无法从日志里还原出”这 3 条记录其实是同一次业务调用的 3 次尝试”

这张表看着简单，但落地时最容易踩的坑是：把 cost_usd 当成”最终账单金额”来用。它只是网关按内置价格表实时估算出来的数字，服务商可能有阶梯定价、批量折扣、缓存命中折扣（比如 Anthropic 的 prompt caching 会让实际扣费远低于按 prompt_tokens 直接换算的结果），网关侧如果不同步维护这些折扣规则，cost_usd 就只能当参考，不能拿去对财务报表较真。

Token 归一化与多模型计量

不同服务商的 token 定义存在细微差异：

服务商	Token 化方式	1000 个中文汉字约等于
OpenAI	tiktoken（BPE）	~700 tokens
Anthropic	类似但略有差异	~600–700 tokens
Google Gemini	SentencePiece	数值可能不同
国内厂商	各自实现	部分按字计费

网关的归一化策略：

以服务商返回的 usage 字段为准（最准确）
若上游不返回 usage（罕见），用本地 tokenizer 估算
多模型对比报表时注明”token 数以各上游为准，不可直接横向比较”

这里有个真实会踩的坑：某些国内厂商的兼容接口在流式模式下，usage 字段只在最后一个 chunk 里出现，而且不是每次都出现——网络抖动导致连接提前断开时，最后那个带 usage 的 chunk 可能根本没送达。这种情况下网关如果傻等 usage 字段等不到就永久挂起，会导致这条记录一直卡在”进行中”状态、既不计费也不释放配额占用。正确做法是给流式请求设置一个”结束超时”（比如最后一个 token 到达后 30 秒还没等到 usage 就强制用本地 tokenizer 兜底估算一次），并把这类记录单独打上 usage_estimated: true 的标记，方便后续对账时区分哪些数字是精确的、哪些是估的。

第 2 点里的”本地 tokenizer 估算”也不是随便选一个 tokenizer 就能用。如果请求的是 GPT 系列模型，本地就该用对应的 tiktoken 编码表（cl100k_base 或更新的 o200k_base，具体用哪个要对应模型版本，选错了估算误差能到 20% 以上）；如果请求的是 Claude 系列，Anthropic 官方没有完全公开的本地 tokenizer，只能用近似值（比如按 1 个英文单词约 1.3 token、1 个中文汉字约 1.5-2 token 做粗估），这个粗估的误差比 tiktoken 精确计算大得多，报表里一定要标注清楚这是估算值，不能和精确值混在同一栏里做加总。

配额管理：四个维度

1. 总额度限制（最常用）

key_team_a：总额度 1,000,000 tokens
  ├── 已使用：423,000 tokens（42.3%）
  └── 剩余：577,000 tokens

额度耗尽后请求返回 429，提示”额度不足”。

2. 时间窗口速率限制

key_team_a：
  RPM（每分钟请求数）: 60 req/min
  TPM（每分钟 token 数）: 100,000 tokens/min
  RPD（每日请求数）: 10,000 req/day

速率限制与总额度独立生效，同时检查。

3. 按模型的差异化配额

某些场景需要限制高成本模型的用量：

key_team_a:
  gpt-4o：每日上限 50 次请求
  gpt-4o-mini：不限制
  claude-3-5-sonnet：每日上限 20 次请求

4. 预算告警

在额度耗尽前提前告警，而不是等到拒绝请求时才发现：

75% 告警：发送邮件通知 key 管理员
90% 告警：发送告警并提示续充
100% 耗尽：请求返回 429，附带"联系管理员充值"提示

这四个维度不是选一个就够，实际生产环境通常是叠加使用的，但叠加时容易漏掉一个细节：总额度和速率限制的检查顺序。如果网关先扣总额度、后判断是否超过 RPM，那么一个突发的请求洪峰会先把额度扣掉一部分，即使最终因为超速率被拒绝，这部分 token 记账也可能已经落地，造成”明明请求失败了却扣了钱”的诡异现象。正确的顺序应该是：先做速率限制判断（不涉及计费，只看时间窗口内的请求数/token 数是否超限），通过之后再进入真正的模型调用和计费流程。把这个顺序在代码里写反，是我见过排查耗时最长的一类 bug——现象是”账单和实际调用量对不上”，但表面看用量记录逻辑完全没问题，问题出在判断顺序上。

另外，“按模型的差异化配额”这个维度在实操中经常被低估。举个例子：一个团队给 gpt-4o 设置每日 50 次上限、claude-3-5-sonnet 每日 20 次上限，本意是控制高成本模型的调用。但如果网关的 failover 策略是”gpt-4o 限流后自动切到 claude-3-5-sonnet”，两个配额加起来实际上限就是 70 次，而不是任何一个单独看到的数字——这在做成本预算时很容易被忽略，导致”配额设置得挺严，账单还是超了”的困惑。排查这类问题的方法很直接：把 model_actual 和 model_requested 不一致的记录单独筛出来看占比，如果 failover 触发率超过 10%，说明限流策略之间存在这种隐性叠加，需要重新核算实际上限。

用量报表与分析

网关侧的用量报表应支持以下维度的汇总：

报表维度	示例
按时间	按天/按小时的 token 趋势
按 Key	各团队/应用的用量排行
按模型	各模型的请求量和 token 占比
按上游	各服务商的实际调用量（用于对账）
按状态	成功 / 4xx / 5xx / failover 的占比

导出格式：支持 CSV 导出，便于导入财务系统或 BI 工具做进一步分析。

OneAPI/NewAPI 的用量统计配置

两者均在”日志”和”数据统计”模块提供用量数据：

日志页面：每条请求的详细记录，支持按令牌（key）、渠道（上游）、模型筛选
数据统计：按天汇总的 RPM、TPM、成功率、费用趋势图
令牌用量：在”令牌管理”中查看每个令牌的已用额度和剩余额度

注意：OneAPI/NewAPI 的费用计算基于自配置的”倍率”（相对于 OpenAI 定价的倍数），与实际服务商账单可能有差异，需定期做对账校准。

常见问题

网关统计的 token 数和服务商账单对不上，怎么办？ 少量误差（1%–3%）属正常，主要来源：流式响应中 usage 字段有时不返回（需网关估算）、不同模型的 token 化差异。建议以服务商账单为计费依据，网关统计用于内部分摊参考。误差超过 5% 时需排查是否有请求漏记。

配额耗尽后能自动续充吗？ 主流自建方案（OneAPI/NewAPI）不支持自动续充，需管理员手动操作。部分托管服务支持预付费余额低于阈值时自动扣款续充。对生产环境，建议配置充足的告警提前量，而不是依赖自动续充。

如何统计流式响应的用量？ 流式响应（SSE）完成后，上游在最后一个 chunk 中通常会返回包含 usage 的 data: [DONE] 消息。网关需要等待流结束后再记录用量，而不是在流开始时就计量。