6.2 KiB
本机执行清单（给本地 AI 逐条执行）
本文件是 Hark 对本机计算的唯一要求清单。按顺序执行，每一步把「回传」里的文件或输出原样交给用户，不要跳步，不要自行改代码。 所有命令在仓库根目录（G:\Robot_v2\机器人手臂）的 Git Bash 里运行。完成的条目由 Hark 在下一次提交里删掉。
当前状态（2026-10-19 02:00）：第二次预训练开环已正常（候选多样性 0.65、8 候选最好 2.9 mm），闭环仍 0% 到达 / 100% 碰撞； DAgger 阶段曾把显存吃到约 30 GB，原因是 kin.gaps 一次几千个点、cap=40 mm，已修复（kin.gaps 自动分块），尚未实测。
第 0 步：同步代码
git fetch gitea && git reset --hard gitea/main
git log --oneline -1 # 应为「fix: 闭环失败定位与显存修复……」或更新
- 训练控制台若开着，先点「停止」，确认没有 python 训练进程在跑。
- 不要启动 DAgger / M5，等 Hark 看完第 1、2 步的结果再定。
第 1 步：gaps 显存峰值（不到 1 分钟）
PYTHONUTF8=1 python - <<'EOF'
import torch
from ml.common.kin_torch import Kin
kin = Kin(device='cuda')
for n, cap in [(512, 40.0), (4096, 4.0), (4096, 40.0)]:
q = kin.lo + (kin.hi - kin.lo) * torch.rand(n, 6, device='cuda')
torch.cuda.empty_cache(); torch.cuda.reset_peak_memory_stats()
with torch.no_grad(): kin.gaps(q, cap)
print(f'n={n:5d} cap={cap:4.0f} peak {torch.cuda.max_memory_allocated() / 2**30:6.2f} GiB', flush=True)
EOF
- 通过：三行峰值都 ≤ 2 GiB。
- 任务管理器里专用显存接近 24 GB 或共享显存开始上涨：立刻 Ctrl+C，回传已打印的行，不要继续第 2 步。
- 回传：终端输出的 3 行。
第 2 步：闭环失败定位（约 2–4 分钟）
PYTHONUTF8=1 python -m ml.eval.diag_cl --ckpt ml/runs/base/last.pt --n 256 --out ml/runs/diag_cl.json
- 运行期间看一眼任务管理器，专用显存应远低于 24 GB；超过 22 GB 就 Ctrl+C 并回传终端输出。
- 回传：
ml/runs/diag_cl.json、ml/runs/replay_teacher.json、ml/runs/base/log.jsonl。
回传汇总
| 步骤 | 回传内容 |
|---|---|
| 1 | 终端 3 行峰值 |
| 2 | ml/runs/diag_cl.json、ml/runs/replay_teacher.json、ml/runs/base/log.jsonl |
| 任一步出错 | 终端最后 30 行输出 |
执行回传（2026-10-19 02:35，本地 AI）
第 0 步：同步代码
分叉：本地 5a87c06（含 ml/eval/diag_collision.py 等本地提交，晚 02:00 前）与 gitea/main 573082d（03:24 强推）各有 1 个提交；本地未提交改动 ml/monitor.html（开环指标两张图）、ml/pstate.py（train 归档加 review_*）。
已 git merge 573082d 合流（工作区内容与 573082d + 未提交改动一致），未执行清单里的 git reset --hard，无训练进程在跑。
注：本地现比 gitea/main 领先 2 个提交（合并提交 + 上述未提交改动尚未提交），未 push。
第 1 步：gaps 显存峰值（实测）
n= 512 cap= 40 peak 1.20 GiB pairs=10724086
n= 4096 cap= 4 peak 9.30 GiB pairs=14880476
n= 4096 cap= 40 peak 9.30 GiB pairs=87180763
未通过（两条 4096 都是 9.30 GiB，>2 GiB）。三行是独立新进程各跑一次的结果（排除分配器缓存假象），9.30 GiB 是可复现的确定值。
定位（在 gaps() 内插探针，不改行为）：
- 峰值全部出在粗筛段（
cc/d2/per，一次材料到 491 组 × 67256 粗对）：4096 点第一次d2 = (cc[:,cp_a]-cc[:,cp_b]).pow(2)的广播中间量就 ~9.3 GiB。[coarse]探针打到 9.30 GiB 后，后续[bounds]/[pre-loop]/[post-loop]/[cat-done]都不再涨。 - 新加的分块（PAIR_BUDGET=2e6）只对精算段生效：本模型几何比注释里假想的大得多——1936 条胶囊 / 491 组 / 67256 粗对 / 104.7 万细对，4096 点粗筛幸存 2.41 亿对（cap=4 就已超预算 120 倍），分块确实在切（cap=4 切 121 块、cap=40 切 283 块，每块 10–45 点），每块精算峰值 ≤1.0 GiB。合计峰值还是被粗筛一条打回 9.3 GiB。
- 512 点 cap=40 的 1.20 GiB 同样出自粗筛（512×67256 → 广播中间量 ~1.2 GiB），精算段只占其中一小截。
- 旧版对比（
0b47905，无任何分块）：同一三条独立实测 4.59 / 16.98 / 36.89 GiB——旧版 4096×40 的 36.9 GiB 在 24 GB 卡上必 OOM，与"dagger 吃满 24 GB、估计 30 GB"记录吻合。本版把 4096×40 从 36.9 降到 9.30 GiB（约 4.0×），但 4096 两条仍在 9.30，>2 GiB 门槛。
建议修复（未改代码，等你定）：粗筛也按 PAIR_BUDGET 同类逻辑分块（复用同一套 bounds），或把粗筛改成按粗对列分块累加 per；粗筛分摊到 ~200 万对/块后，预计三条都能回到 ≤2 GiB。
第 2 步：闭环失败定位（ml/runs/diag_cl.json，完整内容见该文件）
关键数字：
- A（特征口径）：全组通过。 最大差全部在 fp32 数值噪声量级（最大 3.6e-6，gaps 组；其余 ≤4.8e-7）。Python 现算特征与数据集 X 口径一致，排除"闭环看到没见过的输入"这条路。
- B（噪声下动作差）：无害。 同一噪声两份特征的动作差 mean 5.1e-6°、p90 8.8e-6°，参照动作幅度 14.7°。
- C（失败形态，n=256）：
- 关安全层：到达 0%，碰撞 99.6%；首次碰撞 p10/p50/p90 = 0.4/1.46/3.52 s，仅 0.4% 在 0.1 s 内（不是"起步就撞"）。
- 碰撞组对：2-4 共 90 次（J3-J5），其次 0-4（J1-J5）42、0-3（J1-J4）33、0-5 21、0-2 19、1-6 18。
- 全程最小目标误差 p10/p50/p90 = 93/254/432 mm——连 5° 都没保持，不是"接近到不了"，是根本走不到。
- 开安全层：到达 0.4%，碰撞 5.5%，刹车中位数 5 次——安全层把碰撞从 99.6% 压到 5.5%，但任务仍然到不了。
其余两个回传文件
ml/runs/replay_teacher.json（00:41 开训前自检的产物，非本次新跑）：n=512，到达 1.0、碰撞 0.0、min_gap p10 0.5 mm、pass=true。ml/runs/base/log.jsonl：末行 eval（step 14000）success 0.0、collision_rate 1.0、collision_steps_mean 268、ol_fk_mm 5.98、ol_best_mm 2.92、ol_div 0.655。与 C 段一致。