详细分析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 样本是：(ot,lt,At∗)\left(o_t,\ l_t,\ A_t^{*}\right)(ot,lt,At∗)其中：oto_tot：机器人当前观测，包括图像、机器人状态等；ltl_tlt：自然语言任务指令；At∗A_t^{*}At∗：人类示范或专家策略产生的未来一段动作，即专家动作块（Expert Action Chunk）。如果动作预测 horizon 为HHH，那么：At∗=[at∗,at+1∗,…,at+H−1∗]A_t^{*}=[a_t^{*},a_{t+1}^{*},\ldots,a_{t+H-1}^{*}]At∗=[at∗,at+1∗,…,at+H−1∗]因此，从数据集语义上说：RLinf 具身 SFT 的真正 label，本质上是专家动作，而不是语言 token。但是对于 π₀、Evo-1 这样的流匹配模型（Flow-Matching Model），训练时不会直接让网络输出At∗A_t^{*}At∗后和它做普通动作 MSE。专家动作首先和随机噪声组合成一个带噪动作状态，再把监督目标变换成某种速度场（Velocity Field）。因此还必须区分两层“label”：数据层 label：专家动作At∗A_t^{*}At∗；优化层 target：由专家动作、噪声和时间变量构造出来的 flow velocity。这是理解 RLinf VLA SFT 最重要的一点。截至当前 RLinf 主分支，框架已经原生支持 Evo-1 的全参数 SFT，并提供 OpenPI / OpenPI_RLinf、DreamZero、LingBot-VLA 等具身 SFT 数据与模型路径；Evo-1 官方示例明确采用 SFT → GRPO 的训练流程。 turn577980view02. 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,)iftorch.is_tensor(output):loss=outputelse:loss=output["loss"]因此，真正决定 SFT 数学含义的是：具体模型的 ForwardType.SFT ↓ 具体模型的 sft_forward()而不是SFTRunner。 turn267306view33. 数据到底是怎样组织的？3.1 原始数据不是普通的 input-label 文件具身训练数据通常按照机器人轨迹（Trajectory / Episode）存储。一条 episode 可以抽象为：τ={ (It,st,l,at)}t=0T−1\tau=\{(I_t,s_t,l,a_t)\}_{t=0}^{T-1}τ={(It,st,l,at)}t=0T−1其中：ItI_tIt：一个或多个相机图像；sts_tst：机器人本体状态；lll：任务自然语言描述；ata_tat：专家在时刻ttt执行的真实动作。例如 LIBERO 中 Evo-1 的观测由相机观测和机器人 state 构成，动作是连续 7-DoF，包括 6-DoF 末端执行器增量以及 gripper；同时每个 episode 有对应自然语言任务 prompt。3.2 Dataset 会把 trajectory 切成训练 sample训练时一般不会把整条 episode 一次送给模型，而是在某个时间点ttt采样：xt=(It,st,l)x_t=(I_t,s_t,l)xt=(It,st,l)然后取后续HHH个专家动作：At∗=[at∗,at+1∗,…,at+H−1∗]A_t^{*}=[a_t^{*},a_{t+1}^{*},\ldots,a_{t+H-1}^{*}]At∗=[at∗,at+1∗,…,at+H−1∗]因此可以把一个 SFT 样本理解成：{ language_instruction, camera_observation, robot_state, expert_action_chunk }这就是具身 SFT 最基本的数据结构。这里的动作分块（Action Chunking）非常重要：模型学的通常不是ot→ato_t\rightarrow a_tot→at而是：ot,lt→[at,at+1,...,at+H−1]o_t,l_t\rightarrow[a_t,a_{t+1},...,a_{t+H-1}]ot,lt→[at,at+1,...,at+H−1]这样模型一次推理可以生成未来一段控制序列。4. RLinf 中 input 和 label 应该怎样定义？这里最好分成三层。4.1 数据集层从行为克隆的语义看：InputXt={ It,st,lt}X_t=\{I_t,s_t,l_t\}Xt={It,st,lt}即：图像；本体状态；自然语言任务。LabelYt=At∗Y_t=A_t^{*}Yt=At∗即专家动作块。这与普通监督学习最接近。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 的参数。但从机器学习语义看，它仍然属于监督信息，不是推理条件。原因是训练过程中需要拿它生成带噪动作：xt=f(A∗,ϵ,t)x_t=f(A^{*},\epsilon,t)xt=f(A∗,ϵ,t)而在真正机器人推理时根本没有A∗A^{*}A∗，只会从随机噪声开始逐步生成动作。所以应当区分：条件输入（Conditioning Input）：图像、语言、state；训练监督（Training Supervision）：expert actions；训练辅助随机变量（Training Auxiliary Variables）：noise、flow time；实际回归目标（Optimization Target）：velocity。4.3 loss 层这里的 label 已经不一定是A∗A^{*}A∗本身。对于 flow matching：A∗→加入随机噪声→xtA^{*}\rightarrow\text{加入随机噪声}\rightarrow x_tA∗→加入随机噪声→xt同时构造：A∗,ϵ→v∗A^{*},\epsilon\rightarrow v^{*}A∗,ϵ→v∗模型预测：vθ(xt,t∣I,s,l)v_\theta(x_t,t\mid I,s,l)vθ(xt,t∣I,s,l)最后优化：L=∥vθ−v∗∥2\mathcal L=\|v_\theta-v^{*}\|^2L=∥vθ−v∗∥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 batchRLinf 使用DistributedSampler支持多 GPU 数据切分，并用StatefulDataLoader支持恢复训练时的数据迭代位置。 turn474000view67. Evo-1 一个 batch 中究竟有什么？evo1_sft_collate_fn最终组织出的主要字段包括：{"prompts":...,"images":..
