Phase 2：DeepSeek-V4-Pro 双机 Pro6000D SGLang 硬件与资源竞争归因

当前状态：Phase 2 首次正式双机 Run 已完成。 Run dsv4pro-phase2-20260731-130125 在 26 分 26 秒内完成 8/8 个 benchmark，无 OOM；GPU、CPU 和双 Rail RDMA 数据已完成首轮归因。 本阶段在此停止，不自动进入 Phase 3。

1. Phase 1 交接结果

最终基线已由 Head 与 Worker 日志证明使用 mlx5_0/mlx5_3 双 Rail NET/IB + GDRDMA， 正式测量请求为冷 Prefix。正式矩阵 12/12、长 Decode 补测 2/2 均成功。 Phase 2 保持相同服务配置和请求口径。

2. 本阶段的边界

• 只测试 SGLang，不测试 vLLM。
• 保留模型、镜像、TP16、EP2、显存比例和已验证的双 Rail NCCL 配置。
• 不启用 Nsight Systems、PyTorch Profiler、NCCL DEBUG 或投机解码。
• 不调参，不尝试优化；先获得足以区分瓶颈类别的硬件证据。
• 只重放五个固定代表负载和一组混合 A/B，不重复 Phase 1 全矩阵。
• 采集器从请求开始前启动，到请求结束后停止，不能中途补采后声称完整。

3. 待验证假设

4. 诊断 Run

1. 保存两节点静态快照：GPU/NIC/NUMA 拓扑、驱动、CUDA、镜像与服务命令。
2. 复用 Phase 1 已验证的 run_quick_map.sh start 启动同配置双机服务。
3. 在 Head 和 Worker 同时启动 GPU、CPU、网卡与 RDMA 采样，先记录 15 秒空闲基线。
4. 依次重放 128K → 1, C=1、32K → 1, C=16 与 1K → 1K, C=32。
5. 重放 1K → 4K, C=16 和 128K → 1K, C=1，观察持续与长上下文 Decode。
6. 重放 1K → 1K, C=32 Control 与 128K Prefill 注入 Treatment，保留相同注入时序。
7. 请求结束后继续采样 15 秒，再停止采集器和服务。
8. 按时间戳将请求、GPU、CPU 和双 Rail 指标对齐，生成摘要与判定。

idle 15s
  │ 128K→1 C1 │ 32K→1 C16 │ 1K→1K C32
  │ 1K→4K C16 │ 128K→1K C1
  │ Decode Control │ Decode + Prefill
cooldown 15s

Head 与 Worker 的所有采集器覆盖完整诊断窗口。

Phase 1 中服务加载约 5 分 30 秒；五个固定负载加混合 A/B、静态快照、 采样和清理，目标仍控制在约 30 分钟内。

4.1 你只需要运行的入口

操作规则：先在 Worker .7 做一次 DCGM 准备，再只在 Head .5 执行 Phase 2 的 all。 不要手工执行 Phase 1 的 start 或 stop。 Phase 2 会在内部复用它们，并负责异常退出时的采集器、Head、Worker 清理。

# [仅在 Worker 174.1.51.7 执行一次]
# 不需要 source、conda activate，也不要在 .7 运行 Phase 2 的 all
systemctl start nvidia-dcgm
systemctl is-active nvidia-dcgm
dcgmi discovery -l

# 预期：第二条输出 active，第三条列出本机 8 张 GPU

# [以下仅在 Head 174.1.51.5 执行]
cd /data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_hardware_contention_attribution

# 第一次先展开全部命令，不启动服务、不占用 GPU、不发送请求
DRY_RUN=1 RUN_ID=dsv4pro-phase2-dryrun-$(date +%Y%m%d-%H%M%S) \
  bash run_hardware_contention_attribution.sh all

# 正式实验：仍然只有同一个 all 入口，tmux 只负责断线后继续运行
RUN_ID=dsv4pro-phase2-$(date +%Y%m%d-%H%M%S)
tmux new-session -d -s dsv4pro-phase2 \
  "RUN_ID=${RUN_ID} bash run_hardware_contention_attribution.sh all \
   2>&1 | tee /data/hzy/${RUN_ID}.log"

tmux attach -t dsv4pro-phase2

.7 的三条命令只负责让 Worker DCGM Host Engine 可用； SGLang Worker、其余采集器和结果回收仍由 .5 的唯一入口通过 SSH 管理。 若需要机器重启后自动启动 DCGM，应由运维另行决定是否执行 systemctl enable nvidia-dcgm。

all 内部执行顺序：

配置与工具门禁
  → Phase 1 start：启动同配置 TP16 服务
  → 两节点静态快照
  → 启动两节点采集器并记录 15 秒 idle
  → 五个固定 Case
  → 混合 Prefill/Decode A/B
  → 15 秒 cooldown
  → 停止采集器并保存后快照
  → Phase 1 stop：停止 Head/Worker
  → 生成按 Case 对齐的 CSV、JSON 与 report.md

Phase 1 的作用是提供已经验证过的双机 Docker 服务和 Benchmark 实现， 不是第二个用户入口。实际展开的服务、Benchmark 和采集命令都会写入 results/<RUN_ID>/service/、commands/ 和 head|worker/collector_commands/，不依赖跨文档猜测。

5. 采集指标

6. 精简代码设计

已新增目录：

/data/hzy/sskj/experiments/pro6000/
dsv4pro_pro6000d_2node_sglang_hardware_contention_attribution/

Phase 2 不复制双机 Docker 启停实现。唯一入口在内部调用 Phase 1 的 run_quick_map.sh start/fixed/mixed/stop，只新增硬件采集、时间对齐和代表负载编排。 顶层仍只保留一个 Shell 文件，不创建额外 tmux、launch、start 或 stop 脚本。

7. 结果结构

results/<RUN_ID>/
  manifest.json
  run.log
  bench/
    bench_cmd.txt
    bench.log
    bench.jsonl
  service/
    head_server_cmd.txt
    worker_server_cmd.txt
    head_server.log
    worker_server.log
  head/
    gpu_samples.csv
    dcgm_dmon.log
    mpstat.log
    pidstat.log
    sar_net.log
    perf_stat.log
    docker_top.log
    numastat.log
    rdma.csv
    static_before.log
    static_after.log
    collector_commands/
  worker/
    ...
  collector_status.csv
  markers.csv
  bench_summary.csv
  gpu_summary.csv
  rdma_summary.csv
  case_windows.csv
  case_gpu_summary.csv
  case_rdma_summary.csv
  summary.json
  report.md

8. 验收结果

• 五个固定负载和混合 A/B 共 8 行全部成功，口径与 Phase 1 一致。
• Head/Worker GPU、CPU、NUMA、RDMA 采集完成，Case 时间窗和结构化摘要已生成。
• 两端 NCCL 日志确认 mlx5_0/mlx5_3 双 Rail NET/IB + GDRDMA。
• 服务和采集器完成清理，两节点 16 张 GPU 均已释放。
• Worker DCGM 因宿主 nvidia-dcgm 未启动而提前退出；Head DCGM 有效，但本 Run 不能做双节点 DCGM 对称比较。
• 当前 Case 时间窗包含客户端准备和 Warm-up，硬件均值可用于方向判断，但不能替代精确的主测量窗口或 Phase 3 Timeline。

9. 实施记录

10. 真机结果

Run：dsv4pro-phase2-20260731-130125，状态 COMPLETED。运行时间为 13:01:25 至 13:27:51 CST， 8 个结果全部成功，0 个失败。正式入口仅在 174.1.51.5 执行； Worker 服务和采集器由脚本通过 SSH 自动启动。

cd /data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_hardware_contention_attribution

RUN_ID=dsv4pro-phase2-20260731-130125
tmux new-session -d -s dsv4pro-phase2 \
  "RUN_ID=${RUN_ID} bash run_hardware_contention_attribution.sh all \
   2>&1 | tee /data/hzy/${RUN_ID}.log"

10.1 代表负载

10.2 混合 Prefill/Decode

这再次证明 Prefill 会明显干扰正在进行的 Decode。ITL P95 仍约为 62 ms，并不与 TPOT 恶化矛盾：少量同步长停顿可能不足全部 token 间隔的 5%， 因而会被全局 token 级 ITL P95 隐藏，而请求级 TPOT 和 E2E 会暴露它。

10.3 GPU、CPU 与通信

• 128K Prefill 注入窗口两节点平均 GPU 利用率为 99.78% / 99.34%，平均功耗约 274 W；频率稳定在约 2.38–2.41 GHz，没有频率塌陷证据。
• 显存稳定在每卡约 83.2–83.4 GiB / 85,651 MiB，只剩约 2.3 GiB 余量。
• 整机 CPU 平均约 8%–11%，I/O Wait 为 0；但注入窗口仍有 5/4 个 Head/Worker 核平均超过 80%，单线程调度或 NUMA 热点尚未排除。
• 两条 RDMA Rail 流量几乎对称，所有采集到的错误增量均为 0。最高负载为 32K → 1, C=16：Head/Worker 总发送约 140.0/139.3 Gbit/s，即每条 400G Rail 约 70 Gbit/s。
• 因此原始 RoCE 带宽没有饱和；但 TP16 collective 的延迟、调度和 Rank 同步开销仍需 Timeline 才能拆开。

10.4 卡间通信路径

在进入 Phase 3 前只需一次性补 p2pBandwidthLatencyTest、单机 8 卡 all_reduce_perf 和双机 16 卡 all_reduce_perf， 分开量化机内 PCIe 与跨机 RoCE 的硬件基线；后续阶段不重复跑这些微基准。

10.5 首轮结论与采集限制

当前证据支持把下一步缩到 TP16 的 Kernel、Scheduler、PCIe/RDMA Collective 和 Rank 同步时间线。Phase 3 只分析真实请求中通信出现的位置、耗时和与计算的 重叠关系，不重复 Phase 2 的平均 GPU/CPU/RDMA 采集。原始双 Rail 带宽、整机 CPU 容量和降频都不像首要瓶颈；但 Phase 2 粗粒度指标还不能给出具体 Kernel 根因。

• Worker 的 nvidia-dcgm Host Engine 未启动，导致 Worker DCGM 提前退出。重跑前只需在 .7 启动 DCGM；整套 Phase 2 仍只在 .5 执行。
• 当前 Case 时间窗包含客户端启动、数据准备、Warm-up 和退出，硬件平均值被非正式测量阶段稀释；后续要增加主 benchmark 精确起止标记。
• pidstat -durwt 一秒采样生成约 850/735 MB 日志；后续改为进程级或 5 秒采样，减少诊断扰动。
• 完整归因见 analysis.md，原始结构化摘要和两端 NCCL 证据已一并归档。

返回 Phase 1 实施记录

返回推理优化主计划