perf+exp: 轮次34——复用cum_xf进库(22项指标逐位不变)、批量认证压最坏尾部(80→37ms)、FP16/BF16实测无收益

- 撤回一条自己的假收益：先前"合并几何查询→24.5ms"不成立。①第一版把 xf= 传给含5行的 gaps，
  只有第0行走完宽相位，认证点全部退回截顶40.0（少干活）；②真实顺序 特征→推理→候选→认证，
  认证点依赖网络输出，故"特征间隙与认证点合并一次调用"实现上做不到
- 可实现并已落地：gm_groups(..., xf=) 复用 features 已算的 cum_xf，B=1 交错实测 P50 −3.4ms；
  256题重跑 22 项指标与轮次33 base 逐项相同
- 新增 --cert_batch（默认0不变）：K条候选并成1次 gaps 调用。合成夹具(B=2)断言选择/轨迹/证书逐位一致，
  变异检查（换回错误索引）2项测试立即失败；256题重跑同样 22 项指标逐位相同
  实测交换：典型 33.5→37.6ms，最坏（前面候选被拒）80.2→37.1ms，P99 64.7→48.3ms
- FP16/BF16 实测不比 FP32 快（推理 7.68→8.31→8.58ms），整周期不变而 P99 更差，动作偏差 0.005°/0.038°
  → 小批量下不是算力受限，半精度不划算，推理保持 FP32
- 仍不达 20ms：下一刀是流水线复用（下次规划的特征间隙＝本次已认证的末点），可整块省掉特征 ~13ms
- 测试 32→34 项

docs/探索日志.md

@@ -694,6 +694,33 @@
   - **50 Hz 结论（当前状态）**：真实配方一个规划周期 **36.7 ms（P99 49.2）≈ 27 Hz**，仍不满足"P99<20 ms"；且必须记住这是在**不限幅**（可超速 1.66×）的策略分布下测的——限幅后的到达率代价见上表，两者不能混着谈。
   - f32 与 f64 的间隙在 3 个点上完全相同（最大偏差 0.0 mm、无符号翻转），但 **3 个点不足以支持"认证可以改用 float32"**，需按真实轨迹批量对比才能下结论。
 
+## 轮次 34：GPU 周期的可实现优化——复用 FK 与压认证最坏情况（exp: `exp/dagger-deploy`）
+
+- **起因与一次自我撤回**：轮次 33 记下"合并几何查询看能不能进 20 ms"后，先按 `docs/experiment_round34_fused_cycle.json` 测出"整周期 41.9→24.5 ms"。这个数**作废**，两个独立原因：
+  1. 第一版的"合并"把 `xf=` 传给了包含 5 行的 `gaps` 调用，而 `gaps` 的 `xf` 是按行对应的 → 只有第 0 行走完宽相位，认证点 4 行全部退回截顶值 40.0 mm，即**少干了活**（表现为认证矩阵差 31.17 mm）。修好后同一 cap 下矩阵逐位一致（差 0.0 mm）。
+  2. 更根本：真实管线顺序是 特征 → 推理 → 候选 → 认证，**认证点依赖网络输出**，所以"特征用的 q 间隙与认证点间隙合成同一次调用"在实现上做不到。该文件保留作记录，但不能当作可实现收益。
+- **只测可实现的口径**（`docs/experiment_round34_geom_opt.json`；B=1、K=8、commit 2；7 个变体逐轮交替、奇数轮反序，80 轮；等价性两项都 `True`：批量认证矩阵与逐条循环逐位一致、features 复用 xf 前后逐位一致）：
+
+  | 变体 | 含义 | P50 | P95 | P99 |
+  |---|---|---|---|---|
+  | A_today | 现口径 | 33.49 | 46.14 | 64.69 |
+  | B_xf_reuse | `gm_groups` 复用 features 已算的 `cum_xf` | **30.12** | 42.35 | 66.37 |
+  | C_batch_cert | K 条候选的认证点并成 1 次 gaps | 38.05 | 50.17 | 59.86 |
+  | D_both | B + C | 34.87 | 39.81 | 48.26 |
+  | E_both_cont_n8 | B + C + 连续认证 n=8 | 43.73 | 51.08 | 65.68 |
+  | F_worst_loop8 | **最坏情况**：所有候选被拒（今天逐条串行 K 次调用） | 80.22 | 88.44 | 89.55 |
+  | G_worst_batch | 同一最坏情况但并成 1 次调用 | **37.14** | 46.06 | 52.22 |
+
+  - **复用 FK 是无条件收益**：省一次 `cum_xf`（约 3.4–3.7 ms），特征输出逐位一致，已直接实现进 `ml/common/kin_torch.py` 的 `gm_groups(..., xf=)` 与 `ml/common/features.py`（默认行为不变，新参数仅在调用方已算过 xf 时传）。
+  - **批量认证是"典型换尾部"**：常见路径（第一条候选就通过）贵 4.6 ms；但今天一旦前面的候选被拒就要串行调用，实测最坏 **80.2 ms（12.5 Hz）→ 37.1 ms**，P99 64.7→48.3 ms（D vs A）。硬实时看的是最坏情况，所以这条值得做，但要按"典型略变慢、尾部大幅变稳"来汇报，不能只报 P50。
+  - **仍未到 20 ms**：即便 D 档 P50 34.9 ms、P99 48.3 ms。连续认证挂在 D 上是 43.7 ms（E）。所以 GPU 侧下一步只能是更结构性的：认证降 float32（需先批量量化 f32/f64 判据差异，不能凭 3 个点下结论）、把宽相位做成可增量复用的核、或 `torch.compile`/CUDA Graph 把碎 kernel 合批。
+- **等价性闸门（纯效率改动不许改变任何结果）**：
+  - 复用 FK：同一 256 题、同 seed、同配方重跑（`docs/experiment_round34_xf_reuse_check.json`），**22 个指标逐项与轮次 33 base 完全相同**（含 success 0.57421875、time_ok 0.390625、brakes 19.25、speed_ratio_max 1.660003662 等）。整批墙钟 296.3 → 318.0 s，是两次独立运行的差，**不能当作开销结论**：省下的那次 `cum_xf` 只在 B=1 交错实测里量到 −3.4 ms，批量评估里一次调用已覆盖 256 行，摊薄后不足以抵消运行间波动。
+  - 批量认证（`--cert_batch 1`，默认 0 不变）：同一 256 题重跑 **22 项指标与 base 逐项相同**（`docs/experiment_round34_cert_batch_check.json`，success 0.57421875、time_ok 0.390625、speed_ratio_max 1.660003662 等全部一致），整批墙钟 296.3 → 306.9 s（批量口径把 8 次串行调用换成 1 次 K×256 点的大调用，均值略涨符合预期，与 B=1 交错实测方向一致）。合成夹具里也断言两条路径选到同一条候选、同一前缀长度、逐位相同的轨迹与证书。
+- **测试 32→34 项**：`CertBatchEquivalenceTest` 两条（候选 0 前缀不完整 → 选候选 1；所有候选第 2 步都不安全 → 两条路径都停在第 1 步）。写夹具时踩到一个自己的坑：桩里掩码写成 `q[:, :1]` 再 `[:, None]` 变成 3 维，广播出 (4,4,49) 才报"size 16"，是**测试桩错**不是库错——先证形状再改代码。
+
+## 分支清理（2026-10-20）
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。