# GLM-5.3-NVFP4 (Pro6000D×8) SGLang TP4PP2 Torch-Profiler Profile 与优化方向

- 日期：2026-09-06　机器：174.1.60.5（8×RTX 6000D 85.6GB, SM120, PCIe Gen5, 无 NVLink）
- 完整报告：`D:\sskj\reports\GLM53_TP4PP2_Profile与优化方向_2026-09-06.md`（结论、排名表、NCCL 验证实验全在该文件）
- 上游依据：09-05 并行方案对比（TP8 / TP4PP2 / EP8 / DP）确认 TP4PP2 为最优配置

## 目的

对获胜配置 TP4PP2 做 prefill / decode / 128k 前缀命中三场景 torch profiler 采集，
量化 kernel 热点、PP 流水线气泡、NCCL 通信占比、CPU 调度空隙，产出优化方向排序；
并用对照实验检验 profile 提出的第一假设（NCCL LL 协议误选）。

## 部署（与 09-05 获胜配置逐字一致）

```
bash /root/deploy_par.sh "--tp 4 --pp-size 2 --disable-overlap-schedule --max-prefill-tokens 16384" nomtp
```

镜像 `lmsysorg/sglang:nightly-dev-20260828-daf63171`；容器 glm53-nvfp4:30000；
KV fp8_e4m3 自动；SM120 三件套（`--disable-shared-experts-fusion --moe-runner-backend flashinfer_cutlass --disable-flashinfer-autotune`）；
hicache-ratio 3；mem-frac 0.88；chunked-prefill 8192。忠实性：干净复测 cc16 16k/512
输出 104.7 tok/s / TPOT 50.87ms，与 09-05 基准（103.3 / 55.4）一致。

## 采集协议

| 场景 | 负载 | 说明 |
|---|---|---|
| A prefill | 16×(16384→1) cc16 | ~34 个 8192-token chunk 前向 |
| B decode | 16×(16384→512) cc16 | TTFT 过后 arm 60 步 |
| D 128k/90% | 8×131072 cc8 | 共享前缀 117968；后缀 prefill 窗口 arm 16 前向 |
| E 协议对照 | 16k probe ×2 前向 | NCCL_PROTO=Simple 变体下的 AR kernel 取证 |

- `POST /start_profile`，CPU+GPU activities，无 stack；采集前 flush + 微量预热 + 再 flush；bench 每轮换 seed
- **with_stack 在本 nightly 病态（两次复现：16k 直接 OOM 僵尸；2k probe flush 挂死）——禁用**

## 关键结论（详见报告）

1. **PP 气泡证伪**：chunked prefill 形成天然微批流水，两 stage 同忙 96.0%，经典气泡仅 ~4%
2. **prefill 墙 = PP0 链路**：计算 22.8s(65%) + TP4 AR 10.4s(30%)，35.2s 墙钟
3. **AR 已近带宽极限**：96MB/3.7ms ⇒ busbw≈39GB/s ≈ PCIe Gen5 实际峰值 ~75%；"_RING_LL" 内核名是 NCCL 2.28 混合 plan 命名，非半带宽 LL 线格式
4. **NCCL_PROTO 强制实验证伪快赢**：docker `-e` 到不了 rank 进程（sglang worker spawn 丢弃 NCCL env），AR p50 3.69→3.70ms 不变，e2e 噪声内
5. **decode**：步长 21-26ms（MoE GEMM 35% + SendRecv 18%），无 MTP；PP1 AllGather 273 次不在 cuda graph 内
6. **128k/90%**：DSA indexer `sm120_fp8_mqa_logits` 占 28%（PP0）/23%（PP1），是其服务的稀疏注意力本体（17%）的 1.6×；后缀有效速率 5.2k tok/s
7. **profiler 工程发现**：flush 阻塞全流水线 11s；带 profiler 的 bench 指标作废

## 第二轮优化实验（2026-09-07）：配置级方向全部证伪

详见 `results/analysis/optimization_round2_findings.md`。干净 128k/90% 基线补测（TTFT p50 14.70s / TPOT 51.7ms）；
chunk 16384 因 MoE 工作区 OOM（3.08GB > 2.11GB 空闲）证伪且收益主体不存在（AR 带宽受限、indexer 功不变）；
AR 现成开关扫描全部不适用（quant-comm=NPU、AR 融合=SM90/100 门控、symm-mem/NVLS=NVLink 向）；
indexer 28% 属 DSA 算法固有成本（无复用机会、SM120 仅 deepgemm、模型已做 index_topk_freq=4 跨层共享）。
**结论：现有配置即本栈配置最优；剩余提升均为开发投入（PP+MTP > AR 重叠/量化内核）。**

## 优化方向（排序见报告 §4，09-07 更新）

① prefill AR 通信-计算重叠 / 量化 AR（协议红利已排除）；② PP+MTP（decode 最大杠杆）；
③ 128k 场景 DSA indexer 前缀复用/调优；④ chunk 8192→16384 重测；⑤ MoE 胶水融合 + PP1 AG 入图；⑥ decode 尾部。

## 目录

```
scripts/   deploy_par_605.sh（部署）、profile_cap.sh（A/B/C 编排）、run_phase2.sh（冒烟+干净bench+D+C）、
           bench_128k_hit90_prof.py（D 驱动+arm）、probe_c*.py（小探针）、
           pp_align.py（跨rank墙钟对齐+分箱）、nccl_forensics.py / nccl_names.py（NCCL 取证）、census.py（事件普查）
results/   analysis/（pp_align/triage/forensics/census 输出）、bench/（干净 bench 与采集期 bench 日志）、ops/（部署与采集日志）
```

trace 原始文件（体积大，不入库）：`60.5:/data/hf_models/pp2tp4_profiles/{A_prefill,B_decode,D_128k,E_nccl_simple}/`
（8 rank × 4 场景；A 的 PP0 ~70-77MB gz，其余 ~2-9.5MB）。

## 复现

1. `bash scripts/deploy_par_605.sh "<同上参数>" nomtp`（60.5 上原路径 /root/deploy_par.sh）
2. 等 /health=200，GSM8K 冒烟
3. `bash scripts/profile_cap.sh`（A/B）；`python3 scripts/bench_128k_hit90_prof.py --concurrency 8 --num-requests 8 --run-id <新> --arm-profile <dir> --profile-steps 16`（D）
4. `python3 scripts/pp_align.py <trace_dir>`；`python3 scripts/nccl_forensics.py <trace>`；`python3 scripts/nccl_names.py <trace>`
5. triage 三表用 zcode skill `llm-torch-profiler-analysis` 的 analyze 脚本（docker cp 进容器跑）

## 事后状态

60.5 当前运行原样 TP4PP2（glm53-nvfp4:30000）。恢复 GLM-5.3-Flash kt：
`bash /root/deploy_glm53_flash_kt_gpu_graphs.sh`（先 kill -9 本容器 sglang 进程并等显存归零）。