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

当前状态：Phase 2 最终采集代码已完成，等待最终双机复跑。 首次 Run dsv4pro-phase2-20260731-130125 的 8/8 个 benchmark 均成功；提交 30664faa41f8 已补齐正式测量窗口、双节点 DCGM 门禁、 低开销进程采样、机内 PCIe P2P、单/双机 AllReduce 与逐指标自动报告。 本阶段复跑完成并汇报后才进入 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 配置。
• 模型端到端 Case 不启用 Nsight Systems、PyTorch Profiler、NCCL DEBUG 或投机解码；独立通信基线临时启用 NCCL INFO 以保存实际路径证据。
• 不调参，不尝试优化；先获得足以区分瓶颈类别的硬件证据。
• 只重放五个固定代表负载和一组混合 A/B，不重复 Phase 1 全矩阵。
• 采集器从请求开始前启动，到请求结束后停止，不能中途补采后声称完整。

3. 待验证假设

4. 诊断 Run

1. 确认 16 张 GPU 空闲，先跑两节点 PCIe P2P、单机 8 rank AllReduce 和双机 16 rank AllReduce；双机分别测试 NCCL_CROSS_NIC=0/1/2。
2. 保存两节点静态快照：GPU/NIC/NUMA 拓扑、驱动、CUDA、镜像与服务命令。
3. 复用 Phase 1 已验证的 run_quick_map.sh start 启动同配置双机服务。
4. 在 Head 和 Worker 同时启动 GPU、CPU、网卡与 RDMA 采样，先记录 15 秒空闲基线。
5. 依次重放 128K → 1, C=1、32K → 1, C=16 与 1K → 1K, C=32。
6. 重放 1K → 4K, C=16 和 128K → 1K, C=1，观察持续与长上下文 Decode。
7. 重放 1K → 1K, C=32 Control 与 128K Prefill 注入 Treatment，保留相同注入时序。
8. 请求结束后继续采样 15 秒，再停止采集器和服务。
9. 按时间戳将请求、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、 静态快照、采样和清理组成一次完整 Phase 2 Run。

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 内部执行顺序：

配置、工具、DCGM 与 GPU 空闲门禁
  → 通信基线：两节点 P2P、两组单机 8-rank AllReduce、
                三组双机 16-rank NCCL_CROSS_NIC A/B
  → Phase 1 start：启动同配置 TP16 服务
  → 两节点静态快照
  → 启动两节点采集器并记录 15 秒 idle
  → 五个固定 Case
  → 混合 Prefill/Decode A/B
  → 15 秒 cooldown
  → 停止采集器并保存后快照
  → Phase 1 stop：停止 Head/Worker
  → 生成按第 5 节逐项对应的 CSV、JSON 与 report.md

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

5. 采集指标

本节记录正式实现使用的命令，而不是建议性伪代码。命令由 run_hardware_contention_attribution.sh 在 Head 和 Worker 同时启动； 每条展开后的命令会另外保存在 results/<RUN_ID>/head|worker/collector_commands/。

5.1 时间对齐与 Case Marker

# 每条 GPU/RDMA 样本写入相同格式的宿主机墙钟时间
date +%s%N

# 实验前检查两节点秒级时钟差
date +%s

# Case 开始、结束和服务状态由 Python 写入 markers.csv
python3 hardware_contention_attribution.py marker \
  --path markers.csv \
  --node head \
  --event case_start \
  --case-id long_prefill_latency_128k_c1

最终实现由 Phase 1 监听 bench.log 中的 Starting main benchmark run，立刻写入 measurement_start.json；再使用 SGLang bench.json 的正式 benchmark duration 计算结束时间。Phase 2 优先读取 measurement_started_at/measurement_ended_at，不会把数据生成和 Warm-up 混入硬件均值。REQUIRE_PRECISE_WINDOWS=1 时，任何 Case 缺少精确窗口都会让汇总失败，而不是悄悄回退。

5.2 GPU 基础状态：nvidia-smi

nvidia-smi \
  --query-gpu=index,timestamp,utilization.gpu,utilization.memory,\
memory.used,memory.total,power.draw,temperature.gpu,\
clocks.sm,clocks.mem,pstate \
  --format=csv,noheader,nounits

脚本每秒运行一次，并在每行前加入 wall_time_ns 和节点角色。

原始输出为 head|worker/gpu_samples.csv； gpu_summary.csv 汇总整段运行， case_gpu_summary.csv 按节点、Case 和 GPU 汇总平均值与峰值。

5.3 GPU Profiling Counter：DCGM

DCGM_FIELD_IDS=1001,1002,1003,1004,1005,1009,1010

dcgmi dmon \
  -e 1001,1002,1003,1004,1005,1009,1010 \
  -d 1000

sm_active 高而 sm_occupancy 低，表示 SM 经常有工作， 但同时驻留的 Warp 不多；后续通过 Kernel Timeline 区分小 Kernel、 寄存器/共享内存约束和同步。DCGM 是 NVIDIA Data Center GPU Manager： nvidia-dcgm/nv-hostengine 是后台 Host Engine， dcgmi 是客户端，Field ID 是指标编号。最终代码在两节点预检 dcgmi discovery -l，任一 Host Engine 不可用即 fail-fast； 正式结果必须同时包含 Head 和 Worker 的 case_dcgm_summary.csv。

5.4 CPU、进程与 Kernel Launch 侧证据

# 全部逻辑 CPU，每 5 秒输出一次
mpstat -P ALL 5

# 找到容器内进程对应的宿主 PID
docker top <container> -eo pid,ppid,psr,pcpu,pmem,stat,comm,args

# 最终命令：进程级 CPU、I/O、缺页、上下文切换，不展开全部线程
pidstat -durw -p "<comma-separated-host-pids>" 5

# 每 5 秒输出一次硬件/软件计数器增量
perf stat -p "<comma-separated-host-pids>" -I 5000 \
  -e cycles,instructions,cache-misses,context-switches,\
cpu-migrations,page-faults

# mpstat/pidstat/perf 每行都由包装器增加：
# wall_time_ns TAB node TAB 原始输出

最终实现使用进程级 5 秒采样，避免首轮线程级 1 秒采样产生数百 MB 日志。 case_cpu_summary.csv、case_process_summary.csv 和 case_perf_summary.csv 都按正式测量窗口切片；只有先发现异常进程， 才在后续短窗口单独开启线程级采样。

5.5 NUMA 与 CPU/内存亲和

# 静态 NUMA 节点、CPU 和内存布局
numactl --hardware
numastat -m

# 每 5 秒按容器宿主 PID 查看本地/远端 NUMA 内存
numastat -p <host-pid>
# 解析为：
# wall_time_ns,node,node0_mib,node1_mib,total_mib,process_count

# 同时保存 GPU、CPU、NIC 的拓扑关系
nvidia-smi topo -m

NUMA 是多路 CPU 机器的“本地内存”结构。进程长期从远端 NUMA Node 取内存， 或 GPU/NIC 对应的 CPU 线程被调度到另一侧，可能增加 Host 侧延迟。 最终采集器把 numastat -p 解析为 numa_samples.csv，再按正式测量窗口生成 case_numa_summary.csv。这样可以直接比较 Node0/Node1 MiB， 而不是依靠人工阅读不断刷新的文本。

5.6 普通网卡统计与 RDMA 数据面

# Linux netdev 层，每 5 秒采样吞吐与错误
sar -n DEV,EDEV 5

# Case 前后保存物理端口状态和驱动计数器
ethtool eth0
ethtool eth3
ethtool -S eth0
ethtool -S eth3

# RDMA 设备与端口状态
ibdev2netdev
ibstat
rdma link show

sar 记录 Linux 普通网络栈中的 eth0/eth3 流量； GDRDMA 数据量由 mlx5_0/mlx5_3 HCA 的 sysfs Counter 记录：

for hca in mlx5_0 mlx5_3; do
  base="/sys/class/infiniband/${hca}/ports/1"
  cat "${base}/counters/port_xmit_data"
  cat "${base}/counters/port_rcv_data"
  cat "${base}/counters/port_xmit_wait"
  cat "${base}/counters/port_xmit_discards"
  cat "${base}/counters/port_rcv_errors"
  cat "${base}/hw_counters/req_transport_retries_exceeded"
  cat "${base}/hw_counters/req_rnr_retries_exceeded"
done

原始数据为 head|worker/rdma.csv； case_rdma_summary.csv 按 Case、节点和 HCA 计算吞吐及错误增量。 它说明双 Rail 的实际流量、均衡性和错误增量； case_netdev_summary.csv 同时保留 Linux netdev 层的 eth0/eth3 RX/TX 与错误。Phase 3 再把 NCCL Collective 放到请求 Timeline 中分析持续时间和计算重叠。

5.7 机内 PCIe 与 NCCL 通信基线

# 由 all 入口自动执行；不需要用户手工运行 torchrun
# 每个节点：所有 GPU 源/目标对，FP16 256 MiB CUDA P2P copy
python3 communication_baseline.py p2p \
  --size 256M --warmup 3 --iterations 10

# 每个节点：8 rank NCCL AllReduce
torchrun --standalone --nproc-per-node=8 \
  communication_baseline.py all-reduce \
  --sizes 1M,64M,1G --repetitions 3 --warmup 5 --iterations 10

# 双节点：16 rank；分别设置 NCCL_CROSS_NIC=0、1、2
torchrun --nnodes=2 --nproc-per-node=8 \
  --master-addr 10.101.0.11 --node-rank <0-or-1> \
  communication_baseline.py all-reduce \
  --sizes 1M,64M,1G --repetitions 3 --warmup 5 --iterations 10

P2P 结果按 same_pcie_switch（PIX）和 cross_numa_sys（SYS）分别汇总，不用一个平均值掩盖跨 CPU 路径。 AllReduce 同时报告 P50/P95 latency、algbw、 busbw、正确性错误数和实际 NCCL 路径。1 MiB、64 MiB、1 GiB 分别覆盖小消息延迟、中等消息和大消息带宽；双机 A/B 直接给出 NCCL_CROSS_NIC=0/1/2 的数值比较。

5.8 静态快照与结果关系

nvidia-smi
nvidia-smi topo -m
lscpu
numactl --hardware
ip -details link show eth0
ip -details link show eth3
docker inspect <container>
docker top <container> -eo pid,ppid,psr,pcpu,pmem,stat,comm,args

5.9 最终结果如何逐项汇报

最终 report.md 的章节顺序与本节一一对应。每一项必须同时给出 原始文件、有效样本数、Head/Worker 数值、Case 间变化和解释； 不能只写“GPU 较忙”“网络未饱和”这类抽象结论。

某个采集器无数据时报告显示 - 并附失败状态，不会把缺失值写成 0。正式 Run 默认 ALLOW_PARTIAL_COLLECTORS=0， 因此必需采集器提前退出会让 Run 失败。

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
  communication/
    p2p_head.log
    p2p_worker.log
    allreduce_head_8gpu.log
    allreduce_worker_8gpu.log
    allreduce_two_node_x0.log
    allreduce_two_node_x1.log
    allreduce_two_node_x2.log
  head/
    gpu_samples.csv
    dcgm_dmon.log
    mpstat.log
    pidstat.log
    sar_net.log
    perf_stat.log
    docker_top.log
    numa_samples.csv
    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
  communication_summary.csv
  communication_aggregate.csv
  case_gpu_summary.csv
  case_gpu_node_summary.csv
  case_dcgm_summary.csv
  case_cpu_summary.csv
  case_process_summary.csv
  case_perf_summary.csv
  case_numa_summary.csv
  case_netdev_summary.csv
  case_rdma_summary.csv
  summary.json
  report.md

8. 验收结果

• 最终代码固定到提交 30664faa41f8；Shell 语法检查和三个 Python 文件编译通过。
• Phase 1 精确窗口 4/4 单元测试通过；Phase 2 采集、解析与通信聚合 8/8 单元测试通过。
• 完整 Dry-run 不启动服务即可展开全部模型、采集和通信命令；通信子流程生成 2 个 P2P、2 个单机 AllReduce、6 个双机 rank 命令。
• 最终代码默认要求精确测量窗口、两端 DCGM 可用和全部必需采集器存活，缺失时 fail-closed。
• 首次 Run 的性能数据保留在第 10 节；最终代码尚未在 16 卡上复跑，因此新通信基线和逐指标表暂不填写虚构数值。

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 卡间通信路径

最终代码使用当前 SGLang 镜像内的 PyTorch/CUDA/NCCL 实现等价微基准： 两节点 P2P 全矩阵、两组单机 8-rank AllReduce 和三组双机 16-rank NCCL_CROSS_NIC A/B。结果统一写入 communication_summary.csv 与 communication_aggregate.csv； 完成 Phase 2 后，后续阶段不重复跑这些微基准。

10.5 首轮结论与最终代码修正

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

• Worker DCGM 缺失已改为双节点启动前门禁；最终 Run 不再接受单边 DCGM 数据。
• 宽泛 Case 窗口已改为正式 benchmark 起点加 duration 的精确窗口，并由 REQUIRE_PRECISE_WINDOWS=1 强制执行。
• pidstat/mpstat/perf/sar/numastat 已改为进程级 5 秒采样，保留时间戳并降低诊断扰动。
• 最终 report.md 已按第 5 节逐项输出数值表；缺失采集显示为 -，不会解释为 0。
• 完整归因见 analysis.md，原始结构化摘要和两端 NCCL 证据已一并归档。

返回 Phase 1 实施记录

返回推理优化主计划