perf(profiling): motion tracking update_state/reset_done 逐 term profiling（#1292 杠杆 1）

[TATP-233]

Parent: #1292（"更优先的杠杆"第 1 条）

⚠️ 临时需求（TODO: #1292 完成后删除）
本 issue 引入的 per-term profiling 埋点是临时代码：profiling 本身有计时开销、会影响被测路径效率，不作为永久功能维护。TODO：#1292 的优化开发（#1294/#1295/#1296）全部完成后，删除这些埋点。 实现时请把埋点集中、标记清楚（如统一 PROFILING_TEMP 注释），保证届时可低成本移除。

背景

#1292 的三后端同机 benchmark 已确认：sac/g1_motion_tracking 在 mjwarp 把物理压到 ~18 ms 后，瓶颈落在 manager 数值层（update_state + reset_done 占 env step 约 69–79%，跨 Xeon/Ryzen 两台机器复现）。但目前只有阶段级计时，不知道 update_state 的 29–83 ms 具体花在哪几个 term。

目标

用现有 instrumentation + 最小新增埋点，产出 motion tracking task 的逐 term profiling 报告，回答：

1. update_state 中 observation / reward / metrics / curriculum 各 manager 及其内部每个 term 的耗时分布。
2. reset_done 中 event terms 采样、row-scoped obs 重建各 term 的耗时分布（现有 RESET_DONE_DETAIL_TIMING_KEYS，见 src/unilab/base/np_env.py:25-66，只到阶段级，不含 per-term）。

范围

• 优先复用现有埋点；manager 层 per-term timing 如缺失（当前 src/unilab/managers/ 无 per-term 计时），以 opt-in、默认关闭 的方式补充，不改动任何数值路径。
• 埋点为临时代码（见顶部 TODO）：接受 profiling 开启时的性能损耗，但关闭路径应尽量零开销，且代码上易于整体拆除。
• 只针对 sac/g1_motion_tracking（mujoco / motrix / mjwarp 三后端同机各出一份）。
• 产出：profiling 数据 + 热点 term 排序结论，作为 perf(managers): per-term 防御性 isfinite 扫描降级为采样/可配置（#1292 杠杆 2） #1294/perf(managers): 纯 NumPy 临时数组消除（out=/in-place）（#1292 杠杆 4） #1296 的 term 级依据。本 issue 只测不改，任何优化另行开 issue。

验收

• 三后端同机对照报告（复用 scripts/benchmark/rl/benchmark_offpolicy_collector_active.py 必测项口径），明确列出 update_state / reset_done 的 top-N 热点 term 及占比。
• 新增埋点默认关闭，开启/关闭两种状态下 benchmark 无统计显著差异（关闭时零开销可验证）。
• 埋点代码有统一标记，评估：Manager-based API 下用 Numba 加速 collector 后处理与 reset 的可行性（基于 #932 复盘） #1292 关闭前提交清理 PR 删除。

[TATP-233]

逐 term profiling 报告（同机：Ryzen 9 9950X3D 16C + RTX 4090，8192 envs，warmup 10 / measure 100 steps）

实现说明（临时代码，TODO: #1292 完成后删除）

• 新增 src/unilab/utils/term_profiling.py（UNILAB_TERM_PROFILING=1 开启，默认关闭）；挂点覆盖 ObservationManager.compute_group（term func / per-term 后处理 copy+noise+clip+scale+nan / group 级 concat 三段，区分 |step 与 |reset 相位）、RewardManager.compute、MetricsManager._compute_term、TerminationManager.compute、EventManager.apply（全 mode）、CurriculumManager.compute。全部挂点带 PROFILING_TEMP (#1293, TODO: remove after #1292) 标记，grep -r PROFILING_TEMP 即可整体拆除。
• 关闭时每个挂点仅一次属性判断、零分配（共享 nullcontext）；ManagerBasedRlEnv._load_managers 处按 case 重置统计（多 case 单进程互不污染）。
• 测试：tests/utils/test_term_profiling.py（3 项，含关闭时 no-op、记录/dump/reset 行为）；tests/managers 56 项全过，ruff 全过。
• 结果 JSON：scripts/benchmark/outputs/offpolicy_collector_active/results_sac_g1_motion_tracking_profiling_{on,off}_ryzen9950x3d.json（gitignore 内）。

埋点开销验证（ON vs OFF，同代码路径）

Backend	env/s ON → OFF	env step ms ON → OFF	update_state ON → OFF	reset_done ON → OFF
mujoco	71,126 → 71,274	113.2 → 112.9	28.45 → 28.58	9.58 → 9.65
motrix	58,411 → 58,974	138.3 → 136.9	49.43 → 49.10	18.77 → 17.44
mjwarp	122,563 → 129,210	64.9 → 61.4	28.39 → 28.53	14.36 → 14.07

mujoco/motrix 差异 ≤1%；mjwarp 吞吐差 ~5%，与本机无代码改动时的 run 间波动同量级（同一份二进制两次基线跑出过 124,417 与 129,210）。结论：关闭时开销不可测，满足验收；开启时每 step 约 180 个挂点 × 2 次 perf_counter，本身开销 ~µs 级，不扭曲热点排序。

分类聚合（mean_ms ≈ ms/vector-step）

类别	mujoco	motrix	mjwarp
reward/step	6.17	6.23	5.68
termination/step	4.48	10.44	4.99
obs/step（term getter 本体）	0.99	5.81	0.93
obs_post/step（copy/noise/clip/scale/nan）	2.13	3.75	2.00
obs_group_post/step（concat 等）	1.28	1.23	1.14
obs/reset	0.81	6.36	0.87
obs_post/reset	1.61	2.20	1.56
已归属合计	17.5	36.1	17.2

覆盖率：step 相位已归属 15.0 / 27.4 / 14.7 ms，分别占 update_state（28.4 / 49.4 / 28.4 ms）的 53% / 55% / 52%（其余为 manager 编排、_map_observations 等循环外开销）；reset 相位已归属 2.5 / 8.6 / 2.5 ms，占 reset_done（9.6 / 18.8 / 14.4 ms）的 26% / 46% / 17%——reset 大头仍在 backend set_state 边界与 reset 编排（本 task 配置下无 event/metrics/curriculum term 参与，dump 中无任何此类行）。

update_state top 热点 term（ms/vector-step）

term	mujoco	motrix	mjwarp
termination/anchor_pos	3.94	9.89	4.55
reward/motion_body_pos	1.28	1.24	1.17
reward/motion_body_ang_vel	1.26	1.25	1.18
reward/motion_body_lin_vel	1.25	1.24	1.17
reward/motion_body_ori	1.11	1.13	1.07
reward/joint_limit	0.54	0.64	0.46
termination/anchor_ori	0.39	0.40	0.35
reward/motion_global_root_ori	0.22	0.22	0.20
reward/action_rate_l2	0.21	0.20	0.17
reward/motion_global_root_pos	0.19	0.19	0.17

reset 相位 top：obs_post/actor/joint_pos|reset（0.68 / 1.09 / 0.66）、obs_post/actor/joint_vel|reset（0.67 / 0.72 / 0.65）、motrix 特有 obs/{actor,critic}/joint_pos|reset（1.76 / 1.86）、obs/{actor,critic}/joint_vel|reset（0.91 / 0.87）。

结论（对 #1294/#1295/#1296 的指向）

1. 单一最大热点是 termination/anchor_pos（3.9–9.9 ms/step，占 update_state 14–20%），加 reward/motion_body_* 四项（合计 ~4.7–5.0 ms，16–18%）——这 5 个 task-owned motion terms（src/unilab/tasks/motion_tracking/common/manager_terms.py）合计约占 update_state 的 1/3，是 perf(managers): 纯 NumPy 临时数组消除（out=/in-place）（#1292 杠杆 4） #1296 的首选对象（motion reference 逐 env 索引/插值是纯数组数值，且逐 step 重复计算）。
2. manager 框架层开销被量化：mujoco/mjwarp 上 obs_post + obs_group_post 合计 3.4 / 3.1 ms/step；对便宜 term（如 joint_pos），post 开销（copy/clip/scale/nan 扫描）约为 term 本体的 2.5 倍（0.73 vs 0.29 ms）——这是 perf(managers): per-term 防御性 isfinite 扫描降级为采样/可配置（#1292 杠杆 2） #1294（isfinite 降级）与 perf(managers): 纯 NumPy 临时数组消除（out=/in-place）（#1292 杠杆 4） #1296（copy/临时数组消除）的直接依据，两者上限合计约 3 ms/step（mjwarp 上 ~10% update_state）。
3. motrix 的 update_state 高出 mujoco/mjwarp 的 ~20 ms 主要是 getter 边界而非 manager 数学：obs/step + obs/reset 合计 12.2 ms（mujoco 仅 1.8 ms），单 joint_pos getter 近 2 ms/step。这指向 perf(reset): reset 路径 backend 边界 row-scoped 化与 set_state 计时补齐（#1292 杠杆 3） #1295 / perf: Motrix reset 热路径 Rust/motrixsim 边界优化（#679 延伸） #682 的 backend 边界方向，NumPy 层优化碰不到。
4. reset_done 的 manager 可归属部分仅 17–46%，大头仍在 backend set_state 与 reset 编排（与 评估：Manager-based API 下用 Numba 加速 collector 后处理与 reset 的可行性（基于 #932 复盘） #1292 原判断一致），perf(reset): reset 路径 backend 边界 row-scoped 化与 set_state 计时补齐（#1292 杠杆 3） #1295 的 row-scoped 化空间主要在 reset 相位 obs_post（1.6–2.2 ms/step，含全 batch copy 后切片）。
5. 没有任何 term 热点达到"纯数组数值热点且占 e2e 显著比例"的 Numba 重启门槛：最大的 anchor_pos 在 mjwarp 上占 env step 的 7.4%，且其与 motion 数据索引耦合，优化首选是算法/数组层（perf(managers): 纯 NumPy 临时数组消除（out=/in-place）（#1292 杠杆 4） #1296），与 评估：Manager-based API 下用 Numba 加速 collector 后处理与 reset 的可行性（基于 #932 复盘） #1292 总结论一致。

[TATP-233]

PR #1297 已合入 dev/issue-1292-motion-tracking-manager-perf（profiling 报告见上方评论）。注意：埋点删除 TODO 不在本 issue 关闭范围内——按约定在 #1292 收尾时以单独清理 PR 执行（grep PROFILING_TEMP 可定位全部挂点）。