DeepSeek V4 正式版预计在 7 月中旬上线。相比发布时间，更值得工程团队提前处理的是新的 API 峰谷计价：按北京时间分时段收费，上午 9 点到 12 点、下午 2 点到 6 点属于峰时，价格翻倍；其他时段维持基准价。对调用量稳定的业务来说，这不是财务备注，而是架构参数。
价格变成了调度信号
过去很多团队优化 LLM 成本，主要盯着 token、缓存、模型选择和提示词长度。V4 的峰谷计价把另一个变量推到台前：调用发生的时间。
这会直接影响三类任务：
- 实时交互：客服、IDE 助手、在线搜索问答，通常无法为了省钱延迟数小时。
- 准实时任务：内容审核、报告摘要、工单分类，可以接受几分钟到几十分钟延迟。
- 批处理任务：离线总结、向量补全、日报生成、数据标注，最适合迁移到谷时。
也就是说，API 调用不再只是“请求来了就打模型”。更合理的做法是把任务按时效分层：必须立即返回的继续实时调用；可以等待的进入队列；批量任务避开北京时间 9:00-12:00 和 14:00-18:00。
北京时间是账单边界，不是服务器本地时间
峰谷计价按北京时间计算，这个细节容易踩坑。你的服务可能跑在 UTC、美国西部时间、新加坡时间，容器里的 TZ 也可能没有配置。成本判断如果直接用 datetime.now()，很容易在跨区域部署时算错。
可以这样实践：把“是否峰时”封装成一个独立函数，并显式使用 Asia/Shanghai 时区。下面的 Python 示例不依赖第三方库，适合放进任务调度器、网关或批处理入口。
from datetime import datetime, time
from zoneinfo import ZoneInfo
BJ = ZoneInfo("Asia/Shanghai")
PEAK_WINDOWS = [
(time(9, 0), time(12, 0)),
(time(14, 0), time(18, 0)),
]
def is_deepseek_peak(now: datetime | None = None) -> bool:
"""Return True if current Beijing time is in DeepSeek V4 peak window."""
now_bj = (now or datetime.now(tz=BJ)).astimezone(BJ)
current = now_bj.time()
return any(start <= current < end for start, end in PEAK_WINDOWS)
def estimated_multiplier(now: datetime | None = None) -> int:
return 2 if is_deepseek_peak(now) else 1
if __name__ == "__main__":
now = datetime.now(tz=BJ)
print(f"Beijing time: {now:%Y-%m-%d %H:%M:%S}")
print(f"DeepSeek V4 price multiplier: {estimated_multiplier(now)}x")
运行：
python deepseek_price_window.py
如果你的系统用 Celery、Sidekiq、BullMQ 或 Kafka 消费任务，也可以把这个判断放在消费者侧：峰时只处理高优先级队列，谷时再释放低优先级批量任务。
把调用分成“现在做”和“等会做”
新的计价机制不会要求所有业务都避峰。真实用户正在等待答案时，强行延迟通常得不偿失。但很多 LLM 调用并不需要同步完成，它们只是被写成了同步。
一个实用改造是给任务加 latency_class：
interactive：立即调用，成本接受峰时翻倍。deferable：峰时入队，谷时消费。batch：只在谷时跑，失败后重试也避开峰时。
下面是一个最小 Flask 示例，演示如何在峰时把可延迟任务写入本地队列文件。这里假设你已有实际 DeepSeek API 调用函数，示例重点是调度边界，不是官方 SDK。
from datetime import datetime
from pathlib import Path
from zoneinfo import ZoneInfo
import json
from flask import Flask, request, jsonify
app = Flask(__name__)
BJ = ZoneInfo("Asia/Shanghai")
QUEUE_FILE = Path("deferred_jobs.jsonl")
def is_peak() -> bool:
now = datetime.now(tz=BJ).time()
return (now >= datetime.strptime("09:00", "%H:%M").time() and now < datetime.strptime("12:00", "%H:%M").time()) or \
(now >= datetime.strptime("14:00", "%H:%M").time() and now < datetime.strptime("18:00", "%H:%M").time())
def call_deepseek(prompt: str) -> dict:
# Replace this with your real DeepSeek API request after V4 is available.
return {"answer": f"processed: {prompt[:40]}"}
@app.post("/llm/tasks")
def create_task():
payload = request.get_json(force=True)
prompt = payload["prompt"]
latency_class = payload.get("latency_class", "interactive")
if latency_class in {"deferable", "batch"} and is_peak():
job = {
"prompt": prompt,
"latency_class": latency_class,
"created_at_bj": datetime.now(tz=BJ).isoformat(),
}
with QUEUE_FILE.open("a", encoding="utf-8") as f:
f.write(json.dumps(job, ensure_ascii=False) + "\n")
return jsonify({"status": "queued", "reason": "peak pricing window"}), 202
result = call_deepseek(prompt)
return jsonify({"status": "done", "result": result})
if __name__ == "__main__":
app.run(port=8080, debug=True)
本地试跑：
pip install flask
python app.py
curl -X POST http://127.0.0.1:8080/llm/tasks \
-H 'Content-Type: application/json' \
-d '{"prompt":"总结今天新增的 300 条工单", "latency_class":"deferable"}'
生产环境里不要用 JSONL 文件当队列，可以换成 Redis、SQS、Kafka、PostgreSQL job table 或你现有的任务系统。
成本优化不能牺牲产品体验
峰时价格翻倍会诱导团队“能拖就拖”，但边界要清楚：用户正在聊天、排障、写代码时，延迟就是产品质量的一部分。省下的 API 费用如果换来更低的转化率或更高的人工处理成本，就不是优化。
更稳妥的落地清单是：
- 先打点：记录每次调用的北京时间、业务场景、token 量和是否可延迟。
- 再分层：把调用分成实时、可延迟、批处理，不要一刀切。
- 做保护：峰时预算超限时，优先降级非核心任务，而不是影响核心链路。
- 看账单：V4 上线后用真实账单校准估算，不要只靠本地 multiplier 推导。
DeepSeek V4 的模型能力值得关注，但峰谷定价会更快影响后端系统的形状。谁能把调用时间、任务优先级和业务体验放在同一张表里看，谁就能在新价格规则下少花冤枉钱。