★ FEATURED ARTICLE 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倍长上下文质量实测最高评估到256K100万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点击可查看大图。指标HySparse2HySparseHybrid SWA100万Token预填充FLOPs基准约2.92倍约5.02倍100万Token KV CacheFP82.69GB6.72GB12.09GB256K RULER-v258.4532.6135.74百万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.69GBHySparse为6.72GBHybrid SWA为12.09GB。HySparse2为什么适合AI AgentAgent会不断接收长网页、代码和日志。HySparse2减少长输入预填充成本并通过Token级选择提高跨多轮历史寻找关键证据的精度。
阅读完成 · 觉得有帮助？
