V4.12 训练全程记录

Transformer 闭环泊车 · 169 机器 (RTX 5880-Ada-48Q) · 本页实时更新训练状态与完整复盘

目标:全面超越 V4.6 基线(0.28m / 99%)

当前闭环 pos_err
epoch 进度
零碰撞率
历史最优

实时状态 等待数据

训练状态
train loss
teacher forcing
预估剩余
最后更新
等待训练日志…

数据源:169 机器 journal_v412.json,每 15 分钟由巡检同步到本站。

训练机器信息(169)

项目配置
主机无影云 p-0d01zbt5suva74z3e(内部代号 169) · ssh root@8.149.76.169 -p 53198
GPUNVIDIA RTX 5880-Ada-48Q · 48GB 显存(vGPU)
驱动 / CUDA570.172.18 / CUDA 12.8
CPU / 内存 / 磁盘32 核 / 62GB / 98GB(余 78GB)
软件栈Ubuntu AL8 · Python 3.10 · PyTorch + numpy + casadi(阿里云镜像安装)
角色分工169 = 训练 + DAgger 求解;本机(49.232) = warehouse 数据生产/入库;新加坡(47.84) = 本展示站

训练数据

项目详情
warehouse 原始数据53,992 条 A 级样本(100% 全量质检通过:RK4 一致性 + OBB 零碰撞 + 终点达标)
13 类难度场景dense 7,772 · standard_wide 7,188 · narrow_corridor 6,783 · rotated_cars 6,313 · asymmetric 4,996 · path_interference 4,556 · offset_corridor 4,332 · open_lot 3,459 · s_corridor 2,591 · start_interference 1,935 · extreme_rotation 1,795 · half_blocked 1,607 · pillar_field 665
SE(2) 增强每条 ×3(θ₁θ₂ 同旋转 +Δθ / .copy() 防 view 覆写 / 增强后重算 metrics / OBB 碰撞检测),稀缺场景 ×4 → 目标 ~162K
增强质检门槛collisions=0 且 rk4_max_err<0.01m 且 pos_err<0.05m,不过即弃
DAggerOnline 专家纠错数据,每 epoch 配比 20%,训练中每 10 epoch 热加载
管线实况运行中,完成后更新…

训练配置(相对 V4.11 的全部改动)

Input (B,10,51) → Linear(51→256)+PosEnc → 6×TransformerEncoder(256/8/1024,PreLN) → last frame → MLP(256→64→2) → tanh → (δ±0.40rad, v±2.0m/s) # 架构不变 4.77M SS: ep15 起 → ep60 到 floor 0.5 # V4.11: ep10→80 floor0.3 崩了 DAgger: 20% batch 混合, 10ep 热加载 Noise: 0.05m + 1° ramp ep0-30 (与SS错峰) LR 5e-4 AdamW+cosine · batch 8192 · BF16 AMP · torch.compile 熔断: 连续3次VAL恶化 或 VAL>2×best → 立即停, 保存现场, 禁止自动重启
参数V4.11(崩溃)V4.12
SS start/end10 / 8015 / 60
SS floor0.30.5
DAgger 配比~10%(且与 SS 绑定)20%(与 SS 解绑)
状态噪声0.15m/0.03rad0.05m + 1°(错峰爬坡)
VAL 频率每 5 epoch每 epoch(熔断输入)
熔断机制无(外部乱干预)制度化熔断 + 只读巡检
LR1e-3→5e-45e-4

详细操作步骤记录

01 · 机器验收
ssh 登录 169,确认 GPU(RTX5880-Ada-48Q 48G / 驱动 570.172.18 / CUDA 12.8)、32 核 CPU、62G 内存、磁盘余 78G。干净系统:Python 3.10,无 torch/casadi,需自装。
2026-08-22 20:5x
02 · 环境安装
pip3 install -i https://mirrors.aliyun.com/pypi/simple/ torch numpy casadi(注意:该机 pip 不支持 --break-system-packages 参数)。
2026-08-22 21:1x
03 · 数据上传
本机 warehouse(53,992 条 .npz + index/stats,tar 213MB 压缩后 4.7MB)→ scp 至 169 /root/warehouse/samples/;训练脚本上传至 /root/v412_work/;DAgger 求解器 generate_data_v3_5.py/root/parking_datagen/
2026-08-22 21:16
04 · 增强管线 build_v412_data.py
24 进程并行:读 warehouse → 逐条 SE(2) 刚体变换(θ₁θ₂ 同时 +Δθ、全部 .copy() 防覆写、U 机体坐标不变)→ 重算 metrics → 100% 全检(OBB 碰撞=0 / RK4 重积分误差<0.01m / 终点 pos<0.05m)→ 不过即弃。稀缺场景(pillar_field/extreme_rotation/half_blocked/start_interference)×4,普通 ×3。⚠️ 开发中抓到一处险情:初版 RK4 公式误写 th2dot=v/L1·sinβ,对照 transformer_model.py 修正为 v/L2·sinβ(L2=8.0)——这就是"先文档后编码+全检"的意义。
2026-08-22 21:2x
05 · 启动训练 train_v412.py
命令:python3 train_v412.py --data-dir /root/training_data_v412 --dagger-dir /root/dagger_v412 --epochs 100 --batch-size 8192 --lr 5e-4。nohup 后台运行,日志 training_v412.log,journal_v412.json 供本页实时展示。验证集:seed=42 固定切分,500 条闭环 rollout 每 epoch 评估。
待执行
06 · Online DAgger 生成
首个 best checkpoint 出现后,后台运行 generate_dagger_v410.py collect + solve:模型闭环 rollout 收集飘移态(drift>1m)→ casadi 同伦求解器解最优纠正 → (window, expert_control) 落盘 /root/dagger_v412/。训练进程每 10 epoch 自动热加载。
待执行
07 · LLM 智能巡检(只读)
cron 每 15 分钟:拉取 169 的 journal → 同步到本页 → 异常才通知用户(熔断触发/NaN/进程消失/VAL 雪崩)。巡检无任何写权限,不碰训练进程。
待执行

🚨 数据危机:warehouse U 字段损坏(2026-08-22 深夜发现)

事件:V4.12 增强管线跑 100% 全检时,RK4 动力学一致性检查 99.1% 样本失败。逐层排查(增强数学 → RK4 公式对照 → 逐文件 FD 反演 → 全量扫描)锁定根因。
排查步骤发现
① 增强后全检失败5.4 万条 RK4 重积分误差高达数米(阈值 0.01m)
② FD 反演真实控制量有限差分得到的实际速度 = U[0]、实际转速 = U[1]——U 存的是两个恒定标量(全程平均速度/平均转速),不是逐步控制序列
③ 轨迹结构分析30/30 抽样 dθ₁ 全程恒定 → X 轨迹是恒曲率圆弧几何构造,不满足挂车动力学(无真实倒车机动)
④ 全量扫描 53,992 条53,485 条 U 损坏(99.1%)/ 507 条完好
⑤ 根因定位gen_worker_v5_test.py L338-353:MPC 初始解路径"从轨迹反推控制",存的是 (v, dθ₁/dt) 伪控制量却标记为 (delta, v)。v5_success / v5_new_success 两大批次 99% case 命中此路径
幸存数据:v5_prod 批 505 条 + 零散回收 2 条(真求解器路径产出,RK4 全过)+ 本机 s210001-3 未入库 31 条 = 538 条干净样本。本机数据 worker 已停止,污染源切断。
影响面:V4.9 / V4.11 两代训练用的旧批次数据同样带此缺陷——模型实际在学"恒曲率弧线拟合",这是三代训练始终到不了 V4.6 基线的深层原因之一。教训再次验证铁律 #9:模型效果差,先查数据再查算法

🔧 修复方案:重解 53,485 条 U(X 热启动,保留几何多样性)

用户拍板采用"重解 U"路线(对比:修 bug 重新生产 / 只用 538 条冒烟)。X 轨迹的几何质量完好(13 类场景、起点/终点/避障分布都在),只是标签坏了——丢掉坏 U,用 NLP 求解器问"什么逐步控制能让卡车贴着这条已有轨迹走"。

详情
求解机无影云 w7k123b4aph2ffo(16核/30G,casadi 已装)——经本机 10125 反向隧道接入;纯 CPU 任务不占用 169 GPU 机时
方法casadi/IPOPT:动力学为硬约束 + 轨迹贴合影子代价,坏 X 作为热启动初值(比从头解快 3-5 倍)
验收门槛与生产一致:pos<5cm / coll=0 / RK4<0.01 / th1e<1° / th2e<3°,不过进 failures 留分析
进度准备中:脚本开发 → 100 条小批量校准(耗时/淘汰率)→ 全量放开过夜
预期与风险:恒曲率构造的 X 物理上未必可精确复现,重解实际找的是"最贴近 X 的物理可行轨迹",会有淘汰率(预估 20-40%)。救回 3-4 万条即满足 V4.12 需求(×3 增强后 10 万+)。
08 · 🚨 数据危机与止血
增强管线 100% 全检揪出 warehouse 99.1% 样本 U 字段是恒曲率伪控制(gen_worker_v5_test.py MPC 反推路径 bug)。本机数据 worker 停止,6 条产出隔离;确认干净存量 538 条。
2026-08-22 23:xx
09 · 重解 U(无影云 16 核)
用户拍板"X 热启动重解 U"路线。求解机=无影云(经 10125 反向隧道)。脚本 resolve_u.py → 100 条校准 → 53,485 条全量。进度见上方"重解 U"卡片。
2026-08-23 进行中

训练复盘(结束后填写)

训练进行中。训练结束后在此填写:① 最终成绩 vs V4.6 基线逐项对比 ② 训练过程曲线解读(SS 下潜段表现/熔断是否触发)③ 数据管线质检结果 ④ 失败案例归因 ⑤ 下一步迭代方向。