ImageWAM — 图像编辑即世界动作模型

Do World Action Models Really Need Video Generation, or Just Image Editing? · SJTU / EIT / Tencent RoboticsX / THU · arXiv 2606.19531 (2026)

速览
动机·视频vs编辑
方法·架构
KV Cache机制
训练·推理
实验
复现评测
真机训练规划
相关工作对比
代码印证
评价与启发
自测

一句话

世界动作模型(WAM)真的需要"生成未来视频"吗?还是只要"想象一张编辑后的目标图"就够了? ImageWAM 用图像编辑模型替代视频生成:只建模 current→target 单帧变换,推理时甚至不解码那张目标图,而是把图像编辑去噪过程中产生的 KV cache 直接当作紧凑的"世界-动作上下文",喂给 flow-matching 动作专家。结果:追平视频 WAM,FLOPs 降到 1/6、延迟降到 1/4。

本页可靠性🟢源码/论文核对:方法公式、实验数字均逐条核对自 PDF 原文(arXiv:2606.19531v1);架构机制核对自仓库 src/imagewam/models/backbones/(mot.py/action_dit_omnigen2.py/omnigen2_video_expert.py)。解读与类比为学习者视角。原文:arXiv · 项目页 · 代码(HF collection: yuyangalin/imagewam)

速览卡片

内容
标题ImageWAM: Do World Action Models Really Need Video Generation, or Just Image Editing?
单位上海交大 / 东方理工(EIT) / 腾讯 RoboticsX / 清华 / 中关村学院
核心思想图像编辑模型(而非视频生成)当 WAM backbone;推理只跑一步编辑分支取 KV cache,不解码目标图
三个变体FLUX.2 ImageWAM(4B/9B,最强) · OmniGen2 ImageWAM · Ovis-U1 ImageWAM(1.1B DiT,最小)
动作头flow-matching Action Expert(DiT),通过 joint attention 读取编辑分支 KV
关键结果RoboTwin2.0-Rand 93.56 · LIBERO 平均 98.4 · LIBERO-Plus 83.1(FLUX.2 4B) · 真机 84.5(π0 55.8)
复现验证LIBERO 4套件 97.9%(论文98.4%) · 8×H20 · 1000 episodes · 32分钟 · 0 crash
效率延迟 1081ms→263ms,FLOPs 63.65→9.72(约视频 WAM 的 1/6)
是否需额外具身预训练(P.T.=✗),只在下游 benchmark 演示上训练即超越众多需预训练的 baseline
为什么值得学:它把"世界模型 = 预测未来视频"这条主流路线做了一次尖锐的解构——指出视频生成的三大浪费(见"动机"tab),并用图像编辑这一"天生同时需要理解+生成"的通用任务给出更省的替代。对理解 WAM / VLA / 世界模型的分野很有代表性。

动机:视频生成 WAM 的三大缺陷

先厘清概念梯队:VLA(vision-language-action) 直接从"观测+指令"预测动作;WAM(world action model) 在中间插入一步"视觉想象",先想象未来、再据此产生动作(reason-before-act)。主流 WAM 用视频生成来做这步想象。

VLA:(ot, l) → at:t+H   视频 WAM:(ot, l) → ôt+1:t+H+1 → at:t+H

论文指出,用视频生成当 WAM backbone 有三个结构性缺陷:

缺陷说明
① 推理昂贵要预测/处理跨多帧的稠密时空 token,去噪+解码开销大(表5:1081ms / 63.65 TFLOPs)
② 浪费在动作无关细节视频生成会精细建模与动作无关的时序外观(背景、纹理、光影变化),这些对"该怎么动"没有帮助
③ 长时想象误差误导动作长 horizon 的想象帧含几何畸变、空间布局不一致的伪影(图5),而动作是 conditioned 在这些帧上的 → 伪影会把动作带偏

关键洞察:机器人操作 = 指令引导的视觉变换

作者把操作任务重新表述为:给定当前图 + 语言指令,产生一张"任务完成后的目标图"。这恰好就是图像编辑(text-guided image editing)做的事——按指令修改源图、保留无关内容。于是他们只建模端点帧

ImageWAM:(ot, l) → ôedit ≡ ôt+H+1 → at:t+H

ôedit 是一张 source-conditioned 的单帧,概括了"当前观测在该任务指令下应发生的视觉变换"。

图像编辑预训练与策略学习天然对齐的三点(论文原话归纳)
instruction-to-change alignment:编辑模型学的就是"指令→视觉改变",正是策略需要的;
easier goal/change proxy:单张目标帧比整段视频更易作为目标/变化代理;
compact inference:一步编辑分支 forward 就够,不必展开稠密未来 token。
反直觉之处:既然只要目标帧,为何连目标帧都不解码?因为动作专家需要的不是像素,而是"编辑过程中蕴含的变换信息"——这信息在去噪 transformer 的 KV cache 里已经有了,解码成图反而多此一举。这是下一 tab 的核心。

整体架构(图2)

指令 l
"Put shoes into box"
❄ Text tokenizer
+ ❄ LLM
❄ VLM 理解
(冻结)
当前观测 ot
VAE Enc
🔥 Image Editing Backbone
(diffusion 分支,可训)
KV↓
🔥 Action Expert
(flow-matching DiT)
at:t+H

❄ 冻结(VLM/多模态理解模块) 🔥 可训(diffusion 编辑分支 + 动作专家)

三个组件

① Image Editing Backbone(编辑分支)

基于现成图像编辑模型(OmniGen2 / Ovis-U1 / FLUX.2)。输入当前观测 ot + 指令 l,本职是去噪生成"编辑后目标帧"。ImageWAM 复用它去噪过程中每层 transformer 的 KV cache 作为条件,而不只是拿它解码一张图。

② Action Expert(动作专家)

一个 flow-matching 的 DiT(见 ActionDiTOmnigen2)。把动作 chunk 编码成 token,通过 joint attention 读取编辑分支的 KV cache,预测动作速度场。

③ 冻结的 VLM 理解模块

编辑模型里负责编码指令/视觉上下文的 VLM 部分保持冻结,提供稳定的语言-视觉条件;只训练 diffusion 生成分支和动作专家。

为什么冻结 VLM、只训 diffusion 分支?(消融 Q2) 理解需要高层语义抽象,生成需要细粒度空间/结构细节,尤其在深层两者需求冲突。统一大模型里联合优化会互相干扰(improve generation 伤 understanding,反之亦然)。ImageWAM 解耦二者:冻结理解、只适配生成分支+动作专家 → 在非关键帧未来预测设定下超过 UniVLA / BagelVLA(表6)。

核心机制:KV Cache 当作"世界-动作上下文"

这是全文最关键、也最容易误解的一步。请分三层理解。

第一层:什么是这里的 KV cache

编辑分支是一个多层 transformer。去噪时,视觉 latent 先与指令(经冻结 VLM)交互,然后逐层做 attention。每一层 ℓ 都会算出 Key/Value 张量。ImageWAM 把这些逐层 KV 收集起来:

Ceditτ = { (Kτ, Vτ) }ℓ=1..L = feditτ(ot, l)  (式5)

τ 是随机采样的编辑去噪时间步。因为这份 cache 是在"视觉 latent 已经和指令充分交互之后"算出来的,所以它已经编码了"任务条件下的视觉变换信息",而无需把最终目标图解码出来。

第二层:动作专家怎么用它(joint attention)

关键实现在 mot.py(Mixture-of-Transformers)。编辑专家和动作专家逐层并行前进,在每层的 attention 里,动作 token 的 Query 去 attend 拼接了编辑分支 K/V 的联合序列

Attn(Qaction, [Kaction; Kedit], [Vaction; Vedit])

也就是说,动作 token 不是"看一张图",而是"直接钻进编辑模型的中间推理里,读它每一层关于'该怎么变'的内部表征"。这就是论文说的 transfers the image editing model's internal reasoning process to robot control

类比:视频 WAM 是"先把电影拍完(解码未来帧),再让人看电影猜动作";ImageWAM 是"不拍电影,直接读导演脑子里的分镜草稿(KV cache)"——省掉了渲染成像的全部开销,还避开了成像伪影。

第三层:Fast-WAM 变体对照

为公平对比,作者还实现了 Fast-WAM 式的视频 WAM 变体:未来视频 token 只在训练时用于 video co-training,推理时移除,动作专家仅用"当前观测+指令"产生的 KV。这给出一个"和 ImageWAM 一样没有未来 token"的视频 WAM 基线。ImageWAM 在此基础上进一步把"视频"换成"图像编辑"。

一句话记住:ImageWAM 的"世界模型输出"不是一张图、不是一段视频,而是图像编辑去噪 transformer 每一层的 (K,V)——一组紧凑、任务条件化、聚焦"变化"的中间表征,通过 joint attention 直接注入动作专家。

训练:两个 flow-matching 目标联合优化

① 图像编辑目标 Limg

让编辑分支学会预测任务相关的端点帧。目标帧 ot+H+1 经 VAE 编码成 latent z*;采噪声 εz、图像流时间 r,构造插值 latent,diffusion 分支预测速度场(flow matching):

zr = (1−r)z* + rεz  (式6)
Limg = E‖ uϕ(zr, r | ot, l) − (εz − z*) ‖²  (式7)

这个目标保住编辑分支"预测任务相关未来视觉状态"的能力,也逼它的 KV cache 编码有用的变换信息。

② 动作 flow matching 目标 Lact

动作 chunk a* 采噪声 εa、动作流时间 s,构造插值,动作专家conditioned 在编辑 cache Ceditτ 上预测动作速度场:

as = (1−s)a* + sεa  (式8)
Lact = E‖ vθ(as, s | ot, l, Ceditτ) − (εa − a*) ‖²  (式9)

注意两个不同的"时间":s 是动作 flow-matching 时间,τ 是图像编辑去噪时间步。训练时随机采 τ,让动作专家见到去噪不同阶段的 cache。

总损失 L = Lact + Limg (联合优化)

推理:一步编辑 forward,不解码图

推理时既不做完整未来视频生成,也不解码完整编辑图。固定一个编辑去噪时间步 τ*,只跑一次编辑分支 forward 取 cache,然后动作专家据此去噪产生动作:

Ceditτ* = feditτ*(ot, l) → ât:t+H ~ pθ(at:t+H | ot, l, Ceditτ*) (式10-11)
对比视频 WAM 要去噪+解码跨多帧的稠密时空 token,ImageWAM 只算一组逐层编辑 cache 直接用。既保住 reason-before-act 原则,又避开稠密未来 token 的实例化。

实验设置

关键差异:ImageWAM 不用额外具身预训练(P.T.=✗),只在下游 benchmark 演示上训练,却超越许多需要预训练的 VLA/WAM。评测 benchmark:LIBERO、LIBERO-Plus、RoboTwin 2.0,外加真机 Dobot XTrainer 双臂 4 任务。

评测协议矩阵

评测块Benchmark / 平台任务与数据为什么这样测本地复现对齐
标准仿真LIBEROSpatial/Object/Goal/Long 四套件;每套件 10 tasks;每任务 500 demos;2 视角拼接 224×448,动作 chunk=16。确认“图像编辑式 WAM”在常规 VLA benchmark 上不掉点,并与 π0/π0.5/Motus/FastWAM 对齐。已用官方 FLUX.2 4B checkpoint 跑全量 LIBERO:97.9%,论文 98.4%,差 -0.5pp,基本对上。
强 OOD 仿真LIBERO-PlusCamera/Robot/Language/Light/Background/Noise/Layout 七类扰动。检验 ImageWAM 是否真的利用“任务相关视觉变化”而不是记住固定视角/背景。未本地复现;页面记录论文表格。
双臂仿真RoboTwin 2.0单策略覆盖所有任务;clean + randomized;论文训练含 2500 clean + 25000 randomized trajectories,评测每任务 100 trials。验证图像编辑先验在更复杂双臂和强随机化设置下是否成立。未本地复现;训练成本约 8×H20 5 天。
真实双臂Dobot XTrainer4 个真机任务,每任务约 100 demos,评测 50 trials/任务;覆盖长程、可变形、遮挡、精细控制。验证不用额外具身预训练的 ImageWAM 是否能在真实机器人上超过 VLA/WAM 基线。未复现;硬件与数据不可用。
效率测试同模型推理链路比较完整图像编辑、KV cache、prefix-only attention、torch.compile、CUDA graph。证明 ImageWAM 的卖点不仅是成功率,也包括不解码目标图带来的闭环效率。本地 LIBERO 复现未报告独立延迟;论文表格为准。

RoboTwin 2.0(表1)

方法P.T.CleanRand.Avg
π065.9258.4062.16
π0.582.7476.7679.75
Motus88.6687.0287.80
FastWAM91.8891.7891.83
ImageWAM93.2093.5693.38

LIBERO(表2)与 LIBERO-Plus(表3)

LIBERO 四套件平均:ImageWAM 98.4(π0.5 96.9,与视频 WAM 相当)。LIBERO-Plus(更强分布偏移,含 Camera/Robot/Language/Light/Background/Noise/Layout 七类扰动)三变体平均成功率:

方法P.T.CameraRobotLanguageLightBackgr.NoiseLayoutAvg
OpenVLA-OFT56.431.979.588.793.375.874.269.6
π013.86.058.885.081.479.068.953.6
FastWAM16.444.568.978.253.737.760.751.5
ImageWAM(OmniGen2)80.049.270.982.669.477.171.871.8
ImageWAM(Ovis-U1)63.358.475.486.366.775.274.671.2
ImageWAM(FLUX.2 4B)80.850.391.498.185.593.880.583.1
ImageWAM 在 Camera 扰动上碾压(80.8 vs π0 的 13.8)——因为 source-conditioned 编辑上下文帮助策略聚焦"任务相关视觉变化"而非过拟合固定视角。

真机(表4)与效率(表5)

方法真机 Avg延迟TFLOPs中间态
π055.8
π0.572.3
FastWAM-IDM79.01081 ms63.65Video
FastWAM(1 Step)302 ms13.21Cache
ImageWAM84.5263 ms9.72Cache

真机四任务(叠三碗/叠毛巾/开抽屉存马克笔/挂杯)ImageWAM 全部最优,T2(叠毛巾,可形变物体)增益最大(+9 vs FastWAM)。

消融要点(4.4)

  • Q1 能换编辑模型吗?能。OmniGen2/Ovis-U1/FLUX.2 都超过 FastWAM,越强的编辑 backbone 策略越鲁棒 → 不绑定特定 edit 模型。
  • Q2 为何不用统一理解-生成模型?理解要语义抽象、生成要空间细节,深层冲突;解耦(冻结理解+只训生成分支)优于 UniVLA/BagelVLA。
  • Q3 编辑 backbone 更大更好吗?FLUX.2 4B→9B 平均 83.1→85.2,主要提升在 Robot/Language/Background/Layout;但 Camera/Light/Noise 非单调 → 规模有益但依赖 cache 与扰动类型的对齐。

训练/评测资源配置 🟢论文核对

来源:PDF §5.2 训练细节 + 表8(通用超参)/表9(数据集配置)/表10(训练成本)。

配置
训练 GPU8× NVIDIA H20(所有变体统一)
分布式策略DeepSpeed ZeRO-1;FLUX.2 9B 因显存改用 ZeRO-2
精度 / 优化器bf16 · AdamW(β=0.9,0.95) · lr 1e-4 · warmup-cosine · grad clip 1.0
推理硬件(测效率)单卡 A6000

训练成本(表10)

Benchmark模型时长Batch/GPU
LIBEROOmniGen218 小时12
LIBEROOvis-U118 小时16
LIBEROFLUX.2 4B18 小时10
LIBEROFLUX.2 9B1.6 天12
RoboTwinOmniGen2 / FLUX.2 4B5 天48†
Real-WorldOmniGen218 小时16

† 有效 per-GPU batch,含 3 步梯度累积。LIBERO 训 10 epoch、RoboTwin 5 epoch、真机 10 epoch。

门槛解读:H20(96GB)是国内合规的大显存卡,8 卡即可复现。LIBERO 单实验约 18h(≈1 GPU·天量级×8)相对亲民;RoboTwin(5万+轨迹)要 5 天×8 卡是主要开销。推理侧一张 A6000(48GB)即可,延迟 263ms 满足实时控制。若只有 24-48GB 卡,可优先跑最小的 Ovis-U1(1.1B DiT)变体。

复现评测:FLUX.2 4B × LIBERO 全量

🟢实测复现 在 ICL(8× NVIDIA H20, 96GB/卡)上,用官方 release checkpoint ImageWAM-FLUX.2-4B-LIBERO 完成全量 LIBERO 4 套件评测。总成功率 97.9%,论文报告 98.4%,差异 0.5pp 在统计波动范围内,复现成功。

评测结果总览

97.9%
Overall 成功率
论文 98.4%
1000
总 Episodes
40 任务 × 25 trials
32min
总评测时间
8×H20 满载
0
Crash / 系统失败
全部正常退出

套件级成功率(可视化对比论文)

libero_spatial
96.8%
libero_object
98.4%
libero_goal
98.0%
libero_10
98.4%
Overall
97.9%

条形 = 实测 | 橙线 = 论文报告(98.4% 平均)

逐任务热力图(40 任务 × 25 trials)

颜色深度 = 成功率(绿=100%,黄=92-96%,橙=84-88%)

libero_spatial(96.8%)

0
1
2
3
4
5
6
7
8
9

libero_object(98.4%)

0
1
2
3
4
5
6
7
8
9

libero_goal(98.0%)

0
1
2
3
4
5
6
7
8
9

libero_10(98.4%)

0
1
2
3
4
5
6
7
8
9

hover 查看具体数值。8 个非满分任务(共 21/1000 失败 trial),最低 84%(spatial task5: "pick up bowl on ramekin"——需精准定位堆叠物体)

复现 vs 论文对比表

套件论文报告我们复现差异判定
libero_spatial96.8%
libero_object98.4%
libero_goal98.0%
libero_1098.4%
Overall98.4%97.9%-0.5pp复现成功
论文仅报告 4 套件平均 98.4%,未逐套件列出。差异 0.5pp 在 25 trials/任务的 95% 置信区间(±2-3pp)之内。

评测配置

配置
硬件8× NVIDIA H20 (96GB/卡), ICL 集群
CheckpointImageWAM-FLUX.2-4B-LIBERO 官方 release (model.pt, 9.04GB)
骨干FLUX.2-klein-base-4B + FLUX.2-dev AE + Qwen3-4B
评测规模4 套件 × 10 任务 × 25 trials = 1000 episodes
并行策略max_tasks_per_gpu=4, chunk_size=1 → 32 并发 + 8 pending
GPU 峰值显存74.6 GB / 卡(4 任务共享时)
渲染MUJOCO_GL=osmesa (headless, 无显示器)
action_horizon16 步
replan_steps12 步
总耗时~32 分钟 (15:55 → 16:27)

部署踩坑与经验

踩坑 Top 3(完整闭环见部署记录)
#问题根因解决
1uv sync 编译 mmcv-full 失败只需 shared extra,uv sync 会锁全量(含 dim/mmcv)改用 uv pip install -e ".[shared]"
2LIBERO editable 安装后 import 失败顶层 libero/ 无 __init__.py → MAPPING 空PYTHONPATH 注入 third_party/LIBERO
3推理时 No module named 'hydra'worker 子进程用系统 python.env.local 补 PYTHON_BIN 指向 .venv
复现要点总结
① 只装 [shared] extra,不碰 dim/mmcv
.env.local 必须设 PYTHON_BIN + LIBERO_WORKER_ENV_SOURCE
③ LIBERO 首次 import 有交互向导,headless 需 echo N | python -c 'import libero.libero' 预生成 config
④ 图像方向:get_libero_image()[::-1,::-1] 180° 旋转是正确的(抽帧验证为正立场景)
⑤ HF gated 模型需 token + license 同时满足

复现命令

# SSH 连接开发机
ssh -p 443 root@10.82.96.110

# 环境准备
cd /robot/bionic-control-data/czy/projects/ImageWAM
source .venv/bin/activate
unset ALL_PROXY HTTP_PROXY HTTPS_PROXY http_proxy https_proxy all_proxy
export MUJOCO_GL=osmesa PYOPENGL_PLATFORM=osmesa
export PYTHONPATH=$PWD/third_party/LIBERO

# 完整评测(默认参数 = 4套件 × 25 trials × 8 GPUs)
bash scripts/flux2/run_eval_flux2_libero.sh

# Smoke 快速验证(2 分钟)
NUM_GPUS=2 TASK_SUITE_NAMES='[libero_spatial]' NUM_TRIALS=2 \
  bash scripts/flux2/run_eval_flux2_libero.sh

真机训练规划:从采集数据到部署

🟢实践指南 本节基于代码仓库的训练流程分析 + 论文真机实验配置,给出从真机数据到 ImageWAM 部署的完整路径。

核心结论:只需后训练(fine-tune),不需要具身预训练。
论文所有实验(Table 1-4)都标注 P.T. = ✗。ImageWAM 直接在下游演示数据上训练即超越需要预训练的 baseline(π0/π0.5)。论文真机实验也只训了 18 小时。

数据要求:标准 Episode 即可

是的,标准的 state-action episode + 相机图像 + 语言指令就是全部。不需要特殊标注、不需要人类视频、不需要仿真对。

每条 Episode 需要包含

数据项格式说明
相机图像序列RGB 视频/图像帧(≥1个视角)主相机(固定/第三人称)+ 可选腕部相机
动作序列每时间步的 action 向量7-DoF(单臂EE) 或 14-DoF(双臂EE):xyz + rpy/quat + gripper
状态序列每时间步的 state 向量关节角/末端位姿 + gripper 状态
语言指令一条自然语言字符串描述该 episode 完成的任务,如 "把杯子放到盘子上"
无额外标注:不需要目标图像标注、不需要奖励信号、不需要成功/失败标签(只用成功的演示)。ImageWAM 会自动把 episode 首帧当源图、末帧当编辑目标帧。

两个组件分别用什么数据训练?

ImageWAM 内部有两个可训组件,它们联合训练(同一份数据,一个 loss 函数同时优化两者):

图像编辑分支(世界/动态模型)

训练目标:从"当前帧 + 指令"预测"任务完成后的目标帧"

用到的数据

  • Episode 首帧图像(当前观测 ot
  • Episode 末帧图像(编辑目标 ôedit
  • 语言指令(编辑条件)

它学到的:理解"pick up the bowl"意味着碗从桌上移到了盘子里的视觉变换

Limg = ‖ uϕ(zr, r | ot, l) − (ε−z*) ‖²

动作专家(扩散策略)

训练目标:给定编辑分支 KV cache + 当前观测 + 本体感知,预测 action chunk(16步)

用到的数据

  • 每个时间步的 (state, action) 对
  • 当前帧图像
  • 编辑分支产出的 KV cache(训练时随机采 τ)

它学到的:在"世界想象的条件"下执行具体的运动控制

Lact = ‖ vθ(as, s | ot, l, Cedit) − (ε−a*) ‖²
总损失 L = Lact + Limg (联合优化,一份数据两个目标)
关键点:你不需要分别准备两份数据。一份标准 episode 数据同时训练两个组件——图像编辑分支自动取首末帧学视觉变换,动作专家用每步的 state-action 学控制。

单臂 vs 双臂配置

配置单臂 + 夹爪双臂 + 夹爪
ACTION_DIM7(xyz + rpy + gripper)14(左臂7 + 右臂7)
状态维度8(7关节角 + gripper)16(双臂各8)
delta_action_dim_mask[true×6, false](位姿用delta,gripper用绝对)[true×6, false, true×6, false]
相机建议固定相机 + 腕部相机(横向拼接 224×448)固定相机 + 双腕部相机(或固定+1腕,见下)
训练时长参考~18h(8×H20,论文真机规模)~18-24h(数据可能更多)
模型变体推荐FLUX.2 4B(最强)FLUX.2 4B(显存够,14-DoF 论文 RoboTwin 验证过)
双臂 14-DoF 已验证:论文 RoboTwin 评测就是 14-DoF 双臂 + 3 相机,action_dim=14,proprio_dim=14,已证明可行。

相机配置与图像处理

推荐配置

方案相机数拼接方式输入尺寸适用
A(标准)固定 + 腕部horizontal(左右拼接)224 × 448单臂
B(紧凑)固定 + 左腕 + 右腕robotwin layout(compact_288x256)288 × 256双臂
C(简单)仅固定相机无拼接224 × 224任务简单时

ImageWAM 对图像方向敏感——确保送入模型的图像是正立的(桌面在下)。训练和推理必须一致。

训练流程(完整步骤)

Phase 0: 数据准备

将真机采集的 episodes 转为 LeRobot v2/v3 格式(parquet + mp4)。每条 episode 必须有:

  • 连续的 RGB 帧序列(视频)+ 对应的 action/state 数值序列
  • 一条描述任务的语言指令
  • 推荐 ≥50 episodes/task(论文真机每任务约 50-100 条)

Phase 1: 预计算(自动化)

# 1. 预计算 Qwen3 文本 embedding cache(只需跑一次,加速后续训练)
GPU_PER_NODE=8 TASK_TYPE=real FLUX2_VARIANT=4b PRECOMPUTE_QWEN3_CACHE=true \
  bash scripts/flux2/run_train_flux2_klein_imagewam.sh

# 2. ActionDiT 初始化权重(自动从 FLUX.2 骨干提取,无需手动)
#    脚本检测 ACTION_INIT 不存在时自动调用 preprocess_action_dit_flux2.py

Phase 2: 训练

# 环境变量
export DATA_ROOT="/path/to/your/real_data"
export FLUX2_SRC="./third_party/flux2"
export FLUX2_AE_MODEL_PATH="./checkpoints/flux2/FLUX.2-dev/ae.safetensors"

# 启动训练(8×H20,ZeRO-1,~18h)
GPU_PER_NODE=8 \
TASK_TYPE=real \
FLUX2_VARIANT=4b \
bash scripts/flux2/run_train_flux2_klein_imagewam.sh

Phase 3: 评测 & 部署

# 使用训练产出的 checkpoint
export CKPT_PATH="./runs/train/YYYYMMDD_HHMMSS/checkpoints/checkpoint_best.pt"
export DATASET_STATS_PATH="./runs/train/YYYYMMDD_HHMMSS/dataset_stats.json"

# 推理延迟: ~263ms/step(单卡 A6000),满足实时控制
# action_horizon=16, replan_steps=12(每 12 步 replan 一次)

训练超参数推荐

参数来源/说明
learning_rate1e-4论文所有实验统一值
num_epochs10论文 LIBERO/真机统一 10 epoch
batch_size (per GPU)10-12H20 96GB 下 FLUX.2 4B 的极限
gradient_accumulation1-3有效 batch = per_gpu × 8卡 × accum
optimizerAdamW (β=0.9, 0.95)标准配置
lr_schedulercosinewarmup 5%
weight_decay1e-2论文配置
mixed_precisionbf16H20 原生支持
ZERO_STAGE1(4B)/ 2(9B)4B 足够 ZeRO-1
action_horizon16预测 16 步动作
replan_steps12执行 12 步后重新规划
endpoint_frames_onlytrueImageWAM 核心:只取首末帧

数据量 vs 预期效果

数据规模任务数预期效果参考
50 eps/task × 4 tasks = 2004~80-85% 成功率论文真机 84.5%(4任务)
50 eps/task × 10 tasks = 50010~85-95%类比 LIBERO-10
50 eps/task × 40+ tasks40+~95%+LIBERO 规模(我们复现 97.9%)
数据质量 > 数量:ImageWAM 对演示质量敏感。确保演示是流畅的、成功的、无过度犹豫/重试的。论文用了 no-ops 过滤(去除静止帧)+ nonidle_filter(去除空闲段)。

方案选择决策树

Q1: 你有多少 GPU 显存?
├── 8×H20 (96GB) 或 8×A100 (80GB) → FLUX.2 4B(最强,推荐)
├── 8×3090/4090 (24GB) → OmniGen2 或 Ovis-U1(更小)
└── 单卡推理部署 → 推理只需 1×A6000(48GB) 或 1×H20

Q2: 训练时间预算?
├── ≤1天 → FLUX.2 4B / OmniGen2(18h,8×H20)
├── 2-5天 → 可加大数据量或用 FLUX.2 9B
└── 极致速度 → Ovis-U1(1.1B DiT,最快但略弱)

Q3: 单臂还是双臂?
├── 单臂 7-DoF → ACTION_DIM=7, proprio_dim=8
└── 双臂 14-DoF → ACTION_DIM=14, proprio_dim=16(RoboTwin 配置已验证)

与其他方案对比:为什么选 ImageWAM

方案是否需要预训练数据要求推理延迟真机效果
π0 / π0.5(大规模多机器人数据)预训需 10k+ hrs~300ms55.8-72.3%
ACT / Diffusion Policy~50-100ms无 WAM 加持
FastWAM(视频WAM)1081ms79.0%
ImageWAM同(state-action eps)263ms84.5%
选 ImageWAM 的理由
① 不需要预训练——直接在你的真机数据上训就行
② 推理 263ms 满足实时控制(10Hz replan 够用)
③ 论文真机最强(84.5% vs π0 的 55.8%)
④ 支持单臂/双臂/多相机(代码已有完整适配)
⑤ 生态优势——基于 FLUX.2,图像编辑社区持续推进的骨干

部署踩坑预警(基于我们的复现经验)

#解决
1uv sync 拉全量依赖编译失败只装 [shared] extra:uv pip install -e ".[shared]"
2LIBERO/第三方包 editable 安装后 import 失败用 PYTHONPATH 注入,不改第三方代码
3多进程 worker 找不到 venv.env.local 设 PYTHON_BIN 指向 .venv/bin/python
4HF gated 模型下载权限需要 token + 已接受 license 双重验证
5图像方向不一致导致成功率为0确保训练/推理图像都是正立的(抽帧验证)
6checkpoint 文件名与文档不一致ls 实际文件为准,不信 README

执行 Checklist










三种"生成模型服务于动作"的范式对比

"预测未来图像/视频到底有没有用?"是当前 WAM 领域最核心的争论。ImageWAM、DiT4DiT、DynaGuide 分别给出了三种不同但互补的答案。

核心主张对比

维度ImageWAMDiT4DiTDynaGuide
核心主张图像编辑的 KV cache 比视频/图像像素更有用视频生成的中间特征比像素输出更有用动态模型的梯度比条件化训练更灵活
生成模型角色编辑分支跑一步 forward,取逐层 KV视频 DiT 做 teacher,蒸馏特征给 action DiT动态模型预测未来潜在状态,梯度引导去噪
推理时生成图像?否(只取 KV cache)否(teacher 推理时丢弃)否(只在潜在空间预测)
像素输出不需要不需要不需要
生成模型骨干FLUX.2(图像编辑)Cosmos-Predict2.5-2B(视频生成)自训动态模型(DinoV2 潜在空间)
训练时用视觉监督?是(L_img 监督编辑分支)是(视频生成监督 Video DiT)是(动态模型单独训预测未来潜在)
动作模型flow-matching Action DiTflow-matching Action DiT预训练 Diffusion Policy(不修改)
预训练要求无具身预训练(P.T.=✗)视频预训练(Cosmos),可选具身预训练需预训练策略 + 动态模型

它们在说同一件事的不同方面

共识:三者都认为生成模型的价值不在于像素输出,而在于其内部编码的物理/语义信息。推理时都不解码完整图像/视频。

ImageWAM 的回答

"图像编辑模型去噪一步产生的 KV cache 已经编码了足够的'视觉变换信息',不需要解码成图。而且图像编辑比视频生成更适合——因为操作本质是 source→target 的单帧变换。"

推理保留编辑分支(取 KV),263ms

DiT4DiT 的回答

"视频生成模型的中间去噪特征是最好的动态表征。但推理时不需要整个视频模型——用蒸馏把知识压缩到 action DiT 里就行。视频生成是 scaling proxy,不是推理工具。"

推理只跑 action DiT(teacher 丢弃),更快

DynaGuide 的回答

"不修改策略,只用外部动态模型的梯度在去噪过程中'拉'动作方向。动态模型在 DinoV2 潜在空间预测未来,不生成像素。策略和引导完全解耦。"

推理:策略去噪 + 动态模型梯度引导

"预测图像没必要"——三者怎么看?

表面上 DiT4DiT 说"预测图像没必要"而 ImageWAM 还用了图像编辑模型,看似矛盾。但实际上:

预测像素有必要吗?生成模型有必要吗?训练时视觉监督有必要吗?
DiT4DiT❌ 推理不需要✅ 训练时 teacher 需要✅ 视频生成是最好的 proxy
ImageWAM❌ 推理不解码✅ 推理时保留编辑分支取 KV✅ L_img 监督编辑分支
DynaGuide❌ 完全在潜在空间✅ 动态模型相当于轻量世界模型✅ 动态模型需要训
三者的真正分歧不是"要不要图像",而是"推理时保留多少生成能力"
• DiT4DiT 最激进——训练完就丢掉视频模型,推理零开销
• ImageWAM 保守——保留编辑分支一次 forward(+263ms),换取更精准的世界想象
• DynaGuide 正交——不改策略本身,用外部动态模型在推理时注入物理信息

效果与效率对比

指标ImageWAM (FLUX.2 4B)DiT4DiT (Cosmos 2B)DynaGuide
LIBERO 平均98.4%98.6%—(未评测)
RoboCasa-GR150.8%
RoboTwin-Rand93.56
CALVIN70%(引导成功率)
真机84.5%(4任务)G1 humanoid(7任务)72-80%(cup preference)
推理延迟263ms更快(无 teacher)较慢(多步梯度计算)
训练 GPU8×H20, 18h32 GPU中等
具身预训练不需要可选(GR1 数据)不需要

适用场景差异

场景最佳选择原因
固定任务集、追求效果ImageWAM无预训练、效果最强(LIBERO 98.4%, 真机 84.5%)、推理实时
大规模预训练、追求泛化DiT4DiT视频做 scaling proxy,10× 数据效率,zero-shot 潜力
已有预训策略、推理时灵活引导DynaGuide不改策略,即插即用,支持正负多目标引导
资源有限(8 GPU 以下)ImageWAM (Ovis-U1)1.1B DiT 最小变体
人形机器人高自由度DiT4DiT已在 29-DoF GR1 上验证

启发:生成模型在机器人中的三种用法

① 条件提供器
ImageWAM: KV cache
|
② 知识蒸馏源
DiT4DiT: teacher→student
|
③ 梯度引导器
DynaGuide: ∇ guidance
总结:三者不矛盾,而是在"生成模型如何服务于动作"这个问题上探索了三条互补的路径。未来方向可能是它们的融合——用图像编辑/视频的 KV cache 做训练时的 teacher(DiT4DiT 思路),推理时用动态模型梯度做 test-time 引导(DynaGuide 思路),编辑分支提供 fallback 条件(ImageWAM 思路)。

代码印证:机制在仓库哪里

🟢源码核对 仓库 ~/projects/ImageWAM/,推荐从 FLUX.2 变体入手。核心在 src/imagewam/models/backbones/

① MoT:编辑专家 + 动作专家的 joint attention

mot.py(Mixture-of-Transformers)是 KV 融合的落点。它校验所有 expert 层数/头数一致,逐层并行推进,在 _mixed_attention 里把动作 Query 与拼接后的 K/V 一起做 attention:

def _mixed_attention(self, q_cat, k_cat, v_cat, attention_mask, ...):
    # q_cat: 动作 token 的 Query
    # k_cat / v_cat: [K_action ; K_edit] / [V_action ; V_edit]  ← 编辑分支 KV 拼进来
    key_len = k_cat.shape[1]
    H, H_kv, D = self.num_heads, self.num_kv_heads, self.attn_head_dim
    ...
    out = F.scaled_dot_product_attention(q, k, v, attn_mask=attn_mask, enable_gqa=enable_gqa)
    # 动作 token 通过 joint attention 读取编辑分支的逐层 KV

这正是式(5)-(9)里 "动作专家 conditioned 在 Cedit" 的实现:不是把 cache 拼成一个 context 向量,而是在每层 attention 里把编辑分支的 K/V 拼到动作 token 的注意力键值上

② 动作专家:flow-matching DiT

action_dit_omnigen2.pyActionDiTOmnigen2:动作经 action_encoder(Linear) 变 token,加 RoPE 与 timestep 调制,过若干 OmniGen2TransformerBlock,head 输出动作维度的速度场。它声明 block_protocol="omnigen2" 以便和编辑专家在 MoT 中对齐拼接。

class ActionDiTOmnigen2(nn.Module):
    block_protocol = "omnigen2"
    def __init__(self, action_dim, ..., num_layers=26, ...):
        self.action_encoder = nn.Linear(action_dim, hidden_dim)
        self.blocks = nn.ModuleList([OmniGen2TransformerBlock(...) for _ in range(num_layers)])
        self.head = LuminaLayerNormContinuous(..., out_dim=action_dim)  # 输出动作速度场

③ 编辑专家封装

omnigen2_video_expert.pyOmniGen2VideoExpert 包住 OmniGen2Transformer2DModel,暴露 blocks/num_heads/num_kv_heads/RoPE,供 MoT 逐层取 KV。仓库还提供 action_dit_flux2.py/ovis_u1_video_expert.py 等对应三个变体。

目录导航:imagewam.py(204KB,主 pipeline 组装) · mot.py(joint attention 核心) · imagewam_cache_idm.py / imagewam_noise_idm.py(cache 版 / noise 版 IDM 变体) · lora.py(编辑分支 LoRA 适配)。数据侧 README 提及 no-ops 过滤与 FastWAM 预处理数据。

评价与启发

它把什么问题问清楚了

"世界模型是否必须=预测未来视频"是当前具身领域的一个隐含假设。ImageWAM 通过把 WAM 的中间态从"视频"退化到"单张编辑目标帧",再退化到"根本不解码、只取 KV cache",一步步逼问:reason-before-act 真正需要的是"想象的像素",还是"想象过程中的中间表征"?答案偏向后者。

方法论上的三个亮点

  • 把生成任务当表征提取器:不要生成结果(图/视频),只要生成过程中的 KV——这是"生成即表征"思路在机器人上的一次干净落地。
  • 解耦理解与生成:冻结 VLM 理解、只训 diffusion 生成分支,规避统一模型的目标冲突(消融 Q2 有实证)。
  • 效率是一等公民:1/6 FLOPs、1/4 延迟且不掉点,对真机实时控制(263ms)有直接意义。

值得追问/存疑处

  • τ* 的选择:推理固定单个去噪时间步取 cache,τ* 怎么选、对不同任务是否稳健,论文给的是经验设定,值得关注其敏感性。
  • "不解码目标图"的可解释性代价:视频/图像 WAM 至少能可视化"想象",ImageWAM 的中间态是 KV,调试与失败归因更难(图4的 attention 可视化是一种补偿)。
  • 依赖强编辑基座:最好结果来自 FLUX.2,意味着方法的上限被通用图像编辑模型的进步牵引——是优点(搭生成社区顺风车)也是依赖。
与本站其它页联动:配合"世界模型"页理解 WAM 谱系;配合 DP·DiT·Flow Matching 页理解这里的 flow-matching 动作专家;配合 starVLA 页对比"VLM 只做条件编码器 vs 这里编辑分支做条件编码器"的异同——ImageWAM 的 VLM 依然是冻结的条件提供者,创新点在"多加一个可训的图像编辑生成分支来产出更好的条件 cache"。

自测:6 题检验理解