DeepSeek API 价格与计费详解（含省钱配置）

DeepSeek API 计费结构：输入、输出与缓存命中三条计价线

场景与需求：为什么算这笔账

我的需求很典型：给一个日活不高的工具站和几个自动化脚本接 LLM 能力——文本摘要、分类打标、代码问答，偶尔夜间跑批。特点有三：

调用量可预估但不大，峰值集中在晚上的定时任务；
对模型能力要求中等，推理模型只在少数难题上用；
预算敏感：月成本希望控制在两位数（元）量级；
不想被订阅制绑架——IDE 订阅（见Cursor vs GitHub Copilot 深度对比）按月固定付费，而我这种间歇性用量，按量付费更划算。

如果你是重度 Agent 用户或团队场景，本文的框架一样适用，把用量假设换成你的真实值即可。

候选方案

方案	形态	成本结构	优点	缺点
DeepSeek 官方 API	OpenAI 兼容接口	按 token 计费，预付费充值	国内直连、单价低、模型迭代快	高峰期可能限流，无 SLA 承诺（以官方文档为准）
三方聚合平台	统一网关转发多家模型	按 token 计费，常在官价上加价	一个 Key 调多家、账单统一	加价，稳定性多一层依赖
云厂商托管	云上开通 DeepSeek 系模型服务	按 token 计费	发票、企业合规顺手	单价通常高于官方
本地自部署（蒸馏小模型）	开源权重 + 自己的显卡	一次性硬件 + 电费	零边际成本、数据不出门	消费级显卡只能跑 7B / 8B 量级蒸馏版，与满血版能力差距明显

官方 API 的 OpenAI 兼容性是关键卖点：现有 OpenAI SDK 代码只改 base_url 和 model 名就能迁移，接入步骤见DeepSeek API 接入教程。

测算模型与假设

先摆计费规则里属于通识的部分：

计量单位是 token，官方计价以每 100 万 tokens 为单位，按实际用量结算；
输入、输出分开计价，业内通行输出单价高于输入，常见 2 倍到 4 倍量级（DeepSeek 当前精确倍数【待补：官网价格页】）；
上下文缓存：重复出现的前缀（比如同一段 system prompt 反复带上）命中缓存后，这部分输入的费用大幅降低，精确折扣【待补：官网缓存计费说明】；
两个模型名对应两条价目：deepseek-chat（非推理，对应 V3 系）与 deepseek-reasoner（推理，对应 R1 系，会额外产出思考过程 tokens），当前的版本映射与单价【待补】；
HTTP 状态语义：429 是触发限流，402 是余额不足，两者都直接影响跑批任务的可用性。

token 怎么估？官方文档给过粗略换算：1 个中文字符约 0.6 个 token，1 个英文字符约 0.3 个 token（以官方最新口径为准）。先估单次请求的输入输出规模，再乘频次。

我的用量假设（个人实际值【待补：以近三个月账单为准】）：

假设项	取值（示例数字，发布前替换）
日均请求数	300 次（含跑批）
平均输入	800 字 ≈ 480 tokens
平均输出	300 字 ≈ 180 tokens
推理模型占比	10% 的请求走 reasoner
system prompt	全部请求复用同一段前缀（吃缓存折扣）

测算结果表

公式先给出来，单价留待补位（示例数字，发布前替换）：

月成本 = 日均请求数 × 30 × [
    输入 tokens × 输入单价/100万
  + 输出 tokens × 输出单价/100万
]
缓存节省 = 月成本 × system prompt 前缀占比 × (1 - 缓存命中折扣)

项目	数值
deepseek-chat 输入单价（元 / 100 万 tokens）	【待补：官网价格页】
deepseek-chat 输出单价（元 / 100 万 tokens）	【待补】
deepseek-reasoner 输入 / 输出单价	【待补】
缓存命中输入单价	【待补】
按上表假设的月成本	【待补：代入公式计算】
其中缓存可省	【待补：按 system prompt 复用率估算】

举例演示公式用法（纯示例数字，发布前替换）：假设输入单价 1 元 / 100 万 tokens、输出 2 元 / 100 万 tokens，则”日均 300 次请求、每次输入 480 tokens + 输出 180 tokens”的月成本 = 300 × 30 × (480 × 1 + 180 × 2) / 1000000 ≈ 7.6 元。把真实单价代入重算即可，方法不变。

决策框架

按四个问题往下走：

月调用量在百万 tokens 以内？ 官方 API 按量付费，成本大概率是几元到几十元，别考虑订阅制和自部署，直接选官方。
需要发票和统一账单？ 云厂商托管或三方平台，用一定的加价换财务合规。
数据绝对不能出门？ 只有自部署一条路，同时接受蒸馏小模型的能力折损——7B 量级模型 FP16 大约要 16 GB 显存量级，量化后可以压到 8 GB 上下（精确值【待补：按具体模型核对】），能力与满血版差距明显。
重度推理需求？ reasoner 单价更高，且思考过程 tokens 也计费，把推理请求限制在真正需要的环节，其余全部走 chat 模型。

再给三条我实际在用的省钱配置：

system prompt 固定且前置：让重复前缀命中上下文缓存，长前缀场景的折扣立竿见影；
max_tokens 显式设置：防止异常长输出拖高账单，顺便兜底超时；
429 按指数退避重试：等待 1 秒、2 秒、4 秒逐次翻倍，无脑并发只会限流得更狠；收到 402 先充值再排查代码，别改参数白折腾。

对账方法也交代一下：每次响应里的 usage 字段会返回 prompt_tokens（输入）和 completion_tokens（输出），月账单对不上时，用这两个字段按天聚合就能定位到具体哪类请求在烧钱。

我的最终选择

主方案：DeepSeek 官方 API + 按量预付费。理由：

OpenAI 兼容，迁移零成本，代码里只改两行配置；
我的用量小，按量付费比任何订阅制都便宜，月账单预期在个位数到十位数（元）之间（真实账单【待补：上线满三个月后贴数据】）；
国内直连，夜间跑批不需要考虑网络代理；
充值起步金额低，试错成本几乎为零（起步金额与发票政策【待补：以充值页为准】）。

备用方案：三方平台留一个 Key，官方高峰期限流影响跑批时效时切过去兜底（实际触发频率【待补：以近三个月 429 出现次数统计为准】）。