小米 MiMo-V2.5 今日下线：V2.6 全面接管，文本模型默认变成多模态

对开发者来说，模型下线从来不是一条普通公告。接口还在、参数没变，但返回结果可能已经换了一个模型。10 月 21 日上午 10 时，小米 MiMo 的 mimo-v2.5-pro 与 mimo-v2.5 正式下线，系统全面替换为 mimo-v2.6-pro 与 mimo-v2.6-flash。更关键的变化是：原本只支持文本输入的 V2.5-Pro，替换之后默认具备多模态理解能力。

一分钟速览

• mimo-v2.5-pro 与 mimo-v2.5 于 10 月 21 日 10:00 下线，分别由 mimo-v2.6-pro、mimo-v2.6-flash 接管
• 自动路由从 10 月 14 日 18:00 就已开始，API 参数保持适配
• 替换后最大的变化是多模态理解：文本模型升级为原生全模态模型
• 定价沿用 V2.5 系列：Flash 每百万词元输入 1 元、输出 2 元；Pro 输入 3 元、输出 6 元，并提供 99% 缓存折扣

迁移时真正要盯的三个细节

官方文档把参数规则写得很细，其中三处最容易踩坑。第一，在思考模式下，mimo-v2.6-flash 与 mimo-v2.6-pro 不支持自定义 temperature 和 top_p，实际传参固定为 temperature 1.0、top_p 0.95。依赖低温度做稳定输出的业务，需要重新评估结果波动。

第二，如果调用 V2.5 时自定义了参数，自动路由到 V2.6-Flash 时会继承 V2.5 的传参，这可能导致「以为用的是新默认值、实际用的是旧参数」的错位。第三，max_completion_tokens 的默认值从 32768 提升到 131072，长输出场景的上限被大幅放宽，但成本控制逻辑也要同步调整——输出更长，账单也会更长。

从「文本模型」到「原生全模态」

小米在 9 月 22 日发布并开源了 Xiaomi MiMo-V2.6 系列，包含 Pro 与 Flash 两个原生全模态模型。所谓原生全模态，指的是模型在设计阶段就把文本、图像等模态放进同一套表征与训练流程，而不是在文本模型外面再挂一个视觉编码器。对开发者最直接的好处是：同一个接口可以同时处理文字和图片，不必再维护两套调用链。

把 V2.5 这样的纯文本模型下线，本质上是一次产品形态的切换。过去「文本模型」和「多模态模型」是两个并列选项，现在多模态成了默认能力，文本只是其中一种输入。这个变化对应用层的影响可能比参数调整更大：文档理解、截图问答、图表分析这类过去需要额外组件的功能，会变成一次普通 API 调用。

价格仍是最大的变量

V2.6 系列沿用 V2.5 的定价，Flash 每百万词元输入 1 元、输出 2 元，Pro 输入 3 元、输出 6 元，并提供 99% 的缓存折扣。官方给出的对比是：在同等智能水平下，价格仅为海外模型的 1/20 至 1/60。

这个价格区间意味着，国产模型的竞争已经从「能不能用」进入「单位智能的成本」。当输入价格低到每百万词元 1 元，很多过去因为成本而不敢做的场景——全量日志分析、批量文档处理、长会话记忆——开始变得经济可行。而 99% 的缓存折扣，实际上是在鼓励开发者把稳定的系统提示词和知识库前置，用工程手段进一步压低成本。

趋势洞察：模型迭代正在变成「滚动升级」

这次下线最值得记录的一点，不是某个参数变了，而是节奏：9 月 22 日发布 V2.6，10 月 14 日开始自动路由，10 月 21 日正式下线 V2.5，前后不到一个月。模型迭代正在从「大版本发布」变成「滚动升级」，开发者面对的不再是几年一次的技术选型，而是持续不断的兼容性维护。

这意味着应用层需要新的工程习惯：把模型调用抽象成可替换的适配层，为关键业务保留回归测试集，对温度、最大输出、多模态输入等参数做显式声明而不是依赖默认值。模型会一直变，能穿越版本变化的，只有测试和抽象。