DeepSeek在2026年8月17日调整了API价格:旗舰模型V4-Pro输出价从6元涨到27元,缓存命中输入从0.025元涨到0.30元(涨1100%),同时引入行业少见的峰谷分时定价——闲时价格是高峰的一半。这不是态度变化,是产能约束:8月1日V4-Flash单日消耗8万亿token,其中5万亿来自免费额度。而涨价的杀伤力并不均匀,它取决于你的Agent负载结构。这篇给一套算法:先算清你的token分布,再决定该优化缓存、该砍上下文,还是该把任务挪到夜里。
关键词:DeepSeek调价、峰谷定价、Agent成本、token优化、缓存命中率、上下文管理、V4-Pro
一、两个矛盾的数字
2026年5月,DeepSeek宣布了一轮降价,宣传语是”永久降价75%”。
2026年8月17日00:00,V4-Pro系列API新价格生效,旗舰模型输出价从每百万token 6元涨到27元。三个月,同一个季度,一家刚宣布永久降价的厂商涨价350%。
同一份调价表里还有一条更刺眼的:
| 项目 | 调价前 | 高峰时段 | 闲时 | 高峰涨幅 |
|---|---|---|---|---|
| V4-Pro 输出 | 6元 | 27元 | 13.5元 | +350% |
| V4-Pro 输入(缓存未命中) | 3元 | 9元 | 4.5元 | +200% |
| V4-Pro 输入(缓存命中) | 0.025元 | 0.30元 | 0.15元 | +1100% |
| V4-Flash 输出 | 2元 | 9元 | 4.5元 | +350% |
单位都是元/百万token。峰谷时段按北京时间切分:每天9:00-12:00、14:00-18:00算高峰,其余为闲时,闲时价格是高峰的一半。
调价同时,V4-Pro结束了测试阶段,全面转为正式商用服务。
先说清楚一件事:这次不是简单涨价,是引入了一个新的价格维度。 调价前你只有一个价,调价后有两个,而它们差2倍。绝大多数厂商涨价是统一涨,DeepSeek选择按时间切分——第四节会拆这个选择,它比涨价的幅度更值得注意。
二、产能是被什么吃穿的
2.1 8万亿token的一天
2026年8月1日,开源Agent工具OpenCode披露,DeepSeek V4-Flash在该平台单日消耗8万亿token。
这个数字需要有个参照系。同一时期,大模型路由平台OpenRouter接入了400多款模型,全平台日均token调用量约6.6万亿。
一个模型在一个入口里一天的消耗,超过了一个路由平台全平台的日均。
8万亿里的构成更值得注意:其中5万亿来自免费试用额度,3万亿来自付费。8月3日到9日那一周,OpenRouter榜单上V4-Flash周调用量8.83万亿token,环比增长570%,排全球第一。
免费额度占了单日消耗的62.5%。这个比例是后面所有解释的基础——涨价的第一动因不是付费用户用得多,是免费流量把产能吃穿了。
2.2 涨价前13天的信号
8月4日,距离新价格生效还有13天,DeepSeek API开始频繁返回”容量不足”。
到了9月,媒体报道的标题变成了”周日闲时也服务器繁忙”——注意这四个字,闲时。8月17日之后闲时单价已经是高峰的一半,如果闲时都忙,说明产能缺口不是靠错峰能解决的。
2.3 底账
公开报道提到,DeepSeek手里大约有2万张H系列等效芯片,训练和推理在同一个资源池里争抢;自建的乌兰察布智算中心没有完全交付。从4月开始,公司密集招聘数据中心运维、IDC设计规划的工程师。
把供需两侧的数字摆在一起:
供给侧:约 2 万张等效芯片,训练推理同池,智算中心未交付
需求侧:单日 8 万亿 token,其中 62.5% 来自免费额度
同期 OpenRouter 全平台日均 6.6 万亿
产能是按问答时代的成本结构规划的,需求已经是Agent时代的量级。 这个错配是本次调价最直接的解释,比任何”商业策略”之类的说法都更接近事实。
三、Agent把负载结构换掉了
产能不够是个供给问题,但需求为什么涨到8万亿,需要解释。
阿里云可观测团队公开过一组数据,样本是近一周数百位用户、近三万个session,总token数千亿级。里面有个数字:
output token 只占总量约 0.35%。
其余99.65%的token是什么?是让模型反复读取它已经知道的东西。
同一份数据里还有几个细节:
| 观察维度 | 数据 |
|---|---|
| output / total | 约 0.35% |
| 全局 cache_read / input | 约 87% |
| 输出 50-200 token 的调用 | 占总消耗 37% |
| 输出 200-500 token 的调用 | 占总消耗 28% |
| session步数 6-15步的产出密度 | 1.14% |
| session步数 200+步的产出密度 | 0.24% |
| 典型浪费:无新证据的重复工具调用 | 超过半数会话出现 |
前两档合计占65%的token消耗,而这两次输出区间的共同特征是:模型最终只写了50到500个token,但在写之前读了大量内容。
Manus团队披露过他们在生产环境的输入输出比,大约100:1。Spheron的实测更极端,agent推理任务里input到output的原始比率达到267:1,prefill占比85%-95%。
3.1 两种负载不是一个量级
| 维度 | 问答时代 | Agent时代 |
|---|---|---|
| 单次输入 | 数百至数千token | 数十万token |
| 调用次数 | 1 | 数十到数百轮 |
| 成本结构 | 以输出为主 | 以输入为主 |
| 每轮实际产出 | 全量 | 增量 |
问答时代一个请求算一次钱,Agent时代一个任务算几十次到几百次钱,而且每一次都要把之前的全部历史重发一遍。同一份token量,两种模式的账单差着数量级。
DeepSeek的2万张卡是在需求还是问答模式时规划的。当需求切换到Agent模式,产能不变而单位时间消耗翻了几十倍,价格必须动。
3.2 一个反直觉的推论
99.65%的token不是产出这件事,会改变你对优化方向的判断。
多数人看到”Agent很贵”的直觉反应是”让模型少输出点”。但output只占0.35%。真正烧钱的是读取,而且是你自己让模型反复读的那部分。
这一条会在第六节变成具体的优化顺序。
四、峰谷定价是在用价格做调度
先回到调价表。行业里多数厂商涨价是统一的:贵了大家一起承担。DeepSeek这次的做法是引入时间维度,把单价劈成两档。
这个机制不新,电力行业用了上百年:峰谷电价,用价格杠杆引导用电负荷避开高峰。
区别在于大多数API厂商不这么做,原因是调度难度——调用方是分散的客户端,你没法要求它什么时候发起请求。DeepSeek的做法是把调度权交给价格:你想省50%,就自己挑时间。
对使用方来说,这意味着一个此前不存在的选项:
调价前:同一份负载,账单唯一
调价后:同一份负载,
高峰调用 = X 元
闲时调用 = X ÷ 2 元
峰谷价差恒定是2倍,因为它由”闲时=高峰的一半”这个定义直接决定。所以挪动的收益天花板是50%,没有例外。
4.1 峰谷价差还有一个隐藏作用
统一定价下,高峰期的无效流量是纯亏损——刷接口、重试风暴、无意义的轮询检查,这些消耗的产能和有效请求一样,但没有任何产出。
峰谷价差天然抑制这类流量。用户会自己把重试从10点挪到凌晨3点。这是在用价格机制筛掉那些本来就不该在高峰跑的请求。
4.2 什么样的负载该挪
| 负载类型 | 能不能挪 | 原因 |
|---|---|---|
| 实时对话 | 不能 | 延迟敏感,挪了就崩 |
| 在线服务的同步接口 | 不能 | 同上 |
| Agent长任务 | 部分可以 | 非交互的计算步骤可以挪 |
| 批量文档处理 | 必须挪 | 延迟几小时无所谓 |
| 离线评测、回归测试 | 必须挪 | 通常本来就夜间跑,天然匹配 |
| 定时报表、数据同步 | 必须挪 | 可调度 |
判断标准很简单:这个结果什么时候必须出来? 什么时候必须,就别挪;不必须,就挪。
五、算一遍:一个30轮Agent session现在多少钱
抽象讨论不如算一笔具体的账。下面这个模型的结构来自阿里云可观测的公开数据形态:
- 30轮session
- 静态前缀2.3万token(系统提示3000 + 工具定义20000)
- 每轮新增内容从8000递增到53000(用户输入 + 工具返回 + 模型输出回喂)
- 输出约为新增内容的30%
跑一遍的结果:
| 项目 | token | 占总token | 涨价后成本占比 | 单价变化 |
|---|---|---|---|---|
| 未命中输入 | 892,500 | 48.2% | 51.9% | 3→9元(+200%) |
| 输出 | 267,750 | 14.5% | 46.7% | 6→27元(+350%) |
| 缓存命中输入 | 690,000 | 37.3% | 1.3% | 0.025→0.30元(+1100%) |
单session总成本:
调价前 4.30 元
涨价后(高峰) 15.47 元 +260%
涨价后(闲时) 7.73 元 +80%
5.1 缓存涨1100%,为什么只占账单的1.3%
这是这次调价里最容易算错的地方。
缓存命中输入涨了1100%,是三条里最猛的。但它在这个session里只贡献了0.21元,而未命中输入贡献8.03元。涨得最猛的那一项,恰恰是账单里最不重要的那一项。
原因不难理解:Agent的静态前缀(系统提示、工具定义)每轮都能命中,这部分单价再低也省不到哪里去。真正花钱的是每轮新增的那些内容——工具返回的文件内容、命令输出、日志、上一轮的模型回复。这些内容每一轮都是新的,无法命中缓存。
5.2 一个必须说清的口径差异
上面这个模型的 cache_hit/input 是44%。而阿里云公开的全局数据是87%。
两个数字不矛盾,但口径完全不同。阿里云那个数是一周约3万个session的全局值,里面短会话占很大比例——短会话里静态前缀占绝对多数,缓存命中率自然高。
而这里用的模型是30轮长会话。长会话的缓存命中率反而更低,因为每轮新增的大量内容稀释了静态前缀的比例。
这一点值得单独说,因为它推翻了一个流行建议(见下节)。
六、三个杠杆,收益差很多
现在可以做优化决策了。把能做的三件事在同一份账单上比较:
| 优化动作 | 收益 | 天花板在哪 |
|---|---|---|
| 负载挪到闲时 | 50% | 峰谷价差固定2倍,不可能更高 |
| 每轮新增内容砍一半 | 约26% | 只影响未命中那51.9%的一半 |
| 缓存命中率 44%→80% | 约10% | 高命中率时这项占比趋于0 |
峰谷调度的收益大于所有内容优化的总和。 这是最反直觉也最实用的一条。
6.1 “提高缓存命中率”这个建议过时了
如果只按涨幅看,缓存命中涨了1100%,最该优化的是它。但把成本结构摊开就明白了:命中率越高,这一项占总账单的比例越小,而它已经是账单里最小的部分了。
从44%提到80%,未命中输入从51.9%降到约21%,省下约10%。真实但有限。
真正该做的是让”缓存命中”这个分类失去意义。 如果整段历史都能命中,未命中那51.9%就不存在了。
具体的做法是压每轮新增的内容:
- 工具输出硬截断,比如只给2000行/50KB,grep结果单行500字符以内
- 完整内容落盘,需要时再按需读取,而不是一次性全塞进上下文
- 把大段的文件schema、详细定义追加到轨迹末尾,不要插回前缀——因果注意力决定了末尾追加不影响已算过的部分
- 缓存间隔太长导致前缀失效时,综合成本反而可能高于不用缓存
6.2 三个杠杆各自的适用条件
不是所有负载都能享受50%的峰谷收益,这取决于你的负载结构:
你今天的高峰账单占比 能省多少
─────────────────────────────────────
100%(全在高峰) 50%
70% 35%
50% 25%
20% 10%
0%(本来就夜间跑) 0%
先算这个占比,再决定要不要投入精力做调度改造。
七、两个能直接跑的工具
7.1 token结构体检
先跑这个,看清楚你的钱花在哪:
#!/usr/bin/env bash
# token 结构体检:输入实际用量,输出成本构成和优化优先级
# 用法:./token_audit.sh <缓存命中输入> <未命中输入> <输出>
# 支持 1.5M / 300K / 1500000 写法
PEAK_IN_MISS=9.0; PEAK_IN_HIT=0.30; PEAK_OUT=27.0
parse() {
local v="$1"
case "$v" in
*M|*m) echo "${v%[Mm]}" | awk '{printf "%d", $1*1000000}' ;;
*K|*k) echo "${v%[Kk]}" | awk '{printf "%d", $1*1000}' ;;
*) echo "$v" | tr -d '_' ;;
esac
}
audit() {
local hit miss out
hit=$(parse "$1"); miss=$(parse "$2"); out=$(parse "$3")
local total=$((hit + miss + out))
[ "$total" -eq 0 ] && { echo "输入不能全为 0" >&2; return 1; }
local ch cm co
ch=$(awk -v h=$hit -v p=$PEAK_IN_HIT 'BEGIN{printf "%.4f", h*p/1000000}')
cm=$(awk -v m=$miss -v p=$PEAK_IN_MISS 'BEGIN{printf "%.4f", m*p/1000000}')
co=$(awk -v o=$out -v p=$PEAK_OUT 'BEGIN{printf "%.4f", o*p/1000000}')
printf '%-14s%14s%12s%14s\n' "项目" "token" "占比" "成本(高峰)"
printf '%-14s%14s%12s%14s\n' "--------------" "--------------" "------------" "------------"
printf '%-14s%14s%11.1f%%%14s\n' "缓存命中输入" "$hit" \
"$(awk -v h=$hit -v t=$total 'BEGIN{print h/t*100}')" "$ch"
printf '%-14s%14s%11.1f%%%14s\n' "未命中输入" "$miss" \
"$(awk -v m=$miss -v t=$total 'BEGIN{print m/t*100}')" "$cm"
printf '%-14s%14s%11.1f%%%14s\n' "输出" "$out" \
"$(awk -v o=$out -v t=$total 'BEGIN{print o/t*100}')" "$co"
echo ""
local top
top=$(awk -v ch=$ch -v cm=$cm -v co=$co \
'BEGIN{ if (cm>=ch && cm>=co) print "miss"; else if (ch>=cm && ch>=co) print "hit"; else print "out" }')
case "$top" in
miss) echo " 1. [最高] 压每轮新增内容:工具输出、文件、日志进历史后每轮重发"
echo " 大输出硬截断,完整内容落盘,schema 移到轨迹末尾"
echo " 2. 负载挪到闲时(21点-9点、周末),峰谷价差固定 2 倍"
echo " 3. 提高缓存命中率 —— 高命中率会让这项占比变小" ;;
hit) echo " 1. [最高] 缓存占账单大头 —— 提高前缀稳定性收益最大"
echo " 时间戳、余额等易变内容分离出稳定前缀"
echo " 2. 负载挪到闲时" ;;
out) echo " 1. [最高] 输出占比高 —— 控制输出长度,或把重生成换成局部修补"
echo " 2. 负载挪到闲时"
echo " 3. 检查是否有无新证据的重复生成" ;;
esac
}
audit 690000 892500 267750 # 30轮Agent session
跑一个30轮Agent session的用量(690000 / 892500 / 267750),输出是:
项目 token 占比成本(高峰)
缓存命中输入 690000 37.3% 0.2070
未命中输入 892500 48.2% 8.0325
输出 267750 14.5% 7.2293
优化优先级:
1. [最高] 压每轮新增内容
2. 负载挪到闲时
3. 提高缓存命中率
换成短会话为主的场景(8700000 / 1000000 / 350000),结论会反过来变成”输出占比高”,因为缓存项在这里是账单大头。同一份工具,两种负载给出两种不同的优先级,这比任何通用建议都更实用。
7.2 峰谷调度核算器
看清占比之后,算挪动能省多少:
#!/usr/bin/env python3
"""峰谷调度核算器:算清负载挪到闲时能省多少。
价格单位:元/百万token(DeepSeek V4-Pro,2026-08-17 起)
高峰:北京时间 9-12点、14-18点;闲时 = 高峰的一半
"""
from dataclasses import dataclass
PRICE = {
"peak": {"in_miss": 9.0, "in_hit": 0.30, "out": 27.0},
"idle": {"in_miss": 4.5, "in_hit": 0.15, "out": 13.5},
}
PEAK_HOURS = {(9, 12), (14, 18)}
@dataclass
class Usage:
in_miss: float = 0
in_hit: float = 0
out: float = 0
def cost(self, band: str) -> float:
p = PRICE[band]
return (self.in_miss * p["in_miss"]
+ self.in_hit * p["in_hit"]
+ self.out * p["out"]) / 1_000_000
def __add__(self, other: "Usage") -> "Usage":
return Usage(self.in_miss + other.in_miss,
self.in_hit + other.in_hit,
self.out + other.out)
def is_peak(hour: int) -> bool:
return any(lo <= hour < hi for lo, hi in PEAK_HOURS)
def evaluate(buckets: dict) -> dict:
"""buckets: {小时: Usage}"""
peak, idle = Usage(), Usage()
for h, u in buckets.items():
if is_peak(h):
peak += u
else:
idle += u
total = Usage()
for u in buckets.values():
total += u
now = peak.cost("peak") + idle.cost("idle")
ideal = total.cost("idle") # 全部挪到闲时的理论下界
return {"now": now, "ideal": ideal, "saving": now - ideal,
"peak_ratio": peak.cost("peak") / now if now else 0}
# 三个预设场景
scenarios = {
"30轮Agent session,全在高峰": {
10: sum((Usage(in_hit=23_000, in_miss=8_000 + i * 1_500,
out=(8_000 + i * 1_500) * 0.3) for i in range(30)),
Usage())
},
"离线批量,凌晨3点": {3: Usage(5e7, 2e7, 5e6)},
"混合:日间批 + 夜间批": {
10: Usage(2e7, 5e6, 2e6),
2: Usage(3e7, 8e6, 3e6),
},
}
for name, buckets in scenarios.items():
r = evaluate(buckets)
print(f"\n{name}")
print(f" 高峰账单占比 {r['peak_ratio']*100:>5.1f}%")
print(f" 当前成本 {r['now']:>8,.2f} 元")
print(f" 挪到闲时后 {r['ideal']:>8,.2f} 元")
print(f" 可省 {r['saving']:>8,.2f} 元 ({r['saving']/r['now']*100:.0f}%)")
三个场景跑出来的结果:
| 场景 | 高峰账单占比 | 可省 |
|---|---|---|
| 30轮Agent session,全在高峰 | 100% | 50% |
| 离线批量,凌晨3点 | 0% | 0% |
| 混合:日间批 + 夜间批 | 57.1% | 29% |
可省比例几乎就等于高峰账单占比。 因为峰谷价差固定2倍,能挪走的部分省一半,挪不走的部分一点不省。
八、结语
不打算在这里感慨”国产大模型免费午餐到头了”。这次调价有明确的供需解释:2万张等效芯片、训练推理同池、智算中心未交付,对上单日8万亿token的调用量,其中六成还是免费流量。价格必须动,这不是商业策略问题。
真正值得记的是另一个数字:output只占总token的0.35%。
这个数字说明,你的钱几乎全部花在”让模型读取”上,而不是”让模型产出”上。涨价把这块的成本抬高了3.5倍,而且这部分是你控制不了的——决定权在模型那侧,在你的调用侧。
你能控制的是什么时候调,以及每轮带进去多少东西。
峰谷调度能省最多50%,砍每轮新增内容能省26%,提高缓存命中率能省10%。三个数字放在一起,优先级是清楚的。
留一个判断:当一个厂商把”永久降价75%”和”涨价350%”放在同一个季度里,而中间发生了什么变化可以用”output占0.35%”这一个数字解释——那么你该重新算的不是模型值不值钱,而是你的负载结构健康不健康。
