谷歌DeepMind搞出了Transformer杀手：MoR架构让大模型推理快2倍、内存省一半

先说结论：KAIST、Mila和谷歌DeepMind团队联合发了一篇论文，提出了一个叫MoR（Mixture-of-Recursions，递归混合体）的新架构。在135M到1.7B参数规模下，它的推理吞吐量比传统Transformer提升超过2倍，KV缓存内存直接减半。论文已经在arXiv上公开了。

MoR到底干了什么

传统Transformer有个问题——它对所有token一视同仁。你输入「的」「是」「在」这种虚词，和输入「量子纠缠」「反向传播」这种硬核词汇，模型给的计算资源是一样的。这不合理。就像你去便利店买瓶水，和去4S店提辆车，不应该排同一个队。

MoR的核心思路是把「参数共享」和「自适应计算」捏到了一起。它设计了一个共享的层堆栈，让token可以循环经过这些层，但不是每个token都走同样的深度。简单的token走一两层就退出了，复杂的token循环三四层甚至更多。

路由器才是灵魂

MoR里最关键的东西叫路由器（Router），一个小型打分网络。每个token经过一层处理后，路由器会根据它的隐藏状态打分。高分说明这个token还没理解透，继续递归；低分说明已经够了，提前退出。

论文里提了两种路由策略。一种是专家选择路由——每层递归时，由「专家」挑选它认为最值得处理的top-k个token。另一种是token选择路由——token在一开始就自己决定要走多少层，适合推理场景。两种各有优劣，但思路都一样：该省省，该花花。

KV缓存也省了

大模型推理最吃内存的就是KV缓存。Transformer要为每个token、每一层都存一个键值对。MoR的做法是：只有被路由到某一层的token才生成并存储KV对，已经退出的token不占缓存。这样内存直接减半。

还有一个KV共享变体，在第一次递归中生成的KV对可以在后续递归中复用，进一步降低预填充延迟。从工程角度看，这个设计很务实——不光追求学术指标好看，还考虑了实际部署的成本。

实验数据说了什么

论文在135M到1.7B参数范围内做了系统对比。三个核心结论：第一，在相同训练FLOPs下，MoR的验证困惑度明显低于普通Transformer。第二，少样本任务准确率更高，说明模型没有因为参数共享而牺牲能力。第三，推理吞吐量提升超过2倍——这个数字对做工程的人来说很香。

团队还画出了一条新的帕累托前沿线：在模型尺寸和性能的坐标系里，MoR把整条曲线往更小更快的方向推了一步。用行话说，它重新定义了效率天花板。

但别急着喊「Transformer已死」

实话实说，135M到1.7B这个规模离生产环境还有距离。GPT-5是万亿参数级别，MoR能不能在这个量级保持优势，论文没给答案。架构创新从实验室到落地，中间隔着大量的工程验证和生态适配。

不过方向是对的。大模型不能永远靠堆参数活着，迟早要从「暴力美学」转向「精巧设计」。MoR证明了这条路可行：不是参数越多越好，而是谁更会分配计算资源。这才是未来大模型架构该有的样子。