Azure OpenAI与Foundry 2026年11月退役清单：o1、Claude Haiku 4.5等模型迁移指南

微软Azure OpenAI与Foundry服务即将在2026年11月迎来一轮集中退役，涉及o1、o1-pro、codex-mini、Claude Haiku 4.5等多个模型。对于依赖这些模型构建生产应用的团队来说，这不仅仅是一次版本更新，更是一次需要提前规划的架构迁移。

退役时间表：三波集中下线

根据微软官方公告，退役将分三个时间点进行，每个时间点对应的模型类别和影响范围各有不同。

11月15日：codex-mini与Claude Haiku 4.5率先退役

第一波退役发生在11月15日，涉及codex-mini和Claude Haiku 4.5两个模型。codex-mini是面向代码生成场景的轻量模型，而Claude Haiku 4.5则是Anthropic在Azure平台上提供的快速响应模型。两者同时退役，意味着同时依赖代码补全和低延迟对话的团队需要在这一天之前完成切换。

有意思的是，Claude Haiku 4.5的退役说明Azure上的第三方模型同样遵循生命周期管理规则，并非只有OpenAI自家模型会被淘汰。

11月17日：两个gpt-chat-latest预览版下线

第二波在11月17日，两个gpt-chat-latest预览版模型将退役。预览版模型本身定位就是临时性、实验性的，微软通常会为预览版设定较短的存活周期。如果生产环境仍在调用带preview标识的端点，需要优先排查。

11月19日：o系列大规模退役

第三波也是影响最大的一波，11月19日o1、o1-pro以及另外五个o系列模型将集中退役。o1系列是OpenAI推理模型的核心产品线，o1-pro更是面向高复杂度推理任务的增强版本。一次性退役七个o系列模型，对使用推理模型做Agent、复杂分析或数学推理的应用来说，冲击最为直接。

自动升级规则：不是所有部署都会“被迁移”

微软对模型退役的处理方式并非一刀切。部分部署配置了自动升级（auto-upgrade）规则，会在退役日期后将流量自动导向推荐的替代模型；但另一些部署——尤其是固定版本（pinned version）的部署——不会自动迁移，退役后调用将直接失败。

这意味着团队需要主动检查每个部署的升级策略。如果部署时选择了固定版本以保证输出稳定性，那么这次必须手动指定替代模型并重新部署。自动升级虽然省事，但也可能带来输出行为的变化，需要在测试环境中先行验证。

自动升级（auto-upgrade） 是Azure OpenAI部署配置中的一项生命周期管理选项。当基座模型被标记为退役时，若部署启用了自动升级，平台会在退役生效后将部署自动指向微软推荐的替代模型，无需用户手动重建部署。与之相对的是固定版本（pinned version） 部署，即用户显式锁定模型的具体版本号以确保输出行为稳定，这类部署在模型退役后不会获得任何自动迁移，调用请求会直接返回模型不可用的错误。自动升级虽然降低了运维中断风险，但由于替代模型在训练数据、对齐策略和推理特性上可能不同，输出风格、格式遵循度甚至token消耗都可能发生变化，因此生产环境通常建议先在预发布部署中验证，再决定是否开启自动升级。

替代模型与价格考量

微软为每个退役模型提供了推荐替代方案。o1系列的替代通常指向更新版本的推理模型，codex-mini的替代则可能落在其他代码专用模型上。迁移时不能只看模型名称的对应关系，还要关注三个实际因素：

输入输出价格差异。 不同代际模型的定价结构不同，推理模型尤其如此。o1-pro的高推理成本在替代模型上可能有所变化，需要重新核算单位调用成本。

上下文窗口与输出限制。 替代模型的上下文长度、最大输出token数可能与原模型不一致，影响长文档处理和复杂Agent的提示词设计。

延迟与吞吐特性。 推理模型和快速响应模型的延迟特征差异明显，替换后需要重新评估端到端响应时间是否满足SLA。

Azure OpenAI的模型部署通常与API版本号绑定，调用端点形如/openai/deployments/{deployment-name}/chat/completions?api-version=...。迁移到替代模型时，不仅要替换部署名，还可能需要升级API版本以支持新模型的参数特性（如新的推理参数或结构化输出格式）。此外，部署名与模型名在Azure中是解耦的：一个部署名可以在重建时指向不同的基座模型，这为“保持应用侧标识符不变、只切换后端模型”提供了可能，但前提是团队在应用层没有把模型名硬编码进业务逻辑。

部署变更：迁移的实际操作要点

从工程角度看，这次退役涉及的不只是改一个模型名称。部署变更通常包括：更新模型部署配置、调整API版本号、修改应用中的模型标识符、重新跑一遍回归测试。如果应用使用了模型路由或fallback逻辑，还需要更新路由表中的模型映射。

对于多模型编排的系统，建议把模型标识符集中配置化，而不是散落在代码各处。这样在下次模型生命周期变动时，改动范围可控。

团队应该现在做什么

距离11月还有一段时间，但迁移窗口并不宽裕。建议按以下优先级推进：先盘点所有Azure OpenAI和Foundry部署，标记出使用退役模型的端点；再对照官方替代建议做兼容性测试；最后在测试环境验证输出质量与成本变化后，安排生产切换。对于固定版本的部署，务必在退役日期前完成手动迁移，避免服务中断。

模型退役是云平台AI服务的常态。把模型版本管理纳入日常运维流程，比每次被动应对更划算。

背景补充

推理模型（reasoning model） 与传统的对话补全模型在调用机制上有本质区别。o1系列在生成最终回答前会先产生一段不对外暴露的“推理token”（reasoning tokens），模型通过链式思考完成问题拆解与自我校验，因此单次调用的延迟更高、计费token数也更多。这类模型适合数学证明、复杂代码重构、多步Agent规划等需要深度推理的任务，而对低延迟闲聊类场景并不经济。迁移到新一代推理模型时，除了关注推理token的计费方式是否变化，还要注意部分新模型可能引入了推理强度（reasoning effort）等可调参数，以及是否支持流式输出推理过程，这些都会影响原有提示词和超时设置的设计。