企业官网建设流程全解析

说实话，刚看到“AMD Radeon Cloud 具身智能实战白皮书”这个题目的时候，我的第一反应是：又来了一个装腔作势的官方宣传语。但真正动手把 RoboTwin 从零跑到官方评测闭环之后，我发现自己对 AMD 生态、对具身智能的数据闭环都有了完全不同的理解。这篇东西我会写得非常细，尽量把数据获取、检索逻辑、ROCm 训练环境和最终评测的整个链路说透。

先说结论：RoboTwin 这类基于 Genesis 仿真引擎的具身智能平台，放在 AMD Radeon Cloud 上确实能跑通，但前提是你得理解“Radeon Cloud 不等于一个更便宜的 CUDA GPU”这句话。ROCm 的软件栈、PyTorch 的适配版本、数据集的检索组织方式，每一步都有它自己的脾气。如果你手里正好有 AMD Radeon Cloud 的实例，或者正准备往 ROCm 上迁移具身智能训练任务，这篇文章就是给你写的。

1. 为什么在 AMD Radeon Cloud 上跑 RoboTwin：选型逻辑

1.1 具身智能训练卡在“显存”这道门槛上

先聊聊我为什么选择 AMD Radeon Cloud 来跑 RoboTwin。原因很简单：本地一张消费级显卡，显存根本扛不住具身智能的训练任务。

RoboTwin 这类平台，一个典型的模仿学习任务会用到双目视角图像、机械臂末端状态、语言指令嵌入，把这些拼成一个 batch 送进神经网络，显存占用随随便便就是 16GB 往上。用本地 3090 跑小数据集还能凑合，一旦加上 ACT 或者 DexVLA 这种稍微大一点的模型，显存墙就卡在你脸前。

Radeon Cloud 的优势正在这里：按小时租用，实例上直接给到 48GB 甚至 64GB 的高端 Radeon 系列显卡，不需要一次性买硬件，也不用考虑散热和机箱。对我这种验证 RoboTwin 跑通流程的人来说，成本就是几个小时的钱，比买一张顶级卡然后吃灰划算太多。

1.2 ROCm 是什么，换平台后最容易被忽视的差异

如果你之前只用过 CUDA，那 ROCm 就是你从 NVIDIA 生态切换到 AMD 生态时必须重新认识的东西。ROCm（Radeon Open Compute）是 AMD 开源的计算平台，你可以把它理解为 AMD 版的 CUDA 工具链。包括驱动、编译器、数学库（比如 rocBLAS、MIOpen）和运行时。

但注意一个关键差异：ROCm 不是简单地把一套驱动装上去就完事了。它跟 PyTorch 的版本绑定非常紧密。在 CUDA 生态里，你装一个torch默认就带 CUDA 12.x 的支持；在 ROCm 生态里，你必须安装对应 ROCm 版本的 PyTorch 轮子，而且要确保系统里的 ROCm 驱动版本与 PyTorch 编译时用的版本接近，否则跑模型时会出现莫名其妙的算子错误。

我在 Radeon Cloud 上刚开始犯的错就是直接pip install torch，结果安装的是 CUDA 版本，代码里torch.cuda.is_available()返回 False。后来清掉环境，重新用 Radeon Cloud 自带 ROCm 仓库的版本安装，才算走上正轨。这个细节会在环境准备章节里详细展开。

2. 从申请实例到 ROCm 环境就绪：准备阶段的全过程

2.1 实例选择与 SSH 登录

Radeon Cloud 的实例申请界面跟大多数云平台类似，核心选择项是显卡型号、CPU 核数、内存和系统镜像。

我的建议是：如果只跑 RoboTwin 单任务训练，选择实例时优先看显存而不是显卡数量。单卡 64GB 的实例通常比双卡 32GB 的实例更省心，因为 RoboTwin 官方训练的默认配置就是单卡。系统镜像直接选官方提供的 Ubuntu 22.04 版本，ROCm 6.x 对 Ubuntu 22.04 的适配是最成熟的。如果你选的是 Ubuntu 24.04 或者其他定制镜像，后续装 ROCm 库时可能会遇到依赖冲突。

登录之后的第一个动作，我建议先跑三行命令确认硬件和驱动：

rocm-smi rocminfo lspci | grep -i radeon

rocm-smi能看到显卡温度、频率和显存占用；rocminfo能确认 ROCm 驱动是否正常加载的 agent 信息；lspci则是确认系统识别到了显卡。其中任何一步异常，都值得在跑训练之前排查干净，否则你后面只会把时间浪费在更诡异的地方。

2.2 安装 ROCm 版本 PyTorch，并跑通验证脚本

Radeon Cloud 镜像一般自带 ROCm 驱动，但 PyTorch 还需要单独装。这里给出一条我已经验证过的命令：

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

注意，下面的数字要跟你的 ROCm 版本对应。如果rocm-smi显示的是 5.7 或 6.2，那索引地址里的rocm6.0也要改成对应版本。装完之后用一段验证脚本检查环境：

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) x = torch.randn(1024, 1024, device="cuda") y = torch.matmul(x, x) print(y.sum().item())

如果torch.cuda.is_available()返回 True，矩阵乘法也顺利算出结果，那 ROCm 这边的核心链路基本就通了。

2.3 环境变量与全局优化

在真正跑 RoboTwin 之前，还有几个环境变量值得提前设置好：

export HSA_OVERRIDE_GFX_VERSION= export PYTORCH_ROCM_ARCH=gfx90a export MIOPEN_DEBUG_CONV_DIRECT=0

这段需要解释一下。HSA_OVERRIDE_GFX_VERSION在消费级 Radeon 卡上比较重要，因为它能把 GFX1030 这类架构伪装成数据中心卡支持的架构，避免 MIOpen 库不认卡的问题。在 Radeon Cloud 的数据中心级实例上，这个变量通常留空就行。PYTORCH_ROCM_ARCH则告诉 PyTorch 只编译对应架构的 kernel，能显著减少第一次跑训练时的编译等待时间。MIOPEN_DEBUG_CONV_DIRECT=0是我遇到卷积算子性能异常时排查出来的一个开关，如果你训练时 MIOpen 的自动调优耗时过长，可以试试这个。

设置完成后，再跑一次python -c "import torch"，确认没有报错，就可以进入数据阶段了。

3. RoboTwin 的数据管线：检索、下载、校验与组织

3.1 数据从哪来：官方数据集与本地生成两种路径

RoboTwin 之所以引起我的兴趣，很大程度上是它在数据层面的设计。它的数据不是一堆散落的 hdf5 文件，而是围绕 Genesis 仿真引擎建立了一套自动化生成和检索机制。

跑通训练的第一种路径是使用官方数据集。你需要在 RoboTwin 仓库的 release 页面找到数据文件，通常会遇到文件拆成几十个分卷的情况。这种方式的优点是数据已经经过校验，直接指向训练脚本就能跑；缺点是如果你想换任务、换场景，官方数据的形态跟你实际的需求往往对不上。

第二种路径是本地生成数据。RoboTwin 提供数据生成脚本，你可以指定任务的 ID，在 Genesis 仿真环境中自动生成示范数据。这是更贴合自定义需求的路径，也是“数据+检索”这套机制真正的价值所在。我强烈建议你至少在本地生成一个小规模数据切片，感受一下整个过程，再去碰官方大包。

3.2 “检索”的双重含义：任务库检索与 RAG 技能检索

标题里的“检索”两个字，我认为可以从两个层面理解。

第一个层面是数据集的检索。RoboTwin 官方数据涉及拾放、堆叠、开瓶、双手协作等多种任务类型。如果你需要在本地从一个大而全的数据集中筛出特定的任务做训练，就需要按照任务名或指令标签去做过滤。RoboTwin 的仓库里有现成的数据描述文件，列出了每个数据包对应的任务 ID、物体模型和语言指令，你可以用这些文件做一次离线索引，然后再批量下载。

第二个层面更有意思：RAG 检索增强，也就是在数据生成阶段，通过检索与任务描述最相关的运动技能模板来生成训练数据。RoboTwin 的做法大致是这样的：先用语言模型生成任务描述，然后在已有的技能库中检索与之匹配的轨迹模板；再把模板转换成仿真中的动作序列；最后在 Genesis 中并行回放这些动作，只有回放成功的样例才会被保留进数据集。

这一步的实用价值在于，你不需要为每个新任务手写几百条轨迹。只要你有一个覆盖基础技能的检索库，新的任务描述进来后，系统能以较高的概率自动组装出一条可执行的示范轨迹。我对这个机制的体会是：它把“给数据打标签”变成了“让数据按语义自动检索生成”，本质上很像把大模型的 RAG 思想搬到了低层运动技能生成上。

3.3 本地组织格式与加载配置

RoboTwin 的数据目录组织方式，不同版本可能略有差异，但常见结构类似这样：

dataset/ task_pick_place/ episode_0000.hdf5 episode_0001.hdf5 ... task_open_bottle/ episode_0000.hdf5 ... meta/ task_description.json object_list.json

每个 HDF5 文件里通常存了图像帧、机械臂关节位置、末端执行器状态、动作指令和语言指令。训练脚本在加载数据时，会读取一个config里指定的数据根目录和任务列表。

我第一次加载官方数据时，就栽在目录路径的格式上：官方示例代码默认数据路径是./data，但我放在了./dataset下，结果训练脚本直接报找不到文件。后来重新梳理了数据组织方式，把任务名写成跟 meta 文件里完全一致的大小写格式，才顺利跑通。

提示：如果你用 RoboTwin 训练时发现“数据列表为空”，十有八九是任务名不匹配。先检查 meta 文件里的任务 ID，别急着怀疑下载的文件损坏了。

4. ROCm 下的 RoboTwin 训练实操

4.1 训练入口与关键参数

环境就绪、数据到位之后，就进入训练阶段。RoboTwin 的训练入口是一个组合脚本，通过多个参数来控制任务、算法和数据路径。以常见的 ACT 算法为例，启动命令大致这个样子：

python train.py --algo act --task pick_place --batch-size 32 --lr 1e-4 --ckpt-dir ./checkpoints --epochs 100

不同版本打包的命令可能有差异，但核心参数基本围绕算法类型、任务名、batch size、学习率、检查点目录和训练轮数展开。

关于训练过程中参数的选择，我给出的建议是：第一遍跑通用官方默认参数，不要自作聪明去调学习率。很多人在第一次训练时就调--lr和--batch-size，导致模型不收敛，然后开始怀疑 ROCm 平台有问题，其实只是超参配置不合理。先让整个流程跑通，确认每个环节都没有 bug，再去做实验优化。

4.2 显存管理与 batch size 配置

Radeon Cloud 实例的显存虽大，但 RoboTwin 在图像输入上的开销也不小。我实测下来，一个 32 的 batch size，加上 2 个视角的 RGB 输入，显存占用大约在 20GB 到 24GB 之间。如果你的实例只有 32GB 显存，这个配置已经接近上限了。

显存管理的核心思路是：先小后大，逐步增加。先用 batch size 8 跑一个 epoch，观察rocm-smi的显存占用曲线。如果稳定在 60% 以下，再翻倍。一旦出现torch.cuda.OutOfMemoryError，不要盲目把 batch size 降到 1，先检查是不是数据加载器里有内存泄漏，或者某个可视化开关没关导致有额外的显存开销。

4.3 训练中容易踩的 4 个坑

我这次训练大概踩过四个比较有代表性的坑，列出来供你参考。

第一个坑：MIOpen 自动调优时间过长。第一次训练时，程序会在初始化阶段花大量时间搜索卷积算法，看着像卡死，实际上是在为当前架构做 benchmark。解决方案是提前设置环境变量，跳过或缩短自动调优过程。

第二个坑：数据加载器的 CPU 瓶颈。原始数据是 HDF5 格式，读取并解码图像是纯 CPU 操作。如果 dataloader 的num_workers设置太低，你会在rocm-smi里看到 GPU 利用率很高但没什么实际计算量，训练速度上不去。建议把num_workers调到 8 以上，并且确认数据放在本地固态盘而不是网络盘上。

第三个坑：ROCm 版本与 PyTorch 轮子不匹配。如果你在训练过程中发现某个算子的实现报错“not implemented”或者“unsupported”，大概率是版本不匹配。此时不要试图用export去糊弄，而是查看当前 ROCm 版本，重装对应的 PyTorch 轮子。

第四个坑：检查点路径的权限问题。Radeon Cloud 的实例默认用户是ubuntu，如果你用 root 安装了依赖，再用普通用户跑训练，可能会出现检查点目录无法写入的权限错误。最简单的做法是统一用同一个用户操作，或者在--ckpt-dir里指定一个有写权限的路径。

5. 官方评测闭环：Benchmark、成功率报告与模型导出

5.1 评测脚本怎么跑

训练完成之后，就要进入标题里说的“官方评测闭环”。RoboTwin 的官方评测不是在真机上跑，而是在 Genesis 仿真环境里跑一个独立的评测流程。这个设计的好处很明显：不同研究者可以在完全一致的环境下比较模型表现，不会被真实硬件差异干扰。

评测脚本通常接收一个模型权重目录和任务列表，然后在仿真环境里重复执行多次实验，记录每次尝试的成功与否。启动方式大致类似：

python evaluate.py --algo act --ckpt ./checkpoints/model.pth --task pick_place --episodes 20

--episodes代表跑多少次评测实验。为了得到统计上可信的结果，我建议至少跑 20 次，官方评测一般也按这个量级来。

5.2 结果的判定与报告解读

评测脚本会输出每个 episode 的成功或失败，并汇总一个成功率报告。RoboTwin 官方评测里，单个任务的完成度并不是简单的“成功或失败”二分，而是包含多个子步骤的完成状态。比如开瓶任务，可能细分为接近瓶子、抓住瓶盖、旋转瓶盖、完成开瓶这几个阶段。评测脚本会报告每个阶段的完成率，最后综合成一个成功率。

读这份报告时，我建议你区分“端到端成功率”和“阶段完成率”。如果你的模型端到端成功率很低，但阶段完成率很高，说明模型已经掌握了大部分运动技能，只是在某个关键衔接步骤上出了问题。这种情况下，优先去看失败 episode 里的那个步骤，往往比盲目调参更有效。

5.3 闭环意味着什么：从数据到评测的反复

我跑完第一轮训练和评测之后，对“闭环”这个词有了更具体的理解。闭环的核心，是你能够根据评测结果反向修改数据或参数，然后再次训练和评测，形成可重复迭代的工作流。

RoboTwin 在这方面的优势在于，数据生成、模型训练、仿真评测三个阶段都是自动化脚本，不需要人工介入。我做过一次这样的实验：先用本地生成的小数据集训练一个模型，评测成功率只有 40%；然后从大训练集中检索出与失败案例更相似的任务数据，合并进训练集再训一轮，评测成功率提到了 60% 以上。

这其实就是检索增强在闭环中的意义。你不只是在用数据训练模型，还在用评测结果反过来指导“应该检索和补充哪些数据”。这种工作流一旦跑顺了，整个调优过程就从“盲试”变成了“有方向的迭代”，效率完全不一样。

如果只看官方文档，你可能觉得 RoboTwin 只是一个数据生成工具。但真正在 Radeon Cloud 上跑完一轮之后，我的体会是：它更像一个把数据、训练和评测粘合在一起的操作系统。ROCm 环境确实需要额外花时间配置，但一旦跑通，后续的迭代速度反而比本地折腾 GPU 更让我满意。如果你也在 AMD 生态里摸索具身智能，建议先从一个小任务、一批小数据、一轮评测开始，跑通闭环，然后你自然会明白该往哪个方向加量。