ml: 显存预算按 19–20 GB 落地（APG batch 128→48 + 每进程硬帽 + vram 上日志/网页）；自检四处判据与环境坑修好，整轮 7/8 通过 3.5 分钟
- ml/configs/apg.json：batch 128→48。本机实测（d=192 同结构、每进程 19.2 GB 硬帽、1 步即到位）batch=128 无论 plans 取 60 还是 150 都 OOM（崩前已分配 17.85 GiB；d=32 小模型也 17.54 GiB，说明是展开图吃显存而非模型大小）；48/plans=150 为 13.08、48/60 为 7.67。展开长度 plans 没动，降 plans 会把长任务绕出段截掉。
- ml/common/vram.py（新）：limit() 设每进程帽 VRAM_FRAC 默认 0.78≈18.7 GiB 并打印上限；peak_gib() 供日志。train.py 与 apg_finetune.py 调用，每条记录新增 vram 字段（实测 train batch=1024 → 2.71，APG 自检档 → 0.33）。没帽时 APG 会把整卡顶到 23.6 GB、连桌面一起挤掉。
- ml/monitor.py / monitor.html：状态带 vram_budget_gb（默认 20，VRAM_BUDGET_GB 可改），GPU 显存条按预算算并超线变色，指标卡加「显存峰值」（>14 黄 >17 红）。headless 加载渲染 DOM 复核过。
- ml/configs/smoke.json 补 apg 段（batch=8）+ selftest.sh 的 APG 两项带 --config：原先不带 → 自检第 6 项按正式 batch=128 跑，本机必 OOM。
- ml/selftest.sh：gen_resume 判据由 cmp -s 改为剔除 plan_ms/cert.ms 两个墙钟字段后逐条比（旧判据恒 false）；rec() 值非合法 JSON 时记 false 不再静默丢项。
- ml/selftest_proc.py：alive() 读 tasklist 改 text=True+errors='replace' 并防 None（中文 Windows 表头 GBK 会让读线程抛 UnicodeDecodeError→stdout=None→TypeError）；wait_pids 带上最后一次异常。
- ml/monitor.py find_bash()：便携版 git 的 mingw64 布局要再上一层找 bash，并兜 which('bash')（排除 System32 的 WSL）。本机原先返回 None → 网页「开始训练」起不动、自检进程两项没跑。
- 整轮自检重跑：gen_resume/prep_rerun/train_stop/train_stopfile/apg_resume/tree_killed/survive_parent_exit 全 true，仅 train_term false（timeout 的 TERM 送不到原生 python，rc=124 硬杀）；用时 3.5 分钟。
- 文档：新增第七节（显存实测表、自检 8 项结果、四条判据/环境坑、本机改动清单）；A-3 改为「实现方已改、待复跑验证」，C-5/C-6 标为已实测，D 组复核后关闭。
This commit is contained in:
+74
-7
@@ -3,7 +3,7 @@
|
||||
六轮历史（`0218d7f` → `a5e779c`）：第一轮 13 条、第二轮可行性、第三~五轮处置、第六轮本机实跑。**已解决的条目按用户要求删去，完整原文在 git 历史里**。本文件只剩三部分：仍有效的实测数字 / 仍未解决的问题 / 已复核正常的项，供实现方下一轮处置。
|
||||
|
||||
环境：本机 CBB-003（RTX 3090、28 核、Python 3.12 + torch 2.10 + onnxruntime 1.22、Edge + onnxruntime-web 1.20.1）。
|
||||
当前结论：第 1–6 步已实测可跑；**第 7–13 步零证据**；R4 部署口径（纯推理）已判通过，`bash ml/pipeline.sh r4` 端到端 rc=0（2026-10-18 本机修复后复跑）。A 组原三处中两处已修，只剩离线部署 A-3。
|
||||
当前结论：第 1–6 步已实测可跑；**第 7–13 步零证据**；R4 部署口径（纯推理）已判通过，`bash ml/pipeline.sh r4` 端到端 rc=0（2026-10-18 本机修复后复跑）。A 组原三处中两处已修，A-3 由实现方第七轮改掉、待本机复跑验证。**第七轮本机复核与显存预算（19–20 GB）见第七节。**
|
||||
|
||||
---
|
||||
|
||||
@@ -43,8 +43,8 @@ tickGapMax 全部 ≈21.5 ms（20 ms 节拍没被卡住）。背景：第五轮
|
||||
- `pipeline.sh` 7 处 `json.load(open(...))` 全部补 `encoding='utf-8'`（`:90 :110 :118 :127 :136 :138 :144`）。
|
||||
- 附带发现并修掉：r4 分支末行 `[ "$r" = null ] && echo` 在 `r=pass` 时整体返回 1，`set -e` + EXIT trap 把**通过的 r4 记成 rc=1**（`all` 会因此停）。已改为 `if ... then ... fi`。
|
||||
|
||||
**A-3 仍未修：`&ortLocal=1` + 默认 proxy 必然失败。**
|
||||
`ik-policy-glue.js` 把 `ort.env.wasm.wasmPaths` 设为相对前缀 `vendor/ort/`，ORT 对 `.mjs` 走 `import()` 需要绝对说明符 → `no available backend found. ERR: [wasm] TypeError: Failed to resolve module specifier 'vendor/ort/ort-wasm-simd-threaded.mjs'`。README 明确支持的离线部署路径在默认配置下不可用。（`ortLocal=1` + `proxy=0` 未测；`wasmPaths` 与 proxy 无关，大概率同样失败。）
|
||||
**A-3 离线 ort 加载：实现方第七轮已改（绝对 URL + `vendor_ort.sh`），本机待复跑验证。**
|
||||
`ik-policy-glue.js` 把 `ort.env.wasm.wasmPaths` 设为相对前缀 `vendor/ort/`，ORT 对 `.mjs` 走 `import()` 需要绝对说明符 → `no available backend found. ERR: [wasm] TypeError: Failed to resolve module specifier 'vendor/ort/ort-wasm-simd-threaded.mjs'`。README 明确支持的离线部署路径在默认配置下不可用。（`ortLocal=1` + `proxy=0` 未测；`wasmPaths` 与 proxy 无关，大概率同样失败。）**复跑判据**：断网/CDN 不可达时 `bash ml/pipeline.sh r4` 仍能出数（探针默认走本地 `webapp/vendor/ort/`），且 `&ortLocal=1` 的查看器徽标显示「策略模式就绪」。
|
||||
|
||||
### B. 待实现方判断（数据已摆在上面；分歧按第五轮第〇节规则，以实现方为准）
|
||||
|
||||
@@ -60,12 +60,13 @@ tickGapMax 全部 ≈21.5 ms（20 ms 节拍没被卡住）。背景：第五轮
|
||||
2. **3 mm 间隙过滤的真实剔除比例（`gapDrop`）没测过**：只测过沙箱 30 条（剔 9/29，不具代表性）；上表 p50 4.4 mm 是未过滤口径。生成后看 `stats.json` 的 `gapDrop`。
|
||||
3. **R2 新判据（`label_std_norm`）的池无关性**：需在 1.7 M 样本上 `--pool 50000` 与 `--pool 200000` 两跑、差 <0.02 才成立；没做。默认 `R2_STRICT=0` 只警告，开着就是一道未校准的闸。
|
||||
4. **R8 出题耗时**：沙箱 2 题 9 分钟没出完；本机未测（`policy_bench.json` 会记 `requested` / `genS`，不足额时看警告）。
|
||||
5. **Windows 侧生命周期全部未实测**：关控制台黑窗口训练是否继续（`CREATE_NO_WINDOW`）、`/proc/$$/winpid` + `taskkill /T` 能否结束整树、Git Bash 自带 `timeout` 能否把 TERM 送到 python / node。
|
||||
6. **断点续跑的沙箱自测未在本机复核**：gen 截断续写（「续写：已有 N 条」）、train STOP 存档（rc 143、`last.pt` 第 N 步）、apg `--resume`、prep 二次运行「待打包 0 个」。
|
||||
5. ~~**Windows 侧生命周期未实测**~~ → **已实测**（见 7.2）：整树杀净 ✅、关黑窗口训练继续 ✅、`timeout` 的 TERM 送不到 python ❌（超时只能硬杀，靠 STOP 文件与定时存档）。
|
||||
6. ~~**断点续跑未在本机复核**~~ → **已实测**（见 7.2）：gen 按条续写逐条一致、train STOP 2 s 存档续训、apg `--resume`、prep 二次运行「待打包 0 个」全部通过。
|
||||
7. **APG 的机时仍然零实测**（显存已量：`batch=48/plans=150` → 13.08 GiB）。`batch` 从 128 降到 48 后每步代价与收敛都要重算一遍才知道。
|
||||
|
||||
### D. 小遗留
|
||||
|
||||
`webapp/models/README.md` 过时：还写"由 `--fp16` 生成"、指向"第 8 步"（现为第 10 步、默认 fp32）。
|
||||
~~`webapp/models/README.md` 过时~~ → 实现方第七轮已改，本机复核过：现在写的是 `bash ml/pipeline.sh export`（默认 fp32）、第 10 步、新输入签名 `feat[1 或 K,83]` 与 `feat_dyn`，并说明离线要先跑 `ml/prep/vendor_ort.sh`。
|
||||
|
||||
---
|
||||
|
||||
@@ -81,7 +82,7 @@ tickGapMax 全部 ≈21.5 ms（20 ms 节拍没被卡住）。背景：第五轮
|
||||
|
||||
1. ~~A 组修复并重跑 `r4`~~：已完成（本机 2026-10-18，rc=0、P99 11.25）。
|
||||
2. 接着 `FROM=gen TO=prep` 跑一次（数小时），拿 `gapDrop` 与 R2 两个口径的数——C-2 / C-3 随之消掉，B-2 的 Node 侧安全层数字可顺手从 m5 前的 bench 拿。
|
||||
3. B 组等上面的数字齐了再定；C-1 / C-5 / C-6 随第一次真跑逐项核对；A-3（离线 ort 加载）交给实现方。
|
||||
3. B 组等上面的数字齐了再定；C-1/C-7 随第一次真跑逐项核对；A-3 由实现方已改，本机复跑 `r4` 时顺带验（会弹有界面窗口）。
|
||||
|
||||
---
|
||||
|
||||
@@ -179,3 +180,69 @@ V1 通过后再跑，分三段，每段跑完把回传文件发我：
|
||||
| 后训练与评测 | `FROM=apg TO=accept bash ml/pipeline.sh all` | 约 10–20 小时 | `ml/runs/acceptance.json`、`policy_bench.json`、`r9_browser.json` |
|
||||
|
||||
任何一段中途出错：把出错信息发我，我修完后用 `FROM=<出错阶段>` 接着跑，前面的不重做。
|
||||
|
||||
---
|
||||
|
||||
## 七、本机复核第六/七轮处置（2026-10-18，含显存预算）
|
||||
|
||||
**先说约束（用户定的，之前所有估算都按整卡 24 GB 写了）**：本机 Windows + 4K 桌面**空闲就占 4.4 GB**（`nvidia-smi` 空载 23604→4394 MiB 实测），所以 **ML 只能用 19–20 GB**。
|
||||
|
||||
### 7.1 APG 会直接把第 8 步打崩（实测，非推算）
|
||||
|
||||
用 d=192（与正式训练同结构）、`--steps 1`（峰值在第一次反向就到位）、每进程硬帽 19.2 GB，逐档实测 `max_memory_allocated`（GiB）：
|
||||
|
||||
| batch | plans=60 | 90 | 120 | 150 |
|
||||
|---|---|---|---|---|
|
||||
| 32 | 6.14 | | | 9.53 |
|
||||
| **48（已定为新值）** | 7.67 | | | **13.08** |
|
||||
| 56 | | | 13.61 | |
|
||||
| 64 | 10.81 | 15.41 | | 17.66 |
|
||||
| **128（原值）** | **OOM** | | | **OOM**（崩前已分配 17.85 GiB） |
|
||||
|
||||
- **原 `batch=128` 无论 `plans` 取 60 还是 150 都 OOM**（d=32 的小模型也一样，崩前 17.54 GiB）→ 显存是被展开图吃掉的，与模型大小、数据量无关。
|
||||
- **已把 `apg.json` 的 batch 定为 48，`plans 60→150` 不动**：最坏 13.08 GiB，加桌面 4.4 GB ≈ 17.5 GB，在 19–20 GB 预算内。没选"降 plans"是因为降展开长度会把长任务的绕出段截掉（就是口径-3 那个问题）。`batch=64 + plans=150` 要 17.66 GiB，加桌面就到 22 GB 了，不取。
|
||||
- **加了每进程显存硬帽**：`ml/common/vram.py`，`VRAM_FRAC` 默认 0.78 ≈ 18.7 GiB，训练与 APG 启动时打印上限。没帽时它会把整卡顶到 23.6 GB、连桌面一起挤掉（就是这次报显存的原因）。
|
||||
- **显存用量现在看得见**：`train.py` / `apg_finetune.py` 每条日志带 `vram`（峰值 GiB）；监控页指标卡加「显存峰值」（>14 黄、>17 红），GPU 卡的显存条改成按 **20 GB 预算**算而不是整卡 24。实测：预训练 `batch=1024` 记到 `vram: 2.71`，APG 自检档 `vram: 0.33`。
|
||||
- 对照：预训练 `batch=1024` 峰值 **2.76 GiB**（够）；`check_r2` 每样本常驻 **776 B** → 1.7 M 样本 **1.32 GB** + 分块 0.05（4× 池自检 0.2）≈ **1.6 GB**，脚本里"GPU 峰值 <0.5 GB"错了约 3 倍，但不会崩。
|
||||
- 顺带：N-6 的"按空闲显存 1/4 自动定块"、出题分块等估算都要按 19 GB 重算。
|
||||
- **`ml/configs/smoke.json` 原来没有 `apg` 段**，而 `selftest.sh` 调 APG 时不带 `--config` → 自检第 6 项实际按正式 `batch=128` 跑，在本机必然 OOM、自检永远跑不完。已补 `apg` 段（`batch=8`、实测 `vram` 0.33 GiB）并让自检带 `--config`。
|
||||
|
||||
### 7.2 生命周期与断点续跑：本机整轮自检 **7/8 通过**，用时 3.5 分钟
|
||||
|
||||
| 项 | 结果 |
|
||||
|---|---|
|
||||
| `gen_resume` | ✅ true（判据修正后）——「续写：已有 2/6 条，从第 3 条继续」，与一口气生成**逐条一致** |
|
||||
| `prep_rerun` | ✅ true——二次运行「待打包 0 个」 |
|
||||
| `train_stop` | ✅ true——`--stop-at 20` → rc 143、`last.pt` 第 20 步、续训到 40 步 rc 0 |
|
||||
| `train_stopfile` | ✅ true——写 `ml/runs/STOP` 后 **2 s** 退出并存档（第 351 步）。控制台「停止」走的就是这条路 |
|
||||
| `train_term` | ❌ **false（Windows 的真实限制）**——`timeout` 的 TERM 送不到原生 python，rc=124 是硬杀。结论：阶段超时不能指望体面存档，靠 STOP 文件 + 每 10 分钟定时存档 |
|
||||
| `apg_resume` | ✅ true（自检档 `batch=8`，`vram` 0.33 GiB） |
|
||||
| `tree_killed` | ✅ true（实测）——`taskkill /T /F` 把 bash→python+node 整树杀净，没留孤儿 |
|
||||
| `survive_parent_exit` | ✅ true（实测）——启动器退出后子树仍活着 = **关掉控制台黑窗口不影响训练** |
|
||||
|
||||
用时 3.5 分钟（APG 用自检档；上一轮 APG 走正式 `batch=128` 时是 13.2 分钟，而且 OOM）。
|
||||
之前测不到的原因：① `monitor.find_bash()` 在本机返回 `None`（Qoder 自带 git 在 `mingw64\bin\git.exe`，"上上级 + bin/bash.exe"推出一个不存在的路径）；② `selftest_proc.alive()` 用 `text=True` 读 `tasklist`，中文 Windows 的表头是 GBK → 读线程 `UnicodeDecodeError`、`stdout` 变 `None` → `TypeError`，异常又被 `wait_pids` 的 `except Exception` 吞掉。
|
||||
|
||||
### 7.3 两条判据自身的问题（会让"通过/失败"失真）
|
||||
|
||||
1. **`selftest.sh:27` 用 `cmp -s` 逐字节比生成结果**，但记录里含 `plan_ms` 与 `cert.ms` 两个**墙钟耗时字段** → 两次运行不可能相同，**这项永远是 false**。我在副本里重跑基线、只把这两个字段剔掉后逐行比：**6 条完全一致** → 续写逻辑正确，是判据错。
|
||||
2. **`rec()` 用 `json.loads` 解析传入值**，而 `str(None).lower()`=`none` 不是合法 JSON → 抛异常、整项**静默不进结果文件**，`all_pass` 照样算出来。所以"第七轮说自检已修完"的两项进程测试，实际上是没跑过。
|
||||
3. **自检副本只复制 `git ls-files` 里的文件**（`selftest.sh:16`）→ 任何**未跟踪的新文件**在副本里不存在，调用它的项会以 `ModuleNotFoundError` 变成 rc=1，看起来像功能坏了。本轮新加 `ml/common/vram.py` 就踩了：`train_stop`/`train_stopfile`/`apg_resume` 三项同时 rc=1，`git add` 之后才恢复。判据建议：自检开头先 `git ls-files --others --exclude-standard` 非空就报出来（或改用 `git ls-files -o --exclude-standard -t` 一起复制）。
|
||||
|
||||
### 7.4 本机已改的（都按实测落地，不改判据含义）
|
||||
|
||||
| 位置 | 改动 | 验证 |
|
||||
|---|---|---|
|
||||
| `ml/monitor.py` `find_bash()` | 便携版 git 的 `mingw64` 布局要再上一层；再兜 `which('bash')`（排除 System32 的 WSL bash） | 返回 `...\.qoder\bin\git\bin\bash.exe`（bash 5.2.37）；网页「开始训练」在本机的拦路石解除 |
|
||||
| `ml/selftest_proc.py` `alive()` / `wait_pids()` | `tasklist` 用 `text=True, errors='replace'` 并防 `None`；起不来时把最后一次异常带进结果 | `tree_killed`、`survive_parent_exit` 两项实测 true |
|
||||
| `ml/selftest.sh` | `rec` 解析失败记 false 不再丢项；`gen_resume` 判据剔除 `plan_ms`/`cert.ms`；APG 两项带 `--config` | 重跑第 1 项已变 **true**（「续写：已有 2/6 条 → 逐条一致」） |
|
||||
| `ml/configs/apg.json` | `batch 128 → 48`，加 `_vram` 记录实测表 | 最坏 13.08 GiB（实测），在 19–20 GB 预算内 |
|
||||
| `ml/configs/smoke.json` | 补 `apg` 段（`batch=8`） | 自检 APG 档 `vram: 0.33` |
|
||||
| `ml/common/vram.py`（新）+ `train.py` + `apg/apg_finetune.py` | 每进程硬帽 `VRAM_FRAC=0.78`（启动打印上限）；日志每条记录加 `vram` 峰值 | `显存上限：本进程 18.7 GiB（整卡 24.0 × 0.78）`；train `vram: 2.71` |
|
||||
| `ml/monitor.py` + `ml/monitor.html` | 状态带 `vram_budget_gb`（默认 20，`VRAM_BUDGET_GB` 可改）；GPU 显存条按预算算并超线变色；指标卡加「显存峰值」 | headless 加载渲染出的 DOM 里有「显存峰值 / 预算 19–20 GB（整卡 24，桌面占 4–5）」 |
|
||||
|
||||
### 7.5 仍需实现方处理的（我没动）
|
||||
|
||||
- **APG 的 `steps` 与机时**：`batch` 从 128 降到 48，每步看到的任务少 2.7 倍。`steps=3000` 要不要加、加多少是收敛判断，我只有显存实测、没有这个依据。`R2/R4/N-6` 各处按整卡写的显存估算文案也要按 19–20 GB 重写。
|
||||
- `R4 复跑`：`feat_dyn` 要重导模型，探针现在会**弹有界面窗口**跑 `viewer_ref`（30 题×≤10 s）与 WebGPU——本机跑之前请知悉会有窗口，别动它。
|
||||
- B-2 的几何查询搬 Worker（若本机 R9 仍不过）；R9 用真模型才有意义。
|
||||
|
||||
Reference in New Issue
Block a user