小米新开源模型MiMo-V2-Flash，一招把计算量砍到底

小米刚开源了一个 309B 的大模型 MiMo-V2-Flash，技术报告里有个数据让我很意外：

它只让模型“看” 128 个 token，却能处理 256k token 的超长文档。

而且，“看得少”的版本，在长文档理解测试上的成绩，反而比“看得多”的版本更高。

这是怎么回事？

今天我们来聊聊这个反常识的设计，以及它背后的技术洞察。

什么是“看多少”？

大模型处理文字的时候，有一个关键机制叫注意力（Attention）。

简单说，就是模型读到当前这个字时，得回过头去看看前面的字，才能明白当下的含义。

比如你问模型：“小沐昨天去北京，他今天去了哪里？”

模型在理解“他”这个字的时候，需要“看”到前面的“小沐”，才知道“他”指的是谁。

传统的做法是：让模型看到所有字。你给模型一篇 10000 字的文章，模型在处理每个字的时候，都可以参考这 10000 个字的全部信息。

这叫“全局注意力”。听起来很完美，信息全面，不会遗漏。

但问题是——计算成本太高了！！

我们来算一笔账。假设文章有 n 个字。

• 第 1 个字需要看到前 1 个字的信息
• 第 2 个字需要看到前 2 个字的信息
• 第 3 个字需要看到前 3 个字的信息
• …
• 第 n 个字需要看前 n 个字的信息

总共需要看多少次？1+2+3+…+n ≈ n²/2

计算量是字数的平方级别。

1000 字的时候，100 万次计算，还行。
10000 字的时候，1 亿次计算，有点吃力。
256000 字的时候？655 亿次计算，每生成一个字都要算一遍。

这就是为什么很多模型处理长文档的时候会变得很慢，甚至直接告诉你“超过上下文限制”。

全局注意力的计算成本，随文档长度指数级增长。

让 AI 学会选择性近视

MiMo-V2-Flash 的做法很有意思。它把模型的几十个层，硬生生拆成了两种：

• 近视层（Sliding Window）：占了绝大多数（5 层），每层只能看见前后 128 个 Token。
• 远视层（Global）：只有少数（1 层），可以看清全文。

然后像叠汉堡一样循环堆叠：

近视 → 近视 → 近视 → 近视 → 近视 → 远视 → 近视 → 近视 → ...  

为什么这样设计？小沐觉得可以用一个比喻来理解：

想象你在读一本 500 页的小说。

全局注意力的读法：每读到一个字，都要强迫自己把从第 1 页到刚才的所有内容在脑子里过一遍。“这个‘他’是谁来着？让我从头想一遍…”

这得累死谁啊。。

混合注意力的读法：大部分时候，你只关注当前这一段在说什么。只有在章节转换、情节呼应的关键时刻，才去回忆前面的内容。

这不就是我们真实的阅读方式吗？不仅不傻，反而更符合认知规律。

那又有朋友要问了：128 个 token，两三句话，够用？

远距离的信息怎么传递？

问得好！但这正是 Transformer 架构的神奇之处——接力传递。

虽然每层近视层只能看 128 个 token，但层和层之间的信息是会传递的。

假设你要理解第 10000 个字，需要参考第 1 个 token 的信息：

1. 第 1 层（近视）：把第 1 个字的信息传给了第 128 个字。
2. 第 2 层（近视）：第 128 个字带着第 1 个字的信息，传给了第 256 个字。
3. ……
4. 第 N 层（远视）：所有局部信息汇聚，第 1 个字和第 1 万个字终于“相见”了。

此外，每隔 6 层就有一个“远视层”做全局汇总，确保长距离信息不会丢失。

这就像“击鼓传花”，信息层层接力。

这就是为什么 128 的窗口可以处理 256K 的上下文。

实验数据：少看真的更强？

原理说通了，效果怎么样？别是“省了算力，丢了智商”吧？

来看技术报告里的实测数据：

RULER 128K 测试：涨了 0.4%

InfBench 测试：涨了 3.2%

What？

混合注意力不仅没掉分，反而还涨分了？🤨

小米对此给出了一个很有趣的解释，小沐愿称之为 “拒绝 AI 摸鱼理论”：

如果每一层都能看到全局，模型可能会“犯懒”——反正哪层都能看到全部，我就不专心处理局部细节了。

但现在，绝大多数层被强制戴上了“高度近视镜”，它们被迫极度专注于处理局部的语法、搭配。而那唯一的“远视层”，则被迫承担起整合全局的重任。

分工明确，各司其职。 这就好比公司管理：

• 混乱模式：所有员工都想管 CEO 的事，结果没人干活。
• 高效模式：员工专心拧螺丝（处理局部），经理专心定战略（整合全局）。

这波啊，是组织架构优化的胜利！

省了 6 倍内存

除了变聪明，这个设计还送了一个超级大的工程红利：省显存！

模型推理的时候，需要把之前处理过的信息存起来（叫 KV-cache），方便后续参考。全局注意力的 KV-cache 大小和上下文长度成正比。

全局注意力下，256k 的上下文，KV-Cache 就要存 256k 的量。显卡在燃烧啊！

但混合注意力下

• 5/6 的层只存 128 个 Token 的信息。
• 只有 1/6 的层需要存全量。

KV-cache 直接压缩到原来的 1/6 左右。

这意味着：

• 同样的显卡，可以处理更长的文档
• 同样的长度，推理速度更快
• 同样的效果，成本更低

效果更好 + 成本更低，这是真正的“免费的午餐”。

注意力垃圾桶

报告里还有一个让小沐觉得特别优雅的细节：Attention Sink（注意力汇聚点）。

什么意思？

Softmax 函数要求注意力总和必须是 100%。

但有时候，模型在理解当前这个字的时候，真的不需要特别关注任何其他字。

比如生成一个很常见的词“的”，不需要回顾什么上下文，直接输出就行。

但 Softmax 要求注意力必须分配出去啊，分给谁？

MiMo-V2-Flash 的解法是：找一个固定的“垃圾桶”，把不需要的注意力都丢进去。

它给每个注意力头加了一个可学习的 Bias（偏置）。这个偏置不对应任何真实的字，专门用来接收“多余的注意力”。

效果呢？

模型不再依赖第 1 个 token 当垃圾桶，长上下文处理更稳定。

好的设计是顺势而为

看完 MiMo-V2-Flash 的报告，给小沐最大的启发是： 好的技术设计，往往是“顺势而为”，而不是无脑堆料。

• 觉得窗口不够大？不是无脑加显存，而是思考“真的需要看那么多吗？”
• 注意力没地儿放？不是死磕架构，而是造个虚拟容器。

很多时候，问题的本质不是“资源不够”，而是“资源分配不合理”。这个道理，在大模型架构设计上成立，在其他很多领域也成立。

最后报个实测数据：169 tokens/秒！

一篇 500 字的新闻稿，4 秒搞定。

这速度，真的是在飞~

50 个 case 都在这里啦，感兴趣的朋友可以进来感受一下~

https://xiaomi.wmxiaomu.com

参考文献
MiMo-V2-Flash Technical Report  
StreamingLLM: Efficient Streaming Language Models with Attention Sinks  
Longformer: The Long-Document Transformer