DeepSeek 涨价 3.4 倍，我算完账决定不换模型——峰谷差 2 倍、缓存差 30 倍，但真正更省钱的是那个「2 倍」
目录
- 前言
- 一、先把价目表钉死
- 谷值到底怎么算
- 二、峰值只占一周的 20.8%
- 三、30 倍的缓存差距
- 四、三种负载，四种花法
- 五、我判断错了：30 倍的杠杆，实际省得比 2 倍的少
- 六、怎么量出你自己的输入输出比
- 七、所以「你换了吗」
- 1. 先看你的输入输出比
- 2. 能异步的全部挪出峰值
- 3. 把缓存命中率当成一个要监控的指标
- 那什么情况下真该换
- 八、脚本
- 小结
- 参考
本文不是 API 调用实测，我手上没有 DeepSeek 的付费 key。它是一份可以自己重跑的算账：
价目表逐条取自官方定价页与 2026-08-13 的调价公告，测算脚本和完整原始输出都在文末，你可以换成自己的
调用量再跑一遍。开头我判断错了一次，第五节是纠正过程——那也是这篇最值得看的部分。
前言
8 月 13 日 DeepSeek 宣布调价，8 月 17 日零点生效，同时上线峰谷计费。旗舰deepseek-v4-pro的输出价格从每百万 token6 元涨到峰值 27 元，谷值 13.5 元。按峰值算是 4.5 倍，按整单算下来我这边的三个负载画像都是 3.3–3.4 倍。
社区里的讨论基本分两派：一派算完峰值价直接说「换 Kimi / GLM」，另一派说「谷值只涨 2.25 倍，还能接受」。两派都只盯着峰谷这一个变量。
我把官方价目表整个摊开算了一遍，发现最该看的不是峰谷：
| 杠杆 | 单价差距 |
|---|---|
| 峰值 vs 谷值 | 2 倍 |
| 缓存未命中 vs 命中 | 30 倍 |
看到 30 倍的时候我的第一反应是「那还讨论什么峰谷，去做缓存啊」。这个反应是错的。算完总账才发现，在相当一部分场景里，那个 2 倍的杠杆反而省得更多。
原因很简单，但很容易忽略：输出 token 不参与缓存，而挪时段是所有单价一起减半。
先给结论：三种典型负载，只要挪到谷值 + 把缓存命中率做到 80%，账单都比涨价之前还低。所以「你换了吗」这个问题，我的答案是不换——但用法得改。
一、先把价目表钉死
所有计算的地基。数字取自官方定价页，单位是元 / 百万 token：
| 模型 | 时段 | 输入（缓存命中） | 输入（未命中） | 输出 |
|---|---|---|---|---|
deepseek-v4-flash | 峰值 | 0.10 | 3.00 | 9.00 |
deepseek-v4-flash | 谷值 | 0.05 | 1.50 | 4.50 |
deepseek-v4-pro | 峰值 | 0.30 | 9.00 | 27.00 |
deepseek-v4-pro | 谷值 | 0.15 | 4.50 | 13.50 |
两个模型的上下文都是 1M，最大输出 384K。
调价前的旧价（无峰谷、无分档，来自调价公告与报道）：
| 模型 | 输入 | 输出 |
|---|---|---|
deepseek-v4-flash | 1.00 | 2.00 |
deepseek-v4-pro | 3.00 | 6.00 |
一个必须说清的缺口：我没有找到旧价的缓存命中单价的可靠公开数字。所以本文所有「旧价」一律按未命中计。
这会高估旧价、低估涨幅——文中的涨幅倍数是保守下界。如果你在调价前就吃满了缓存折扣，
实际感受到的涨幅会比本文的数字更大。这一条影响第六节的结论，我在那里会再提一次。
谷值到底怎么算
「谷值是峰值的一半」是官方页面写明的规则，不是我推的。峰值时段是工作日北京时间 9:00–12:00 和 14:00–18:00。
二、峰值只占一周的 20.8%
这条被讨论忽略得最厉害。把一周 168 小时逐小时判一遍：
PEAK_HOURS=[(9,12),(14,18)]# 北京时间，仅工作日defis_peak(dt:datetime)->bool:ifdt.weekday()>=5:returnFalsereturnany(lo<=dt.hour<hiforlo,hiinPEAK_HOURS)base=datetime(2026,8,31,0,0,tzinfo=timezone(timedelta(hours=8)))# 周一 00:00peak=sum(1forhinrange(168)ifis_peak(base+timedelta(hours=h)))跑出来：
峰值时段：工作日 9:00–12:00、14:00–18:00（北京时间） 一周 168 小时中：峰值 35 小时（20.8%），谷值 133 小时（79.2%） 逐日核对： 周一 峰值 7 小时 周二 峰值 7 小时 周三 峰值 7 小时 周四 峰值 7 小时 周五 峰值 7 小时 周六 峰值 0 小时 周日 峰值 0 小时画成一周的格子图，一眼就能看出比例：
每周只有 35 小时是峰值，剩下 133 小时都是谷值。整个周末都是谷值。
这意味着：如果你的负载是批处理、离线任务、夜间跑的数据管道，那「涨价 4.5 倍」这个说法跟你没关系——你本来就在谷值区间，实际涨幅是 2.25 倍。
反过来，如果你是面向国内用户的在线服务，那 9–12 点和 14–18 点恰好是你流量最高的时候。峰谷计费的设计意图是明摆着的：把能挪的负载挪走，给挪不走的腾出容量。
顺带一提，这个时段表意味着海外用户占了便宜：美西时间的工作日白天对应北京时间的深夜，全是谷值。
三、30 倍的缓存差距
同一张表，换个方向看：
deepseek-v4-flash 峰值 命中 0.10 未命中 3.00 输出 9.00 未命中/命中 = 30 倍 deepseek-v4-flash 谷值 命中 0.05 未命中 1.50 输出 4.50 未命中/命中 = 30 倍 deepseek-v4-pro 峰值 命中 0.30 未命中 9.00 输出 27.00 未命中/命中 = 30 倍 deepseek-v4-pro 谷值 命中 0.15 未命中 4.50 输出 13.50 未命中/命中 = 30 倍 峰值 / 谷值 = 2.0 倍（官方规则） 未命中 / 命中 = 30 倍（两个模型、两个时段都是 30）两个模型、两个时段，未命中比命中都是整整 30 倍。这个比例被维持得如此整齐，说明它是定价时刻意设计的参数，不是凑出来的。
30 倍 vs 2 倍。第一眼看上去没得比。
四、三种负载，四种花法
光看单价没用，得算总账。我构造了三个负载画像，覆盖缓