上周还能沿用的模型名称，这周可能已经成为报错入口。小米MiMo官方文档确认，mimo-v2.5-pro与mimo-v2.5已于10月21日北京时间10:00正式下线，原模型名失效。此前从10月14日18:00开始的自动转发，是迁移过渡，不是永久兼容。对仍在调用旧名称的应用，眼下要检查的是部署配置，而不只是更新宣传页上的模型版本。

快速看点：两个旧模型分别迁移至V2.6-Pro与V2.6-Flash；思考模式下的采样参数有固定处理规则；Flash路径的默认输出上限从32768变为131072。这不是新模型在21日首发，也不代表请求会自动生成四倍长度或产生四倍账单。

自动替换与正式下线，是两个时间点

模型下线通知的更新时间是10月9日，执行节点则分为两步。10月14日18:00后，旧模型名的请求自动转到对应新模型，并按新版模型计价；10月21日10:00后，旧名称不再有效，继续使用会收到报错。22日阅读这项通知时，迁移窗口已经结束。

对应关系也要分清：mimo-v2.5-pro替换为mimo-v2.6-pro，mimo-v2.5替换为mimo-v2.6-flash。名称看似只差一个版本号，实际后端和参数处理可能已经变化，不能把旧名仍然出现在配置文件中理解为仍然运行旧模型。

本次通知针对这两个具体标识。不能只因为其他产品名称也含有V2.5，就推断语音合成、语音识别或全部同代产品一并停止。排查应按实际调用的模型ID逐一匹配，而不是对产品前缀做批量替换。

能发出请求，不代表参数含义没变

官方对Pro路径写明API参数适配，升级后还支持多模态理解。但接口层兼容不等于输出风格、工具选择、答案结构或业务判断完全相同；新增多模态能力也不意味着原本只发文字的应用自动获得了新的业务流程。

思考模式下，V2.6-Flash与V2.6-Pro不支持自定义temperature和top_p，实际采用temperature为1.0、top_p为0.95。若应用此前依赖较低温度来控制输出，应核对这一模式边界，再用真实任务评估稳定性，不能只看请求参数有没有填写。

旧mimo-v2.5路径自定义的参数，在过渡转发时会按通知规则继承；若没有指定max_completion_tokens，则采用新Flash默认值。官方列出的差异是32768变为131072，这一项是完成输出的上限，不是模型上下文窗口。

更高的上限只是允许模型在需要时生成更多内容，不等于每次请求都生成到上限，也不能直接据此计算实际费用增长。交付团队应结合实际输出量、执行时长、任务完成情况和账单观察，而不是把一个配置差异当成确定的性能或成本结果。

迁移清单要覆盖后台，不只聊天窗口

一个项目可能在多个位置保存模型名：在线服务环境变量、网关路由、批处理作业、评测脚本、定时任务和故障备用配置。只修前台聊天界面，仍可能留下夜间任务或回退分支继续访问旧标识。检查范围应跟随真正的调用链，而非只看代码仓库搜索结果。

切换后也不宜盲目反复重试。若错误来自旧模型名称失效，重复发送同一标识不会恢复旧服务；应先确认配置和替换关系，再以受控样本验证。对于已经成功的外部写操作，模型调用层重试还需要与应用自身的重复执行防护分开处理。

回归测试至少应包含正常回答、结构化输出、工具调用和长输出任务，并比较缺省参数与显式参数两条路径。这里的检查清单是实施建议，不是小米披露的生产故障统计，本次也没有证据说明多少客户发生了中断。

旧版本若已不再提供服务，所谓回滚也不能简单恢复旧模型名。团队需要准备当前仍可用的替代路线，确认权限、预算和业务评测均满足要求；不能在失败后才发现备用配置与主链路指向同一个已失效名称。

小编判断：模型ID应进入发布管理

这次下线提醒的，不只是某家厂商的版本更新。模型名称、实际服务版本、默认参数与退出日期，都是应用运行契约的一部分。即使平台提供自动转发，企业仍应把过渡窗口写入变更计划，并保留切换前后的配置与评测记录。

最直接的验收方式，是确认生产部署和后台任务不再使用失效ID，替代模型通过固定回归样本，输出预算与告警能覆盖新默认值。官方文档能证明的是下线规则，业务是否已经恢复则必须由自己的运行证据回答，不能把“改了一个字符串”当成迁移完成。