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

当前状态：旧脚本口径审计完成，Phase 2 代码尚未开始。 本页从第一行 Phase 2 代码开始同步维护。每次代码改动、静态验证、真机运行和结果判断都会在对应小节留下文件路径、命令和证据，不在阶段结束后凭记忆补写。

1. 为什么立即进入 Phase 2

Phase 1 在没有 Profiler、没有 Prefix Cache 命中的条件下得到以下结果：

ISL / OSL / C	输入 TPS	TTFT	结果
1K / 1 / 1	64.44 tok/s	15.88 s	完成
32K / 1 / 1	64.96 tok/s	504.44 s	完成
128K / 1 / 1	65.20 tok/s	2010.38 s	完成

三个长度的输入吞吐几乎相同，TTFT 近似按 token 数线性增加。这已经不是“继续扩充 Shape”能回答的问题。Phase 2 要回答： 稳定的约 65 token/s 到底受 GPU 计算、显存、CPU 调度还是双机通信中的哪一项限制。

1.1 Phase 2 前置审计

旧脚本较短的 TTFT 已确认不是同口径反例。旧脚本固定执行 16 条同 Prompt Warm-up，从不清 Prefix Cache，并按固定 Seed 递增长度；17:40 的失败 Run 还在 18:01 正式 Run 前预热了同一批 1K 请求。全字段比较显示新旧 server_info 的关键运行参数相同。

同一服务上的最小复现得到：两次独立清 Cache 的 1K→1 TTFT 分别为 16.04 秒和 15.90 秒；把 OSL 改为 128 后是 15.79 秒；按旧命令语义重新执行仍为 14.60 秒，而不是旧产物的 0.455 秒。因此 Phase 2 将继续 profile 清 Prefix Cache 后的完整冷 Prefill。Warm Prefix/Prefix Cache 收益另立 A/B，不与本阶段混算。

2. 本阶段的边界

只测试 SGLang，不测试 vLLM。
保留 Phase 1 的模型、镜像、TP16、EP2、显存比例和 NCCL 参数。
不启用 Nsight Systems、PyTorch Profiler、NCCL DEBUG 或投机解码。
不调参，不尝试优化；先获得足以区分瓶颈类别的硬件证据。
第一轮只重放 32K → 1, C=1，与 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 秒空闲基线。
清空 Prefix Cache，发送一条 32K → 1, C=1 请求，Seed 与 Phase 1 一致。
请求结束后继续采样 15 秒，再停止采集器和服务。
按时间戳将请求、8K Chunk、GPU、CPU 和 Rail 指标对齐，生成摘要与判定。

idle 15s │──────── 32K Prefill：4 × 8K Chunk ────────│ cooldown 15s
          ↑ request_start                              ↑ request_end
          Head 与 Worker 的所有采集器覆盖完整时间窗

预计服务加载约 6 分钟、请求约 8.5 分钟，连同快照和清理应在 20 分钟左右完成。

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 入口路径、32K Case、采样间隔、结果路径	待实现
`hardware_attribution.py`	结构化解析、时间对齐、统计摘要与报告生成	待实现
`tests/test_hardware_attribution.py`	计数器差分、单位换算、统计与缺失工具回退测试	待实现
`README.md`	入口命令、环境变量和结果目录说明	待实现

Phase 2 不复制双机 Docker 启停实现。唯一入口通过环境变量调用 Phase 1 的 run_quick_map.sh start/stop，只新增硬件采集和 32K 请求编排。顶层仍只保留一个 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 的 32K Case 一致。
两节点采集器均覆盖请求开始前 15 秒到结束后 15 秒。
每份时间序列有节点名、墙钟时间和单调时钟，能与服务 Chunk 日志对齐。
采集器不可用时记录 UNAVAILABLE 和原因，不静默跳过。
异常退出仍会停止采集器、Head/Worker 容器并确认 GPU 释放。
报告至少能缩小到“计算/显存、CPU 调度、网络通信、频率节流、节点不均衡”中的一个或两个方向。
若粗粒度指标仍无法区分，明确指出需要 Phase 3 的哪一段 Timeline，而不是强行给根因。

9. 实施记录

时间	代码或运行	结果
2026-07-30 15:46 CST	创建 Phase 2 设计与档案	代码尚未开始，等待按本页设计实现
2026-07-30 16:35 CST	完成旧脚本与 quick-map 同口径审计	排除服务参数、OSL=1 和一次性 JIT；确认旧产物被 Warm-up、跨 Case 与前一轮 Prefix Cache 污染

10. 真机结果

尚未运行。代码实现、静态验证和 Dry-run 完成后，将先向用户说明具体代码改动，再启动真机诊断。

返回 Phase 1 实施记录

返回推理优化主计划