deepseek价格收费标准

做预算时最容易翻车的不是单价贵，而是口径没对齐：拿错档位、把输入输出混算、忘了缓存和批量的差别，最后预算表和账单对不上。这篇不背数字，而是把 DeepSeek 的计费档位、要核对的字段、以及一套可复用的预算与核对流程讲清，让你手里的预算表能跟着官方页面自己更新。

做预算时最容易翻车的不是单价贵，而是口径没对齐：拿错档位、把输入输出混算、忘了缓存和批量的差别，最后预算表和账单对不上。这篇不背数字，而是把 DeepSeek 的计费档位、要核对的字段、以及一套可复用的预算与核对流程讲清楚。

目标很朴素：让你手里那张预算表能跟着官方页面自己更新，而不是每调一次价就得重做一遍。下面按「先分清维度、再挑档位、然后搭表、记日志、对账、重算、排错、例行」的顺序走，每一步都给你能直接照做的动作。

先分清 DeepSeek 的计费是按哪几个维度切的

很多人以为计费就是一个单价乘总量，其实它至少切了四层。第一层是模型档位，不同档位对应不同的能力与延迟预期，不是同一个东西打折。第二层是方向，输入和输出分开计，价格通常不一样。第三层是缓存，命中缓存的部分往往走另一套价。第四层是调用方式，批量离线处理和实时在线调用不是一个口径。

把这四层拆开看，任何一层对不上，算出来的数就是错的。举个通用场景：一家 5 人小团队做的客服摘要功能，白天实时调用、夜里跑批量补数据，这两条路径的单价结构就不一样。如果你只按一个平均单价估，月底必然对不上。具体每档当期值一律以站内官方价格页为准，不要把历史印象写进预算表。

档位

按能力与延迟预期划分的模型层级，决定基础单价区间

方向

输入（发出去的上下文）与输出（模型生成的内容）分开计价

缓存

相同前缀的重复输入被复用时的计费方式，通常与普通输入不同

批量

离线提交、对时效不敏感的任务通道，计费口径与实时调用分开

你的活该落在哪一档：按任务特征而不是按价格挑

挑档位的正确姿势是先看任务特征，再看价格。短问答、改写、分类这类输入短、输出短、要求快的任务，用低档位通常就够，硬上高档位是浪费。长文档理解、多轮推理、需要读大量上下文再给结论的任务，低档位容易答不全，反复重试反而更贵。

还有一种情况是按价格挑最便宜的档位，结果因为输出不稳定，人工兜底和返工成本远超省下的那点调用费。什么情况下该用便宜档：输出格式固定、可校验、错了能自动重试的场景。什么情况下不该省：输出直接面向用户、错了要人工介入的场景。

不适用场景要写清：对输出稳定性要求极高的场景，不要只看单价拍板，先用小流量做一次对照，把两者在真实数据上的表现和重试率都记下来，再决定。具体档位能力差异到 /models 资料库看当时的说明。

把用量换算成预算：一张能自己更新的表怎么搭

预算表的核心不是算得多准，而是能自己更新。表结构建议按「功能模块 / 档位 / 方向 / 月调用量」分行，单价单独留一列或一个区域，只从站内页面抄当期值。这样官方一调价，你只改单价区，不动结构。

1. 第一步：拆模块把产品拆成几个独立调用点，每个调用点单独一行，比如「摘要」「分类」「问答」。验证方式：能对应到日志里的来源字段。
2. 第二步：填用量每个模块填月调用量和平均 token 数，来源是日志导出，不是估的。验证方式：模块用量加总接近日志总量。
3. 第三步：留单价位单价列不写死，标注「见 /price-watch 当期值」，更新时只改这一列。验证方式：改完单价行，总额自动重算。
4. 第四步：加缓冲在总额上乘一个缓冲系数，系数依据重试率、上下文波动、缓存命中情况定。验证方式：回看上月实际花费与预算的差距，据此调整。

从用量记录倒推的思路是：先有日志字段，再有月总量，再乘单价，最后加缓冲。缓冲该留多少没有固定值，重试率高、上下文长度波动大、没做缓存，就该留宽一些；反之可以紧一些。别用一个拍脑袋的固定系数套所有模块。

发生费用之前先把用量记全：日志里必须有哪几列

按次记录不够用，很多账单差异都出在长尾请求上：平时都是短问答，偶尔来一个超长文档，就把那个月的预算顶穿了。所以日志必须能按 token 维度聚合，而不是只能数次数。

• 时间戳：精确到分钟，方便跨月切分和对账
• 模型档位：记录实际调用的档位，不是你以为的那个
• 输入 token：发出去的上下文长度
• 输出 token：模型生成的长度
• 是否命中缓存：区分缓存价和普通输入价
• 请求状态：成功、失败、重试要分开记，重试也可能计费
• 调用来源模块：对应预算表那一行，方便归因

落地动作很具体：先在测试环境开一周完整日志，跑一遍聚合，看清长尾分布，再决定预算表的缓冲系数。别一上来就在生产环境大改，先用测试数据把字段和口径校准。

月底对账的固定顺序：从差异反推原因

对账不要一上来就看总账，那样差异原因会被掩盖。按固定顺序逐层缩小范围，能最快定位到哪一层口径没对齐。顺序是：先比总量，再比方向，再比缓存，最后比周期。

1. 比总量用日志总量乘单价，和账单总额比。差异大说明单价比对错了，去 /price-watch 重新核对当期档位价格。
2. 分方向把输入和输出拆开各自比。输入对不上多半是上下文长度估错；输出对不上多半是生成长度波动。
3. 查缓存看命中缓存的部分是否按缓存口径算。缓存价和普通输入价不同，混算会拉大差异。
4. 切周期确认账单周期和你的统计周期是否完全对齐，跨月调用和结算时点差都会造成假差异。

常见差异来源还包括预扣与结算的时点差、失败重试是否计入。什么情况下不要自己猜：差异持续存在且逐层都对齐不了，这时候要怀疑渠道计费口径，用站内中转站目录与可信度排行检查你走的渠道是不是按官方口径算的。

什么时候必须重算一遍预算

预算不是做完就扔那的，要有明确的触发条件。触发条件一到就重算，别等账单来了才发现。重算不等于全表重做，通常只需要改单价列和少数几行的用量。

• 官方价格调整：以 /price-watch 的变动记录为准
• 切换模型档位：换档就换单价行
• 上线批量任务：口径从实时切到批量
• 上下文长度显著变长：输入 token 基数整体抬升
• 并发与 RPM 限制变化：可能被迫分流到其他档位或渠道

把价格变动追踪页加进定期巡检，每周或每月扫一眼，比等账单出问题主动得多。巡检动作就是打开 /price-watch 看有没有标红的变动，有就改预算表的单价列和缓冲系数。

预算表最常见的几个错法，逐条对照排查

下面这几条是反复出现的错法，逐条对着自己的表查一遍，能解决大部分对不上账的问题。

还有一个隐蔽错法：把中转站的折算价直接当官方价写进预算表，忽略了折算口径和汇率成本。这类渠道的计费未必和官方逐字对应，用之前先到 /sites 看渠道说明，并在表里单独标一列「计费来源」，别和官方口径混在一起。

把它变成每月十分钟的例行动作

这套东西要能持续，就得压缩成固定动作，每月十分钟跑完。动作顺序固定：抄当期单价、导出用量、跑一次对账、更新缓冲系数、记录本月结论。谁来做都行，关键是别攒到季度末，那时差异已经混在一起，翻不回去了。

• 抄单价：从 /price-watch 抄当期值到预算表的单价列
• 导用量：按模块和方向导出上月 token 聚合
• 对账：按总量、方向、缓存、周期四步走一遍
• 调系数：根据实际与预算的差距更新缓冲系数
• 记结论：一句话写下本月为什么多了或少了，供下月参考

刚起步时还能再简化：只盯三个数——总调用量、总 token、总花费。先把这三个数跑通、能对上账，再往细里拆模块和方向。一上来就搭复杂表，大概率维护不下去。

预算表的准确度不来自一次算得多细，而来自每月能稳定对上一次账。