递归深度VLA：潜空间迭代推理实现可扩展的测试时计算

如果你最近一直在碰视觉-语言-动作模型（VLA）相关的实操项目，应该会有同感：训练阶段恨不得把显存吃满，但推理阶段就这么僵在原地，一条前向通路从头走到尾，模型“会不会多想一步”完全不由你说了算。我最初想给手上的VLA方案加入隐测试-时计算规模化的能力时，试过加宽网络、试过堆注意力层，也试过照搬大语言模型那种长思维链，效果都不理想，最后把方向收敛到一个叫“递归-深度VLA”的结构上。这套结构的核心没那么玄：让模型在潜空间里反复迭代同一个推理块，推理阶段想要更多计算量就多跑几轮，像考试时跟监考老师多要一张草稿纸，从粗到细慢慢演算，而不是直接换一个更聪明的脑子。这篇文章就聊聊我踩过的坑、设计取舍，以及怎么把这种“隐性测试时计算”真正落地到VLA策略里。

1. 项目背景：VLA模型缺的那块拼图

1.1 单步前向的尴尬

先对齐一下背景。现在大家说的VLA，基本是把视觉观测、语言指令和本体状态拼在一起，经过一个多模态主干，最终映射成动作输出。训练用法通常很直接：喂一批专家演示，做行为克隆或者带扩散头的行为克隆，让模型见过足够多的“状态-动作”对以后，在部署时输入当前帧，输出下一时刻的关节角度或末端位移。

问题在于，这个推理过程是“一次性”的。无论当前场景是简简单单的抓取，还是桌面堆满遮挡、指令本身还很含糊的高难度操作，模型前向传播的FLOPs完全一样。更麻烦的是，你无法在部署时追加计算。模型的第一版推理结果如果不对，没有机制让它回头修一修。这在少数普通场景里看不出来，一旦遇到分布外状态，比如换了个光源、换了张桌子纹理，单步前向的脆弱性会被放得很大。

最开始我的想法很粗暴：既然一次前向不够，那就把模型做大。但VLA的视觉编码器和多模态主干本来就非常吃显存和延迟预算，把参数量翻倍，训练成本、推理延迟、部署显存全都跟着翻倍。而且行为克隆场景里，专家数据本身带着噪声，一个动辄几十亿参数的大模型在小规模机器人数据上反而更容易过拟合。显然，单纯堆参数不是正确答案。

1.2 测试时计算为什么值得做

在推理阶段去“追加计算”，其实是另一条路。训练阶段我们把模型压到够用就行，测试时根据任务的复杂度动态调整计算量。打个比方，考试的时候你可以先快速做一遍，时间剩得多再把每道题的草稿重新验算一遍；而不是平时刷题就刷到宇宙尽头。

大语言模型那边已经有类似“思维链”“推理时扩展”的做法，但那些方法大多建立在显式文本token序列上。模型先生成一串推理文字，再给出答案。这套思路搬到机器人控制上有几个硬伤：token序列生成慢，机器人控制循环里根本等不起；文本推理链经常胡说八道，生成“我现在应该向右移动”但实际动作却偏离目标；而且文本token和机器人动作之间的耦合并不紧，推理链越长，动作误差可能越大。

所以我更关注的是“潜空间里的迭代推理”这个方向。思想其实很容易理解：让模型带着视觉特征、指令特征和一小组可学习的隐变量，在同一个推理块里反复进行多步更新。每多跑一轮，隐变量就往“更接近正确动作分布”的位置挪一点。整个过程不产生一个多余的文本token，也不会把计算量浪费在自然语言符号上，完全是隐式的、连续空间里的推演。这就是“隐测试-时计算规模化”的含义：测试时用同样的算法、同样的模型权重，只放大迭代次数，就能获得更强的策略性能。

1.3 标题里的关键词拆解

项目标题里“递归-深度”指的是结构上不追求物理层数特别深，而是通过递归地调用同一个模块来获得“等效深层”的表征能力。这种操作在图像分类里早就有过，比如某些递归残差网络，反复使用同一个卷积块叠加多层效果；在VLA里，我们把这种思想放大成“策略级的迭代推理”。“潜迭代推理”则是强调所有推理过程不离开隐状态空间，中间步骤既不是文本，也不是离散动作token，而是一组连续向量。“隐测试-时计算”是指，这种计算扩展不依赖任何外挂模块，测试阶段只要在循环里调整迭代次数即可。

这套思路真正落地之后，带来的直接好处有三个：第一，模型参数量不变，推理成本随迭代次数线性增长，你可以按部署机器的算力动态调整；第二，训练时用一个统一的模型权重覆盖不同的“思考步数”，不需要为每个延迟档位单独训练模型；第三，潜空间迭代天然适合做多帧视觉特征的融合，比把两帧图像简单拼在一起更自然。接下来我重点拆解架构设计和实现细节。

2. 整体方案设计：把“再想一会儿”做成一个算子

2.1 架构总览

整个模型分成四大部分：视觉编码器、文本编码器、潜迭代推理核心、动作生成头。视觉编码器负责把当前相机画面切成patch并编码成一系列visual tokens，文本编码器把语言指令编码成cond tokens，本体状态则通过一个小型MLP压缩成一个state向量。视觉token和文本token并不直接进入动作头，而是作为交叉注意力的条件来源。

核心部分是一组固定数量的latent tokens，我习惯设成16个，维度与主干的隐藏层宽度一致。初始化时这组token可以从一个可学习的参数表直接拷贝，也可以由视觉特征池化后映射生成。前向时latent tokens会作为query，同时与文本token、视觉token做交叉注意力，再经过一个混合器和一个前馈网络，完成一轮“推理”。这个块结构被反复调用T次，每一轮都把latent tokens更新一遍。最终的动作头从最后一轮latent tokens里读出动作。

从抽象角度看，这个结构很像一个循环神经网络，但循环发生在特征维度和语义维度上，不是直接在隐藏单元上做简单递归。倒过来想，它也好比一个迭代求解器：给定条件以后，latent tokens在状态空间里朝着不动点方向收敛，每多迭代一轮，离策略需要的动作表征就更近一点。

2.2 为什么非要在潜空间里迭代

这里有个关键取舍：为什么不让模型直接生成一串中间的思考token？或者为什么不用一个深层Transformer把前向深度拉上去？

深层Transformer的问题前面提过，计算量固定、部署不灵活。而“文本式思维链”的问题在于动作空间和语言空间之间存在语义鸿沟。机器人的底层控制指令是高维连续向量，一步推错，后续所有“思考”都可能在错误的世界模型里打转。相反，潜迭代推理让模型在同一个连续空间里反复修正状态表征，路径是平滑的，不会因为离散符号化而损失信息。尤其在高频控制任务上，连续空间的迭代天然适合输出平滑的动作序列。

实际上这和数值计算里的“不动点迭代”非常像。线性方程组既可以一步直接求解，也可以用雅可比迭代反复逼近；迭代次数越多，数值解越接近真解。潜迭代推理就是把这个思想搬到了策略网络上：每一次循环都在隐式地执行一次“当前状态是否足够好”的修正。为了让这个修正过程稳定，我在设计推理块的时候加入了一个输出gate，初始化为零。这样前几轮推理不会一下把初始的latent tokens冲飞，模型可以先学会“不做多余修改”，再慢慢学会“如何修改”。

2.3 隐测试-时计算机制的基础

训练和推理阶段，迭代次数不一定相同。训练时我会让模型经历1到6次迭代，随机抽样；推理时可以把迭代次数拉到8次、16次甚至更多。这样做的目的是让模型学会“无论最终迭代到第几步，动作头都要能给出合理输出”。如果训练时只固定跑4步，推理时一旦变成8步，模型很容易在额外迭代中跑飞，输出动作变得激进。

所以训练阶段必须显式地让模型适应不同的“思考步数”。我的做法是：在每个训练步里先随机采样一个T，让模型自动向前跑T轮，动作头可以接在最后一轮，也可以把每一轮动作头输出全部保留下来做加权。为了加强中间监督，我对每一轮的动作预测都计算损失，只是越靠近中间步骤损失权重越低，比如说最后一轮权重1.0，倒数第二轮0.5，更早的轮次0.2。这样模型既不会被中间步骤的错误输出带偏，又能保证即使早停也能给出不差的结果。

3. 实操实现细节：从网络定义到训练配置

3.1 潜迭代块的实际代码结构

下面是一段核心迭代块的简化实现，风格上更像PyTorch，但我在自己的训练框架里也是按这个结构写的。重点不是每一行代码，而是几个关键设计点：交叉注意力、门控残差、权重共享。

import torch import torch.nn as nn class LatentReasoningBlock(nn.Module): def __init__(self, dim=768, num_heads=8, ff_dim=2048): super().__init__() self.norm1 = nn.LayerNorm(dim) self.norm2 = nn.LayerNorm(dim) self.cross_attn_text = nn.MultiheadAttention(dim, num_heads, batch_first=True) self.cross_attn_visual = nn.MultiheadAttention(dim, num_heads, batch_first=True) self.mixer = nn.Sequential( nn.Linear(dim, dim * 2), nn.GELU(), nn.Linear(dim * 2, dim) ) self.ffn = nn.Sequential( nn.Linear(dim, ff_dim), nn.GELU(), nn.Linear(ff_dim, dim) ) self.gate_scale = nn.Parameter(torch.zeros(1)) def forward(self, latent, text_tokens, visual_tokens): h = self.norm1(latent) h = self.cross_attn_text(h, text_tokens, text_tokens)[0] h = self.cross_attn_visual(h, visual_tokens, visual_tokens)[0] h = self.mixer(h) h = self.ffn(self.norm2(h)) gate = torch.tanh(self.gate_scale) return latent + gate * h

这里有两个容易被忽略的细节。

第一个是gate初始化为零，意味着刚初始化时整个推理块就是一个恒等映射。这对稳定训练至关重要。潜迭代块会被递归调用多次，如果一开始就输出很大的残留量，梯度会像雪球一样滚下去，几个step内loss就炸了。用tanh套上可学习标量，既保证了初始恒等，又让模型自己学习到底需要多大幅度的状态更新。

第二个是循环时同一个模块的权重是共享的，这等于训练了一个“迭代算子”，而不是训练了T个不同的网络层。共享权重能显著减少参数量，也迫使模型在所有迭代步上表现得一致；代价是如果算子学得不好，所有步都会受影响，所以训练时的迭代随机化和梯度缩放很重要。

主模型前向部分长这样：

class RecursiveLatentVLA(nn.Module): def __init__(self, dim=768, latent_len=16, num_heads=8, max_iter=8): super().__init__() self.latent_len = latent_len self.reason_block = LatentReasoningBlock(dim, num_heads) self.latent_tokens = nn.Parameter(torch.randn(1, latent_len, dim) * 0.02) self.action_head = nn.Sequential( nn.Linear(dim, 512), nn.GELU(), nn.Linear(512, 7) ) def forward(self, visual_tokens, text_tokens, state_vec, iter_steps=4): B, _, D = visual_tokens.shape latent = self.latent_tokens.expand(B, -1, -1) state_emb = state_vec.unsqueeze(1).expand(B, self.latent_len, -1) latent = latent + state_emb all_actions = [] for _ in range(iter_steps): latent = self.reason_block(latent, text_tokens, visual_tokens) all_actions.append(self.action_head(latent[:, 0, :])) final_action = all_actions[-1] return final_action, all_actions

这里的动作头只取了第一个latent token，实际工程中我一般会对16个token做mean pooling，再送入动作头，会更稳。不过为了代码简洁，示例里直接用第一个token。latent token初始化为很小的随机值，再叠加上state embedding，这样同一组初始token在不同本体状态下就有不同的推理起点，避免所有序列挤到同一个特征点上。

3.2 训练T随机化、BPTT截断与梯度缩放

因为推理块要被循环跑很多次，梯度会沿着时间维度往回传。直接展开16步跑反向传播，显存消耗相当于一个16倍深度的网络，大部分项目根本扛不住。我的做法是两件事配合。

第一，训练时的迭代次数不固定，从1到6之间随机采样。显存压力可控，同时模型天然学会了在不同步数下工作。推理时即使跑到16步，也不会因为“训练没见过这么多次迭代”而性能崩掉，前提是你加了后续要讲的一致性和中间监督。

第二，如果确实需要固定跑长迭代并回传梯度，可以用截断BPTT。也就是说，每N步切断一次计算图，只保留最近N步的梯度回传。配合梯度检查点（gradient checkpointing），把推理块的前向激活临时扔掉，反向时重新计算，显存能压下去一大截。对于N=8、latent_len=16、dim=768的配置，单卡跑8步迭代加视觉编码，实测显存占用大约比单步前向多出35%到50%，是可以接受的。

梯度缩放也容易踩坑。共享权重的推理块被调用了T次，反向时同一组参数的梯度被累加了T份。如果T在训练时随机变化，即使batch size固定，有效梯度规模也在变化。直接套用一个固定学习率，小T和大T的更新幅度会差很多。我在训练里给损失乘了一个缩放系数：1 / sqrt(T)，这样模型在不同迭代深度下更新幅度更均衡。这个细节不算精妙，但不加的话，训练曲线会像心电图一样抖动，非常难判断收敛情况。

3.3 训练损失设计：让多步迭代不白跑

基础损失是行为克隆。连续动作输出用MSE或者扩散损失；离散动作则用交叉熵。我强烈建议至少对最后两步动作头输出进行监督，而不是只监督最后一步。原因很简单：如果只监督最后一步，中间步骤的动作输出可以完全是垃圾，模型没有动力保证中间步骤的表征是合理的。推理早期步骤一旦跑偏，最后一步要花很大力气往回拉，推理时间拉长后反而更不稳定。

我自己常用的损失函数大概是这样的：

loss = 0.0 weight = 0.2 for i, act in enumerate(all_actions): if i == len(all_actions) - 1: loss += 1.0 * F.mse_loss(act, target_action) else: loss += weight * F.mse_loss(act, target_action) weight *= 1.5 latent_delta = torch.mean(torch.norm( all_latents[-1].detach() - all_latents[-2], dim=-1 )) consistency_loss = torch.clamp(latent_delta - 0.1, min=0.0) loss += 0.1 * consistency_loss

这个consistency_loss是个“软约束”：它不强制最后两步的latent向量完全一样，但会惩罚最后一步仍然发生剧烈变化。实验中最常见的失败模式是，模型在前几步快速朝目标方向移动，后面几步又开始在latent space里绕圈，最后一步动作输出自然就飘了。加入这个抑制项后，高迭代次数的输出明显更稳定。

另外，如果想进一步提高多步迭代的价值，可以做一个动作置信度头。从每一轮动作输出中抽一个特征，再加一个小MLP预测“该动作能不能成功执行”。这个置信度可以作为“是否要提前停止”的依据，后面推理时能用上。

3.4 推理阶段的动态计算配置

到了部署阶段，隐测试-时计算规模化的好处就体现出来了。同样的一个模型文件，放在低算力嵌入式平台上，就设iter_steps=2，保证实时控制；放在有GPU的工控机或者服务器上，就设iter_steps=8或者16，换更高的操作成功率，不需要换模型。

如果你知道任务的难度分布，还能做得更细。比如在模拟器里，先把任务分类成“简单”“正常”“困难”。简单任务跑2步，正常任务跑4步，困难任务跑8步。我在实验中甚至试过在推理阶段做一个动态早停：每跑一步，计算当前latent和上一步latent之间的余弦距离，如果连续两步的距离都小于某个阈值，就直接跳出循环，用当前动作输出。这个方案在很多场景下能把平均迭代次数从8降到4.7左右，成功率基本不掉。

还有一点值得注意：latent迭代虽然不是随机采样，但如果你把dropout保留在激活状态，每次迭代的语义会有微小扰动。部署时我通常固定eval模式，关掉dropout，保证迭代过程是确定性函数。否则同一个输入在不同机器上跑出不同动作，排查问题会变得非常痛苦。

4. 怎么验证“隐测试-时计算”真的可规模化

4.1 实验设计思路

我在一个自研的模拟操作环境里做了一套对照实验。任务包括推箱子、分拣彩色积木、戴遮挡抓取三组，难度递增。训练数据统一来自同一条专家策略收集的3万条演示，模型结构完全相同，训练配置完全相同；唯一的变量是推理时的迭代次数，从1、2、4、8一直拉到16次。在模型无关的前提下，如果成功率随着迭代次数上升而稳定上升，就说明隐测试-时计算确实能work。

这里要特别强调控制变量。很多人验测试时计算能力时喜欢顺带换掉视觉编码器或者动作头，结果性能变化根本说不清是哪一部分带来的。我们做这个项目时坚持所有checkpoint都固定住，只改iter_steps。同一份模型权重，在同一个环境里连续跑20组随机种子，每组任务重复50次，最后取平均成功率。

4.2 可扩展性曲线到底长什么样

放一张我在模拟实验里得到的典型结果表，注意这不是为了显示某个绝对数字，而是展示趋势。

从表里能看到一个关键规律：成功率提高速度是边际递减的。前几步迭代带来的增益最大，从8步到16步的提升很小，有的任务上还出现了轻微回落。这说明潜迭代推理不是“越多越好”，推理块学到的是一个快速收敛的迭代算子，一般在4到8步之间就接近不动点了。如果你在实验里发现继续增加迭代步骤成功率反而下降，那大概率是训练时的一致性约束太弱，或者中间监督没有做好，模型在长迭代时开始发散。

另一个值得关注的现象是：推理耗时增长不算线性，因为计算里包含了一次视觉编码的固定开销。这其实是好事，说明增加推理步数不像堆预计算那样会让延迟爆炸，迭代成本只占推理总耗时的一部分。

4.3 可视化和多步行为分析

为了验证“每一步都在干啥”，我把每轮迭代的latent向量做了PCA降维，投影到二维空间里观察轨迹。效果大概是这样：前两步latent会出现明显跳变，从初始点快速接近一个“条件语义中心”；中间几步在动作相关的低维方向上缓慢游走；最后两步基本只在一个很小的邻域内微调。如果把trajectory按迭代步数依次显示出来，很像一个人在正式落笔前先画几笔大纲，再逐步细化。

我还统计过中间动作输出的变化幅度。训练比较差的checkpoint会出现“第一轮输出一个很激进的偏移，第二轮马上又拉回来，第三轮再冲出去”的震荡行为。这种震荡在高迭代时特别伤，因为最终动作头读到的latent可能正好卡在一个不稳定的点附近。后续我在中间监督里把所有轮次动作输出都向专家动作对齐，震荡幅度立刻小了很多。

4.4 和“显式思维链”做一次对比

为了说服自己“潜迭代”确实比“文本链”更适合机器人控制，我也做了一个对照：把迭代推理块替换成一个小的语言模型解码器，让它先生成一段类似“我要先向右移动，再向下抓取”的推理文本，然后从文本embedding里解码出动作。结果不出意料，成功率低了不少，耗时却是潜迭代的8倍以上。语言符号带来的信息瓶颈在高频控制任务里非常致命，连续动作分布被压缩进一个离散词元序列，等于让一个游泳运动员先背出每一划的力学公式再下水。

5. 常见问题与排障速查

这部分是实操阶段最值得记下来的部分，我把这几轮调试里遇到过的典型问题、现象和解决办法整理成了下面这张速查表。

有一条排障经验特别想强调：永远先检查动作头的输入是不是“稳定输入”。我发现很多看似是迭代推理的问题，最后都出在latent向量经过多步更新后分布偏移，导致动作头面对一个从没见过的特征分布。所以每次加新结构时，我会打印最后一轮latent的均值、方差和最小值/最大值。一旦发现均值和训练时的初始latent相差太远，优先调整门控尺度，而不是去调动作头。

另外，收敛后的latent有一个我常用的简单评测指标：动作条件熵。把动作头输出的连续动作做一个小型高斯假设，计算每轮动作分布的对数似然。当迭代步入8步之后，动作分布方差应明显变小。如果方差反而变大，说明模型在犹豫，这时候把一致性损失权重调高基本都能找回稳定。

6. 后续可以往哪走

我个人在实现递归-深度VLA过程中最大的体会是，测试时计算扩展这件事，真正难的不是“把循环加上去”，而是让循环每一步都有意义。模型完全可以通过短路来假装思考，比如第一轮输出最终答案，后面几轮全在复制粘贴；也可以反过来，前面几轮乱试，最后一轮强行修正。这两种情况训练loss都不难看，但推理性能就是起不来。我的建议是，把“中间步骤质量”当成一种显式监督信号参与到训练里，否则循环越多，模型的噪声越大。

顺着这个方向往后做，我觉得有三个点特别值得探索。第一是把潜迭代和扩散动作头融合起来，让每一轮迭代都在做更精细的扩散去噪，现在扩散策略本身的生成式推理已经很强，如果迭代算子和扩散采样能共用一套收敛机制，潜力会更大。第二是引入某种“分支回溯”机制，在潜空间里同时维护多个候选latent序列，测试时用置信度选出最好的轨迹，这相当于把树搜索搬进潜空间。第三个方向是跨任务自适应：通过少样本prompt调整latent的初始化方式，让固定权重模型在新任务上不需要微调就能靠更多迭代步数取得更好表现。

最后再补一个实战提醒：如果你手头的VLA骨干已经训练得非常好，才想在后端接一个潜迭代模块，不要急着解锁全部迭代步数。花半天时间把冻结其他结构、只训练推理块和动作头的收敛流程跑通，再逐步放开其余模块。这套方法论说来朴素，却能省下你至少一周的调参时间。