仪表盘显示 7 天消耗 4 亿 token,看似吓人——但拆开看,真实成本一个月才几十块。
现象
hermes insights 显示:
- 输入 477 万 + 输出 92 万
- Total 4 亿(对不上?)
真相:Total = 输入 + 输出 + 缓存读 + 缓存写 + 推理
4 亿的真实构成:
| 项目 | 数量 | 占比 |
|---|---|---|
| 缓存读取(cache read) | 3.99 亿 | 98.6% |
| 输入 | 447 万 | 1.1% |
| 输出 | 76 万 | 0.2% |
| 推理 | 33 万 | 0.08% |
“4 亿"几乎全是缓存读取——不是真的消耗了 4 亿新 token。
为什么有这么多缓存读
长会话场景(如 QQ 单窗口聊天):每轮对话都要把整个会话历史重新发给模型。但历史大部分没变,被**上下文缓存(cache)**命中——服务端只收极低的缓存价,不重新计费。
单轮实测:发一条消息,输入 2,421 token,但缓存读 23 万(整个历史)。
成本换算
按 DeepSeek V4-Flash 价格(涨价前):
| 项目 | 数量 | 单价 | 成本 |
|---|---|---|---|
| 缓存读 | 3.99 亿 | 0.02 元/百万 | ~8 元 |
| 输入(未命中) | 447 万 | 1 元/百万 | ~4.5 元 |
| 输出 | 76 万 | 2 元/百万 | ~1.5 元 |
| 周成本 | ~14 元 |
结论
- 仪表盘的"Total token"极具误导性——缓存读占绝对大头,但单价极低
- 长会话 + 上下文重发型用量,恰好是缓存定价最友好的场景
- 即使 DeepSeek 涨价(2026-08 预告大幅上调),影响也有限——大头是本就便宜的缓存读
- 真省钱方向:控制会话长度(减少缓存读总量),但边际收益小
怎么看真实成本
- 关注
cache_read_tokens的单价(0.02 元/百万),别被总量吓到 - 中转服务(如 opencode-go)可能不返回价格信息(
cost_status: unknown),账单以中转后台为准