CleanRL SAC 运行时基准解析MuJoCo v4 连续控制任务的 SPS 吞吐实测与复现指南【免费下载链接】cleanrlHigh-quality single file implementation of Deep Reinforcement Learning algorithms with research-friendly features (PPO, DQN, C51, DDPG, TD3, SAC, PPG)项目地址: https://gitcode.com/GitHub_Trending/cl/cleanrlCleanRL 仓库中的 sac_runtimes.md 以一张精简的运行时基准表记录了sac_continuous_action.py在 MuJoCo v4 六个连续控制环境上的训练吞吐SPSsteps per second。本文以该运行时数据为核心结合 benchmark/sac.sh、cleanrl_utils/benchmark.py 与 sac_continuous_action.py 源码说明这些数值从何而来、如何度量、如何复现以及与 docs/benchmark/sac.md 中学习性能episodic return表的对照关系。读者读完后将掌握 CleanRL SAC 基准的运行机制、SPS 指标的统计口径并能独立在本地或 Slurm 集群上复现同一组运行时数据。运行时基准表SPS 数据总览sac_runtimes.md记录的是一次带版本标签pr-424的基准实验的 SPS 测量结果实验对象为sac_continuous_action即 cleanrl/sac_continuous_action.py覆盖 6 个 MuJoCo Gymnasium v4 连续控制环境环境openrlbenchmark/cleanrl/sac_continuous_action ({tag: [pr-424]})HalfCheetah-v4174.778Walker2d-v4161.161Hopper-v4173.242InvertedPendulum-v4179.042Humanoid-v4177.31Pusher-v4172.123这组数值直接来自 wandb 上被标记为pr-424的sac_continuous_action实验集openrlbenchmark/cleanrl工作区。pr-424是 CleanRL 以自动打标签autotag机制为对应 Pull Request 生成的 wandb 标签用于把同一算法在不同代码版本下的表现区分开来这一点在 cleanrl_utils/benchmark.py 的autotag()函数中有明确实现它会依次尝试读取 git tag如v1.0.0b2-8-g6081d30、git commit 数并通过 GitHub API 尝试解析对应的 PR 号最终合并进WANDB_TAGS环境变量。从数值上看六个环境的 SPS 高度一致约 161179这与 SAC 在 MuJoCo 类环境上的训练特点相符观测与动作维度相近、单步交互开销相近且sac_continuous_action.py默认使用单环境num_envs1、每步固定进行 critic 更新、每policy_frequency步进行 actor 更新计算负载与环境类型关系不大。而Humanoid-v4177.31与Walker2d-v4161.161之间的差距则可以推断主要来自环境仿真器本身的单步计算差异而非算法开销差异——这属于由代码结构与数据一致性推断出的观察具体到每个环境仍需以实际 profiling 为准。SPS 指标的统计口径在深入复现之前先明确 SPS 在 CleanRL 中的定义。查看 sac_continuous_action.py 的训练循环if global_step % 100 0: ... print(SPS:, int(global_step / (time.time() - start_time))) writer.add_scalar( charts/SPS, int(global_step / (time.time() - start_time)), global_step, )其中start_time time.time()在环境 reset 之前记录sac_continuous_action.py。因此SPS 已推进的全局步数global_step÷ 从启动到当前时刻的总墙钟时间它是从进程启动起的累积平均吞吐不是瞬时帧率记录点每 100 步一次写入 TensorBoard 的charts/SPS标量若启用了--track再经 wandb 的sync_tensorboardTrue同步到云端sac_continuous_action.py。这也解释了运行时表中的数值为何是一个略低于单步理论吞吐的均值——它包含了启动、环境初始化、首次填充learning_starts默认 5000 步随机探索数据等阶段的耗时。charts/SPS是在 CleanRL 各单文件算法中统一记录的指标例如 ppo.py 的训练循环同样输出该标量且各算法的运行时基准文档如 ppo_runtimes.md、ppo_atari_runtimes.md都采用同一套 wandb 数据提取口径因此不同算法、不同环境之间的 SPS 可以横向比较。复现路径一本地多进程跑分运行时数据来源于与学习性能完全相同的基准流程。查看 benchmark/sac.sh这是仓库为 SAC 连续控制基准提供的官方入口脚本uv pip install .[mujoco] uv run python -m cleanrl_utils.benchmark \ --env-ids HalfCheetah-v4 Walker2d-v4 Hopper-v4 InvertedPendulum-v4 Humanoid-v4 Pusher-v4 \ --command uv run python cleanrl/sac_continuous_action.py --track \ --num-seeds 3 \ --workers 18 \ --slurm-gpus-per-task 1 \ --slurm-ntasks 1 \ --slurm-total-cpus 10 \ --slurm-template-path benchmark/cleanrl_1gpu.slurm_template脚本第一步安装带mujoco额外依赖的 CleanRL依赖清单见 requirements/requirements-mujoco.txt含 gymnasium、mujoco、torch、wandb 等。随后调用cleanrl_utils.benchmark模块执行调度。从 cleanrl_utils/benchmark.py 可以看到该工具实际会展开的命令矩阵for seed in range(0, args.num_seeds): for env_id in args.env_ids: commands [ .join([args.command, --env-id, env_id, --seed, str(args.start_seed int(seed))])]即--num-seeds 3会为每个环境生成 seed 1、2、3 三条命令最终展开为 6 环境 × 3 种子 18 条训练命令。每条命令形如uv run python cleanrl/sac_continuous_action.py --track --env-id HalfCheetah-v4 --seed 1--workers控制并行度benchmark.py在--workers 0且未指定 Slurm 模板时使用ThreadPoolExecutor以指定数量的子进程并发执行这些命令cleanrl_utils/benchmark.py。需要特别说明的是本仓库中benchmark/sac.sh的默认形态是面向 Slurm 集群的携带--slurm-*参数并指定了--slurm-template-path。如果要在单机本地复现运行时数据可将命令简化为uv pip install .[mujoco] uv run python -m cleanrl_utils.benchmark \ --env-ids HalfCheetah-v4 Walker2d-v4 Hopper-v4 InvertedPendulum-v4 Humanoid-v4 Pusher-v4 \ --command uv run python cleanrl/sac_continuous_action.py --track \ --num-seeds 3 \ --workers 4此时benchmark.py会以 4 个 worker 在本机并行跑完 18 个实验实验数据通过--track上传到 wandb并带上 autotag 生成的版本标签--auto-tag默认开启。每个训练 run 的charts/SPS曲线即可用于复算运行时表中的均值。若不需要云端跟踪可去掉--track此时 SPS 仍会打印在终端并写入本地 TensorBoard 的runs/{run_name}目录。关于并行度有一个来自官方文档的实践建议对于 envpool、procgen 这类高吞吐环境官方在 docs/get-started/benchmark-utility.md 中建议将--workers降为 1 以避免进程间争抢 CPU 拉低 SPS而 SAC 在 MuJoCo 上属于低吞吐环境多 worker 并行反而能最大化 GPU/CPU 利用率这也是sac.sh中--workers 18的用意。复现路径二Slurm 集群调度benchmark/sac.sh的--slurm-*参数将实验提交到集群执行。从 cleanrl_utils/benchmark.py 可以看到完整的模板渲染逻辑{{array}}被替换为0-17%18任务数组范围 并发上限{{env_ids}}、{{seeds}}被替换为环境与种子数组{{gpus_per_task}}、{{ntasks}}、{{cpus_per_gpu}}分别来自--slurm-gpus-per-task、--slurm-ntasks与根据--slurm-total-cpus计算出的每 GPU CPU 数渲染结果写入slurm/{uuid}.slurm文件随后以sbatch --parsable提交并打印 Job ID。模板本体是 benchmark/cleanrl_1gpu.slurm_template其中定义了单任务单 GPU 的资源配置--gpus-per-task、--mem-per-cpu12G等任务数组内通过$SLURM_ARRAY_TASK_ID / len_seeds与% len_seeds分别索引环境与种子env_ids{{env_ids}} seeds{{seeds}} env_id${env_ids[$SLURM_ARRAY_TASK_ID / {{len_seeds}}]} seed${seeds[$SLURM_ARRAY_TASK_ID % {{len_seeds}}]} ... srun {{command}} --env-id $env_id --seed $seed换言之运行时基准与学习性能基准共用同一套 Slurm 脚本与同一批 runSPS 数据就来自这些 run 上报到 wandb 的charts/SPS曲线——这也是为什么sac_runtimes.md与 docs/benchmark/sac.md 中的结果表共享同一pr-424标签与同一组环境列表。运行时背后的实现影响 SPS 的关键参数SPS 的绝对数值取决于 sac_continuous_action.py 中Args数据类定义的默认参数。理解它们有助于解读运行时数据、并根据硬件调整吞吐预期参数默认值对运行时的影响num_envs1单环境串行推进SPS 直接受单步仿真耗时限制learning_starts5000前 5000 步只做随机探索、不训练拉低早期累计平均 SPSbatch_size256每步 critic 更新从回放池采样的批量大小直接决定每步反向传播开销policy_frequency2每 2 步训练一次 actor并补偿执行 2 次更新影响 actor 更新开销占比target_network_frequency1每步对两个目标 Q 网络做 Polyak 软更新tau0.005autotuneTrue启用自适应熵系数每步额外执行一次log_alpha的梯度更新buffer_size1e6回放池容量不直接影响每步耗时gamma/tau0.99 / 0.005算法超参数与吞吐无关从训练循环sac_continuous_action.py可确认每个环境步的计算量一次 critic 更新两个 Q 网络各自前向 MSE 损失 反向传播、每 2 步一次 actor 更新含策略熵项、每步一次双目标网络软更新。在单 GPU--slurm-gpus-per-task 1条件下这些操作在 256 隐藏层宽度的 MLP两个 256 维全连接层上开销很小因此吞吐主要被 MuJoCo 仿真器单步耗时主导最终体现为六个环境 SPS 都落在 160180 区间。运行时与学习性能的对照SPS 只回答“训练多快”不回答“训练多好”。学习性能由 docs/benchmark/sac.md 的结果表给出两者使用同一基准配置同环境、同种子、同pr-424标签、各 3 个种子取均值环境sac_continuous_action1M 步训练回报HalfCheetah-v49634.89 ± 1423.73Walker2d-v43591.45 ± 911.33Hopper-v42310.46 ± 342.82InvertedPendulum-v4909.37 ± 55.66Humanoid-v44996.29 ± 686.40Pusher-v4-22.45 ± 0.51将两张表合读可以得到“性价比”视角例如InvertedPendulum-v4的 SPS 最高179.042意味着在同等训练预算下它最早收敛而Walker2d-v4SPS 最低161.161且回报方差较大±911.33说明该环境仿真与学习都相对困难。需要强调的是sac.md中引用的学习回报是训练过程回报training episodic return且Pusher-v4的-22.45 ± 0.51属于该任务本身训练回报的合理水平不应仅凭绝对值判断算法优劣。对于希望可视化 SPS 曲线的读者仓库提供了基于 openrlbenchmark 的绘图脚本 benchmark/sac_plot.sh它从 wandb 拉取pr-424标签下的charts/episodic_return数据并生成对比图支持--scan-history以扫描完整历史同样的--filters查询语法也可将metriccharts/episodic_return替换为metriccharts/SPS来绘制运行时曲线。适用前提与注意事项口径前提运行时表中的 SPS 是包含启动与随机探索阶段在内的累计均值且与具体 GPU/CPU 型号强相关换硬件后绝对数值会变化但六个环境之间的相对排序通常保持稳定文中分析属于基于仓库代码与数据的推断精确复现应以 benchmark/sac.sh 在当前硬件上实测为准。复现前提需要先按 requirements/requirements-mujoco.txt 安装 mujoco 依赖并使用仓库推荐的环境管理工具uv运行--track需要 wandb 账号与网络。标签语义pr-424是 autotag 机制自动生成的版本标识见 cleanrl_utils/benchmark.py跨版本比较时应始终携带该标签避免把不同代码版本的 run 混在一起比较。配套文档基准工具的全部命令行参数说明见 docs/get-started/benchmark-utility.mdSAC 连续控制算法的完整设计说明、指标含义与实现细节见 docs/benchmark/sac.md同类运行时基准可参考 docs/benchmark/ppo_runtimes.md 与 docs/benchmark/ppo_atari_runtimes.md 进行跨算法对照。小结sac_runtimes.md以一张表浓缩了 CleanRL SAC 在 MuJoCo v4 基准上的运行时画像六个环境 SPS 介于 161179 之间体现了连续控制单环境训练“仿真主导、算法开销小”的典型特征。这张表的背后是 benchmark/sac.sh cleanrl_utils/benchmark.py 的自动化基准流水线、charts/SPS的统一定义、以及pr-424自动版本标签的可追溯机制。结合 docs/benchmark/sac.md 的学习回报表读者即可对 CleanRL SAC 形成“多快 多好”的完整评估并在本地或 Slurm 集群上复现整组数据。【免费下载链接】cleanrlHigh-quality single file implementation of Deep Reinforcement Learning algorithms with research-friendly features (PPO, DQN, C51, DDPG, TD3, SAC, PPG)项目地址: https://gitcode.com/GitHub_Trending/cl/cleanrl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考