三个月前刚宣布永久降价,这个季度涨价350%:DeepSeek的峰谷定价怎么算

三个月前刚宣布永久降价,这个季度涨价350%:DeepSeek的峰谷定价怎么算

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%”这一个数字解释——那么你该重新算的不是模型值不值钱,而是你的负载结构健康不健康。


Comments

No comments yet. Why don’t you start the discussion?

发表回复