墙钟时间：env steps 不是唯一成本

1. 1e8 steps 在慢 sim 上要几周

PPO 论文 benchmark 常报 1e8 env steps；HalfCheetah 单 env 约 2000 fps，1e8 steps 要 14 小时——尚可。换成复杂 manipulation sim 单 env 200 fps，同样 steps 要 6 天。SAC 1e6 steps off-policy 可能更快到可用 policy。Sample efficiency ≠ wall-clock，论文脚注 hardware 和 n_envs 不是礼貌，是必要条件——读者拿 laptop 复现 1e8 step 实验，和作者用 32 env 集群不是同一回事。

产线排期问「多久能出 policy」，不是「多少 steps 收敛」。真机 10 Hz 控制下 1e6 real steps 约 28 小时不间断——通常不可行，pipeline 必须接受 sim pretrain + 少量 real fine-tune。Research milestone 用 sample；product milestone 用 wall-clock 和 human oversight cost——两套指标都要，但排期只听后者。向管理层汇报「还需五百万 steps」而不换算成天数，等于把 sample complexity 的账算在业务头上。

2. 瓶颈定位

Profile 指标：steps_per_second = total_steps / elapsed_time。SB3 verbose=1 打印 fps。Log 每 10k step 的 elapsed time，forecast ETA——没有 ETA 的 sprint 承诺是猜拳。若 fps 在 10k step 后下降，可能是 memory leak 或 env 未 reset 干净，要查而非盲目加 env 数。

HalfCheetah 类 locomotion 任务 env 是瓶颈；Atari 类 GPU env 是常态；manipulation 带渲染时常 200 fps 以下——同一算法、同一 steps，wall-clock 可差 10×，对比实验必须 lock hardware 和 n_envs。

Cloud 并行 32 env 时注意 CPU 核数和 MuJoCo license；GPU 空转时加 env 数比加 network width 更有效。Team 共享 fps benchmark 机器型号；换 laptop 跑 baseline 前先对照 reference fps。过大 batch 等 GPU、env 饿死——profile 先确认瓶颈在哪，再花钱。

3. 算法选型 implication

Research benchmark：PPO 简单可复现，sample 多但 wall-clock 可并行 env 补。论文对比时注明 steps 和 wall-clock 双轴，避免读者按 steps 估算自己的训练时间。
Real 机器人：prefer SAC sample efficiency + sim pretrain；real 1e4 step fine-tune 而非 1e7——overnight 1e4 steps 可能够 fine-tune，1e7 不现实。真机 pipeline 的 wall-clock dominated by human safety check，不是 GPU 算力。
Atari：GPU env + big replay，wall-clock 和 sample 都重要。

对比算法时，同 wall-clock 比 eval return，而非同 steps——PPO 5e6 steps @ 15000 fps 和 SAC 1e6 steps @ 3000 fps wall-clock 相近，谁 eval return 高才是公平对比。Buy GPU 之前先 profile env：HalfCheetah 2000 fps 时 GPU 不是瓶颈，加 core 比加 A100 划算。

4. Cost sheet 与排期

Cost sheet：cloud $/1Menvsteps\times budgetsteps；和humandemo$/条对比，选 cheapest path to 80% success。Sprint planning 用 wall-clock estimate：fps × 可用 GPU hours = 可完成 steps，再选算法 target steps。

Pipeline 设计：sim 训到 80% 性能 → sim2real → real 1e4 step fine-tune。Wall-clock 决定能不能 iterative research——1e6 real steps 在 10 Hz 下约 28 小时，通常不可接受，offline RL、sim pretrain、BC warm start 不是可选项，是硬约束。Internal milestone 表格同时列 sample 与 wall-clock，避免只报 steps 误导排期。

5. 真机 sample budget

Real robot overnight 1e4 steps 可能够 fine-tune，1e7 不现实——pipeline 设计要接受。Cloud burst 并行 64 env 注意 MuJoCo license 和 CPU RAM。Human oversight cost 也要算：真机每 step 可能需要人盯着，wall-clock 和 human-hours 双重约束。

6. 失败模式

32 env 并行但 CPU 打满，反而慢。论文比 sample complexity 时不脚注 wall-clock，读者误以为 1e8 step 人人都训得起。只报 steps 的 milestone 会系统性低估交付时间。

7. 验收

• Log fps vs n_envs 曲线找 sweet spot（通常 8~16 env 性价比最高）。
• 对比 PPO vs SAC 同 wall-clock 的 eval return，非同 steps。
• 真机 pipeline：sim 80% 性能 → sim2real → real 1e4 fine-tune。
• Buy GPU 前先 profile env，确认瓶颈在 network 而非 env。
• Internal milestone 同时列 sample 与 wall-clock。
• Cost sheet 对比 cloud steps 与 human demo 成本。

8. 案例：买 A100 后 fps 不变

某团队为加速 RL 训练买了 A100，HalfCheetah 单 env 2000 fps 下 GPU 利用率始终 0%——瓶颈在 env step，不在 network。加 SubprocVecEnv 到 16 env 后 fps 从 2000 升到 18000，A100 才开始有利用率。教训：Buy GPU 之前先 profile env；HalfCheetah 类任务加 core 比加 A100 划算。

9. 与 sim 选型的关系

MuJoCo 单 env 2000 fps，PyBullet 同任务可能 800 fps，Isaac Gym GPU 并行可达 50000+ fps——换 sim 等于换 wall-clock 预算。选型时不只看物理保真度，还要看 fps × 可用并行度。Manipulation 任务若 Isaac 支持且 fps 高一个数量级，同样 1e7 steps 的 wall-clock 差几天。

Sim 预训练到可用 policy 的 wall-clock，加上 sim2real 适配时间，加上真机 fine-tune 的 human oversight，才是完整交付 estimate。只算 sim training steps 会低估总工期一半以上。

10. 团队共享 benchmark

Team 维护一台 reference 机器，定期跑标准 env（HalfCheetah 8 env）记录 fps，新成员 laptop 跑 baseline 前先对照。Cloud 实例型号变化（vCPU 数、内存带宽）也会改 fps——同一脚本在不同 cloud SKU 上 fps 差 30% 不罕见，排期要留 buffer。向业务汇报 deadline 时用 wall-clock estimate 加 20% buffer，而非 raw steps 换算。Sprint 结束时对照 forecast ETA 与实际 elapsed，校准 fps 估计——第二次排期会比第一次准得多。

Wall-clock 决定能不能 iterative research。Sample complexity 是论文语言，fps 和 sample budget 是产线语言——只报 steps 的 milestone 会系统性低估交付时间。