生命周期指南
了解我们的模型弃用流程所需掌握的信息
弃用流程
1. 公告
- 向近期在受影响模型上有推理流量的所有账户发送电子邮件通知。
- 在弃用历史记录页面添加一条带日期的条目，列出受影响的模型 ID、下线日期以及推荐的替代模型。
2. 过渡期 — 7 天
- 自公告之日起，受影响模型将正常处理请求 7 天。
- 替代模型可在 Model Studio 中通过 API 使用，以便进行并行测试。
- 在整个过渡期内，支持团队将协助选择替代模型并进行集成变更。
3. 生命周期结束
- 到达下线时间后，受影响模型将停止处理流量，且不再可访问。
- 向已退役模型 ID 发送的请求将返回错误。系统不会将请求回退路由到其他模型，也不会将旧 ID 重定向到其替代模型（如果应用程序没有自己的回退路径，将会失败）。请在此日期前完成迁移。
通知期
| 模型类型 | 下线前通知期 |
|---|---|
| Model Studio 中的 Serverless 模型 | 7 天 |
如果模型被上游提供商撤回、许可证变更导致我们失去托管权利，或存在需要立即处理的安全或合规问题，通知期可能会缩短。
建议的迁移步骤
- 在弃用历史页面中找到你当前使用的模型，并记录其推荐的替代模型及停用日期。
- 审计你的使用情况，识别出所有引用受影响模型 ID 的服务、智能体、批处理任务和已保存的配置。
- 根据你的工作负载评估推荐的替代模型。推荐是基于能力层级和模型谱系，而非你的具体流量情况。如果成本或延迟是你的主要约束条件，当前目录中的其他模型可能更适合你。
- 针对具有代表性的生产流量进行 A/B 测试。替代模型的行为很少完全一致，因此在全面切换之前，请验证输出质量、令牌消耗和延迟。
- 更新你的 API 调用并逐步推出。先切换一小部分流量，然后逐渐增加，最后切换全部。在切换完成之前，请保持旧的备用路径可用。
- 在切换期间及切换后的一段时间内，密切关注错误、延迟和成本。
最佳实践
- 将模型 ID 放在配置中，而不是代码中，这样未来的变更只需更新配置，而无需发布新版本。
- 在生产请求处理中构建备用模型路径。
- 在每个停用日期之前，检查弃用历史页面以及你的电子邮件通知。
- 自行保留提示词、评估集和必要配置的副本，而不是依赖平台侧的存储。
- 尽可能围绕模型接口而非特定模型进行设计，以便在替换时能以最小的改动进行切换。
当替代模型不是直接替换时
有些替代方案需要的不仅仅是更改模型 ID，有些功能在替代后可能没有等效选项。嵌入模型是前一种情况的最常见例子：由于不同模型之间的嵌入向量不可互换，任何更改都需要在查询流量切换之前重新嵌入你的语料库，这通常需要比过渡窗口允许的更长的准备时间。如果你的工作负载属于上述任一情况，请尽早联系我们，以便我们讨论可选方案。
获取帮助
如果你需要帮助选择替代模型或测试你的集成，请联系我们的支持团队。