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_ncclisend 内（懒加载 2-rank NCCL communicator 创建自旋，102% CPU） - PP1_TP0 停在
request_receiver.py:142 _pull_raw_reqs的 GLOOpoint_to_point_pyobjirecv - 根因：通道断裂——请求中继的发送端在 mixin 里（已切 NCCL），接收端却在
scheduler_components/request_receiver.py（补丁树之外，仍走 GLOO），两端永不相遇。全库仅 2 个point_to_point_pyobj使用者，无第三者顺序风险。
r36 修复（request_receiver_degloo.py，第 8 个挂载文件）：
_pull_raw_reqsp2p 分支（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）。
风险与遗留显式记录
- async-IMA 竞态未根治：sanitizer 路线不可行（见上），r36 全部验证在 SYNC_MASK=127 掩码下通过。 动掩码/改流拓扑/图化任一变动都可能重新暴露，动前必须重跑全套稳定性门。
- PP+MTP 的兑现条件（后续若再战）：verify-step 需压到 <148ms（现 235@cc16/148@cc8）——图捕获修复（Phase4 深水区） 是最大单点杠杆；否则 MTP 在 PP 内为净负收益，不如 B（TP4PP2 nomtp）。
- A16 三参数口径（MRR32 + cuda-graph-max-bs-decode 16 + bs 4/8/12/16）已从档案找回并用于恢复部署。