exp: 轮次33——限幅实测要付5.1pp到达（57.4→52.3%）；GPU真实周期36.7ms≈27Hz，瓶颈是重复几何而非推理

- 四组单变量对照（同256题同seed）：base / inc_cap / gap_margin 0.5 / 两者同开
  限幅后 到达 0.5742→0.5234、time_ok 0.3906→0.2656、2s误差比 0.210→0.279、超VMAX 1.0→0.0、刹停几乎不变
  → 之前那部分到达率是超速换来的；损失在逼近末段，不在刹停
- 0.5mm 余量门只付 3 题（0.5742→0.5625）；但 plans['gaps'] 在 0.5mm 截顶，5mm 护栏可达性需抬 cap 重算
- 前提更正：eval_cl 不传 steps、rollout 默认 steps=1（policy.py:156 一步生成），先前按 steps=16 得到的
  "当前配方 116ms≈8.6Hz" 作废；真实配方 36.68ms P50 / 49.17ms P99 ≈ 27.3Hz
- 归因更正：空算子 0.028ms、空 sync 0.005ms、encode 2.27ms → 不是启动/同步地板；
  单步推理仅 7.2ms 且 K=1→8 免费，周期里 ~27ms 是 cum_xf+宽相位的重复计算
- certify_uniform 挂上后 36.7→45.3ms（n=8）/49.6ms（n=16）
- kin_torch 补 a/b 形状守卫（脚本里广播不一致会算错 view），测试 30→31 项

docs/探索日志.md

@@ -650,9 +650,50 @@
 - **两个新开关**：`inc_cap=1` 在**反馈叠加之后**再按每轴 VMAX·DT 限幅（此前 `inc=clamp(act,±1)·astep` 之后又加 `gain×fb`，所以 1.66× 是结构性的）；`gap_margin>0` 让安全层要求间隙 > 余量而非 >0，并把宽相位 cap 自动抬到 `margin+0.5`——不抬的话 `gaps(allq, 0.5)` 的截顶值 0.5 会让任何 >0.5 的余量门限恒假。`col`（真实碰撞计数）仍按 `gap≤0` 判，不随余量改变，所以两者不会互相顶替。
 - **部署侧同病**（只读核查，未改 JS）：`webapp/js/ik-policy.js:355` 也是 `inc[s][j] += fbGain*fbStep[j]` 在 ±1·STEP 之后叠加，所以浏览器控制器同样能超 VMAX；JS 的余量是 `o.margin=5` 的**投影式**护栏（`project()` 每轴 ≤projMax，只处理 gap<margin 的近距对），与本轮的"低于余量就刹停"不是同一机制；`ACC=5.0` 只用于刹停段长度，不是每步加速度上限（§9.2 也没给数值化的加速度门槛，所以 `accel_ratio` 只作变体间比较）。
 - **间隙分布的口径坑**：第30轮 `plans['gaps']` 是在 cap=0.5 下记录的，所以"最小间隙 ≥1 mm 的题占 0"是截顶假象。可说的是：逐题最小记录间隙 p5 **0.0005**、p25 0.0064、中位 **0.046** mm，57.4% 的题曾低于 0.5 mm——即策略实际贴障碍飞，而查看器护栏是 5 mm。要把 0.5 以上那段分开，必须抬 cap 重算（本轮后续做）。
-- **四组单变量对照**（同 256 题、同 seed、其余按第30轮配方）：base / `inc_cap=1` / `gap_margin=0.5` / 两者同开。结果与加密复核见本节末尾的补充提交。
+- **四组单变量对照**（同 256 题、同 seed、其余按第30轮配方）：base / `inc_cap=1` / `gap_margin=0.5` / 两者同开。结果见下表。
+
+- **四组单变量对照结果**（同 256 题、同 seed、K=8、commit 2、fb 2.2、fb_block_gain 0.5、dls_safety 1、select endpoint、replan empty、partial 1；`docs/experiment_round33_{base,cap,margin,both}.json`）：
+
+  | 变体 | 到达 | 无碰撞到达 | time_ok_1p3 | 真实碰撞 | 刹停/题 | 速度比 p50 | 超 VMAX 题占比 | 2 s 误差比 |
+  |---|---|---|---|---|---|---|---|---|
+  | base | 147/256 = 0.5742 | 0.5742 | 0.3906 | 0 | 19.25 | 1.660 | 1.000 | 0.2100 |
+  | `--inc_cap 1` | 134/256 = 0.5234 | 0.5234 | 0.2656 | 0 | 19.55 | 1.000 | 0.000 | 0.2790 |
+  | `--gap_margin 0.5` | 144/256 = 0.5625 | 0.5625 | 0.3789 | 0 | 20.05 | 1.660 | 1.000 | 0.1817 |
+  | 两者同开 | 133/256 = 0.5195 | 0.5195 | 0.2617 | 0 | 19.97 | 1.000 | 0.000 | 0.2870 |
+
+  - **速度限幅是有代价的硬约束**：每轴增量限回 VMAX 后到达 −5.1 pp、time_ok −12.5 pp、2 s 误差比 0.210→0.279。也就是说 base 的 57.4% 里**有一部分是用超速换来的**：反馈在限幅之外叠加，实际替模型补了速度。不能把 base 当作"满足速度约束的成绩"。
+  - **机理**：base 速度比 p50=1.660 恰等于 `1+0.3×fb_gain 2.2`；限幅后刹停几乎不变（19.25→19.55），但 time_ok 掉得比到达更多，说明损失集中在**逼近目标末段被剥夺了超速修正**，不是更容易刹停。所以出路不是调低增益（第29/30轮已测：增益小到达就掉），而是把该由前馈承担的速度还给模型——在限幅后的分布上重采数据（DAgger，需批准），或用不违反速度约束的前馈（#14 的余量投影 + 按时限打分）。
+  - **0.5 mm 余量门很便宜**：只少 3 题、刹停 +0.8/题，2 s 误差比反而更好（0.182）。但这不等于裕度够用——它只说明"要求 0.5 mm 不明显拖慢"。5 mm（查看器护栏）是否同样便宜，取决于策略能否找到 ≥5 mm 的路径，必须抬 cap 重算真实间隙分布才能回答（第30轮 `plans['gaps']` 在 0.5 mm 截顶，算不出这一条）。
+  - 四组 `collision_rate` 都是 0，但这仍是端点/中点离散口径；`gap_margin` 不改 `col` 判据（仍 `gap≤0`），余量与碰撞计数是两条独立的线，不互相顶替。
 - **回归**：`python -m unittest tests.test_eval_cl` **30 项通过**（新增 4 项）：未限幅时实测速度比确实 =3.4/1.2>1（灵敏度）、限幅后恰为 1.0、0.3 mm 间隙在余量 0 时通过而余量 0.5 时刹停、5 mm 间隙在余量 0.5 时仍通过（证明 cap 抬升生效，否则该测试会恒假）。
 
+- **GPU 上的一个控制周期（按 GPU 口径实测）**：诊断档与逐项分解见 `docs/experiment_round33_gpu_cycle.json`，真实配方（steps=1）见 `docs/experiment_round33_gpu_cycle_steps1.json`，RTX 3090、B=1、float32 推理 + float64 认证，每项 20 次预热 + 120 次计时并 `cuda.synchronize`。
+
+  - **前提更正（重要）**：`eval_cl` 从不传 `steps`，`rollout` 默认 `steps=1`，而 `ml/model/policy.py:156` 写明"steps=1 即一步生成，steps>1 是诊断用"。所以第27轮以来的所有评估成绩一直是**单步推理**；本节先用 steps=16 测出的"当前配方 116 ms ≈ 8.6 Hz"是口径错误，已作废并在下面用真实配方重测。
+  - **真实配方（steps=1, K=8）的分解**：
+
+  | 环节 | P50 | P95 | P99 |
+  |---|---|---|---|
+  | 推理 `sample_k` steps=1，K=1 / 4 / 8 | 7.11 / 7.08 / 7.19 | 9.45 / 10.17 / 9.95 | 11.91 / 14.00 / 11.34 |
+  | 特征 83 维（总 / 其中宽相位间隙 / 其中 FK） | 13.11 / 8.18 / 4.00 | 19.57 / 16.57 / 7.51 | 21.17 / 19.43 / 8.47 |
+  | 目标反馈 DLS 1 步 | 6.53 | 9.32 | 12.62 |
+  | 现有离散安全层 4 点（cap 1.0） | 7.41 | 11.34 | 13.80 |
+  | `certify_uniform` 2 根 n=8 / n=16 | 9.70 / 16.07 | 14.40 / 20.95 | 15.75 / 24.42 |
+
+  | 组合周期（同一位姿，顺序测；跨行比较受漂移影响，只作量级） | P50 | P95 | P99 |
+  |---|---|---|---|
+  | K=8 + 离散安全层（真实配方） | **36.68 → 27.3 Hz** | 43.27 | 49.17 |
+  | K=4 / K=1 + 离散安全层 | 37.71 / 40.36 | 55.17 / 48.46 | 76.53 / 52.06 |
+  | K=8 + 连续认证 n=8 | 45.34 → 22.1 Hz | 49.68 | 52.20 |
+  | K=8 + 连续认证 n=16 | 49.55 → 20.2 Hz | 56.85 | 59.06 |
+  | （对照）诊断档 steps=16 的同一周期 | 116.5 | 134.5 | 142.6 |
+
+  - **归因更正（先证仪表再下结论）**：空算子 P50 0.028 ms、空 `synchronize` 0.005 ms、一次 `encode` 2.27 ms，所以**不是启动/同步地板**。先前口算的"5–10 ms 是 GPU 启动开销"错了，在此更正：特征 13.1 ms、认证 7.4 ms、DLS 6.5 ms 是 B=1 下真实的小算子工作量——即 **GPU 在单臂批量=1 时利用率极低**，而不是被框架拖慢。
+  - **推理不是瓶颈，几何才是**：单步推理 7.2 ms，且候选数几乎免费（K 1→8 不涨）；一个周期里几何类工作合计约 27 ms（特征宽相位 8.2 + 特征 FK 4.0 + 认证 7.4 + DLS 6.5），并且这几次调用各自重复做 `cum_xf` 与宽相位筛选。所以 50 Hz 的路径是**合并几何查询**（`features()` 已支持 `gm=`/`xf=` 复用，`gm_groups` 文档保证与整表 `gaps` 数值一致），而不是继续压推理。
+  - **连续认证的增量成本可接受**：在同一位姿上 n=8 只比现有离散层贵约 8.7 ms（整周期 36.7→45.3 ms），n=16 贵约 12.9 ms。也就是说"段内连续证明"在 GPU 上不是奢侈项，真正卡住 20 ms 的是那 ~27 ms 的重复几何。合并后再看是否进得了 20 ms——这一步正在做交错复测（跨行顺序测的数字受漂移影响，不作最终结论）。
+  - **50 Hz 结论（当前状态）**：真实配方一个规划周期 **36.7 ms（P99 49.2）≈ 27 Hz**，仍不满足"P99<20 ms"；且必须记住这是在**不限幅**（可超速 1.66×）的策略分布下测的——限幅后的到达率代价见上表，两者不能混着谈。
+  - f32 与 f64 的间隙在 3 个点上完全相同（最大偏差 0.0 mm、无符号翻转），但 **3 个点不足以支持"认证可以改用 float32"**，需按真实轨迹批量对比才能下结论。
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。