DeepSeek 开放平台在 8.6 发布官方通知，表示计划近期整体上调 DeepSeek API 服务定价，预计涨幅较大，具体方案以正式通知为准。对于已经依赖 DeepSeek API 的应用团队来说，这不只是一次价格变化，也会影响模型选型、调用策略、预算控制和服务稳定性。
当前官方 API，尤其是 v4-flash，价格长期处于非常低的水平，在主流模型中具备明显的性价比。随着请求量快速增长，官方服务此前也出现过不稳定情况。价格上调可能成为平台调节供需的一种方式，但开发者不能等到正式价格发布后才开始准备。
价格变化意味着什么
在正式方案公布之前，具体涨幅、不同模型的价格梯度以及输入输出 token 是否采用不同计费方式，都不能提前下结论。可以确定的是，现有成本模型需要重新审视，尤其是以下几类应用：
- 高频调用的聊天、搜索和内容生成产品。
- 使用长上下文、长输出的代码助手和文档问答系统。
- 通过批量任务持续调用模型的数据处理流程。
- 对延迟和可用性要求较高、没有备用模型的线上服务。
过去非常低的单次调用成本，可能掩盖了提示词过长、重复请求、无效重试和输出失控等问题。价格调整后，这些问题会直接反映到月度账单中。
先建立自己的调用成本账本
不要等平台发布新价格后再统计用量。现阶段可以先记录每次请求的输入 token、输出 token、模型名称和业务场景。下面是一个不依赖第三方库的 Python 示例，假设应用能够从 API 响应中拿到 usage 字段。
运行前，将示例中的 MODEL_PRICES 替换为正式通知发布后的价格，单位假设为“每百万 token 的价格”。
from collections import defaultdict
from dataclasses import dataclass
# 示例价格仅用于演示计费逻辑，不代表官方价格。
MODEL_PRICES = {
"deepseek-v4-flash": {
"input_per_million": 0.50,
"output_per_million": 1.00,
},
}
@dataclass
class Usage:
model: str
scenario: str
input_tokens: int
output_tokens: int
def estimate_cost(usage: Usage) -> float:
prices = MODEL_PRICES[usage.model]
input_cost = usage.input_tokens / 1_000_000 * prices["input_per_million"]
output_cost = usage.output_tokens / 1_000_000 * prices["output_per_million"]
return input_cost + output_cost
def summarize(usages: list[Usage]) -> None:
totals = defaultdict(lambda: {"requests": 0, "tokens": 0, "cost": 0.0})
for item in usages:
key = f"{item.model}:{item.scenario}"
totals[key]["requests"] += 1
totals[key]["tokens"] += item.input_tokens + item.output_tokens
totals[key]["cost"] += estimate_cost(item)
for key, value in sorted(totals.items()):
print(
f"{key} requests={value['requests']} "
f"tokens={value['tokens']} "
f"estimated_cost={value['cost']:.6f}"
)
if __name__ == "__main__":
summarize([
Usage("deepseek-v4-flash", "chat", 1200, 350),
Usage("deepseek-v4-flash", "chat", 900, 180),
Usage("deepseek-v4-flash", "document_qa", 12000, 900),
])
在真实项目中，可以把 Usage 数据写入日志、时序数据库或业务明细表，并增加用户、租户、接口、HTTP 状态码和重试次数等维度。这样正式价格发布后，只需更新价格配置，就能快速估算不同业务线的成本变化。
三个方向降低价格冲击
控制输入上下文
输入 token 往往是最容易被忽略的成本来源。对话系统不应无限拼接历史消息；文档问答系统也不应把所有检索结果原样塞入提示词。可以采用以下策略：
- 只保留最近几轮对话，其余内容压缩为摘要。
- 对检索结果进行去重和截断。
- 将固定的长指令拆分为必要规则和可选规则。
- 对重复文档、重复问题和重复结果增加缓存。
控制输出长度
为每个业务场景设置合理的最大输出 token。客服回复、分类结果和结构化抽取通常不需要很长的自然语言输出。对于 JSON 输出，还应在提示词和服务端校验中明确字段范围，避免模型持续生成无关解释。
减少无效重试
服务不稳定时，简单地无限重试会放大请求量，也会让故障期间的账单快速增长。建议为重试设置次数上限、指数退避和超时，并区分可重试错误与业务错误。例如，鉴权失败、参数错误通常不应自动重试；临时限流或网关错误才适合有限重试。
可以这样实践一个简单的重试策略：
import random
import time
RETRYABLE_STATUS_CODES = {429, 500, 502, 503, 504}
def call_with_retry(call_api, max_retries=3):
for attempt in range(max_retries + 1):
response = call_api()
if response.status_code < 400:
return response
if response.status_code not in RETRYABLE_STATUS_CODES:
raise RuntimeError(f"non-retryable status: {response.status_code}")
if attempt == max_retries:
raise RuntimeError(f"request failed after retries: {response.status_code}")
delay = min(30, 2 ** attempt) + random.uniform(0, 0.3)
time.sleep(delay)
这个示例假设 call_api() 返回带有 status_code 属性的响应对象。生产环境还需要配合请求超时、幂等设计、熔断和监控，避免多个服务实例同时进行重试风暴。
不要只看单价，也要看可用性
API 单价只是总成本的一部分。若服务频繁超时或返回错误，应用还会产生排队、重试、人工处理和用户流失成本。面对价格和稳定性同时变化的可能性，线上系统可以提前准备：
- 为关键链路设计备用模型或备用供应商。
- 将模型调用封装在统一接口后面，避免业务代码绑定某一家 SDK。
- 为不同场景配置质量、延迟和成本等级。
- 记录每个模型的成功率、P95 延迟、平均 token 数和单请求成本。
- 对高成本接口设置租户级或用户级预算上限。
备用模型不一定要立即切换。更稳妥的方式是先建立灰度开关，在主模型出现持续超时、限流或成本超过阈值时，再将特定低风险流量切换出去。
发布前检查清单
正式价格方案发布前，可以完成以下准备：
- 盘点所有调用 DeepSeek API 的服务和定时任务。
- 统计至少一段完整周期的请求数、输入 token 和输出 token。
- 区分生产、测试、内部工具和批处理流量。
- 查找过长上下文、无限输出和重复重试。
- 为关键接口补充超时、有限重试和降级策略。
- 把模型名称与价格放入可热更新的配置，而不是硬编码在业务逻辑中。
- 准备预算告警，覆盖日成本、月成本和单租户成本。
DeepSeek API 的低价曾让许多团队可以快速验证产品和扩大调用规模。价格上调后，真正重要的不是简单判断“贵了多少”，而是知道每一次调用为哪个业务结果付费，并且在成本、质量和可用性之间做出可观测、可回滚的选择。具体价格仍应以平台正式通知为准，但成本核算和调用治理现在就可以开始。