AMD Radeon云实例+ROCm跑通RoboTwin具身智能训练全流程

坦白说，一开始我以为在 AMD 的 Radeon GPU 云实例上跑通 RoboTwin 会是一趟特别折腾的旅程。毕竟具身智能训练这条链路，大家早就习惯了 NVIDIA 的 CUDA 生态，模型选型、第三方库、训练框架全都默认往 CUDA 靠；一换到 AMD 的 ROCm，很多“装上就能跑”的东西都得重新验证一遍。但实际花了一周把整套流程从 0 推到官方评测闭环之后，我的结论是：这条路完全可行，而且值得认真写出来分享。

这里要交代清楚核心内容是什么：AMD Radeon Cloud 上配 ROCm，把 RoboTwin 的双臂操作仿真数据平台完整跑通，包括种子数据整理、检索增强生成大规模训练数据、策略模型训练，以及最后的官方评测打分。RoboTwin 是开源的双臂操作基准与数字孪生数据生成平台，核心思路是用少量真实遥操作数据当种子，通过检索增强和场景参数化，扩展出上千条可训练轨迹，再用这些数据训练视觉-语言-动作策略，最后放进官方 benchmark 里评估成功率。这篇文章就是我这套流程的实战记录，适合想用 AMD GPU 跑具身智能训练、或者刚接触 RoboTwin 还没来得及理清数据链路的开发者。不管你有没有 CUDA 基础，按这个路径走一遍，启动成本能压到很低。

1. 思路拆解：为什么这个闭环值得完整跑一遍

1.1 RoboTwin 在解决什么根本问题

具身智能领域卡得最死的其实不是模型，是数据。真实机器人遥操作数据需要有人一台台机器人、一个个场景去采，成本高、速度慢、场景覆盖有限，想让策略在仿真环境里学到可迁移的操作技能，没有足够多样的轨迹数据几乎不可能。RoboTwin 的思路是“用数字孪生把少量种子数据放大”：先录一小批真实或高保真仿真操作轨迹，再通过调整物体位置、初始位姿、任务语义描述等参数，生成大量看起来真实、动作分布合理的训练数据。

但这里有个关键问题：数据生成不能靠随机拼凑，否则语言描述、场景配置、轨迹动作三者会对不上，训练出来的策略会学到一个“错乱”的分布。所以“检索增强”环节在 RoboTwin 里不是锦上添花，而是保证数据质量的核心。检索增强负责在给定任务需求和场景状态时，从种子数据里找到最匹配的轨迹片段和初始条件，再交给数字孪生变体生成，确保新数据的动作语义和任务目标一致。

后续的训练和官方评测则是标准的闭环动作：用生成数据训练策略模型，放进官方评测脚本跑固定场景的成功率，再通过失败案例回头补数据、调检索策略或者改模型结构。整个过程不是一条单向流水线，而是一个可以反复迭代的环。

1.2 为什么把 AMD Radeon GPU 云实例放进这套流程

选择 AMD Radeon GPU 云实例，最直接的动力是成本和可得性。云上的 AMD Radeon 实例，比如基于 RX 7900 系列或者其他 RDNA/CDNA 架构显卡的规格，租金通常比同级别 NVIDIA 实例便宜，尤其在训练和仿真分离、不需要大规模多卡并行的时候，性价比优势很明显。

其次是 ROCm 生态已经到了可以日常使用的程度。PyTorch 官方直接发布 ROCm 版本的 wheel 包，RoboTwin 这种项目依赖的主要是 PyTorch、PyBullet、numpy、hydra 这类通用库，并没有强依赖只有 CUDA 能跑的第三方组件。也就是说，RoboTwin 本身对 GPU 计算平台没有绑定，只要 PyTorch 能用 ROCm 正常做算子计算，训练就能跑。

另外一个容易被低估的点是，AMD 云实例的内存和 CPU 配置往往比较均衡，而 RoboTwin 有一部分工作负载在 CPU 上完成，比如 PyBullet 仿真数据生成、轨迹过滤、检索排序。这类任务不吃 GPU，但吃内存和 CPU 核心。把仿真和训练放在同一台机器上，反而省掉了数据搬运的时间。

1.3 闭环里的四个环节分别承担什么角色

数据是底层资产，负责提供动作分布的“原始素材”；检索是数据质量守门员，决定哪些轨迹能进入生成流程，哪些轨迹会被丢弃；训练负责把高质量数据压缩进策略网络，让模型学会从图像和语言指令映射到动作；官方评测负责给出一个不掺杂主观感受的量化结果，告诉你当前数据、检索、训练方案到底行不行。

这四个环节缺一不可。没有数据，策略没有学习对象；没有检索，数据量大但噪声高，训练效率反而下降；没有训练，数据只是静态资产；没有评测，你会陷入“loss 降了但机器人没学会”的盲区。我跑完整个闭环最大的感受是：评测结果必须反哺到数据和检索环节，否则这个环就断掉了。

2. 环境搭建：把 AMD Radeon Cloud 变成一台可训练的机器人工作站

2.1 实例选择与系统准备

我先说结论：建议直接选择 Linux 系统、32GB 以上内存、至少 16GB 显存、200GB 可用磁盘的 Radeon GPU 实例。RoboTwin 的单臂和双臂仿真场景并不算重，但 PyBullet 仿真同时跑多个进程时 CPU 内存会吃得很厉害，尤其是加载纹理和计算深度图的时候，16GB 内存会有点紧张。GPU显存方面，16GB 跑扩散策略的图像输入已经够用，如果后面想跑更大 batch 或者更高分辨率，24GB 会更舒服。

系统层面我会优先选 Ubuntu 22.04 之类的长期支持版本，因为 ROCm 和 PyTorch 对这系列系统的适配最好。选好实例之后，先跑一个简单的硬件检测，确认系统看到了 GPU：

rocm-smi

如果这条命令能正常列出显卡型号、显存、温度等信息，说明驱动层没问题。接下来就是安装 ROCm 版本的 PyTorch。

2.2 ROCm 与 PyTorch 安装的核心命令

ROCm 版本的 PyTorch 安装并不复杂，重点是要用对的 pip 源。官方在 PyTorch 的 wheel 索引里维护了 ROCm 版本，可以直接安装：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.2

装完后用一段最小代码验证，不要直接跑训练，先确认 PyTorch 能看到 GPU：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

这里有个容易误解的地方：在 PyTorch 的 ROCm 版本里，torch.cuda.is_available()返回 True 是正常的，因为它把 AMD GPU 伪装成了 CUDA 兼容接口，上层代码不用改。看到 True 别慌，这恰恰说明 PyTorch 已经通过 ROCm 接管了显卡。如果返回 False，优先检查 PyTorch 包的平台标签是不是linux_x86_64，以及是不是装了 CPU 版本。

2.3 拉取 RoboTwin 代码与环境依赖

RoboTwin 官方仓库拉下来之后，先看 requirements 文件，把依赖装齐。常见的依赖包括 PyBullet、numpy、hydra-core、torch、torchvision、opencv-python、tensorboard 这些。PyBullet 是仿真核心，建议单独装一遍确认版本，因为 RoboTwin 的场景物体模型和 PyBullet 版本有一定绑定关系，版本差太多会出现加载模型报错或者碰撞检测异常的问题。

装完后用一个简单方式验证环境完整性：

python -c "import robottwin; print(robottwin.__version__)"

如果导入报错，大概率是缺了某个视觉库，比如 imageio、pyrender 之类。这类依赖问题不用慌，顺着 traceback 逐个装上就行。我第一次跑的时候就是卡在 pyrender 的 OpenGL 依赖上，在无显示环境的云实例里需要装osmesa相关的系统库才能让它静默渲染。

2.4 环境层面的几个实用建议

第一，强烈建议把依赖版本固定下来。项目跑通一次之后，马上pip freeze导出 lockfile，不然过两周回来复现，依赖升级会把环境搞得面目全非。第二，ROCm 在首次运行某些算子时会有明显的编译过程，表现为前向计算卡住十几分钟，这不是死机，是 MIOpen 在底层做 kernel 编译和缓存。建议把/tmp和 MIOpen 缓存目录分配到足够空间，并做好心理预期。第三，如果实例支持容器，直接用 ROCm 官方镜像省去很多系统层配置问题。

3. 数据与检索：训练集不是随便生成出来的

3.1 种子数据长什么样

RoboTwin 的种子数据来自遥操作采集的轨迹，一条轨迹大致包含三部分：视觉观测（相机图像）、关节状态与动作序列、任务语言描述。视觉观测可以是单视角或多视角图像，动作序列是双臂关节角度的逐帧目标值，语言描述用于告诉模型“当前在做什么任务”。

实践上我会把种子数据组织成两类目录：一类是原始 hdf5 或 json 格式的轨迹文件，一类是索引文件，记录每条轨迹对应的任务 ID、初始物体位置、目标物体位置、轨迹长度、是否成功完成等信息。索引文件很重要，因为检索增强环节需要快速遍历和筛选轨迹，一个个读大文件效率太低。

如果一开始没有现成的遥操作数据，RoboTwin 也提供了官方数据资源，可以直接下载当种子。我建议先跑通官方种子数据，再考虑采集自己的数据，这样可以保证数据格式和仓库脚本完全对齐，少踩一层格式转换的坑。

3.2 检索增强到底在做什么

传统 RAG 的直觉是“根据问题找相关文档片段”，RoboTwin 里的检索增强更接近“根据任务需求和场景状态找相关操作轨迹”。给定一个任务描述，比如“将红色方块放入左侧蓝色桶中”，系统先去种子数据里查找语义相近的轨迹，再根据当前场景中物体位姿和种子轨迹的初始位姿做几何匹配，选出最合适的轨迹作为生成基础。

为什么要做这一步？因为数字孪生生成不是凭空捏造轨迹，而是在种子轨迹基础上做场景参数扰动、视角变化、物体位置变化，重新渲染成新数据。如果种子轨迹跟目标任务根本不对应，再怎么扰动也生成不出合理的轨迹。

我用一个生活类比来说明：做菜的时候你有本菜谱，菜谱里几千道菜的步骤。现在有人点了一道“番茄牛腩”，你不可能去翻“清蒸鲈鱼”的步骤来改。检索增强就是那个帮你快速找到最接近菜谱的能力。

3.3 一个轻量可落地的检索实现思路

RoboTwin 官方方案里检索增强做得更复杂，但实战中可以先从轻量方案起步。我的实现分两步：先用语言模型对任务描述做语义召回，再用几何距离做精排。语义召回可以用现成的 embedding 模型，比如 BAAI 的 bge 系列，在 CPU 上跑都很快，因为候选轨迹数量不多。几何精排则比较基础，把轨迹关键帧的末端位姿和当前场景目标位姿做归一化欧氏距离计算，取 top-k 条轨迹作为候选。

import numpy as np from sentence_transformers import SentenceTransformer # 语义召回：先按任务语义粗筛 model = SentenceTransformer("BAAI/bge-small-zh-v1.5") task_emb = model.encode("将红色方块放入左侧蓝色桶中") traj_embs = model.encode([t["description"] for t in traj_index]) recall_ids = np.argsort(task_emb @ traj_embs.T)[::-1][:20] # 几何精排：按初始末端位姿与目标位姿距离排序 def distance_to_target(traj_pose, target_pose): return np.linalg.norm(np.array(traj_pose) - np.array(target_pose), axis=-1).mean() candidates = sorted(recall_ids, key=lambda tid: distance_to_target( traj_index[tid]["init_eef_pose"], target_eef_pose ))[:10]

这里重点不是算法多高级，而是流程要通：先粗筛、再精排、最后把选出来的轨迹 ID 和场景配置一起传给生成脚本。我在实际跑的过程中发现，语义粗筛可以很粗暴，但几何精排必须做，否则生成出来的轨迹经常出现“动作方向对但初始抓取位置偏差很大”的情况，训练时模型会学得很混乱。

3.4 训练集组织时最容易踩的三个坑

第一个坑是任务数据泄漏。如果训练集和评测集用了同一批种子数据的扰动版本，评测成功率会虚高。我建议按“任务描述”切分，保证评测任务里出现的任务，在训练集没有语义完全相同的轨迹。第二个坑是轨迹重复。合成数据量上来以后，很多轨迹只是在原始轨迹上做了微小的位姿扰动，模型看到的多样性有限，训练后期会过拟合到几条核心轨迹。解决方法是加入场景多样性控制，比如物体颜色、摆放范围、干扰物数量都要有变化。第三个坑是丢失 metadata。每条合成轨迹都应该记录来源轨迹 ID、生成参数、是否成功完成，这样评测失败后能反查是哪类数据导致的问题。

4. ROCm 训练：让策略模型在 AMD 卡上真正收敛

4.1 策略模型选型：扩散策略作为默认答案

RoboTwin 支持的策略模型里，我选扩散策略（Diffusion Policy）作为默认方案，因为它稳定、对多模态动作分布建模好，而且依赖很简单。动作生成被建模成去噪过程：训练时给动作序列加噪声，让模型学会根据观测和语言指令预测噪声；推理时从随机噪声开始，逐步去噪得到动作序列。扩散策略在双臂操作场景里表现比较稳，尤其是在抓取位置有多种可行解的情况下，能保留动作分布的多样性。

如果你对 Octo 这类大模型微调方案更感兴趣，RoboTwin 也有对应入口。但我的经验是，在 AMD Radeon GPU 云实例上，扩散策略的工程摩擦最小：不需要下载几十 GB 的预训练权重，不需要处理 transformers 和 tokenizer 的版本兼容，训练和评测的代码路径也短。先把扩散策略跑通，后续再换大模型是更好的节奏。

4.2 我用的训练配置与关键超参数

配置文件基于官方仓库的 yaml 模板修改，核心参数大致如下：

train: batch_size: 32 num_workers: 0 lr: 1e-4 weight_decay: 1e-6 grad_accumulation: 4 mixed_precision: bf16 gradient_checkpointing: true max_steps: 8000 dataset: image_size: 256 obs_steps: 2 action_horizon: 16 num_demo_trajectories: 1200

batch_size设在 32，配合grad_accumulation=4，等效 batch 是 128，在 16GB 显存上比较舒适。image_size从原始分辨率降到 256，大幅降低视觉编码器的计算压力，同时保留足够信息判断物体位置和抓取姿态。action_horizon设为 16，意味着模型一次预测 16 步动作，执行时用 receding horizon 的方式滚动预测。

num_workers必须设为 0，这是 ROCm 下非常关键的一点。PyTorch DataLoader 的多进程 worker 会在 fork 后初始化 ROCm 上下文，经常导致显存分配异常或者 kernel 崩溃，与其花时间调参，不如直接单进程加载数据，配合预读缓存把 IO 开销压下去。

4.3 ROCm 下必须处理好的三个工程问题

第一个是混合精度选型。在 ROCm 上，fp16 在某些算子上的 kernel 实现不如 bf16 成熟，训练时容易出现梯度 NaN 或者 loss 震荡。我直接启用 bf16，一方面精度问题少，另一方面现代 AMD GPU 对 bf16 支持度更好。第二个是环境变量调优。如果你的显卡不是 ROCm 官方明确支持的型号，可能需要设置HSA_OVERRIDE_GFX_VERSION来指定 GCN 架构版本，但一定不要照抄网上的值乱设，要根据自己的显卡架构来。比如 RDNA2 系架构通常用HSA_OVERRIDE_GFX_VERSION=10.3.0，RDNA3 可能需要11.0.0，设错了会出现“显存能分配但 kernel 无法执行”的诡异现象。

第三个是首次 kernel 编译的耐心。启用 bf16 和某些卷积算子时，第一次运行会触发 MIOpen 的 kernel 编译，表现就是卡在一个 step 上很久，日志不更新。我建议训练前先用一小段数据跑一个warmup脚本，让所有算子都编译一遍，再正式开训，能省掉训练到一半“假死”的心慌。

4.4 训练时怎么判断模型在收敛

不要只看 loss 的绝对值，扩散策略的 loss 波动本来就大，我主要看几个趋势：整体 loss 有没有稳定下台阶、验证集上动作预测误差有没有下降、生成的动作轨迹是否逐渐变得平滑。训练过程我会固定每个 checkpoint 间隔，比如每 1000 步保存一次，保留ema权重和优化器状态，方便后续评测时回滚到效果更好的版本。

实际跑下来的记录大概是：前 1500 步 loss 快速下降，1500 到 5000 步缓慢下降，5000 步之后基本进入平台期。这时候强行继续训练意义不大，不如拿去跑评测，用失败案例指导数据迭代。训练日志我习惯同时写到 TensorBoard，方便对比不同数据版本带来的效果差异。

5. 官方评测闭环：用指标把“能跑”变成“能用”

5.1 官方评测机制到底在评估什么

RoboTwin 的官方评测不是简单加载模型跑几个场景看热闹，它有一套相对固定的规程：每个任务在标准场景中执行若干次尝试，场景初始化包含随机扰动，比如物体位置在指定范围内波动、相机视角有微小差异。评测统计的核心指标是成功率，也就是成功完成任务闭环的比例。

除成功率外，还会记录平均完成步数、子任务完成度、碰撞次数等辅助指标。我在实战中主要盯成功率，但每次失败都会详细记录是卡在哪个阶段。比如“接近物体”成功但“抓取”失败，和“抓取”成功但“放置”失败，对应的数据问题完全不同。前者说明视觉推理或者轨迹生成精度不够，后者说明动作序列的末端阶段和场景几何没有对齐。

5.2 把训练好的 checkpoint 接到评测流程

官方评测脚本会读取你指定的 checkpooint，构建对应的 policy 实例，然后在仿真环境里逐任务跑。这里最容易出问题的不是 GPU 性能，而是模型状态字典的 key 对不上。比如训练时用了ema权重，评测脚本可能默认加载普通权重；或者训练时对观测做了归一化，评测时忘了加载归一化参数，都会导致评测分数异常低。

我的做法是在训练脚本里把“完整 checkpoint”和“推理专用 checkpoint”分开保存。推理专用权重包含模型参数但不包含优化器状态，文件更小，加载更快，也避免了评测时误用优化器状态带来的隐性影响。评测启动前，我会单独跑一段验证代码，确保加载的模型输出动作范围和训练时的范围一致，防止静默错误。

评测时也要注意仿真和训练的隔离。训练进程和评测进程不要同时使用同一张卡，ROCm 支持多进程并行，但显存不够的时候评测会被挤爆。我一般把评测放在独立会话里，保持只有一个进程在用 GPU，这样评测时间更可预测。

5.3 从评测结果反向改进数据闭环

我第一次跑完评测，成功率只有十一个点，这个数字对正式实验来说非常难看。接着我把失败案例按阶段拆开看，发现大量失败集中在“初始接近物体时末端位置偏移明显”，说明训练数据里初始位姿分布和评测场景的初始位姿分布不一致。于是回到检索生成环节，增加了初始位姿分布的采样范围，重新生成了大约 500 条补充轨迹，再用同样训练配置微调，成功率明显提升，单次实验里到了四十多个点。这个数字有随机性，但趋势很明确：评测暴露问题，数据闭环补位，是整套流程里价值最大的一环。

6. 常见问题与避坑清单：实测踩过的那些坑

6.1 ROCm 相关问题速查表

6.2 数据与训练环节的三个隐藏问题

第一，训练集里混入失败轨迹风险极高。合成数据脚本不一定保证所有轨迹都真实完成，如果生成出来的轨迹在最后一步目标未达成，也会被当成训练数据写进数据集。我在过滤环节加了一个规则：检查轨迹最后一帧末端执行器与目标物体位姿的距离，超过阈值直接丢弃。第二，轨迹长度不一致。扩散策略训练需要固定长度的动作序列，短的轨迹要截断或者 padding，长的轨迹要随机采样窗口。我建议在数据预处理阶段统一截成长度一致的 segments，不要在训练循环里做动态处理，否则 Dataloader 的复杂度会翻倍。第三，背景纹理和光照变化容易被忽略。数字孪生生成数据时，如果只改变物体位置不改变光照，训练出来的视觉编码器会过拟合到固定光照条件，评测时换个视角就崩。

6.3 评测结果不稳定时的稳定性技巧

评测结果有波动是正常的，但波动大到无法判断模型好坏的时候，需要先稳定评测环境。我习惯固定随机种子，包括 PyBullet 的场景初始化、策略推理时的噪声采样，在固定种子下跑 20 个 episode，至少能把指标波动压到可解释的范围。另外就是给每个 episode 设置最大步数，防止模型陷入原地抖动浪费算力。对应到流程里，为评测单独写一个配置文件，和训练配置彻底分开，这样改评测逻辑不会污染训练代码。

6.4 我最后想分享的几个个人经验

这套流程我跑下来，最深刻的体会是“端到端先跑通，再谈优化”。第一次做的时候我试图把所有环节都做到位，数据要一千条、检索要上大模型、训练要加数据增强，结果各个模块互相打架，花了大量时间排错。后来强行缩小规模，先用 100 条轨迹把训练和评测链路跑通，再逐步扩量，反而顺畅得多。

另外想强调一个心态问题：在 ROCm 上跑 AI 训练确实会碰到一些 CUDA 生态里不会出现的边角问题，但绝大部分都能通过环境变量、版本固定、算子替换解决，没有必要因为第一次接触就放弃。AMD Radeon GPU 云实例加 ROCm 的路线，目前已经足够支撑 RoboTwin 这种规模的具身智能实验，而且成本对个人开发者非常友好。

如果你后续想继续深入，我建议从两块扩展：一是把检索增强换成更强的大模型方案，让任务描述到轨迹映射更精准；二是把扩散策略换成支持多模态输入的大模型，看看在 AMD 卡上能不能复现官方 baseline 以上的效果。数据闭环一旦跑通，往上叠加新模块只是时间问题。