小米 MiMo-V3 押注 HySparse 2：百万上下文预填充降 5 倍

小米正在为下一代 MiMo-V3 换一套专门面向 Agent 的注意力架构。

9 月 23 日，小米 MiMo 大模型负责人罗福莉宣布，MiMo-V3 将采用全新架构，其核心组件 HySparse 2 已于今日发布。按照小米公布的数据，在 100 万 Token 的长上下文场景下，HySparse 2 可将预填充计算量降低 5.02 倍，将 KV Cache 缩小 4.5 倍，同时在 MRCRv2、RULER-v2 等长上下文检索评测中取得更高分数，AgentPPL 和 LongPPL 则进一步降低。

这不是一次简单的推理加速更新，而是小米对下一代 Agent 工作负载的一次架构押注。过去的长上下文优化，通常围绕“如何让模型读得更长”展开；HySparse 2 关注的则是另一个更现实的问题：当 Agent 连续工作几十轮、每一轮都产生新的观察结果时，模型如何既记住足够多的信息，又不被预填充成本和 KV 缓存拖垮。

一句话看懂：HySparse 2 是什么

HySparse 2 是一种面向超长上下文和 Agent 推理的混合稀疏注意力架构，它通过少量全注意力层负责建立全局信息与 KV 缓存，再让后续稀疏层复用这些结果，从而减少重复计算和显存占用。

传统 Full Attention 的问题在于，序列越长，计算和缓存成本越容易失控。模型处理 1 万 Token 时，成本或许还在可接受范围内；但当上下文扩展到 100 万 Token，任何一层都对全部 Token 做注意力计算，就像每次查资料都把整座图书馆的所有书重新翻一遍。即使硬件能够承受，服务端的吞吐、延迟和显存成本也会迅速恶化。

稀疏注意力的思路，是让模型只关注一部分 Token。问题是，稀疏得太激进，模型可能错过埋在长文档深处的关键信息。HySparse 的核心价值，正是在“全局可见性”和“稀疏计算”之间做折中：不是让所有层都完整扫描上下文，而是保留少量承担全局信息汇总的 Full Attention 层，再将重要 Token 的选择结果和 KV 信息传递给后续稀疏层。

小米在此前的 HySparse 工作中已经展示过这套方向的潜力。在一个 80B-A3B MoE 模型实验中，模型总共 49 层，仅保留 5 层 Full Attention，其余层采用稀疏注意力；在保持长距离信息访问能力的同时，KV Cache 存储开销接近降低 10 倍。HySparse 2 则进一步把优化目标从“减少缓存”推进到“减少百万上下文预填充”。

最大变化：预填充不必等到所有层都完成

预填充是长上下文推理中最容易被低估的成本。

预填充，或 Prefill，是模型首次读取用户输入、历史对话、工具返回结果和文档内容，并建立中间状态的过程。对于普通问答，输入可能只有几百到几千 Token；但对于 Agent，一次工具调用可能返回数十万 Token 的网页、代码库、数据库结果或执行日志，这时预填充就会成为首要瓶颈。

小米此次给出的关键数据是，在 1M Token 长度下，HySparse 2 的预填充计算量降低 5.02 倍。换句话说，在相同硬件和实现条件下，原本需要完成一大段全量上下文计算的任务，理论上可以用约五分之一的 FLOPs 达到接近的处理目标。

更重要的是，HySparse 2 不是单纯删掉计算，而是重新安排了不同层之间的信息流。小米介绍称，由于交叉解码器中的 KV Cache 现在全部来自自解码器，预填充过程在自解码器完成时即可停止。这意味着系统不必等待所有交叉解码器层完成完整的上下文预填充，部分计算可以直接被省略。

这对 Agent 尤其重要。一个典型的 Agent 任务往往不是“输入一次、输出一次”，而是“思考—调用工具—读取结果—继续思考”的循环。每轮循环都可能把新的长文本观察结果追加到上下文中。如果每次追加内容都必须让所有层重新完成全量预填充，模型的响应延迟会随着轮数不断累积。HySparse 2 的目标，是让新增信息只触发必要的计算，而不是把整个上下文再处理一遍。

KV 缓存缩小 4.5 倍，意义不只是省显存

KV Cache 是长上下文推理的核心缓存机制，也是服务商最头疼的显存开销之一。

KV Cache 是模型在处理上下文时保存的 Key 和 Value 中间状态，生成后续 Token 时可以直接复用这些状态，避免重复计算历史内容。它让连续生成变得高效，但缓存大小会随着上下文长度、层数、并发请求数同步增长。

在 1M Token 长度下，HySparse 2 将 KV Cache 缩小 4.5 倍。这个数字直接影响的不只是单个请求的显存占用，也影响同一台服务器能同时服务多少个长上下文请求。

假设一个 Full Attention 模型在特定配置下需要为某个百万 Token 请求保留 400 GB 的 KV Cache，那么缩小 4.5 倍后，理论上可能降至约 89 GB。实际数值还会受到模型层数、隐藏维度、KV 头数量、数据类型和并行策略影响，但方向非常明确：在相同显存下，服务端可以容纳更多并发请求；在相同并发量下，则可以使用更少的 GPU。

对于企业用户，这种变化比单纯的单请求延迟下降更有价值。长上下文 Agent 的成本往往由显存占用、批处理效率和请求并发共同决定。KV Cache 过大时，服务端很难把多个长请求放进同一个 Batch，GPU 也可能因为缓存碎片和动态扩容而无法保持高利用率。缓存缩小后，系统更容易进行连续批处理和请求复用。

不过，KV Cache 缩小并不等于上下文能力自动提升。真正难的是，压缩缓存之后仍要保留正确的信息。只要稀疏选择错过了关键 Token，模型就可能在后续推理中出现“看过但想不起来”的问题。因此，HySparse 2 把长上下文检索准确率放在与效率同等重要的位置。

四个技术变化：KV 桥接、KV 重用与 Token 级选择

HySparse 2 的第一个关键机制是 KV Bridging，也就是 KV 桥接。

KV 桥接沿用了 YOCO 类架构的思路：交叉解码器中的全注意力层，不再独立从原始输入构建 K/V，而是利用自解码器产生的隐藏状态构建自己的 Key 和 Value。这样做的结果，是不同模块之间可以共享已经提取出的上下文信息，减少重复的全量计算。

HySparse 2 的第二个关键机制是 KV Reuse，也就是 KV 重用。

在每个混合块内部，稀疏层会复用前一层全注意力层生成的 KV Cache 和 Token 选择索引。传统做法往往需要每一层重新判断哪些 Token 重要，而 KV 重用把这种判断结果向后传递。模型不必在每层都重新做一次“全局搜索”，后续稀疏层可以直接沿用前面已经建立的注意力路由。

HySparse 2 的第三个变化是从 Block 级选择切换到 Token 级选择。

Block 级稀疏通常以固定大小的 Token 块为单位进行筛选，工程实现相对简单，但粒度较粗。如果一个块里只有少数几个 Token 重要，系统仍然可能被迫保留整个块。Token 级选择则可以更精确地保留真正有用的信息，减少无效上下文进入后续计算。

Token 级选择也会带来更高的索引管理复杂度。系统需要维护更细粒度的选择结果，硬件访存和算子融合也更难设计。因此，这一变化能否在真实推理服务中转化为稳定收益，取决于小米后续的 CUDA Kernel、编译器和推理框架实现，而不只是论文中的 FLOPs 数字。

HySparse 2 的第四个变化，是用近期 Token 的强制窗口替代独立的 Sliding Window Attention 分支。

近期 Token 强制窗口，是指无论全局选择结果如何，模型都会保留一段最近生成或最近输入的 Token，避免局部连续信息被稀疏机制丢弃。小米表示，这一设计让本地 Token 和全局 Token 可以共享同一个 KV Cache，而不再需要维护一套独立的 SWA 分支。

这套设计的工程价值很明显：缓存结构更统一，索引路径更简单，也更适合长序列中的动态更新。对于 Agent 来说，最近一轮工具返回结果通常具有很高价值，强制保留近期窗口可以降低模型在局部上下文中“断片”的风险；而全局稀疏路径则负责从更早的历史中找回关键事实。

为什么 Agent 工作负载更需要这套架构

Agent 推理是一种“短动作、长观察、持续增长上下文”的工作负载。

普通聊天模型的上下文通常由用户问题和几轮对话组成，输入增长相对缓慢。但 Agent 在执行任务时，一次简短动作可能触发一个很长的观察结果。例如，模型只输出“搜索相关文档”，工具却返回几十页网页内容；模型只调用一次代码执行器，结果可能包含完整日志、堆栈信息和测试报告。

这会形成一个特殊的计算模式：动作很短，观察很长；输出很短，输入很重；每次工具调用之后，上下文都在增长。模型真正需要优化的，不只是生成阶段的 Decode 速度，而是每轮新观察结果进入上下文后的 Prefill 成本。

罗福莉表示，Agentic 推理是一种截然不同的工作负载，每一轮交互中，一个简短动作可能返回需要预填充的长文本观察结果，同时上下文还在不断增长。因此，预填充成本、KV Cache 大小和检索准确率会同时处于关键路径上。

这也是 HySparse 2 与传统长上下文方案的区别。传统方案可能优先追求更大的上下文窗口，或者通过量化、分页缓存和 Prefix Cache 降低成本；HySparse 2 则从注意力结构本身入手，试图让模型只为真正重要的 Token 支付计算和缓存成本。

从产品角度看，如果这套架构能够稳定落地，它更适合以下几类任务：

• 代码 Agent： 长时间读取代码仓库、构建日志、测试结果和历史修改记录。
• 研究型 Agent： 连续浏览大量网页、论文、报告，并反复回溯早期证据。
• 企业知识库 Agent： 在长文档、会议记录和数据库结果之间建立跨轮次关联。
• 浏览器与操作系统 Agent： 每次操作都可能返回结构化页面状态、截图描述和工具执行日志。
• 多步自动化任务： 上下文不会因为一次回答结束而清空，而是随着任务状态不断累积。

MRCRv2、RULER-v2 更高，但还不能等同于全面领先

小米称，HySparse 2 在 MRCRv2 和 RULER-v2 上取得更高分数，同时 AgentPPL 和 LongPPL 更低。

MRCRv2 是面向长上下文检索与复制能力的评测，重点考察模型能否在超长输入中找到并复现相关信息。RULER-v2 则是一组长上下文能力测试，覆盖关键信息检索、聚合、推理等不同任务。AgentPPL 和 LongPPL 通常用于衡量模型在 Agent 或长上下文场景中的困惑度表现，数值越低往往意味着模型对相关序列的建模更稳定。

这些指标说明，HySparse 2 并非只追求“算得更少”，至少在小米公布的实验中，稀疏计算没有明显牺牲长上下文信息访问能力。尤其是 MRCRv2 和 RULER-v2 同时提升，意味着它可能不仅能保留局部信息，也能维持跨长距离的检索路径。

但需要注意的是，目前小米公开的信息主要是架构预告和指标方向，尚未披露 MiMo-V3 的参数规模、模型类型、训练数据、完整评测表、推理硬件、Batch 配置以及 HySparse 2 与 Full Attention 基线的具体吞吐对比。因此，5.02 倍 FLOPs 降低并不能直接换算成 5.02 倍端到端速度提升。

实际服务效果还会受到稀疏算子利用率、GPU 内存带宽、请求长度分布、并发量、通信开销和调度策略影响。理论计算量下降，可能在低并发或短上下文场景中难以完全兑现；但在百万 Token、长链路、多轮 Agent 任务中，收益更有可能显现。

HySparse 2 与此前 HySparse 的关系

HySparse 2 更像是对原有混合稀疏路线的一次系统升级，而不是完全另起炉灶。

此前的 HySparse 采用“少量 Full Attention 层 + 多层 Sparse Attention 层”的混合结构。Full Attention 层负责提供全局信息访问和 Token 选择，Sparse Attention 层则使用全局稀疏与局部窗口相结合的方式，减少每层需要处理的内容。

在 80B MoE 实验中，HySparse 仅保留 49 层中的 5 层 Full Attention，仍能在部分任务上超过 Full Attention 基线。这一结果的重要性在于，稀疏注意力不再只是“能力打折后的低成本版本”，只要全局稀疏通路设计得当，它也可能帮助模型减少无关信息干扰。

HySparse 2 的推进方向更加明确：进一步降低预填充计算、统一 KV Cache、减少跨模块重复处理，并让长上下文能力更贴近 Agent 的实际交互模式。相比此前重点展示 KV Cache 降低，HySparse 2 把 Prefill、Cache 和 Retrieval 三个指标放到同一个系统目标中。

这也是小米目前在大模型基础设施上的一个鲜明判断：未来的竞争不只在参数规模和基准分数，还在于谁能让模型以更低成本持续运行更长时间。对于 Agent 来说，模型每多完成一轮工具调用，背后就多出一轮上下文处理；架构能否控制这笔“隐形账单”，会直接决定产品能不能规模化。

MiMo-V3 之前，小米刚发布 MiMo-V2.6

HySparse 2 的发布，紧接在小米 MiMo-V2.6 系列开源之后。

9 月 22 日凌晨，小米发布并开源 MiMo-V2.6 系列，包含 Pro 与 Flash 两个原生全模态模型。小米将这一系列定位为探索 RSI，也就是递归自我改进路径的重要一步，试图通过规模化扩展强化学习算力，让模型在持续探索和反馈中提升能力。

从产品节奏看，小米正在同时推进两条路线：一条是通过 MiMo-V2.6 等模型扩大多模态和强化学习能力，另一条是通过 HySparse 2 这类底层架构降低长上下文 Agent 的推理成本。前者决定模型“会不会做更多事情”，后者决定模型“能不能长期、低成本地把事情做完”。

MiMo-V3 是否会延续 MiMo-V2.6 的全模态能力，目前尚未公布；HySparse 2 将应用于多大规模的模型，也没有公开答案。小米只表示，后续将继续在更大规模模型上验证 HySparse 的极限和潜力，并探索进一步减少 Full Attention 层数量的可能性。

OpenAI Hub 判断：方向比参数更值得关注

HySparse 2 最值得关注的地方，不是“5.02 倍”这个单独数字，而是它把长上下文优化的重心从窗口长度转向了 Agent 的真实计算路径。

过去一年，行业不断把上下文窗口从 128K 推向 256K、1M 甚至更高，但窗口变大不等于任务成本变低。对于 Agent，真正的问题是每一轮工具调用之后，系统是否必须重新支付整段上下文的处理成本，以及服务器是否有足够显存同时承载大量长请求。

小米给出的方案是：用少量全注意力层建立全局信息，用 Token 级稀疏选择筛掉大部分无关内容，用 KV 桥接和 KV 重用减少重复处理，再用近期 Token 窗口保住局部连续性。如果这些机制能在真实推理引擎中兑现，HySparse 2 可能成为 MiMo-V3 的核心竞争力，而不是论文中的附加组件。

但它能否真正改变市场，还要看三个后续信息：第一，MiMo-V3 的完整能力和参数配置；第二，HySparse 2 在公开硬件上的端到端延迟、吞吐和显存数据；第三，模型在代码 Agent、浏览器 Agent 和长文档问答中的实际错误率。

目前可以确认的是，小米已经把下一代模型的关键问题定义得很清楚：百万 Token 不是终点，能否让 Agent 在百万 Token 上下文里持续工作，才是下一阶段的竞争焦点。MiMo-V3 还没有正式发布，但 HySparse 2 已经提前透露了它的技术路线——少做无效计算，少存无关信息，同时尽量不牺牲模型找到远处关键信息的能力。

关键数据一览

| 项目 | HySparse 2 公布信息 | 影响 | |---|---:|---| | 测试上下文长度 | 1M Token | 面向百万级长上下文场景 | | 预填充计算量 | 降低 5.02 倍 | 减少长输入首次处理成本 | | KV Cache | 缩小 4.5 倍 | 降低显存占用，提高并发潜力 | | 长上下文检索 | MRCRv2、RULER-v2 得分更高 | 强化远距离信息访问能力 | | Agent 长上下文建模 | AgentPPL、LongPPL 更低 | 改善 Agent 场景下的序列建模稳定性 | | 主要机制 | KV Bridging、KV Reuse、Token 级选择、近期 Token 强制窗口 | 减少重复计算并统一缓存路径 |

参考来源

1. IT之家：罗福莉官宣小米 MiMo-V3 采用全新架构，核心 HySparse 2 今日发布 —— 小米 MiMo-V3、HySparse 2 以及核心性能数据的主要来源。
2. IT之家：MiMo-V2.6 系列相关报道 —— 小米 MiMo-V2.6 Pro 与 Flash 系列发布背景，具体页面以 IT之家站内信息为准。
3. 量子位：小米给 KV Cache 减负 80%，MiMo 团队推出混合稀疏注意力架构 —— HySparse 早期架构思路、Full Attention 层配置及长上下文实验背景。该链接为补充技术资料，因站点不在本次指定可访问域名范围内，正文不作为主要引用链接展示。