RLinf 具身模型 SFT 训练机制完整分析报告

详细分析RLinf框架中的具身模型的sft是如何训练的？训练数据是如何组织的？输入、label分别是什么？loss是什么？给出一个完整的分析报告

我会先把 RLinf 的官方论文、代码仓库和训练脚本对齐起来，重点追踪 SFT（Supervised Fine-Tuning，监督微调） 的数据流：数据格式 → tokenizer/processor → model input → label mask → loss 计算 → batch/并行训练。然后我会给你一份“从样本到梯度”的完整报告，尽量把具身模型部分讲到能直接对照代码。

目前已经确认：RLinf 现在把具身 SFT 单独做成了一条 examples/sft/train_vla_sft.py → SFTRunner → FSDPVlaSftWorker 的训练链路，而不是把它塞进 RL actor update 里；对 Evo-1，官方明确写的是 AdamW（AdamW Optimizer）+ cosine schedule（余弦学习率）+ flow-matching MSE（流匹配均方误差）。我接下来重点把 worker 里的 batch 字段和具体 loss 路径挖出来，因为这决定“input / label 到底是什么”。

关键点已经很清楚了：在 RLinf 里，“label”通常 不是 NLP SFT 那种单独的 labels=input_ids。对连续动作 VLA，离线示范中的 专家动作块（expert action chunk） 才是原始监督信号；以 π₀ / Evo-1 为例，模型在 forward 内部再采样噪声和时间，把专家动作转换成 流速度标签（flow-velocity target），最后做 MSE。Evo-1 代码甚至直接构造 target_velocity = actions_gt - noise，并用 action_mask 排除 padding 维度。

:::writing{variant=“document” id=“48271” title=“RLinf 具身模型 SFT 训练机制完整分析报告”}

RLinf 具身模型 SFT 训练机制完整分析报告

1. 结论先行

要理解 RLinf 中具身模型的 监督微调（Supervised Fine-Tuning, SFT） ，最关键的是不要套用纯语言模型 SFT 的思路。

在语言模型中，我们通常会把问题理解为：

• input：prompt + response token；
• label：response token；
• loss：token-level Cross Entropy。

但在 RLinf 的具身 视觉-语言-动作模型（Vision-Language-Action Model, VLA） 中，尤其是 π₀、π₀.₅、Evo-1 这类连续动作生成模型，情况完全不同。

从最抽象的角度，一个 SFT 样本是：

$$\left(o_t,l_t,A_t^{\ast }\right)$$

其中：

• $o_t$：机器人当前观测，包括图像、机器人状态等；
• $l_t$：自然语言任务指令；
• $A_t^{\ast }$：人类示范或专家策略产生的未来一段动作，即 专家动作块（Expert Action Chunk） 。

如果动作预测 horizon 为 $H$，那么：

$$A_t^{\ast }=[a_t^{\ast },a_{t+1}^{\ast },\dots ,a_{t+H-1}^{\ast }]$$

因此，从数据集语义上说：

RLinf 具身 SFT 的真正 label，本质上是专家动作，而不是语言 token。

但是对于 π₀、Evo-1 这样的 流匹配模型（Flow-Matching Model） ，训练时不会直接让网络输出 $A_t^{\ast }$ 后和它做普通动作 MSE。专家动作首先和随机噪声组合成一个带噪动作状态，再把监督目标变换成某种 速度场（Velocity Field） 。

因此还必须区分两层“label”：

1. 数据层 label ：专家动作 $A_t^{\ast }$；
2. 优化层 target ：由专家动作、噪声和时间变量构造出来的 flow velocity。

这是理解 RLinf VLA SFT 最重要的一点。

截至当前 RLinf 主分支，框架已经原生支持 Evo-1 的全参数 SFT，并提供 OpenPI / OpenPI_RLinf、DreamZero、LingBot-VLA 等具身 SFT 数据与模型路径；Evo-1 官方示例明确采用 SFT → GRPO 的训练流程。 turn577980view0

---

2. RLinf 中 SFT 的整体软件架构

RLinf 并没有在一个统一的 SFTLoss 里硬编码所有具身模型的 loss。

它的设计更接近：

训练入口
  ↓
SFTRunner
  ↓
FSDPVlaSftWorker
  ↓
模型专属 DataLoader
  ↓
batch
  ↓
model(
    forward_type=ForwardType.SFT,
    data=batch
)
  ↓
模型自己的 sft_forward()
  ↓
loss
  ↓
backward
  ↓
optimizer.step()

也就是说：

RLinf 统一的是 SFT 的训练控制流、分布式训练、梯度累积、checkpoint 等基础设施；真正的 input、label 如何解释，以及 loss 如何构造，是由具体 VLA 模型决定的。

当前标准入口 examples/sft/train_vla_sft.py 会创建训练集群和 FSDPVlaSftWorker，之后实例化 SFTRunner 并启动 worker。

SFTRunner 本身并不计算具身 SFT loss，而是反复调用 worker 的 run_training()，同时负责 global step、checkpoint、日志等控制逻辑。

在 FSDPVlaSftWorker 内部，核心接口可以高度概括成：

output = self.model(
    forward_type=ForwardType.SFT,
    data=batch,
)

if torch.is_tensor(output):
    loss = output
else:
    loss = output["loss"]

因此，真正决定 SFT 数学含义的是：

具体模型的 ForwardType.SFT
        ↓
具体模型的 sft_forward()

而不是 SFTRunner。 turn267306view3

---

3. 数据到底是怎样组织的？

3.1 原始数据不是普通的 input-label 文件

具身训练数据通常按照机器人 轨迹（Trajectory / Episode） 存储。

一条 episode 可以抽象为：

$$\tau =\{(I_t,s_t,l,a_t){\}}_{t=0}^{T-1}$$

其中：

• $I_t$：一个或多个相机图像；
• $s_t$：机器人本体状态；
• $l$：任务自然语言描述；
• $a_t$：专家在时刻 $t$ 执行的真实动作。

例如 LIBERO 中 Evo-1 的观测由相机观测和机器人 state 构成，动作是连续 7-DoF，包括 6-DoF 末端执行器增量以及 gripper；同时每个 episode 有对应自然语言任务 prompt。

---

3.2 Dataset 会把 trajectory 切成训练 sample

训练时一般不会把整条 episode 一次送给模型，而是在某个时间点 $t$ 采样：

$$x_t=(I_t,s_t,l)$$

然后取后续 $H$ 个专家动作：

$$A_t^{\ast }=[a_t^{\ast },a_{t+1}^{\ast },\dots ,a_{t+H-1}^{\ast }]$$

因此可以把一个 SFT 样本理解成：

{
    language_instruction,
    camera_observation,
    robot_state,
    expert_action_chunk
}

这就是具身 SFT 最基本的数据结构。

这里的 动作分块（Action Chunking） 非常重要：模型学的通常不是

$$o_t\to a_t$$

而是：

$$o_t,l_t\to [a_t,a_{t+1},...,a_{t+H-1}]$$

这样模型一次推理可以生成未来一段控制序列。

---

4. RLinf 中 input 和 label 应该怎样定义？

这里最好分成三层。

4.1 数据集层

从行为克隆的语义看：

Input

Xt={ It,st,lt}X_t=\{I_t,s_t,l_t\}Xt​={ It​,st​,lt​}

即：

• 图像；
• 本体状态；
• 自然语言任务。

Label

$$Y_t=A_t^{\ast }$$

即专家动作块。

这与普通监督学习最接近。

---

4.2 DataLoader / forward 层

对于 flow matching 模型，batch 中通常还会把专家动作一起传入 forward()。

因此你在代码里可能看到：

model(
    images=images,
    states=states,
    prompts=prompts,
    actions_gt=actions_gt,
)

很容易产生一个疑问：

actions_gt 既然被传进 model，那么它是不是 input？

从 PyTorch 函数调用形式看，它确实是 forward 的参数。

但从机器学习语义看，它仍然属于监督信息，不是推理条件。

原因是训练过程中需要拿它生成带噪动作：

$$x_t=f(A^{\ast },ϵ,t)$$

而在真正机器人推理时根本没有 $A^{\ast }$，只会从随机噪声开始逐步生成动作。

所以应当区分：

• 条件输入（Conditioning Input） ：图像、语言、state；
• 训练监督（Training Supervision） ：expert actions；
• 训练辅助随机变量（Training Auxiliary Variables） ：noise、flow time；
• 实际回归目标（Optimization Target） ：velocity。

---

4.3 loss 层

这里的 label 已经不一定是 $A^{\ast }$ 本身。

对于 flow matching：

$$A^{\ast }\to \text{加入随机噪声}\to x_t$$

同时构造：

$$A^{\ast },ϵ\to v^{\ast }$$

模型预测：

$$v_{\theta }(x_t,t\mid I,s,l)$$

最后优化：

$$\mathcal{L}=\Vert v_{\theta }-v^{\ast }{\Vert }^2$$

所以：

数据库里的 label 是 action，而送进 MSE 的 target 是 velocity。

下面用 RLinf 两个具体实现证明这一点。

---

5. Evo-1：RLinf 中最清楚的一套具身 SFT 实现

Evo-1 是目前非常适合拿来理解 RLinf SFT 的实例，因为它的数据、batch 和 loss 都在 RLinf 代码里暴露得非常直接。

Evo-1 本身约为 1B 参数，使用 InternVL3-1B 作为视觉语言 backbone，再连接基于 DiT 的 流匹配动作头（Flow-Matching Action Head） 。RLinf 已经提供 Evo-1 全参数 SFT 配置，并说明官方 recipe 使用 AdamW、带 warmup 的 cosine schedule 和 flow-matching MSE。

---

6. Evo-1 的训练数据组织

RLinf 的 Evo-1 SFT 数据读取不是简单指定一个 .json 文件。

data.train_data_paths 指向的是一个 Evo-1 dataset configuration YAML，然后由 Evo-1 自己的 LeRobot dataset 实现加载机器人数据。这个 YAML 可以定义多个 data group、最大 action/state 维度、最大相机 view 数等。 turn474000view5

其数据 pipeline 大致是：

LeRobot Dataset
      ↓
Evo-1 dataset config YAML
      ↓
LeRobotDataset
      ↓
DistributedSampler
      ↓
StatefulDataLoader
      ↓
evo1_sft_collate_fn
      ↓
training batch

RLinf 使用 DistributedSampler 支持多 GPU 数据切分，并用 StatefulDataLoader 支持恢复训练时的数据迭代位置。 turn474000view6

---

7. Evo-1 一个 batch 中究竟有什么？

evo1_sft_collate_fn 最终组织出的主要字段包括：

{
   
   
    "prompts": ...,
    "images": ..