循环超过两次会怎样：循环Transformer与循环MoE深度对比

一、对比背景：两种“省着用参数与计算”的思路

大模型的成本可以拆成两个正交的量：参数量（决定显存与存储占用）和每个token的计算量（决定延迟与吞吐）。标准稠密Transformer里这两者是绑定的：多加一层，参数和计算同步增长。于是业界发展出两个解耦方向：

• 循环（权重共享）：同一组层反复执行多次，参数不增加，“有效深度”随循环次数增长。它省的是参数。
• MoE（混合专家）：把一层改造成“路由器 + 专家池”，路由器为每个token挑选少数几个专家，参数总量可以很大，但实际计算量可控。它省的是计算。

两个方向各自成熟后，一个自然的设想是：把循环套在MoE外面——反复使用同一套专家池，每一轮都让路由器重新选一次专家。理论上，MoE贡献额外容量、循环贡献额外深度，本该是双赢组合。但研究与工程实践反复观察到的结论是：这个组合跑不起来，而且问题恰恰在循环次数超过两次之后集中暴露。

本文的对比对象由此明确：循环稠密Transformer（反复复用同一组稠密层） 与 循环MoE（反复复用同一套专家池、每轮经路由器重选专家）。核心问题是：循环次数从1次、2次增加到3次以上，两者各自会发生什么。

二、对象定义：先弄清两边到底是什么

2.1 循环稠密Transformer

将Transformer的某个块（或一段层）用同一份权重反复执行K次，隐藏状态在残差流上被同一组变换迭代精炼：

# 循环稠密Transformer（示意）
h = embed(x)
for k in range(K):          # K 为循环次数
    h = h + DenseBlock(h)   # 同一组参数反复使用

关键性质：每一轮循环，全部共享参数都确定性地参与计算。循环K次，模型的有效深度约等于“K × 层数”。

2.2 MoE基础

MoE把“一层”改造为“路由器 + N个专家子网络”。路由器对每个token打分，选出Top-k个专家（k远小于N），加权汇总输出。参数存放在所有专家中，计算只花在选中的专家上。这个定义是理解全文的前提：MoE的本质是“条件计算”——算什么由路由器临时决定。

2.3 循环MoE

# 循环MoE（示意）
h = embed(x)
for k in range(K):
    h = h + MoEBlock(h)     # 每轮都要经路由器重选专家

关键性质：每一轮实际参与计算的，是路由器这一轮选中的那k个专家。专家池参数在轮与轮之间共享。

三、相同点分析：为什么它们常被放在一起讨论

两类方案在动机层面高度一致，这也是“组合它们”听起来合理的原因：

1. 目标相同：在固定的参数预算或计算预算下提升模型质量，追求质量与成本的更优交换比。
2. 手段同源：本质都是“复用”。循环是在时间维度复用同一组层；MoE是在token维度复用专家池中的子集。
3. 都存在收益递减：无论哪种循环，隐藏状态随迭代轮数增多会逐渐收敛，继续循环的边际收益都会下降。
4. 训练都需要额外技巧：循环结构需要在时间维度上回传梯度（类似训练循环网络的展开计算图），激活显存随K增长；MoE需要负载均衡等辅助损失防止专家利用失衡。

相同点之下，真正的分歧藏在“每一轮循环里，到底有没有新计算发生”。

四、核心差异分析

4.1 最关键的差异：“每轮新计算”的确定性不同

• 循环稠密：每一轮都对全部参数做一遍完整的非线性变换。哪怕表示已经收敛，这一轮的变换本身依然是“新的计算”，结构上保证了有效深度随K增长。
• 循环MoE：每一轮只对路由器选中的专家做计算。多轮循环是否带来新的专家知识，取决于路由器是否换专家——这是一个“条件性”承诺，不保证兑现。

这一确定性差异，是后续所有表现分化的根源。

4.2 循环次数从1到2到3+：行为分化

• K=1：循环MoE就是普通MoE，循环稠密就是普通稠密模型，都是成熟方案。
• K=2：循环稠密通常仍有稳定提升；循环MoE此时也常能获益——路由器在第2轮看到的是第1轮加工后的表示，有机会选出互补的专家，叠加不同视角的信息。
• K>2：分化出现。循环稠密进入收益递减的平台期，但不会“空转”；循环MoE则普遍出现路由坍缩——第3轮及以后，路由器为同一个token选出的专家集合几乎不再变化，新增的循环变成“用同样的专家反复处理几乎同样的表示”，计算在原地打转。

4.3 路由坍缩的机理：为什么偏偏是第三次以后

这一现象可以从四个相互叠加的机制理解：

1. 路由器输入的收敛。路由器的输入是残差流上的隐藏状态。第1轮时状态是“新鲜”的；经过两轮专家写入，表示已趋于稳定，每轮增量越来越小。路由器是确定性的打分函数——输入几乎不变，Top-k选择自然几乎不变。
2. 自我强化回路。被选中的专家把输出写回残差流，会进一步强化“让路由器选择自己”的那些特征，形成正反馈，选择愈发固定。
3. 辅助损失存在盲区。常规的负载均衡损失只约束“一个批次内所有token是否把专家用得均匀”，完全不约束“同一个token在不同轮次之间是否换了专家”。时间维度的坍缩没有任何损失项去惩罚。
4. 选择饱和。随着训练推进，路由器打分的差距拉大，选择越来越接近硬性确定，进一步锁死。

结果是一个双重落空：MoE承诺的“额外容量”没有兑现——参数很多，但多轮循环实际只反复使用同一小撮专家；循环承诺的“额外深度”也没有兑现——重复近似恒等映射的计算对表示的改造能力迅速衰减。同时还要多付出K倍的路由开销和随K增长的激活显存。

4.4 有效深度与有效容量的错位

可以更抽象地总结：循环稠密买到的是“深度”，普通MoE买到的是“容量”（知识面），循环MoE试图两者兼得，但坍缩使其两头落空。这解释了为什么“参数规模看似变大、循环次数看似变深”的模型，实测提升远低于预期。

4.5 训练稳定性差异

• 循环稠密：结构简单，主要代价是激活显存随K增长、梯度需在时间维度回传，整体相对稳健。
• 循环MoE：除上述代价外，还要叠加MoE固有的训练问题——负载均衡、路由打分异常、专家利用失衡；在循环设定下这些问题会与时间维度的坍缩互相放大，训练不稳定性更高。

4.6 显存与推理成本结构

• 两者训练时的激活显存都随K近似线性增长。
• 循环稠密参数少，权重显存占用小；循环MoE的全部专家权重需常驻显存，参数容量的“大”直接转化为部署显存压力。
• 推理延迟上，两者都与K成正比；循环MoE额外多出“每轮一次路由打分与分发”的开销，K越大，这部分固定开销被放大K倍。

五、对比表格：一表总览关键差异

对比维度	循环稠密Transformer	循环MoE
参数组织	一组稠密层，全体参数共享复用	路由器 + 专家池，参数分片存放
每轮参与计算的参数	全部共享参数（确定性参与）	路由器选中的Top-k专家（条件性参与）
循环增益来源	有效深度随K近似线性增长	名义上“深度×容量”，实际易坍缩
K=1→2 的表现	通常有稳定提升	常有提升（第2轮可选互补专家）
K>2 的表现	收益递减、进入平台期	路由坍缩，新增循环近似无效
训练稳定性	相对简单稳健	需负载均衡、路由正则等辅助手段
权重显存	小（参数总量少）	大（全部专家常驻显存）
推理延迟	与K成正比	与K成正比，另含每轮路由开销
工程复杂度	低，可即插即用	高：专家并行、通信、路由监控
倾向的适用面	参数受限、需要推理深度	容量受限、需要知识覆盖面

六、典型场景选择

• 场景一：参数/显存预算受限（端侧、小模型、边缘部署）。瓶颈在参数量，循环稠密更契合——用极小的参数代价换取有效深度，工程链路简单。
• 场景二：大规模预训练、追求知识容量。瓶颈在“模型知道多少”，普通MoE（不套循环）是更直接的选择，容量扩展路径成熟。
• 场景三：希望“深且宽”同时兼得。可以尝试循环MoE，但应把K控制在2附近，并先做路由诊断（见第八节）；若诊断显示轮间选择高度重合，应果断放弃叠加循环，改用堆叠更多MoE层等替代路线。
• 场景四：延迟敏感的在线推理。任何循环方案都要克制K；若叠加MoE，需把“路由开销 × K”计入延迟预算，并评估专家并行带来的通信成本。

七、选型建议：条件化判断而非绝对推荐

选型的第一步是回答“瓶颈到底是什么”：

1. 若瓶颈是参数量（装不下模型）：优先循环稠密结构。
2. 若瓶颈是容量（知识面不够、数据多而杂）：优先普通MoE，K=1即可，不必强行叠加循环。
3. 若团队运维与训练工程能力有限：循环稠密的接入门槛和监控成本显著更低；MoE对负载均衡、专家并行、通信调优的要求更高。
4. 若坚持尝试循环MoE：把它当作实验性方案对待——预留回退开关、限定K不超过2、全程监控轮间路由重合度，用数据而非直觉决定去留。

八、迁移与使用注意事项及改进方向

8.1 先诊断：如何判断发生了路由坍缩

在训练或评测脚本中记录每个token在各轮的专家选择，统计轮间重合度：

# 诊断示意：统计各轮循环的专家选择重合度
selected = [router.topk_ids(h, k) for k in range(K)]  # 每轮的选择集合
overlap = mean(jaccard(selected[k], selected[k - 1])
               for k in range(1, K))
# overlap 趋近 1 → 路由坍缩：后续轮次在做重复计算

若重合度随轮次快速逼近1，说明增加循环次数只是在浪费算力，应停止加深循环。

8.2 可考虑的改进方向（通用思路）

• 迭代感知路由：向路由器注入轮次信息（如循环序号嵌入），让不同轮次“知道自己在第几轮”，从而有能力刻意换专家：

# 迭代感知路由（示意）
def route(self, h, k):
    g = self.gate(h + self.iter_embedding(k))  # 注入轮次信息
    return topk(softmax(g), self.top_k)

• 轮间错峰惩罚：对“同一token在相邻轮次选择相同专家”施加惩罚项，把负载均衡思想从batch维度扩展到时间维度。
• 路由输入解耦：让路由器读入经过归一化或截断处理的隐藏状态，弱化残差流收敛对打分的同化作用。
• 务实策略：直接把K限制为2，用“两轮互补专家”吃掉组合红利中相对可靠的部分，回避第三次以后的坍缩区。

8.3 工程与部署注意

• 从循环稠密迁移到含MoE的方案时，需重新评估权重显存（专家全量常驻）、引入专家并行与通信开销，并配置路由统计监控；训练上需加入负载均衡等辅助损失并安排充分的warm-up。
• 从普通MoE迁移到循环MoE属于实验性改造，务必保留K=1的回退配置，逐步灰度验证。
• 若选择云端训练与部署，可借助百度智能云等平台提供的GPU算力、容器平台、监控告警与日志服务等通用能力，把每轮专家分布、轮间选择重合度、专家负载熵等指标纳入统一可观测体系，让“坍缩是否发生”成为可持续监控的运行时指标而非一次性实验结论。

九、总结

回到最初的问题：循环超过两次会怎样？答案因架构而异。循环稠密Transformer在第三轮之后表现为收益递减的平台期，但每一轮仍有完整的新计算发生；循环MoE则在第三轮之后普遍触发路由坍缩——路由器为同一token反复选择同一批专家，容量与深度的双重承诺同时落空，多出的循环近似于无效计算。

决策思路可以归纳为一条主线：先判断瓶颈是参数、容量还是深度；再评估路由行为的确定性——凡是“新计算是否发生”依赖运行时条件判断的方案（如MoE路由），在叠加循环这类时序结构时，都必须为“条件不兑现”的风险做诊断与兜底。对多数团队而言，循环稠密与普通MoE各自站在天平两端，而循环MoE目前仍是一个需要谨慎对待、以K=2和小规模实验为边界的研究性组合。