性能：先分清延迟与吞吐#

单个机器人能否按时完成一步，与一批环境每秒能生成多少样本，是两种性能问题。 前者关心一次更新的耗时与抖动，后者关心大量工作总共完成得多快。

从一帧拆开成本#

将一次系统更新分成物理、控制、观测生成、渲染、数据搬运和通信。先确认测量覆盖哪个范围，再讨论“加速”。

假设一个教学例子中物理耗时 1 ms、渲染 7 ms。即使把物理耗时减半，串行总耗时也只是从 8 ms 变为 7.5 ms。现实中若存在并行和异步队列，还要追踪关键路径，不能简单累加各段耗时。

仿真时间、墙钟时间与实时率

实时率可以写成“推进的仿真时间 / 消耗的墙钟时间”。推进 1 s 仿真用 0.5 s 墙钟，平均实时率就是 2。它没有告诉你最慢一步花了多久，也不保证每个控制截止时间都满足。

对闭环系统，除了平均值，还应看耗时分布、超时次数与队列积压；对训练采样，还要明确是否计入重置、观测、设备传输和学习器等待。这里给的是测量思路，不是 MATRiX 的性能数据。

单实例闭环： 先量实际物理步与控制链的端到端延迟。批量 API 不会自动消除通信等待或渲染阻塞。
CPU 多实例采样： 学习模型共享、每线程工作区和状态隔离，再看 mujoco.batch。它在 3.17.0 引入，不能用旧 rollout 接口的契约直接替代。
GPU 批量： 再看 MJX / MuJoCo Warp 的模型支持、精度、编译和搬运成本。后端选择必须结合任务与实际输出，不能只比较包名。

先固定模型、物理时长、控制周期、输入与输出要求；然后只改变一个明确因素。若关闭渲染后速度提升，要说明测量的是无渲染路径；若同时改变步长与控制频率，则不能把差异全部归给求解器。

保留完整任务结果与关键物理量。更快但丢失接触、漏记观测或改变控制语义，不是同一个工作负载下的收益。

一次只推进一个小模型，逐步在 CPU 和 GPU 之间拷贝状态。GPU 一定更快吗？

不能由硬件名称判断。启动、同步和数据搬运可能占据主要成本；批量规模与计算密度也会改变结论。需要测完整路径，并保持模型、控制和输出可比较。

先查一个实际场景的物理步、控制更新与渲染是否在同一阻塞路径上，再决定优化对象。把“物理计算慢”“等待数据”“显示慢”分开，下一次修改才有明确目标。