DeepSeek宣布调整API价格

官方一发调价公告，最慌的往往不是还没接入的人，而是已经写在线上、每天有稳定调用量的开发者。这篇不讲新闻本身，只讲你该按什么顺序确认自己受不受影响、哪些调用会变贵或变便宜、预算要不要重算、以及什么情况下值得考虑换路线。

官方一发调价公告，最慌的往往不是还没接入的人，而是已经写在线上、每天有稳定调用量的开发者。公告本身讲的是什么价、什么时候生效，二手转述经常有偏差，所以这篇不重复新闻，只讲你该按什么顺序确认自己受不受影响、哪些调用会变贵或变便宜、预算要不要重算、以及什么情况下值得考虑换路线。

调价这件事对每个人的含义完全不一样：一个月调用几次的人基本无感，把接口当成核心链路的团队才需要动脑子。下面按「先搞清落点、再重算预算、再决定动不动架构、最后看日常运维」四步走，每一步都给你可执行的判断标准，而不是让你凭感觉慌。

先弄清调价落在你账单的哪一段

调价公告的标题通常写得很宽，但实际生效范围往往比标题窄。第一步不是算钱，而是确认你自己到底调了哪个模型、走的是哪条通道、按什么口径计费。这一步做错了，后面所有测算都是白算。

具体来说，调价的落点大致分四类：单价档位变化、计价口径变化、优惠或折扣规则变化、只在某类模型或某个通道生效。你要做的是把公告里的生效范围和自己的调用记录对齐，看落在哪一类上，而不是被标题里的「全系」两个字带着跑。

• 把最近一段时间的用量记录按模型、按输入输出拆开，看每项占你总花费的比例，占比小的那几项就算涨了也不值得动架构
• 区分一次性影响和结构性影响：偶发的批量任务涨点钱无所谓，每天固定跑的定时任务才是要重算的部分
• 确认计价口径：是按输入输出 token 分开算，还是按调用次数算，有没有缓存、批处理这类特殊档位，口径不同结论可能相反
• 判断标准很直接：如果某项调用在你总花费里占比很低，就别为它改技术方案；不适用的情况是，你正好处在试用阶段、调用量很小，调价基本不影响你，先别急着优化

把预算重算一遍，别用脑子估

很多人听到调价后的第一反应是「大概会贵一点吧」，然后就没有然后了。正确做法是拿真实的用量日志倒推，而不是拿当时的单价乘一个想象出来的调用次数。单价去哪看，写在下面 sources 里的官方页面，站内也有换算工具可以套，直接套你自己的日志数据。

重算的时候，把缓存、重试、超长上下文这几项都算进去。调价公告里的单价往往只是基础价，实际扣费口径可能不止一层。算完之后做三档测算，看最坏那档会不会击穿你的月度预算线，再决定要不要设告警。

判断标准：如果重算后月度差额在你的容错范围内，就不要为了省这笔钱去改已经稳定的链路，改动的调试成本和引入故障的风险通常比省下的钱更贵。真正的数字，到站内价格与成本相关页面核对当时的报价口径，别用记忆里的老账。

要不要换模型或换路线的判断顺序

调价之后最容易被带偏的动作就是「马上换一家」。换不换，取决于这个模型在你系统里承担的是什么活，而不是取决于单价涨没涨。

1. 先分类你的调用把调用分成离线批处理和在线交互两类：离线批处理可容忍延迟，切换或换便宜档位的空间大；在线交互对稳定性和输出质量敏感，省下的钱可能不够补体验损失
2. 按完整链路算对比别只比单价，要按同一个真实任务的完整链路算一遍，包括失败重试、额外调用、人工返工这些隐性成本
3. 先跑影子流量如果决定并行试一条替代路线，先跑影子流量对比成本和输出，不要直接切主流量；对比一段时间后再决定是否迁移
4. 设好回退条件切换前写清楚什么情况下回退，比如输出质量下降、失败率上升，避免为了省钱把线上搞挂

不适用的情况也要说清楚：如果你的业务对某家模型有明确的能力依赖或合规要求，这时调价只是成本项之一，不该成为切换的主导理由。另外，如果你的调用量本身很小，切换带来的迁移成本很可能远超省下的费用，这种情况下保持不动反而更理性。

调价当天到一周内的动作清单

调价不是一次性事件，而是一次让你检查成本管理习惯的机会。下面这份清单按时间顺序排，照着做基本不会漏。

还有一个容易被忽略的动作：把这次调价的假设写进你的测算表备注，比如「假设缓存命中率不变」「假设用量按近期趋势走」。下次再调价，你直接改这几个假设就能重算，不用从头来一遍。这比每次调价临时抱佛脚省事得多。