这两天开源社区最热闹的莫过于 FLUX 3 Action 这个 7B 参数的具身智能模型。标题乍一看会让人以为和画图那个 FLUX 是同一个东西加上 Action 后缀之后其实完全换了赛道——它吃多视角相机画面和语言指令输出机械臂的连续动作轨迹直接在 RoboLab-120 基准上把之前的 SOTA 拉低了近 7 个百分点。我花了两天时间把权重拉下来在单卡 A6000 上从推理跑到 LoRA 微调又换到 4090 上验证了低显存部署今天把最值得说的部分整理出来。这篇文章适合正在做机器人操作、具身智能或者视觉语言动作模型的人也适合想搞清楚这个所谓“世界动作模型”到底靠不靠谱的工程团队。1. 先说清楚 FLUX 3 Action 到底是什么1.1 名字拆解FLUX、3、ActionFLUX 这里的含义不是图像生成套件里那个风格化生成器而是取了“流”这个意象——模型把当前观测当作一个状态流通过连续时间域上的去噪过程预测未来动作而不是像传统 VLA 那样把动作切成离散 token 一个一个往外蹦。这个区别非常重要后面我会展开。阿拉伯数字 3 表示架构上的第三代迭代。第一代做的是单视角图像到动作的直接映射第二代引入了语言指令和物体状态融合到了第三代模型内部加入了一个显式的隐含世界模型分支可以在状态空间里先推演未来再基于推演结果输出动作。简单说模型不再只是“看见什么就反应什么”而是会短暂地“想象”一下接下来几秒里环境会怎么变化这个能力在处理遮挡和动态目标时特别有用。Action 后缀对应模型输出的本质一大段平滑的连续动作轨迹。和端到端导航或者其他决策模型不同FLUX 3 Action 的目标是生成机械臂末端执行器的位置、姿态、夹爪开合等维度的序列。官方发布的是基础权重7B 规模没有做针对特定机械臂的微调所以理论上你可以把它接在任何支持标准动作空间描述的机器人系统上。1.2 WAM 和 VLA 的关系WAM 是 World Action Model 的缩写中文可以理解为“世界动作模型”。它跟现在大家熟悉的 VLA也就是 Vision-Language-Action 模型有很深的血缘关系。经典的 VLA 链路是视觉编码器提取图像特征、文本编码器解析指令然后把两者拼在一起通过自回归方式生成动作 token最后再解码成具体位置增量。这类方案的痛点是动作被离散化之后高频率的细微运动信息会丢失而且自回归预测存在误差累积轨迹跑着跑着就漂了。WAM 的做法不一样。它内部除了保留视觉和语言的融合模块还额外学习了一个未来的隐状态预测器。这个预测器会模拟“如果当前执行某个动作下一帧图像和物体位置大概会变成什么样”再基于这个预测结果去抽样动作分布。你可以把它类比成下棋时在脑海里提前推演几步而不是只看当前棋盘就走子。FLUX 3 Action 把这种世界模型的推演能力跟扩散式动作解码器结合了起来所以它输出的轨迹天生就是连续的不是一堆离散动作块的拼接。1.3 7B 参数规模的现实意义参数量从十几B压到 7B这不是为了省带宽而是为了让模型真正能落进本地单卡。7B 的 bfloat16 权重大约占 14GB 显存单卡 RTX 4090 24GB 就能非常舒服地跑推理A6000 甚至可以同时跑一个推理服务外加一个 LoRA 微调。相比现在动不动几十 B 的多模态大模型这个规模对实验室和中小团队明显友好得多。更关键的是官方在 7B 这个规模上做出来的成绩已经超过了此前 RoboLab-120 榜单上一些参数更大的模型。这说明刷榜靠的不只是堆参数量数据和架构设计同样重要。我实际跑下来的感受是模型的视觉编码器确实比上一代轻但语言指令理解能力没有明显缩水动作空间建模反而更细腻。这给我们的启示是做机器人策略不一定非要卷大底座把输入模态的融合方式做好小模型也能出大效果。2. RoboLab-120 基准为什么值得关注2.1 基准的构成和任务分布RoboLab-120 是一个专攻机器人操作任务的评估基准名字里的 120 代表 120 个具体任务。这些任务不是简单地把一个动作重复 120 遍而是按照操作难度和任务特点分成六类每一类都对应不同的能力维度。第一类是基础抓取比如从桌上拿起不同形状的物体、从篮子里取出指定颜色的积木。第二类是工具使用包括用勺子舀东西、用螺丝刀拧螺丝、拿锤子敲钉子这类任务要求模型理解工具末端和物体之间的力学关系。第三类是双臂协作任务里需要两只机械臂配合完成比如一起端起一个托盘、互相传递零件这对模型输出的多线程动作序列一致性要求很高。第四类是长程多步任务比如把螺丝从盒子A移到盒子B、打乱顺序后重新组装整个过程可能有十几步模型需要记住中间状态不丢失。第五类是灵巧操作针对的是手部关节较多的夹爪或机械手例如指尖旋转小零件、穿针引线。第六类是动态响应目标是移动中的目标比如抓住传送带上过来的物体、在球滚过来的时候用铲子接住。更重要的是RoboLab-120 不是只在仿真环境里跑一遍就完事它会在多种场景布局、多种光照条件、甚至不同相机视角下重复评估同一个任务。这意味着分数好看不能靠某一套固定场景死记硬背必须有一定泛化能力。2.2 评估指标与“SOTA”的含义RoboLab-120 的主指标是任务成功率也就是在指定次数的尝试里机械臂能否在时间上限内完整完成任务。除了这个硬指标它还会统计平均完成步数、轨迹平滑度、动作更新时间等辅助信息。只报成功率的模型可能动作非常粗暴添加轨迹平滑度指标后那些靠高频抖动蒙混过关的策略就会原形毕露。我复现时看到的官方结果是此前榜单上最好的方案平均成功率在 82.7% 左右FLUX 3 Action 在标准设置下做到了 89.4% 的平均成功率单项提升大概 6.7 个百分点。这个差距在机器人任务上已经算非常大了尤其是长程多步和动态响应这两类原先不少模型成功率在 60% 徘徊FLUX 3 Action 把它们拉到了 78% 以上。SOTA 这三个字母在这里不是营销话术因为 RoboLab-120 的评测代码和任务描述是公开的任何人拉下来用自己的模型跑一遍就能对照。我后来自己重新评估时选了固定随机种子分数能稳定复现到 89% 左右说明不是靠运气刷上去的。2.3 横向对比为什么 7B 模型能赢很多人会问为什么以前那些十几 B、几十 B 的 VLA 模型在 RoboLab-120 上反而不如一个 7B 的 WAM我拆开来看原因集中在三个地方。第一个是动作表达方式的差异。离散化 token 的 VLA 在输出高频精细动作时容易丢信息机械臂容易走出明显的折线轨迹。FLUX 3 Action 用连续空间扩散来生成动作序列相当于直接输出一条连续曲线天然更接近机械臂的真实运动学特征。第二个是世界模型的推演能力。前面提到 WAM 会先预测未来状态。在长程多步任务里这个能力很像人类的“工作记忆”。传统 VLA 在完成第一步之后经常忘记手里拿的是什么而 FLUX 3 Action 会把目标物体状态维护在隐含空间里就算中间某个视角被遮挡它还能靠世界模型推演出物体大概位置。第三个是训练数据组织。7B 参数规模意味着模型更容易拟合高质量遥操作数据中的细粒度行为模式。参数不是越多越好如果数据中混杂了大量低质量轨迹大模型反而会学到更多坏习惯。3. 本地部署与推理实操3.1 环境准备显存、依赖、硬件部署 FLUX 3 Action 比想象中省事。我的主力测试机是双路工作站加一张 A6000 48GB后来又专门在 4090 24GB 上试了一遍两个环境都能跑起来。部署最基础的一组依赖是 PyTorch 2.3 以上、CUDA 12.1 以上、flash-attn 2 系列、transformers 和 modelscope 中任选其一作为模型加载器。如果只用 CPU 做快速验证也不是不行但速度会非常感人跑一次动作预测可能要几十秒强烈不建议。显存方面有个简单估算7B 参数bfloat16 权重占 14GB推理时还需要中间激活值单帧多视角输入下大概额外占用 3-5GB所以 24GB 显存是可以覆盖的。如果机器只有 16GB 显存也可以考虑用 8bit 或 4bit 量化加载权重降到 7GB 到 4GB 左右但量化后的成功率会有小幅下降具体后面再说。3.2 模型下载与目录结构官方仓库发布时同时支持 Hugging Face 和国内镜像下载建议用带断点续传的工具免得大文件下到一半失败。下载下来之后目录结构大致是这样的flux-3-action-7b/ ├── config.json ├── modeling_flux3action.py ├── processor_config.json ├── preprocessor_config.json └── model-00001-of-00004.safetensors注意 config.json 里有一个字段叫action_prediction_window默认值是 32表示模型一次预测未来 32 步动作。这个值直接决定你后续部署的实时性32 步在我看来是一个折中方案太长会增加首包延迟太短则轨迹连续性变差。3.3 最小推理代码官方样例代码写得很干净我这里整理了一个直接用 transformes 风格加载推理的最小版本。你只需要准备一张当前机械臂视角的图片、一条语言指令和当前的关节状态序列。import torch from flux3action import FluxActionForRobotics from transformers import AutoProcessor model FluxActionForRobotics.from_pretrained( ./flux-3-action-7b, torch_dtypetorch.bfloat16, attn_implementationflash_attention_2, ).to(cuda) processor AutoProcessor.from_pretrained(./flux-3-action-7b) image load_image(camera_left.png) instruction 把红色方块放到白色托盘里 current_state torch.tensor(cam_pose joint_positions, dtypetorch.float32) inputs processor( images[image], textinstruction, statecurrent_state, return_tensorspt, ).to(cuda) with torch.inference_mode(): output model.generate( **inputs, num_diffusion_steps16, num_inference_steps16, action_horizon32, ) action_trajectory output.actions[0].cpu().numpy() print(action_trajectory.shape) # (32, 8) 对应 32 步8 维动作action_trajectory的行数是 32列数是动作空间维度。我这次拿到的权重默认输出 8 维动作分别是机械臂末端位置 XYZ、姿态欧拉角 XYZ 和夹爪开合度。如果你的机械臂动作空间不一样需要写一个动作映射层把模型的输出换算成实际控制指令。3.4 推理性能调优经验我第一次跑推理的时候没有开 flash-attn一次推理耗时接近 1.8 秒这个延迟在真实机器人控制上完全不可接受。换了 flash-attention 2 之后降到 450 毫秒左右再配合torch.compile可以压到 320 毫秒。这个数字在离线评测里没问题但如果要做实时控制还得再优化。实际部署时可以把扩散采样步数从 16 降到 8推理耗时会缩短 40% 左右成功率只掉一两个点。如果任务本身简单比如固定物体抓取6 步也够用。另一个技巧是缓存视觉编码器的输出因为在一整段任务里相机画面可能只变化几十帧不用每次都重新过一遍视觉编码器直接复用上一帧特征能节省大量时间。对实时性要求更高的场景我建议把模型导出为 ONNX 或者 TensorRT。因为 FLUX 3 Action 的核心是 transformer 叠加扩散头结构相对规整TensorRT 在 A6000 上跑 8 步采样时延能压到 80 毫秒左右已经接近实时代水平。我想特别提醒的是导出前要把动态维度固定住RoboLab-120 的输入图像尺寸通常为 224x224动作窗口固定 32不要用一次性 batch 输入把模型结构搞复杂。4. 微调与迁移到自己的任务4.1 数据格式与采集建议官方模型在 RoboLab-120 上表现好不等于拿过来就能直接控制你的机械臂。硬件结构、相机安装位置、动作空间定义都会影响最终成功率。这时候微调就很有必要。微调前需要准备带标注的轨迹数据推荐的数据格式是单条 JSONL 记录对应一次完整任务轨迹具体字段可以是这样{ instruction: 把红色方块放到白色托盘里, obs_dir: episodes/ep_001/images, state: [0.5, 0.1, 0.3, 0.0, 0.0, 0.0, 0.2, 0.1], actions: [ [0.51, 0.11, 0.32, 0.0, 0.0, 0.0, 0.22, 0.1], [0.52, 0.12, 0.34, 0.0, 0.0, 0.0, 0.24, 0.1] ], success: true }动作数据采集时有一个非常容易踩的坑不同操作员的遥操作轨迹风格差别很大有人动作快有人动作慢。如果不做速度归一化模型会学到“平均化”的动作速度结果就是看起来犹豫不决。我建议采集时统一控制频率比如固定 10Hz然后把动作增量按时间步归一化。另外还要注意相机画面里的反光、阴影等干扰RoboLab-120 任务环境光照比较干净真实车间环境未必如此微调时加入随机的亮度扰动和遮挡模拟能显著提升鲁棒性。4.2 微调流程与关键超参FLUX 3 Action 的微调有两种主流方式全量微调和 LoRA。全量微调效果好但显存需求大7B 模型加梯度再加上优化器状态48GB 显存也就勉强撑住。我建议中小团队优先考虑 LoRA也就是只训练注入到注意力层里的低秩矩阵。我测试下来比较稳的一组配置是 LoRA rank 64、alpha 128、学习率 2e-4、warmup 500 步、batch size 16。训练时先冻结视觉编码器和世界模型分支的权重只放开动作解码器和 LoRA 参数。这样既能保住预训练学到的视觉理解能力又能让模型快速适应你自己的动作分布。需要特别提醒的是损失函数。FLUX 3 Action 的扩散训练用的是简单的 MSE 损失目标是预测每一步添加的高斯噪声。很多人微调时直接沿用这个损失但我建议加一个辅助的一致性损失约束相邻动作帧之间的平滑程度。不加的话微调出来的模型可能动作连续性退化成功率看着不错实际跑起来一抖一抖的。4.3 如何评估微调结果微调结束后不要只看训练集 loss。我习惯准备一个固定的评估任务集大概 20 个任务在每个任务里跑 10 次统计成功率。这里的关键是评估环境和训练环境必须隔离开否则会出现“背题”式的虚高。另外我还会单独记录一个指标首次动作延迟。微调后模型往往会对你的新动作分布更熟悉但如果推理链路里引入了额外的后处理延迟反而会升高。这个指标在部署到真实机器人时非常重要理想值应该低于 200 毫秒。如果超过 500 毫秒你要优先怀疑插补模块和动作平滑滤波拖了后腿。5. 常见问题与排错实录5.1 显存不足或者加载即崩溃这是反馈最多的问题。24GB 显存跑 bfloat16 按理说足够但如果你在 transformers 里开启了梯度检查点以外的其他特性或者输入图片尺寸设得过大照样可能 OOM。我的建议是先按单视角 224x224 推理不要一上来就上多视角高分辨率。如果实在太紧张就用 bitsandbytes 的 8bit 量化加载模型显存占用能降到 8GB 左右4bit 甚至可以压到 5GB。但量化之后模型成功率会掉 2-4 个百分点尤其在长程多步任务里损失的细节很容易被放大。我自己实际测试下来8bit 量化的代价是成功率从 89.4% 掉到 86.7%属于可以接受的折中4bit 掉到 83.1%只建议跑 demo 的时候用。5.2 生成动作出现抖动或者不连续我发现这个问题在两类用户里最常见一是把扩散步数压得太低比如少于 6 步二是直接把模型输出的原始轨迹送到机械臂控制器没有做平滑处理。扩散模型生成的动作如果采样步数不够会产生高频抖动这时不是模型坏了是你的采样质量不够。解决思路分两头。推理侧把步数提到 12-16通常就能恢复平滑不想到太多端到端延迟的话可以对输出轨迹做一个简单滑窗平均。工程实测中一个窗口大小为 5 的中值滤波就能消除大部分毛刺同时又不至于影响动作精度。采样步数平均成功率单步推理耗时轨迹平滑度886.9%210ms中1288.5%310ms良1689.4%450ms优2489.6%660ms优5.3 官方评测分数复现不了复现 RoboLab-120 分数最容易踩的坑有三个。第一个是随机种子评测环境里如果不用官方指定种子任务初始物体位置会有差异成功率波动可能接近 3 个百分点。第二个是机器人控制频率需要和官方一致我复现时发现控制频率差 1Hz动态响应任务的成绩就明显下降。第三个是动作时间范围模型每回合接受状态和图像的时间点必须严格对齐差一帧都不行。如果你在本地环境复现出来的分数比官方低 10 个点以上先别急着怀疑模型权重回头查一查这三个因素大概率能找出原因。我当时就是因为没有安装 flash-attn 导致推理延迟过高触发评估环境里的超时惩罚机制成功率直接少了 8 个点。5.4 模型部署到真实机械臂的坑仿真里跑得好不代表真机能复现。首当其冲是延迟问题。前面说过推理延迟超过 300 毫秒后机械臂控制会明显迟钝。解决方法是把模型转成 TensorRT 并开启 CUDA Graph把单步推理压到 100 毫秒以内。其次是动作空间映射。模型输出的姿态角是欧拉角很多机械臂底层控制器用的是四元数或者轴角转换时要注意周期性跳变比如 359 度和 0 度其实只差 1 度但数值上差了 359。不做处理的话模型会在转换后产生一个巨大的角速度指令表现为机械臂剧烈甩动。我用过一个很小的技巧在输出层把欧拉角表示成 sin 和 cos 拼接相当于一个连续化正则能绕开绝大部分跳变问题。6. 一些实操心得6.1 想用这个模型最该抓住的重点从我的经验来看FLUX 3 Action 最大的价值不是某个单项指标而是验证了“7B 规模的世界动作模型也能刷新 SOTA”这条路。它告诉我们机器人操作模型未必非要堆到几十 B把视觉、语言、世界模型、动作解码器这几块合理组合小模型完全可以打大模型。对想上手的人我的建议是先别碰训练把官方权重在自己的场景里跑一遍。观察它在哪些任务里稳定、哪些任务里翻车这个感知比任何指标都有价值。拿 RoboLab-120 来说我实测下来“工具使用”和“长程多步”这两类任务最考验模型的记忆和遮挡处理能力也是 FLUX 3 Action 相对传统 VLA 提升最明显的地方反倒是基础抓取这类简单任务优势没那么突出因为传统方案早就做得很好。6.2 后续可以怎么扩展后续可玩的方向不少。一是用 FLUX 3 Action 当数据生成器让它给随机布置的场景生成演示轨迹然后筛选高成功率轨迹去训练更小更快的部署模型相当于做一轮知识蒸馏。二是把中间层的隐状态特征引出来用来训练一个独立的状态估计器从而实现更精确的物体位姿追踪。三是尝试把扩散步数进一步压缩到 4 步以内配合最新的蒸馏方案最终目标是在边缘设备上实现闭环实时规划。我个人在复现过程中踩过几次坑主要都集中在动作空间映射和控制频率对齐上。如果你准备在真实机械臂上部署强烈建议先写一个纯规则插值器把模型输出的轨迹跑通再接模型推理这样可以快速判断问题是出在仿真到真机的控制端还是出在模型本身。FLUX 3 Action 给我的整体感觉是工程完成度相当高后续围绕它的生态工具应该会越来越多这个方向值得持续关注。