deepseek-r1 token价格

你准备把项目接到DeepSeek上，翻了几页资料，发现同样是「百万token」的说法，口径却对不上：有的只算输入，有的把缓存读写分开列，还有的标价早就改过了。这篇不背数字，只教你从哪里拿到当期价格、怎么把单价换成一次任务的钱、以及价格变了以后按什么顺序重新核一遍，避免拿旧价做预算。

你准备把项目接到 DeepSeek 上，翻了几页资料，发现同样是「百万 token」的说法，口径却对不上：有的只算输入，有的把缓存读写分开列，还有的标价早就改过了。这不是谁写错了，而是三处页面的计价前提本来就不一样。

这篇不背数字，只教你从哪里拿到当期价格、怎么把单价换成一次任务的钱、以及价格变了以后按什么顺序重新核一遍，避免拿旧价做预算。所有具体数值一律以站内页面当时显示的为准，你看到这篇文章时它可能又变了。

先搞清楚：为什么你查到的价格对不上

先把「对不上」的原因拆开。绝大多数情况不是有人写错，而是三个口径没对齐：计价单位是每百万 token 还是每千 token、币种是哪个、以及缓存读写算不算在内。三处页面各自默认不同，直接抄进同一张表就会出错。

• 只看了输入价没算输出价：很多任务输出占比不低，只按输入估会明显偏低
• 缓存读写另计：命中缓存的输入和未命中的输入单价可能不同，页面上有时分列两行
• 折扣与赠送额度没扣：这类额度通常有抵扣顺序，不写进文档后面就对不上账
• 计价单位不一致：每百万和每千混着看，差好几个数量级
• 时效性差异：聚合页和导航页的缓存更新有延迟，不是实时同步

判断标准很简单：如果你没法用一句话说清「这个数字是每多少 token、什么币种、含不含缓存」，那它就不能拿来横向比较。先把口径对齐，再谈谁便宜。

当期价格去哪看：三处入口和各自用途

官方口径适合做基准，聚合比价页适合横向看多家，站内的价格变动追踪页用来判断「现在这版价格是不是最近的」。三者用途不同，不要拿其中一处去否定另一处。需要具体数字时，到 /price-watch 核对当时的数字。

1. 先锁基准打开官方价格与规格页，抄下计价单位、币种、输入/输出/缓存各行的写法，写成一句话备注。
2. 再横向比到聚合比价页看同口径的其它家，只比能对齐的那几行，对不齐的直接标「不可比」。
3. 最后校时效到 /price-watch 看这档价格最近有没有调整记录，有调整就以变动后的口径为准。

顺序反了会很费时间：先去比价页挑便宜，再回头发现口径对不上，前面挑的全白做。先锁基准，再横向比，最后校时效。

100万token到底多少钱：把单价换成你的任务

「100 万 token 多少钱」这个问题本身没有唯一答案，因为输入和输出单价通常不同，缓存命中与否也不同。正确的换算顺序是：先估单次任务的输入 token 与输出 token，再分别乘各自单价，最后相加。别拿一个混合单价乘总量。

• 输入输出差价通常明显：长文档总结这类输入远大于输出的任务，和代码补全这类输出偏多的任务，结论会相反
• 缓存项要单独拎出来：命中缓存的输入和未命中部分不是同一个价，估算时按你的实际命中率大致分一下
• 重试与失败调用也算钱：网络失败、超时重发都会产生 token，长期看这部分比例不低
• 批量与实时不同：离线批处理可以把请求攒起来，实时接口没有这个空间
• 换算后落到「每次调用多少钱」，比落到「每百万多少钱」更容易做预算

手上没有现成数字时，用站内 token 单价换算与模型成本计算器页把参数填进去，比手算稳。填的时候注意它是按每百万还是每千计，单位错了结果会差好几个数量级。具体数值到 /tools/speed-test 一类的工具区看当时的页面。

一个通用估算模板

推理型模型的钱花在哪：和普通对话模型的差别

推理型模型的输出里往往包含较长的思考过程，输出 token 会明显多，按输出价算的那部分占比就升高了。对同一个问题，普通对话模型可能几句话就答完，推理型会先展开一大段再给结论。

什么情况下不适用：如果你的任务本身输出很短、只是偶尔用一次，推理型和普通档位的总花费差距可能被调用量摊平，这时为省这点钱去改架构不划算。判断动作是：拿同一批真实请求各跑一遍，只比「总 token 数乘对应单价」，不要比单次响应时间，那是另一个维度的事。

输出占比

推理型通常比普通对话模型高，成本结构因此偏向输出价

适用场景

复杂推理、多步规划、需要中间步骤的任务，省下的返工可能抵掉差价

不适用场景

输出本来就短、调用频率低、答案格式固定的任务

验证方式

同一批真实请求各跑一遍，只比总 token 乘单价

系列里选哪档：按任务而不是按单价排序

不要按单价从低到高排一遍就定。先列任务清单，再用「单位任务成本」排序。同一个任务在系列里各档模型上各跑一小批，记录总 token 和对应单价，算出每次调用成本，再决定。

• 批量清洗、格式转换：输出短、规则明确，优先低档位，注意别为省一点钱牺牲成功率
• 长文总结：输入极大、输出中等，重点看输入价和缓存策略
• 代码生成：输出偏多，重点看输出价，同时把重试次数记上
• 多轮对话：单轮便宜但轮次多，要按一次会话的总 token 算，不是按单轮
• 复杂推理：低价档可能反复重试，重试本身也计费，把重试算进成本才准

注意事项：低价档在复杂推理上失败率高，重试两三次就把省下的钱吃回去了。所以对比时要用「有效回答的每次成本」，而不是「成功调用的每次成本」。型号在售情况到站内模型库页确认，别用已经下架的档位做基准。

价格调整后，按这个顺序重核一遍

价格变了不用慌，按固定顺序走一遍，通常十几分钟能得出要不要动的结论。顺序错了会做很多无用功。

1. 确认变动范围到 /price-watch 看变的是哪一档、是输入还是输出、有没有涉及缓存项。只变输出价，和输入输出都变，影响完全不同。
2. 确认型号状态回模型库页确认这个型号是否仍在售、上下文和缓存支持有没有变化，避免基于已调整的规格算价。
3. 替换单价重算把成本计算器里的旧单价换成新单价，用上个月的真实用量重跑一遍，得出新旧差额。
4. 只对差额大的任务做评估差额占总预算比例小的任务不动；比例大的再考虑换档或改调用方式，小额度任务不值得为省一点钱改代码。

落地清单：接之前和每月各做一次

把下面两段各存一份，接入前跑一遍，之后每月跑一遍。清单不长，但能省掉大量事后追账的时间。具体数字一律以站内页面当时显示的为准。

接入前

• 确认计价单位、币种、输入输出是否分开计价
• 确认缓存是否计费、按什么比例分档
• 确认是否有赠送额度，以及抵扣顺序
• 把上面几条写进项目文档，别只留在一个人的聊天记录里
• 把预算告警设上，把跑飞限制在一晚以内

每月一次

• 在用量日志里记下每次调用的输入 token、输出 token、缓存命中情况，缺字段就没法复盘
• 用真实用量反推花费，和账单对一遍
• 差得多时先查口径，再怀疑平台
• 对差额最大的那个任务，重新评估一次档位是否还合适

顺序上有个经验：先对齐口径，再看趋势，最后才看绝对值。口径没对齐时，绝对值比较没有意义，趋势也容易误读。有疑问时到 /guide 看有没有同类问题的排查记录。

拿到任何一个单价，先问三件事：每多少 token、什么币种、含不含缓存。答不上来，这个数字就先别用。