deepseek api token价格

很多人第一次给项目接 DeepSeek，卡在同一件事上：模型页和价目页都看过了，还是不知道自己的活该用哪一档、一个月大概会烧多少。这篇不讲具体数字，只讲怎么读计价口径、怎么按任务挑档位、怎么把单价换成自己能对得上的用量。看完你至少知道去哪几个页面核对当期价格，以及选型时该问自己哪几个问题。

很多人第一次给项目接 DeepSeek，卡在同一件事上：模型页和价目页都翻过了，还是不知道自己的活该用哪一档、一个月大概会烧多少。问题不在数字本身，而在没人把计价口径拆开讲——输入和输出是两笔账，缓存命中和未命中又是两笔账，模型之间还分推理型和吞吐型。口径不清楚，看再多数字也对不上自己的用量。

这篇不写具体价格，只讲怎么读计价口径、怎么按任务挑档位、怎么把单价换成自己能对得上的用量。看完你至少知道去哪几个页面核对当期价格，以及选型时该问自己哪几个问题。凡是涉及金额的地方，一律以站内页面当时的数字为准，别拿旧截图做决定。

DeepSeek 的 token 计价到底按哪几个维度算

第一件事是把「一次调用花了多少钱」拆成可统计的小块。同一个模型，输入和输出的单价不是一回事，输入侧还要再分缓存命中与未命中。你做预算时如果只记一个总 token 数，最后一定和账单对不上，因为你根本不知道钱花在哪一段。

• 输入与输出分开计价，同一模型两档单价不同，算成本时必须分别乘各自用量
• 缓存命中与否影响输入侧口径，命中部分和未命中部分不是同一个价（怎么生效看 token-cost 那篇，这里只提醒分开统计）
• 按量计费以每百万 token 为单位报价，换算成一次对话或一次批处理要自己乘，站内换算工具可以做这步
• 推理型任务的输出字数经常远超输入，输出侧要单独拎出来估，别被输入的数字带偏

不同模型档位的差别，决定了你该用哪一档

选档位之前先给任务分类。要推理链条、多步判断的（代码审查、复杂问答、带约束的规划），和只要吞吐、改写、抽取的，本来就该用不同档位。用错档位不是贵一点的问题，是花了两份钱买一份效果。

还有一个容易被忽略的点：长上下文任务的价格压力主要来自输入侧，上下文塞得越满，单次调用越贵，这跟模型档位是两件事。别把「换个便宜模型」当成解决长上下文成本的手段，先看看是不是文档塞太多。

报价去哪查：三个页面各管什么

价格是会变的，所以比价的第一步不是记住数字，而是记住去哪核。站内这几处各管一段，别混着用，也别只看一处就下结论。

/official-api/providers/deepseek

这一家官方基准价与模型规格，最接近原始口径

/official-api 和 /models

同一张表里横向比别家，模型库可按厂商筛

/price-watch

价格调整类内容归得比较全，盯变价看这里

/tools/token-price-calculator

把单价换成你场景的花费，比手算稳妥

核价时有个习惯值得养成：每次查完顺手记下你是在哪个页面看的、大概什么时候看的。过一阵子发现账单和预期不一致，至少知道当时依据的是哪一版口径，而不是凭印象争论。

选型时的四步核查顺序

1. 第一步：拆自己的用量结构把上个月真实用量按输入、输出、缓存命中三类拆开。没有用量记录就先补日志，字段设计可以参考用量日志那篇。拆不开就没法比价。
2. 第二步：同一批任务跑候选模型拿自己的样本在候选模型上各跑一遍，比的是同一批任务的通过率，不是纸面单价。通过率差一截，便宜也没意义。
3. 第三步：代进用量结构算月成本把候选模型的当期单价（到 /official-api/providers/deepseek 核对）代进你的用量结构，算出各自月成本，再和通过率一起看。两个维度分开看容易选错。
4. 第四步：留一档降级方案主模型不可用或限速时切到哪一档，提前测好。别等出事了再临时挑，那时候没时间比价。

接上之后怎么持续盯成本

选型只是开头，接上之后成本会随着任务变化漂移——某天加了个长上下文功能，或者重试逻辑写崩了，账单都会变形。持续盯的目的不是省钱，是早点发现异常。

• 每次调用的模型、输入输出 token、是否命中缓存、耗时记进同一张表，账单和用量对不上时才有依据
• 设一个日或周维度的用量阈值提醒，超了先看是不是重试风暴或长上下文任务混进来了
• 每次官方调价或自己换档位，在记录里留一条时间戳，历史上做过的事才追得回来
• 什么情况下不适用：只偶尔调几次做验证的阶段不必上这套记录，等进入正式开发再补

这套记录还有一个副作用：下次官方调价时，你能直接拿自己的用量结构重算一遍，不用从头再拆一次数据。前面花的时间在这里会省回来。