DeepSeek 官宣 API 将大幅涨价：新价格未公布，开发者先重算成本

DeepSeek 在 2026 年 8 月 6 日向开发者发出价格调整预告：近期将整体上调 API 服务定价，并明确提示“预计涨幅较大”。截至目前，官方尚未公布新价格、生效日期，也没有说明缓存命中价、缓存未命中价和输出价会按什么比例调整。

这条消息直接影响把 DeepSeek 当作默认模型的产品。眼下能确认的是“将涨价”，无法确认涨多少、何时执行。开发者现在最有价值的动作，是按现行用量测算不同涨幅下的成本，并等待正式价格表，而不是依据未经确认的倍数提前充值。

已确认的信息只有三项

本次预告提供的信息很短，边界也很清楚：

• 调整对象是 DeepSeek API 服务的整体定价。
• 官方预计涨幅较大，并提醒用户合理安排使用。
• 具体方案以之后的正式通知为准。

“整体上调”通常比单一模型或单一计费项调价影响更广，但官方还没有披露覆盖范围。因此，V4 Flash 与 V4 Pro 是否采用相同涨幅，缓存命中优惠是否保留，免费额度是否变化，目前都不能下结论。

网页端和 App 的普通对话服务也没有出现在已公开的调价说明中。现阶段应把影响范围限定在 API 用户，不宜把消息扩展为 DeepSeek 全线产品开始收费或涨价。

现行价格将成为成本测算基线

DeepSeek 官方定价页在公告发布时列出的人民币价格如下，计费单位均为每百万 tokens：

同一次请求可能同时产生缓存命中输入、缓存未命中输入和输出 tokens，最终费用取决于三部分实际用量。对长系统提示词、多轮对话和代码仓库上下文较多的 Agent 应用来说，缓存命中率会显著改变实际账单，仅拿输出单价乘总 tokens 容易高估或低估成本。

官方新价格尚未发布，上表只能作为调价前的基线，不能当作未来价格。团队可以先用最近 7 天或 30 天的真实用量，分别模拟上涨 50%、100% 和 200% 的情形：

这只是压力测试，不是对 DeepSeek 最终涨幅的预测。它的作用是让团队提前看到毛利、套餐额度和用户限额可能出现的缺口。

Agent 产品会最先感到成本变化

聊天产品的一次请求往往只产生一轮或少量多轮调用。代码 Agent、研究 Agent 和自动化客服则可能在一个任务内连续调用模型、工具和检索服务，失败重试还会继续增加 tokens。API 单价上涨后，这类产品的单任务成本会被调用链放大。

受影响更明显的团队通常有以下特征：

• 把 DeepSeek 设为默认模型，用户每次操作都会触发调用。
• 提供固定月费或买断制服务，但没有设置 tokens 上限。
• 长上下文占比高，且没有持续监控缓存命中率。
• 免费用户量大，模型成本主要由付费用户补贴。
• 工作流包含多 Agent 协作、自动重试或长时间后台任务。

内容工具和内部助手也需要关注，但调整压力取决于调用频率。低频生成文章大纲、摘要或运营文案的团队，即使单价明显上升，月度绝对增量仍可能有限。高频 Agent 产品则要同时看每任务成本和任务成功率，避免为了省 tokens 而牺牲完成质量。

小团队现在可以做四件事

1. 保存真实用量基线

按模型拆分最近一个完整周期的缓存命中输入、缓存未命中输入、输出 tokens 和失败重试量。不要只看账户总支出，否则正式价格发布后很难判断哪个环节导致成本增长。

2. 给核心功能做涨价压力测试

为每个付费套餐计算单用户毛利，并用 50%、100%、200% 三档涨幅测试。若某一档已经让套餐亏损，可以提前准备限额、超额计费或模型路由方案，但不必在正式价格公布前仓促上线。

3. 检查缓存与上下文

固定系统提示词、稳定的知识库前缀和重复对话上下文有机会提高缓存命中。团队还应删除无效历史消息，限制不必要的工具回传内容，并区分需要 V4 Pro 的复杂任务与可由 V4 Flash 处理的常规任务。

4. 做可切换的模型层

如果业务代码直接绑定单一模型名和返回格式，临时迁移会很痛苦。可以把模型选择、超时、重试、工具调用兼容和用量记录放到统一适配层，再用一组真实任务评估候选模型。价格只是一项指标，迁移决策还要看成功率、延迟、输出长度和人工返工成本。

下一份正式通知才是决策点

接下来需要观察四个字段：新价格、生效日期、各计费项涨幅，以及余额和既有合同如何处理。若官方同时调整峰谷时段、并发限制或免费额度，团队还要重新评估任务调度方式。

在这些细节落地前，现行价格仍是唯一可靠基线。先把成本结构算清楚、把模型调用层做成可切换，再根据正式价格表决定是否改套餐、限额度或迁移模型，风险会比追逐未经确认的涨价传言小得多。