ALOHA ACT这个项目关注机器人模仿学习的应该都听过。它把低成本的双手臂操作平台和基于Transformer的动作分块策略结合起来让机械臂能学会整理、插销、叠放这类精细操作。我这次复现的目标很简单在一套AMD 9700X处理器加RTX 5070 Ti显卡、CUDA 12.8环境的机器上把ACT从数据采集、模型训练到仿真评分完整跑通。这套组合不算顶级但算力足够真正麻烦的是兼容性——50系显卡是最新Blackwell架构社区里大部分老教程还停留在4090配CUDA 11.8直接照抄作业基本会死在环境安装上。这篇文章是我的实际复现记录不是官方教程的翻译。如果你手里同样是9700X、5070 Ti这类新硬件正打算复现ACT或者类似的动作分块模仿学习项目这里面的环境和踩坑部分应该能帮你省下不少排查时间。我也会把训练参数怎么定、数据集怎么检查、checkpoint怎么挑这些实操细节讲清楚争取让你照着走一遍就能跑出结果。1. 为什么是9700X5070 Ti这套硬件对ALOHA ACT到底意味着什么1.1 CPU与GPU的实际分工ACT并不是动辄几百亿参数的超大模型。它的主体是CVAE加Transformer规模中等对算力的要求属于中端偏上。CPU在里面的主要职责是数据读取、三路摄像头图像的解码以及一些在线预处理GPU负责网络的前向传播和反向传播。9700X是8核16线程单核频率高跑PyTorch的DataLoader和处理HDF5数据几乎没有瓶颈。实际训练时我观察过CPU占用率大部分时间在40%上下波动说明CPU不是短板瓶颈主要还是在GPU算力上。很多人在配置单上纠结要不要上更贵的CPU从ACT复现的角度看9700X已经足够。但如果你的数据集规模很大或者你打算同时跑多个训练任务那么多核优势才会体现出来。另外9700X的内存控制器和DDR5带宽对HDF5这种文件的连续读取也有帮助数据集录制和训练时的随机读取速度都比老平台明显快。1.2 5070 Ti的显存和架构是决定性因素RTX 5070 Ti有16GB显存对ACT而言刚好卡在够用和紧张的分界线上。官方参考配置batch_size8在这个显存下可以跑但如果你想在训练的同时再开一个评测进程或者把图像输入尺寸调大就有爆显存的风险。更重要的是50系是Blackwell架构计算能力是sm_120必须CUDA 12.8以上的运行时才包含对应的GPU kernel。这也是标题里CUDA 12.8不是随手写的而是这套硬件能不能跑ACT的第一道硬门槛。举一个直观的对比老教程里最常用的CUDA 11.8加PyTorch 2.0组合在5070 Ti上连最基本的张量计算都做不了因为旧PyTorch的wheel包里根本没有为sm_120编译的kernel。官方在适配新卡上通常会有滞后所以需要找到新版本的PyTorch才行。下面这个表格是我做选型时的对比依据配置GPU架构计算能力最低可用 CUDA显存复现ACT的定位RTX 4090Ada Lovelacesm_89CUDA 11.824GB社区教程最多无额外兼容负担RTX 4070 Ti SuperAda Lovelacesm_89CUDA 11.816GB显存和5070 Ti同级可跑batch8RTX 5070 TiBlackwellsm_120CUDA 12.816GB必须cu128全家桶新硬件首选A100Amperesm_80CUDA 11.x40GB原论文环境训练时间最短1.3 为什么不能沿用老教程的环境组合我之前搜过的复现经验贴绝大多数都是4090配CUDA 11.8、PyTorch 2.0这个组合在Ada架构上验证过很多次没问题。但到了5070 Ti这里CUDA 11.8下所有旧版PyTorch都无法识别GPU强行跑会得到一个很经典的错误CUDA error: no kernel image is available for execution on the device。这个错误的意思是GPU架构和当前PyTorch里编译好的kernel不匹配不是你的GPU坏了也不是驱动没装好。所以我从一开始就决定操作系统驱动、CUDA运行时、PyTorch编译版本三者统一到新的体系里而不是沿用老教程。具体来说就是驱动用570系列以上PyTorch安装cu128构建Python版本固定在3.10。这是整个复现计划里最重要的一次选型后面所有环节都建立在它之上。2. 环境搭建CUDA 12.8时代的第一道坎2.1 驱动与CUDA之间的微妙关系系统我用的Ubuntu 22.04。有一个容易误会的点由于PyTorch的cu128 wheel自带CUDA runtime其实不需要在系统里单独装一套完整的CUDA Toolkit。但不代表驱动可以不管驱动版本必须足够新。我一开始没注意驱动版本装好PyTorch后执行torch.cuda.is_available()返回True但一往GPU上放数据就报错nvidia-smi里显示CUDA driver version is insufficient。把驱动升到570系列之后问题才消失。这里建议用NVIDIA官方驱动的network installer装避免用系统自带驱动源因为新驱动对Blackwell架构的支持最全。装完驱动直接重启然后跑一下nvidia-smi确认能看到RTX 5070 Ti驱动版本在570以上再继续下一步。2.2 PyTorch cu128安装与验证安装命令比较简单我用的这个pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128注意不是默认的PyTorch源必须走cu128这个index。PyTorch从2.7版本开始提供cu128构建所以装到的基本会是2.7及以上版本。装完以后强烈建议做一次最小验证import torch print(torch.__version__) # 2.7.0cu128 print(torch.cuda.is_available()) # True print(torch.cuda.get_device_name(0)) # RTX 5070 Ti torch.zeros(1).cuda()最后一行torch.zeros(1).cuda()如果能执行且不报错说明kernel已经正确装上。这一步能筛掉后面99%的环境问题。很多人卡在torch.cuda.is_available()是False要么是装了CPU版本的torch要么就是驱动太旧。如果发现安装来源不对先卸载torch和torchvision再重新装cu128版本。2.3 依赖版本不能闭眼装ACT官方仓库的requirements.txt是基于老环境写的在新硬件和新Python版本下直接装会有几个兼容冲突。按我这次的经验这四个包需要特别留意timm跟PyTorch 2.7有一些API名称变动版本太老会在创建模型时报AttributeError建议用0.9.x以上版本pymunkALOHA仿真环境里模拟物理交互需要它它的版本不能随便升以仓库要求为准因为API有变动mujoco需要用独立的mujoco包版本在2.3.x左右跟老的mujoco_py不是同一个东西gymact里的环境代码按老gym接口写的新版gymnasium改了API如果以后出现gym.make相关报错需要做兼容处理或固定版本我最后是先按requirements.txt装一遍再逐个把报错的包拉到正确版本。特别要注意HDF5和mujoco这些带二进制依赖的包不建议用conda和pip混着装容易出两个版本互相覆盖的问题统一用pip管理最省心。2.4 Python版本别选太新Python 3.10是我实测下来最稳妥的选择。3.11和3.12本身兼容性也不差但有一些老依赖在新Python下没有预编译wheel需要现场编译而现场编译对GCC版本有要求。Ubuntu 22.04默认自带GCC 11遇到需要C17扩展的包基本够用。如果出现gcc: error: unrecognized command-line option这类问题先检查是不是GCC版本太低该升级就升级别在这一步纠结太久。3. 数据从哪来没有真实机械臂时的仿真数据集制作3.1 先跑通ALOHA仿真环境ALOHA本体是一套成本不低的双臂机械臂硬件非刚需可以先不买直接用仓库自带的MuJoCo仿真环境复现算法。ACT仓库里有一个仿真环境模块配合record_sim_episodes.py可以在仿真里录制机械臂完成任务的数据。仿真环境内置了一个经典任务场景机械臂、夹爪、桌面、目标物的起始位置都会随机每一次演示轨迹都有变化。一个容易忽略的点仿真演示数据不是用键盘遥控录的仓库里内置了脚本化策略每个episode自动生成一段轨迹。这样做的好处是数据一致性好坏处是轨迹多样性有限会直接影响最终泛化效果。所以录制的时候我建议生成50个episode并且在每次录制时让目标位置和机械臂起始位置保持随机不要录出50个几乎完全一样的轨迹。3.2 数据集结构长什么样录制完成的数据用HDF5保存内部结构大致是这样的observations/qpos机械臂关节角度作为策略观测的一部分observations/images/cam_high顶部相机图像提供全局视角observations/images/cam_left_wrist左手腕相机图像observations/images/cam_right_wrist右手腕相机图像action每个时间步的关节目标动作了解这个结构很重要因为constants.py里的camera_names列表必须和这里的图像键名完全一致少一个训练时就会报KeyError。我建议录完之后用仓库自带的visualize_episodes.py把所有episode完整播放一遍确认图像、qpos、action三个模态的时间轴能对上。这一步就算多花半小时也值因为数据集的问题越早发现越好解决。3.3 数据数量和质量怎么把握官方参考建议是50个episode。我实测下来20个episode也能训出一个会动的模型但成功率不稳定测试的时候经常翻车。换成50个之后成功率明显上升。另外episode长度也要看ACT训练时会对序列做截断和padding长度分布太乱会让loss出现周期性波动。录制时脚本化策略本身成功率不是100%所以录完要检查一下有多少episode是真正完成了任务。如果某些episode从开始到结束都没碰到目标物直接删掉不然模型会学到中途放弃这种错误行为。判断episode是否成功最直观的方式就是看可视化视频里机械臂的末端坐标和目标物的最终位置是否重合。这一步不要偷懒数据质量直接决定后面所有环节的天花板。4. ACT模型训练参数、显存与训练时长的实测节奏4.1 先弄清仓库代码的模块边界在跑训练之前建议把代码结构快速过一遍这样报错后能快速定位问题。几个关键文件的作用分别是constants.py所有全局配置数据处理、模型参数、任务名、相机名都在这里改基本上是训练前唯一需要动手的文件policy.pyACTPolicy类CVAE编码器、Transformer编码解码器、前向传播和loss计算都在里面train.py数据加载、训练循环、checkpoint保存eval.py加载模型在仿真环境里评测训练的自定义内容大多集中在constants.py基本不需要动模型结构。如果以后想在ACT基础上做算法改进再去policy.py里改网络。4.2 超参数设置与它们背后的逻辑这里直接给表格是我这次跑通的配置参数我的设置作用与理由chunk_size100一次预测未来100步动作序列对应约6秒的行为是ACT动作分块的核心batch_size816GB显存下能稳住的配置OOM再降到4lr1e-5官方设定不要习惯性改成1e-4容易震荡num_epochs2000官方建议轮数训练时间约8小时以上camera_namescam_high, cam_left_wrist, cam_right_wrist三路相机输入缺一个模型就学不到对应视角信息policy_typeACT指定使用ACT策略而不是默认的纯Transformer策略chunk_size这个参数值得多说两句。ACT的核心思想是让模型一次预测100步动作序列而不是逐帧预测。逐帧预测的问题在于误差会一步步累积第一步偏一点第二步偏更多最后整个轨迹漂移。分块预测相当于让模型先看到任务的整体走势再靠每次推理时滚动更新来修正偏差。chunk_size设太大模型需要提前规划太长时间反而学不好设太小就退化成逐帧预测没有分块的意义。100是论文里验证过的合理值不用改。4.3 训练命令与日志怎么看训练命令大致是python train.py --dataset data_dir --ckpt_dir ckpt_dir --policy_type ACT --batch_size 8 --num_epochs 2000训练日志里重点看train loss的趋势以及每个epoch保存的checkpoint。我这次前100个epoch里loss下降很快后面慢慢变缓到400到500个epoch之间开始平滑1000个epoch之后训练还在继续但每个checkpoint的成功率提升已经很小。官方建议在A100上跑2000个epoch大约需要500分钟5070 Ti按我实测大概需要8小时出头具体取决于数据集长度和图像解码速度你跑的时候有个心理预期就行。训练过程中还有一个细节代码默认每100个epoch保存一次checkpoint比如100、200、300一直到2000。所以中途中断也不是坏事至少能拿到前面已经保存的模型。如果训练到一半显存溢出程序直接崩溃最后一个checkpoint可能是之前保存的不会完全白跑。4.4 16GB显存下的OOM处理思路训练到一半爆显存第一反应是降batch_size从8降到4。不过不要同时把图像尺寸缩太多ACT对图像分辨率比较敏感图像模糊了模型学不到细节。另一个办法是确认是不是验证流程把多余数据一次性放进了GPU如果验证集比较大单独跑评测会更安全。还有一个容易忽略的点如果机器上开着桌面环境或浏览器显存被占掉一部分训练时就会更紧张。我在跑训练时关掉了不必要的图形界面batch8就稳定了。如果还想继续用大batch可以考虑把视觉骨干从默认换成一个参数量更小的网络但会改变模型精度需要重新调参。这个留作后续优化方向第一个模型先保证能跑通。5. 评估与部署把checkpoint变成真实动作5.1 评估脚本怎么用训练完成后用eval.py在仿真环境里做评测。命令大致是python eval.py --task sim_transfer_cube --dataset data_dir --ckpt_dir ckpt_dir --checkpoint epoch编号 --num_episodes 100评测逻辑是加载指定checkpoint让模型控制仿真机械臂重复执行任务每个episode起始状态不同最后统计成功率。这个成功率比训练loss更能说明模型好坏。评估时会看到模型动作在仿真里实时执行有没有稳定抓取、有没有放到位一目了然。5.2 成功率不是越高越好但要有一个参照官方预训练模型在任务上能到90%以上的成功率。自己完整训练出来的模型成功率会受数据质量和训练时长影响我看到的结果在80%附近还算正常。如果你发现成功率特别低先不要怀疑代码大概率是数据集问题比如episode数量不够或任务完成率低。checkpoint的选择也要讲究。很多人会直接用最后一个checkpoint但训练后期有时会出现轻微过拟合导致成功率回落。正确做法是用eval.py把最近几个checkpoint都各跑几十个episode记录成功率挑最高的那个做最终模型。这个挑模型的过程很值不到半小时但能让最终效果差出一截。5.3 从仿真到真机的差距如果你想把这个模型迁移到真实ALOHA硬件上除了模型本身还有三个环节最容易丢精度相机标定、机械臂本体标定、执行频率。ACT在真机上通常以15Hz左右的频率读取观测并输出动作块但实际推理耗时必须低。模型会预测100步但在每个控制周期都会用当前观测重新推理新的动作序列也就是滚动更新所以GPU推理延迟直接影响控制品质。5070 Ti做这个模型的前向推理实测在几十毫秒控制节奏完全跟得上。真机的执行频率和仿真的控制频率未必完全一致这需要在部署代码里做时间戳对齐不然机械臂动作会出现明显的迟滞。没人能保证仿真里跑通的checkpoint直接到真机上就100%好用但这个差距可以通过后续微调和数据补充来弥补。6. 复现全程踩坑清单按报错信息定位问题6.1 最常见CUDA no kernel image现象是代码在.cuda()调用或第一次前向传播时报CUDA error: no kernel image is available for execution on the device。这个错误我在最初两个小时里反复遇到原因其实很单纯当前PyTorch版本没有为sm_120架构编译kernel。排查链路是这样的先跑nvidia-smi确认驱动能识别到RTX 5070 Ti驱动版本是不是570以上在Python里打印torch.version.cuda如果显示11.8或12.1问题基本锁定卸载旧torch和torchvision重新用cu128 index安装再执行torch.zeros(1).cuda()验证如果你是照着老教程配置的大概率会走到第二步。我见过有人反复重装驱动解决不了就是因为PyTorch版本没换方向错了。6.2 timm和transformers类型错乱现象是训练到视觉骨干前向传播时报AttributeError: module timm has no attribute create_model或者某个Transformer类名冲突。原因通常是timm版本太老或者环境里存在另一个依赖也带了同名模块。排查思路先看timm版本如果低于0.9升级到0.9.x以上。再看transformers是不是被某个依赖锁成了特别老的版本新timm和老transformers有时会在一些类名上打架。这个坑在官方requirements.txt里没有明确约束需要自己根据报错微调。6.3 MuJoCo在无显示器环境下的渲染失败现象是仿真环境初始化时报OpenGL初始化失败常见的错误信息包含failed to create GL context。如果你在本地带显示器的机器上跑一般不会遇到如果通过远程服务器跑或者完全没有图形环境就需要额外设置。解决方式设置环境变量MUJOCO_GLegl让MuJoCo走EGL离屏渲染或者用xvfb-run python eval.py ...包一层虚拟显示确认系统里安装了libegl1和libgl1-mesa这些OpenGL相关库我的实测是MUJOCO_GLegl最干净不需要额外开虚拟显示服务训练和评测的速度也更快。6.4 Loss一直不降的排查链路如果训练了几百个epochtrain loss都没有下降的意思问题大概率不在网络而在数据或配置链路。我当时的排查顺序打开一个HDF5文件检查action是不是全零或者全一样。如果动作数据没录上模型无从学习检查constants.py里的camera_names和数据集里的图像键名是否完全一致一个错一个漏都会导致观测通道不完整确认学习率是1e-5不是被全局脚本覆盖成了更大的值。1e-4在ACT上会震荡确认policy_type确实是ACT。act仓库支持几种策略如果命令行参数被改掉训练出来的就不是CVAE分块模型收敛行为完全不同我最后发现的问题出在数据集中混杂了失败episode模型怎么学都学不对。把失败episode过滤掉之后loss很快就降下来了。这里再强调一次花时间清洗数据比任何调参都有效。6.5 关于显存和混合精度的一点经验ACT训练默认不开AMP混合精度。50系显卡支持FP16和FP8理论上能提速但ACT的loss计算里有些数值在混合精度下不稳我没有强行开AMP而是保持FP32训练通过控制batch_size来管理显存。实测速度不算慢不值得为了那一点速度增加调试风险。后来我发现训练时真正拖慢速度的不是GPU算力而是CPU端在做HDF5读取和图像解码所以数据加载的预处理可以在训练脚本里适当调大预取数让GPU尽量保持满负荷。最后再分享一个我觉得最容易被忽略的判断标准复现这类算法时不要只盯着训练loss曲线。ACT最终的价值体现在任务成功率上而不是loss绝对值。我第一次训练时loss到800个epoch后基本不再变化还以为模型学废了结果用eval.py跑下来才发现那个800步的checkpoint效果反而最好。所以训练中途不要急着改参数先把每个checkpoint都保存好统一用仿真评测来挑最终模型。这个方法在ALOHA ACT上比看loss曲线可靠得多。 
长河君 · 2026/10/23 5:39:40 · 阅读 1.2k ALOHA ACT复现全记录：AMD 9700X+RTX 5070 Ti环境搭建与踩坑指南
ALOHA ACT这个项目关注机器人模仿学习的应该都听过。它把低成本的双手臂操作平台和基于Transformer的动作分块策略结合起来让机械臂能学会整理、插销、叠放这类精细操作。我这次复现的目标很简单在一套AMD 9700X处理器加RTX 5070 Ti显卡、CUDA 12.8环境的机器上把ACT从数据采集、模型训练到仿真评分完整跑通。这套组合不算顶级但算力足够真正麻烦的是兼容性——50系显卡是最新Blackwell架构社区里大部分老教程还停留在4090配CUDA 11.8直接照抄作业基本会死在环境安装上。这篇文章是我的实际复现记录不是官方教程的翻译。如果你手里同样是9700X、5070 Ti这类新硬件正打算复现ACT或者类似的动作分块模仿学习项目这里面的环境和踩坑部分应该能帮你省下不少排查时间。我也会把训练参数怎么定、数据集怎么检查、checkpoint怎么挑这些实操细节讲清楚争取让你照着走一遍就能跑出结果。1. 为什么是9700X5070 Ti这套硬件对ALOHA ACT到底意味着什么1.1 CPU与GPU的实际分工ACT并不是动辄几百亿参数的超大模型。它的主体是CVAE加Transformer规模中等对算力的要求属于中端偏上。CPU在里面的主要职责是数据读取、三路摄像头图像的解码以及一些在线预处理GPU负责网络的前向传播和反向传播。9700X是8核16线程单核频率高跑PyTorch的DataLoader和处理HDF5数据几乎没有瓶颈。实际训练时我观察过CPU占用率大部分时间在40%上下波动说明CPU不是短板瓶颈主要还是在GPU算力上。很多人在配置单上纠结要不要上更贵的CPU从ACT复现的角度看9700X已经足够。但如果你的数据集规模很大或者你打算同时跑多个训练任务那么多核优势才会体现出来。另外9700X的内存控制器和DDR5带宽对HDF5这种文件的连续读取也有帮助数据集录制和训练时的随机读取速度都比老平台明显快。1.2 5070 Ti的显存和架构是决定性因素RTX 5070 Ti有16GB显存对ACT而言刚好卡在够用和紧张的分界线上。官方参考配置batch_size8在这个显存下可以跑但如果你想在训练的同时再开一个评测进程或者把图像输入尺寸调大就有爆显存的风险。更重要的是50系是Blackwell架构计算能力是sm_120必须CUDA 12.8以上的运行时才包含对应的GPU kernel。这也是标题里CUDA 12.8不是随手写的而是这套硬件能不能跑ACT的第一道硬门槛。举一个直观的对比老教程里最常用的CUDA 11.8加PyTorch 2.0组合在5070 Ti上连最基本的张量计算都做不了因为旧PyTorch的wheel包里根本没有为sm_120编译的kernel。官方在适配新卡上通常会有滞后所以需要找到新版本的PyTorch才行。下面这个表格是我做选型时的对比依据配置GPU架构计算能力最低可用 CUDA显存复现ACT的定位RTX 4090Ada Lovelacesm_89CUDA 11.824GB社区教程最多无额外兼容负担RTX 4070 Ti SuperAda Lovelacesm_89CUDA 11.816GB显存和5070 Ti同级可跑batch8RTX 5070 TiBlackwellsm_120CUDA 12.816GB必须cu128全家桶新硬件首选A100Amperesm_80CUDA 11.x40GB原论文环境训练时间最短1.3 为什么不能沿用老教程的环境组合我之前搜过的复现经验贴绝大多数都是4090配CUDA 11.8、PyTorch 2.0这个组合在Ada架构上验证过很多次没问题。但到了5070 Ti这里CUDA 11.8下所有旧版PyTorch都无法识别GPU强行跑会得到一个很经典的错误CUDA error: no kernel image is available for execution on the device。这个错误的意思是GPU架构和当前PyTorch里编译好的kernel不匹配不是你的GPU坏了也不是驱动没装好。所以我从一开始就决定操作系统驱动、CUDA运行时、PyTorch编译版本三者统一到新的体系里而不是沿用老教程。具体来说就是驱动用570系列以上PyTorch安装cu128构建Python版本固定在3.10。这是整个复现计划里最重要的一次选型后面所有环节都建立在它之上。2. 环境搭建CUDA 12.8时代的第一道坎2.1 驱动与CUDA之间的微妙关系系统我用的Ubuntu 22.04。有一个容易误会的点由于PyTorch的cu128 wheel自带CUDA runtime其实不需要在系统里单独装一套完整的CUDA Toolkit。但不代表驱动可以不管驱动版本必须足够新。我一开始没注意驱动版本装好PyTorch后执行torch.cuda.is_available()返回True但一往GPU上放数据就报错nvidia-smi里显示CUDA driver version is insufficient。把驱动升到570系列之后问题才消失。这里建议用NVIDIA官方驱动的network installer装避免用系统自带驱动源因为新驱动对Blackwell架构的支持最全。装完驱动直接重启然后跑一下nvidia-smi确认能看到RTX 5070 Ti驱动版本在570以上再继续下一步。2.2 PyTorch cu128安装与验证安装命令比较简单我用的这个pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128注意不是默认的PyTorch源必须走cu128这个index。PyTorch从2.7版本开始提供cu128构建所以装到的基本会是2.7及以上版本。装完以后强烈建议做一次最小验证import torch print(torch.__version__) # 2.7.0cu128 print(torch.cuda.is_available()) # True print(torch.cuda.get_device_name(0)) # RTX 5070 Ti torch.zeros(1).cuda()最后一行torch.zeros(1).cuda()如果能执行且不报错说明kernel已经正确装上。这一步能筛掉后面99%的环境问题。很多人卡在torch.cuda.is_available()是False要么是装了CPU版本的torch要么就是驱动太旧。如果发现安装来源不对先卸载torch和torchvision再重新装cu128版本。2.3 依赖版本不能闭眼装ACT官方仓库的requirements.txt是基于老环境写的在新硬件和新Python版本下直接装会有几个兼容冲突。按我这次的经验这四个包需要特别留意timm跟PyTorch 2.7有一些API名称变动版本太老会在创建模型时报AttributeError建议用0.9.x以上版本pymunkALOHA仿真环境里模拟物理交互需要它它的版本不能随便升以仓库要求为准因为API有变动mujoco需要用独立的mujoco包版本在2.3.x左右跟老的mujoco_py不是同一个东西gymact里的环境代码按老gym接口写的新版gymnasium改了API如果以后出现gym.make相关报错需要做兼容处理或固定版本我最后是先按requirements.txt装一遍再逐个把报错的包拉到正确版本。特别要注意HDF5和mujoco这些带二进制依赖的包不建议用conda和pip混着装容易出两个版本互相覆盖的问题统一用pip管理最省心。2.4 Python版本别选太新Python 3.10是我实测下来最稳妥的选择。3.11和3.12本身兼容性也不差但有一些老依赖在新Python下没有预编译wheel需要现场编译而现场编译对GCC版本有要求。Ubuntu 22.04默认自带GCC 11遇到需要C17扩展的包基本够用。如果出现gcc: error: unrecognized command-line option这类问题先检查是不是GCC版本太低该升级就升级别在这一步纠结太久。3. 数据从哪来没有真实机械臂时的仿真数据集制作3.1 先跑通ALOHA仿真环境ALOHA本体是一套成本不低的双臂机械臂硬件非刚需可以先不买直接用仓库自带的MuJoCo仿真环境复现算法。ACT仓库里有一个仿真环境模块配合record_sim_episodes.py可以在仿真里录制机械臂完成任务的数据。仿真环境内置了一个经典任务场景机械臂、夹爪、桌面、目标物的起始位置都会随机每一次演示轨迹都有变化。一个容易忽略的点仿真演示数据不是用键盘遥控录的仓库里内置了脚本化策略每个episode自动生成一段轨迹。这样做的好处是数据一致性好坏处是轨迹多样性有限会直接影响最终泛化效果。所以录制的时候我建议生成50个episode并且在每次录制时让目标位置和机械臂起始位置保持随机不要录出50个几乎完全一样的轨迹。3.2 数据集结构长什么样录制完成的数据用HDF5保存内部结构大致是这样的observations/qpos机械臂关节角度作为策略观测的一部分observations/images/cam_high顶部相机图像提供全局视角observations/images/cam_left_wrist左手腕相机图像observations/images/cam_right_wrist右手腕相机图像action每个时间步的关节目标动作了解这个结构很重要因为constants.py里的camera_names列表必须和这里的图像键名完全一致少一个训练时就会报KeyError。我建议录完之后用仓库自带的visualize_episodes.py把所有episode完整播放一遍确认图像、qpos、action三个模态的时间轴能对上。这一步就算多花半小时也值因为数据集的问题越早发现越好解决。3.3 数据数量和质量怎么把握官方参考建议是50个episode。我实测下来20个episode也能训出一个会动的模型但成功率不稳定测试的时候经常翻车。换成50个之后成功率明显上升。另外episode长度也要看ACT训练时会对序列做截断和padding长度分布太乱会让loss出现周期性波动。录制时脚本化策略本身成功率不是100%所以录完要检查一下有多少episode是真正完成了任务。如果某些episode从开始到结束都没碰到目标物直接删掉不然模型会学到中途放弃这种错误行为。判断episode是否成功最直观的方式就是看可视化视频里机械臂的末端坐标和目标物的最终位置是否重合。这一步不要偷懒数据质量直接决定后面所有环节的天花板。4. ACT模型训练参数、显存与训练时长的实测节奏4.1 先弄清仓库代码的模块边界在跑训练之前建议把代码结构快速过一遍这样报错后能快速定位问题。几个关键文件的作用分别是constants.py所有全局配置数据处理、模型参数、任务名、相机名都在这里改基本上是训练前唯一需要动手的文件policy.pyACTPolicy类CVAE编码器、Transformer编码解码器、前向传播和loss计算都在里面train.py数据加载、训练循环、checkpoint保存eval.py加载模型在仿真环境里评测训练的自定义内容大多集中在constants.py基本不需要动模型结构。如果以后想在ACT基础上做算法改进再去policy.py里改网络。4.2 超参数设置与它们背后的逻辑这里直接给表格是我这次跑通的配置参数我的设置作用与理由chunk_size100一次预测未来100步动作序列对应约6秒的行为是ACT动作分块的核心batch_size816GB显存下能稳住的配置OOM再降到4lr1e-5官方设定不要习惯性改成1e-4容易震荡num_epochs2000官方建议轮数训练时间约8小时以上camera_namescam_high, cam_left_wrist, cam_right_wrist三路相机输入缺一个模型就学不到对应视角信息policy_typeACT指定使用ACT策略而不是默认的纯Transformer策略chunk_size这个参数值得多说两句。ACT的核心思想是让模型一次预测100步动作序列而不是逐帧预测。逐帧预测的问题在于误差会一步步累积第一步偏一点第二步偏更多最后整个轨迹漂移。分块预测相当于让模型先看到任务的整体走势再靠每次推理时滚动更新来修正偏差。chunk_size设太大模型需要提前规划太长时间反而学不好设太小就退化成逐帧预测没有分块的意义。100是论文里验证过的合理值不用改。4.3 训练命令与日志怎么看训练命令大致是python train.py --dataset data_dir --ckpt_dir ckpt_dir --policy_type ACT --batch_size 8 --num_epochs 2000训练日志里重点看train loss的趋势以及每个epoch保存的checkpoint。我这次前100个epoch里loss下降很快后面慢慢变缓到400到500个epoch之间开始平滑1000个epoch之后训练还在继续但每个checkpoint的成功率提升已经很小。官方建议在A100上跑2000个epoch大约需要500分钟5070 Ti按我实测大概需要8小时出头具体取决于数据集长度和图像解码速度你跑的时候有个心理预期就行。训练过程中还有一个细节代码默认每100个epoch保存一次checkpoint比如100、200、300一直到2000。所以中途中断也不是坏事至少能拿到前面已经保存的模型。如果训练到一半显存溢出程序直接崩溃最后一个checkpoint可能是之前保存的不会完全白跑。4.4 16GB显存下的OOM处理思路训练到一半爆显存第一反应是降batch_size从8降到4。不过不要同时把图像尺寸缩太多ACT对图像分辨率比较敏感图像模糊了模型学不到细节。另一个办法是确认是不是验证流程把多余数据一次性放进了GPU如果验证集比较大单独跑评测会更安全。还有一个容易忽略的点如果机器上开着桌面环境或浏览器显存被占掉一部分训练时就会更紧张。我在跑训练时关掉了不必要的图形界面batch8就稳定了。如果还想继续用大batch可以考虑把视觉骨干从默认换成一个参数量更小的网络但会改变模型精度需要重新调参。这个留作后续优化方向第一个模型先保证能跑通。5. 评估与部署把checkpoint变成真实动作5.1 评估脚本怎么用训练完成后用eval.py在仿真环境里做评测。命令大致是python eval.py --task sim_transfer_cube --dataset data_dir --ckpt_dir ckpt_dir --checkpoint epoch编号 --num_episodes 100评测逻辑是加载指定checkpoint让模型控制仿真机械臂重复执行任务每个episode起始状态不同最后统计成功率。这个成功率比训练loss更能说明模型好坏。评估时会看到模型动作在仿真里实时执行有没有稳定抓取、有没有放到位一目了然。5.2 成功率不是越高越好但要有一个参照官方预训练模型在任务上能到90%以上的成功率。自己完整训练出来的模型成功率会受数据质量和训练时长影响我看到的结果在80%附近还算正常。如果你发现成功率特别低先不要怀疑代码大概率是数据集问题比如episode数量不够或任务完成率低。checkpoint的选择也要讲究。很多人会直接用最后一个checkpoint但训练后期有时会出现轻微过拟合导致成功率回落。正确做法是用eval.py把最近几个checkpoint都各跑几十个episode记录成功率挑最高的那个做最终模型。这个挑模型的过程很值不到半小时但能让最终效果差出一截。5.3 从仿真到真机的差距如果你想把这个模型迁移到真实ALOHA硬件上除了模型本身还有三个环节最容易丢精度相机标定、机械臂本体标定、执行频率。ACT在真机上通常以15Hz左右的频率读取观测并输出动作块但实际推理耗时必须低。模型会预测100步但在每个控制周期都会用当前观测重新推理新的动作序列也就是滚动更新所以GPU推理延迟直接影响控制品质。5070 Ti做这个模型的前向推理实测在几十毫秒控制节奏完全跟得上。真机的执行频率和仿真的控制频率未必完全一致这需要在部署代码里做时间戳对齐不然机械臂动作会出现明显的迟滞。没人能保证仿真里跑通的checkpoint直接到真机上就100%好用但这个差距可以通过后续微调和数据补充来弥补。6. 复现全程踩坑清单按报错信息定位问题6.1 最常见CUDA no kernel image现象是代码在.cuda()调用或第一次前向传播时报CUDA error: no kernel image is available for execution on the device。这个错误我在最初两个小时里反复遇到原因其实很单纯当前PyTorch版本没有为sm_120架构编译kernel。排查链路是这样的先跑nvidia-smi确认驱动能识别到RTX 5070 Ti驱动版本是不是570以上在Python里打印torch.version.cuda如果显示11.8或12.1问题基本锁定卸载旧torch和torchvision重新用cu128 index安装再执行torch.zeros(1).cuda()验证如果你是照着老教程配置的大概率会走到第二步。我见过有人反复重装驱动解决不了就是因为PyTorch版本没换方向错了。6.2 timm和transformers类型错乱现象是训练到视觉骨干前向传播时报AttributeError: module timm has no attribute create_model或者某个Transformer类名冲突。原因通常是timm版本太老或者环境里存在另一个依赖也带了同名模块。排查思路先看timm版本如果低于0.9升级到0.9.x以上。再看transformers是不是被某个依赖锁成了特别老的版本新timm和老transformers有时会在一些类名上打架。这个坑在官方requirements.txt里没有明确约束需要自己根据报错微调。6.3 MuJoCo在无显示器环境下的渲染失败现象是仿真环境初始化时报OpenGL初始化失败常见的错误信息包含failed to create GL context。如果你在本地带显示器的机器上跑一般不会遇到如果通过远程服务器跑或者完全没有图形环境就需要额外设置。解决方式设置环境变量MUJOCO_GLegl让MuJoCo走EGL离屏渲染或者用xvfb-run python eval.py ...包一层虚拟显示确认系统里安装了libegl1和libgl1-mesa这些OpenGL相关库我的实测是MUJOCO_GLegl最干净不需要额外开虚拟显示服务训练和评测的速度也更快。6.4 Loss一直不降的排查链路如果训练了几百个epochtrain loss都没有下降的意思问题大概率不在网络而在数据或配置链路。我当时的排查顺序打开一个HDF5文件检查action是不是全零或者全一样。如果动作数据没录上模型无从学习检查constants.py里的camera_names和数据集里的图像键名是否完全一致一个错一个漏都会导致观测通道不完整确认学习率是1e-5不是被全局脚本覆盖成了更大的值。1e-4在ACT上会震荡确认policy_type确实是ACT。act仓库支持几种策略如果命令行参数被改掉训练出来的就不是CVAE分块模型收敛行为完全不同我最后发现的问题出在数据集中混杂了失败episode模型怎么学都学不对。把失败episode过滤掉之后loss很快就降下来了。这里再强调一次花时间清洗数据比任何调参都有效。6.5 关于显存和混合精度的一点经验ACT训练默认不开AMP混合精度。50系显卡支持FP16和FP8理论上能提速但ACT的loss计算里有些数值在混合精度下不稳我没有强行开AMP而是保持FP32训练通过控制batch_size来管理显存。实测速度不算慢不值得为了那一点速度增加调试风险。后来我发现训练时真正拖慢速度的不是GPU算力而是CPU端在做HDF5读取和图像解码所以数据加载的预处理可以在训练脚本里适当调大预取数让GPU尽量保持满负荷。最后再分享一个我觉得最容易被忽略的判断标准复现这类算法时不要只盯着训练loss曲线。ACT最终的价值体现在任务成功率上而不是loss绝对值。我第一次训练时loss到800个epoch后基本不再变化还以为模型学废了结果用eval.py跑下来才发现那个800步的checkpoint效果反而最好。所以训练中途不要急着改参数先把每个checkpoint都保存好统一用仿真评测来挑最终模型。这个方法在ALOHA ACT上比看loss曲线可靠得多。