DeepSeek涨价了！但是具体涨了多少？

目录

• 先看一下我的 Token 用量
• Flash 实际涨了多少？
• 再看 Pro 的价格
• 那为什么会这样？
• 缓存率可能比涨价本身更重要
• 简单总结一下

---

DeepSeek 涨价了。

看价格表的话，部分价格涨了好几倍，最高的看上去甚至接近 12 倍。但是实际负担价格并没有提升这么多。

因为不同类型 Token 的用量差距非常大。尤其是日常使用中缓存率比较高的情况下，涨价得最多的那一项，可能本来就只占账单里很小的一部分。

以我自己和朋友实际使用情况测算一下。

先看一下我的 Token 用量

上周总共消耗了：

输入 Token：971,729,018
其中缓存：843,197,440
输出 Token：4,197,467

这里的输入 Token 里面，已经包含了缓存命中的部分。所以真正没有命中缓存、需要按照正常输入价格收费的 Token 是：

971,729,018 - 843,197,440 = 128,531,578

也就是说，三种 Token 的数量分别为：

类型	Token 数量
缓存未命中输入	128,531,578
缓存命中输入	843,197,440
输出	4,197,467

把输出 Token 当作 1，它们的比例大约是：

30.6 : 200.9 : 1

为了后面好算，我们直接近似成：

缓存未命中输入 : 缓存命中输入 : 输出
              30 :              200 : 1

这也是为什么不能只看价格表中的最高涨幅：输出价格虽然涨得很显眼，但我的缓存命中输入是输出的 200 倍，缓存未命中输入也有输出的 30 倍。

Flash 实际涨了多少？

先带入 DeepSeek 的旧版价格：

30 × 1 + 200 × 0.02 + 1 × 2 = 36

再看低谷时段价格：

30 × 1.5 + 200 × 0.05 + 1 × 4.5 = 59.5

新版高峰期价格则是：

30 × 3 + 200 × 0.1 + 1 × 9 = 119

放在一起看就是：

价格	相对成本	相比旧价格
旧价格	36	1 倍
低谷时段价格	59.5	约 1.65 倍
高峰时段价格	119	约 3.31 倍

所以，虽然价格表中部分单价看上去涨了很多，但按照我的实际 Token 比例，低谷时段价格的负担大约上涨了 65%，高峰期则变成了原来的 3.3 倍左右。

这里的 36、59.5 和 119 是为了方便比较得出的相对成本，不是具体账单金额。不过比例不变，所以不影响我们判断实际涨幅。

如果完全按照我上周的 Token 数量计算，对应费用大约是：

价格	估算费用
旧价格	153.79
低谷时段价格	253.85
高峰时段价格	507.69

再看 Pro 的价格

Pro 也用同样的 Token 比例计算。

旧价格：

30 × 3 + 200 × 0.025 + 1 × 6 = 101

低谷时段价格：

30 × 4.5 + 200 × 0.15 + 1 × 13.5 = 178.5

新价格高峰期：

30 × 9 + 200 × 0.3 + 1 × 27 = 357

结果如下：

价格	相对成本	相比旧价格
Pro 旧价格	101	1 倍
Pro 低谷时段价格	178.5	约 1.77 倍
Pro 高峰时段价格	357	约 3.53 倍

按照上周的实际用量换算，大约是：

价格	估算费用
Pro 旧价格	431.86
Pro 低谷时段价格	761.54
Pro 高峰时段价格	1,523.08

也就是说，Pro 的实际负担大约上涨到了原来的 1.77～3.53 倍，同样没有价格表看上去那么夸张。

那为什么会这样？

主要原因就是：日常使用的缓存率可以非常高。

我上周的缓存命中率大约是：

843,197,440 ÷ 971,729,018 ≈ 86.8%

也就是接近 87%。

在这种情况下，虽然缓存命中输入也涨价了，但价格依然远低于没有命中缓存的输入。而输出 Token 虽然单价涨得最多，数量却非常少。

一般大家的一次请求，输出可能就几百个 Token，但是输入可以轻松上万。系统提示词、聊天记录、工具定义、文件内容等，都会算进输入 Token。尤其是在 Agent 和长对话场景中，输入比输出多几十倍甚至几百倍非常常见。

所以输出价格看起来涨得很凶，但它在总费用中的占比并不一定高。

以 Flash 低谷时段价格为例：

缓存未命中输入：30 × 1.5 = 45
缓存命中输入：  200 × 0.05 = 10
输出：            1 × 4.5 = 4.5
总计：59.5

其中缓存未命中输入占了：

45 ÷ 59.5 ≈ 75.6%

也就是说，费用的大头其实是缓存未命中的输入，占了总费用的四分之三左右。输出只占约 7.6%。

所以对实际账单影响最大的，往往不是输出价格涨了多少，而是你的输入有多少没有命中缓存。

缓存率可能比涨价本身更重要

缓存率是一个非常重要的指标。

还是按照前面的 30 : 200 : 1 来算，此时总输入为 230 份，缓存率约为 87%。低谷时段价格的费用是：

30 × 1.5 + 200 × 0.05 + 1 × 4.5 = 59.5

假设总输入和输出都不变，但是缓存率从约 87% 降到了 50%，那么 230 份输入就会变成 115 份缓存未命中、115 份缓存命中：

115 × 1.5 + 115 × 0.05 + 1 × 4.5 = 182.75

费用就从 59.5 变成了 182.75：

182.75 ÷ 59.5 ≈ 3.07

也就是说，总 Token 数完全没变，只是缓存率从约 87% 掉到了 50%，费用就变成了原来的 3 倍左右。

这可能比涨价本身还要可怕。

简单总结一下

DeepSeek 这次确实涨价了，而且部分单项价格涨幅非常大。但是，对于缓存率比较高、输入远多于输出的日常使用场景，实际账单不会直接按照最高涨幅上涨。

按照我这个中转站上周的 Token 比例：

• Flash 低谷时段价格大约是旧价格的 1.65 倍；
• Flash 高峰期大约是旧价格的 3.31 倍；
• Pro 低谷时段价格大约是旧价格的 1.77 倍；
• Pro 高峰期大约是旧价格的 3.53 倍。

所以实际负担大概是上涨到原来的 1.6～3.5 倍，并没有最高 12 倍那么夸张。

当然，这个结果取决于每个人的 Token 构成。如果你的缓存率很低，或者输出 Token 占比特别高，那么涨价的影响也会更明显。

后面有空我会继续整理开销控制、缓存优化和 Token 监控相关的内容，欢迎关注。