MiniMax宣布从2026-10-19起停止向新用户开放M2.5和M2.7系列，并计划于11月18日将这两款模型的API正式下线。公告强调不同套餐用户的迁移路径不同，开发者需在截止日前检索模型ID、评估替代方案并完成回归测试与降级策略。
MiniMax开放平台公告显示，M2.5和M2.7系列模型将从2026年10月19日起停止向新用户开放调用，并计划于11月18日正式下线。对于仍在生产环境中使用这两个模型的开发者而言，这不是一次单纯的模型列表更新，而是一个需要在明确期限前完成评估和迁移的API兼容性变更。
MiniMax在官方模型文档中说，现有按量付费API用户可以继续使用M2.5和M2.7，直到11月18日。下线后，针对这些模型的API请求将不再生效。平台没有在这份公告中承诺为按量付费流量自动切换到新模型，因此依赖旧模型名称的应用应提前检查调用路径、模型参数和异常处理逻辑。
公告同时区分了不同用户类型。M Plan和Token Plan用户从10月19日起，针对M2.5和M2.7的请求将自动路由至M3.1 Flash Preview。原有模型名称仍可作为兼容入口继续使用，用户不需要立即修改请求中的模型名称，平台并称套餐的用量权益不会因此改变。M3.1 Flash Preview目前主要通过M Plan和MiniMax Code提供，并非所有按量付费API用户都能直接将其作为同等替代品使用。
两个日期对应两种不同的服务状态
10月19日并不意味着M2.5和M2.7对所有用户立即停止服务。它首先意味着新用户不能再开始使用这两个模型；对已有按量付费用户，服务窗口将延续到11月18日。后一个日期才是API服务正式终止的时间点。
这一安排使迁移工作具有明显的时间边界。开发者需要确认应用使用的是M2.5、M2.5-highspeed、M2.7还是M2.7-highspeed，并区分账户属于按量付费、M Plan还是Token Plan。不同套餐的自动路由和可用模型并不相同，不能简单把“旧模型下线”理解为所有请求都会被无缝切换到同一个新模型。
MiniMax的模型文档目前将M3列为面向新一代任务的模型，并把M3.1 Flash Preview描述为具有原生多模态和百万级上下文能力的版本。不过，旧模型停用本身并不能证明新模型在每个具体任务上的能力、速度、价格或输出稳定性都已经等价。生产系统仍需要通过回归测试确认提示词、工具调用、结构化输出、上下文长度和成本变化。
从模型更新转向API生命周期管理
模型服务商越来越多地采用“旧模型保留一段时间、随后统一迁移”的生命周期管理方式。对开发者来说，真正的风险通常不在于模型页面上少了一个选项，而在于应用把模型ID、输出格式或推理行为写死在业务流程中。一旦请求在11月18日后直接失败，依赖该模型的客服、代码生成、内容处理或智能体任务都可能受到影响。
MiniMax此次公告也显示，模型迁移并不只有技术层面的改名问题。M Plan和Token Plan用户可以依赖平台自动路由，但这会让底层模型发生变化；按量付费用户则需要自行规划替代方案。两种情况下，都应重新评估响应延迟、上下文处理、工具使用和计费方式，而不能仅凭请求仍能成功就认定迁移已经完成。
这类变化与MiniMax此前推动开放模型和多模态产品的路线形成了对照。公司今年发布H3时，曾将多模态输入、视频生成和开放权重作为重点方向；AI Flux此前对MiniMax H3的报道曾指出，模型竞争正在从单一能力比较转向产品、部署和生态的综合竞争。对API客户而言，这也意味着服务稳定性和迁移政策本身正在成为模型平台竞争的一部分。
开发者现在需要核查什么
首先，应从代码、配置文件和网关路由中搜索M2.5和M2.7的全部模型ID，确认是否存在按环境区分的隐藏调用。其次，应记录现有请求的输入输出规模、平均延迟、失败率和月度成本，建立迁移前后的可比较基线。对于依赖函数调用、代码生成或长上下文的应用，还需要用真实业务样本测试新模型，而不是只进行简单问答对比。
按量付费用户应重点确认MiniMax-M3的可用性、价格和调用限制；M Plan与Token Plan用户则应验证自动路由后的输出是否仍符合业务要求。无论采用哪种路径，都应在11月18日前保留可回滚的配置，并为模型请求失败、输出格式变化和延迟上升准备降级策略。
MiniMax的公告确认了服务安排和迁移时间表，但没有据此宣称M2.5或M2.7的模型能力、客户使用结果或商业表现发生了变化。当前能够确认的是：新用户开放范围已经收紧，现有用户的迁移窗口正在倒计时，而11月18日之后旧模型API请求将不再可用。