小米 MiMo-V2 系列 6 月 30 日下线，V2.5 全面接棒

小米给 MiMo-V2 系列定了死期：6 月 30 日零时

小米 MiMo 开放平台今天挂出了一纸下线通告——MiMo-V2 系列的四款模型，从 mimo-v2-pro、mimo-v2-omni、mimo-v2-flash 到 mimo-v2-tts，将统一在 2026 年 6 月 30 日零时停服。过了这个点，旧模型名称会彻底失效，继续按老名字打 API 的请求直接返报错。

这事其实在 5 月底就已经吹过风。彼时雷军那边的口径还比较温和，说的是 Pro 和 Omni 两款先迁；现在公告补齐了 Flash 和 TTS 的时间表，等于把 V2 整条产品线一次性收掉。距离最终下线只剩 18 天，没动手的团队需要尽快排期了。

时间线拆开看：分两批切，过渡期不长

小米这次没有玩“一刀切”，而是分两批切流量，并且每批都留了“系统替换”作为缓冲。简单理解就是：还没到正式下线那天，旧模型名能继续调，但流量已经悄悄走到新版本上去了，价格也按新版收。

第一批（已经发生）：

• mimo-v2-pro → mimo-v2.5-pro：北京时间 6 月 1 日零时已自动路由
• mimo-v2-omni → mimo-v2.5：同样是 6 月 1 日零时切换

第二批（一周后）：

• mimo-v2-flash → mimo-v2.5：6 月 18 日零时自动路由
• mimo-v2-tts → mimo-v2.5-tts：6 月 18 日零时自动路由

最终关闸时间：

• 6 月 30 日零时：旧模型名全部失效，再调就报错

这套节奏在大模型 API 厂商里算是比较克制的。OpenAI 当年弃用 text-davinci 系列只给了几周公告，Anthropic 弃用旧版 Claude 也是说停就停。小米这次官方公告 → 自动路由 → 强制下线三段式走完，留给开发者的窗口期接近一个月，至少在排期上不算粗暴。

Pro 和 Omni：API 参数完全兼容，几乎是无痛迁移

对于已经在生产环境跑 mimo-v2-pro 的团队，好消息是迁移成本基本为零。小米官方明确说，这两款模型的 API 参数可以完全适配 V2.5 对应版本，业务侧只需要把模型名字段从 mimo-v2-pro 改成 mimo-v2.5-pro，其他什么都不用动。

这种“参数对齐”的做法，本质上是把 V2.5 当作 V2 的能力升级版来设计，而不是另起炉灶。从用户视角看，最大的差异其实在三点：

1. 价格按新版计费。V2.5 系列前不久刚做过一轮永久降价，降幅 57%-99%，所以多数场景下迁移完账单是变便宜的，不存在“被升级被收割”的反向操作。
2. 推理性能拉满。V2.5-Pro 的 UltraSpeed 模式据小米说是业内首个在 1 万亿参数模型上做到 1000 tokens/s 输出速度的，这个数字放在 6 月份的国内闭源/混源模型阵营里属于第一梯队，但要付出 3 倍价格换 10 倍输出体验。
3. 能力代际差。V2.5 在长上下文、代码、多模态推理上相较 V2 有明显提升，迁移完一般不会出现“老业务回归测试不过”的尴尬。

对开发者来说，如果原本就在用 SDK 走的是配置化的 model name，那基本只是改个环境变量的事。

Flash 和 TTS：要注意几个坑

相比无痛迁移的 Pro/Omni，Flash 和 TTS 这两款需要稍微仔细一点。

Flash 路由的是 mimo-v2.5（非 -flash）

注意公告里这个细节：mimo-v2-flash 自动路由到的是 mimo-v2.5，而不是 V2.5 体系里专门的轻量版。这意味着原本走低延迟、低单价的 Flash 业务，迁过去之后定位会变。如果对延迟和价格特别敏感，可能需要单独评估一下 V2.5 主力版的响应曲线，或者考虑切到其他厂商的轻量模型补位。

这也侧面说明小米对 V2.5 系列的策略思路：用统一的主力模型覆盖原本 Pro/Omni/Flash 三个档位，靠 UltraSpeed 这种模式去拉差异，而不是再去维护一条独立的 Flash 产品线。

TTS 的音色映射要重测

语音业务是这次迁移里最需要警惕的部分。mimo-v2-tts 切换到 mimo-v2.5-tts 时，音色体系直接换了——新版本不再沿用旧的音色 ID，而是根据集群地域做差异化映射：

• 中国集群：mimo_default → 映射为 冰糖
• 其他集群：mimo_default → 映射为 mia

这种地域差异化听起来有点像“一国两声”，但对实际业务影响不小。如果你的产品有海外用户，同一个默认音色 ID 在中国和海外集群下听感会完全不一样，需要在客户端层面做对齐，或者干脆显式指定音色，避免“同一段广告，国内用户听到甜系少女，海外用户听到另一种气质”的尴尬。

建议 TTS 业务方在 6 月 18 日之前把这几件事做掉：

• 把现有调用里所有依赖 mimo_default 的代码改成显式音色
• 跑一遍音色映射回归，重点听情绪标签、停顿、语速的差异
• 如果做了情感 TTS 的微调或 prompt 工程，新模型可能要重新调一遍

为什么小米这个时间点要清理 V2？

答案其实很直白：V2.5 不只是“更好”，而是“足够好到可以不留 V2”。

四月底发布 V2.5 时，小米一次性放出了四款模型，其中两款承诺开源；五月初 V2.5-Pro 拿到了 UltraSpeed 模式，1 万亿参数 1000 tokens/s 这个组合在国内是头一份；五月中又做了一轮极限降价，把 API 单价拉到几乎跟二线模型平齐。三连击之后，V2 在性价比、性能、上下文能力上都被自家新版本全面压住，留着只会增加运维负担和用户决策摩擦。

从产品视角看，小米 MiMo 团队做得比较果断的一点是：没有让 V2 和 V2.5 长期并存。很多大厂模型 API 喜欢挂一长串老版本，结果就是新用户看不懂选哪个，老用户也懒得迁。小米这次直接限定迁移窗口，把决策强行收敛到 V2.5，对平台演进效率是有好处的。

国内大模型 API 的节奏，正在向“季更”靠拢

顺着这件事往外看一层，会发现 2026 年上半年国内大模型 API 厂商基本都进入了“季更”节奏：

• 通义 Qwen 系列保持每月小更、每季度主版本切换
• DeepSeek 这边 V3 系列也在频繁迭代
• 智谱 GLM 同样在主力模型上做了多轮静默升级
• 小米这次 V2 → V2.5，正好赶上 V2.5 发布后的两个月节点

两个月一个主力版本，对开发者意味着什么？意味着你不能再把模型名硬编码在业务里，CI 里也得加自动适配的兜底，否则下一次类似的“强制路由 + 30 天后下线”节奏一来，就是连夜上线热修复。

国内做 AI 应用的团队，今年最该养成的一个习惯是：把模型名当成可热切换的配置项，并且默认接入一个聚合层。这也是 OpenAI Hub（openai-hub.com）这类聚合平台存在的意义——一个 Key 调 GPT、Claude、Gemini、DeepSeek 各家模型，统一 OpenAI 格式，遇到这种厂商集中下线老版本的情况，至少在调用层不用满世界改代码。 小米 MiMo V2.5 系列也已经在 OpenAI Hub 上线，原本走 V2 的请求可以借这个迁移窗口顺便把对接收敛掉。

给开发者的迁移建议

按业务分类整理一下，照着做就行：

用 Pro/Omni 跑文本和多模态推理的：

• 立即把 model 字段改成 mimo-v2.5-pro 或 mimo-v2.5
• 跑一遍核心场景的回归，重点看长上下文和复杂推理
• 评估是否要开 UltraSpeed 模式，权衡 3 倍单价换 10 倍速度

用 Flash 跑低延迟业务的：

• 6 月 18 日前完成切换，别等自动路由
• 单独测一下延迟，必要时考虑分流到其他厂商的轻量模型
• 如果是 ToC 高并发场景，提前压测 V2.5 主力的尾延迟

用 TTS 做语音生产的：

• 立刻盘点所有依赖 mimo_default 的调用
• 改成显式音色，不要依赖默认映射
• 海外业务一定要测“mia”音色的实际听感
• 重新跑一遍情感、停顿、语速回归

所有团队都该做的：

• 把模型名配置化，下次再有强制下线不至于改代码到天亮
• 监控里加上“模型名是否在生效列表”的告警
• 在 OpenAI Hub 这类聚合层做一层兜底，模型一旦报错可以自动 fallback

小结

小米这一波操作中规中矩——给了一个月公告期，分两批自动路由，对 Pro/Omni 用户基本无痛，对 Flash/TTS 用户略有坑但都能提前规避。真正值得复盘的不是这次下线本身，而是国内大模型 API 厂商正在以季更速度迭代，开发者侧的工程实践得跟上。

6 月 30 日零时是个明确的 deadline，剩下的时间不多。该改的改，该测的测，别让一行写死的模型名，把你的服务在凌晨拉下线。

参考来源

• 小米 MiMo-V2 系列模型 6 月 30 日正式下线，Pro 版已自动切换至 V2.5 - IT之家：IT之家对本次 MiMo-V2 下线公告的完整报道，包含四款模型的时间表和音色映射细节