deepseek 百万 token 价格

很多人接完 DeepSeek API 才发现，账单既不是按「次」收，也不是按「字」收，而是输入和输出分开按 token 累计。等第一次对账单的时候，才发现缓存命中、输出占比、系统提示词长度都在悄悄影响结果。这篇不背数字，而是把百万 token 的计价结构、用量拆法和估算步骤讲清楚，让你能自己推算。

很多人接完 DeepSeek API 才发现，账单既不是按「次」收，也不是按「字」收，而是输入和输出分开按 token 累计。第一次对账单的时候，往往才注意到缓存命中、输出占比、系统提示词长度都在悄悄影响结果。这篇不背数字，而是把百万 token 的计价结构、用量拆法和估算步骤讲清楚，让你能自己推算一个月大概要花多少。

先说清楚一件事：下面提到的所有单价、比例、月花费，都不写死在这里。单价会变，模型档位会变，你的业务比例更是只有你自己知道。所以要养成的习惯是——报价去站内官方页面对照，用量从自己返回体里抄，估算表自己维护。看完这篇你手里应该有一张能跑起来的成本表，而不是一段背下来的数字。

先搞清「百万 token」到底在卖什么

「百万 token」是报价的计量单位，不是套餐包，别把它当成一次买断的额度。真正要分清的是按 token 计费的三个层次：输入、输出，以及缓存相关的读写项。这三类单价通常不一样，尤其是输出，往往显著高于输入。很多人的误区是把它们当成一个总单价去乘总量，算出来的结果和账单自然对不上。

输入 token

你发给模型的内容，包括系统提示词、历史对话、检索回来的资料，全都算在这里

输出 token

模型生成并返回给你的内容，单价一般高于输入，长回答任务要重点盯这一项

缓存读

命中缓存的那部分输入，通常比普通输入便宜，但前提是你的请求前缀稳定可复用

缓存写

把内容写进缓存的那一侧，是否单独计费、怎么计，以站内官方页面的口径为准

所以实际花多少，取决于你的输入输出比例。一个把长文档丢进去只求一句话结论的任务，和一个让模型自由发挥写长文的任务，即使总 token 数一样，账也完全不一样。做预算前先把这三类的当期单价列清楚，到站内官方页面对照当时的数字，不要用记忆里的数字做预算。

去哪看 DeepSeek 的当期报价，怎么读那张表

读价格表最容易出错的不是看漏行，而是看错口径。先确认表头：哪些列是输入、哪些列是输出、缓存有没有单列出来。再看单位标注，有些页面会给到更小单位的报价，换算成百万 token 时要乘对倍数，漏乘一次整张预算表就偏了。最后区分标准价和条件价，夜间、批量之类的优惠档往往有生效前提，不满足就按标准价走。

• 把你要用的那个模型行单独摘出来，存成一份自己的对照表，比价和记账都以这一行为准
• 注意单位标注是每百万 token 还是更小的粒度，换算倍数写在自己表里，别靠临时心算
• 区分标准价和条件价，优惠档要写清生效前提（时段、批量、缓存命中等）
• 报价页面的更新不一定有通知，把核对动作排进固定周期，而不是想起来才看
• 遇到同一模型出现多个价格条目，先看它们的适用范围说明，别默认挑最低的那条

如果你还要横向对比不同家的报价，别只比一个单价数字。把输入价、输出价、缓存价、以及有没有条件价这几项一起摆出来看，结论往往和只比单价时不一样。站内比价页面会把这些维度并排放，自己去核对当时的数字即可。

输入和输出的比例，才是决定成本的大头

同样是百万 token，全输出和全输入的账差得很远。因为输出单价通常更高，一个输出占比高的任务，成本会被显著放大。所以估算的第一步不是算总量，而是估一个输入输出比。这个比例从业务场景来：摘要、分类、检索问答这类偏输入；写文案、写代码、生成报告这类偏输出。

有一个容易被忽略的点：系统提示词、历史对话、检索回来的资料全都算输入。特别是带固定人设或多轮记忆的应用，每次请求都会把这些重发一遍，占比往往比你想象的大。想知道真实比例，别拍脑袋，拿一段真实请求跑一次，把返回体里的输入和输出 token 数记下来。

这张表只是给你一个分类框架，比例还是要用自己的真实请求去测。不适用的情况是：如果你的调用形态非常单一，比如每天固定批处理同一个模板，那直接用实测平均值代替分类估算就行，没必要建复杂模型。

怎么把一次调用换算成 token 数

估算是估，测量是测量，两者要分开。先建立手感：用站内的 token 换算工具把一段真实文本过一遍，看看多少字大概对应多少 token。注意中文、英文、代码的 token 密度不一样，混排内容不要用同一个系数硬套，否则估算会系统性偏一侧。

1. 准备样本从你线上真实请求里挑 3 到 5 条有代表性的，包含最短、最长和典型场景，别只用最干净的那一条
2. 过一遍换算工具把样本文本丢进站内 token 换算工具，记下输入侧的 token 数，建立「多少字对应多少 token」的手感
3. 调用后读返回体每次调用后从返回体的用量字段里读实际输入、输出 token 数，这是唯一权威的来源
4. 对比估算与实测把实测值和事前估算对一遍，差得多就找原因：是提示词写长了，还是上下文没截断
5. 写进成本表把修正后的系数写进你的成本表，以后每加一个功能，都按新比例重算一遍

这里有个纪律：不要用估算值去对账，对账只认返回体和账单里的实际数。估算的作用是事前做决策，比如「这个功能上不上」「要不要换档位」，而不是事后解释差异。

从单次成本推到月度花费的步骤

单次成本清楚了，接下来是往月度推。核心是把输入和输出分开算，绝对不要混在一个总单价里。混算的结果在小用量时看不出问题，量一大就会和账单差出一截。下面是可执行的顺序。

1. 算单次用量取一个典型请求，记下输入 token 数和输出 token 数两个数，分开记，不要合并
2. 乘日调用量输入、输出分别乘以每天调用次数，得到日用量的两个分量
3. 推到月度日用量再乘 30 得到月用量，同样保持输入、输出两条线不合并
4. 分别乘单价输入月用量乘输入单价，输出月用量乘输出单价，两个结果相加才是总成本；单价到站内官方页面核对当时的数字
5. 加余量与重试按业务流量波动加一定比例的余量，并把重试、失败重发产生的额外调用也算进去，这步不是可选项
6. 存成模板把整套算法做成一张表，输入、输出、次数、余量四个格子可改，下次新功能直接套

余量留多少取决于你的业务流量波动，没有统一答案。波动大、有活动峰值的业务要多留；内部工具、低频调用可以少留。不确定就先用偏保守的数值跑一个月，再按实际对账结果回调。

怎么跟踪单价变化和用量变化

账单涨了有两种可能：单价变了，或者用量涨了。这两种情况的处理方式完全不同——单价变了你只能重新做预算或换档位，用量涨了要去查是哪个功能带来的增量。如果不分开记，就会陷进「感觉变贵了但不知道贵在哪」的状态。

• 把报价来源固定成站内页面，隔一段时间核对一次，不要靠记忆里的数字
• 用量侧单独记三个数：请求数、输入 token、输出 token，缺一个就没法复盘
• 给用量加一个简单的趋势记录，不用复杂工具，一张按天追加的表就够
• 发现异动先分类：是单价调整，还是某个功能上线带来的用量跳变
• 给总花费设一个阈值提醒，超过就去看，别等到月底才发现

不适用的情况也要说清楚：如果你的调用量很小且低频，专门做跟踪投入的精力可能不划算。这种情况下更现实的做法是设一个预算告警，超了再回头查，而不是每天盯趋势。

在不改需求的前提下压成本的方向

压成本不等于砍功能。多数时候，钱花在了结构上而不是需求上。按下面几个方向过一遍，通常能找出不需要动产品逻辑就能改的地方。注意这些是方向不是承诺，具体能压多少取决于你的请求结构，自己去测算。

这些方向里，缩短固定前缀通常是收益最直接、风险最小的一个。但它也有前提：提示词缩短后输出质量不能明显下滑，所以改完要拿一组样本对比，别直接上线。

账单出来后怎么核对，差在哪一步

对账的顺序很重要：先对齐单价口径，再对齐用量口径。多数差异来自把缓存读写混进了普通输入，或者漏算了重试产生的调用。按下面的顺序走一遍，基本能定位到差异出在哪一层。

1. 对齐单价拿你记账时用的单价，和站内官方页面当期数字逐项比，确认输入、输出、缓存各列都对得上
2. 对齐用量把你的用量记录和账单里的量对比，重点看缓存读写有没有被算进普通输入
3. 排查重试检查是否有失败重发、自动重试的调用被计入，这部分会实实在在累加，容易漏
4. 定位最大偏差项把估算表和实际值放一起，差得最多的那一项就是下次要改的估算参数
5. 固定节奏把对账变成一个每月固定的小动作，比事后追查便宜得多

估算是用来做决定的，对账是用来修正估算的；两件事别混着做。

最后提醒一句：上面所有涉及具体数字的地方——单价、你的输入输出比、月花费、余量比例——都请你到站内对应页面去核对当时的数字，再用自己的请求实测填进去。这篇文章给的是流程和判断标准，数字永远以你现场看到的为准。