DeepSeek 将于 8 月 17 日调整 API 定价，实时工作负载面临压力

DeepSeek 将于 8 月 17 日调整 API 费率，推出双时段高峰定价机制，使请求时机成为推理成本的直接组成部分。该公司表示，非高峰时段的使用成本将仅为高峰时段的一半。对开发者而言，眼前的矛盾很明确：灵活的批处理任务可以追逐更低费率，而面向客户的应用却无法简单地等待。

这一变更将自 2026 年 8 月 17 日北京时间午夜起生效。高峰时段为北京时间上午 9:00 至中午 12:00，以及下午 2:00 至 6:00。根据 DeepSeek 的官方定价页面，其余所有时段均被归类为非高峰时段。

这不仅是又一次 token 费率调整。DeepSeek 正在为访问时机赋予明确的时间价值，将应用程序的调度安排转化为成本控制机制。这使其低成本定位与智能体、客服系统、编程产品及其他必须即时响应的服务的运营需求产生张力。

这一模式类似于云计算中的容量定价：能够容忍延迟的任务若接受不确定的启动时间，便可获得更优惠的待遇。例如，Google 推出了面向无需立即启动、且具有明确运行时长任务的 Flex-start VMs。DeepSeek 则在更贴近模型 API 的层面应用了类似的经济信号。

结果是将 API 客户分成两类。能够控制工作负载运行时间的团队获得了新的优化杠杆；服务实时用户的团队则要承担部分由时钟决定的费率，即便其应用和 token 用量保持不变。

DeepSeek 将于 8 月 17 日调整什么

DeepSeek 正以按日程对同一模型活动收取不同费率的机制，取代原有的全天统一费率结构。

更新后的结构涵盖 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro，也适用于主要计费类别：缓存输入、未缓存输入和生成输出。因此，在高峰窗口内处理的 token，与在该窗口外处理的等量 token，费用将不同。

API，即应用程序编程接口，使软件无需使用面向消费者的聊天界面，也能向模型发送请求。开发者通常按处理 token 的数量和类型付费。Token 是代表单词、词语片段、数字或标点符号的小型单位。

按照 DeepSeek 的安排，每天有 7 个小时落在两个高峰窗口内，其余 17 个小时为非高峰时段。该日程遵循北京时间，而非各客户所在地时间，因此其实际影响因地区而异。

第一个窗口为北京时间上午 9:00 至中午 12:00。第二个窗口从下午 2:00 开始，到下午 6:00 结束。两个窗口之间间隔两小时，在中国工作日的中间形成了一个短暂的非高峰时段。

北美开发者通常会在傍晚或夜间遇到这些窗口，具体取决于所在地和夏令时规则。这使得美国和加拿大许多日间服务较容易获得非高峰访问。亚洲团队则更可能在正常工作时间面临高峰定价。

截至 8 月 14 日可访问的定价页面将 DeepSeek-V4-Flash-0731 和 DeepSeek-V4-Pro-0813 列为当前版本。两者均支持思考与非思考模式、100 万 token 上下文窗口、工具调用、JSON 输出，以及 DeepSeek 的 Responses 和兼容 Anthropic 的 API。

该页面还列出了两款模型各自的并发限制。并发指服务允许同时处理的请求或处理流数量。它之所以重要，是因为若延迟的工作负载随后遭遇容量瓶颈，较低费率的价值就会下降。

DeepSeek 尚未公布详细的需求曲线，解释为何选择这些具体窗口；也未发布利用率数据，说明当前各时段的流量规模。据 South China Morning Post 报道，该公司此前在发给订阅者的消息中，将按时定价与更优资源分配和服务稳定性联系起来。

这一解释合乎逻辑，但它仍是公司给出的理由，而非经过独立验证的容量研究。8 月的日程揭示了 DeepSeek 希望需求向何处转移，却没有说明这些时段之外存在多少闲置容量，也没有说明这一激励能否消除拥堵。

对客户而言，最稳妥的理解应是从运营角度出发：同一请求现在有两种可能的计费结果，决定因素是 DeepSeek 何时处理它。新结构生效后，仅基于月度 token 用量的成本预测将不再完整。

最低费率如今需要调度控制能力

DeepSeek 最具吸引力的经济性将属于那些能够等待、排队或跨时区转移的工作负载。

部分模型活动天然具备灵活性。公司可以延后文档索引、夜间评估、合成数据生成、报告起草或大规模分类。这些任务可以进入队列，并在非高峰窗口开启时启动。

这种灵活性在新体系下变得更有价值。团队可以按紧急程度标记请求，为实时任务保留立即执行，并将后台工作延后处理。它们也可以将处理分散到全天，而不是总在固定的本地时刻启动每一批任务。

面向客户的产品则自由度更低。客服助手必须在客户在线时作答；编程助手必须在开发者工作时响应；搜索功能不能仅因底层模型进入高峰时段，就将查询搁置数小时。

智能体应用还面临额外复杂性。一个智能体在完成一项用户任务时，可能发出多次模型调用，包括规划、检索、工具选择、验证和修订。因此，其成本既取决于 token 用量，也取决于完成任务前所需的步骤数量。

缓存可以减少重复输入处理。DeepSeek 的上下文缓存系统会将可复用的提示材料存储在磁盘上，并尝试在后续请求中复用。该公司的缓存文档将其描述为降低重复上下文成本的方法。

但缓存并不能消除时机问题。DeepSeek 的新日程区分缓存输入与未缓存输入，同时对两者都适用高峰和非高峰定价。一款缓存复用率极佳的产品，在用户于指定窗口到来时，仍可能面临更高费率。

因此，团队应评估完整任务，而非孤立的 token。即使模型输入费率较低，若其需要更多推理步骤、生成更长输出或需要重试，吸引力也可能下降。反之，如果模型能以更少调用完成工作，即使标价更高，仍可能具有经济性。

这种任务层面的视角对自主系统尤为重要。与简单的问答界面相比，它们的消耗更难预测。一个用户请求可能一次调用便完成，另一个则可能触发多个工具和多轮模型推理。

新结构也会改变预算告警机制。固定的每日 token 阈值将不再对应固定的支出阈值。财务和工程团队需要按模型、token 类别和时间窗口区分使用情况。

这要求计费导出或应用遥测数据中包含清晰的时间戳。团队应记录请求何时开始、由哪个模型处理、是否使用了缓存输入，以及发生了多少次后续调用。缺少这些字段，意外增长将难以解释。

工作负载路由提供了另一种应对方式。应用可以将紧急工作发送给针对延迟和可用性选择的模型，再将后台任务分配给成本更低的路径。该策略需要评估，因为切换模型可能改变输出质量、工具行为、格式和安全表现。

路由层也会增加工程开销。团队必须维护适配多个提供商的提示词、规范化响应、管理不同凭证，并测试故障回退行为。一旦将这些运营成本纳入计算，非高峰执行带来的表面节省可能会缩小。

最有条件从中受益的公司，是那些已经将在线推理和离线推理分开的公司。它们知道哪些任务有严格的延迟目标，哪些可以容忍等待。将所有请求都通过单一同步路径发送的组织，未来需要进行更多重构。

DeepSeek 的价格战策略遭遇容量成本

核心矛盾不再是 DeepSeek 与昂贵竞争对手之间的较量，而是 DeepSeek 的可负担性承诺与服务集中需求的成本之间的冲突。

DeepSeek 帮助将低 API 费率推向生成式 AI 竞争的核心议题。2025 年 2 月，它在低谷时段推出大幅折扣，给中国及国际模型提供商带来压力。Reuters 的报道将此举描述为对竞争对手的挑战，而这些竞争对手当时已在面对 DeepSeek 的低成本模型。

2026 年 8 月的调整并未放弃非高峰访问折扣，而是正式拉大了低需求与高需求时段之间的差距。最便宜的体验仍然可用，但客户必须提供调度灵活性才能获得它。

这意味着商业叙事发生了实质性逆转。低费率曾是简单的获客信息；按时定价则将可负担性转化为有条件的承诺，其价值取决于地理位置、工作负载设计和用户行为。

DeepSeek 表示，该机制有助于资源分配和服务稳定性。这一逻辑遵循基本的基础设施经济学：加速器容量成本高昂，需求在一天中不断变化，而未使用的计算时间无法储存到明天。

较低的非高峰费率会鼓励客户将可延后请求转移至更安静的时段。如果有足够多的用户响应，DeepSeek 就能利用相同基础设施处理更多总工作量，也能减少为应对最尖锐需求峰值所需的服务器数量。

高峰定价则构成该机制的另一面。它要求对延迟敏感的客户在容量竞争最激烈时承担更多费用。这可以为额外基础设施提供资金、抑制非必要使用，或同时实现两者。

不过，这种设计将部分容量管理责任转移给了客户。DeepSeek 不再以单一可预测费率吸收每一次需求高峰，而是要求开发者决定哪些任务值得立即执行。API 的价格成为一种信号，告诉应用提供商更希望它们何时运行。

这种方法在相邻的云市场已有先例。Google 的 Dynamic Workload Scheduler 为可等待计算资源的工作负载提供成本优化访问。其调度器定价将灵活消费与标准容量预期区分开来。

Google 还推出了适用于可容忍延迟的模型请求的灵活推理层级。更广泛的趋势已经很清晰：AI 服务商正越来越多地将紧急计算与可进入队列等待的工作区分开来。DeepSeek 的安排之所以值得注意，在于这种区分以固定的每日时段公开呈现。

固定窗口比不断变化的现货价格更容易理解。开发者无需预测实时市场，也能据此规划。代价是，固定时段未必能反映某一天的实际需求。

公共假期、产品发布或病毒式传播事件，都可能令流量偏离预期模式。DeepSeek 可能在名义上的高峰期拥有闲置容量，也可能在低峰期遭遇拥堵。除非公司修改规则，客户仍将按既定费率计费。

区域因素也令竞争格局更加复杂。北京工作时间与亚洲大部分地区的活跃时段重叠。北美团队则可能发现，其常规工作日大多落在 DeepSeek 的高峰窗口之外。

这意味着，该时间表并不会对所有竞争对手施加同等压力。Alibaba、ByteDance、Tencent、Baidu 及其他面向中国市场的服务商，服务的客户需求通常遵循相近的区域节奏。美国服务商面对的是不同的使用模式，即使其公布的 Token 费率看起来更高。

Alibaba Cloud 展示了另一条竞争路径。其 Model Studio 支持按量付费的模型调用、捆绑 Token 套餐，以及访问多个模型系列。该公司的 token plan 强调汇总用量、模型切换及可预测的订阅式消费。

这些方案与 DeepSeek 的 API 并不直接等同。它们采用不同的访问打包方式，也可能涉及不同的部署区域、模型、配额和性能特征。不过，它们表明竞争对手可以在不复制同一套按钟点划分的时间表的前提下，对基于时段的定价作出回应。

一种回应是提供可预测的月度用量。另一种是为需要保障容量的团队提供预留吞吐量。第三种则是提供接受延迟的灵活层级，而不将客户绑定在固定时段内。

DeepSeek 的优势将不止取决于最低可用费率。开发者还会比较可靠性、模型质量、延迟、上下文处理、缓存行为、数据政策、区域访问能力和集成成本。最便宜的 Token，并不必然意味着完成任务的成本最低。

定价时间表并不保证什么

更低的低峰费率并不保证有闲置容量，而更高的高峰费率也并不保证更好的服务。

DeepSeek 将该政策与改善资源分配和稳定性联系起来。这一时间表可以鼓励更平滑的需求曲线，但该公司并未承诺为支付高峰费率的客户提供特定延迟、可用性水平或处理优先级。

这一区别对生产环境买家十分重要。在繁忙时段收取更高费用，可能让人感觉是在为高级服务付费，即便公开规则只是调整 Token 费率。除非合同或服务文档明确规定，否则团队不应假定自己拥有优先访问权。

低峰用户则面临相反的风险。许多客户可能会将最大的任务安排在低费率时段刚开始的同一时刻。这样的行为非但未必能平滑需求，反而可能在各个窗口边缘形成新的流量陡增。

队列设计可以降低这一风险。团队可以添加随机启动时间、将任务分散到一个时间区间内，或设置内部并发上限。这些措施能够保护客户自身的应用，但不会揭示 DeepSeek 的底层容量情况。

固定时间表也带来了时钟管理问题。应用需要可靠地从北京时间进行转换，包括正确识别日历日期。北京不采用季节性调时，而许多北美和欧洲地区会采用。

围绕固定本地时间转换构建的调度器，可能会在夏令时开始或结束时发生偏移。更稳妥的做法是以协调世界时存储时间戳，并通过程序计算当前对应的北京时间窗口。账单审查也应使用同一套转换逻辑。

临近边界的请求值得特殊处理。一个长时间运行的请求可能在高峰窗口开始前发起，并在其开始后才结束。DeepSeek 的公开定价页面说明了这些窗口，但并未清晰描述这类边界情况以哪个时间戳为准。

请求开始时间、Token 处理时间或完成时间，都可能产生不同结果。流式响应让这种区别更为重要，因为输出会在一段时间内陆续返回。边界流量规模较大的开发者应寻求澄清，并核对首批账单。

重试还带来了另一层不确定性。如果请求在低峰期失败，并在高峰窗口开始后成功，最终费用可能与应用最初的预期不符。这取决于失败和重试的 Token 如何出现在 DeepSeek 的计费记录中。

服务商比较同样需要谨慎。直接比较 Token 费率，可能忽略不同模型为同一任务生成的 Token 数量差异。也可能忽略缓存保留、提示词格式、推理开销，以及决定结果是否需要修订的质量门槛。

基准测试分数不足以解决这一问题。编码模型可能在公开测试中表现良好，却难以适应某家公司的代码仓库规范。推理模型可能回答准确，但耗时过长，或产生不必要的冗长输出。

团队需要衡量每项完成任务成功率的应用专属评估。一个有用的测试集应包含常规请求、困难边界案例、工具故障、长上下文，以及能够测试缓存的重复提示词。

8 月的这次调整也恰逢 DeepSeek 最近更新模型阵容。评估新价格的客户可能也在同步评估模型行为，因此很难单独分离定价本身的影响。总支出的变化可能反映费率、用量增长、输出长度或完成质量。

社区反应可以提供早期预警信号，但不能作为可靠的成本估算。用户指出，重度依赖缓存的工作负载成本显著上升，并讨论 DeepSeek 是否仍具竞争力。这些计算取决于各自的流量模式，不应代替经过测量的生产数据。

因此，最有力的审慎结论是有限的。DeepSeek 已经创造了一种激励，应该会推动部分可灵活安排的需求发生转移。但它尚未证明会有多少流量迁移、可靠性是否会改善，或客户将如何衡量由此增加的复杂性。

新费率生效后值得关注的三个信号

第一个月将显示，基于时段的推理会成为一种持久的运营模式，还是又一次定价实验。

第一个信号是 DeepSeek 在各窗口边界时的服务表现。开发者应在每天每次切换前后跟踪延迟、错误率、排队时间和吞吐量。高峰期出现实质改善，将支持该公司的资源分配论点。

相反的结果则会削弱这一论点。如果客户支付高峰费率，但延迟和可用性保持不变甚至恶化，这项政策看起来将更像一次收入调整，而非服务管理工具。公开状态数据和客户遥测数据将比笼统说法更重要。

第二个信号是实际有多少工作负载发生迁移。团队应比较 8 月 17 日前后在高峰和低峰时段处理的 Token 占比。还应衡量，延迟任务是否会在高峰窗口结束后立即形成新的峰值。

广泛转向低峰执行将强化 DeepSeek 的机制。这将表明，开发者可以将推理时机视为可调整的基础设施变量。迁移幅度有限则意味着，大多数有价值的工作负载对延迟过于敏感，无法重新安排。

第三个信号是竞争对手的反应。中国模型服务商可以通过更低费率、用量套餐、预留容量、更强的服务保障或更便捷的多模型路由来回应。国际服务商则可以强调可预测定价或不设固定区域窗口的灵活推理产品。

如果直接复制 DeepSeek 的时间表，将验证按时段定价成为新的竞争维度。若转向预留吞吐量或月度套餐，则指向另一条路径：买家为可预测性付费，而非追逐低负载时段。

开发者应先进行受控的账单审计，而不是仓促迁移。记录一周具有代表性的模型、时间戳、缓存、Token、延迟和任务成功数据。按新时间表重新计算该工作负载，然后确定哪些任务可以在不损害用户体验的情况下迁移。

接下来，测试一个小规模低峰队列。包括重试限制、随机启动时间、截止时间处理，以及紧急工作的回退路径。比较每项成功任务的完整成本，而不仅是某一 Token 类别的标价。

最后，应随时准备一套服务商中立的评估集。DeepSeek 的 8 月 17 日政策，使工作负载架构成为采购决策的一部分。重要的问题不再是哪种模型宣传的费率最低，而是哪种模型、时机、可靠性与工程投入的组合，能够以最低总成本产出可靠结果。