循环深度架构：用重复计算换推理深度

近年来，大模型能力提升主要沿着两条路径推进：一条是扩大参数规模与训练数据，另一条是增加推理阶段的显式计算，例如让模型输出更多中间步骤。前者成本高、周期长，后者会带来明显的输出延迟与词元消耗。循环深度架构提供了第三条思路：不显著增加模型层数与参数规模，而是让同一组网络块在推理时反复计算，把“深度”从静态结构变成可调的计算预算。本文围绕循环深度Transformer展开，讨论其工作机制、优势边界、训练推理权衡，以及工程落地时必须补齐的监控与治理能力。

一、传统深层模型为什么需要新思路

常规Transformer可以理解为一条单向计算链路：输入经过嵌入层后，依次穿过若干层，每层执行注意力与前馈计算，最终由输出头给出结果。模型有多少层，前向计算就大致执行多少次固定变换。若希望模型在复杂问题上“想得更深”，常见做法是堆叠更多层、扩大隐藏维度或增加参数。这确实能提升表达能力，但也带来显存占用、训练成本、推理延迟和部署复杂度同步上升的问题。

更关键的是，静态深度并不等于自适应深度。简单问题与复杂问题走同一条计算路径，简单问题可能被过度计算，复杂问题又未必获得足够计算。循环深度试图把“计算深度”从模型结构里解耦出来：网络块仍然只有一组，但可以在推理阶段循环多次，用重复计算换取更高的有效深度。

二、循环深度Transformer的核心机制

循环深度架构通常包含三个部分：输入编码、可共享的Transformer块、输出头。与普通堆叠结构不同，共享块在多轮循环中复用同一组权重。第一轮计算得到的隐藏状态不会直接进入下一层，而是被送回共享块入口，继续加工若干轮，直到满足停止条件后再交给输出头。

其简化流程可表示为：

输入序列
  -> 嵌入表示 h0
  -> 共享Transformer块重复执行：
       h_t = Block(h_{t-1})
       若满足停止条件，则退出循环
  -> 输出头生成结果

伪代码示例如下：

def forward(x, shared_block, head, max_loops, halt_policy):
    h = embed(x)
    history = []
    for step in range(max_loops):
        h_prev = h
        h = shared_block(h)
        history.append(summarize(h))
        # 停止策略可基于循环步数、状态变化幅度或轻量分类器
        if halt_policy(h, h_prev, step, history):
            break
    return head(h), {
        "loops": step + 1,
        "halt_reason": halt_policy.last_reason,
        "state_stats": history
    }

这里的关键不是“重复”本身，而是权重共享下的递归计算。参数量没有随循环次数线性增长，但计算图深度被拉长。对于部分推理任务，多轮循环可以让隐藏状态逐步细化，形成一种隐式中间推理。与显式输出大量推理文本相比，这种方式可以把中间过程压缩在隐藏状态中，减少对外可见的推理词元，但也会带来可解释性与审计难题。

三、它和“堆更多层”有什么不同

循环深度与简单加深网络有相似之处，也有本质差异。堆叠层意味着每层拥有独立参数，模型容量与结构深度同步增加；循环深度则复用同一组块，增加的是计算步数与有效深度，参数规模相对稳定。可以把它类比为一段可重复行走的楼梯：台阶数量不变，但可以多绕几圈到达更高处。

这种设计带来三个直接特性：

1. 参数效率更高：新增计算预算不必对应新增参数，部署时的模型体积更可控。
2. 测试时算力可调：通过循环次数、早停策略和动态深度控制，可以在延迟与效果之间做权衡。
3. 有效深度可扩展：在训练分布覆盖的范围内，增加循环次数可能提升复杂任务表现，但并非无限叠加都有效。

需要强调的是，循环次数不是越多越好。循环过少可能欠计算，循环过多可能过计算、放大噪声或导致状态漂移。实际系统需要结合任务类型、输出稳定性、延迟预算与评测曲线确定上限。

四、训练与推理阶段的主要挑战

循环深度把计算图展开后，训练内存和梯度传播成本会随循环次数增加。若直接对多轮循环做完整反传，显存压力可能迅速上升。工程上常见思路包括梯度检查点、截断反传、随机循环深度、循环一致性约束、残差门控与归一化稳定策略等。训练时还应让模型见过不同循环步数，避免只适配固定轮数，否则推理阶段调整预算时容易性能骤降。

推理阶段的挑战主要在延迟与批处理效率。不同样本可能需要不同循环次数，若同一批次内循环次数不一致，会造成算力浪费或调度复杂。常见做法是按预算分组、设置最大循环上限、使用轻量停止策略，并对超时请求回退到固定轮数或较小模型路径。对于在线服务，应把循环次数纳入容量模型：平均循环次数决定算力成本，尾部循环次数决定延迟上限。

五、隐式推理带来的可观测性难题

当中间推理被压缩进隐藏状态，外部系统只能看到最终输出，调试和审计难度会上升。传统显式推理文本至少可以被记录、抽检和规则过滤；循环深度模型则需要额外建设可观测性能力。建议至少记录以下指标：

• 每次请求实际循环次数及分布；
• 停止原因：达到上限、状态收敛、策略判定或其他；
• 隐藏状态的范数、变化幅度与异常波动统计；
• 不同循环预算下输出的一致性与差异；
• 超时、回退与低置信度请求比例；
• 输入输出审计日志与策略命中记录。

在百度智能云等通用云环境中，可借助容器平台、日志服务、监控告警等通用能力承载评测流水线与运行观测。但工具只是载体，关键是把“计算预算—输出质量—延迟成本”三者建立可追踪的关联。对于高风险场景，不能仅依赖模型自述，应结合输出审核、规则策略、人工抽检与离线评测。

六、工程落地建议

落地循环深度架构时，可按以下清单推进：

1. 定义任务分层：区分简单问答、复杂推理、代码生成等任务，分别设定循环预算。
2. 建立预算曲线：离线评测不同循环次数下的准确率、稳定性、延迟和成本，找到收益拐点。
3. 设置硬上限与早停：硬上限保证延迟可控，早停策略减少无效计算。
4. 准备回退路径：超时或状态异常时回退到固定轮数、缓存结果或人工处理。
5. 完善监控审计：记录循环次数、停止原因、状态统计与输出差异。
6. 做灰度与对照实验：按流量比例灰度，比较传统固定深度与循环深度的综合收益。
7. 关注训练稳定性：使用检查点、截断反传、随机深度与归一化策略，避免梯度异常。

七、适用场景与边界

循环深度更适合需要多步内部计算、但对显式推理文本长度敏感的任务，例如复杂问答、结构化推理、约束满足类问题和部分代码理解任务。对于简单分类、短文本抽取等任务，增加循环次数往往收益有限，反而增加延迟。对强审计场景，隐式推理需要额外治理手段，不能因为减少显式词元就忽视可解释性要求。

总体来看，循环深度不是“免费午餐”，而是一种把参数规模、计算深度和推理预算重新分配的设计。它的价值在于让模型在部署后仍能调节有效计算深度，但前提是训练策略、停止机制、容量模型与可观测性同步建设。对开发者而言，理解其计算图本质与工程边界，比追逐单一指标更重要；对企业而言，只有在评测、监控和回退机制完备后，循环深度才可能成为稳定可用的推理加速与能力扩展手段。