> 来源：A Dual-Path Architecture for Scaling Compute and Capacity in LLMs，Markus Frey, Behzad Shomali, Joachim Koehler, Mehdi Ali，Lamarr Institute / Fraunhofer IAIS / 波恩大学，https://arxiv.org/abs/2605.30202
---
想象你在读一篇文章。遇到"的""了""是"这类功能词，你的大脑几乎不费力气，一扫而过；但碰到一个数学公式或逻辑推理链，你会停下来反复琢磨——同样的阅读过程，不同位置分配的"算力"天差地别。
大语言模型却做不到这一点。传统的 Transformer 对每个 token 一视同仁，用同样深的网络、同样多的参数处理"的"和"∫"。循环 Transformer（Looped Transformer）试图用"深"来弥补——把同一个模块反复执行多次，省参数但费计算；标准 Transformer 则走"宽"路线——堆更多参数，一步到位但费显存。
问题是：深和宽，为什么只能选一个？
双通道：深和宽同时存在
这篇论文提出了 Dual-Path Block，核心思路极其简洁：在同一个层里，并行放两条路——
- 深路径（Deep Path）：一个共享参数的 Transformer 块，循环执行 N 次。参数少，但可以反复"思考"，适合需要多步推理的 token。
- 宽路径（Wide Path）：一个扩大了前馈网络（FFN）的单次块。参数多，但只走一遍，适合需要大量知识检索的 token。
这就像给模型装了一个"注意力调度员"——不是让所有 token 走同一条路，而是让每个 token 自己选：你是需要多想几遍，还是需要查更多资料？
门控学到了什么？直接可解释
最让人兴奋的发现是：这些门控权重是直接可解释的，不需要任何事后分析。
研究团队观察了训练好的门控分布，发现了一个清晰的规律：
| Token 类型 | 门控偏好 | 直觉解释 |
|---|---|---|
| 功能词（的、了、是） | → 宽路径 | 不需要推理，需要语言知识 |
| 词汇内容（动词、形容词） | → 宽路径 | 需要语义知识库 |
| 标点符号 | → 深路径 | 结构性标记，需要多步处理 |
| 数学/符号 | → 深路径 | 需要多步推理 |
实验结果：同等算力下全面胜出
在两个 FLOP 预算下（约 1.5B 和 3B 参数规模），Dual-Path 模型在语言建模和下游任务评估中全面超越了同等算力的基线模型，同时使用的参数量更少。
消融实验也很有说服力：
- 两条路都不可或缺：关掉任何一条（$g_d=0$ 或 $g_w=0$），性能都显著下降。
- 逐 token 决策有意义：如果把门控权重随机打乱（保持边际分布不变），性能也会下降，说明模型确实在"因 token 制宜"地分配算力。
- 循环次数不能外推：训练时循环 3 次，推理时加到 5 次并不会更好——模型学到的循环动力学有"舒适区"。
为什么这很重要？
这篇论文解决了一个长期存在的架构困境：循环 Transformer 省参数但缺容量，标准 Transformer 有容量但费参数。Dual-Path 的回答是——别选了，两个都要，让模型自己决定每个 token 走哪条路。
更深层的启示是：逐 token 的计算分配可能是下一代 LLM 架构的关键方向。人类大脑不会对每个字花同样的力气，模型也不应该。Dual-Path 用最简洁的方式证明了这一点——一个可解释的门控，就足以让模型学会"什么时候该深思，什么时候该快过"。
当然，这项工作也有局限：目前只在较小规模（1.5B-3B）上验证，门控的"深/宽"二分是否是最优的分配粒度也值得探讨。但方向是对的——让模型学会"看菜下碟"，比给所有菜一锅炖要高效得多。
---
论文链接：https://arxiv.org/abs/2605.30202