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

当前状态：Phase 2 代码已实现，静态检查、5 项单元测试与本地 Dry-run 已通过。 尚未启动双机模型服务或正式采集 GPU 数据。真机运行后，本页只保留成功 Run 的 Run ID、命令、结果与结论。

1. Phase 1 交接结果

代表负载	关键结果	Phase 2 用途
128K → 1，C=1	Input TPS 2,710.16；TTFT P95 48.344 s	纯长 Prefill 的计算、显存与通信归因
32K → 1，C=16	Input TPS 3,112.77；TTFT P95 162.087 s	并发 Prefill 的排队、Chunk 调度与节点均衡
1K → 1K，C=32	Output TPS 461.68；TPOT P95 63.31 ms	普通 Decode 的 GPU、CPU 与通信基线
1K → 4K，C=16	Output TPS 310.02；TPOT P95 50.33 ms	持续 Decode、KV 增长和稳态资源占用
128K → 1K，C=1	TTFT P95 49.326 s；TPOT P95 32.24 ms	分离长 Prefill 与长上下文 Decode 成本
1K → 1K，C=32 + 128K 注入	Output TPS -24.08%；TPOT P95 +66.55%	Prefill 干扰 Decode 时的硬件资源竞争

最终基线已由 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. 待验证假设

假设	预期硬件表现	后续方向
DSV4/NSA Prefill Kernel 计算受限	GPU 持续忙、高功耗和稳定频率；双 Rail 流量不高	Phase 3 捕获 Kernel 与 Attention/Indexer 时间线
权重或激活显存带宽受限	GPU Memory Utilization 高，SM 指标未必饱和；功耗可能低于纯计算	补 DCGM/Profiler 的 DRAM Active，再看 Kernel
TP16 跨机通信受限	RoCE 吞吐高或两条 Rail 明显失衡，GPU 出现等待	NCCL_CROSS_NIC 0/1/2 快速 A/B，随后看 NCCL Timeline
CPU Scheduler 或 Kernel Launch 受限	GPU 利用率锯齿或有空洞，单 CPU 核持续满载	定位 Scheduler/Tokenizer 线程与 launch gap
频率、功耗或温度限制	P-state、SM Clock 或 Power 持续异常，可能出现节流原因	修正电源、散热或 Clock Policy 后复测
节点或 Rank 不均衡	两节点或不同 GPU 的利用率、功耗、网络流量存在固定偏差	检查 NUMA、GPU-NIC 亲和与慢 Rank

4. 诊断 Run

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

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

# [仅在 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

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

层级	连续采样	静态或前后快照	局限
GPU	利用率、Memory Utilization、显存、功耗、SM/Memory Clock、温度、P-state	`nvidia-smi topo -m`、Compute Process	`nvidia-smi` 的 Memory Utilization 不是实际 HBM GB/s
CPU	每核利用率、上下文切换、服务进程 CPU/内存	NUMA 拓扑、容器 PID 与 CPU Affinity	需要时间戳与 GPU Chunk 日志对齐
Network	`eth0/eth3` RX/TX	`ethtool -S` 错误计数前后差	普通 netdev 统计不一定覆盖所有 RDMA 细节
RDMA	`mlx5_0/mlx5_3` port_xmit/recv_data 差分	Port State、GID 与错误计数	计数单位需要按设备定义换算
DCGM	若可用则记录 SM Active、DRAM Active、Tensor Active、PCIe	工具版本与可用 Field	不可用时明确记录，不能用粗粒度指标冒充

6. 精简代码设计

已新增目录：

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

文件	职责	当前状态
`run_hardware_contention_attribution.sh`	唯一 Shell 入口；服务启停、双节点采集器、Case 编排、健康检查和 Trap 清理	已实现
`config.env`	Phase 1 相对路径、节点、五个固定 Case、混合 A/B 与采样策略	已实现
`hardware_contention_attribution.py`	Manifest、标记、Bench 校验、按 Case 时间窗切片和硬件摘要	已实现
`tests/test_hardware_contention_attribution.py`	GPU 统计、RDMA 单位、Marker、嵌套结果与时间窗测试	5/5 通过
`README.md`	唯一入口、范围和结果目录说明	已实现

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. 验收条件

Bench 的 ISL、OSL、并发、Seed、缓存状态与 Phase 1 对应 Case 一致。
两节点采集器均覆盖请求开始前 15 秒到结束后 15 秒。
GPU/DCGM/RDMA 时间序列带节点名和墙钟时间，能按 Phase 1 的实际 Case 测量窗口切片。
采集器不可用时记录 UNAVAILABLE 和原因，不静默跳过。
异常退出仍会停止采集器、Head/Worker 容器并确认 GPU 释放。
报告至少能缩小到“计算/显存、CPU 调度、网络通信、频率节流、节点不均衡”中的一个或两个方向。
若粗粒度指标仍无法区分，明确指出需要 Phase 3 的哪一段 Timeline，而不是强行给根因。

9. 实施记录

时间	代码或运行	结果
2026-07-30 15:46 CST	创建 Phase 2 设计与档案	采用单入口和独立轻量采样，不复制双机服务启动逻辑
2026-07-30 22:55:37 CST	完成 Phase 1 阶段交接	双 Rail 门禁和 12/12 正式结果通过；选定纯 Prefill、并发 Prefill、混合干扰三个诊断负载
2026-07-31 12:26:00 CST	完成 Phase 2 代码	扩展为五个固定负载和混合 A/B；实现双节点 GPU/DCGM/CPU/NUMA/网络/RDMA 采集、时间对齐和异常清理
2026-07-31 12:26:00 CST	本地验证	`bash -n`、Python 编译、5 项单元测试与全流程 Dry-run 通过；未占用 GPU

10. 真机结果

尚未运行正式双机诊断。代码和本地 Dry-run 已完成；下一步是在 174.1.51.5 做服务器端静态检查与 Dry-run，随后由同一 all 入口启动正式 Run。正式完成后本节将替换为成功 Run 的结果和瓶颈判断。

返回 Phase 1 实施记录

返回推理优化主计划