site logo

Marico's space

site logo

Marico's space

首页
我的日志
我的游记
世界·视野
编程技术

技术合作:

look@marico.cc

+86 18660050334

 

Claude Opus 4.8 Fast Mode 即将停用：安全迁移实战手册

AI技术与应用 2026-11-02 20:55:44 5

最近折腾 Claude Opus 4.8 Fast Mode 的下线迁移，顺手踩了几个坑：只看模型名根本找不全调用链，改完模型 ID 也不等于迁移完成。这篇把兼容、延迟、容量和成本回归一次性讲清楚，给出一套能直接落地的迁移方案。

首发于 NoorYasser.com。本 DEV（开发者社区）版本面向正在规划迁移的工程师做了适配。

Anthropic 将于 2026 年 11 月 30 日移除 Claude Opus 4.8 的 Fast Mode。在该日期之后，同时使用模型 ID claude-opus-4-8 和 speed: "fast" 的请求将返回错误。

这次下线的是功能，不是 Opus 4.8 模型本身。Anthropic 的生命周期页面仍将 Claude Opus 4.8 标记为活跃状态，模型最早也要到 2027 年 5 月 28 日才会退役。

实际处理不能只改一行模型名称。如果某条生产链路依赖 Opus 4.8 Fast Mode，就应该把迁移到 Claude Opus 5.5 这件事拆成兼容性测试、离线评估和可观测的灰度发布三个阶段。同时，要记录每次请求实际使用的推理模式，不能只看配置里申请了什么速度。

关键时间点与影响范围

问题 官方明确答案 工程影响
11 月 30 日停止的是什么？ Claude Opus 4.8 的 Fast Mode 删除所有 4.8 链路中的 speed: "fast"，或者完成迁移
Opus 4.8 本身会同时退役吗？ 不会，仍被列为活跃状态 不要把标准速度的 4.8 流量误判为 11 月故障
推荐的 Fast Mode 目标 Claude Opus 5.5 切换流量前验证请求与响应契约
Opus 5.5 还需要旧的 Beta 请求头吗？ 不需要 链路迁移后移除旧请求头注入
如何确认真实服务模式？ 读取 usage.speed 监控实际模式，而不只是申请意图
达到 Fast Mode 容量上限会怎样？ 返回 429 或 529；429 可能包含 retry-after 使用有上限的重试，或者有意识地降级到标准速度

下文的日期、支持模型、请求字段、价格、限流行为和 Opus 5.5 兼容性变化，均来自 Anthropic 官方文档，最后核对时间为 2026 年 11 月 1 日。资产盘点、评估、灰度和降级方案则是工程侧建议。

1. 找出所有受影响的请求链路

只在应用代码里搜索一个模型 ID 远远不够。Fast Mode 可能由 SDK（软件开发工具包）封装层、网关策略、环境变量、托管 Agent 模型对象、功能开关或者请求模板注入。

至少要盘点下面这些位置：

  • 直接调用 Messages API（应用程序接口），请求体中同时包含 model: "claude-opus-4-8" 和 speed: "fast"
  • 使用相同模型和速度配置的托管 Agent 定义
  • 会附加 fast-mode-2026-02-01 Beta 请求头的共享客户端
  • opus-fast、premium-low-latency 等内部别名
  • 只有超时或容量错误后才会触发的降级分支
  • 定时任务和低频管理流程
  • 按旧模型或 Beta 功能分组的看板、告警和预算
  • 只验证 HTTP 请求成功，没有验证响应契约的测试

一份内部资产记录可以简单到这样：

{ "route": "support-escalation-agent", "model": "claude-opus-4-8", "requested_speed": "fast", "beta_header": "fast-mode-2026-02-01", "effort": "high", "tool_choice": "required", "fallback": "opus-4-8-standard", "owner": "support-platform"
}
Enter fullscreen mode Exit fullscreen mode

这不是 Anthropic API Schema，而是一份归属与风险记录。它应该在流量切换前，把隐藏的兼容性工作暴露出来。

2. 把 Opus 5.5 当成一次契约迁移

Anthropic 的迁移指南记录了多项差异。即使提示词完全不变，这些差异也可能影响应用行为。

Thinking 与 Effort

在 Opus 4.8 上，请求省略 thinking 字段时，Thinking 默认关闭；在 Opus 5.5 上，即使省略该字段，Thinking 仍会运行。Anthropic 还记录了默认 effort 的变化：Opus 4.8 默认是 high，Opus 5.5 默认是 medium。

别让默认值在暗中决定迁移结果。要为每类经过评估的工作负载显式设置 effort，解析兼容 Thinking 的响应，并同时比较质量和 Token（模型处理文本的基本单位）用量。

工具契约

Opus 5.5 文档列出了几项破坏性变化，涉及强制工具调用、模型关联的 Thinking Block，以及更早版本的 computer-use 工具。如果 Agent 强制调用工具、回放包含 Thinking Block 的对话，或者使用 computer_20251124，就必须把这些链路纳入兼容性测试。一个纯文本提示词调用成功，不能证明 Agent 工作流已经兼容。

Prompt Caching 与 Priority Tier

Opus 5.5 可缓存 Prompt 的最低长度是 512 个 Token，而 Opus 4.8 是 1,024 个 Token。即使应用代码没有任何变化，这也会改变缓存创建方式和成本结构。

Anthropic 同时说明，Opus 5.5 不支持 Priority Tier。Fast Mode 和 Priority Tier 是两种不同的容量产品，不能默认其中一个可以替代另一个。

3. 正确测量延迟

Anthropic 对 Fast Mode 的描述，是同一个模型使用更快的推理配置运行，最高可提供 2.5 倍的每秒输出 Token 数。这是供应商对输出吞吐量的描述，不是首 Token 延迟。

延迟需要拆开看：

end_to_end = queue_wait + request_setup + TTFT + generation + tool_time + post_processing
generation = output_tokens / observed_OTPS
Enter fullscreen mode Exit fullscreen mode

其中，TTFT（首 Token 时间）指首 Token 延迟，OTPS（每秒输出 Token 数）指每秒输出 Token 数。

如果排队等待或工具调用占据了主要延迟，输出吞吐量再高，用户体验也可能几乎不变。较长的流式响应则可能受益，即使 TTFT 没有明显改善。

以下指标都要报告 p50 和 p95：

  • 首 Token 时间
  • 每秒输出 Token 数
  • 端到端延迟
  • 工具执行时间
  • 重试与降级带来的延迟

Anthropic 当前价格页显示，Opus 5.5 Fast Mode 的输入 Token 单价为每百万 Token 8 美元，输出 Token 单价为每百万 Token 40 美元。Opus 4.8 Fast Mode 对应的价格则是每百万 Token 10 美元和 50 美元。这些只是供应商价格，不代表你的实际账单。Prompt Caching 和数据驻留区域的倍率可能与 Fast Mode 价格叠加，因此必须根据真实用量记录计算成本。

4. 灰度前先冻结评估契约

建立一套经过隐私审查的评估集，覆盖每条受影响的请求链路。样本要包含短答案、长文本流式生成、连续工具调用、拒绝回答、可缓存 Prompt 和峰值上下文请求。

至少要评估以下指标：

  • 任务正确性和指令遵循能力
  • 工具选择、参数有效性和完成率
  • 响应解析器兼容性
  • Thinking Block 和停止原因处理
  • TTFT、输出吞吐量以及端到端 p50/p95
  • 输入、缓存输入和输出 Token 数
  • usage.speed 分布
  • 429、529 和其他错误率
  • 重试放大效应与标准速度降级率
  • 每个成功任务的成本，而不是每次原始请求的成本

两条链路必须使用相同的提示词、工具、种子数据和评分规则。拿繁忙的 Opus 4.8 生产链路，跟负载很轻的 Opus 5.5 开发请求做对比，根本无法隔离模型或服务模式带来的差异。

5. 明确降级行为

一个安全的路由器需要区分四件事：

  1. 产品策略申请的模型
  2. 请求链路申请的速度
  3. usage.speed 返回的实际速度
  4. 真正提供响应的降级链路

简化后的策略可以这样写：

if route_flag == "opus-5-5-fast": call Opus 5.5 with speed="fast" verify usage.speed
elif route_flag == "opus-5-5-standard": call Opus 5.5 without fast mode
else: keep the approved legacy route during the canary
Enter fullscreen mode Exit fullscreen mode

遇到 429 时，应遵守 retry-after，并在有上限的延迟预算内重试。遇到 529 或重试预算耗尽时，只有产品契约允许，才可以降级到标准速度。同时记录降级原因和最终服务模式。

不要为了把错误变成 HTTP 200，就悄悄切换到另一个模型。模型变化可能直接影响质量、安全性、工具行为和成本。

6. 分阶段受控发布

一套实用的执行顺序如下：

  1. 盘点所有链路、负责人、请求头、别名和降级策略。
  2. 兼容性测试请求与响应契约、工具流程和解析器。
  3. 离线评估质量、延迟组成、Token 用量和成本。
  4. 影子测试或流量回放处理经过隐私保护的流量，不影响真实用户。
  5. 灰度发布通过功能开关向一小部分具有代表性的流量开放新链路。
  6. 按链路扩大范围只有错误率、质量、延迟和成本门槛全部通过后再执行。
  7. 删除旧链路并在 11 月 30 日前移除旧 Beta 请求头。

回滚范围一定要小：只切换一个链路开关，保留请求证据，回到最近一次验证过的配置。如果回滚时还同时修改提示词、工具、缓存边界和重试规则，那已经是第二次迁移，而不是故障控制。

最佳实践

  • 固定模型版本，并显式设置 effort。
  • 分别记录申请速度和 usage.speed。
  • 把 429 和 529 当作容量信号，而不是模型故障的证据。
  • 在截止日期前，对任何仍然存在的 Opus 4.8 Fast 请求触发告警。
  • 计算每个成功任务的成本。
  • 为每条降级链路定义经过产品批准的延迟与质量契约。
  • 切换完成后，删除过时请求头、别名、看板和运维手册中的旧步骤。

常见反模式

  • 只修改模型字符串
  • 假设 Fast Mode 能改善首 Token 延迟
  • 把 Opus 4.8 模型退役和 Fast Mode 下线当成同一件事
  • 只比较平均延迟，忽略尾部延迟
  • 根据配置推断服务模式，而不是读取 usage.speed
  • 无限期保留一个从未测试过的标准速度降级链路
  • HTTP 状态码返回 200 就宣布迁移成功，却不检查工具完成率或输出质量是否回归

上线前检查清单

11 月 30 日之前，确认以下事项：

  • 生产环境中不再有请求同时使用 claude-opus-4-8 和 speed: "fast"
  • Opus 5.5 的请求、响应、Thinking 和工具契约全部通过测试
  • 在代表性样本上通过质量、延迟、Token 用量和成本门槛
  • usage.speed 已经可以在遥测数据中看到
  • 429 和 529 的处理有明确上限，而且可观测
  • 标准速度降级是经过明确选择并完成测试的
  • 旧 Beta 请求头和内部别名已经删除
  • 回滚方案和链路归属已经记录在文档中

官方资料

  • Claude Platform 发布说明
  • Anthropic Fast Mode 文档
  • Claude Opus 5.5 迁移指南
  • Anthropic 速率限制
  • Anthropic 价格说明
  • Anthropic 模型退役计划

完整版本、相关架构说明和原始发布背景，可阅读《Claude Opus 4.8 Fast Mode 即将停用：在不引入延迟回归的情况下完成迁移》。