DeepSeek 的 V4 API 定价已从简单的模型选择问题转变为计时问题。

该公司的官方 API 定价页面现在列出了 DeepSeek V4 Flash 和 DeepSeek V4 Pro，具有 100 万个令牌的大型上下文窗口、OpenAI 格式和 Anthropic 格式的基本 URL，以及缓存命中输入、缓存未命中输入和输出令牌的单独计费类别。 Techmeme 8 月 13 日汇总的报告称，DeepSeek 正在提高 V4 型号价格并引入动态高峰/非高峰计费，新定价将于 2026 年 8 月 16 日世界标准时间 16:00 生效。

这使得这一变化不仅仅是例行的价格表更新。 对于运行大量检索代理、长上下文编码助手、批量分析作业或面向客户的 AI 产品的团队来说，DeepSeek 请求的成本现在可能不仅取决于选择的模型，还取决于发送请求的时间以及可以从缓存中提供多少提示。

DeepSeek V4 计费中的变化

DeepSeek 当前的 API 文档介绍了 V4 Flash 和 V4 Pro 可以通过 OpenAI 风格和人类风格的 API 格式。 这很重要，因为许多开发人员已经通过兼容层将 DeepSeek 与其他提供商一起路由，而不是编写特定于提供商的应用程序代码。

值得注意的计费结构是缓存命中输入、缓存未命中输入和输出之间的分离。 实际上，这意味着重复的提示前缀、系统指令、工具模式或长的可重用上下文块可以具有与新提交的提示文本不同的成本概况。 这已经是 DeepSeek V4-Pro 成本故事的重要组成部分。 新的高峰/非高峰层增加了另一个变量：相同的工作负载可能会根据其运行时间而定价不同。

二次报告指出，V4 型号的材料价格上涨，并且从 8 月 16 日开始实行动态计划。 一些社区计算声称，对于特定的缓存密集型情况，特别是在缓存命中定价急剧变化的情况下，百分比增长非常大。 在与实时发票或 DeepSeek 的当前计费表进行检查之前，应谨慎对待这些数字。 然而，发展方向已经足够明确：API 消费者不能再仅通过标题模型能力和名义每个代币费率来评估 DeepSeek V4。

为什么高峰和非高峰定价很重要

高峰/非高峰定价在基础设施市场中很常见，但对于主流 LLM API 来说，这仍然是一种相对较新的模式。 它创造了云和数据团队熟悉的激励措施：将灵活的工作移出昂贵的窗口，为面向用户的请求保留宝贵的时间，并在延迟不重要时让批处理作业等待。

对于人工智能应用程序来说，这有几个实际效果。 实时支持机器人通常无法将客户响应延迟到更便宜的窗口。 每晚的代码库分析作业、文档丰富管道或评估运行通常可以。 代理系统处于中间位置：一些工具调用是交互式的，而其他工具调用可以排队、重试或计划。

这改变了路由问题。 现在，根据质量、延迟和代币价格在模型之间进行选择的网关必须考虑时间。 如果 DeepSeek V4 Pro 在非高峰时段具有成本效益，但在高峰时段价格昂贵，则应用程序可能会在白天更喜欢其他模型，并稍后返回 DeepSeek。 如果 V4 Flash 对快速任务仍然有吸引力，但缓存经济性因长共享前缀而恶化，则提示架构本身可能需要审查。

对于使用 AI API 网关的团队来说，最有用的功能可能不是另一个模型切换。 它可能是策略：立即发送交互式请求，对非紧急作业进行排队，在请求进入较高成本窗口时发出警告，或者在批量运行开始之前应用团队级预算。 这与模型门式基础设施直接相关，因为当提供商价格是动态而非静态时，统一计费、使用情况分析和路由控制变得更有价值。

谁受影响最大

最大的影响可能会落在具有可预测工作负载的大容量开发人员和企业身上。 消费者聊天产品、编码代理平台、研究工具、数据清理服务和内部自动化团队都可能发送大量类似的请求。 这些系统通常受益于即时缓存，但它们也对数百万或数十亿个令牌中乘以的每个令牌的微小更改很敏感。

通过 OpenAI 兼容接口使用 DeepSeek 的团队不应假设兼容性使他们免受计费更改的影响。 该请求可能看起来很熟悉，但发票仍然遵循 DeepSeek 的特定于型号的定价规则。人为格式的访问从另一个方向产生了同样的问题：更简单的集成并不能消除了解提供商计费类别的需要。

维护定价计算器、经销商仪表板或内部退款工具的开发人员应该快速更新假设。 如果产品中的定价表仍然将 DeepSeek V4 视为单一的固定每个代币成本，则可能会低估或夸大实际使用情况。 这可能会扭曲客户利润、团队预算和模型选择决策。

采购和财务团队也应该注意。 动态 API 定价使得每月预测变得更加困难。 如果用户流量集中在高峰时段，那么在测试中可以承受的工作负载在生产中的表现可能会有所不同。 同样的风险也适用于演示、评估和代理基准测试：一天中某个时间运行的模型比较可能并不代表连续运行相同工作流程的经济性。

团队现在应该做什么

立即采取的步骤是将技术迁移与财务验证分开。 如果应用程序已通过支持的 API 格式调用 DeepSeek V4 Flash 或 V4 Pro，则可能不需要更改代码。 但计费假设、警报和仪表板确实需要审查。

工程团队应确定哪些 DeepSeek 工作负载是交互式的，哪些是可推迟的。 如果产品要求允许，批量汇总、嵌入相邻丰富、存储库分析、合成数据生成和评估套件都是非高峰调度的候选者。 代理框架不仅应该记录令牌计数和模型 ID，还应该记录请求时间、缓存命中行为和输出量。

团队还应该重新检查提示缓存策略。 如果可重用的上下文块仍然比未缓存的输入便宜，那么缓存仍然很有价值。 如果特定模型和时间窗口的缓存命中定价大幅上涨，则可能值得缩短系统提示、拆分工作流程或比较其他提供商以执行重复的长上下文任务。

仍不确定的是每个工作负载的确切实时价格影响。 DeepSeek 的官方文档确认了定价页面中可见的模型格式、上下文窗口和计费类别，而二级报告则描述了 8 月 16 日高峰/非高峰激活和价格上涨。 精确的成本增量取决于当前活动表、发送请求的时间、缓存行为和输出长度。

更广泛的教训是不确定性较小。 LLM 定价即将开始实施。 模型选择、请求计时、缓存设计和预算策略现在相互关联。 对于开发者和企业来说，AI API成本控制不再只是部署后的电子表格练习；这是生产人工智能系统需要如何路由的一部分。