DeepSeek Flash 明天降价？不，是"回调"——一笔账算给你看TL;DR 速览
定性：9/10 12:00 起 Flash 系列回调价格，而非全面降价 最大降幅：缓存命中输入从 0.05→0.02 元/百万token，降 60% 输出只降一点：4.5→4 元，没回到 8/17 涨价前的 2 元 谁受益：缓存命中率高、输入占比大的应用省得多



一、先说清楚：这次是"回调"，不是"普降"9 月 9 日 DeepSeek 在开放平台发了公告，9 月 10 日 12:00 起调整 Flash 系列（deepseek-v4-flash 和 deepseek-v4-flash-vision-exp）的调用价格。
我把"现在正在执行的价"和"9/10 起生效的新价"并排放在一起（单位：每百万 token，空闲时段）：
计费项
现价
9/10 起新价
降幅
输入·缓存命中
0.05 元
0.02 元
↓60%
输入·缓存未命中
1.5 元
1 元
↓33%
输出
4.5 元
4 元
↓11%
高峰时段（工作日 9:00-12:00、14:00-18:00）价格是空闲时段的2 倍，这个规则不变。
注意一个细节：输入部分这次是"回到 8 月涨价前"，但输出没有。 8/17 前输出是 2 元，现在降完还是 4 元——输出的降幅远小于输入。所以严格说，这次是"输入回调、输出只降一点"，不是"全部回到原价"。看到"最高降 60%"的标题，先别急着高兴——那个 60% 是缓存命中输入，跟你关系大不大，得看你的调用结构。
二、先把"缓存命中"这层讲透这次降幅最大的"缓存命中"，很多人没细想它到底是什么意思。DeepSeek 的计费把输入分成两档：
缓存命中：你发给模型的这部分内容，模型之前已经处理过，直接复用结果。典型如固定系统提示词、长期不变的 few-shot 示例、长对话里反复出现的历史上下文。缓存未命中：模型第一次见的新内容，需要从头算一遍。这是最贵的输入档。为什么缓存命中便宜？因为模型推理最耗算力的，往往不是"You think"，而是"你读一遍上下文"。上下文里重复出现的部分，已经被预计算好了，直接拿出来用，自然便宜。
这次缓存命中输入从 0.05 降到 0.02，等于把这部分几乎砍到零成本。所以如果你平时构建的是"长系统提示 + 固定上下文 + 多轮重复对话"这类应用，你才是这次降价最大的受益人。
三、给你算一笔实账：到底省多少光看百分比容易晕，我用几个典型场景算给你看。
场景 A·通用任务：空闲时段跑一次任务，消耗 100 万 token 输入（缓存未命中）+ 100 万 token 输出。
按现价：1.5 + 4.5 = 6 元按新价：1 + 4 = 5 元单次省 1 元，降幅约 16.7%单看 16.7% 好像不高？但如果你日调用量是"千万级"甚至"亿级"，这 16.7% 就是实打实压下来的成本。
场景 B·重缓存应用：假设某客服机器人，80% 的输入都能命中缓存，每百万 token 输入、百万 token 输出。
按现价：输入 0.8×0.05 + 0.2×1.5 = 0.34，加输出 4.5，共 4.84 元按新价：输入 0.8×0.02 + 0.2×1 = 0.216，加输出 4，共 4.216 元降幅约 12.9%，且随着缓存命中率越来越高，降幅会更接近那"砍六成"的红利场景 C·纯生成：输出占比 90% 以上的应用（写长文、批量生成）。
按现价：0.1×1.5 + 0.9×4.5 = 4.2 元按新价：0.1×1 + 0.9×4 = 3.7 元降幅仅 11.9%——输出只降 11%，你省得最少三个场景对比下来，结论很清楚：这次降价是"偏科"的，重缓存、重输入的应用吃肉，纯生成的应用只能喝汤。
四、一个容易被忽略的点：它是怎么"赚回来"的很多人只看到"降价了"，忽略了两件事：
高峰翻倍还在——工作日 9:00-12:00、14:00-18:00 价格翻倍。如果你的任务不急，挪到晚上或周末跑，价格直接减半。DeepSeek 在更明显地用价格信号引导你把任务错峰，等于用"时间差"换"价格优惠"。它在给新一代 Flash 铺路——9/8 官方开始内测 v4.1 flash 中间版本，宣传点是"能力更强、速度更快、成本更低"。这次 Flash 降价，很大程度是先把价格水位放低，给新模型的面世做铺垫——先用价格稳住存量开发者，等新模型来了再承接性能升级。所以更值得留意的不是"这次降了多少"，而是这轮降价背后，DeepSeek 打算怎么抢 API 市场。用低价稳住存量，用新一代模型完成性能跃迁，这套组合拳的意图很明显。
五、和"8 月涨价"连起来看这轮降价的背景，值得单独讲。8 月 13 日，DeepSeek V4 Pro 正式版上线时，官方同时宣布 API 涨价，V4 Pro 系列最高涨幅达 11 倍。当时就有不少开发者吐槽"高峰涨价太多，没有性价比了"，甚至有团队开始考虑迁移。
所以这次 Flash 的降价，更像是对上一轮涨价的部分回调，而不是亲民降价：
输入端（缓存命中、缓存未命中）：回到 8/17 涨价前水平输出端：仍比 8/17 前贵一倍（2 元 → 4 元）换句话说，DeepSeek 在不同的计费项上做了取舍——把输入打下来留住存量，把输出留着支撑新模型的成本结构。这个策略对谁有利、对谁不利，前面场景 B/C 已经说得很清楚。
六、那段对开发者意味着什么如果你是 API 调用方，我的建议是别急着改代码，先改调用策略：
能错峰的错峰——把批量、非实时任务挪到晚上或周末，成本直接减半。这是最简单、见效最快的优化。提高缓存命中——固定系统提示词、复用长上下文，让更多输入走"缓存命中价"。这比单纯看单价更重要，因为缓存命中输入已经低到 0.02，把未命中转成命中，差价远比等降价来得大。评估输出占比——如果你的应用输出大，这次降价对你的收益有限，别被"降了 60%"的标题带偏，真正影响你账单的是输出量。输出是这次降得最少的一档。长期成本规划——下次衡量用不用 DeepSeek，别只看这一次的降价，把"高峰翻倍""缓存命中率""输入输出占比"都纳入你的成本模型里。做一个简单的 token 成本试算，比盲目信任某个"降价 60%"的宣传可靠得多。七、一个实用的成本试算方法前面讲了那么多，落到实操，我推荐你做一个简单的 token 成本试算表。不用写代码，Excel 或一张纸就能做：
步骤
做法
① 采样
抓一段你真实的调用日志，记录 prompt_tokens / completion_tokens / cache_hit_tokens
② 拆分
把输入拆成"缓存命中"和"缓存未命中"两部分，看比例
③ 套价
分别套旧价、新价，算出单次调用成本
④ 月化
乘以月调用次数，得到月度成本
⑤ 对比
对比新旧价，看你的真实降幅（别信宣传的"60%"）
很多团队算完才发现：自己寄希望于"降价 60%"，实际因为输出占比高，真正降幅只有十几个点。而这个试算，5 分钟就能做出来，比任何宣传都靠谱。
八、几个常见的成本误区最后提醒几个容易踩的坑，都是我在实际项目里常看到的：
只盯着单价，不看用量——很多团队纠结"每百万 token 多少钱"，却忽略了真正烧钱的是调用量。一个应用如果调用量翻 10 倍，单价降 20% 也没用，成本照样爆炸。把"缓存命中"当天然生效——缓存命中率不是白来的，它依赖你把提示词做稳定、把上下文做得可复用。如果每次调用都带上随机的时间戳、随机 ID，缓存命中率会掉到接近 0，那"砍六成"的红利你就吃不到。指望一次降价解决成本问题——降价是平台策略，随时可能变动（8 月刚涨过，9 月又降）。真正靠谱的是把成本模型建起来，让"什么场景用什么模型、什么时候跑"成为一套可复用的决策逻辑，而不是跟着平台价格波动走。说到底，定价是平台的，成本是技术的。 平台怎么定价，你控制不了；但你的调用结构（输入输出占比、缓存命中率、是否错峰）是可以优化的。与其盯着别人的价格表，不如先把自家应用的"成本画像"画出来——这才是能长期帮你省钱的、真正握在自己手里的东西。
我的判断这次不是"DeepSeek 良心发现"，更像一次精准的价格战——用输入端的降幅去抢"输入密集型"的开发者场景（RAG、文档处理、客服），同时保留峰值翻倍做错峰引导，还顺手给新一代 Flash 铺路。对大多数开发者来说，最该做的不是记住"降了多少"，而是算清楚自己的调用里输入、输出、缓存命中各占多少——这笔账，才是决定你月底账单的关键。DeepSeek 这套"降输入、稳输出、加高峰"的组合，本质上是在用价格锚定自己的生态位：它要的不是最便宜，而是让一批重输入的开发者离不开它。 对开发者而言，唯一确定的是变化本身——把成本测算变成习惯，比抓住某一次降价更有用。