DeepSeek V4 涨价后，API 成本怎么重新算：峰谷时段、缓存命中与中转倍率清单
DeepSeek V4 Pro 正式版上线后，API 定价改成峰值与非峰值两套价格，V4-Flash 和 V4-Pro 的缓存命中、缓存未命中、输出 token 价格也不同。本文用官方价格表拆解真实成本，并给出选择中转渠道和改造调用策略时的核对清单。
正文
DeepSeek V4 涨价后，API 成本怎么重新算：峰谷时段、缓存命中与中转倍率清单
如果你的程序还在用旧的 DeepSeek API 单价估算预算，2026 年 8 月 16 日之后，账单模型已经不够用了。
DeepSeek V4 Pro 正式版上线，同时 API 定价引入了峰值和非峰值时段。官方定价页现在同时列出 V4-Flash-0731 与 V4-Pro-0813，并分别区分缓存命中、缓存未命中和输出 token。对普通聊天请求来说，这只是价格表多了几行；对长上下文、工具调用和 AI 编程代理来说，同一条请求在不同时间发出，成本可能直接翻倍。
本文不把“涨价”简单等同于“不能用”，而是回答三个更实际的问题：怎么重新算一条请求的成本，哪些任务适合安排到非峰值时段，以及通过中转 API 使用时如何避免只看倍率却算错最终价格。
价格核对时间：2026 年 8 月 18 日（UTC）。实际扣费仍应以账户当时的价格页、账单和具体渠道条款为准。
先看懂 DeepSeek V4 的新价格结构
DeepSeek 官方说明，V4 系列的 API 新价格从 2026 年 8 月 16 日 16:00 UTC 起生效；非峰值价格是峰值价格的一半。官方定义的峰值时段是每天 01:00–04:00 UTC 和 06:00–10:00 UTC，其余时间属于非峰值。
截至本文核对时，官方价格表如下，单位均为美元 / 1M tokens：
| 模型 | 缓存命中（非峰值 / 峰值） | 缓存未命中（非峰值 / 峰值） | 输出（非峰值 / 峰值） |
|---|---|---|---|
| DeepSeek-V4-Flash-0731 | $0.007 / $0.014 | $0.22 / $0.44 | $0.66 / $1.32 |
| DeepSeek-V4-Pro-0813 | $0.022 / $0.044 | $0.66 / $1.32 | $1.98 / $3.96 |
这张表有三个容易被忽略的地方：
- 峰值不只是输出变贵。 输入缓存命中、输入缓存未命中和输出三项都会按峰值价计算。
- 缓存命中与未命中差距很大。 如果长上下文每次都被当成未命中，单看“模型每百万 token 多少钱”会严重低估成本。
- Flash 和 Pro 的差异要按任务算。 Pro 的价格更高，但复杂推理、长代码修改或工具调用失败重试的次数，也可能决定最终成本，而不是单价本身。
用两个例子重新估算账单
例子一：1M 输入未命中 + 200K 输出
假设一次请求有 1M 输入 token，缓存没有命中，输出 200K token：
- V4-Flash 非峰值：
1 × 0.22 + 0.2 × 0.66 = $0.352 - V4-Flash 峰值：
1 × 0.44 + 0.2 × 1.32 = $0.704 - V4-Pro 非峰值：
1 × 0.66 + 0.2 × 1.98 = $1.056 - V4-Pro 峰值：
1 × 1.32 + 0.2 × 3.96 = $2.112
同一个请求只因为发送时段不同，Flash 和 Pro 都会出现约两倍的价格差。对于批处理、离线评测、代码库索引和日报生成，这已经足以影响排队策略。
例子二：1M 输入命中缓存 + 200K 输出
如果这 1M 输入 token 命中缓存，V4-Flash 的估算变成：
- 非峰值：
1 × 0.007 + 0.2 × 0.66 = $0.139 - 峰值：
1 × 0.014 + 0.2 × 1.32 = $0.278
这里输出 token 反而成为主要成本。也就是说，压缩重复上下文有帮助，但限制无效输出、工具调用循环和过长 reasoning 同样重要。
以上只是官方标准价的算术示例，不包含中转站倍率、账户优惠、余额规则、失败重试或其他增值服务费用。真实账单应使用 API 返回的 usage 字段与渠道账单交叉核对。
哪些任务值得安排到非峰值时段
不是所有流量都应该为了省钱延迟。可以先把任务按时效分成三类：
可以延迟的任务
- 批量摘要、离线分类和数据清洗
- 代码仓库索引、文档向量化和夜间评测
- 非实时的回归测试与候选模型对比
- 报表、日报和低优先级内容生成
这些任务可以进入队列，在 UTC 非峰值时段执行。不要只按服务器本地时区写死时间，跨地区团队应统一用 UTC 计算，并给时段切换留出几分钟缓冲。
不应为了价格强行延迟的任务
- 用户正在等待的对话
- 生产故障定位和恢复
- 有明确 SLA 的实时 Agent
- 需要立刻完成的支付、风控或人工协作步骤
这类请求更适合按优先级选择模型和备用渠道，而不是让用户等待非峰值价格。
需要先观测再决定的 Agent 任务
AI 编程代理和工具型 Agent 往往同时包含实时步骤与可延迟步骤。可以把“理解任务、决定是否调用工具”保留在实时路径，把批量检索、长文档总结和回归评测放入非峰值队列。但这需要记录每个步骤的模型、token、时段、重试次数和失败原因，不能只在任务结束后看总账单。
通过中转 API 使用时，别只看“倍率”
如果你通过中转渠道调用 DeepSeek V4，至少要把下面四层价格分开：
- 官方基础价：当前模型、峰值/非峰值、缓存命中/未命中和输出 token 的价格。
- 渠道标价或倍率：渠道是否对不同模型、不同分组、不同时间段使用不同倍率。
- 账户规则：是否有充值门槛、余额扣费顺序、最低消费、活动有效期或并发限制。
- 请求实际成本：实际 token、缓存状态、重试次数和是否发生 fallback。
例如一个渠道宣传“低倍率”，但只对非峰值输入生效；或者把缓存命中、缓存未命中统一按一个价格展示，最终都可能让预算失真。比较渠道时，应要求对方明确：
- 是否完整透传
usage，能否看到缓存命中信息； - 峰值时段是否沿用官方分时价格，还是渠道自行设定统一价格；
deepseek-v4-flash和deepseek-v4-pro是否对应官方模型版本；- 工具调用、Responses API、Anthropic 兼容接口是否真的可用，而不是只支持基础聊天；
- 失败重试和自动切换是否会重复计费；
- 并发限制是上游限制、渠道限制，还是账户分组限制。
如果无法得到清晰答案，不要用一条成功请求就判断渠道“便宜”或“稳定”。先用脱敏样本做小额验证，记录请求模型、时段、输入输出 token、返回错误和最终扣费。
给模型路由和成本治理的四条规则
规则一：把“任务优先级”和“模型能力”分开
高优先级不一定需要 Pro，复杂代码修改也不一定适合 Flash。路由记录应同时包含任务类型、时效要求、上下文长度、工具调用风险和模型选择原因。
规则二：把缓存命中率纳入预算
不要只设置“每月多少 token”的总额度。至少按模型统计缓存命中率、未命中输入 token、输出 token 和重试 token，否则团队无法解释预算为什么突然上升。
规则三：把峰值价格当成真实上限
非峰值价格适合做优化目标，峰值价格才是实时流量的预算上限。预算告警、渠道比较和 fallback 评估都应按峰值价做一次压力估算。
规则四：模型升级后重新做回归
V4-Pro GA 的调用方式和模型名变化，要以官方发布说明与当前文档为准。即使 API 代码不用改，也应重新检查工具调用、结构化输出、长上下文、并发和失败重试。价格变化与能力变化同时发生时，不能只因为单价低就自动扩大流量。
结论：先算清真实成本，再决定要不要换模型
DeepSeek V4 的变化并不是简单的“价格变贵”。它把成本拆成了模型、缓存状态、输出长度和时间段四个变量，也把模型路由从“选 Flash 还是 Pro”变成了“什么任务、什么时段、用什么渠道、是否值得重试”。
对实时请求，重点是能力、失败兜底和峰值预算；对离线任务，重点是队列调度、缓存命中和实际 usage；对中转用户，重点则是把官方价格、渠道倍率、账户规则和最终扣费逐项对齐。
在做决定前，先用一小批真实但脱敏的请求验证三件事：模型版本是否对应、usage 是否完整、账单是否能按价格表复算。算不清的低价，通常还不能算作真正的低成本。