deepseek api调用价格

很多人第一次对着两张价目表发愁：输入输出分开算、缓存命中打折、批处理半价，两边口径还不一样，估出来的月账单跟实际差好几倍。这篇不背数字，只讲两家的计费结构差在哪、你自己的用量该怎么折算成钱、上线后怎么核对账单，数字去哪一页查都写清楚。

很多人第一次对着两张价目表发愁：输入输出分开算、缓存命中打折、批处理半价，两边口径还不一样，估出来的月账单跟实际差好几倍。这篇不背数字，只讲两家的计费结构差在哪、你自己的用量该怎么折算成钱、上线后怎么核对账单，数字去哪一页查都写清楚。

DeepSeek 和 ChatGPT 在 API 计费上都能归到「按量计费」这个大类，但具体条款差别不小。你真正要做的不是记住单价，而是把自己的业务用量摸清楚，再对着当天的官方价目表算一遍区间。凡是正文里出现的价格、折扣力度、版本名，一律以站内页面为准，别拿记忆里的旧数字去估。

两家的钱到底按什么收

按量计费的公共结构是：输入 token 和输出 token 分开计价，输出通常贵一档。所以在谈价格之前，先把自己业务的输入输出比例摸出来。一个写摘要的场景和一个写代码的场景，比例完全不同，直接决定哪家更划算。

输入 token

你发给模型的内容，包括系统提示、历史对话、检索回来的资料

输出 token

模型生成的内容，通常单价高于输入

缓存命中

同一段前缀重复出现时，部分厂商按折扣价计费，命中条件各平台写法不同

批处理

非实时任务走批处理通道，单价通常更低，代价是延迟变长

长上下文加价

超过某个长度档位后单价跳档，不是线性叠加

• 先统计一次典型请求的输入输出 token，长上下文场景单独拎出来算
• 把「能缓存的前缀」和「每次都变的部分」分开，别混在一起估
• 同价目表里的几个折扣位：缓存命中、批处理、长上下文加价、推理档位，逐条对能不能落到你的场景
• 订阅制（ChatGPT 侧套餐）和按量 API 是两套账，包月额度不能当成 API 免费额度

去哪查、查哪几列

打开价格页别只看第一列数字。先对齐单价单位是每百万 token 还是每千 token，两家的写法不一定一样，差一个量级会让你整个估算全错。然后重点看计费条件：缓存怎么算命中、输出长度怎么分档、有没有按次计的附加项。

每家官方价格与规格的入口都在站内有整理，直接去对应页面拿当天口径。价格会变，正文里不写死任何数字，换算的时候用站内的换算工具把单价代进去。

• 到 DeepSeek 官方价格与规格页看输入输出分档和缓存说明
• 到 OpenAI 官方价目与图片视频模型对照页看按量条目
• 单价换算用 Token 单价换算工具，把每百万 token 换成你业务的单次成本
• 整体成本估算用模型成本计算器，把日调用量一起代进去

把自己的用量折算成钱

估成本最容易犯的错，是拿单价直接乘总 token 数。正确顺序是三步：先统计一次典型请求的输入输出 token，长上下文场景要单独算；再乘以日调用量，得到每天的输入输出 token 总量；最后才乘各自单价。两步三步之间错一步，结果就差好几倍。

1. 统计典型请求抽十条真实请求，数出输入输出 token 的中位数和最大值，两个都留着，用于算区间
2. 算日用量用中位数乘日调用量得到稳定态，再用最大值乘一次得到峰值态，两个结果并排写
3. 乘单价得区间分别按缓存命中与不命中各算一版，得出成本下限和上限，中间的差额就是你优化的空间
4. 交叉验证拿估算值和实际上线一周后的账单对一次，差得离谱先怀疑是不是把输出按最大值填了

真实用量榜反映的是别人的场景，你的平均上下文长度可能和它差一个量级，不要直接照抄结论。缓存命中率是最大的变量，先把「同一段系统提示反复出现」这类可缓存的部分摘出来，再分别算命中与否两版成本，作为区间。

上线后怎么盯住这笔钱

上线前的估算只是参考，真正的成本控制发生在运行期。最基础的动作是按调用方打标签：哪个功能、哪个用户组、哪次实验。没有标签，月底看到总额你根本不知道怎么摊到各个业务上。

• 按功能、用户组给调用打标签，账单才能拆开看
• 日志字段按上表埋齐，缺一项后面就要靠猜
• 设日/周成本阈值告警，比设总额告警更早发现异常
• 单次请求成本突然翻倍，通常是被换了模型或上下文炸了，先查这两个
• 定期回看价格变动追踪，厂方调价和调计费规则是两回事，后者更容易被漏掉

监控字段的取舍可以参考站内质量监控的思路：先保证关键字段不缺，再看要不要加细粒度指标。字段埋得越早，后面做优化时越有依据，事后补埋等于从头再跑一遍。

想省钱的几个正经动作

省钱不是换一家便宜的就完事，而是分两刀：砍输入和砍输出。输入里长对话是费用大头，输出里小作文是费用大头，这两处改起来最快见效也最稳。

• 砍输入：系统提示精简、历史对话裁剪或摘要，别把整段历史每次都重发
• 砍输出：限制 max tokens、要求结构化短答，别让模型写小作文
• 换档位：简单任务分流到便宜档或批处理，难任务才用贵模型，切换后计费口径要重新核一遍
• 缓存和批处理能用就用，但先确认你的场景命中条件是不是真能满足，不满足反而白改代码

换档位之前先把分流规则写清楚：什么样的请求算简单、什么算难、由谁判断。规则含糊会出现同一类请求今天走便宜档明天走贵档，账单忽高忽低，根本没法归因。分流之后，计费口径如果跟着变了，要重新按新档位的规则算一遍。

什么情况下这套算法不适用

上面这套「统计 token 乘单价」的算法默认你走的是官方直连、按量计费。下面这几种情况要换一套口径，硬套会得出错误结论。

走中转站的尤其要注意：你的账单是平台开的，不是厂方开的，倍率和最低计费都可能是平台自己定的。先在站内中转站目录里把对应平台的口径看清楚，再谈贵不贵。

开工前对着这个清单过一遍

1. 确认接入方式先分清楚自己要接的是官方直连还是中转，两者价格口径不同，混着算必错
2. 统计典型请求数出输入输出 token 的中位数和最大值，长上下文场景单独统计
3. 拿当天单价到官方价格页取当天口径，别用记忆里的旧数字，单位是每百万还是每千要看清楚
4. 算两版区间按缓存命中与不命中各算一版，得出成本下限和上限，上限和下限差得越多优化空间越大
5. 先埋日志再优化日志字段先埋好，再谈优化，否则优化了什么、省没省都没法验证
6. 设阈值告警日/周阈值告警先设上，超了再分析怎么省，别等月底账单出来才发现

这份清单能帮你把「估成本」这件事从拍脑袋变成有依据的动作。做完之后你手里应该有一张成本区间表，而不是一个孤零零的数字。后面的优化和调价追踪，都从这张表出发。