中/EN
实战 SOP
实战 SOP

模型下线迁移止血 SOP：4 步把涨价、替换与下线三类变更的账算清

2026 年 8 月 31 日集中发生三件事：Sonnet 5 的 API 费率从 2 与 10 美元恢复到 3 与 15 美元、GPT-5.4 与 GPT-5.4 mini 对 ChatGPT 登录的 Codex 用户停止提供、kimi-k2.5 与 moonshot-v1 同日下线。这三类变更的处理方式完全不同，但很多团队用同一套动作应对，结果要么过度反应要么反应不足。这篇给一套四步流程：第 0 步先分类，用公告里的关键词判断是下线（sunset / deprecated，当天必须处理）、替换（replace / default 变更，本周内，不报错但模型变了，需回归）还是涨价（只写 pricing，本月内，业务不中断但要重算成本）；第 1 步依赖盘点，用一条 grep 把散落在各处的模型 ID 全扫出来，收敛到集中配置并接进 CI；第 2 步按类型执行迁移动作；第 3 步用分词放大系数、峰谷时段占比、缓存命中率三个系数重算月度成本。另附 11 条可复制检查清单、第 4 步的限额与告警与降级路径配置，以及七个踩坑点——最常见的一条是模型 ID 散落在代码里，改一处漏三处。

发布于 2026年8月31日12 分钟阅读
<!-- model-sunset-migration-cost-sop | sop | 模型下线迁移止血 SOP：4 步把涨价、替换与下线三类变更的账算清 -->

2026 年 8 月 31 日集中发生了三件事：Claude Sonnet 5 的 API 费率从 2 与 10 美元恢复到 3 与 15 美元，GPT-5.4 与 GPT-5.4 mini 对 ChatGPT 登录的 Codex 用户停止提供，月之暗面的 kimi-k2.5 与 moonshot-v1 同日下线。这三类变更的处理方式完全不同，但很多团队用同一套动作去应对，结果是要么过度反应，要么反应不足。这篇给一套四步流程：先分类，再盘点，再迁移，最后重算计量与加监控。

先说边界：本文事实基于 aitoolsrecap 2026-08-31 当日汇总、腾讯 AI 日报 2026-08-31 条目、TheRouter.ai 于 2026-08-24 检索的各平台定价与弃用公告，以及一份逐页复核官方定价页的速查表（2026-08-24 复核、8-28 再复核）。价格为 2026-08-31 快照，随时可能变动，执行前请以自己账户所在区域的官方定价页与官方公告为准。文中的命令与配置示例为通用做法示意，需按你的技术栈调整。涉及具体模型 ID 的迁移目标，请以厂商公告为准，本文不给未经核实的替代建议。

一、第 0 步：先分清你遇到的是哪一类变更

这一步最容易被跳过，但它决定了后面所有动作的优先级。三类变更的紧迫性完全不同。

类型表现紧迫性不处理的后果
下线（sunset）旧模型 ID 停止响应立即，当天调用直接失败，业务中断
替换（replacement）入口还在，模型被换掉本周内输出风格与能力变化，需回归
涨价（repricing）ID 不变，单价变化本月内成本上升，不中断

今天的三个事件刚好对应三类：kimi-k2.5 与 moonshot-v1 是下线，必须当天处理；GPT-5.4 退出 Codex 是替换，你的调用不会报错，但拿到的模型变了，需要回归测试；Sonnet 5 恢复标准价是涨价，业务不中断，但要重算成本。

把它们混为一谈会造成两种浪费：把涨价当成下线，会触发不必要的紧急迁移；把下线当成涨价，则会等到线上报错才动手。判断方法很简单，去厂商公告里找两个词——写 sunset 或 deprecated 的是下线，写 replace 或 default 变更的是替换，只写 pricing 的是涨价。

二、第 1 步：依赖盘点，把模型 ID 从代码里捞出来

绝大多数团队在第一次遇到下线时才会发现，自己根本说不清用了多少个模型 ID、分布在哪几个服务里。先把这件事做完。

第一步是全库扫描。 在项目根目录执行一条递归搜索，把常见的模型名前缀都匹配一遍，排除依赖目录：

bash
grep -rnE "(gpt-|claude-|kimi-|moonshot|qwen|deepseek|glm-|doubao|gemini|grok|mimo)" \
  --include="*.ts" --include="*.tsx" --include="*.py" --include="*.js" \
  --include="*.json" --include="*.yaml" --include="*.yml" --include="*.env*" . \
  | grep -v node_modules | grep -v ".next" > model-inventory.txt

别只搜源码。模型 ID 经常藏在三个容易被忽略的地方：环境变量文件里的默认模型、配置文件里的 fallback 链、以及数据库或缓存里存的历史会话记录。最后这一类最麻烦，因为它们是运行时数据，改代码不会自动生效，需要写迁移脚本。

第二步是建一张登记表，并给它加上到期日字段。 建议把散落的字符串收敛到一处配置，形如：

ts
export const MODELS = {
  chat: {
    id: 'kimi-k3',
    provider: 'moonshot',
    sunset: null,
    migratedFrom: 'kimi-k2.5',
    note: '2026-08-31 由 k2.5 迁移，定价以账户所在区域官方页为准',
  },
  reason: {
    id: 'deepseek-v4-pro',
    provider: 'deepseek',
    sunset: '2026-10-24',
    migratedFrom: 'deepseek-reasoner',
    note: '峰谷计价：工作日 9-12 与 14-18 为高峰，闲时减半',
  },
  cheap: {
    id: 'gpt-5.6-luna',
    provider: 'openai',
    sunset: null,
    migratedFrom: null,
    note: '高吞吐简单任务分流用，永久价 0.20 / 1.20 美元',
  },
} as const

这个结构的价值不在优雅，而在于把"到期日"变成了一个显式字段。有了它，下次公告来临时你要改的是一行配置，而不是翻遍整个代码库去找散落的字符串。顺带提醒：把这张表接进 CI，写一条检查规则，凡是引用了已过 sunset 日期的模型 ID 就直接让构建失败，比任何文档提醒都管用。

三、第 2 步：迁移，三类变更各自的切换动作

下线类：立即切，且要验证。 今天下线的 kimi-k2.5 与 moonshot-v1，迁移目标是 kimi-k3。切换动作本身只是改一个 ID，但有两件事要做在前面：一是确认新 ID 在你账户所在区域的定价，不同来源给出的 kimi-k3 数字差异不小（有按美元报 3 与 15 的，也有按人民币报 20 与 100 的），别拿别人的账单当自己的预算；二是跑一轮回归，因为模型换了，输出分布一定变，凡是 downstream 有解析逻辑的地方都要重测。

替换类：两条路，选一条。 GPT-5.4 离开 Codex 影响的是用 ChatGPT 账号登录的那批用户，被 GPT-5.6 Terra（2 与 12 美元）与 Luna（0.20 与 1.20 美元）取代。你有两个选择：接受新模型并跑回归，或者改用 API key 认证以继续用原模型。前者省事但要承担行为变化，后者稳定但要把 key 管理纳入你的密钥体系。判断依据是这两个模型在你的核心任务上差异有多大，测一轮就知道，别靠猜。

提前排期类：把已知的到期日一次性排进去。 已经公告的还有一串：9 月 14 日 Claude Code 永久周限额生效、10 月 10 日 DashScope 一轮 sunset 退役 30 多个旧模型 ID（含 qwen-turbo、qwen-vl-plus、qwen-audio-turbo 与若干早期 Qwen3 快照）、10 月 24 日 deepseek-chat 与 deepseek-reasoner 弃用、11 月 12 日 OpenAI 模型离开 Cursor、约 11 月 21 日 GPT-5.6 Sol 促销价结束（4 与 20 回到 5 与 30）。这些都应该现在就进排期，而不是等到公告周。

四、第 3 步：计量重算，三个系数决定你的真实账单

迁移完成后，成本账单和迁移前不可直接比较，因为计量口径可能变了。有三个系数必须重算。

系数一：分词放大。 Sonnet 5 换了分词器，相同输入映射的 token 数变成原来的 1.0 到 1.35 倍，具体倍数随内容类型浮动。官方没有给细分，所以最可靠的办法是拿自己的真实语料，用新旧分词器各数一次，得到自己的实际系数。这件事成本极低，但比任何估算都准。

系数二：峰谷时段。 DeepSeek 自 8 月 17 日起峰谷计价，工作日 9:00–12:00 与 14:00–18:00 是高峰价，闲时减半，周末全天按闲时计。可异步的工作负载应尽量调度到闲时，这是一倍价差，且不需要任何技术改动。注意别用过期的旧价做预算：8 月 13 日发布时记的是未命中输入 3 元、输出 6 元，峰谷改革后高峰已变为 9 元与 27 元。

系数三：缓存命中率。 各平台对命中前缀缓存的输入 token 给远低于标准的单价，部分模型的缓存命中价只有标准输入价的几十分之一。这一层变量在你手里：把稳定的系统提示放在最前面、让多轮对话复用历史前缀，命中率就能上去。建议在日志里单独记一个缓存命中 token 数，否则你永远不知道自己吃了多少折扣。

把三个系数合进一个公式，得到可复用的月度成本估算：

text
月度成本 ≈ 输入 token × 放大系数 × 输入单价 × (1 − 缓存命中率)
        + 输入 token × 放大系数 × 缓存单价 × 缓存命中率
        + 输出 token × 输出单价

需要提醒的是，输入与输出的比重会显著改变结论：输出单价通常是输入的三到五倍，凡是按"各占一半"做过粗估的预算，今天起都应按真实比重重算。具体的折算示例与排序变化，见本批横评篇 /zh/posts/post-aug31-token-cost-comparison-review。

五、第 4 步：监控与止血，限额、告警、降级

限额变化要提前知道。 Anthropic 已公告 9 月 14 日起永久上调 Claude Code 每周限额 25%，当前的 50% 临时扩容保持到 9 月 13 日。把三个时点指数化后是：5 月前基线 100，现在 150，9 月 14 日起 125。也就是说相对旧标准涨 25%，相对你现在正在用的水平降 17%。如果你依赖 Claude Code 的周额度做重度开发，9 月 13 日之前仍是扩容期，之后可用容量会低于现在，工作排期要按新的量排。

告警要按模型分账。 建议至少设三条：单模型日成本超过预算阈值的告警、单模型 token 量环比突增的告警、以及缓存命中率跌破预期的告警。第三条最容易被忽略，但缓存命中率下跌往往意味着有人改了提示词结构，成本会在你不知情的情况下悄悄翻倍。

降级路径要预先铺好。 最省钱的模型不是挑出来的，是分流出来的。以每百万 token 输入 0.20 美元、输出 1.20 美元的 GPT-5.6 Luna 为例，它的综合单价是 0.7 美元，约为 Sonnet 5 的十三分之一。把分类、抽取、格式化、路由这类高吞吐简单任务从旗舰模型摘下来放上去，通常比换一家供应商省得多，而且不影响核心环节的质量。

六、一份可复制的检查清单

按执行顺序排，可以直接抄走：

  1. 全库扫描模型 ID，含环境变量、配置文件与运行时数据，产出登记表
  2. 给每个 ID 标注类型（在用 / 已弃用 / 待迁移）与到期日
  3. 把 ID 收敛到一处配置，接进 CI 做过期检查
  4. 下线类：今天切换，切前确认新 ID 在自己区域的定价，切后跑回归
  5. 替换类：二选一（接受新模型跑回归，或改走 API key 保原模型）
  6. 已知到期日：9-14、10-10、10-24、11-12、11-21 一次性进排期
  7. 用真实语料测出分词放大系数
  8. 可异步任务调度到闲时
  9. 日志加缓存命中 token 计数，设命中率告警
  10. 按模型分账，设日成本与突增告警
  11. 给简单任务铺一条到廉价模型的降级路径

七、七个踩坑点

只看标价不看分词。 这是本次最容易踩的一坑。Sonnet 5 费率涨 50%，但代码负载叠上分词变更后实际涨幅在 65% 到 100% 之间。你的账单涨了多少，跟你输入的是什么内容直接相关。

把促销价当永久价建模。 GPT-5.6 Sol 的 4 与 20 美元是促销，约 11 月 21 日后回到 5 与 30，综合单价从 12 跳到 17.5。任何需要工程投入的迁移，都应该按到期后的价格算回报，三个月的差价通常覆盖不了迁移成本。

模型 ID 散落在代码里。 改一处漏三处，是迁移事故最常见的直接原因。集中配置加 CI 检查能一次性解决。

忽略输入输出比重。 输出单价是输入的三到五倍，用 1:1 估算的预算与实际可能差很远。

不监控缓存命中率。 命中率是个沉默变量，掉了不会报错，只会在月底账单上体现。

订阅额度与 API 混算。 这次 Sonnet 5 的定价变化只影响 API，Consumer 订阅不受影响。两类成本的口径不同，别放在一张表上比。

没有降级路径。 等到要省钱的时候才发现没有廉价模型可切，就只能全量降级或硬扛成本。降级路径应该在成本健康的时候铺好。

最后说一句关于节奏的话。这一轮变更看着密集，拆开看每一件其实都给了提前量：Sonnet 5 的标准价在两个月前发布时就写在定价说明里，Claude Code 的限额调整提前了半个月公告，DashScope 的十月退役更是留了六周窗口。真正让人措手不及的从来不是公告本身，而是没有把模型 ID 当成会过期的依赖来管理。把第 1 步那张登记表建起来、接进 CI，往后每一次公告对你来说，就只是改一行配置的事。

常见问题

Q1：模型 ID 散落在几十个文件里，怎么一次性捞干净？ A1：先用一条 grep 把候选全扫出来，再人工确认。命令：grep -rnE "(gpt-|claude-|kimi-|moonshot|qwen|deepseek|glm-|doubao|gemini|grok|mimo)" --include="*.ts" --include="*.py" --include="*.json" --include="*.yaml" .。扫出来之后不是逐个改，而是收敛到一处集中配置（见第 1 步的 MODELS 示例），再让业务代码只引用常量。改完之后把这条 grep 接进 CI，作为一条会失败的检查——这样下次有新 ID 硬编码进代码，CI 会拦住它。

Q2：迁移到新模型后，提示词要不要重新调？ A2：要，但要分清轻重。同一厂商同系列的换代（比如 kimi-k2.5 到 kimi-k3）通常不需要重写提示词，只需回归测试；跨厂商迁移（比如 DeepSeek 换 GLM）就必须重跑一遍提示词与工具调用 schema 的回归。最容易被忽略的是分词差异——同样的提示词在不同 tokenizer 下 token 数不同，直接影响成本与上下文占用，这一点在迁移前后各测一次就能量化。

Q3：怎么估算迁移后的账单变化，避免上线才发现超预算？ A3：按第 3 步的公式算三个系数：分词放大系数（同一批样本在新旧 tokenizer 下各测一次取比值）、峰谷时段占比（异步负载能调度到闲时的比例）、缓存命中率（生产流量上实测）。月度成本约等于输入 token 乘以放大系数再乘以输入单价乘以（1 减缓存命中率），加上缓存部分的成本，再加上输出 token 乘以输出单价。三个系数里任何一个用默认值而非实测值，估算就会偏。

Q4：缓存命中率掉了怎么发现？ A4：它不会报错，只会在月底账单上体现，所以必须主动监控。做法是把每次调用的缓存读写 token 数打到日志，按小时聚合算命中率，然后设一条阈值告警（比如低于基线 20 个百分点就告警）。最常见的掉命中原因不是模型侧问题，而是有人往提示词前缀里塞了时间戳、请求 ID 或随机顺序的检索片段——把前缀污染了。

Q5：降级路径怎么设计才算合格？ A5：三个条件。第一，廉价备选模型要在成本健康的时候就接入并通过回归，不能等到要省钱时才第一次调。第二，切换开关必须是配置级别的一行改动，而不是改代码再发版。第三，降级后的输出质量要有可接受的下限——如果降级会导致功能不可用，那它不是降级路径，是故障路径。本次 Sonnet 5 只影响 API、订阅不受影响，正好说明两类额度的降级策略也要分开设计。

本文由 AI 辅助生成，经人工审核编辑。最后更新：2026-08-31

常见问题

模型 ID 散落在几十个文件里，怎么一次性捞干净？
先用一条 grep 把候选全扫出来再人工确认：grep -rnE "(gpt-|claude-|kimi-|moonshot|qwen|deepseek|glm-|doubao|gemini|grok|mimo)"，配合 --include 限定文件类型。扫出来之后不是逐个改，而是收敛到一处集中配置，再让业务代码只引用常量。改完之后把这条 grep 接进 CI 作为一条会失败的检查，这样下次有新 ID 硬编码进代码，CI 会拦住它。
迁移到新模型后，提示词要不要重新调？
要，但要分清轻重。同一厂商同系列的换代（比如 kimi-k2.5 到 kimi-k3）通常不需要重写提示词，只需回归测试；跨厂商迁移（比如 DeepSeek 换 GLM）就必须重跑一遍提示词与工具调用 schema 的回归。最容易被忽略的是分词差异——同样的提示词在不同 tokenizer 下 token 数不同，直接影响成本与上下文占用，迁移前后各测一次就能量化。
怎么估算迁移后的账单变化，避免上线才发现超预算？
按三个系数算：分词放大系数（同一批样本在新旧 tokenizer 下各测一次取比值）、峰谷时段占比（异步负载能调度到闲时的比例）、缓存命中率（生产流量上实测）。月度成本约等于输入 token 乘以放大系数再乘以输入单价乘以（1 减缓存命中率），加上缓存部分的成本，再加上输出 token 乘以输出单价。三个系数里任何一个用默认值而非实测值，估算就会偏。
缓存命中率掉了怎么发现？
它不会报错，只会在月底账单上体现，所以必须主动监控。做法是把每次调用的缓存读写 token 数打到日志，按小时聚合算命中率，再设一条阈值告警（比如低于基线 20 个百分点就告警）。最常见的掉命中原因不是模型侧问题，而是有人往提示词前缀里塞了时间戳、请求 ID 或随机顺序的检索片段，把前缀污染了。
降级路径怎么设计才算合格？
三个条件。第一，廉价备选模型要在成本健康的时候就接入并通过回归，不能等到要省钱时才第一次调。第二，切换开关必须是配置级别的一行改动，而不是改代码再发版。第三，降级后的输出质量要有可接受的下限——如果降级会导致功能不可用，那它不是降级路径，是故障路径。本次 Sonnet 5 只影响 API、订阅不受影响，正好说明两类额度的降级策略也要分开设计。

相关文章

实战 SOP

用 GPT-6 Astra 搭建长任务智能体工作流

基于 GPT-6 Astra 真实能力（105 万上下文、12.8 万输出、对齐越权 0%）搭建长任务智能体的实战 SOP：先完成三项准备（OpenAI Python SDK 1.50+、OPENAI_API_KEY 环境变量、API 白名单），再按长上下文规划→定义工具（函数调用 + 计算机使用）→异步调用模式→中途纠偏→验收与成本控制的顺序落地。重点：开局只放任务目标、验收标准、工具清单与关键背景让模型先出计划；工具须写清 name/description/parameters；异步用流式事件 + 后台队列 + 任务 id 轮询；纠偏直接注入新指令无需重启；验收用独立脚本做断言、默认收小 max_output_tokens 并设日花费上限。

2026年9月4日11 分钟阅读
实战 SOP

Claude Fable 5.1 API 破坏性变更迁移 SOP

2026-09-01 Fable 5.1 发布列了三条破坏性 API 变更，任何一条都可能在切模型时直接 400 或静默退化。① tool_choice=any/tool 返回 400，改用 auto + strict tool use/structured outputs；②思考块模型绑定单向兼容——Fable 5.1 能读旧模型的 thinking block，旧模型读不了新的，降级时丢失推理链；③编辑历史轮次使思考块失效，对 2026-08-31 及之后创建的账号强制报错。本文给出升级前三步自查、逐条迁移代码、迁移后回归验证（并行调用分布、thinking 连续性、20+ 轮压测、水印/C2PA 下游兼容）、灰度降级与回滚，以及八条避坑（含整文件重写倾向、低 effort 凭记忆作答、改写历史击穿缓存）。beta 能力 turn-scoped system messages 与 context-editing 为解药，header 确切名称以官方文档为准。

2026年9月1日10 分钟阅读
实战 SOP

Qwen3.8-Flash-Next 全栈部署 SOP：125B 主模型 + 51B N-gram 嵌入，从托管 API 到 Apple Silicon 的三层路线

把 Qwen3.8-Flash-Next 从「能跑起来」推到「跑得省」的三层路线。托管层零运维：QwenCloud API 兼容 OpenAI 与 Anthropic 规范，QwenWork 的 Standard 模式由它驱动。服务化自部署给四条逐字出自官方 README 的命令：transformers serve（--continuous-batching）、SGLang（--tp-size 4 --context-length 262144 --reasoning-parser qwen3 --tool-call-parser qwen3_coder）、vLLM（--tensor-parallel-size 4 --max-model-len 262144 --enable-auto-tool-choice）与 TokenSpeed，四者都在 localhost:8000/v1 提供 OpenAI 兼容 API。本地与端侧另有 llama.cpp 的 GGUF、Apple Silicon 的 mlx-vlm 与 Unsloth。工程上最值得记的一点是额外那 51B N-gram embeddings 可以卸载到主机内存，靠异步预取与模型计算重叠——README 未给官方显存基线，故不猜硬件门槛，标注以官方 recipe 与实测为准。含 YaRN 外推 1M 的取舍、微调框架选择（Unsloth / Swift / Llama-Factory）与 7 条踩坑，其中第一条就是：GitHub 仓库无 LICENSE 文件，商用前先去模型页核对协议。

2026年8月30日12 分钟阅读