usage 用量对账是什么
每次响应的 usage 字段都带着输入、输出与缓存明细的 token 数，按用户、功能、模型、渠道等维度落库聚合，才能回答「钱到底花在哪了」。没有用量数据，一切降本都是盲调：既不知道哪个功能在增长，也无法验证优化是否奏效。落地要点有三个：单价放配置表，便于厂商调价后按当时价格重算历史账单；缓存命中部分单独统计，用于核算缓存收益；按日看输出的中位数与 P95，成本长尾通常藏在分布尾部而不是平均值里。
基本信息
| prompt_tokens | 输入总数，用于上下文规模监控 |
|---|---|
| completion_tokens | 输出总数，用于输出长度治理 |
| cached_tokens | 缓存命中部分，用于核算缓存收益 |
| total_tokens | 合计，用于配额与预算控制 |
| 聚合维度 | 用户、功能、模型、渠道、租户 |
| 单价管理 | 放配置表，调价后可重算历史账单 |
典型使用场景
- 成本归因：找出本月账单增长来自哪个功能或租户
- 配额管理：按用户或部门统计用量并设限额
- 优化验证：对比优化前后的同口径用量变化
- 缓存收益核算：确认折扣是否真的落到账单上
- 预算预测：按近期用量趋势推算下月支出
用量落库与聚合
用量落库与聚合
for resp in stream_responses:
log_usage(
user_id=resp.user,
feature=resp.route, # 功能维度的标签
model=resp.model,
channel=resp.channel,
prompt=resp.usage.prompt_tokens,
completion=resp.usage.completion_tokens,
cached=resp.usage.get("cached_tokens", 0),
)
# 按日聚合：成本 = 各类 token 数 × 当日单价（单价从配置读）
# 输出分布看 P50 与 P95，只盯平均值会漏掉成本长尾常见 usage 字段读法
| 字段 | 含义 | 用途 |
|---|---|---|
| prompt_tokens | 输入 token 总数 | 上下文规模与压缩收益监控 |
| completion_tokens | 输出 token 总数 | 输出长度治理与上限校准 |
| cached_tokens | 命中缓存的输入部分 | 缓存折扣核算 |
| total_tokens | 本次调用合计 | 配额与预算对账 |
单价放配置表而不是写在代码里：厂商调价时只需改数据，历史账单还能按当时价格重算，避免新旧口径混算。
聚合维度要在埋点时一次设计好：事后想按租户或渠道拆分，却发现日志里根本没有该字段，只能重新埋点再等数据积累。