Diffusion Policy 具身智能 VLA 模型昇腾 310P 离线推理部署指南ONNX 导出、ATC 转 OM 与 PushT 仿真评测【免费下载链接】cann-recipes-embodied-ai本项目针对具身智能业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-embodied-ai本篇技术指南以 cann-recipes-embodied-ai 仓库中 manipulation/diffusion-policy/infer_with_om 目录为核心完整讲解 Diffusion PolicyDP这一基于扩散模型的模仿学习控制策略在昇腾 310P 上的部署全流程环境搭建、PyTorch 模型导出 ONNX、ATC 转 OM、精度验证以及基于 OM 后端在 MuJoCo PushT 仿真环境中的评测。读完本文你将能够独立复现 Host 导出 ONNX → 310P ATC 转 OM → 310P 仿真评测 的完整链路并掌握归一化处理器迁移、输入输出 schema 解析、误差指标判读等关键实战技巧。DP 模型与任务背景什么是 Diffusion PolicyDiffusion Policy论文《Diffusion Policy: Visuomotor Policy Learning via Action Diffusion》是一种典型的基于扩散模型的模仿学习控制策略。与传统的自回归策略不同DP 将机器人策略表示为一个条件去噪扩散过程策略网络在给定当前观测视觉图像 机器人状态的条件下通过多次去噪迭代逐步恢复出一段未来的动作序列。这种建模方式带来两个显著优势多模态动作分布处理能力同一观测下存在多种可行的动作轨迹时扩散模型能够自然地表示这种多峰分布而自回归形式往往只能取单峰高维动作空间稳定性对高维动作输出的训练和采样过程更稳定不易出现累积误差。DP 是许多后续研究如 3D 扩散策略等的基石也是当前具身智能 VLAVision-Language-Action方向的重要基线模型。本样例使用的示例模型与任务本样例使用的示例模型为 HuggingFace 上的lerobot/diffusion_pusht该模型是在 MuJoCo 仿真环境中针对PushT任务微调得到的模型。PushT 任务要求机器人通过推杆将 T 形物体推送到目标位置是一个经典的 2D 视觉操作仿真任务。模型文件在本地以目录形式组织例如dp_model/其中config.json定义了模型的输入输出特征与推理参数model.safetensors存放权重。模型的输入输出定义DP 模型的输入输出格式定义在模型目录的config.json中。样例使用一路摄像头其核心配置如下input_features: { observation.image: { shape: [ 3, 96, 96 ], type: VISUAL }, observation.state: { shape: [ 2 ], type: STATE } }, output_features: { action: { shape: [ 2 ], type: ACTION } }, n_action_steps: 8,对应的输入输出数据规格可归纳为输入数据名数据类型(dtype)数据大小(shape)observation.images_xxx摄像头图像Float32$[1, N_c, 3, H, W]$observation.state机器人位姿Float32$[1, N_k]$输出数据名数据大小(shape)actions$[1, chunk_size, N_k]$参数符号说明$N_c$摄像头个数图片个数训练时决定通常为一至三路摄像头$N_k$自由度由机器人构型决定PushT 示例中为 2$H, W$摄像头拍摄 RGB 图像分辨率示例中为 96×96$chunk_size$机器人执行步数个数定义为n_action_steps示例中为 8。从源码看convert_and_verify_onnx.py 中通过_infer_action_dim从config.json的output_features[action].shape[0]推断动作维度、通过_infer_n_action_steps读取n_action_steps并通过cfg.image_features与cfg.robot_state_feature自动构建与训练配置严格一致的确定性输入从而保证导出与验证时的 shape 与模型实际定义一致。多摄像头场景下脚本会为每个摄像头 key 单独构造输入并堆叠出聚合的OBS_IMAGES张量shape 为(B, s, n, C, H, W)其中 n 为摄像头数。昇腾 310P 运行环境配置与昇腾平台相关的环境配置OM 模型转换及运行需要安装 CANN 软件包。本样例的编译执行依赖 CANN 开发套件包cann-toolkit与 CANN 二进制算子包cann-kernels支持的 CANN 软件版本为CANN 8.0.0-8.2.RC1。请从昇腾社区软件包下载地址下载对应架构软件包例如Ascend-cann-toolkit_8.2.RC1_linux-x86_64.run与Ascend-cann-kernels-310p_8.2.RC1_linux-x86_64.run并按 CANN 安装文档依次安装。安装完成后每次新建终端都需要先 source 环境变量# ${cann_install_path} 为 CANN 包的实际安装目录注意每次新建终端时首先 source 一下 set_env.sh # 方式1默认路径安装以 root 用户为例 source /usr/local/Ascend/ascend-toolkit/set_env.sh # 方式2指定路径进行安装 source ${cann_install_path}/ascend-toolkit/set_env.sh与昇腾服务器无关的环境配置在 Host 侧CPU/GPU 机器准备 lerobot 运行环境用于模型加载、ONNX 导出与归一化参数迁移# 1) 拉取 lerobot 仓库并切到指定 commit cd manipulation git clone https://github.com/huggingface/lerobot.git # 如果 contrib 下没有 lerobot 目录 cd lerobot git checkout d9e74a9d374a8f26582ad326c699740a227b483c # 2) 创建运行环境 conda create -y -n lerobot python3.10 conda activate lerobot # 3) 安装 lerobot本地可编辑安装 pip install -e . # 4) 仿真依赖Aloha 仿真需要 gym_aloha / gym-aloha # 推荐用 extra 一次性安装 pip install -e .[aloha] # 5) 固定 numpy 版本如你的环境需要补齐相关依赖缺失 pip install numpy1.26.0 pip install decorator pip install gym_pusht pip install pymunk7.0.0 # pumunk 版本过高不兼容 cd ../diffusion-policy/infer_with_om仿真渲染MuJoCo无头模式如果服务器/容器缺少显示环境或 OpenGL 渲染后端MuJoCo 可能无法正常渲染。可以在运行仿真/评测前指定 EGL 无头渲染export MUJOCO_GLeglDP 在昇腾 310P 上的推理步骤总览本样例采用离线推理模式通过昇腾亲和的 OM 文件部署。推荐的单机器链路如下在 310P 宿主机导出 ONNX使用 Host CPU使用 ATC 将 ONNX 转为 OM在 310P 上使用 OM-backend sim-evaluator 在仿真环境评测在 310P 上。链路中的每一步都有对应脚本支撑见附录目录树convert_and_verify_onnx.py 负责 PyTorch → ONNX 导出与验证ATC 命令行负责 ONNX → OMverify_om_onnx.py 负责 ONNX(CPU) 与 OM(NPU) 的数值对比eval_dp_ascend.py 负责 OM 后端仿真评测。在转化 ONNX 的机器上还需要额外安装 onnx runtime 依赖pip install onnx # 基于 Host CPU 转换 onnx 请安装310P 宿主机执行 pip install onnxruntime # 基于 Host GPU 转换 onnx 请安装 pip install onnxruntime-gpu1) 导出 ONNX在 HostCPU 或 GPU上执行# 以本地目录为例dp_model/ 里包含 config.json 等文件 # 也可以先用 huggingface-cli 下载到 dp_model/: # pip install -U huggingface_hub # huggingface-cli download lerobot/diffusion_pusht --local-dir dp_model python3 convert_and_verify_onnx.py \ --pretrained-policy-path dp_model \ --output outputs/onnx/dp.onnx \ --device cpu \ --opset 14核心参数说明均可通过--help查看参数默认值说明--pretrained-policy-path必填本地模型目录或 HF Hub repo id需包含config.json与model.safetensors--outputdp/eval/dp_onnx/unet.onnxONNX 输出路径--devicecpuTorch 设备如cpu或cuda:0CUDA 不可用时自动回退 CPU--opset14ONNX opset 版本--seed42确定性 dummy 输入的随机种子--constant-folding开启是否启用 torch.onnx 常量折叠可用--no-constant-folding关闭--no-validate关闭跳过 ONNXRuntime 验证步骤--log-levelINFO日志级别DEBUG/INFO/WARNING/ERROR导出原理源码级从 convert_and_verify_onnx.py 的实现可以看到该脚本只导出 UNet 的 forward而非整个 DiffusionPolicy加载DiffusionPolicy.from_pretrained(policy_path)后通过_build_deterministic_observation构造与 config 严格一致的确定性观测state 填 0.5、图像填0.5/255.0再调用policy.diffusion._prepare_global_conditioning(observation)得到global_cond用_UNetOnnxWrapper包裹policy.diffusion.unet其 forward 签名固定为(sample, t, global_cond)sample初始化为全零、shape 为(1, horizon, action_dim)t固定为[99]int64 时间步torch.onnx.export时指定input_names[sample, t, global_cond]、output_names[model_output]采用ONNX_ATEN_FALLBACK算子导出策略与keep_initializers_as_inputsFalse。说明输入 schema包含多个摄像头 key 时也支持严格来自config.json.input_features默认会用 ONNXRuntime CPU 对比 PyTorch 输出打印 max/mean abs diff 与余弦相似度如需跳过可加--no-validate。样例输出如下INFO: ONNX export finished INFO: Validating ONNX output vs PyTorch (CPU ORT)... INFO: ONNX inference time (CPU): 0.033126 sec INFO: PyTorch output shape: (1, 16, 2) INFO: ONNX output shape: (1, 16, 2) INFO: Max abs diff: 1.22935e-07 INFO: Mean abs diff: 3.55503e-08 INFO: Cosine similarity (min/max/mean): 1.000000 / 1.000000 / 1.000000从输出可见PyTorch 与 ONNX 输出在 CPU 上的最大绝对误差约1.23e-07、平均绝对误差约3.56e-08、余弦相似度恒为 1.0说明导出后的 ONNX 与原始 PyTorch 模型数值行为高度一致。2) ATC 将 ONNX 转为 OM在 310P 上已安装并 source CANN 环境执行 ATC# 推荐直接用 atc路径按你的实际文件位置修改 atc --modeloutputs/onnx/dp.onnx \ --framework5 \ --outputoutputs/om/dp \ --soc_versionAscend310P1参数说明--model输入的 ONNX 模型文件路径--framework5输入模型框架类型5 表示 ONNX--output输出 OM 文件路径前缀转换完成后会在对应目录生成dp.om--soc_version芯片型号必须与实际芯片一致。soc_version需要根据npu-smi info得到的 Name Device 中芯片型号填写例如显示为 310P1则soc_version填写Ascend310P1。更多参数可参考 ATC 工具使用文档。当模型转换完成后当前目录应当存在一个名为dp.om的模型或者--output参数指定目录下终端输出中出现ATC run success, welcome to the next use即表示转换成功。提示根据 docs/deployment_troubleshooting.md 的通用排查经验ATC 编译失败最常见的原因是 CANN 环境未生效或--soc_version与实际芯片型号不一致更换模型 / 输入分辨率 / 动作维度后必须重新导出 ONNX 并重转 OM不要复用旧 OM。3) DP 在昇腾上的精度验证步骤转换完成后需要验证.om模型在 NPU 上的运行结果与原始模型是否一致。验证方式为构造 mock 数据对比 CPU/GPU 与原始 PyTorch 输出的相似度。# 在 310P 上执行需要 ACL/AclLite Python 依赖 python3 verify_om_onnx.py \ --onnx-model-path outputs/onnx/dp.onnx \ --om-model-path outputs/om/dp.om \ --seed 42 \ --n-action-steps 16该脚本会根据 config.json 生成确定性的 dummy 输入支持多摄像头输入并对比 ONNXRuntime(CPU) vs OM(NPU) 的输出。核心参数说明参数默认值说明--onnx-model-path必填ONNX 模型路径--om-model-path必填OM 模型路径--device-id0昇腾设备 ID--seed42dummy 输入随机种子--n-action-steps8sample输入的动作步数--action-dim2sample输入的动作维度--global-cond-dim132global_cond特征维度--timestep0输入t的时间步值验证原理源码级从 verify_om_onnx.py 可以看到make_dummy_inputs使用np.random.default_rng(seed)生成确定性输入sample为(1, n_action_steps, action_dim)的标准正态分布张量t为[timestep]int64global_cond为(1, global_cond_dim)的标准正态分布张量先通过run_onnxruntime_cpu在 CPU 上运行 ONNX随后通过AclLiteResourceAclLiteModel加载 OM 模型并按 ONNX 的输入顺序input_order把同一份输入喂给 OM 执行output_error_metrics对每个输出计算max_abs_error / mean_abs_error / max_rel_error / mean_rel_error以及cosinemin/max/mean共 7 项指标确保 OM 与 ONNX 输出在数值上保持一致。如果报Missing Ascend ACL dependencies (acl/acllite_utils/acllite_model)说明 ACLLite 路径未加入PYTHONPATH可参考 docs/deployment_troubleshooting.md 中的通用解法source /path/to/Ascend/ascend-toolkit/set_env.sh后将ascend-toolkit/latest/thirdpart/python/加入PYTHONPATH。4) 使用 OM-backend sim-evaluator 进行 PushT 任务仿真评测在 310P 上执行需要 ACL/ACLLite Python 依赖可用python3 eval_dp_ascend.py \ --policy.pathdp_model \ --om_model_pathoutputs/om/dp.om \ --env.typepusht \ --eval.batch_size1 \ --eval.n_episodes1 \ --env.episode_length600 \ --seed4412核心参数说明参数说明--policy.path预训练 DiffusionPolicy 目录含config.json同时用于查找归一化处理器--om_model_pathOM 模型路径支持绝对路径或相对路径脚本会优先按当前路径解析找不到时回退到policy_dir下查找--env.type仿真环境类型PushT 任务填写pusht--eval.batch_size并行评测环境数--eval.n_episodes评测回合数--env.episode_length单回合最大步数--seed随机种子--seed4412评测输出评测结果写入outputs/eval/.../eval_info.json日志会打印Aggregated eval metrics包含success_rate、avg_sum_reward、avg_max_reward、eval_time_sec等聚合指标同时在滚动过程中实时打印running_success_rate每回合的sum_reward、max_reward、success、seed会以per_episode列表形式写入eval_info.json便于逐回合分析。评测原理源码级从 eval_dp_ascend.py 的实现可以看到该评测器的核心设计——PyTorch 外壳 OM 内核环境与 rollout 循环完全复用 LeRobot 标准实现make_env、preprocess_observation、policy.select_action关键替换发生在policy.diffusion.unet OmUnetModule(om_model_path)用自定义的OmUnetModule替换 UNet 前向其forward(x, timestep, global_cond)内部把张量转为 numpy 后调用AclLiteModel.execute([x_np, t_np, gc_np])再把结果转回 PyTorch 张量送回扩散调度器完成去噪采样。由于 OM 通常按 batch1 编译当 batch 1 时会逐条推理后堆叠采样循环中t随去噪步数动态变化OmUnetModule的_mk_t_np支持 int、单元素 Tensor、数组等多种传入形式global_cond由 diffusion 的 conditioning 机制在每个推理步计算成功率的解析做了大量健壮性处理_extract_successes同时兼容info[is_success]/info[success]的 mask 形式、final_info的数组/列表/字典形式以及逐回合的 done 标记确保不同版本 gymnasium 环境下都能正确聚合success_rate。归一化处理器policy_preprocessor / policy_postprocessor的获取DP 在训练时通常对 observation / action 做了归一化normalization。为了让OM 输出的 action能正确落回环境动作空间并且OM 输入的 observation与训练时一致评测需要两份处理器产物policy_preprocessor.json 对应的*.safetensors负责推理前对 observation 做与训练一致的预处理/归一化policy_postprocessor.json 对应的*.safetensors负责把模型输出 action 做反归一化unnormalize再送入环境 step。获取方式有两种模型目录里已经自带部分模型仓库支持直接检查dp_model/是否包含上述两个 json 文件及其 safetensors。用迁移脚本生成如果你下载的模型只有model.safetensors config.json没有上述 processor 文件先在 Host 侧运行一次迁移脚本生成模型目录_migrated/python3 ../lerobot/src/lerobot/processor/migrate_policy_normalization.py \ --pretrained-path dp_model默认会生成如下内容dp_model_migrated/ ├── policy_preprocessor.json ├── policy_postprocessor.json ├── policy_preprocessor_step_*.safetensors ├── policy_postprocessor_step_*.safetensors └── ...查找顺序与容错逻辑源码级eval_dp_ascend.py会优先在--policy.path指向的目录查找 processors_find_policy_preprocessor_dir/_find_policy_postprocessor_dir如果没有会自动尝试同级的policy_dir_migrated/目录。也可以直接把--policy.path指向dp_model_migrated/前提是该目录包含config.json。需要特别注意的是DP 评测对处理器缺失是严格报错的_load_policy_processor_or_raise会直接抛出FileNotFoundError明确提示缺失的 json 文件及其两个候选位置而不是静默跳过——因为静默回退会导致 action 尺度错误、评测结果完全失真。如果 json 存在但加载失败最常见原因是引用的*.safetensors未随 json 一并拷贝或与安装的 lerobot 版本不兼容脚本同样会给出明确报错定位。常见问题排查结合仓库通用排查手册 docs/deployment_troubleshooting.md与本样例直接相关的共性问题归纳如下阶段问题现象根因与解决环境准备ATC 编译失败或找不到工具CANN 的set_env.sh未 source环境变量不会跨终端持久化每个新终端都要重新 source模型转换ATC 报算子/shape/dtype/soc_version错误OM 执行报acl.mdl.execute error 507011--soc_version与实际芯片型号不一致或复用了旧 OM用npu-smi info确认芯片型号后重转模型转换import acl/acllite_*模块找不到ACLLite 路径未加入PYTHONPATH将ascend-toolkit/latest/thirdpart/python/加入PYTHONPATH模型转换OM 推理报输入 shape 不匹配ONNX 与 OM 输出对不齐图像分辨率、chunk_size、动作维度与config.json不一致或 OM 输入顺序/dtype 与 ONNX 导出时不一致建议分段单独验证 ONNX vs OM 精度模型转换OM 能跑通但 action 无法落回环境动作空间归一化处理器preprocessor/postprocessor丢失按上文迁移脚本生成模型目录_migrated/运行评测无显示环境下 MuJoCo 渲染失败服务器缺少显示环境或 OpenGL 后端指定export MUJOCO_GLegl走 EGL 无头渲染OSMesa 缺失时安装对应运行库并设MUJOCO_GLosmesa附录相关代码目录结构以下为经过上述操作后DP 适配昇腾场景下infer_with_om目录中的实际文件结构lerobot/ # PyTorch 原始仓库拉取自 HuggingFace lerobot固定 commit └── diffusion-policy/infer_with_om ├── README.md # 本指南对应的原始 README ├── eval_dp_ascend.py # Ascend OM-backend sim-evaluator替换 UNet 为 OM 后仿真评测 ├── convert_and_verify_onnx.py # PyTorch - ONNX 转化脚本导出 UNet 并自动验证 ├── verify_om_onnx.py # ONNXRuntime(CPU) vs OM(NPU) 误差对比脚本 ├── dp_model # HuggingFace 或其他来源下载的模型目录 ├── dp_model_migrated # 迁移脚本生成的带归一化参数文件夹若 dp_model 自带参数可不用 └── outputs/ # 转换产生文件 ├── onnx/ # dp.onnx ├── om/ # dp.om └── eval/ # eval_info.json 等评测结果Citation如果本文档内容在你的工作或研究中被引用可以参考以下两篇原始论文inproceedings{chi2023diffusionpolicy, title{Diffusion Policy: Visuomotor Policy Learning via Action Diffusion}, author{Chi, Cheng and Feng, Siyuan and Du, Yilun and Xu, Zhenjia and Cousineau, Eric and Burchfiel, Benjamin and Song, Shuran}, booktitle{Proceedings of Robotics: Science and Systems (RSS)}, year{2023} } misc{cadene2024lerobot, author {Cadene, Remi and Alibert, Simon and Soare, Alexander and Gallouedec, Quentin and Zouitine, Adil and Palma, Steven and Kooijmans, Pepijn and Aractingi, Michel and Shukor, Mustafa and Aubakirova, Dana and Russi, Martino and Capuano, Francesco and Pascal, Caroline and Choghari, Jade and Moss, Jess and Wolf, Thomas}, title {LeRobot: State-of-the-art Machine Learning for Real-World Robotics in Pytorch}, howpublished \url{https://github.com/huggingface/lerobot}, year {2024} }【免费下载链接】cann-recipes-embodied-ai本项目针对具身智能业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-embodied-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考