DeepSeek API按输入与输出token分别计价，模型类型、缓存命中及优惠时段共同影响账单。本文拆解定价结构、计费规则与成本控制方法。 不少团队第一次做API预算时，习惯按请求次数估算，上线后却发现账单与预期相差很大。DeepSeek API的计费核心是token消耗，输入与输出分开定价，不同模型、缓存命中情况还会带来明显价差。把这几条规则拆开看，成本并不难算。
1. 计费基础：Token如何成为API的计价单位
DeepSeek API并不是按“调用一次收一次费”来结算，而是按模型实际处理的token数量计费。token是模型分词后的基本单位，中文里一个汉字通常接近一个token，英文单词可能被拆成多个token，代码、符号和空格也会参与分词。一次请求的账单由两部分组成，输入token对应你传给模型的提示词、上下文和系统指令，输出token对应模型生成的回答。官方定价页会分别给出输入单价和输出单价，通常以每百万token为单位标价，实际费用按用量比例折算。 把公式写清楚就是：费用等于输入token数除以一百万乘以输入单价，加上输出token数除以一百万乘以输出单价。如果输入命中了上下文缓存，命中部分按更低的缓存单价计算。以deepseek-chat当前公开的人民币价格为例，缓存未命中输入约为2元每百万token，输出约为8元每百万token。假设一次请求输入800个token、输出300个token，均未命中缓存，那么输入费用约为0.0016元，输出费用约为0.0024元，单次合计约0.004元。单次看起来很低，但乘以每天的请求量后，长上下文和长输出会成为账单的主要来源。 真正需要关注的是token结构，而不是请求条数。一个带万字文档的摘要请求，输入token可能达到数万，成本远高于几十条短消息；一个要求生成长篇报告的输出任务，输出token单价又高于输入，费用放大更明显。接入前应先用官方tokenizer或接口返回的usage字段估算典型业务的输入输出比例，再按日调用量做预算。这样得到的数字比“按次估价”更接近真实账单。
2. 模型定价差异：chat与reasoner的成本结构
DeepSeek API当前主要提供deepseek-chat和deepseek-reasoner两类模型，二者定位不同，价格也有明显差距。deepseek-chat面向通用对话、内容生成、摘要和代码补全，响应速度快，价格相对低。deepseek-reasoner面向复杂推理、数学题、逻辑分析和多步决策，输入与输出单价都更高。以公开人民币价格为例，deepseek-chat缓存未命中输入约为2元每百万token，输出约为8元每百万token；deepseek-reasoner缓存未命中输入约为4元每百万token，输出约为16元每百万token。缓存命中时两者都有折扣，但reasoner的绝对单价仍然更高。 reasoner的成本结构还有一个容易被忽略的点：推理模型在给出最终回答前会产生思维链内容，这些推理过程同样消耗输出token。也就是说，同一个问题交给reasoner，账单里的输出token往往不止你看到的最终答案，还包括模型内部推理所消耗的部分。对于简单分类、信息抽取、固定格式转换这类任务，使用reasoner并不会带来成比例的质量提升，反而会让输出token和单价同时上升。把reasoner留给确实需要多步推理的场景，是控制成本的第一道分水岭。 选型时可以用“任务复杂度除以成本敏感度”来判断。客服自动回复、商品文案、文档摘要优先用deepseek-chat，配合缓存和输出长度限制，单位成本可以压得很低。数学解题、复杂合约审阅、多跳问答再考虑deepseek-reasoner，并且要在提示词里明确要求简洁推理，避免模型展开不必要的长链条。模型不是越贵越合适，账单上的差异最终来自任务匹配度。
3. 缓存与优惠：影响实际账单的关键变量
上下文缓存是DeepSeek API账单里最值得利用的折扣机制。当多次请求的前缀内容高度重复时，系统可以自动识别并命中缓存，命中部分的输入token按更低价格计费。典型场景包括固定的系统提示词、长期不变的产品知识库、few-shot示例和长文档开头。以deepseek-chat为例，缓存命中输入价格约为0.5元每百万token，而未命中约为2元每百万token，差距达到四倍。把稳定内容放在提示词前部、把变量放在后部，能提高命中率，也让长上下文应用的成本更可控。 时段优惠会进一步改变实际单价。DeepSeek曾推出错峰时段折扣，在北京时间凌晨低峰期调用deepseek-chat和deepseek-reasoner可享受不同幅度优惠，适合把批量摘要、数据清洗、离线评测等非实时任务调度到夜间执行。这类优惠的具体时段和折扣可能随官方公告调整，接入前应核对最新定价页。对于有弹性计算需求的企业，错峰调度不需要改业务逻辑，却能直接降低单位token成本，属于性价比很高的优化手段。 还有一些变量会影响账单但不直接体现在单价里。失败请求如果触发重试，会重复消耗输入token；流式输出改善的是体验，不改变按token计费的本质；并发限流本身不产生费用，但排队和重试可能拉长任务时间。建议在应用层记录每次请求的usage字段，区分缓存命中与未命中、输入与输出，按业务线拆分API key并设置预算告警。账单异常往往不是单价变了，而是某类长上下文请求悄悄放量。
4. 成本控制与选型：把API账单算在业务之前
控制DeepSeek API成本的第一动作是压缩输入，而不是急着换更便宜的模型。系统提示词里反复出现的礼貌用语、重复背景和无关示例都会进入输入token，长期运行会形成一笔固定开销。把系统指令精简到必要信息，把知识库内容做成可复用的缓存前缀，把历史对话按窗口截断而不是无限拼接，往往能在不损失效果的情况下把输入token降下来。输出侧同样要设边界，通过max_tokens、停止词和格式约束限制模型展开长度，避免短问题生成长文。 第二动作是建立用量观测。DeepSeek接口返回的usage字段会给出输入token、输出token和缓存命中token，按业务线、按模型、按天汇总后，才能看出成本花在哪里。客服机器人可能输入长但输出短，报告生成可能输入短但输出长，两类业务的优化方向完全不同。给每个业务设置独立key和预算阈值，在用量突增时及时告警，比月底看总账单更有用。流式输出和异步调用不改变计费规则，但能改善体验，适合放在非成本敏感环节。 一个常见的优化案例是文档问答。优化前把整份文档塞进每次请求，输入token高且缓存命中不稳定；优化后把文档固定前缀缓存，只把问题放在尾部，同时限制回答在三百字以内，输入和输出同时下降。另一类案例是批量摘要，把任务调度到错峰时段，配合deepseek-chat和较短的输出上限，单位成本可以明显低于白天实时调用。先算清token结构，再谈模型选型和优惠策略，API账单才会从不可控变成可预算。
