DeepSeek宣布调整API避坑，具体流程和判断标准

听说DeepSeek要调整API，很多人的第一反应是「我的代码要不要改」「账单会不会变脸」。但真正该问的是：这次调整落在哪个环节——接口地址、计费口径、限速还是模型可用性。这篇文章给一套从上到下的排查顺序：先确认自己调的是什么，再判断属不属于受影响面，最后决定是改配置、切备用入口，还是什么都不用做。

听说 DeepSeek 要调整 API，很多人的第一反应是「我的代码要不要改」「账单会不会变脸」。这两个问题其实都问早了。该问的是：这次调整落在哪个环节——接口地址、计费口径、限速，还是模型可用性。不同环节的应对成本差得很远，先搞清楚落在哪一层，再决定动不动手。

下面这套排查顺序是从上到下的：先确认自己调的是什么，再判断属不属于受影响面，最后决定改配置、切备用入口，还是什么都不用做。每一步都给判断标准和动作，照着走就行。具体数字不要凭记忆，去站内页面核对当时的发布。

先分清「调整」落在哪一层，再谈避坑

把可能的变更拆成四层看，比笼统地问「改了没有」有用得多。同一份公告，落在接入层和落在计费层，你要做的事完全不是一回事。拆开之后，你会发现自己真正受影响的往往只有一两层。

接入层

域名、请求路径、鉴权方式变了，应对方式是改代码和配置

计费层

单价、缓存口径、输入输出是否分开算变了，应对方式是改预算和用量结构

可用层

模型是否下线、别名是否指向新版本，应对方式是改选型和输出校验

限制层

并发、每分钟请求数、单次上下文上限变了，应对方式是改调度和重试策略

判断标准：公告没写清哪一层时，先默认只有计费层和限制层会动，因为这两层对业务连续性的影响最小，你也有时间观察。不适用的情况是：项目对版本号有硬依赖，比如输出要给下游做格式校验，那就不能只按计费层处理，必须逐条核对可用层，别等线上报错才发现。

盘一遍自己的调用清单，标出受影响项

在动手改任何东西之前，先把手头正在跑的调用列出来。没有这份清单，后面所有判断都是拍脑袋。列的时候不用很细，但模型名、调用入口、量级、有没有缓存这几项必须有。

1. 列调用清单每个在跑的服务写一行：模型名、走官方直连还是中转、平均日调用量、是否有缓存、是否走批处理。缺的项标「待补」，别空着。
2. 逐项打勾三项检查：模型名在调整名单里吗；入口是否依赖某个固定路径；账单里占比最大的是输入还是输出。打勾比写评语快。
3. 排优先级按「调用量 × 单价占比」排序，先处理花钱最多的那一项，而不是先处理你最顺手的那一项。
4. 留档把清单落成表格存下来。下次再有调整直接复用，不用从头问一遍。

• 模型名和别名要分开记，别名指向会变，模型名相对稳定
• 入口写清楚是中转还是直连，中转站自己也可能跟着调
• 量级记录按周算就够，不用精确到天
• 缓存前缀单独标一列，它直接决定实际账单涨幅
• 批处理任务单独列，这类任务对延迟不敏感，迁移成本最低

计费口径变了没有：三步核对法

听到「价格调整」，最容易被带偏的就是口径。公告说的单位和你账单上的单位可能不是一回事，直接比大小会得出完全错误的结论。按顺序走三步，别跳。

判断标准：名义单价变化不等于账单变化。用最近一周的真实用量重算一遍才算数；没有用量记录的话，先补记录再谈判断，否则你只是在猜。要对照各家官方口径，可以到 /price-watch 看当时的数字和追踪记录。

什么时候该动配置，什么时候什么都不用做

很多人一听到调整就开始改配置，改完发现根本没受影响，还引入了新问题。动手之前先过一遍该动和不必动的清单，能省掉大半无效工作。

• 该动：模型别名指向变了，导致输出格式异常
• 该动：计费层涨幅超过你的预算容忍线
• 该动：限制层收紧后频繁触发限速，重试也压不住
• 不必动：只是宣传口径调整，接口行为没变
• 不必动：单价微调，但这一项在你账单里占比很小
• 不必动：你本来就用兼容多种入口的调用方式，换入口不费劲

折中做法是保留原入口，同时配一个备用通道做小流量拨测，确认稳定再整体切。提醒一句：切换前把「切回去要多久」写下来，没有回滚方案的迁移不算避坑。备用入口靠不靠谱，可以到 /tools/speed-test 做一轮实测再决定，别只看宣传页。