小米 MiMo-V3 – 小米 MiMo 团队公布的下一代长上下文基础模型

小米 MiMo-V3是小米 MiMo 团队于2026年9月公布的面向长程智能体任务的下一代长上下文基础模型，主要用于长上下文推理与多轮工具调用，支持两级 KV 共享的混合稀疏注意力与百万 token 级上下文，适用于智能体训练、代码仓库理解与长文档处理场景。

小米 MiMo-V3 的核心能力

小米 MiMo-V3 的改动集中在注意力结构。面向 AI 智能体 的多轮交互中，模型每一轮只输出简短动作，却要读入工具返回的长文本，上下文持续累积，预填充开销、KV 缓存占用与长上下文检索准确率因此同时成为瓶颈。HySparse2 的两级 KV 共享针对这三项分别做了压缩与提升。

两级 KV 共享：KV 桥接与 KV 重用

外层 KV 桥接沿用 YOCO 的思路，把自解码器与交叉解码器之间的共享限定在全注意力层：交叉解码器全注意力层的 K/V 直接由自解码器对应层的隐藏状态构建，避免重复计算。内层 KV 重用让每个混合块内的稀疏层复用上一层全注意力层的 KV 缓存与选择索引。两级共享打通后，交叉解码器的 KV 缓存全部来自自解码器，预填充在自解码器完成后即可退出，跳过交叉解码器的各层计算。

token 级稀疏与近期 Token 强制窗口

相较前代的块级选择，HySparse2 改为 token 级选择，长上下文检索的粒度更细；同时移除稀疏层中独立的滑窗分支，改为把近期 token 的强制窗口并入稀疏选择，让本地与全局 token 共用同一份 KV 缓存。官方在 80B-A3B MoE 模型上验证，这两项调整在长上下文检索与多轮智能体任务上同时带来提升。

预填充计算与 KV 缓存的开销变化

在 100 万 token 上下文下，HySparse2 的预填充计算量降至前代混合滑窗方案的 1/5.02，KV 缓存占用缩小至 1/4.5；MRCR-v2 与 RULER-v2 两项长上下文评测得分高于前代，AgentPPL 与 LongPPL 两项语言建模指标更低。对以长会话为主的智能体应用而言，这两项开销直接决定单轮交互的延迟与显存占用。

与前代的衔接

上一代 Xiaomi MiMo-V2.6 于本月发布并开源，采用混合滑窗注意力，包含 Pro 与 Flash 两个原生全模态模型，上下文窗口为 1,048,576 tokens。MiMo-V3 的 HySparse2 在其基础上替换了稀疏选择的粒度与滑窗分支的组织方式，官方给出的对照数据即以 V2.6 所用的混合滑窗方案为基线。

小米 MiMo-V3 与同类长上下文模型的对比

上表中 MiMo-V3 一列取自其技术论文，其余两列取自各发布方的官方资料与站内已发布页。长上下文方向的差异最直接：MiMo-V3 面向百万 token 级上下文并把预填充与缓存开销作为主要指标，DeepSeek V4.1 Flash 提供 1M token 上下文与 384K 最大输出，Gemini 3.8 未公布上下文规格。开放程度上，DeepSeek V4.1 Flash 以 MIT 许可开放权重，可自建推理服务；MiMo-V3 尚未公布开源计划，Gemini 3.8 为闭源服务。需要立刻上线的场景应优先评估已发布的模型，MiMo-V3 更适合作为技术路线的前瞻参考。

如需对照这一系列上一代的完整规格与开源情况，可参考 Xiaomi MiMo-V2.6（小米已开源的原生全模态模型系列，包含 Pro 与 Flash 两个版本，HySparse2 的对照基线即其采用的混合滑窗注意力方案）。

小米 MiMo-V3 的应用场景与适用人群

该模型面向上下文持续增长的任务，常见场景包括：

• 长程智能体交互：多轮工具调用中反复读入长观测结果，预填充与缓存开销决定单轮延迟。
• 代码仓库理解与改动：在长代码上下文里定位跨文件依赖，token 级稀疏选择有利于检索关键片段。
• 长文档与资料处理：面向百万 token 级上下文做摘要、比对与问答，缓存占用缩小后单卡可承载更长会话。
• 智能体训练与评测：需要长上下文环境与批量并行沙箱，可与前代开源版本配合搭建训练链路。
• 多轮办公与客服助手：对话上下文长期累积，近期 Token 强制窗口有助于保持对最新指令的响应。

适用人群：研究长上下文与智能体推理的模型团队、需要在百万 token 级上下文上构建应用的工程团队，以及希望在开源模型上评估稀疏注意力收益的开发者。由于模型尚未发布，现阶段更适合作为技术选型参考而非生产依赖。

小米 MiMo-V3 的使用方法

模型尚未发布，现阶段从架构评估入手更有效率：

1. 查阅官方论文：在 HySparse2 官方技术论文 中查看两级 KV 共享的设计细节与 80B-A3B MoE 模型上的验证结果。
2. 对照前代规格：先了解 Xiaomi MiMo-V2.6 的参数规模、上下文窗口与开源许可，建立能力基线。
3. 评估上下文需求：按任务的实际长度判断是否需要百万 token 级窗口，避免为长窗口付出不必要的显存与延迟成本。
4. 复现检索效果：用自有长文档与多轮任务核对关键信息召回表现，重点关注长上下文后段的检索准确率。
5. 跟踪发布节奏：模型尚未发布，可关注小米 MiMo 团队的后续公告与开源仓库更新。

评估阶段建议把预填充耗时与 KV 缓存占用列为可观测指标；这两项是稀疏注意力方案的主要收益来源，也决定单位硬件能承载的并发会话数。

小米 MiMo-V3 的价格与开源情况

小米 MiMo-V3 的价格与开源计划尚未公布，官方当前公开的是 HySparse2 的架构设计与论文数据，模型本体、权重与 API 均未对外提供。需要立刻使用的团队，应优先评估已发布的开源或商用模型。

上一代 Xiaomi MiMo-V2.6 采用 MIT 许可并已在 Hugging Face 开放权重，Pro 与 Flash 两个版本均可自行部署，这也是判断 MiMo 系列开源惯性的主要依据。若 MiMo-V3 沿用同一路线，其权重有望在发布后开放；在此之前，HySparse2 的设计可直接借鉴到自研的长上下文模型上。

小米 MiMo-V3 的常见问题