企业官网建设流程全解析

HySparse2把模型拆成前后两段，用两级KV共享和Token级稀疏选择减少长输入计算；但MiMo-V3尚未发布，5.02倍指计算量，不是实测速度。

**先说预测：**MiMo-V3真正值得关注的，可能不是榜单上多涨几个点，而是它准备把Agent最昂贵、最容易被忽视的一段成本砍下来：反复读取工具返回的长网页、代码、文档和执行日志。

小米LLM-Core团队公开了HySparse2论文，团队成员罗福莉也明确表示，MiMo-V3正在采用以HySparse2为核心的新架构。论文中的模型还不是已经上线的MiMo-V3产品，但技术方向已经相当清楚：更少的预填充计算、更小的KV Cache，以及更准确的长历史检索。

小米LLM-Core团队成员罗福莉公开确认：MiMo-V3将采用以HySparse2为核心的新架构。 图片已压缩为WebP，点击可查看大图。

HySparse2的目标是同时降低预填充计算、缩小KV Cache并提升长上下文检索。 图片已压缩为WebP，点击可查看大图。

先划重点：MiMo-V3目前尚未正式发布。论文中的5.02倍是80B-A3B实验模型在100万Token时，相对Hybrid SWA的预填充FLOPs下降，不是端到端响应速度提升5.02倍；长上下文质量实测最高评估到256K，100万Token对应的是计算量与缓存分析。

01 / Agent为什么会被“读材料”拖慢？

一个编码Agent修Bug时，可能只生成几十个Token的指令：读取文件、执行测试、修改代码。但工具返回的源文件、搜索结果和报错日志，动辄几千甚至几万Token。每轮新材料进入上下文后，模型都要先处理输入、建立后续生成所需的KV Cache，再决定下一步。

Agent任务的典型结构：模型输出短指令，工具却返回长网页、代码和运行日志。 图片已压缩为WebP，点击可查看大图。

这个处理输入的阶段叫预填充（Prefill）。在长时间、多轮Agent任务中，生成动作很短，工具观察很长，成本会越来越由预填充主导。与此同时，模型还不能简单丢掉旧内容，因为第20轮需要的线索可能藏在第2轮日志里。

所以问题变成了三件互相拉扯的事：输入要少算、历史要少占显存、关键线索还必须找得准。HySparse2就是针对这三个目标设计的。

02 / HySparse2最关键的一刀：预填充只跑前半段

HySparse2把模型骨干拆成Self-Decoder和Cross-Decoder两段。前段混合全注意力与滑动窗口注意力，负责处理当前输入；后段混合全注意力与稀疏注意力，负责更广范围的历史检索与最终生成。

HySparse2架构：Self-Decoder、Cross-Decoder、KV Bridging与KV Reuse。 图片已压缩为WebP，点击可查看大图。

两段之间由KV Bridging连接：Cross-Decoder中的全注意力层，不再要求长输入完整跑过后半段才能得到缓存，而是从Self-Decoder对应层的隐藏状态重新投影出K和V。Cross-Decoder内部再通过KV Reuse，让后续稀疏层复用全注意力层的KV Cache和选择位置。

结果是，一批很长的新材料到来时，预填充走完Self-Decoder就能提前退出，不必把全部输入继续逐层送进Cross-Decoder。模型开始生成新Token时，后半段仍正常工作，能力没有被简单“砍掉一半”。

论文给出的49层配置中，预填充节点只需要部署前25层和相关投影模块，模型内存需求接近减半；预填充阶段真正执行全注意力的只有一层。

03 / 从按“块”找线索，改成按单个Token找

上一代HySparse按64 Token的块选择历史。如果一个块里只有一个词有用，剩余63个位置仍然会占用有限的注意力预算。面对多轮Agent轨迹，关键证据往往分散在不同工具返回中，这种浪费会直接影响检索精度。

Token级选择能把有限注意力预算分配给分散在历史中的关键位置。 图片已压缩为WebP，点击可查看大图。

HySparse2改为Token级选择。论文的消融实验在相同骨干和注意力预算下选择1024个全局Token，并保留最近128个Token作为局部窗口。这样既能抓住远处零散线索，也不会漏掉刚返回的工具结果。

在32K及以下的预训练长上下文测试中，Token级选择相对块级选择让RULER-v2提高6.57个百分点，双线索MRCR-v2提高8.14个百分点，GraphWalks提高5.55个百分点。

04 / 为什么还要保留少量全注意力？

HySparse2并没有把全注意力全部删除。团队认为，少量全注意力层一方面维持模型质量，另一方面能用完整注意力分数，为后续稀疏层提供“应该看哪些Token”的选择结果。

这相当于让少数层做全局侦察，再让大量稀疏层只处理最值得看的位置。它不需要额外训练独立检索器，但全注意力本身仍然昂贵，所以架构将其比例控制得很低。

05 / 数据到底有多夸张？5.02倍应该这样读

80B-A3B模型在不同上下文长度下的预填充计算量与KV Cache比较。 图片已压缩为WebP，点击可查看大图。

百万Token、FP8缓存条件下的计算量与KV Cache分析结果。 图片已压缩为WebP，点击可查看大图。

**对产品用户最重要的解释：**FLOPs下降不等于延迟按相同比例下降。真实速度还取决于稀疏算子效率、显存带宽、并行调度、输入长度、服务负载、网络和推测解码。它首先证明的是架构上“少算了很多”，并不直接承诺网页端快5倍。

06 / 长上下文质量没有被省掉，反而更强

HySparse2、HySparse与Hybrid SWA在长上下文检索和Agent轨迹上的比较。 图片已压缩为WebP，点击可查看大图。

团队使用相同数据和训练安排，对比HySparse2、HySparse和MiMo-V2系列采用的Hybrid SWA。预训练后的通识、推理和代码成绩有升有降，整体大致可比；最明显的优势集中在长上下文检索。

经过约100B Token的轻量后训练后，HySparse2在论文评估的各个上下文长度上领先两个对照架构。按测试长度平均，MRCR-v2和RULER-v2相对HySparse分别提高11.30和19.81个百分点；同时AgentPPL和LongPPL更低。

这比“缓存变小”更重要。Agent真正需要的不是把一百万Token机械塞进去，而是在大量无关日志之间，把早期决策、文件路径、报错线索和用户约束准确接回当前任务。

07 / 对开发者和普通用户意味着什么？

• **更长的编码任务：**Agent可以保留更多文件、测试日志和操作历史，减少过早压缩导致的信息丢失。
• **更低的长输入成本：**若部署端能把理论计算优势转化为高效内核，处理大型仓库和长文档会更经济。
• **更高的并发空间：**KV Cache更小，同等显存有机会承载更多会话或更长上下文。
• **更稳定的历史检索：**Token级选择更适合从多轮工具轨迹中寻找分散证据。

但现在还不能在API里选择“MiMo-V3”。这篇论文描述的是架构与实验模型，最终产品的参数规模、价格、上下文上限、速度、工具能力和上线时间仍需等待小米正式公告。

08 / 我们的观点：Agent模型正在从“会不会做”转向“能不能一直做”

早期Agent竞争看的是单轮推理和工具调用；现在任务一长，系统瓶颈迅速变成输入处理、缓存、检索和状态管理。模型可以生成漂亮代码，却可能在第30轮忘记第3轮的约束，也可能把大部分算力浪费在反复读取日志上。

HySparse2的方向很务实：不只是扩大上下文窗口数字，而是重新设计长历史如何进入模型、如何保存、如何被找到。若MiMo-V3能把论文中的计算优势转化为稳定的线上吞吐和真实Agent成功率，它可能比单纯刷榜更有产品价值。

现阶段最合理的态度是：架构值得期待，模型仍需等正式发布；计算量数据可信，实际速度不要提前脑补。

常见问题（FAQ）

小米MiMo-V3已经发布了吗？

尚未正式发布。小米团队已公开HySparse2论文，并确认MiMo-V3将采用以该技术为核心的新架构，但产品规格、价格和上线时间仍需等待官方公告。

HySparse2是什么？

HySparse2是一种面向长上下文和多轮Agent任务的混合稀疏注意力架构，通过KV Bridging、KV Reuse、Token级选择和预填充提前退出降低计算与缓存开销。

5.02倍提升代表MiMo-V3速度快5倍吗？

不代表。5.02倍指80B-A3B实验模型在100万Token下，相对Hybrid SWA的预填充FLOPs减少比例。端到端速度还受硬件、内核、调度和网络等因素影响。

HySparse2的KV Cache有多大？

论文分析中，在100万Token和FP8缓存条件下，HySparse2为2.69GB，HySparse为6.72GB，Hybrid SWA为12.09GB。

HySparse2为什么适合AI Agent？

Agent会不断接收长网页、代码和日志。HySparse2减少长输入预填充成本，并通过Token级选择提高跨多轮历史寻找关键证据的精度。