很多人搜「deepseek 的 api 价格 1 元钱多少万字」，想要一个能直接抄的数字。但这个数字取决于你选的模型档位、输入还是输出、文本中英文比例，任何写死的答案都会失真。这篇不讲结论，只给一套换算流程：去哪看单价、怎么量自己文本的 token 密度、按什么口径折算成万字，以及哪些情况下这套算法会算偏。
很多人搜「deepseek的api价格1元钱多少万字」，心里想要的是一个能直接抄的数字。但真实情况是，这个数字会随你选的模型档位、输入还是输出、中英文比例、有没有走缓存而变，谁写死一个答案都会失真。这篇不讲结论，只给一套你自己能复算的流程：去哪看单价、怎么量自己文本的 token 密度、按什么口径折成万字。
先把心态摆正：一块钱能跑多少字不是产品参数，是一道算术题。题目里三个变量——单价、token 密度、输入输出比例——每一个都得你自己填。下面按顺序走一遍，你会得到一个属于你自己业务的区间，而不是一个转发来转发去的数字。
为什么没有人能直接给你一个「一块钱多少万字」的数字
同一块钱，买到的量可以差出好几倍，原因就在单价结构上。输入和输出是两个价，缓存命中和未命中又是两个价，官方页面上的数字还会调整。所以第一步永远是去 /official-api/providers/deepseek 看当前单价，再把数字代进你自己的算式，而不是记别人截图里的数。
- 单价随模型档位和方向变化：输入便宜、输出贵，同一块钱买到的量差好几倍，先看清你用的是哪一档
- 中文和英文的 token 密度完全不同：同样「一万字」，中英混排的 token 数可能差一截，先到 /ai-dict/category/basics 把 Token 和字数的基础关系弄清
- 计费口径会改结果：缓存命中、批量通道的计价方式不一样，不看清口径算出的万字数是虚的
- 单价本身会变：想确认有没有调过价，到 /price-watch 看历史记录，别拿旧价硬算
第一步：量出你自己文本的 token 密度
这一步最容易被跳过，也最影响结果。别拿官方示例或随便一段新闻来测，要拿你真实业务里要跑的那类语料，比如客服对话记录、产品说明文档、代码片段。不同语料的 token 密度能差不少，测错一份，后面全白算。
- 挑一份真实语料选三千字左右、和你日常任务最接近的文本，中英混排的就把混排比例也带上，别为了好算而简化。
- 跑一遍 token 计数用 /tools/token-price-calculator 把这段文本过一遍，记下 token 数，别凭感觉估。
- 算出每字系数token 数除以字数，得到「每字多少 token」这个系数，中文场景通常明显大于 1，注意单位别搞反。
- 按场景各测一份对话、长文档、代码各测一份，分别记下系数；后面按任务类型套对应的那份，不要一份系数打天下。
| 文本类型 | token 密度倾向 | 对换算的影响 |
|---|---|---|
| 纯中文叙述 | 较高 | 同样字数消耗更多 token，一元可跑字数偏低 |
| 纯英文 | 较低 | 一元可跑字数偏高，但别直接套到中文任务上 |
| 含大量代码或表格 | 明显偏高 | 标点、缩进都会被切分，实测为准 |
| 中英混排 | 介于两者之间 | 按你真实混排比例测，别用纯中文代替 |
第二步：把单价换算成「一块钱多少字」
有了单价和每字 token 系数，就能代公式了。核心是输入和输出分开算，再按你实际的输入输出比例加权。只看输入单价是最常见的错误，实际扣费里输出那部分的权重往往被低估。
一元可跑字数 ≈ 1 ÷ 单价 × (1 ÷ 每字token系数) # 输入、输出分别算，再按实际比例加权- 每字 token 系数
- 上一节实测得到的 token 数除以字数，中文通常大于 1
- 输入输出比例
- 你业务里平均每次调用输入和输出各占多少，用调用日志估
- 加权单价
- 输入单价和输出单价按上述比例合成的一个等效单价
如果你不想手算，直接用 /tools/model-cost-calculator 代入单价和字数反推；手算和工具算出来的结果对不上，先回头查是不是把输入输出搞混了。
第三步：三个最容易算偏的地方
- 把「字数」当「token 数」用：中文场景误差最大，长文档任务尤其明显，一字一 token 是错的
- 忽略上下文重复发送：多轮对话每轮都把历史重新计入输入，实际消耗远高于单次文本长度
- 只按成功请求估总账：重试、失败请求、工具调用也会计费，账要拿调用日志对，用量口径可参考 /usage 页面的说明
这三条踩中任意一条，算出来的万字都会偏乐观。建议先拿一小批真实流量跑一天，把实际扣费和你的估算对一遍，差异超过预期就回头检查是哪一条没算进去。
什么情况下这套换算法不适用
这套流程的前提是：按官方线性单价计费、没有额外折扣、文本结构相对稳定。满足不了这些前提，算出来的数字就只能当粗略参考，不能拿去做预算。
- 走中转站或聚合平台时：标价是折算后的倍率价，先按 /ai-dict/category/basics 这类口径把计价方式对齐，再谈换算，不能直接套官方单价
- 有免费额度、赠送额度或阶梯折扣时：边际成本不是线性单价，这时算「一块钱多少字」意义不大
- 批量任务或缓存命中场景：单价结构本身就不一样，应换用长文档成本的评估思路，别硬套单次文本的公式
- 文本结构波动很大的业务：今天跑短问答、明天跑长报告，任何单一系数都会失真，建议按类型分开记系数
判断标准很简单：如果实际扣费和你估算的偏差能稳定控制在可接受范围内，这套算法就可以继续用；偏差忽大忽小、且找不到原因，说明你的场景已经超出它的适用范围了。
最后提醒一句，单价这类会变的数字，永远以站内当天页面为准。想横向比不同官方渠道的单价结构，可以去 /rankings 看当时的对照，别把本文里的任何示例当成实时报价。
下一步拿你手头一段真实语料，去 token 计数工具跑一遍，再代进成本计算器，半小时就能得到属于你自己业务的万字区间，比记任何现成数字都靠谱。→常见问题
能不能直接告诉我 deepseek 一块钱大概能跑多少万字？
任何直接给死数字的回答都不靠谱，因为单价、模型档位、输入输出比例每天都在变，你的文本 token 密度也只有自己测才准。正确做法是去官方价格页抄下当前单价，用 token 换算工具量出自己的每字 token 系数，再代入公式算一次，这样得出的区间才是针对你自己业务有效的。
中文和英文的换算结果会差多少？
差别不小。同样一段内容，中文常用字往往一个到两个 token，英文按词或子词切分，整体 token 密度跟中文不是一个量级，代码和表格又会把系数继续推高。所以别拿一份英文语料的系数去估中文任务，最好按你业务里主要出现的文本类型各测一份，取加权值。
输出比输入贵，那估成本时该怎么算？
按你的真实输入输出比例加权。很多任务输入很长、输出很短，这时候输入单价占主导；但如果是摘要、改写、生成类任务，输出可能占大头。先统计一批真实调用日志里输入和输出 token 的占比，再分别乘各自单价求和，比只按输入单价估算准得多。
