目标：全面超越 V4.6 基线（0.28m / 99%）
实时状态 等待数据
等待训练日志…
数据源：169 机器 journal_v412.json，每 15 分钟由巡检同步到本站。
训练机器信息（169）
| 项目 | 配置 |
|---|
| 主机 | 无影云 p-0d01zbt5suva74z3e（内部代号 169） · ssh root@8.149.76.169 -p 53198 |
| GPU | NVIDIA RTX 5880-Ada-48Q · 48GB 显存（vGPU） |
| 驱动 / CUDA | 570.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，不过即弃 |
| DAgger | Online 专家纠错数据，每 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/end | 10 / 80 | 15 / 60 |
| SS floor | 0.3 | 0.5 |
| DAgger 配比 | ~10%（且与 SS 绑定） | 20%（与 SS 解绑） |
| 状态噪声 | 0.15m/0.03rad | 0.05m + 1°（错峰爬坡） |
| VAL 频率 | 每 5 epoch | 每 epoch（熔断输入） |
| 熔断机制 | 无（外部乱干预） | 制度化熔断 + 只读巡检 |
| LR | 1e-3→5e-4 | 5e-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 留分析 |
| 进度 | ✅ 已完结（2026-08-24）：最终路线 = 场景级重解（goal 同伦链），53,385 任务 100% 跑完，24,910 条成功（46.6%），24,867 条验收入库。详见下方"数据重产完结"卡片。 |
| 尝试 | 结果 | 结论 |
|---|
| ① X 热启动 NLP 重解（贴原轨迹） | 100% 失败 | 坏 X 是恒曲率弧，半径中位数 6.6m < 全舵最小转弯半径 8.28m，物理不可行，NLP 无可行解 |
| ② 直接 solve_homotopy_v3 重解（20 条） | 0/20 成功 | 随机远距离 goal 的冷启动成功率极低，必须走 worker 的 goal 同伦暖启动链 |
| ③ 场景级重解（goal 同伦链，12 条试跑） | 4/12 成功，80s/条 | 链路有效但成功率待提升；成功样本 RK4=0.0000 完美 |
修正认知：坏样本的"几何多样性"真正载体是 start/goal/obstacles 三元组（合法且可复用），不是 X 轨迹本身（物理不可达，救不回来）。场景级重解 = 保留三元组重新生成物理正确的 X/U。
预期与风险：恒曲率构造的 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 进行中
10 · 七机阵列全量重解
场景级重解成功率优化后全量放开：无影机+6台32核容器机(各22 worker)七机阵列，53,385 任务整点 rebalance 自动对账均分，08-23 深夜全部跑完（46.6% 成功率）。
2026-08-23
11 · 第一批入库 + index 治本
18,642 条批1过七道闸入库(git dfbf8ef1f)，53,487 条旧坏数据删除。次日发现批1只建 symlink 未写 index 的根因，触发过一次重复入库事故(24,445条,已回滚)，index 重建三方对齐。
2026-08-23 ~ 08-24
12 · 重产工程完结 🏁
批2 6,225条验收入库(git f4ca0bec5)，修复 ingest 单位bug(422条误拒)。最终库存 25,372 条全绿。七机收尾清理(残留worker+cron)，6台容器机关机，只留 m180 备用。
2026-08-24 08:xx
13 · V4.12 训练启动（m180 · Rev.B）
169 关机省钱，训练迁 m180(16G GPU)。方案 Rev.B：batch 4096+FP16 适配 16G 显存，SS/噪声/熔断等核心哲学不变。数据=25,372×3 SE2 增强后全量训练。方案变化点 6 项已登记，过程实时上本页。
2026-08-24 09:xx
14 · 训练三次失败定位 + Rev.C FP32 稳定启动
4096 OOM → expandable_segments 触发 vGPU 驱动不支持的 cuMemMap（新坑，已最小复现）→ FP16 term-loss 溢出全 NaN（V4.11 老坑，熔断器 ep4 正确拦截）→ FP32 batch2048 稳定运行。变化点 C7/C8/C9 已登记。100 epochs ETA ~10h。
2026-08-24 10:15
15 · Rev.D：熔断器误杀修正 + ep11 续训
Rev.C 跑到 ep11 被 CB_CONSEC 熔断误杀（VAL 3.81→4.52→4.96→4.75 三连恶化）。架构师分析：ep11 处于 warmup 期（SS 要 ep15 才启动），LR 峰值段 VAL 震荡是初级学习正常现象，非 V4.11 式深水区雪崩。用户拍板 Rev.D (C10)：CB_CONSEC 仅在 ep≥15 (SS 启动后) 生效，warmup 期仅保留 CB_BLOWUP 硬防线；从 ep11 checkpoint 断点续训（权重/epoch/best_metric 全恢复），12:06 起 ep12 无缝推进。
2026-08-24 12:06
16 · Rev.E：架构师深挖 + 熔断计数容差带（C11）
ep15 二次熔断后用户全权托管。深挖诊断：①数据对照（U 语义 corr=1.0/场景距离 11.5 vs 11.7m/RK4 全绿）排除数据问题；②定位真 bug = 恶化判定"不比 best 好就+1"，噪声级差异（3.812 vs 3.811）也被累计，且续训不清零历史计数 → ep11/ep15 两连误杀；③训练本身健康（LR 峰值期 VAL 震荡属预期，收敛靠后 85ep 衰减段）；④存档发现：重解批次 58% 步数 delta 贴满舵 ±0.4（IPOPT 紧约束解特性，旧假数据 0%——真物理 vs 恒曲率弧的差异，记录不处理）。C11：恶化判定改为 cur > best×1.15（15% 容差带内波动清零计数），从 ep15 续训。SS 已于 ep15 启动（tf 1.00→0.99），进入深水区观察段。
2026-08-24 13:04
17 · Rev.F：ep18 三连真恶化 → LR 调参重跑（C12）
Rev.E 续训至 ep18 再次熔断（5.91→6.10→5.05，均超 best×1.15 容差带，属真恶化非噪声）。用户拍板"调参重跑"。架构师归因：①SS 已启动（ep15 tf 开始下降），模型进入自回归预测阶段；②LR 5e-4 在 cosine 峰值段，对 58% 满舵贴边的硬数据偏高，loss 15 个 epoch 卡 39.7 纹丝不动 = 随机游走不收敛。C12：LR 5e-4 → 1e-4，从头重跑（旧 best=3.81 是随机游走期产物，不值得续）。旧 checkpoint 存档为 *_reve.pth。
2026-08-24 14:08
18 · Rev.G：ep22 评估阶段 OOM → 评估前清缓存（C13）
Rev.F 健康跑到 ep22（loss 持续下降 42.7→39.88，tf 已入 SS 段 0.93），VAL 评估时 OOM 挂死。根因：长跑显存碎片化累积（10.1G→14.7G 慢涨），评估的 attention in-projection 需 60MiB 连续块时无地可分。C13：每 epoch 评估前后 torch.cuda.empty_cache() 清碎片；cudaDeviceReset 修复 vGPU 上下文后从 ep22 断点续训。注：expandable_segments 在此 vGPU 不可用（Rev.C 已证），empty_cache 是 16G 卡长跑的标准防护。
2026-08-24 16:34
19 · Rev.H：SS 系统性伤害确诊 → floor 0.9 止血（C14/C15）
Rev.G 在 ep25 三连恶化熔断（4.92→6.38/6.26/6.63）。跨版本对照确诊：Rev.E(LR 5e-4) 与 Rev.G(LR 1e-4) 在 tf≈0.90 处 VAL 同步跳涨 1.4m——与 LR 无关，是 SS 本身在这批真物理数据上伤害闭环性能。另发现：纯 teacher forcing 期 VAL 也只到 4.92m（V4.11 同期 2.2m），真数据（58% 满舵）本质难学一倍。C14：SS_FLOOR 0.5→0.9 + SS_END 60→100（SS 伤害止血，先测出无干扰基线）；C15：从头跑（SS 曲线变形，续训会 tf 回跳）。旧 checkpoint 存档 *_revg.pth。下一层嫌疑人：term loss=128 结构性过大（压其他信号 3 个数量级）。
2026-08-24 18:09
20 · Rev.I/J：NaN 双杀确诊 vGPU 软错误
Rev.I(batch1536 从 ep22 续训)在 ep25 突发全 NaN；干净重跑的 Rev.J 在 ep14 再犯。两次共同点：显存爬到 14.5G 贴近 vGPU 上限后、单 epoch 内权重突变（前一个 epoch 完全干净→下一个 100% nan_skip）。梯度裁剪(1.0)在、起点权重验证干净、FP32 无溢出通路——排除算法因素，确诊为 16Q vGPU 高占用下的硬件级软错误洗权重。
2026-08-24 20:35 ~ 22:39
21 · 收工：等待新训练机 🏁
Rev.K(batch1024 + C17 NaN 自动恢复防线)22:41 启动验证后，用户拍板今日收工、明日换更强训练机。m180 训练进程已停(GPU 归零)、巡检 cron 已撤。全部 checkpoint 存档(*_reve/*_revg/*_revh_used)留在 m180 供迁移后对照。
2026-08-24 22:50
22 · 迁移 169（48Q 48G）· 数据血统核验 ✅
用户重启 169 作为新训练机（RTX5880-Ada-48Q 48G / 32核 / BF16 支持 / torch 2.7.1 环境完好）。迁移流水线：Rev.K 训练脚本(含 C10/C11/C13/C17 防线) → 重产 warehouse 25,372 条(200M, tar -h 解引用传输) → SE2 ×3 增强重跑(67,037 条, 22 worker / 11 秒)。血统核验：抽样 200 条增强样本 83 条带 re_resolve 标记(41%)，与重解产物在库占比吻合——确认为重产数据。
2026-08-24 23:40 ~ 23:45
23 · Rev.L：BF16 尝试翻车 → Rev.M FP32 稳定运行
Rev.L(C18)：169 支持 BF16，autocast 切 bfloat16 + batch 8192 + LR 2e-4。翻车：ep1 起 92/93 batch loss NaN（torch.compile ON + BF16 组合引发），C17 NaN 防线触发但因尚无 best 存档陷入恢复死循环（ep2-41 空转）。复盘两 bug：①BF16+compile 未充分验证不该首发；②C17 恢复逻辑缺"无 best 时重新初始化"兜底。Rev.M(C19)：补 reinit 兜底 + 回归 FP32 + batch 6144(显存 29G/48G 安全区) + LR 2e-4 + no-compile。00:00 启动，Epoch1-2 loss 43.2→41.4 健康下降，~90s/epoch，ETA ~2.5h。
2026-08-24 23:47 ~ 08-25 00:05
24 · Rev.N：完整跑到 ep46，169 也现 NaN（重要发现）
Rev.M batch6144 在 ep5 OOM(45.6G/47.7G, 预估30G过于乐观) → Rev.N(C20) batch4096 从 ep2 续训。完整跑通 46 个 epoch：VAL 13.7→4.32m(ep35)，之后 4.3~5.3m 平台震荡，ep46 三连熔断。⚠️ 重大发现：169 上也出现 5 次 weight NaN(ep8/15/17/25/37)，C17/C19 防线全部自动救回——推翻"m180 vGPU 软错误"单一归因，这是跨机器系统性现象（真数据满舵贴边样本的梯度病态 + 梯度裁剪防不住权重污染）。term loss 全程卡 128（其他信号被压 3 个数量级）与平台期吻合。
2026-08-25 00:14 ~ 01:51
25 · Rev.O：LR 5e-5 冲击平台期（守夜自主决策）
ep46 熔断后凌晨 2:26 自主决策(C21)：从 best checkpoint 续训 + LR 2e-4→5e-5，目标是低学习率细搜突破 4.3m 平台。若 Rev.O 仍卡平台 → 白天主线转向 term loss 结构性重构（Rev.P 候选：terminal 项按距离衰减/加权归一，让动力学信号可被学习）。
2026-08-25 02:26
26 · 守夜突破：Rev.P 损失重平衡 + Rev.Q 低 LR 细扫
Rev.P(C22): term 权重 0.3→0.01、rollout 0.2→1.0 从头跑——破局：VAL 从 4.32m 平台直落 2.5m 区，th1 误差 60°→17°（13 版本以来动力学信号首次被学习）。ep49 触到 2.01m 后 2.3-2.7 震荡，ep59 熔断。Rev.Q(C23): LR 3e-5 从 best 续训，ep68 破 2m，best 迭代至 1.81m。诊断链闭环：Rev.N(4.32 平台)→Rev.O(排除 LR)→Rev.P(实锤 term 压制)→Rev.Q(细扫收敛)。
2026-08-25 02:50 ~ 06:47
27 · ✅ Rev.Q 训练完成（100 ep）+ V5 数据生产开动
Rev.Q 完整跑完 100 epochs：VAL best=1.81m（med 1.43m, p90 4.13m, th1=11°, th2=20°, cf=78%）。对照：起点 13.7m → 4.32m 平台(旧损失) → 1.81m(C22 重平衡)。同机并行启动 V5 数据生产（v5_producer.py）：新采样 V5 场景 + 重解工程验证的 K 步 goal 同伦链 + 七道闸 100% 验收，10 worker，⛔ 砍掉老 worker 的伪 U 反推路径（8-22 数据灾难根因）。冒烟验证：产出 QC 全绿（th1e=th2e=pos=0）。
2026-08-25 06:50
🏁 数据重产工程完结（2026-08-24）
结果：53,385 个坏场景重解任务 100% 完成，24,910 条成功（46.6%），deep_verify 七道闸全量验收后 24,867 条入库。warehouse 最终库存 25,372 条干净数据，git 双 commit 封存（dfbf8ef1f + f4ca0bec5），三方对账一致。
| 项 | 详情 |
|---|
| 算力阵列 | 七机并行：无影机 15w + 6×32核容器机各22w（AutoDL 阵列，均分+对账 rebalance 每小时调度） |
| 最终路线 | 场景级重解（保留 start/goal/obstacles 三元组 + goal 同伦链暖启动），非原计划"X 热启动贴轨迹"（物理不可行，见上方三次尝试对照） |
| 成功/报废 | 24,910 成功 / 28,475 报废（坏 X 转弯半径中位数 6.6m < 卡车物理极限 8.28m，无解为主） |
| 验收 | deep_verify 七道闸 100% 逐条：RK4 重积分<0.01 / 非常数 U / 终端误差重算 / 独立碰撞复检 / 控制限内 / Schema 完整，99.9% 直接过；1 条 start 漂移修复，6 条硬伤隔离 |
| 入库批次 | 批1 = 18,642（08-23 21:22）+ 批2 = 6,225（08-24 08:0x），统一批次 v5_resolved |
过程事故与治本（三起，均已修根因）：
① 批1 入库只建 symlink 未写 index.json → 收尾时误判引发一次重复入库（24,445 条错误链接，已回滚），index 重建对齐；
② ingest_incremental.py metrics 单位 bug：重解批次 th 误差存度数，旧代码按弧度阈值比较误拒 422 条全绿样本，已加 re_resolve 标志自适应转换；
③ 机器夜间关机后整点 rebalance 误派 47,776 任务给单机重复重解（白跑 ~5h 已叫停），教训：跨机对账必须区分"机器不可达"与"任务未完成"。
对 V4.12 的意义：数据资产从"99.1% 污染 + 538 条幸存"恢复到 25,372 条全绿真轨迹。×3 SE2 增强后 ≈ 7.6 万训练样本，满足 V4.12 训练需求。剩余 28,475 场景报废不追救。
🚀 V4.12 训练启动 · 方案 Rev.B（m180 训练机适配版）
169 机已关机省钱，训练迁至用户保留的 m180（RTX5880-Ada-16Q / 16G 显存 / 32核 EPYC）。完整设计文档 = V412_Training_Plan_RevB.md（Rev.A 见 V412_Design.md）。训练哲学与 Rev.A 完全一致，仅硬件相关参数适配。
| 项 | 详情 |
|---|
| 训练机 | m180 = 8.147.145.180:56150（AutoDL 容器）· RTX5880-Ada-16Q 16G · torch 2.7.1+cu126（pin，防 169 驱动坑复发） |
| 训练数据 | warehouse 25,372 条全绿真轨迹（重产工程产出）→ SE2 ×3 增强（稀缺场景×4）→ 100% 全量 QC（RK4/OBB/终端误差七道闸）→ ≈7.9 万条 |
| 架构 | V4.9 4.77M 参数（验证过的架构，不动） |
| 超参 | LR 5e-4 cosine · batch 4096 · FP16 AMP(GradScaler) · SS start=15/end=60/floor=0.5 · 状态噪声 0.05m+1° ramp ep0-30 · DAgger 10%(目录空则0, 有数据热加载) |
Rev.A → Rev.B 变化点登记（6 项）：
C1 训练机 169(48G)→m180(16G)，因 169 关机省钱；
C2 batch 8192→4096、BF16→FP16，因 16G 显存约束+16Q 不支持 BF16；
C3 DAgger 20%→10%，因 m180 无历史 DAgger 数据（保留热加载路径，数据到位再评估升回）；
C4 torch.compile OFF，vGPU 环境稳定优先；
C5 max_samples/epoch 1.5M→76万，按实际数据规模；
C6 每 epoch 评估保留不变——熔断是 V4.11 血泪教训，不随硬件缩水。
过程纪律：① 每版方案变化点+原因全部登记本页；② 熔断触发=停止+存档+架构师分析+Rev.C 提案+用户拍板，永不自动重启；③ LLM 巡检 15min 只报告不动手；④ 训练 journal 实时映射到本页。
⚙️ 训练启动过程实录：3 次失败 1 次成功（2026-08-24 09:00-10:00）
| # | 尝试 | 结果 | 根因分析 |
|---|
| 1 | batch 4096 + FP16 AMP | ❌ CUDA OOM | rollout loss 逐步展开显存超线性，14.6G allocated 爆 15.77G 上限。16Q 显存天花板比预估低 |
| 2 | batch 2048 + FP16 + expandable_segments | ❌ operation not supported | 新坑：RTX5880-Ada-16Q vGPU 不支持 cuMemMap VA 映射，PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 直接触发驱动错误（最小复现：设该变量 + nn.Linear().cuda() 必现）。已验证 cudaDeviceReset 可修复上下文 |
| 3 | batch 2048 + FP16（无环境变量） | ⚠️ 跑通但 ep2 全 NaN → ep4 熔断 | FP16 溢出（V4.11 同款老坑）：term loss 初始 ~132，FP16 上限 65504，GradScaler 压不住 → nan_skip=372 全跳。熔断器正确触发（这是它第一次实战，按设计工作） |
| 4 | batch 2048 + FP32（Rev.C） | ✅ 稳定运行 | Epoch1 VAL 8.32m → Epoch2 5.76m 健康下降，显存 10.1G/16G，~6min/epoch，ETA ~10h/100ep |
Rev.B → Rev.C 变化点登记：
C7 AMP: FP16 → FP32（--no-amp），因 16Q 不支持 BF16 且 FP16 term-loss 溢出（V4.11 教训在 16G 卡上无解，只能 FP32）；
C8 batch 4096 → 2048（Rev.B 预估过于乐观，实测 4096 必 OOM）；
C9 ⛔ 禁用 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True（vGPU 不支持，触发 operation not supported）。
代价：训练速度 ~2×于 FP16 理论值，但稳定性优先（用户原则：难而正确，不抄近路）。
Rev.G → Rev.H 变化点 (C14/C15)：
C14 SS_FLOOR 0.5 → 0.9，SS_END_EPOCH 60 → 100。证据链：两次独立 LR 的运行（Rev.E 5e-4 / Rev.G 1e-4）都在 tf 降到 ~0.90 时 VAL 跳涨 1.4m 并三连熔断——SS 的自回归暴露在真物理数据上（58% 满舵贴边、控制信号硬）是系统性伤害，不是噪声不是 LR。floor 0.9 = 几乎纯 teacher forcing 跑完 100ep，先拿干净基线。
C15 从头重跑（非续训）：SS 调度曲线形状改变，续训会导致 tf 回跳混乱。Rev.G 前 25ep 已存档。
Rev.F → Rev.G 变化点 (C13)：
C13 每 epoch 评估前后 torch.cuda.empty_cache()。根因：22 个 epoch 显存碎片化累积（10.1→14.7G），评估 OOM（仅需 60MiB 连续块）。Rev.F 前 22ep 曲线健康（loss 单调降、tf 进 SS 段无崩溃），故断点续训而非重跑。
Rev.E → Rev.F 变化点 (C12)：
C12 LR 5e-4 → 1e-4，从头重跑。归因链：ep18 三连真恶化（容差带内也拦不住的 5.9/6.1 vs 3.81）+ loss 平台 39.7 + SS 深水区开启三证合一——峰值 LR 对真物理数据偏高，模型无法稳定下降。降 5× 后 cosine 从 1e-4 起步。ep9-18 曲线已存档（*_reve.pth + 训练日志），供最终复盘对比。
Rev.D → Rev.E 变化点 (C11)：
C11 CB_CONSEC 恶化判定从"cur ≥ best"改为 cur > best × 1.15。根因：VAL 带随机性，旧判定把 +0.001m 的噪声差异也计为"恶化"，健康训练在 LR 峰值段也大概率凑满 3 连击（ep11、ep15 两连误杀实录）；且 --resume 不清零 n_consec_bad，历史计数直接打死续训。修复后 15% 容差带内波动自动清零计数，真恶化（>15%）才累计。CB_BLOWUP（2×急停）不动。诊断副产品：重解数据 delta 贴边率 58%（vs 旧假数据 0%），U 一致性/场景分布全部验证通过——数据侧无嫌疑，可放心长跑。
Rev.C → Rev.D 变化点 (C10)：
C10 CB_CONSEC（3 连续 VAL 恶化熔断）从"全程生效"改为 仅 epoch ≥ 15（SS 启动后）生效。原因：ep11 误杀实录——warmup 期 LR 处于峰值（5e-4 量级），VAL 在 3.8~5m 区间正常震荡，3 连恶化≠崩溃；熔断器的设计靶点是 V4.11 式 SS 深水区不可逆雪崩（ep35+），提前武装只会误伤。CB_BLOWUP（VAL>2×best 急停）保持全程生效不放松。续训策略：checkpoint_latest（模型权重+epoch+best_metric 原子保存）断点恢复，零重复计算。
工具坑存档：SSH 远程 "pkill -f train_v412.py" 会匹配到 SSH 命令行自身导致会话自杀（新训练根本没启动，日志时间戳是判别关键）；必须 nohup bash -c 包裹或分两步操作。
📋 2026-08-24 训练日完整复盘（Rev.B → Rev.K，11 版迭代）
当日结论：训练未完成，但把 16G vGPU 训练机的全部工程地雷趟完了，同时拿到两个关键科学认知（SS 伤害 + 真数据难度）。用户决定换更强机器后重启，本复盘即新机器训练的避坑指南。
| 版本 | 关键改动 | 结局/教训 |
|---|
| Rev.B | C1-C6: 169→m180 迁移适配 | 方案层面，无直接教训 |
| Rev.C | C7 FP32 / C8 batch2048 / C9 禁 expandable_segments | ✅ 稳定 11ep。教训：vGPU 不支持 cuMemMap(operation not supported)；FP16 term-loss 溢出(V4.11 同款) |
| Rev.D | C10 熔断仅 SS 后生效 | ep11/15 两连误杀的修复之一 |
| Rev.E | C11 恶化判定 15% 容差带 | ep18 三连真恶化熔断(这次是对的) |
| Rev.F | C12 LR 5e-4→1e-4 | loss 恢复单调降；ep22 评估 OOM(显存碎片化 10→14.7G) |
| Rev.G | C13 评估前后 empty_cache | ep22 断点续训；ep25 三连恶化熔断 → 确诊 SS 系统性伤害 |
| Rev.H | C14/C15 SS floor 0.9 + 从头跑 | Epoch1 后 OOM — 2048+rollout3 反传峰值 14.7G 本就贴天，前几版能跑是运气 |
| Rev.I | C16 batch→1536 | ep25 突发全 NaN(显存爬 14.5G 后) |
| Rev.J | 干净重跑 batch1536 | ep14 再犯 NaN — 双杀确诊 vGPU 软错误 |
| Rev.K | C17 NaN 自动恢复防线 + batch1024 | 22:41 启动验证后按用户指令收工 |
两个关键科学认知（跨版本证据链）：
① SS 系统性伤害：LR 5e-4 与 1e-4 两次独立运行都在 tf≈0.90 处 VAL 跳涨 1.4m——scheduled sampling 的自回归暴露在这批真物理数据（58% 满舵贴边）上伤害闭环性能。Rev.H/K 的 floor 0.9 配置保留；
② 真数据难度基线：纯 teacher forcing 下 VAL 最好 4.92m（V4.11 假数据同期 2.2m）——重产的真数据本质上难学一倍，预期管理：新机器上的收敛目标应按此校准。
新机器避坑清单（给明天）：
① 优先 48G 显存(169 同款)——batch 8192 + BF16 + 远离碎片区；② 确认支持 BF16 再用 AMP，否则 FP32；③ ⛔禁用 expandable_segments(vGPU 系)；④ 保留 C13(评估 empty_cache)、C17(NaN 防线)、C10/C11(熔断时机+容差带)——这些是通用防护与硬件无关；⑤ 迁移包=/root/v412 全目录 + training_data_v412(67K) + warehouse_samples(25K)；⑥ torch 2.7.1+cu126 必 pin；⑦ SSH 远程 pkill 自杀坑用"log 时间戳验真启动"。
当日资产：训练代码 11 版迭代全部可追溯(git-worthy)；7 个 checkpoint 存档；数据资产完好(25,372 仓库 + 67,036 增强)；项目网页全程留痕(步骤 13-21 + C1-C17)。新机器开箱即跑，无需重复任何诊断。
🖥️ 训练机迁移：m180 → 169（2026-08-24 深夜）
| 项 | 详情 |
|---|
| 新训练机 | 169 = 8.149.76.169:53198 · RTX5880-Ada-48Q 48G · 32核 · BF16 ✅ · torch 2.7.1+cu126 环境免装 |
| 数据 | 重产 warehouse 25,372 条(血统核验✅ re_resolve 41%) → SE2 ×3 = 67,037 条，10 分钟完成迁移+增强 |
| 配置对比 | batch 1536(FP32/16G) → 6144(FP32/48G)，epoch 7min → 1.5min，100ep 从 10h 压到 2.5h |
| 事故 | Rev.L BF16+compile 组合 NaN(92/93 batch) + C17 恢复死循环(无 best 兜底缺失) → C19 修复后 Rev.M FP32 稳定 |
Rev.L → Rev.M 变化点 (C18/C19)：
C18(已回退) autocast→bfloat16：169 硬件支持但与 torch.compile 组合触发 NaN，未经小批验证就首发是流程错误，教训登记；
C19 NaN 恢复兜底：无 best_model 时 apply(reset_parameters) 重新初始化而非死循环。Rev.M 终版：FP32 + batch6144 + LR 2e-4(48G 卡回归原设计) + no-compile + C10/C11/C13/C17 全防线保留。
🏁 V4.12 Rev.Q 训练完成（2026-08-25 06:47）· 最终成绩 1.81m
结果：100 epochs 完整跑完，VAL pos_err best = 1.811m（中位 1.43m / p90 4.13m），th1=11.3° th2=20.3°，零碰撞率 78%。这是重产真数据上的第一个完整收敛模型。
| 指标 | 起点 | 旧损失最优(Rev.N) | Rev.Q 终点 | V4.6 基线(假数据) |
|---|
| VAL pos | 13.7m | 4.32m（平台死锁） | 1.81m | 0.28m |
| th1 误差 | ~70° | 60-70° 卡死 | 11.3° | — |
| th2 误差 | ~100° | 85-100° 卡死 | 20.3° | — |
与 V4.6 的差距解读：1.81 vs 0.28m——但两者不可直接比：V4.6 训的是恒曲率假轨迹（本质是弧线拟合，好学），V4.12 学的是真物理轨迹（58% 满舵贴边）。真数据天然难学一倍以上（纯 tf 基线 4.92 vs 2.2m）。1.81m 是真数据上的真实水平，且 th1/th2 大幅收敛说明模型在学真泊车。下一版提升路径：①正在生产的 V5 全新数据扩量；②SS 深水区精调（本次 floor 0.9 保守）；③term/rollout 权重进一步扫参。
关键教训沉淀（C1-C23 完整链）：本页 27 个步骤完整记录了从数据危机→重产→11 版踩坑→损失重平衡破局的全程。核心转折点 = C22 损失重平衡：term loss 128 压制动力学信号 3 个数量级是长 plateau 的根因，权重调对后立刻破局。
训练复盘（结束后填写）
训练进行中。训练结束后在此填写：① 最终成绩 vs V4.6 基线逐项对比 ② 训练过程曲线解读（SS 下潜段表现/熔断是否触发）③ 数据管线质检结果 ④ 失败案例归因 ⑤ 下一步迭代方向。