WaveSpeedAI

DeepSeek V4 定价：比 OpenAI 便宜 20-50 倍（成本分解）

DeepSeek V4 定价：比 OpenAI 便宜 20-50 倍（成本分解）

最近，我一直在寻找一个更便宜的模型，一个我可以频繁调用而不用每小时都看一眼账单的模型。DeepSeek V4 在与其他开发者的讨论中不断出现，通常伴随着一句话：“它……真的很便宜。”

Dora 来了。我在 2026 年 1 月下半月将它集成到一些小工作流中：一个研究摘要器、一个产品笔记重写器和一个周度待办项整理器。没什么花哨的。我关心的是在正常的一周内 token 转化为真实成本。以下是我对 DeepSeek V4 API 成本、重要折扣和一个简单预算方法的发现。

当前 DeepSeek 定价

我不会假装这些数字是稳定的。价格会变动，而且因购买渠道而异（直接购买与通过 OpenRouter 这样的中介）。所以，两个参考点：

  • 查看原始来源：官方 DeepSeek API 文档和定价页面。直接连接时这些是标准费率。
  • 如果你通过市场平台路由，打开他们的模型卡。例如，OpenRouter 上的 DeepSeek 模型列出了每百万 token 的费率和任何基于时间的折扣。 我在 2026 年 1 月下旬在各个提供商看到的情况在本质上是一致的：DeepSeek V4 在输入和输出 token 上都远低于前沿模型。具体的成本有所不同。我分享的是我处理定价的方式，而不是将其冻结在某个时刻。

标准费率

如果你是第一次接触基于使用量的模型计费，两个数字很重要：

  • 输入 token（你发送的内容）：按每百万 token 计费。
  • 输出 token（你得到的内容）：也按每百万 token 计费，通常高于输入。

在我的测试中，V4 的原始费率足够低，以至于每天的小幅峰值不会造成伤害。这在批处理任务中最明显。例如，我的周度待办项整理器发送约 20 个提示，每个约 3000-5000 个输入 token，接收 1000-2000 个输出 token。即使以保守的样本费率计算，整个运行的总成本也停留在”咖啡钱”的范围内。

两个实用提示：

  • 输出膨胀会悄悄靠近你。如果你的提示鼓励长思考，输出行可能会使你的账单翻倍。我设置了 max_tokens 上限并使风格更紧凑。既省钱，结果也更好。
  • 块大小很重要。如果你正在总结长文档，你需要为每个重叠的 token 付费。我从 1600 token 重叠改为 400，没有损失质量。

缓存命中折扣（90% 折扣）

这改变了我的心算。一些平台和模型供应商支持对重复前缀的提示缓存。如果提示的前 N 个 token 不变（系统提示、共享指令、架构），缓存命中可以以陡峭的折扣计费。我在几个供应商的缓存实现中看到了 90% 折扣这个数字（可用性因平台而异：确认你的提供商的定价页面）。

这在实践中是什么样的：

  • 我的研究摘要器共享一个长的、固定的系统提示和一个稳定的工具架构。只有源文本改变。
  • 在第一次调用后，后续调用会命中该共享前缀的缓存。
  • 在接受缓存计费的平台上，那些重复使用的 token 降至折扣费率。

从测试中得到的两个警告：

  • “接近”不会被缓存。改变共享前缀中的一行，你会错过命中。
  • 大的、固定的架构会自我偿还。如果你能将指令和工具整合到一个稳定的前缀中，一次做好，然后享受缓存。

如果你的提供商不支持缓存，你仍然可以通过将重复指导移到一个更短、更一致的系统提示中，并从用户消息中去除冗余来模拟一些节省。

非高峰折扣（75% 折扣）

一些市场平台已经开始提供基于时间的折扣以平衡需求。我见过陡峭折扣的非高峰时段（像 50-75% 折扣这样的数字出现，但取决于转售商和模型）。DeepSeek 模型往往参与其中，因为他们的经济学已经倾向于高效。

这对我的帮助有两种：

  • 我为非高峰时段安排了周度待办项工作。相同的工作负载，更低的成本。
  • 我在夜间批处理研究摘要。延迟不重要，折扣很重要。

这不是普遍的。如果你直接连接到 DeepSeek，请检查他们是否发布任何时间段定价。如果你通过中介，阅读模型卡的小字部分。差价可能大到足以改变你何时运行任务。

为什么 DeepSeek 这么便宜

我想了解低价格是否是促销活动，或者架构是否真的支持它。从公开信息来看，两个方面突出。

MoE 架构

DeepSeek 的新型大模型依赖于混合专家（MoE）。简单来说：不是为每个 token 唤醒整个大脑，路由器选择几个专家子网络来处理它。你仍然获得一个有能力的模型，但每一步只有一小部分参数工作，这降低了计算和成本。

这在实践中为什么很重要：

  • 吞吐量扩展得更好。在我这边，即使在我推动并行工作时，p95 延迟仍保持合理。
  • 成本不随复杂性线性上升。长提示不像在密集、始终运行的模型上那样严重。

我用过其他感觉在利基任务上很脆弱的 MoE 模型：V4 在结构密集的提示（JSON 输出、工具使用）上处理得很稳。这种稳定性也是成本故事的一部分：更少的重试，更少的重做。

Engram 效率

DeepSeek 的文档提到了在上下文处理和内存效率方面的工作（他们在一些版本中突出了改进的注意力路由和 KV 缓存处理之类的东西）。我无法验证内部工作，但我可以分享我观察到的：

  • 长上下文提示在我 2026 年 1 月的测试中没有降低吞吐量。我运行了 32K token 的上下文而没有感到”一切都变得很慢”的感觉。
  • 确定性格式化在比我预期更高的温度下保持不变，这意味着我可以在不降低质量的情况下保持输出更短。

我的看法：价格不是营销噱头。这是架构设计的结果，该架构旨在保持每个 token 的计算成本低，加上愿意在价格上传递这一点。如果你对技术细节感到好奇，从官方 DeepSeek 文档和他们模型卡中的任何链接论文开始。

成本计算器模板

我不再将预算锁定在精确的分数上。我规划范围，然后在实际使用稳定后调整。这是我用于 DeepSeek V4 的模板。它足够简单以在电子表格中重新创建。

你需要为每个工作负载填入的输入：

  • 每天（或每批）的调用次数
  • 每次调用的平均输入 token 数
  • 每次调用的平均输出 token 数
  • 每百万 token 的输入费率（来自你的提供商）
  • 每百万 token 的输出费率（来自你的提供商）
  • 每次调用的可缓存前缀 token（如果没有则为 0）
  • 缓存命中折扣（例如，90% 折扣为 0.90）
  • 非高峰倍数（例如，75% 折扣为 0.25，否则为 1）

步骤：

  1. 分离可缓存和不可缓存的输入 token。

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)

  2. 以折扣费率为可缓存部分定价。

    • cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)

  3. 以完整输入费率为可变输入定价。

    • variable_input_cost = (variable_input / 1,000,000) × input_rate

  4. 以输出费率为输出定价。

    • output_cost = (avg_output_tokens / 1,000,000) × output_rate

  5. 按调用加总，然后应用任何非高峰倍数。

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier

  6. 按数量扩展。

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

一个来自我测试周的小型真实示例（2026 年 1 月 23-30 日）：

  • 120 次调用/天
  • 3200 个输入 token/调用，其中 1800 个是固定的、可缓存的前缀
  • 1100 个输出 token/调用
  • 示例费率：$0.40 每百万输入，$1.60 每百万输出（用你的实际费率替换）
  • 缓存命中折扣：90%
  • 非高峰倍数：0.5（通过转售商使用的 50% 折扣时段）

数学（四舍五入）：

  • 每次调用的可缓存成本 = (1,800/1,000,000) × $0.40 × (1 − 0.90) ≈ $0.0000072
  • 每次调用的可变输入成本 = (1,400/1,000,000) × $0.40 ≈ $0.00056
  • 每次调用的输出成本 = (1,100/1,000,000) × $1.60 ≈ $0.00176
  • 每次调用的原始成本 ≈ $0.0023272
  • 非高峰调整后 ≈ $0.0011636
  • 每天 ≈ $0.14
  • 每月 ≈ $4.20

这不是笔误。低的每百万费率加上缓存和非高峰时段把一个”看着账单”的服务变成了我可以忘记的东西。一开始没有节省时间，我花了一小时使可缓存前缀真正固定，但之后的每次调用都变得更便宜。

我在表格中保留的几个护栏：

  • 对 max_tokens 设置硬上限。输出膨胀是安静的预算杀手。
  • 单独跟踪重试。重试是真实的支出。
  • 每周记录平均 token。随着提示的演进，token 漂移会发生。

谁适合这个：

  • 运行许多小型、相似调用的团队（ETL、摘要、QA）。
  • 有可以移到非高峰的批处理工作的制造者。

谁可能不会喜欢它：

  • 需要全天长流式输出的应用，在高峰时段。节省变窄。
  • 没有缓存支持的设置。你仍然支付低费率，但不是愚蠢低的费率。

如果你想要一个起点，在你选择的工具中重新构建上述模板。这是 10 分钟的设置，之后可以省去数小时的猜测。

最后一个注意： 如果你混合使用提供商，也在你的表格中将所有内容标准化为”每 1K token 的成本”。当你决定是否在循环中保留 V4，或者由于质量原因将任务切换到前沿模型时，这样可以更轻松地进行快速并排比较。

我仍在关注非高峰时段如何变化。最近它们已经向晚上早些时候移动。这对批处理工作来说不是问题，只是我关注的事情。