DeepSeek全系API价格大降

你可能正拿着上个月的账单发呆：DeepSeek 降价的新闻刷到了，但自己的调用结构和它未必对得上。这篇不讲新闻本身，只讲怎么把这次调价落到你自己的用量上——先把口径对齐，再挑出能挪过去的任务，最后把预算和告警重新设一遍。

你可能正拿着上个月的账单发呆：DeepSeek 降价的新闻刷到了，但自己的调用结构和它未必对得上。这篇不讲新闻本身，只讲怎么把这次调价落到你自己的用量上——先把口径对齐，再挑出能挪过去的任务，最后把预算和告警重新设一遍。

核心提醒只有一句：调价改变的是单价，不改变你的用量形状。所以真正决定账单的是调用结构、重试次数和并发习惯。下面按「重算—挑任务—改预算—设闸门」四步走，每一步都有可落地的动作，你可以边看边改。

先别急着换：把你的用量重算一遍

直接把新单价乘上旧用量，是最容易出错的做法。因为一次降价对不同任务的影响幅度并不一样：输入输出比例悬殊的任务，感受差别很大。先把最近一个月的调用按任务类型拆开，标出各自的输入输出比例，再决定怎么估。

1. 导出并分类把近一个月的调用日志按任务类型分组（问答、摘要、抽取、代码补全等），每组记录调用次数、平均输入长度、平均输出长度。
2. 对齐口径先到 /ai-dict/category/basics 把 Token、上下文长度这些概念对齐，避免把字符数和 Token 数混着算。
3. 做单价换算用 /tools/token-price-calculator 把新单价代进去，得到每组任务的新估算成本；把结果和旧账单并排放。
4. 判定影响面如果账单大头是图片、语音或检索费用，这次降价对你的影响很小，可以暂时不动。

哪些活适合挪过来，哪些别动

降价不代表所有任务都该切过去。判断标准不是「单价低不低」，而是「这个任务对失败有多敏感」。失败一次重试，省下的单价差可能就被吃回去，甚至反超。

验证方法很朴素：拿同一批真实样本，在新旧两边各跑一遍，比对输出质量和总耗时，而不是只看单次单价。想看同一任务换模型后账怎么算，可以参考 /switch-model-cost-savings 的测算思路，再决定要不要动。

调价之后，预算表要改哪几格

很多人的成本表把单价写死在公式里，一调价就得全表重算。更稳的做法是把单价抽成变量，预算表只引用变量，下次价格变动只改一处。

• 把单价写成独立单元格或配置项，所有任务成本公式引用它，而不是直接填数字。
• 按任务分别列输入、输出、缓存三类用量，每一类单独设上限，而不是只给一个大总额。
• 预扣与最终结算之间常存在差额，预算要预留一档缓冲，别按理论值卡死。
• 字段怎么组织可以参考 /ai-cost-estimate-template 那类模板的结构，照着改比从零做快。
• 每季度重跑一次测算，别等账单出来才发现结构已经变了。

降价的收益，只有在用量结构稳定、失败可控的前提下才真正落到账单上。

设好闸门，别让降价变成多花

单价变低，人的心理阈值也会跟着松：重试多来几次、并发开大一点、超时设长一点。结果用量涨得比单价降得快，账单反而更大。先把这几道闸门定死，再谈迁移。

1. 定重试上限给每个调用通道设最大重试次数和退避策略，超过就失败返回，不要无限重试。
2. 设两级告警一级按日用量阈值提醒，二级按总额上限做硬停，硬停优先级高于任何业务逻辑。
3. 对照同规模量级用 /usage 那类真实用量榜，看看同规模项目的日常调用量级，判断自己是不是跑飞了。
4. 每周扫异常来源多数超额来自某条循环、定时任务或忘记关闭的测试调用，固定每周扫一次。