一个月跑了 15 亿 Token，我的 DeepSeek 账单只有 81 块

前几天我把 7 月份的 DeepSeek API 账单完整导了出来。

结果有点出乎意料：

一个月调用 13,256 次，消耗 15.04 亿 Token，最终费用只有 81.34 元。

平均下来，每天 428 次调用、2.62 元。每次 API 请求的平均成本只有 0.006 元。

如果只看「15 亿 Token」这个数字，很容易得出一个结论：DeepSeek 真便宜。

但把账单拆开以后，我发现真正值得关注的，其实不是价格，而是另外一个东西：

Cache。

15 亿 Token，到底花到哪里去了？

先看整个 7 月的数据：

指标	数据
API 请求	13,256 次
总 Token	15.04 亿
输入 Token	14.97 亿
输出 Token	715.6 万
总费用	81.34 元
平均每天	2.62 元
平均每次请求	0.0061 元

我的主要使用场景不是普通聊天，而是让 Agent 长时间运行。

这类系统有一个非常典型的特点：每次调用模型之前，都要带上一大堆东西。

比如 System Prompt、Skills、工具定义、Memory、历史上下文等。

所以我的平均一次 API 请求，输入竟然达到了：

11.29 万 Token。

但真正新增的内容并没有这么多。

把输入 Token 再拆开：

• 缓存命中：14.60 亿
• 缓存未命中：3671.8 万
• 缓存命中率：97.55%

换句话说，一次典型请求大概是这样的：

已有 Prompt / Skills / Context
约 110,000 Token
        ↓
新增内容
约 2,800 Token
        ↓
DeepSeek
        ↓
输出
约 540 Token

看起来每次都背着一个十几万 Token 的巨大上下文，但其中绝大多数内容其实没有按照正常输入价格重新计费。

最反直觉的是这笔账

7 月份 14.60 亿缓存命中的 Token，一共只花了：

29.24 元。

而另外 3672 万缓存未命中的 Token，却花了：

37.32 元。

再加上 716 万输出 Token，花了 14.78 元。

最终组成了这 81.34 元：

类型	Token	费用
缓存命中 Input	14.60 亿	29.24 元
缓存未命中 Input	3672 万	37.32 元
Output	716 万	14.78 元
合计	15.04 亿	81.34 元

这组数字让我重新理解了一件事：

优化 AI 成本，不能只看 Token 数量。

14.6 亿 Token 并不可怕。

真正贵的反而是那 3672 万没有命中缓存的 Token。

这有点像网站流量。

假设一个网站每个月产生 15TB 流量，但其中 97% 都被 CDN 缓存了，真正打到源站的流量其实很少。

你不能看到「15TB」就判断服务器成本一定很高。

AI 的 Token 也是一样。

所以，“省 Token”可能从一开始就问错了问题

我们平时谈 AI 成本优化，很容易陷入一种直觉：

Prompt 短一点，历史记录少一点，Skill 少加载几个，Token 自然就省了。

这个方向不能说错，但不完整。

因为真正应该优化的是：

高价 Token，而不是所有 Token。

假设为了减少上下文，我把一个稳定的大 Prompt 拆得非常碎，每次根据任务动态拼装。

总 Token 确实可能下降。

但如果因此破坏了稳定的 Prompt 前缀，让缓存命中率从 97% 大幅下降，最后完全可能出现一种反直觉的情况：

Token 少了，账单反而贵了。

所以现在如果再让我看一个 Agent 的成本，我不会只看 Total Tokens。

我会看：

Total Tokens
      ↓
Input / Output
      ↓
Cache Hit / Cache Miss
      ↓
各自单价
      ↓
最终 Cost

Token 数量只是表象，Token 的结构才决定成本。

那是不是完全不用优化上下文了？

也不是。

我的数据里还有一个值得警惕的数字：

平均每次请求输入超过 11 万 Token。

虽然因为缓存存在，这些 Token 很便宜，但「便宜」和「合理」是两回事。

十几万 Token 的上下文依然可能带来其他问题。

比如大量无关 Skill、历史信息和 Memory 同时进入 Context，会降低上下文的信噪比。模型理论上能读完，不代表每一段信息都能被有效利用。

所以后面我还是会继续做 Context 优化。

但目的已经变了。

以前可能是：

为了省 Token，把 Context 砍短。

现在更准确的目标应该是：

为了提高信噪比，让真正需要的信息进入 Context，同时尽量保持稳定结构，提高 Cache Hit。

这两种优化思路看起来很像，底层逻辑却完全不同。

81 块钱背后，其实是三件事情

回头看这份 7 月账单，15.04 亿 Token 最终只花了 81.34 元，并不是单纯因为「DeepSeek 便宜」。

至少有三个因素同时存在：

第一，模型本身价格低。

7 月绝大多数请求使用的都是 Flash 模型，占请求量约 99%。

第二，缓存命中率极高。

97.55% 的输入 Token 命中了缓存，大量重复 Context 没有按照普通输入价格收费。

第三，Agent 的任务结构天然适合缓存。

System Prompt、Skills、工具定义等内容大量重复，真正变化的只是每轮新增的少量信息。

这三件事情叠加起来，才出现了：

13,256 次调用，15.04 亿 Token，最终 81.34 元。

所以这一个月最大的收获，并不是发现 DeepSeek 可以便宜到什么程度。

而是让我对 AI 成本有了一个更具体的认识：

不要再问「用了多少 Token」。

应该问：

这些 Token 里，有多少是 Input，有多少是 Output，有多少命中了 Cache，又有多少是真正需要按高价重新计算的 Token？

在 Agent 时代，Token 就像云计算时代的流量。

流量大小决定规模，流量结构决定账单。

而真正值得优化的，从来不是那个最大的数字。