deepseek 价格前后对比

很多人只记得「DeepSeek 便宜过」或者「好像涨了」，真要写进预算或者跟老板解释，却发现手里只有零散截图和别人的转述。这篇不给你背数字，而是给一套对比方法：调价前后哪些口径变了、旧账和新账分别去哪看、怎么把两次价格放进同一张表里算清实际影响，以及什么情况下这套比法不成立。

很多人对 DeepSeek 的印象停在两个模糊的节点上：要么记得它「曾经特别便宜」，要么隐约觉得「后来好像调过价」。真到要重报预算、跟老板解释为什么这项支出变了、或者合同里要写新报价的时候，手里往往只有几张零散截图和别人的转述，谁也对不上。这篇不给你背任何数字——价格随时会变，写死的数字第二天就可能失效——而是给一套可以反复用的对比方法：调价前后哪些口径变了、旧账和新账分别去哪看、怎么把两次价格塞进同一张表算清实际影响。

核心思路只有一句：比价不是比两个数字，是比「同一份用量在两套计价规则下分别花多少」。单价涨了但你的用法变了，结论可能完全相反；单价没动但分档规则改了，也可能等于变相涨价。所以下文会先讲清动机，再对齐口径，然后带你去站内固定几个页面核对当期数字，最后给一张能直接套用的对比表和一份能长期维护的记录清单。哪些情况下这套比法不成立，也会单拎出来说。

先想清楚：为什么要做「前后对比」

做对比之前先写一句话：我要证明什么。是预算要重报，是合同要重谈，还是某个具体任务的成本要重算？这三种动机对应的取数方式完全不同。预算重报关心的是月度总量，合同重谈关心的是单价条款和分档规则，任务成本重算关心的是输入输出比例和缓存命中率。目标不同，却往往用同一张截图去论证，结果就是数字对不上、谁也说服不了谁。

• 动机一：预算重报。重点看总账，也就是你这段时间的真实用量乘以当期价格，单价的涨跌只是其中一项。
• 动机二：合同重谈。重点看条款口径，包括计价单位、输入输出是否分开、缓存是否单独分档、有没有最低消费或阶梯。
• 动机三：任务成本重算。重点看用量结构，同样是处理一批文本，输入输出比例不同、并发高峰不同，落在账面上的数字能差出可观的幅度。
• 先定结论再取数：写下「我要证明 A 任务单位成本变了多少比例」，再决定抓哪几个字段，否则会陷进比价表格里出不来。

对齐口径：DeepSeek 调价前后动了哪些变量

很多人以为调价就是「单价从 A 变成 B」，其实经常动的是一整套计价规则。按百万 token 统一计价，和按缓存命中、未命中分档计价，是两种完全不同的口径，后者的实际到手成本高度依赖你的命中率。拿这两种口径下的数字直接相减，得到的差额没有意义，因为它混了两件事：价格变了，以及计价方式变了。

这张表建议你自己按当前情况填一遍，尤其是最后两列。填不出来的格子，就是你去站内页面要专门核对的点。处理完这些变量，你手里的「调价前价格」和「调价后价格」才真正可比。

去哪看当期数字：站内几页固定核对点

价格类信息最怕的就是用旧文章的截图。别人的文章写完就定格了，价格还在动。固定做法是：官方口径的当期价格统一到站内官方 API 价格页核对，历次变动的时间线到价格变动追踪页翻，用量和真实结算侧去真实用量榜交叉验证，模型规格差异到模型库确认。四个页面各司其职，别用一页的结论去替代另一页。

核对时顺手记下三件事：你打开页面看到的当期数字、页面口径说明、以及你打开的时间。站内价格页和追踪页的数字会随时间更新，具体是多少一律以你打开那一刻页面显示的为准。这三条记下来，后面你自己复算时才追得回来。

把两次价格放进同一张表：可复用的对比步骤

方法本身不复杂，难的是每次都按同一顺序做，不然结果不可比。下面五步是一套固定流程，下次调价直接照做，不用重新想。

1. 第一步：固定用量样本拿你最近一段真实用量做基准，包含输入 token、输出 token、缓存命中比例、调用次数。不要用假设的「一百万 token」，那会把结论带到跟你无关的方向上。真实用量可以从你自己的计费后台或调用日志导出。
2. 第二步：两套价格套同一份用量把调价前和调价后的计价规则分别套进同一份用量样本，输出三列：调价前花费、调价后花费、差额。注意两套规则的分档方式可能不同，套的时候要按各自规则算，不能直接乘同一个单价。
3. 第三步：拆分差额来源把差额拆成两块：一块来自单价变化，一块来自用量结构变化。两块分开写，结论才站得住。如果用量结构这段时间刚好也变了，混在一起讲会被追问到答不上来。
4. 第四步：落成一句可复用结论把结果写成一句能直接引用的话，比如「同类任务每千次调用的成本变化了多少比例」。带上任务类型和用量特征，下次有人问直接甩这一句，不用翻表格。
5. 第五步：套用站内计算工具省事换算公式如果懒得自己搭，可以借站内工具类页面的成本计算器来算，把两套价格和你的用量填进去，核对结果是否和你手算一致。具体入口到 /tools 工具目录里找当下的计算类页面。

这套流程的关键是第二步和第三步。绝大多数比错的案例，都错在拿两套不同口径的价格直接相减，或者把用量变化带来的成本变化算到了单价头上。你只要保证「同一份用量、同一套换算口径、差额拆两块」，结果基本不会跑偏。

容易比错的四个地方

下面四种错法很常见，共同点是「方向看起来对，幅度完全不对」。每一条都给了排查动作，做完再下结论。

这四条里，第一条和第四条最容易被忽略，因为它们不会让结论符号反掉，只会让幅度失真——而幅度恰恰是你要拿去报预算的那个数。第二条和第三条则可能直接让结论反过来，也值得单独验一遍。

对比完之后：判断这笔变化到底要不要动手

拿到差额之后，不是立刻换方案。先看两个维度：总账占比和用量弹性。占比小，说明这事在你的支出结构里本来就不重要，调整优先级可以往后放；弹性大，说明你可以通过分批、提高缓存命中、在允许的范围内换档位来消化，未必需要换供应商。两个维度都高，才值得认真动手。

总账占比

这项支出在你月度 AI 预算里排到第几位，占比小的先别急着折腾

用量弹性

你的调用方式能不能改：能否分批、能否提高缓存命中、是否允许换档位

切换成本

换供应商或换方案要改多少代码、重跑多少验证，别只看单价省没省

质量与延迟要求

如果任务对结果质量或响应延迟有硬要求，能动的空间可能很小

什么时候这套比法不适用？如果任务对延迟或质量有强硬要求、不能换档位、也不能改调用方式，那所谓「通过结构优化消化涨价」这条路基本走不通，你能做的只是把新价格如实写进预算并说明原因。反过来，如果你的用量本身就不稳定、样本期太短，那算出来的差额参考价值有限，建议先攒够一段稳定用量再比。判断依据写进一份短备忘录，下次调价直接翻出来改数字，不用重新推一遍。

留一份可复盘的记录：下次调价不用重新查

比价这件事的收益是复利的：第一次做花两小时，第二次十分钟。前提是你留的是一份「能重算的输入」，而不是一堆截图。截图里的数字一旦对不上，你连它当时是什么口径都判断不了，只能从头再查一遍。

• 记录字段至少包含：记录时间、来源页面路径、口径说明（计价单位与分档方式）、你当时的实际用量样本、折算后结果。
• 不要只存截图，存输入：用量数据、换算公式、两套价格的口径描述，这三样在手，结果随时能重算。
• 更新频率比精度重要：每次大调价后更新一次，每月顺手核一次，比你追求一次算到完美更实用。
• 团队里指定一个人维护这份记录，避免多人各存一份、互相矛盾，最后没人敢用。
• 结论栏写一句可直接引用的话，附上适用条件，别人拿去用的时候知道边界在哪。

这份记录不需要多复杂，一张表加一份短说明就够。真正有价值的不是某一次算出来的差额，而是「同一份用量在两套规则下怎么比」这件事你已经有了固定流程。下次 DeepSeek 再调价，你打开这张表改两个数字就能交差，而不是重新去网上翻别人的转述。