最近重新看了一遍 DeepSeek API 的价格。

现在和以前有个比较明显的区别：

同样的模型、同样的 Token 数量，在不同时间调用，成本可能不一样。

所以现在评估 DeepSeek API 成本，已经不能只记一个“每百万 Token 多少钱”。

还要把调用时间算进去。

这篇主要记录一下我现在理解的计算方式，以及做实际项目时会考虑哪些因素。

---

1. DeepSeek-V4-Flash 现在是峰谷计费

先看 DeepSeek 官方价格：

https://api-docs.deepseek.com/zh-cn/quick_start/pricing/

目前 DeepSeek-V4-Flash-0731 区分高峰和空闲时段。

高峰时段：

09:00 - 12:00
14:00 - 18:00

其他时间属于空闲时段。

价格大致是：

类型	空闲时段	高峰时段
输入（缓存命中）	0.05 元 / M tokens	0.10 元 / M tokens
输入（缓存未命中）	1.5 元 / M tokens	3 元 / M tokens
输出	4.5 元 / M tokens	9 元 / M tokens

这里 M tokens = 100 万 tokens。

最近网上说的：

白天“梁文锋”，晚上“梁文谷”

其实就是在调侃这套峰谷价格。

---

2. 对个人测试来说，峰谷价格其实影响不大

如果只是开发阶段偶尔调用几十次，我觉得没必要太纠结。

比如一次请求：

输入：3000 tokens
输出：1000 tokens

即使高峰和低峰价格差一倍，换算到单次请求上也没有多少钱。

真正需要开始计算峰谷成本，一般是 Token 用量已经比较大的时候。

比如：

• 批量内容生成
• 数据清洗
• RAG 数据处理
• AI Agent
• Coding Agent
• 在线客服
• SaaS 内置 AI

这些场景每天跑几百万甚至更多 Token 后，调用时间才会真正影响账单。

---

3. 离线任务其实很好处理

如果任务不要求实时返回，峰谷计费反而挺容易利用。

比如：

知识库预处理
批量摘要
日报生成
文本分类
数据清洗
离线 Agent

这些任务完全可以调度到空闲时段。

以前做任务调度主要考虑 CPU、GPU 和队列。

现在模型 API 也可以多加一个参数：

任务是否允许延迟执行？

如果答案是允许，那就可以把 Token 成本一起放进调度策略里。

---

4. 在线业务的问题不太一样

在线业务没有办法主动选择调用时间。

例如 AI 客服：

15:30 用户发送消息

这个请求肯定得立即处理。

不能因为当前属于 API 高峰价格，就等到晚上再调用。

所以在线业务计算模型成本时，最好不要只拿最低价做预算。

至少应该区分：

低峰 Token
高峰 Token

甚至可以直接按照高峰价格做比较保守的成本预估。

这样上线以后不会发现实际账单明显高于测试阶段。

---

5. 我后来又看了一些固定价格的第三方 API

也是因为峰谷这个问题，我最近顺手看了几个第三方模型 API。

其中一个是算桥API。

它不是单独提供 DeepSeek，而是把 DeepSeek、Qwen、Kimi、GLM、Doubao、MiniMax 等模型放在一个统一 API 平台里。

模型列表：

https://suanjiayun.com/api/modelList

目前它的 DeepSeek-V4-Flash-0731 页面显示：

输入：0.60 积分 / M tokens
缓存命中：0.12 积分 / M tokens
输出：1.20 积分 / M tokens

其中：

1 积分 = 1 元

所以换算后就是：

输入：0.60 元 / M tokens
输出：1.20 元 / M tokens

目前这套价格没有再区分峰谷。

模型页面：

https://www.suanjiayun.com/api/modelDetail/6a83b8db31cc72629e2b9ca3

我觉得这种计价方式和官方峰谷价属于两种不同思路：

官方：
价格随时间变化

固定价 API：
价格不随调用时间变化

具体选哪一种，还是要看业务本身的请求分布。

---

6. 不要只比较“100 万 Token 多少钱”

这一点是我最近比较明显的感受。

只看 Token 单价，其实很容易把模型 API 成本看得太简单。

真正接进项目后，还会碰到：

缓存命中率
输出长度
失败重试
模型切换
并发
超时
限流

举个例子。

两个 API：

A：单价低，但经常失败重试
B：单价稍高，但成功率稳定

最后真实成本不一定是 A 更低。

所以我现在评估 API，大概会看：

Token 单价
+
实际 Token 使用量
+
调用时间
+
缓存命中
+
失败重试
+
稳定性

比单看价格表更接近实际情况。

---

7. 多模型项目还要考虑切换成本

现在一个 AI 项目同时用多个模型已经挺常见。

例如：

普通问答 -> DeepSeek
长文本 -> Qwen
Coding -> Kimi / GLM

如果分别接每一家官方 API，就要维护不同的：

API Key
Base URL
model
计费逻辑
错误处理

所以我现在看 API 平台时，也会顺便看它是不是支持多模型统一调用。

这个和价格没有直接关系，但对长期维护成本影响挺大。

尤其后面做模型路由：

任务 A -> 模型 1
任务 B -> 模型 2
模型 1 异常 -> 模型 3

接口层越统一，业务层越简单。

---

8. 我现在怎么估算 DeepSeek API 成本

如果只是粗算，我会分成三种情况。

个人测试

不用算太细。

直接看 Token 总量即可。

离线批处理

优先按照空闲时段价格计算。

如果任务可以调度，尽量错峰。

在线业务

不能假设所有请求都发生在低峰。

更稳妥的是：

按照实际峰谷请求比例计算

或者直接用偏高的价格做预算。

如果使用固定价格 API，则计算逻辑会简单一些：

总 Token × 固定单价

---

总结

DeepSeek API 开始采用峰谷计费后，我觉得最大的变化不是“晚上便宜”。

而是模型 API 的成本模型又多了一个变量：

时间。

以前主要看：

输入 Token
输出 Token
缓存

现在还得加上：

调用发生在哪个时段

对于离线任务，这反而提供了一个新的成本优化手段。

对于在线业务，则需要把峰谷请求比例真正纳入预算。

至于官方 API、固定价格第三方 API、多模型统一 API，最后还是要根据具体项目决定。

我现在更倾向于先把真实流量跑出来，再算：

每一天用了多少 Token
什么时候用的
失败了多少次
最终实际花了多少钱

这个数字比价格页面本身更有参考意义。

---

参考页面

• DeepSeek 官方 API 价格
  https://api-docs.deepseek.com/zh-cn/quick_start/pricing/

• 算桥API 模型列表
  https://suanjiayun.com/api/modelList

• DeepSeek-V4-Flash-0731 模型页面
  https://www.suanjiayun.com/api/modelDetail/6a83b8db31cc72629e2b9ca3