MiMo Desktop扩容，多模型路由起步

小米把 MiMo Desktop 从单一模型入口改成了多模型工作台

小米在 10 月 29 日宣布升级 Xiaomi MiMo Desktop 会员权益：会员总体使用额度上调，订阅价格保持不变，同时新增 DeepSeek、GLM、Kimi、Qwen 等第三方模型。调整已经实时生效，现有会员和后续新订阅用户均适用；已经安装客户端的用户退出后重新进入，即可查看最新模型列表。

**MiMo Desktop 是小米面向办公、设计、编程和多模态创作场景推出的桌面 AI 应用。**它不只负责回答问题，还能读取表格、图片、视频和 PDF，拆解任务、调用工具，并生成文档、PPT、网页、3D 模型或软件工程项目等可继续编辑的成果。

这次更新最值得关注的并不是简单增加几个模型，而是小米开始把 MiMo Desktop 从自家模型客户端，改造成一个包含多家模型的桌面任务入口。对用户来说，模型选择不再局限于 MiMo；对小米来说，Desktop 的竞争重点也开始从“谁的模型跑分更高”，转向“谁更懂得把模型、工具和工作流组织起来”。

新增七款第三方模型，覆盖速度与能力档位

**第三方模型是指并非由小米 MiMo 团队训练、但被集成到 MiMo Desktop 中供用户直接选择的大语言模型。**小米在公告中只以 DeepSeek 系列举例，IT之家在 10 月 29 日测试时则观察到七个第三方模型选项。

截至目前，客户端中被观察到的第三方模型包括：

| 模型 | 所属系列 | 产品命名体现的档位 | 消耗倍率 | 公开性能数据 | |---|---|---|---|---| | DeepSeek V4 Pro | DeepSeek | Pro，偏复杂任务 | 客户端内标注 | 小米暂未公布统一跑分 | | DeepSeek V4.1 Flash | DeepSeek | Flash，偏速度和成本 | 客户端内标注 | 小米暂未公布首 Token 延迟 | | GLM 5.3 | GLM | 标准或高能力档 | 客户端内标注 | 小米暂未公布统一跑分 | | GLM 5.3 Flash | GLM | Flash，偏快速响应 | 客户端内标注 | 小米暂未公布吞吐数据 | | Kimi K3 | Kimi | 单一可见档位 | 客户端内标注 | 小米暂未公布上下文参数 | | Qwen 3.8 Flash | Qwen | Flash，偏快速执行 | 客户端内标注 | 小米暂未公布首 Token 延迟 | | Qwen 3.8 Max | Qwen | Max，偏高质量输出 | 客户端内标注 | 小米暂未公布统一跑分 |

这份列表应被理解为 2026 年 10 月 29 日客户端中的实际可见选项，而不是长期固定的模型清单。小米明确表示可用模型以当前版本为准，后续完全可能继续增加、替换或调整模型；不同会员档位、灰度范围和地区也可能影响最终显示结果。

这些模型名称同时属于 MiMo Desktop 内的产品标签，不能单独作为相关厂商已经面向所有渠道发布同名模型的证据。尤其是具体上下文长度、推理能力、输出速度和多模态支持范围，目前没有伴随这次更新给出统一测试数据，开发者不宜只根据 Pro、Flash、Max 等后缀直接判断实际能力。

加量不加价是真的，但小米没有公布具体增加多少

**会员额度是用户在订阅周期内可以消耗的模型推理资源总量。**小米称此次升级“显著上调”会员总体额度，并且不调整价格，但公告没有给出升级前后的额度数字，也没有按套餐列出增幅比例。

目前能够确认的权益变化如下：

| 对比维度 | 更新前 | 2026 年 10 月 29 日更新后 | |---|---|---| | 会员价格 | 原有订阅价格 | 官方称价格不变 | | 总体额度 | 原会员额度 | 已上调，具体数值未公开 | | 可选模型 | 主要为 MiMo 系列 | 增加七款已观察到的第三方模型 | | 模型消耗方式 | 按原有规则扣减 | 不同模型显示不同消耗倍率 | | 生效范围 | 原有会员 | 现有会员与后续新会员 | | 生效时间 | — | 10 月 29 日实时生效 |

小米这次给出了积极结论，却没有提供足够完整的量化依据。额度究竟增加 20%、50% 还是翻倍，会直接影响会员的真实获得感；如果高阶模型消耗倍率同步较高，那么名义额度增长也未必等于可完成任务数量同比例增长。

消耗倍率比模型数量更能决定这次升级是否划算。假设某个 Flash 模型的倍率为 1，而某个 Pro 或 Max 模型的倍率为 5，那么同一份会员额度理论上只能执行约五分之一数量的高阶模型任务；反过来，如果日常摘要、格式整理和简单检索都交给低倍率模型，用户就能把高阶额度留给代码重构、复杂研究或长链路 Agent 任务。

小米没有在公告中披露每款模型的具体倍率，因此现阶段无法做出精确的单位任务成本比较。用户真正需要观察的是三个数字：一次典型任务消耗多少额度、不同模型的失败重试次数，以及长任务中因上下文重复带来的额外消耗。

多模型路由已经起步，但还不能等同于跨厂商自动调度

**多模型路由是系统根据任务类型、质量要求、响应速度和计算成本，在多个模型之间选择执行者的调度机制。**它可以由用户手动完成，也可以由系统自动判断，二者在产品体验和技术复杂度上并不是一回事。

MiMo Desktop 此前已经提供 Smart 调度模式，可以评估任务属于办公、编程、研究、设计还是混合场景，并在标准模型与旗舰模型、不同 Agent、Harness 和 Skill 之间选择执行路径。大型任务还能被拆分给多个 Agent，分别负责调研、规划、执行和复核。

这次增加第三方模型，首先可以确认的是“模型池扩容”和“用户可手动选择模型”。但小米目前没有明确说明 Smart 模式是否会在 DeepSeek、GLM、Kimi、Qwen 与 MiMo 之间自动切换，也没有说明一个任务的不同阶段能否分别调用不同厂商模型。

因此，更准确的判断是：MiMo Desktop 已经迈入多模型路由的第一阶段，但真正的跨厂商自动路由仍待验证。模型列表变多只是基础设施，系统能否自动知道什么时候该用 Flash、什么时候切换 Max、什么时候让 MiMo 接管工具调用，才是路由能力的核心。

| 能力层级 | 当前可确认状态 | 对用户的意义 | |---|---|---| | 多模型列表 | 已支持 | 用户可以主动切换不同系列模型 | | 不同消耗倍率 | 已支持 | 可以在质量、速度和额度之间权衡 | | MiMo 内部 Smart 调度 | 官方此前已介绍 | 可按任务复杂度匹配执行路径 | | 跨厂商自动选模 | 尚未明确 | 需要观察 Smart 是否覆盖新增模型 | | 单任务分阶段换模 | 尚未明确 | 决定复杂 Agent 任务的成本效率 | | 自动降级与故障切换 | 尚未披露 | 决定高并发或模型异常时的稳定性 |

桌面 AI 的胜负手正在从模型转向调度系统

桌面 AI 产品很难依靠单一模型长期覆盖所有任务。写一封邮件、整理十页会议纪要、分析几百页资料、重构大型代码库和控制浏览器填写表单，对推理深度、上下文长度、工具调用稳定性以及响应速度的要求完全不同。

高性能模型并不适合承包所有任务。用户不会愿意为了改一个标题等待复杂推理，也不应该让低成本快速模型负责高风险的数据分析和大型代码改动；合理的系统应该像操作系统调度 CPU 任务一样，将轻量工作分配给快速模型，将复杂任务交给高能力模型。

MiMo Desktop 的优势在于它已经把路由放进完整工作流，而不是只做一个聊天窗口。根据小米官方说明，产品能够在办公、代码和研究等执行框架之间切换，还能让多个会话分别拥有独立记忆、工作区和任务状态，并通过通信完成协作。

MiMo Code 则是这套桌面能力的重要技术底座。**MiMo Code 是小米开源的终端原生 AI 编程助手，能够读写代码、执行命令、管理 Git，并通过持久化记忆维持对项目的理解。**其公开仓库展示了 build、plan、compose 三种主要智能体模式，以及按需生成子智能体的设计。

第三方模型接入之后，MiMo Desktop 理论上可以把不同模型放到更擅长的位置。快速模型可以负责分类、摘要、格式转换和简单网页处理，高能力模型可以负责研究规划、代码架构、复杂推理和最终复核，而 MiMo 自有模型则可以继续强化与桌面工具、浏览器控制和多 Agent 系统的配合。

长任务的关键不是单次回答，而是避免重复计算

上下文缓存是 MiMo Desktop 控制长任务成本的重要机制。上下文缓存是系统复用已经处理过的提示词、文件内容和历史会话计算结果，从而减少重复推理消耗的技术。

小米此前公布的测试数据显示，MiMo Desktop 在长任务中的同会话缓存命中率最高可达 99%，跨会话缓存命中率最高可达 95%。这两个数字描述的是最高值而非平均值，但仍然说明小米试图解决 Agent 产品最棘手的问题：任务越长，历史上下文越容易反复占用计算资源。

局部编辑同样比“整份重新生成”更适合桌面工作。修改一份 50 页报告中的两个段落时，如果系统只重新处理相关内容，就能同时降低等待时间和模型消耗；如果每次修改都重新读取全部素材，再高的会员额度也会迅速被长任务吞掉。

多模型路由、上下文缓存和局部编辑构成了一套相互关联的成本控制机制。路由决定用哪个模型，缓存减少重复输入，局部编辑缩小重新生成范围；三者中任何一个环节做得不好，最终都会表现为额度消耗过快、响应延迟增加或任务中途失败。

首 Token 延迟改善是好消息，但仍缺少毫秒级数据

**首 Token 延迟是从用户提交任务到模型开始输出第一个内容片段所需的时间。**这个指标直接影响产品是否“跟手”，尤其是在代码补全、短文本改写和连续追问中，比完整输出耗时更容易被用户感知。

小米表示 MiMo Desktop 的首 Token 延迟和服务稳定性已经显著改善，但没有披露升级前后的具体数据。没有从 800 毫秒降到 200 毫秒之类的对照数字，外界就无法判断改善来自模型推理、网络链路、排队策略，还是客户端渲染优化。

第三方模型增加后，稳定性问题反而会变得更复杂。不同模型的响应格式、工具调用行为、上下文限制和高峰期容量并不一致，Desktop 不仅要处理模型输出，还要负责失败重试、状态恢复、任务接续以及额度结算的一致性。

真正成熟的多模型桌面产品应该把这些差异藏在产品层，而不是让用户充当调度员。如果一个模型暂时不可用，系统应当能够明确提示、保存执行状态，并在用户允许的情况下选择能力接近的替代模型，而不是让整个长任务从头开始。

这次更新最适合三类用户

专业用户会比普通聊天用户更快感受到模型扩容的价值。模型之间的差异在一句问答里可能并不明显，但在持续数十分钟的研究、编程和内容生产任务中，速度、可靠性和消耗倍率会被迅速放大。

• **编程用户适合按任务阶段选模。**代码解释和文件检索可以优先考虑快速模型，架构设计、跨文件重构和最终审查则更适合高能力档位。
• **研究用户适合比较长文本处理稳定性。**同一批 PDF、网页与表格交给不同模型后，引用完整度、事实一致性和任务中断率往往比单次跑分更重要。
• **办公用户适合优先控制倍率。**邮件、纪要、表格清洗和版式修改通常不需要每次调用最高档模型，低倍率模型更可能带来稳定的长期收益。

模型选择困难的用户则不必急着逐个测试全部七款模型。更实用的方法是固定三类基准任务：一个五分钟内完成的轻任务、一个包含多个文件的中型任务，以及一个需要浏览器或工具调用的长任务，再比较完成率、耗时、修改次数和额度消耗。

小米真正要证明的是“路由比单模型更好用”

这次会员升级对现有用户是明确利好，因为价格不变、总体额度增加、模型选择也从 MiMo 系列扩展到至少四个外部模型家族。即使暂时不使用第三方模型，额度上调本身也降低了高频桌面任务的使用压力。

这次更新的不足也很清楚：额度增加多少没有数字，模型倍率没有统一公开表格，首 Token 延迟改善没有毫秒级数据，Smart 是否支持跨厂商自动调度也没有明确答案。对强调真实工作交付的产品来说，这些指标比新增模型数量更重要。

小米的策略方向是对的。桌面 AI 最终不会是一个模型对应一个客户端，而会像浏览器管理网页、操作系统管理应用一样，由统一入口组织模型、工具、文件、记忆和多个 Agent；用户购买的也不再只是一次回答，而是完成任务的能力。

MiMo Desktop 现在已经具备多模型工作台的轮廓，但还没有完全展示多模型路由的上限。下一步需要关注的不是列表里还会增加多少名字，而是 Smart 能否在不增加操作负担的前提下，把七款第三方模型和 MiMo 自有模型真正编排成一套稳定、透明且成本可控的执行系统。

参考来源

• IT之家：小米 MiMo Desktop 会员权益升级——报道 10 月 29 日会员额度调整，并记录客户端中可见的七款第三方模型。
• GitHub：XiaomiMiMo / MiMo-Code 中文说明——小米官方开源仓库，介绍 MiMo Code、MiMo Desktop、多智能体模式与持久化记忆等能力。