配额按 token 计
配额应该按 token 而不是按请求数计：长短请求的成本能差几十倍，按请求数配额会让计量与成本分摊同时失真。做法是记录每次调用的输入与输出 token，按标识或租户维度聚合，接近上限时预警，超额时拒绝并给出明确错误。
基本信息
| 计量单位 | 输入与输出 token |
|---|---|
| 聚合维度 | 标识或租户 |
| 预警 | 接近上限时提醒 |
| 超额处理 | 拒绝并返回明确错误 |
| 用途 | 成本分摊依据 |
典型使用场景
- 多租户平台的用量统计
- 按部门做成本分摊
- 给免费额度设置上限
- 核对账单与内部计费是否一致
- 把用量明细开放给用户自助查询，减少人工对账
- 把配额余额与用量放在同一页面，用户能自己判断还剩多少
计量字段
计量字段
# usage.prompt_tokens 输入 token
# usage.completion_tokens 输出 token
# usage.total_tokens 合计
# 网关按标识聚合日/月用量，越线预警或拒绝字段与用途
| 字段 | 含义 | 用途 |
|---|---|---|
| 输入 token | 提示词消耗 | 成本构成 |
| 输出 token | 生成消耗 | 通常单价更高 |
| 合计 | 总用量 | 配额扣减 |
| 按标识聚合 | 租户视图 | 分摊与预警 |
流式响应里 usage 出现的位置由实现决定：缺失时用请求侧计数补偿，两侧口径要先对齐一次。
计量数据要能追溯到请求：保留请求标识与时间戳，出现用量争议时才有对账依据。
配额策略要写清楚：按日还是按月、超额是拒绝还是降速，用户在接入时就应该知道规则。
原始计量记录要保留：规则调整之后仍能回溯历史用量，避免口径变更带来争议。
计量与配额要在同一个数据源上计算：两套数字并存时，以哪一套为准会成为长期扯不清的争议。
计量口径变更要提前公告：用户看到用量数字突变又没人解释，信任成本会很高。