看懂用量明细：模型、Token、缓存与费用怎么算

控制台的用量记录按请求逐条展开，不是只给一个月度总数。这份字段说明帮你把每一列读明白，尤其是"为什么这次比上次贵"这类问题该从哪里看起。

每条记录里有什么

模型与分组 本次请求实际使用的模型、走的协议（Anthropic 还是 OpenAI 兼容）以及服务分组。排查"我明明配的是 A 模型"这类问题，先看这一列——它记的是网关实际收到的模型名，不是你以为发出去的那个。

Token 明细 输入 Token、输出 Token，以及缓存相关的 Token 分开记录。三者的单价不同，这是同样长度的对话费用可能差出几倍的主要原因。

计费方式与费用 不是所有请求都按 Token 计费。网关区分 Token 计费、按次计费、图片和视频等几种模式——图像生成和视频类接口通常按次或按产物计价，跟对话类请求不是一套算法。这一列会标明本次用的是哪种。

请求类型与延迟 调用时间、接口类型和处理延迟。延迟这一列在排查"客户端卡住"时比日志好用：如果网关侧记录的延迟很低，问题多半在客户端到网关之间，而不是模型本身。

带缓存的请求里，命中缓存的那部分输入 Token 单价明显低于常规输入。这带来一个反直觉的现象：两次输入长度完全相同的请求，费用可能差很多——差别在于第二次命中了缓存。

所以看费用波动时，先比对缓存 Token 这一列，再去怀疑别的。长上下文、重复系统提示词的场景尤其明显。

失败的请求记在独立的错误记录里，不混在正常用量中。这样设计的好处是用量统计不会被失败请求污染；代价是排查问题时要记得多看一个地方。

如果你发现客户端报错但用量列表里找不到对应记录，去错误记录里查——通常能直接看到是认证失败、模型不可用还是上游超时。

用量里没有我刚发的请求 最可能的原因是配置没生效，客户端仍在用原来的凭据直连官方接口。这种情况下客户端一切正常，只有用量列表是空的。这也是每次配完都该看一眼用量的原因。

同样的问题，这次贵了不少 按顺序查三件事：模型是不是同一个（看模型与分组列）、输出 Token 是不是更长、缓存有没有命中。多数波动在这三项里能解释。

费用单位看不懂 先看计费方式那一列，确认这条是按 Token 还是按次计价，两者的数字不能横向比较。

用量明细是按请求粒度的，所以可以定位到具体是哪类调用在花钱：

要把不同用途的花费彻底分开，更直接的办法是给不同场景发不同的 API Key，各自设额度——具体做法见「API Key 的额度与有效期怎么设」。