前沿大模型循环深度架构：原理、瓶颈与落地

一、什么是大模型循环深度？架构溯源与核心原理

传统 Transformer 主要通过堆叠层数提升模型容量，参数量也随之快速增长。循环深度（recurrent depth）换了一种思路：让同一组层参数在潜在空间中被重复调用多次，用增加计算深度的方式提升表达能力。

这一思路有明确的学术来源。2018 年提出的 Universal Transformer（Dehghani 等，arXiv:1807.03819）已经在 Transformer 中引入了跨深度的参数共享和循环机制。循环深度可以看作这条技术脉络的现代化改造，并兼顾了两类架构的优点。传统 RNN 依靠时间步之间的循环传递状态，因此难以并行训练。Transformer 通过自注意力实现了并行计算，却缺少显式的迭代推理结构。循环深度在保留 Transformer 并行训练能力的同时，让数据在相同的 Transformer 块中多次流转，模型因此能在隐空间中进行多步推理。

这种参数复用让模型在不增加参数量的前提下获得更多计算步数。推理时的计算量随循环次数增加，模型在复杂任务上的表现也有机会随之提升。

二、算力等效：小参数模型如何获得接近大模型的推理表现

循环深度最受关注的结论来自 2025 年的论文《Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach》（arXiv:2502.05171，作者为 Geiping 等人）。该研究训练了一个约 3.5B 参数的循环模型，并在推理阶段把循环次数提高到约 32 次。作者报告，在 ARC、GSM8K 等推理类基准上，这一配置的表现接近参数量约 50B 的传统模型。

引用这一结论时，需要注意以下三个测试条件：

1. 结论针对推理类任务。它不代表模型在所有任务上都等效于 50B 模型。
2. 对比结果依赖循环次数。循环次数越少，性能越低，因此“等效”指的是特定推理次数下的结果。
3. 具体分数、基准版本和对比基线应以论文原文为准，引用前需要逐项核对。

该研究的意义在于，它表明模型容量可以部分依赖测试时的计算量，而不只依赖物理参数规模。模型可以按任务难度分配计算资源：简单问题少循环，复杂问题多循环。这种测试时计算扩展，为在有限硬件上部署推理能力较强的模型提供了一条路径。代价是延迟会随循环次数上升，因此部署时需要在质量与耗时之间做取舍。

三、循环次数的边界：为什么不是越多越好

循环并非越多越好。部分研究观察到，在传统实现中，循环次数超过一定值后性能可能下降，也有观点认为两到三次附近的收益最高。造成这一现象的原因之一是梯度消失或爆炸：同一组参数反复作用，梯度沿多轮传播时容易失控。另一个原因是表征平滑化：隐状态经过多轮迭代后趋于相似，模型逐渐失去区分细微特征的能力。

目前，业界对某前沿大模型是否突破了这一瓶颈尚无公开确认。以下几个方向属于业界推测，并非已证实的结论：

• 为每一轮循环引入可学习的衰减系数，控制后续轮次对隐状态的修改幅度。
• 在循环过程中结合残差连接，并对每轮隐状态做动态正则化。
• 使用层归一化，防止表征在多轮迭代中坍缩。

这些方法都需要通过训练和评测验证。读者在评估时，应当区分已发表的实验结果与厂商未公开的工程细节。

四、开源模型的循环改造：可行路径与注意事项

近期的一些研究表明，开发者可以把已有的开源模型改造成循环结构。做法是把预训练好的 Transformer 层视为共享权重的循环单元，在外层加入控制循环次数的逻辑。相比从头预训练，这种方式的成本低得多。

但低成本不等于零成本。预训练模型的隐状态分布，是在单次前向传播中学到的。如果直接把输出反馈回输入做多轮迭代，隐状态会偏离原有分布，性能可能下降。因此，改造后仍需要少量训练来适配循环，例如使用 LoRA 等参数高效微调方法，或者设计表征对齐目标，让模型学会在多轮迭代后保持稳定的表征。

工程实现时，有以下三个要点需要明确：

1. KV Cache 策略。每轮循环都会为同一组层生成新的 KV。若每轮独立缓存，显存占用会随循环次数线性增长。若只保留最后一轮或共享缓存，显存更省，但可能损失精度。应根据显存预算和精度要求选择方案，并在验证集上对比效果。
2. RoPE 位置编码。同一个 token 在各轮循环中应保持相同的位置索引。如果把每轮都当作新的序列位置，位置信息会错位，注意力模式也会被破坏。
3. 循环次数上限。应根据任务设置上限，并通过早停或难度判断决定每个请求的实际循环次数，避免所有请求都跑满上限。

对中小团队而言，这种改造的价值在于：用较小的开源基座模型，在特定推理任务上获得接近更大模型的效果。但效果必须用自己的评测集验证，不能直接套用论文中的结论。

五、云端工程化落地：显存、延迟与调度

循环深度在算法层面有明显潜力，但云端落地仍面临三个问题。

首先是显存与延迟的权衡。参数量减少后，静态显存占用随之下降。但循环增加了有效计算深度，KV Cache 的管理变得复杂，单次请求的延迟也会随循环次数增加。部署时可以借助 PagedAttention 等通用的显存管理技术，在吞吐量与延迟之间取得平衡。

其次是测试时计算的自适应调度。循环次数会随请求复杂度变化，这要求推理框架和算力调度系统具备更强的弹性。在 Kubernetes 环境中，可以基于自定义指标配置 HPA（Horizontal Pod Autoscaler），例如每秒循环步数、排队请求的平均循环次数或 GPU 利用率，使副本数随计算负载自动伸缩。调度器还可以把高循环次数的请求分配到独立的资源池，避免长请求拖慢短请求。

最后是分布式训练。传统并行策略通常按层切分模型。在循环架构中，同一组参数被多次使用，流水线并行中层与设备的对应关系被打破，跨节点的通信模式也随之改变。团队需要结合参数共享的特点设计并行方案，并通过通信分析确认瓶颈位