每天读一次用量面板：把原始 token 数变成花钱日记

为什么要看原始 token，而不是只看余额

很多人判断今天花了多少钱，只看充值余额掉了多少。但余额是结果，不是过程。它不能告诉你钱花在哪个模型、哪次调用、是输入太长还是输出太长。

聚合站的计费方式是：每个请求按对应模型的官方价乘以 1.3 扣费。也就是说，token 数 × 官方单价 × 1.3 = 这次请求的扣费。只要你拿到每个请求的 token 明细，就能自己还原出花费。

一次请求里有哪些 token 字段

主流模型的响应体中，usage 字段通常包含这几类数字：

• 输入 token（prompt tokens）：你发过去的内容，包括系统提示、历史对话、检索到的文档。
• 输出 token（completion tokens）：模型生成的内容。
• 缓存读取 token（cache read / cached tokens）：命中提示缓存的输入部分，单价通常低于普通输入。
• 缓存写入 token（cache write）：把内容写进缓存的那一次，部分模型会单独计价。
• 总量（total tokens）：多数情况下是输入加输出，但要注意缓存部分是否被重复计入。

不同厂商的字段命名不完全一致：有的把缓存读取算进输入里再单独列出，有的会拆成 prompttokensdetails。整理数据前，先确认你用的模型返回的是哪种结构，否则会把同一批 token 算两遍。

把面板数字翻译成花费

用量面板一般按请求列出时间、模型、输入、输出、缓存等列。要把它变成“花钱日记”，可以做三步：

1. 按天分组：把同一自然日的请求归到一起，注意时区，跨零点的请求容易分错天。
2. 按模型分类：不同模型的官方单价差很多，混在一起算总量意义不大，分开统计才能看出是谁在吃预算。
3. 按 token 类型分列：输入、输出、缓存读取各占一列，缓存命中率高的时候，这部分能明显拉低实际支出。

单项花费的算法是：该类 token 数 ÷ 该模型的计价单位 × 官方单价 × 1.3。你不需要记住每个模型的单价，只需要知道面板里的 token 数是原始量，最终的倍数由平台统一施加。

三个容易被忽略的细节

• 重试和失败的请求：有些请求没拿到结果但仍消耗了输入 token，如果面板把它们算进去，日花费会比你直觉的高。反过来，客户端自动重试也会重复计费。
• 流式响应：用 stream 模式时，usage 可能出现在最后一个数据块里，如果中途断开，这条请求的用量可能不完整。
• 缓存与上下文的边界：长对话每一轮都会带上历史，输入 token 会随轮次增长。面板上输入列持续变大，往往不是模型变贵了，而是你没有裁剪上下文。

用一张表做每日花费日记

不需要复杂工具，一张表格就能跑起来。建议列：

• 日期
• 模型名
• 请求次数
• 输入 token 合计
• 输出 token 合计
• 缓存读取 token 合计
• 当日折算花费
• 备注（当天做了什么实验、哪个任务最耗）

每天花两分钟从面板抄一次，一周后你就能看出规律：哪类任务输出占比高、缓存到底有没有生效、哪个模型其实可以换成更便宜的。

让明天的数字更好看

看懂 token 之后，优化方向会很具体：

• 能复用系统提示的，开启提示缓存，让缓存读取 token 替代普通输入 token。
• 长文档先摘要再提问，减少每轮的输入负担。
• 简单任务用小模型，把大模型留给真正需要推理的请求。
• 控制 max_tokens，避免模型在无关紧要的回答上生成过量输出。

这些做法不会改变 ×1.3 的计费倍数，但会改变被乘的那个 token 数。每天读一次用量面板，就是把这件事变成习惯的最简单方式。