尧图网站建设 
目录前言一、先把价目表钉死谷值到底怎么算二、峰值只占一周的 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.103.009.00deepseek-v4-flash谷值0.051.504.50deepseek-v4-pro峰值0.309.0027.00deepseek-v4-pro谷值0.154.5013.50两个模型的上下文都是 1M，最大输出 384K。调价前的旧价（无峰谷、无分档，来自调价公告与报道）：模型输入输出deepseek-v4-flash1.002.00deepseek-v4-pro3.006.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.hourhiforlo,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 倍。第一眼看上去没得比。四、三种负载，四种花法光看单价没用，得算总账。我构造了三个负载画像，覆盖缓 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.103.009.00deepseek-v4-flash谷值0.051.504.50deepseek-v4-pro峰值0.309.0027.00deepseek-v4-pro谷值0.154.5013.50两个模型的上下文都是 1M，最大输出 384K。调价前的旧价（无峰谷、无分档，来自调价公告与报道）：模型输入输出deepseek-v4-flash1.002.00deepseek-v4-pro3.006.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.hourhiforlo,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 倍。第一眼看上去没得比。四、三种负载，四种花法光看单价没用，得算总账。我构造了三个负载画像，覆盖缓