Phase 2：DeepSeek-V4-Pro 双机 Pro6000D SGLang Prefill 硬件归因

当前状态：Phase 1 前置条件已通过，等待阶段汇报确认后开始实现。 Phase 2 代码尚未创建。本页已经根据最终 Phase 1 结果选择诊断 Case；后续代码改动、静态验证、真机运行和结果判断会同步写入本页。

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 + 128K 注入	Output TPS -24.08%；TPOT P95 +66.55%	Prefill 干扰 Decode 时的硬件资源竞争

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

2. 本阶段的边界

只测试 SGLang，不测试 vLLM。
保留模型、镜像、TP16、EP2、显存比例和已验证的双 Rail NCCL 配置。
不启用 Nsight Systems、PyTorch Profiler、NCCL DEBUG 或投机解码。
不调参，不尝试优化；先获得足以区分瓶颈类别的硬件证据。
只重放本页选出的三个代表负载，不重复 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，请求参数和 Seed 与 Phase 1 一致。
重放 1K → 1K, C=32 Control 与 128K Prefill 注入 Treatment，保留相同注入时序。
请求结束后继续采样 15 秒，再停止采集器和服务。
按时间戳将请求、GPU、CPU 和双 Rail 指标对齐，生成摘要与判定。

idle 15s │ 128K C1 │ 32K C16 │ Decode Control │ Decode + Prefill │ cooldown 15s
          Head 与 Worker 的所有采集器覆盖完整诊断窗口

Phase 1 中服务加载约 5 分 30 秒，三个诊断负载合计为分钟级；连同静态快照、采样和清理，目标仍控制在 30 分钟内。

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_prefill_hardware_attribution/

文件	计划职责	当前状态
`run_prefill_hardware_attribution.sh`	唯一 Shell 入口；服务启停、双节点采集器、单 Case、Trap 清理	待实现
`config.env`	Phase 1 入口路径、三个诊断 Case、采样间隔、结果路径	待实现
`hardware_attribution.py`	结构化解析、时间对齐、统计摘要与报告生成	待实现
`tests/test_hardware_attribution.py`	计数器差分、单位换算、统计与缺失工具回退测试	待实现
`README.md`	入口命令、环境变量和结果目录说明	待实现

Phase 2 不复制双机 Docker 启停实现。唯一入口通过环境变量调用 Phase 1 的 run_quick_map.sh start/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.csv
    cpu_mpstat.log
    cpu_pidstat.log
    net_sar.log
    rdma.csv
    static/
  worker/
    gpu.csv
    cpu_mpstat.log
    cpu_pidstat.log
    net_sar.log
    rdma.csv
    static/
  summary.json
  summary.csv
  report.md

8. 验收条件

Bench 的 ISL、OSL、并发、Seed、缓存状态与 Phase 1 对应 Case 一致。
两节点采集器均覆盖请求开始前 15 秒到结束后 15 秒。
每份时间序列有节点名、墙钟时间和单调时钟，能与服务 Chunk 日志对齐。
采集器不可用时记录 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、混合干扰三个诊断负载

10. 真机结果

尚未运行。按阶段门约定，先完成 Phase 1 汇报；用户确认进入 Phase 2 后，再实现代码、完成静态验证和 Dry-run，并在启动真机诊断前说明具体改动。

返回 Phase 1 实施记录

返回推理优化主计划