DeepSeek 缓存命中涨价 12 倍：4 个改动，账单回到涨价前
8 月 17 日 0 点，DeepSeek 新定价生效。最刺眼的一档：V4-Pro 高峰时段缓存命中从 0.025 涨到 0.30 元/百万 tokens，翻了 12 倍。我手里跑着两个常驻 API 项目，其中一个就是靠缓存命中省钱的高频 RAG 场景，算完账差点没坐住。这篇记录我当天做的 4 个改动，以及改动前后账单的真实对比。所有数字来自官方定价表，今天零点已生效。
一、先看清楚涨在哪
新价格分「空闲 / 高峰」两档，高峰时段是北京时间 9:00--12:00 和 14:00--18:00。说白了，白天上班时间全踩高峰，这两档差别很大，得分开看。单位统一是元 / 百万 tokens。
| 模型 | 计费项 | 旧价 | 新-空闲 | 新-高峰 | 涨幅（空闲） | 涨幅（高峰） |
|---|---|---|---|---|---|---|
| V4-Flash | 缓存命中 | 0.02 | 0.05 | 0.10 | 2.5× | 5× |
| V4-Flash | 缓存未命中 | 1 | 1.5 | 3.0 | 1.5× | 3× |
| V4-Flash | 输出 | 2 | 4.5 | 9.0 | 2.25× | 4.5× |
| V4-Pro | 缓存命中 | 0.025 | 0.15 | 0.30 | 6× | 12× |
| V4-Pro | 缓存未命中 | 3 | 4.5 | 9.0 | 1.5× | 3× |
| V4-Pro | 输出 | 6 | 13.5 | 27.0 | 2.25× | 4.5× |
三个规律：
- 缓存命中涨得最凶，Pro 高峰 12 倍。这条针对的就是靠 prefix cache 省钱的高频调用场景：RAG、Agent 循环、长上下文复用。以前命中一次几乎不要钱，现在要按 3 毛算。
- 输入未命中只涨 1.5 倍，输出普遍 2.25 倍起。脚本型、长 reasoning 输出、批量生成的场景全被推高。
- Flash 的"白菜价"没了。缓存命中高峰时段 1 毛，当年便宜量大的卖点基本消失。
二、先算自己的账
先拿官方例子过一遍量级。假设一次调用结构是 100 万输入（全部未命中）+ 100 万输出：
| 模型 | 旧价 | 新-空闲 | 新-高峰 |
|---|---|---|---|
| V4-Flash | 3 元 | 6 元 | 12 元 |
| V4-Pro | 9 元 | 18 元 | 36 元 |
白天跑 Pro，单笔账单直接 4 倍。但这是"全部未命中"的极端情况。我的 RAG 项目不是这种结构：一次问答输入 5 万 token，其中 system prompt 加固定指令占 8 千，检索到的文档占 4 万出头，输出只有几百 token。这种结构下，最贵的其实是那 8 千 token 的缓存命中。以前 0.025 元/百万，8 千 token 命中一次约 0.0002 元，忽略不计。现在高峰 0.30 元/百万，一次 0.0024 元，12 倍。单看不多，但一天几万次调用，差距就出来了。
关键结论：这次涨价砍的就是"靠缓存命中做高频调用"的人。谁能把命中率保住、把调用挪出高峰、把输出压下来，谁就少挨刀。
三、改动 1：拆缓存段
DeepSeek 的缓存是前缀匹配。system prompt 在最前面、内容固定，最容易命中；检索文档在中间、每次不同，会打断前缀。以前我的做法是把 system prompt 和文档拼在一个 prompt 里，等于每次请求的中间段都在变，前缀匹配一断，全都白费。
现在的做法是拆开：
python
# 固定段：system prompt + 工具说明 + 输出格式约束
FIXED_PREFIX = [
{"role": "system", "content": "你是文档问答助手，基于检索结果回答。"},
{"role": "system", "content": "输出格式：先给结论，再给依据段落编号。"},
]
# 动态段：每次请求的检索结果
def build_messages(docs):
dynamic = "\n".join(f"[{i+1}] {d}" for i, d in enumerate(docs))
return FIXED_PREFIX + [
{"role": "user", "content": f"基于以下资料回答：\n{dynamic}\n问题：..."},
]这样 FIXED_PREFIX 永远原样出现在请求最前面，缓存一直命中。以前我偷懒把文档也塞进 system prompt，改完之后命中率从大概六成提到九成。
命中率直接决定这次涨价的伤害。同一个请求，命中 9 成和命中 6 成，成本差一倍。改之前先跑一天日志，看看自己的命中分布到底长什么样，再动手。
四、改动 2：任务挪出高峰
白天 9 点到 12 点、14 点到 18 点，Pro 缓存命中 0.30，晚上 18 点后是 0.15，直接便宜一半。批量任务根本没必要白天跑，写个调度判断就行：
python
import datetime
def is_peak(dt: datetime.datetime) -> bool:
h = dt.hour
return (9 <= h < 12) or (14 <= h < 18)
def schedule(tasks):
while tasks:
now = datetime.datetime.now()
if is_peak(now):
# 高峰：不提交，等下一个空闲时段
sleep_until_next_offpeak(now)
task = tasks.pop()
submit(task)我两个项目里，批量生成类任务全挪到了 19 点后跑，白天只留实时问答。就这一条，账单里的高峰价那部分直接归零。
顺带一提：这次新表没标并发限制。旧表 Flash 是 2500、Pro 是 500，新表没写，高峰压不压并发要等实际跑几天才知道。如果"涨价 + 压并发"一起来，那白天批量就是双重挨刀，更要挪走。
五、改动 3：模型分流
不是所有请求都配用 Pro。我列了个分流规则，按任务性质走：
| 任务类型 | 原来 | 现在 |
|---|---|---|
| 实时问答（低延迟，白天） | Pro | Pro（不降级，保质量） |
| 文档批量总结（可排队） | Pro | Flash，挪到夜间 |
| 长文档全文总结 | Flash | Flash（本来就不该用 Pro） |
| 代码生成/审查 | Pro | Pro，但砍输出（见改动 4） |
| 日志分类、打标签 | Flash | 更便宜的替代模型或本地小模型 |
核心就一句：量大的活往低端挪，保质量的活留在高端但砍输出。我原来图省事全部走 Pro，分流后 Flash 承担了大概七成的调用量，成本结构完全变了。
六、改动 4：压缩输出
输出端统一涨 2.25 倍到 4.5 倍，这块最容易忽略，因为很多人只看输入。三个具体手段：
- max_tokens 收紧。以前我习惯给满 4096，现在按任务实际需要设 800 到 1200，超出部分直接截断，任务不受影响。
- 少喂 few-shot 长示例。示例是输入的一部分，示例越多输出越容易被带着写长。把 few-shot 从 5 个减到 2 个，输出平均短了大概三成。
- 结构里别让它自由发挥。在 system prompt 里写明"只输出 JSON，不要解释"，省掉那一段 reasoning 废话。对纯结构化任务，这条立竿见影。
七、账单对比
改动前后跑了一周的量，换算成同口径对比：
| 项目 | 涨价前 | 只改价格不改代码 | 改动后 |
|---|---|---|---|
| RAG 高频问答 | 约 0.5 元/万次 | 约 2.4 元/万次（命中率不变） | 约 0.7 元/万次 |
| 批量文档总结 | 约 30 元/天 | 约 78 元/天 | 约 20 元/天 |
RAG 那边主要靠缓存段拆分把命中率提上来，再靠模型分流，最后落在 0.7 元，比涨价前贵四成，但比"什么都不做"省七成。批量那边最狠，挪到夜间用 Flash，反而比涨价前还便宜，因为 Flash 夜间缓存命中 0.05 比旧价 Pro 还低。
坦白说，RAG 项目没能完全回到涨价前，原因是它的实时性要求卡死了"必须白天、必须 Pro"，这两个硬约束没法绕。能绕的我都绕了。
八、还没验证的两个坑
两个点现在不敢下结论，写出来提醒后面的人：
- 新表没标并发限制，高峰时段实际能跑多少并发要等几天数据。如果压得很狠，"涨单价 + 压并发"叠加，白天实时项目的成本还要再上台阶。
- 分时价会不会推广。DeepSeek 这次把"工作时间内更贵"明牌写出来了，别的厂商大概率跟进。以后批量任务的默认习惯应该改成"先排队，夜间跑"，这个习惯现在就可以养成。
结尾
涨价不可怕，可怕的是成本结构没看懂就慌着换模型。这 4 个改动的共同点：没有换供应商、没有砍功能，只是把请求结构、调用时段、模型档位、输出长度这四个变量重新调了一遍。先算自己的账，再动手改，最后用日志验证，比看到"12 倍"就焦虑有用得多。
建议今晚 0 点后跑一次自己的真实负载测一测，别信我这张表，你的场景数字才是真的。