# GLM-5.3-NVFP4 PP+MTP r36（去边界 GLOO）修复与判决 — 2026-09-08 @174.1.60.8

接续 `glm53_nvfp4_i8k_o1k_c16_bench`（A16/B 基线）与 r33 PP+MTP 深挖（ppmtp_deepdive）。
目标：修复自研 TP4PP2+MTP 补丁并让 MTP 与 PP 双优势同时兑现；判负则 60.8 恢复 A16 在役。

## 结论速览

| 判决项 | 结果 |
|---|---|
| 去 GLOO（r36） | **成立**：稳定（conc_test×3 + cc16 杀手×2 零崩溃、可复现 ±1%），prefill 密集档 8×16384 **-22%**（46.2→36.0s） |
| i8k/o1024/cc16/nreq32 判决（PG19 语料） | **PP+MTP 判负**：e2e P50 **111.2/116.3s** vs B' 同栈对照 **61.5/61.6s**（≡B 基线 61.8s）vs A16 66.2s，**差 1.81×**，双门未过 |
| 缺口归属 | **100% 属 MTP 机制**（B' 在同一 r36 栈上完美复现 B 基线，栈本身零回退）；verify-step ~235ms@cc16 / ~148ms@cc8，break-even 需 <148ms（=52ms×accept2.85） |
| Phase4 图模式（r36g） | **正确性灾难，判死**：`cuda graph: True` 生效但 accept **2.85→1.05**（接受率 0.02）、GSM8K 输出数字噪声（draft+verify 双坏）。**FORCE_EAGER 双开关是承重墙**，非性能旋钮 |
| sanitizer 根治路线 | **不可行**：320 错误全为 NCCL 探测噪声（error 209）；真死因=memcheck 开销 ~10GB/卡 吃掉 0.88 的 KV 余量（最低可行 memfrac 0.959，复现条件被破坏）。沿用 mask=127（4.9ms/轮）+ 实证稳定性，风险显式记录 |
| 在役状态 | **A16 已恢复**（TP8 EAGLE 4/1/5@0.90 + MRR32 + graph bs 4/8/12/16，restart=unless-stopped） |

## r35→r36：一次死锁与一次修复（本次核心工程产出）

**r35**（scheduler_pp_mixin_r35.py，r33 fb8c96f7 基础上去 GLOO）：
- dict 通道元数据：`send_object`（2 条 GLOO/字典 × 3 字典/轮）→ **8KB 固定尺寸 NCCL uint8 缓冲**（pickle 零填充，`pickle.loads` 天然忽略 STOP 后字节——已验证）；CPU 张量随车 GPU 化 + `__pp_cpu_keys__` 回填。
- pyobj 通道（请求中继/控制面）：GLOO 阻塞 `dist.send` → **两段式 NCCL**（int64 size + uint8 payload，空载优化 size=0），走 `world_group.device_group`（与 dict 通道的 pp_group 通信器隔离，FIFO 不串扰）。
- `_pp_nccl_stage_guard`：fill-event 门 + 双流 record_stream（r33 实证：isend 内核跑在调度器 ambient 流而非 send_stream，guard 必须在 isend 入队前）。
- 修掉两处自捕 bug：guard 原在 isend 之后（无效门控）→ 重排；`P2PWork` 须钉住实际发送对象（contiguous() 副本）。

**r35 首部署死锁**（py-spy 双端定格）：
- PP0_TP0 卡在 `_pp_send_pyobj_nccl` isend 内（懒加载 2-rank NCCL communicator 创建自旋，102% CPU）
- PP1_TP0 停在 `request_receiver.py:142 _pull_raw_reqs` 的 GLOO `point_to_point_pyobj` irecv
- **根因：通道断裂**——请求中继的发送端在 mixin 里（已切 NCCL），接收端却在 `scheduler_components/request_receiver.py`（补丁树之外，仍走 GLOO），两端永不相遇。全库仅 2 个 `point_to_point_pyobj` 使用者，无第三者顺序风险。

**r36 修复**（request_receiver_degloo.py，第 8 个挂载文件）：
- `_pull_raw_reqs` p2p 分支（pp_rank≠0 且 attn_tp/cp_rank==0）同步切两段式 NCCL 接收，与发送端同通道同 FIFO 语义（含空载 size=0 锁步）。
- `SGLANG_PP_DEGLOO` 门控，=0 整体回退 r33 GLOO 行为。
- 部署即刻通过：健康 380s（与 r33 完全一致）、池 384,960、冒烟 ALL-OK、accept 2.09-3.54。

## 判决数据（i8k/o1024/cc16/nreq32，PG19 真实语料，温度0，warm+2）

| 配置 | run | e2e P50 | out tok/s | TPOT P50 | TTFT P50 | accept | retract |
|---|---|---|---|---|---|---|---|
| PP+MTP r36 | 9402 | 111.2s | 136.0 | 105.2ms | 4.09s | 2.873 | 0 |
| PP+MTP r36 | 9403 | 116.3s | 133.6 | 106.5ms | 4.07s | 2.842 | 0 |
| B'（同栈 nomtp） | 9405 | **61.5s** | **266.7** | 51.4ms | 9.24s | — | 0 |
| B'（同栈 nomtp） | 9406 | **61.6s** | **265.7** | 51.8ms | 9.29s | — | 0 |
| （参照）B 基线 | 09-08 上午 | 61.8s | 264.9 | 50.3ms | — | — | 0 |
| （参照）A16 基线 | 09-08 上午 | 66.2s | 218.9 | 55ms | 4.0s | 2.50 | 7/7 |

语料窗口：PP+MTP [19,662,144, 20,448,576)、B' [20,448,576, 21,235,008)，各 3×262,144（=warm+2，i8k 全唯一 prompt 窗口=32×8192）。
消耗至 **21,235,008 / 21,296,780**（余 61,772，无复测余量，复测须换语料）。run-id 9401-9406（9401/9404 为 warm，不入判决）。
缓存纪律验证：两配置 hit_rate=0.0（窗口互不重叠、radix 干净）。

**MTP 增量拆解**：稳态 16 并发 decode 190 tok/s → per-req 11.9 tok/s → step≈239ms；8 并发段 step≈148ms（≈A16 的 137ms）。
步长随批超线性 + spec 每轮 4 次 forward（3 draft + 1 verify，全 eager）+ 边界中继 → 2.85× 放大率不敌 4.5× 步长。MTP 在本栈 cc16 为**净负收益 1.59×**。

## cc16 杀手 profile（16×16384/512 random-ids，历史竞态触发器，语料免费）

| 配置 | 种子 | wall | out tok/s | E2E 中位 | TPOT 中位 | accept |
|---|---|---|---|---|---|---|
| r36 eager | 6402 | 105.3s | 77.8 | 72.2s | 72.5ms | 3.76 |
| r36 eager | 6403 | 106.0s | 77.3 | 72.6s | 73.1ms | 3.69 |

零崩溃、±1% 可复现（SYNC_MASK=127 掩码下；历史 SYNC_MASK=0 会触发 async-IMA 的同一 profile）。
注意：random-ids 的 accept 3.7+ 相对真实语料 2.85 虚高，与既有结论一致。

## Phase4 图模式判决（r36g = r36 + FORCE_EAGER_DRAFT/VERIFY=0）

- `cuda graph: True` 确认生效；conc_test ALL-OK 但 **accept len 1.05-1.11 / 接受率 0.02-0.04**（draft 提议几乎全灭）
- 质量门：GSM8K-1 输出即数字噪声 → **verify 图同样损坏**（非仅 draft）
- r33 注释"draft-decode cuda-graph capture issues on PP stages"实证为 draft+verify 双重捕获缺陷
- **修复方向**（未来工程）：按 cudagraph×spec 冲突清单（桶形状/地址预分配/host 控制流等 8 类）做预分配补丁 + 图外 canary，非配置级可解

## 文件清单（md5）

| 文件 | md5 |
|---|---|
| patches/scheduler_pp_mixin_r35.py | efce72af34b2e59f20d2eb0874f9f2b2 |
| patches/request_receiver_degloo.py | ad6c978a3e1efea395ec3d537a4fedd8 |
| scripts/deploy_ppmtp_r35.sh | 86fb4b576fb04eef7b71628324796ab7 |
| scripts/deploy_ppmtp_r36.sh | 7b80f4af0debccef8e87df4a2532d8dc |
| scripts/deploy_ppmtp_r36g.sh | dca9dd387a5e980dc81e25590b895646 |
| scripts/deploy_ppmtp_sanitize.sh | 5bb5a7dfaf00569d5408e487267129a6 |
| scripts/killer_cc16.sh | ac3dda7e05b416aecf1da978325e2584 |
| patches/request_receiver_orig_0901.py | vanilla 参考（镜像原版） |

results/bench_logs/：9401-9406 六轮语料 SUMMARY、killer s6402/6403、质量门 r36（7/7）/r36g（灾难证据）、
四个部署日志、san_crash_prehealth_s6401.log（290K，sanitizer 不可行的完整证据链：320×error209 噪声 + KV OOM 死因）。

60.8 服务器侧资产：/root/scheduler_pp_mixin_r35.py、request_receiver_degloo.py、deploy_ppmtp_r35/36/36g.sh、
sglang_patch2/（r33 七件套不动）、corpus_ids.json（消耗至 21,235,008）。

## 风险与遗留显式记录

1. **async-IMA 竞态未根治**：sanitizer 路线不可行（见上），r36 全部验证在 SYNC_MASK=127 掩码下通过。
   动掩码/改流拓扑/图化任一变动都可能重新暴露，动前必须重跑全套稳定性门。
2. **PP+MTP 的兑现条件**（后续若再战）：verify-step 需压到 <148ms（现 235@cc16/148@cc8）——图捕获修复（Phase4 深水区）
   是最大单点杠杆；否则 MTP 在 PP 内为净负收益，不如 B（TP4PP2 nomtp）。
3. A16 三参数口径（MRR32 + cuda-graph-max-bs-decode 16 + bs 4/8/12/16）已从档案找回并用于恢复部署。