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. 采集指标

本节记录正式实现使用的命令，而不是建议性伪代码。命令由 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

首轮实现的 Case 边界包含 Benchmark 客户端启动、数据生成、Warm-up、正式测量和退出； 因此它适合判断硬件方向，但不是纯主测量窗口。后续实现需要围绕 Starting main benchmark run 增加更精确的起止 Marker。

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-dcgm Host Engine；首轮 Worker 未启动该服务，所以只有 Head 的 dcgm_dmon.log 有效。

5.4 CPU、进程与 Kernel Launch 侧证据

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

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

# 首轮实际命令：CPU、I/O、缺页、上下文切换，并展开线程
pidstat -durwt -p "<comma-separated-host-pids>" 1

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

首轮 pidstat -durwt 对所有线程做 1 秒采样，产生约 850 MB/735 MB 的 Head/Worker 日志，信息量和扰动都过大。后续不照搬：默认改为进程级 5 秒采样； 只有确认某个进程异常后，才在短窗口内开启线程级采样。

5.5 NUMA 与 CPU/内存亲和

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

# 每 5 秒按容器宿主 PID 查看本地/远端 NUMA 内存
numastat -p <host-pid>

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

NUMA 是多路 CPU 机器的“本地内存”结构。进程长期从远端 NUMA Node 取内存， 或 GPU/NIC 对应的 CPU 线程被调度到另一侧，可能增加 Host 侧延迟。 将 numastat -p 的内存分布与 CPU 核、GPU 活跃区间和 Timeline 对齐， 用于定位跨 NUMA 访问。

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

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

# 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 的实际流量、均衡性和错误增量；Phase 3 再把 NCCL Collective 放到请求 Timeline 中分析持续时间和计算重叠。

5.7 静态快照与结果关系

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

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 未启动而提前退出；本 Run 的 DCGM 分析只使用 Head 数据。
• 当前 Case 时间窗包含客户端准备和 Warm-up；后续使用正式主测量起止 Marker 获得精确硬件窗口。

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 3 将继续定位具体 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 实施记录

返回推理优化主计划