小米罗福莉：MiMo-V2.5如何做到又快又强又便宜？ | ICML 2026|icml|mimo|top|上下文|大模型|算法|罗福莉

当所有人都在卷参数，MiMo选择了另外两个被忽视的智能维度——上下文长度与推理速度。

作者丨陈淑瑜

编辑丨岑峰

2026年7月，机器学习领域的顶级学术会议ICML（International Conference on Machine Learning）正式召开。大会首日，小米MiMo团队负责人罗福莉（Fuli Luo）发表了题为“MiMo-V2.5 Series: Efficient Intelligence via Architecture–Training–Inference Co-Design”的主题演讲。

这场演讲直击当前大模型领域的核心痛点：强大的推理能力往往依赖更长的注意力机制、更多的计算资源和庞大的KV缓存，而效率则要求极力压缩计算与存储空间，两者在传统架构下天然互斥。

面对这一挑战，MiMo团队选择跳出单纯调和矛盾的固有思路，转而从架构、训练、推理三个技术栈层面展开端到端的协同设计。

罗福莉系统性地展示了MiMo-V2.5系列如何在这三个层面的创新中，将"聪明、快速、便宜"这三个看似不可兼得的目标同时收入囊中。

▎预训练：用极致稀疏架构砍掉 70% 成本

针对长文本导致的算力与显存暴涨，MiMo 进行了两代架构演进：

MiMo-V2.5引入“混合滑动窗口注意力”（Hybrid Sliding Window Attention）机制，凭借 7:1 的极端稀疏比、仅 128 token 的超小窗口和可学习的注意力沉没值（Attention Sink），成功将算力消耗（FLOPs）和 KV 缓存压缩了 7 倍。
下一代 MiMo-V3则推出“High Sparse（高维稀疏）”架构，将稀疏比推至 11:1 的极限。它直接让少量的全局全注意力层充当“先知（Oracle）”，为后续稀疏层筛选关键 token 并跨层共享 KV 缓存。

实验表明，在 11:1 的极端稀疏下，传统方案会导致 MMLU 得分暴跌 7 分，而 High Sparse 却能在所有基准测试中匹配甚至超越全注意力模型。罗福莉指出，不少于 3 层的全注意力层是长上下文的“定海神针”，在此基础上，稀疏比仍能通过精细化工程继续推高。

▎后训练：无损融合专家能力，驯服 MoE 强化学习

在对齐阶段，MiMo 贡献了两项已被行业广泛采纳的硬核算法：

MOPD（多教师在线策略蒸馏）：通过“教师与学生 log 概率相减”的极简公式，实现了数学、代码等多个领域专家模型能力向单个学生模型的无损融合，摒弃了传统参数合并或级联 RL 的繁琐流程，有效避免了能力折损。
R3（Rollout Routing Replay，推理路由回放）：针对 MoE 架构在强化学习（RL）训练时极易崩溃的痛点，团队挖出根因：训练与推理引擎在同一采样（rollout）中存在约 10% 的专家路由决策分歧。

R3 巧妙地在训练前向传播时强制回放推理侧的专家选择（Top-k Mask），固定路径的同时保持路由器动态更新。

该方法让 KL 散度差距降至 Dense（稠密）模型水平，实现了训练全程零崩溃。

▎推理加速：万亿参数大模型跑出 1000 TPS

团队成员曹士杰展示了 Ultra Speed 的上线数据。万亿参数模型在通用GPU上实现1000 TPS的token生成速度，背后是dFlash推测解码、FP4量化、基于上下文长度的bucket分配策略等一系列系统工程优化。

该服务上线仅一个月便吸引了超 10 万用户申请，在金融、医疗等行业需求旺盛。

曹士杰特别分享了一个令团队深受触动的场景：在手术中，AI快几秒检测到风险或辅助医生做出关键决策，可能挽救一个病人的生命——速度不仅仅是基准测试的分数。

总而言之，MiMo-V2.5 的核心方法论在于打破割裂优化的传统思维。架构的选择决定了推理的底线与价格优势，而训练的创新又反哺了架构的稳定性。

这种“三位一体”的系统级协同，正是 MiMo 在当前大模型价格战中持续保持核心竞争力的根本原因。

以下为罗福莉 and 曹士杰在ICML 2026大会上的演讲精编，雷峰网&AI科技评论在不改变原意的前提下，基于原英文演讲内容进行了编译整理：

超越参数竞赛：MiMo的三维智能观

罗福莉：大家早上好，我是罗福莉，MiMo团队的负责人。很高兴来到ICML大会。今天我将主要介绍MiMo-V2.5系列，以及我们如何在架构、训练和推理三个层面进行协同设计。这次演讲探讨的核心问题其实很简单：我们如何构建一个既聪明、又快、又便宜的大模型？

在接下来的30分钟里，我将向大家展示我们在技术栈的这三个层面是如何落地这一目标的。在此期间，我也会毫无保留地分享哪些方法踩了坑、哪些方法真正见效，以及我们学到了什么。在进入技术细节之前，我想先分享一个支撑MiMo所有研发工作的核心理念。“扩展参数规模”这件事大家都在做，但我们关注的是智能的另外两个维度，这两个维度受到的关注要少得多。第一个维度是上下文长度。我们从256K做到了100万token。而真正的目标，是无限上下文。

为了达到这一目标，我们主要做了两件事：

模型、基础设施与推理框架的协同设计：我们从混合滑动窗口注意力（Hybrid Sliding Window Attention）演化出混合稀疏注意力（Hybrid Sparse Attention）等上下文高效架构，这是我们能够不断降低API价格的核心底气。
vLLM（我们的开源推理框架）中的上下文管理：我们设计了无损上下文管理和持久化记忆系统。

第二个维度是推理速度。我们在万亿参数规模、普通GPU上，将生成速度从每秒100 token提升到了1000 token。速度之所以至关重要，是因为在多智能体（Multi-Agent）系统中，更快的上下文切换意味着更高效的协同创新；同时在模型训练中，更快的rollout速度也意味着模型能更迅速地收敛。

接下来看看MiMo在过去六个月取得的阶段性成果。

今年三月，我们发布了MiMo-V2系列，其中包含拥有万亿参数和100万token上下文的MiMo-V2 Pro，并首次通过SiliconFlow Hunter Alpha平台进行对外服务。自API降价以来，MiMo-V2.5在调用量上一直稳居前两名。这验证了一个事实：开发者最终会倾向于选择高性价比且快速的模型。

在Artificial Analysis Intelligence Index的最新排名中，MiMo-V2.5 Pro的综合表现已与Kimi K2.6和DeepSeek V4处于同一梯队。

那么，我们究竟是如何实现“兼顾高速度与强能力的长上下文智能”的？我们主要在以下三个方向做出了技术突破。

1. 预训练层面：在MiMo-V2中，我们采用了混合滑动窗口注意力机制。通过7:1的极端稀疏比、仅128 token的微型滑动窗口，并结合可学习的注意力sink偏置，确保了小窗口的高效运转。在MiMo-V3中，我们进一步升级为自主研发的High Sparse（混合稀疏注意力）结构，将稀疏比推向了11:1，由全注意力层为稀疏层筛选关键token并共享KV缓存。

2. 后训练层面：为了进一步扩展计算规模，我们提出了两种全新方法。MOPD（Multi-teacher On-Policy Distillation）通过在线策略蒸馏，将多个领域教师模型的能力完美合并到一个学生模型中。我们在去年完成了该方法的大规模落地验证，目前它已成为行业通行做法。另一项早期工作R3（Rollout Routing Replay）则通过在训练期间回放推理引擎的路由选择，彻底解决了MoE强化学习训练不稳定的难题。

3. 推理层面：我们构建了一套专面向滑动窗口注意力机制的推理管线，并通过FP4量化和dFlash将生成速度推向了每秒1000 token的里程碑。

下面，我将逐一详细介绍这三个方向的技术细节。

预训练：从混合滑动窗口到High Sparse

首先从预训练讲起，我将重点剖析注意力骨干架构的设计演进：即如何从MiMo-V2的混合滑动窗口注意力，升级为MiMo-V3的High Sparse（高维稀疏）。

混合滑动窗口注意力的结构非常简洁：它由若干层滑动窗口注意力层与一层全局注意力层交替穿插构成。如图所示，该结构顶部还包含了三层MTP（Multi-Token Prediction）。尽管128 token的窗口通常显得捉襟见肘，但我们通过两项核心设计打破了这一限制：一是引入了可学习的注意力sink偏置参数，二是采用了极端的稀疏比。

在具体的参数设置上，万亿参数的MiMo-V2.5 Pro与3000亿参数的MiMo-V2.5有所不同。Pro版本中仅有10%的层使用全注意力（48层中的5层），而MiMo-V2.5则在48层中保留了9层。另一个区别在于KV头数：Pro版本拥有8个KV头并全面采用GQA（Grouped Query Attention）；而MiMo-V2.5在全局层使用8个KV头，在滑动窗口层则缩减为4个。其余如MoE设置、100万上下文支持以及三层MTP等配置，两者基本保持一致。

这种高度稀疏化设计带来了显著的性能收益。上图对比了在100万上下文环境下，全注意力和混合滑动窗口注意力的表现：后者成功将注意力FLOPs和KV缓存降低了7倍，且序列越长，其优势越明显。

下图展示了一个关键数据：在与DeepSeek、Gemini、Kimi、Qwen等前沿模型的KV缓存效率对比中，无论是预填充（prefill）还是解码（decode）阶段，MiMo的效率都高居第二，仅次于DeepSeek V3。在长上下文服务中，KV缓存直接决定了算力成本，这也解释了为什么我们的API价格能持续走低。

不过，混合滑动窗口注意力仍有其局限性。为此，我们在MiMo-V3中设计并采用了High Sparse（高维稀疏）架构。之所以推行这一新结构，是因为早期的稀疏注意力方法通常依赖额外的预测器来评估token重要性，这导致预填充阶段无法节省内存，且仍需保留完整的KV缓存。

High Sparse的核心思想在于直接复用全注意力层本身来选择重要token，并供后续所有稀疏层使用。在具体实现中，每个block包含一层全注意力层和后续的 $$$$ 层稀疏层。我们在800亿参数规模上，成功将稀疏比推到了1:11。

这一架构的成功运转主要归功于以下三项设计：

指令式选择：全注意力层的FlashAttention在运行中已经自然产生了block级别的注意力分数，我们直接复用这些分数进行token筛选，无需引入额外开销。
跨层KV共享：稀疏层不再维护独立的KV缓存，而是直接共享全注意力层的KV缓存，使内存占用大幅降低10倍。
Block级别的token选择：支持容量动态配置。

实验结果非常具有启发性。在绝大多数基准测试中，全注意力、混合滑动窗口注意力和High Sparse三者的表现极为接近，且High Sparse在很多任务中已经取得了最优结果。有趣的是，在1:11的极端稀疏比下，混合滑动窗口注意力会出现性能崩溃（其MMLU得分比全注意力低了约7个点），而High Sparse在所有基准测试上均能匹配甚至超越全注意力。需要强调的是，稀疏层通过共享全注意力层的KV缓存，节省了10倍的缓存空间。

因此，MiMo-V3明确了未来的技术方向：保留少量的全注意力层并将其KV缓存共享给其他所有层，在确保模型质量无损的同时，实现效率的最大化。

后训练：MOPD与R3--融合多教师能力，驯服MoE强化学习

高效的骨干架构必须配合强大的后训练算法，才能真正转化为模型能力。那么，我们该如何扩展计算规模？为此，我们提出了MOPD和R3两项工作。

在传统的后训练流程中，通常的做法是基于一个共享的SFT基座，并行训练各个领域的教师模型，最后再将它们进行整合。为了培养出数学、编程、安全和Agent等领域的顶级专家模型，我们也会在每个领域分别进行RL（强化学习）训练。然而，如何将这些专门化的领域能力无损地合并到单个模型中，一直是行业难题。我们曾尝试过参数共享、参数合并、在线策略微调、混合数据或级联RL等各种手段，但它们要么伴随着能力的折损，要么会带来训练不稳定的风险。

为了攻克这一瓶颈，我们提出了MOPD（多教师在线策略蒸馏）。MOPD最大的优势在于其极致的简洁性：通过“教师log概率减去学生log概率”进行逐token计算，能够直接嵌入到标准的PPO或GRPO框架中。这一设计具备三个结构性优势：

1. 密集的训练信号：由于信号直接来自各个专门化的教师模型，学生模型得以高保真地继承每个教师的核心能力。

2. 架构轻量化：训练过程中不需要额外的奖励模型（Reward Model）或价值网络（Value Network）。

3. 极强的扩展性：可以根据需求灵活接入任意数量的教师领域。

在MiMo-V2 Flash的后训练阶段，我们首次在开源模型中大规模落地了这一方法，如今它也逐渐演变为开源社区的通用做法。

第二项工作R3（推理路由回放）则源于我们此前在研发中遭遇的MoE训练易崩溃、不稳定的痛点。通过深入排查，我们锁定了问题的根因：在MoE架构中，面对同一个rollout，训练引擎和推理引擎在每层、每个token上会有约10%的路由决策不一致。这种底层路由的分歧会直接导致GRPO风格的训练走向崩溃。

R3的解决方案非常直接：在rollout阶段完整记录推理引擎的专家路由选择，并在后续的训练前向传播中强制回放相同的top-k mask。此时，门控权重仍然基于训练logits重新计算，从而确保梯度能正常流经路由器。我们固定的是专家的选择路径，而不是路由器本身。这些mask会与KV缓存一同进行缓存，因此对训练速度的影响微乎其微。

实验数据的散点图清晰地展示了R3的改进效果：图中每个点代表一个token，横轴和纵轴分别对应推理和训练概率。在没有引入R3时（红色点），数据点大量游离于对角线之外；而引入R3后（灰色点），数据点紧密贴合在对角线上。此时，KL散度差距被成功压低至Dense模型水平。从训练曲线来看，普通的GRPO在迭代到100步左右时就会因不一致性而崩溃，而使用R3的训练全程表现平稳。通过让训练阶段的专家选择与推理阶段完全对齐，R3让MoE的强化学习训练拥有了如同Dense模型一样的稳定性。

推理加速：万亿参数模型的1000 TPS突破

曹士杰：大家早上好，我是来自小米MiMo团队的曹士杰。今天非常高兴能在这里向大家介绍我们上个月正式发布的产品--MiMo-V2.5 Pro Ultra Speed。需要说明的是，这并不是一款全新训练的模型，它依然基于我们的万亿参数Pro模型，但我们在token生成速度上实现了重大突破：首次在通用GPU上，让万亿参数规模的模型跑出了每秒1000 token的骄人成绩。

接下来，我想重点聊聊速度对于大模型的重要意义、我们的技术实现路径，以及我们在生产环境部署中总结的实战经验。

为了让大家直观地感受Ultra Speed的威力，我们可以看一个测试案例：我让模型构建一个AI服务仪表盘，并给出了具体的功能和设计要求。Ultra Speed仅用时约12秒就完成了全部代码和设计输出，而传统的普通API服务完成相同任务通常需要耗时6分钟左右。关于这项技术，我想强调三点：

1. 硬件零门槛：这是一款万亿参数的大模型，全部运行在通用的常规GPU上，不需要任何定制化的特殊硬件。

2. 真正的生产级服务：这绝非实验室的demo展示，而是已经在线上稳定运行的生产级服务，所有用户均可接入，且Web端聊天完全免费。

3. 极高的商业性价比：相较于普通版本，其API价格仅微增3倍，但换来的却是10到20倍的生成速度提升。

在大模型服务中，吞吐量（Throughput）与用户交互性（Latency）之间往往需要进行权衡。在绝大多数高并发场景下，传统的API服务就像是城市公交车--单次可运载大量乘客，总体吞吐量很高，但每个乘客都必须接受更长的等待时间。然而，在许多追求极致生产力或处理紧急状况的场景中，每一秒的延迟都关乎成败。此时，我们更需要一辆救护车--它不需要一次性拉很多人，但必须以最快的速度抵达目的地。这正是Ultra Speed的研发定位。

Ultra Speed上线至今已近一个月，市场反馈令整个团队倍感振奋。上个月有超过10万名用户提交了申请，受限于GPU算力瓶颈，我们目前仅筛选批准了约3万名用户。即便在控流情况下，我们依然观察到Ultra Speed的用户留存率显著超越了标准服务。同时，来自企业侧的需求同样迫切，尤其是在金融、保险、教育以及医疗等行业。

在实际推广中，我们发现不同行业对“速度”的商业估值呈现出有趣的差异。对个人开发者而言，速度直接等同于生产力；对量化交易等金融机构来说，速度可以瞬间转化为真金白银。而在与医疗合作伙伴的交流中，我们收获了更深层次的共鸣：他们对利用Ultra Speed辅助医生进行手术表现出了极大的期待。在复杂的临床手术中，AI如果能提前几秒检测到潜在风险或辅助医生下达关键决策，其背后拯救的就是一个鲜活的生命。这让我们意识到，速度不仅是一个评测指标，更是在物理世界创造核心价值的基石。

以上就是关于Ultra Speed项目的分享，欢迎大家试用我们的服务，谢谢大家！

总结：架构-训练-推理的“三位一体”协同设计

罗福莉：在演讲的最后，我做个简短的总结。我们的初衷是打造一个兼具强大推理能力与极致长上下文效率的模型。在传统视角下，这两者是不可调和的--强推理意味着更多的计算、更长的注意力和更庞大的KV缓存；而高效则要求尽可能削减这些开销。我们的解题思路正是“架构-训练-推理”三层技术栈的端到端协同设计。

在预训练层面：我们实现了从MiMo-V2.5的混合滑动窗口注意力到MiMo-V3中High Sparse架构的平滑演进。通过让全注意力层扮演“先知”角色，完美实现了跨层KV缓存共享。
在后训练层面：MOPD攻克了多教师能力融合的难题，而R3则驯服了MoE强化学习训练，使其具备了与Dense模型相同的稳定性。
在推理层面：依托FP4量化、dFlash以及工程层面的bucket策略，我们成功在万亿规模模型上实现了每秒1000 token的突围。

这三个层面从不是孤立割裂的，它们构成了相辅相成的有机整体。架构的选择决定了推理的边界，而训练的创新又反哺了架构的稳定性。这种“三位一体”的设计哲学，正是MiMo-V2.5系列能够打破性价比僵局、在激烈竞争中持续胜出的根本所在。谢谢大家！

Q&A 问答环节

听众A：我的问题关于从混合滑动窗口（Hybrid SWA）到High Sparse的架构演进。全注意力层充当稀疏层的“先知”并共享KV缓存，这确实是个巨大的突破。我想请问，全注意力层的绝对数量会不会成为模型长上下文能力的瓶颈？另外，目前确定的1:11稀疏比是效率与性能的最优平衡点吗？未来这一比例还有进一步推高的空间吗？

罗福莉：非常深刻的问题。High Sparse的最终性能本质上取决于全注意力层建模的质量，而稀疏比本身并不是限制能力的枷锁。我们之所以追求更高的稀疏比，是为了进一步释放KV缓存压力并削减注意力FLOPs。目前有许多精细的技术可以用来推高稀疏比，例如将现有的block级别token选择细化至token级别，以获得更大的语义容量。此外，将滑动窗口注意力与稀疏注意力机制进行融合叠加，也能进一步拉高稀疏上限。

但正如你所说，这里存在一个底线，那就是全注意力层的绝对数量。我们在早期探索中发现，全注意力层通常不能少于3层（特别是在特定的混合架构中），它是长上下文性能的“定海神针”。总结来说：全注意力层的基数很关键，而稀疏比则可以通过后续的一系列工程和算法优化继续向上突破。

听众B：我很赞赏MiMo-V2.5在长上下文和KV缓存稀疏化上的成果。但我也很好奇，该模型在传统的短上下文任务（例如文本分类、代码补全等）中表现如何？

罗福莉：在短上下文任务上，我们的模型在标准基准测试中同样表现出了极强的竞争力。High Sparse架构在短文本下不会发生性能退化，因为全注意力层依然完整覆盖了整个短序列。在研发中，我们对短上下文的关注度与长上下文完全对齐，因为真实世界的业务场景往往是长短文本混合的。

听众C：我有两个问题。第一，High Sparse架构对你们现有的推理系统会带来额外的重构压力吗？第二，关于推测解码技术，演讲中提到针对不同上下文长度训练了不同的dFlash模型，你们是否做过性能剖析（profiling）？这种针对特定长度定制的模型能否显著提升token的接受率？

曹士杰：首先回答第一个关于High Sparse对推理系统影响的问题。我们在设计High Sparse之初，就确立了“不给推理框架增加额外工程负担”的原则。High Sparse由于直接共享了全注意力层的KV缓存，放置不会产生额外的内存开销，计算量也没有增加。

如果关注最近行业内关于稀疏注意力的工作，你会发现很多方案都需要引入一个额外的Indexer（索引器），但Indexer本质上也是一个需要通览全局的全注意力层，很多工作都卡在如何降低Indexer的计算开销上。既然如此，我们为什么不直接复用模型中本就存在的全注意力层呢？在混合滑动窗口架构中，全注意力层天然就是最好的“先知”，它本身就包含哪些token重要的top-k信息。我们直接复用这些信息，既精简了架构，又彻底解决了长上下文下全注意力层的瓶颈问题，这也是我们有信心持续推高稀疏比的原因。

关于第二个推测解码的问题。在MiMo-V2 Flash的技术报告中，我们使用的是MTP方案。推测解码的接受率在很大程度上取决于下一个token的熵。在代码生成和Agent等逻辑清晰的场景中，token的熵较低，接受率自然非常高。

我们的线上服务也充分利用了这一特性：对于超长上下文的bucket（往往99%是编程或开发场景），我们为其训练了专属的dFlash模型，在测试中甚至能达到“每8个token中接受7个”的极高效率。但在普通的通用Chat场景中，由于语义发散，接受率会相对低一些，维持在4中接受3的水平。这也解释了为什么我们没有采取一刀切的策略，而是针对不同的业务bucket实施差异化的推测解码方案。

听众D：我对MiMo模型采用的稀疏注意力和滑动窗口注意力技术很感兴趣。据我所知，DeepSeek系列也采用了类似的技术路径。而目前行业内还有另一类技术路线，即ChatGLM和Kimi等模型所尝试的线性注意力（Linear Attention）。请问团队是否对这两者做过横向对比？相比之下，MiMo目前的选择具备哪些独特优势？

罗福莉：实际上，我们在去年对线性注意力（包括Mamba等开源SSM状态空间模型架构）进行过非常深入的评测与尝试。我们发现，线性注意力在处理短上下文任务时表现非常出色，但在面对超长上下文以及复杂的长文本推理任务时，其建模能力与基于标准自注意力（Self-Attention）机制的方法相比，依然存在较为明显的代差。

我们最终选择混合稀疏注意力是基于详尽的实验数据做做出抉择。它的核心优势体现在三点：第一，它完整保留了全注意力层的全局建模表现，这是目前线性注意力架构仍难以企及的；第二，得益于创新的跨层KV缓存共享，它在内存效率上已经无限逼近线性注意力；第三，在长上下文深度推理任务中，它依然是目前综合表现最优的解法。

听众E：请问这些技术能否很好地支持大批量（Large Batch）或高并发的工业级场景？

曹士杰：完全可以。我们目前的线上生产环境已经在运行类似的机制。我们在系统层引入了基于上下文长度的bucket动态分配策略。例如，将请求划分为32K以下、32K到128K、以及128K以上等不同的业务桶（bucket）。每个bucket会根据从真实业务中采样的数据，动态匹配和训练专属的dFlash模块，从而在保证大批量并发吞吐量的同时，兼顾单次请求的极致响应速度。

听众F：我对后训练算法非常感兴趣，尤其是技术报告中提及的MOPD。我自己也在在线策略蒸馏（On-Policy Distillation）方向做了一些针对Agent任务的研究，但在长周期（Long-horizon）任务中经常会遭遇错误累积以及学生模型分布偏移（Distribution Shift）导致的训练失败。我很想知道，MiMo在工业工程环境中是如何化解这些失败模式的？有哪些实用的算法优化技巧可以分享吗？

罗福莉：这是一个非常切中要害的问题，因为你提到的这些失败模式也正是我们在研发早期花费了大量精力去攻克的硬骨头。我们目前已经将最新的MOPD技术细节进行了开源。

在这里可以分享一些有用的早期实验结论：例如，为了对抗长周期任务中的分布偏移，可以在训练中引入启发式的KL散度约束，动态过滤掉一些偏离过大的学生rollout数据，以此强力维持学生与教师模型之间的分布相对一致。工业界有很多类似的数据过滤与卷曲机制（Rollout Filtering）能让MOPD在长周期任务中稳定下来。不过我们也承认，面对极长周期的复杂Agent任务，后训练算法在基础设计上仍有进一步迭代优化的空间。

听众G：我有一个关于稀疏注意力层间共享的问题。在你们的架构中，不同层之间的KV缓存是完全共享的，这意味着层与层之间唯一的变量就是Query（Q）的值。请问在实际训练或推理中，你们有没有观察到Query在不同层之间展现出显著的分布偏移？因为KV完全一致，Q的变动将独自决定注意力的走向。

曹士杰：这个架构设计的核心灵感其实正是来源于对传统全注意力模型的实证观察--我们注意到在大模型中，相邻几层之间的注意力模式（Attention Patterns）高度相似，甚至几乎完全一致。这给了我们直接拿掉稀疏层KV、实施跨层共享的底气。在确立了这个架构并跑通了所有性能指标后，从实用主义角度出发，我们确实没有再专门针对Query在层间的微观分布演变进行更深度的统计学分析。

听众H：我注意到在推理侧你们采用了MXFP4量化技术。这是一个相对前沿且仍在演进中的底层技术，目前行业存在很多变体（例如不同的训练感知量化QAT方案等），也有部分学术论文指出了MXFP4在特定场景下的精度缺陷。请问团队为什么坚定地选择了MXFP4并结合QAT来落地？

曹士杰：探讨大模型量化必须要同时兼顾“模型精度”与“硬件效率”这两个维度。从精度角度来看，只要量化配置足够精细（例如选择极小的量化粒度和微型的块大小/Block Size），MXFP4与其他主流低比特格式在最终的精度表现上几乎没有统计学差异。

然而，真正让不同量化方案在工业界拉开差距的是硬件效率。MXFP4是NVIDIA在最新的Blackwell架构GPU上提供原生硬件级支持的低比特格式。这意味着它能直接享有底层算力核心的硬件加速，而不需要开发者像对待其他格式那样去费时费力地编写并优化自定义Kernel。对于瞬息万变的线上生产部署而言，原生硬件的兼容性与运行效率就是核心生命线，这也是我们毫不犹豫选择MXFP4的原因。

听众I：我注意到在MiMo-V2的预训练流程中，团队直接选择了从32K的序列长度起跑，这与目前行业主流的从4K或8K逐步递增的做法大相径庭。请问组织是让混合滑动窗口注意力机制成功运转的关键决定性因素吗？

罗福莉：不是的，序列长度的起点并不是决定性的因素。我们认为，让滑动窗口注意力在性能上能够真正媲美甚至超越全注意力架构的底层关键在于两点：首先是Attention Sink（注意力沉没值）的引入。当我们将模型规模推向万亿级参数时，Sink Value的初始化与更新机制变得无比娇贵--如何在MoE庞大的训练过程中优雅地初始化Sink Value并维持其稳定的梯度更新，才是架构不崩溃的核心。相较之下，初始的训练序列长度更像是一个常规的超参数选择，并非决定滑动窗口成败的胜负手。

听众J：关于强化学习（RL）部分，团队有没有发现长上下文（Long-context）场景下的强化学习，在训练特征上与传统的短上下文存在很大不同？

罗福莉：绝对有。长上下文RL面临最核心的挑战就是奖励信号（Reward Signals）极度稀疏，这导致训练收敛的难度呈指数级上升。我们前面提到的R3（推理路由回放）技术在这种场景下发挥了至关重要的作用，因为它彻底对齐了训练与推理侧的路由行为，斩断了额外的不稳定性源头。目前，我们团队也正在紧锣密鼓地开展更多针对长上下文场景的专用RL算法扩展工作。

听众K：最后一个问题关于位置编码。请问团队是如何处理长序列下的位置编码（Position Embedding）的？训练和推理阶段的处理存在差异吗？另外，当滑动窗口在长文本上向前滑动时，位置编码会被重置吗？

罗福莉：在研究中我们发现，滑动窗口注意力内部的RoPE theta参数在整个训练期间其实完全可以保持静止。在训练初始化阶段，我们可以直接为滑动窗口注意力配置一个足够大的基数（RoPE theta），并在后续的预训练、后训练阶段全程冻结这一数值。不过需要注意的是，全注意力层自身的RoPE theta在进行长上下文纵向扩展（Extension）时，依然需要进行动态微调。

听众K：那在训练和推理之间，这个处理是完全一致的吗？

曹士杰：是的。训练一旦收敛，RoPE theta以及模型的所有权重参数在推理服务期间都是完全静态、不作任何改变的。

听众K：也就是说，即使窗口在持续滑动，每当模型新生成一个token，它的RoPE或位置编码索引依然是在持续累加递增的，对吗？

曹士杰：是的，完全正确。参数和编码机制本身保持绝对的一致与连续。

一个人读论文太孤单，一群人刷顶会才好玩。

ICML 2026召开在即，我们正在召集一波含金量极高的 AI 研究者。群内主打实时论文跟踪与硬核技术探讨，拒绝灌水。

进群传送门：扫码进群或添加微信Vin_Vivid，备注：论文群 + 关注的 AI 方向。