小米MiMo V2.5进入退场倒计时

小米在10月9日宣布，mimo-v2.5-pro和mimo-v2.5两款模型将在2026年10月21日正式下线，现有调用会先于10月14日自动迁移到MiMo-V2.6系列。具体替换关系是：mimo-v2.5-pro转向mimo-v2.6-pro，mimo-v2.5转向mimo-v2.6-flash。

这不是一次简单的模型名称更新，而是一段只有一周的强制迁移窗口。10月14日18:00之后，即使开发者没有修改模型名称，请求也会被小米转发到V2.6，并按照新版模型计费；到了10月21日10:00，两个旧模型名称将彻底失效，继续使用旧名称的请求会直接报错。

换句话说，10月14日是“行为切换点”，10月21日才是“接口失效点”。前一个时间点决定线上应用实际使用哪一个模型，后一个时间点决定应用是否还能正常发出请求。对生产系统而言，真正需要盯紧的日期不是10月21日，而是更早的10月14日。

两个阶段，风险完全不同

自动迁移是指平台在服务端保留旧模型名称，但把请求转发给新的模型执行。它可以减少模型升级带来的瞬时故障，却不能保证新旧模型输出完全一致，更不能替代开发者自己的回归测试。

小米给出的迁移时间表如下：

| 时间（UTC+8） | 平台动作 | 开发者实际感知 | 主要风险 | |---|---|---|---| | 2026年10月14日18:00前 | V2.5系列正常提供服务 | 请求仍由旧模型处理 | 留给测试和切换的时间有限 | | 2026年10月14日18:00起 | 旧名称自动转发到V2.6 | 不改模型名称也会得到V2.6输出，并按新版规则计费 | 输出风格、工具调用和多模态行为可能改变 | | 2026年10月21日10:00起 | V2.5旧模型正式下线 | 旧模型名称失效，请求直接报错 | 未改配置的应用出现硬故障 |

自动转发解决的是可用性问题，没有解决兼容性问题。大模型不是遵循固定输入输出映射的传统函数，同一条提示词换一个模型后，答案长度、推理路径、结构化字段稳定性、工具选择和拒答边界都可能发生变化。即便接口协议没有调整，应用层仍然可能出现行为回归。

这次过渡期只有7天，也说明小米不准备长期维护V2.5兼容层。对于仍在使用旧模型的团队，最稳妥的做法是在10月14日前主动改用新的模型ID，让测试环境和生产环境的模型版本保持明确，而不是依赖平台的隐式转发。

V2.6不只是V2.5换了名字

MiMo-V2.6是小米于2026年9月22日前后全面上线并开源的新一代原生全模态模型系列。原生全模态模型是指模型在统一架构中直接理解文本、图像等多种输入，而不是在语言模型外部临时拼接一个视觉识别模块。

从官方模型列表看，mimo-v2.6-pro和mimo-v2.6-flash都支持文本生成、全模态理解、深度思考、流式输出、函数调用、结构化输出和联网搜索。两者的上下文窗口均为100万Token，最大输出长度为12.8万Token，默认限流上限为每分钟100次请求和每分钟1000万Token。

V2.5系列的能力边界则不完全相同。mimo-v2.5-pro虽然同样支持深度思考、函数调用、结构化输出和联网搜索，但官方能力表没有将它列为原生全模态模型。这意味着从V2.5 Pro迁移到V2.6 Pro，不只是推理性能升级，还可能改变图片输入、跨模态提示词以及工具链的组织方式。

两代模型的核心差异可以归纳为：

| 维度 | mimo-v2.5-pro | mimo-v2.5 | mimo-v2.6-pro | mimo-v2.6-flash | |---|---:|---:|---:|---:| | 定位 | 旧旗舰推理模型 | 旧标准模型 | 新旗舰模型 | 新高性价比模型 | | 迁移关系 | 转向V2.6 Pro | 转向V2.6 Flash | 接替V2.5 Pro | 接替V2.5 | | 原生全模态 | 官方旧能力表未标注 | 能力以旧版配置为准 | 支持 | 支持 | | 上下文窗口 | 100万Token | 100万Token | 100万Token | 100万Token | | 最大输出 | 12.8万Token | 12.8万Token | 12.8万Token | 12.8万Token | | 批量推理 | 不支持 | 不支持 | 支持 | 支持 | | 状态 | 10月21日下线 | 10月21日下线 | 在售 | 在售 |

这次升级最有实际价值的变化，是V2.6把全模态能力和批量推理带到了常规模型线上。全模态适合文档截图分析、图表理解、视觉质检和图文知识库，批量推理则适合离线摘要、数据标注、内容审核和大规模评测，两项能力都比单纯提高跑分更容易转化为开发者能用到的功能。

价格没涨，但批量推理把成本再砍一半

MiMo-V2.6系列沿用了V2.5系列的实时推理价格。mimo-v2.6-flash的未缓存输入价格为每百万Token 1元，输出为2元；mimo-v2.6-pro的未缓存输入价格为每百万Token 3元，输出为6元。

缓存命中价格远低于常规输入价格。V2.6 Flash的缓存命中输入为每百万Token 0.02元，相比1元的未命中价格降低98%；V2.6 Pro的缓存命中输入为每百万Token 0.025元，相比3元降低约99.17%。官方所说的“99%缓存折扣”，主要体现在Pro模型上。

V2.6新增的批量推理价格又是实时推理的一半。Flash批量输入和输出分别为每百万Token 0.5元和1元，Pro则分别为1.5元和3元。对于不要求即时返回的任务，批量模式比换用更小的模型更直接，因为开发者可以保留模型能力，同时把主要Token成本降低50%。

| 模型与推理方式 | 缓存命中输入 | 未缓存输入 | 输出 | 相对实时价格 | |---|---:|---:|---:|---:| | V2.6 Flash实时推理 | 0.02元/百万Token | 1元/百万Token | 2元/百万Token | 基准 | | V2.6 Flash批量推理 | 0.01元/百万Token | 0.5元/百万Token | 1元/百万Token | 降低50% | | V2.6 Pro实时推理 | 0.025元/百万Token | 3元/百万Token | 6元/百万Token | 基准 | | V2.6 Pro批量推理 | 0.0125元/百万Token | 1.5元/百万Token | 3元/百万Token | 降低50% | | V2.6 Pro UltraSpeed | 0.25元/百万Token | 30元/百万Token | 60元/百万Token | 常规Pro的10倍 |

价格不变并不意味着迁移前后账单一定相同。模型输出长度会直接影响费用，如果V2.6在相同任务中生成更多推理Token或更长答案，单次调用成本仍可能上升；反过来，如果新模型用更短的推理过程完成任务，实际成本也可能下降。因此，团队应比较真实请求的平均输入量、平均输出量和缓存命中率，而不能只看价目表。

小米称，MiMo-V2.6 Pro在同等智能水平下的价格约为海外模型的1/20至1/60。这个说法体现了国产模型当前激烈的价格竞争，但“同等智能水平”高度依赖评测集和任务类型，不能直接推导出所有业务都能获得相同比例的成本优势。

Pro、Flash和UltraSpeed应该怎么选

V2.6 Pro是面向复杂项目、长程任务、高价值工作、网络安全与科研场景的旗舰版本。它更适合代码代理、多步骤信息检索、复杂分析和需要反复调用工具的任务，因为这些场景更看重推理上限，而不是单次请求的最低价格。

V2.6 Flash是面向专业办公、高频调用和规模化任务的性价比版本。客服回复、文档摘要、信息抽取、分类、常规内容生成等任务通常不需要旗舰模型的全部能力，Flash每百万Token 1元输入、2元输出的定价更适合稳定的大吞吐量。

V2.6 Pro UltraSpeed是面向强实时交互的高价低延迟版本。小米宣称该模式最高可提供20倍推理速度，但未在参考资料中披露统一的每秒Token数或首Token延迟，因此“20倍”更适合作为特定运行条件下的峰值描述，而不是所有请求都能达到的固定倍率。

UltraSpeed的费用是常规Pro的10倍，未缓存输入达到每百万Token 30元，输出达到60元，而且不支持批量推理。它更适合实时语音助手、交互式编程和需要缩短等待时间的现场系统，不适合普通离线任务。花10倍价格购买最高20倍速度，本质上是在用成本换响应时间，而不是购买更高的模型智能。

小米正在加快模型淘汰节奏

MiMo产品线在2026年的升级周期已经明显缩短。根据此前公告，MiMo-V2-Pro和Omni模型曾在6月30日下线，由V2.5系列接替；仅约三个多月后，V2.5又进入下线流程，接棒者变成V2.6。

快速迭代对模型厂商有明显好处。厂商可以减少旧模型占用的推理集群、监控系统和兼容性测试资源，把强化学习与推理优化集中到最新版本上；开发者也能以相同价格得到更强能力，不必在多个历史版本间反复选择。

快速淘汰对企业用户同样有明确代价。模型ID如果每隔数月就需要更新，提示词评测、合规审核、输出基线和故障预案都要重新执行。对金融、医疗、政务等强调模型版本可追溯性的行业而言，自动迁移甚至可能破坏审计链条，因为配置文件记录的是V2.5，实际执行请求的却已经是V2.6。

小米这次设置一周自动转发期，说明其优先目标是让普通开发者不中断服务，而不是维持长期版本兼容。这个选择对快速开发的应用合理，但对于依赖固定模型行为的生产系统，一周仍然偏紧。成熟的平台最好同时提供模型版本锁定、明确的弃用周期和可查询的实际执行模型信息，让开发者知道一次请求究竟由哪个版本处理。

开发者现在最该检查什么

模型迁移的第一项工作是盘点所有旧模型名称。模型ID可能出现在应用配置、环境变量、工作流节点、桌面客户端、定时任务、评测脚本和低代码平台中，只修改主服务并不能保证10月21日后不再出现失败请求。

模型迁移的第二项工作是用真实业务样本做双版本对照。测试集至少应覆盖结构化输出、长上下文、函数调用、联网搜索、敏感内容处理和异常输入，并记录成功率、响应时间、输入Token、输出Token以及人工评分。只用几条聊天问题判断“答案看起来更好”，不足以验证生产兼容性。

模型迁移的第三项工作是重新检查结构化输出和工具调用。新模型可能更主动地选择工具，也可能修改参数生成习惯；如果业务依赖严格JSON字段、枚举值或固定工具顺序，就需要确认下游解析器是否能处理新增字段、空值和重试行为。

模型迁移的第四项工作是提前更新模型名称并保留回滚开关。10月14日后，旧名称和新名称实际上都将指向V2.6，继续使用旧名称只会掩盖尚未完成的配置修改；10月21日一到，这些被掩盖的问题就会变成直接报错。

模型迁移的第五项工作是重新建立成本基线。团队应分别统计实时和批量任务，把可延迟执行的摘要、标注、评测迁移到批量推理，同时观察缓存命中率。对于拥有长且稳定系统提示词的应用，缓存优化带来的成本下降可能远大于Pro与Flash之间的价格差。

需要特别注意的是，此次下线只涉及文本生成模型mimo-v2.5-pro和mimo-v2.5。mimo-v2.5-asr、mimo-v2.5-tts、mimo-v2.5-tts-voiceclone及mimo-v2.5-tts-voicedesign仍出现在官方模型列表中，不能因为名称同样带有“V2.5”就误判为一并下线。

这次迁移值得做，但不该等平台替你做

MiMo-V2.6在价格不变的前提下增加原生全模态、批量推理和更强推理能力，是一次有实际产品价值的升级。尤其是批量价格降低50%，以及缓存命中输入最低降至每百万Token 0.01元，使它对大规模离线任务更有吸引力。

自动迁移机制降低了突然停服的概率，却也容易让团队误以为无需采取行动。10月14日起，应用输出就可能已经发生变化；10月21日起，旧模型名称则会直接失效。前者影响业务质量，后者影响服务可用性，两种风险都不能靠自动转发彻底解决。

这次下线更值得关注的信号，是小米正在把MiMo模型更新从“可选升级”变成“持续滚动”。对开发者来说，未来真正需要建设的不是一次性的模型替换脚本，而是一套可重复执行的评测、灰度、监控和回滚流程。模型价格可以越来越低，但频繁升级带来的工程成本不会自动消失。

参考来源

• IT之家：小米发布MiMo-V2.5-Pro模型下线通知，可替换为V2.6版本：提供V2.5系列下线时间、自动迁移关系、V2.6发布时间及主要定价信息。