6000D 双机 DeepSeek-V4-Pro 推理优化计划
-适用环境：
+174.1.51.5 + 174.1.51.7，每台 8 张 RTX PRO 6000 Blackwell Server Edition
当前部署：DeepSeek-V4-Pro，16 张 GPU 组成一个完整实例
当前约束：模型暂时只能使用全部 16 张 GPU，无法额外复制一套模型进行 PD 分离
计划版本：2026-07-30 22:55:37 CST适用环境：
174.1.51.5 + 174.1.51.7，每台 8 张 RTX PRO 6000 Blackwell Server Edition
当前部署：DeepSeek-V4-Pro，16 张 GPU 组成一个完整实例
当前约束：模型暂时只能使用全部 16 张 GPU，无法额外复制一套模型进行 PD 分离
计划版本：2026-07-31 13:40:03 CST
当前执行状态与阶段档案
| DeepSeek-V4-Pro / 双机 Pro6000D / SGLang 硬件与资源竞争归因 | -代码、单元测试与本地 Dry-run 已完成；等待服务器端 Dry-run 与正式运行 | +首轮正式 Run 已完成；8/8 benchmark 成功，已获得 GPU、CPU 与双 Rail RDMA 瓶颈方向 | 打开 Phase 2 档案 |
400 Gbit/s ≈ 50 GB/s 只是单向理论上限，NCCL 的
algbw/busbw 与端到端模型吞吐都不能直接等同于该数字。
+
+当前 6000D 机内没有 NVLink。单机 8 卡由 PCIe 连接：
+GPU0–3 与 GPU4–7 各自在本地 PCIe Switch 内通信，两组之间还要经过 Host Bridge
+和 CPU/NUMA 互联。NCCL 机内日志中的 P2P/IPC 是 CUDA P2P over PCIe；
+两机之间则使用 mlx5_0/mlx5_3 双 Rail
+NET/IB + GDRDMA。Phase 2 已测跨机 HCA 流量，但机内 PCIe 的独立
+GPU-to-GPU 带宽和延迟仍需微基准补齐。
+
1. 目标与原则
1.1 最终目标
在不做 PD 分离的前提下，定位 DeepSeek-V4-Pro 在双机 6000D 上的端到端瓶颈，并提高：
@@ -727,10 +735,24 @@ TPOT P95 增加 66.55%。Phase 2 将围绕这两个现象采集硬件时间序 Phase 2：硬件与资源竞争归因档案。本阶段重放长 Prefill、并发 Prefill、 普通 Decode、长输出 Decode、长上下文 Decode，以及 -1K → 1K, C=32 的混合 A/B。目标是在约 30 分钟内区分 GPU、
-CPU、NUMA、双 Rail、调度排队、频率节流和节点不均衡。
+1K → 1K, C=32 的混合 A/B。正式 Run
+dsv4pro-phase2-20260731-130125 已在 26 分 26 秒内完成 8/8 个结果，
+无 OOM；本阶段先停在首轮归因，不自动进入 Phase 3。
-6.1 GPU
+6.1 首轮归因结果
+-
+
- 混合负载再次稳定复现：Decode Output TPS 下降 24.03%，TPOT P95 增加 66.79%，E2E P95 增加 63.30%。 +
- 128K Prefill 注入窗口两节点 GPU 平均利用率约 99%，功耗约 274 W，频率稳定；显存每卡约 83.2–83.4 GiB，只剩约 2.3 GiB 余量。 +
- 整机 CPU 平均约 8%–11%，没有全机 CPU 或 I/O Wait 饱和，但少量 CPU 核持续高负载，Scheduler/Affinity/NUMA 热点仍需关注。 +
- 双 Rail 流量对称且错误增量为 0；最高平均总发送约 140 Gbit/s，即每条 400G Rail 约 70 Gbit/s，原始 RoCE 带宽未饱和。 +
- 下一步应捕获短 TP16 Timeline，区分 GPU Kernel、Scheduler gap、机内 PCIe、跨机 Collective 与 Rank 同步，而不是重跑完整矩阵。 +
+首轮仍有两个采集限制：Worker 的 DCGM Host Engine 未启动，因此只有 Head DCGM
+有效；Case 时间窗包含客户端准备和 Warm-up，硬件均值并非纯主测量窗口。重跑前应先在
+.7 启动 nvidia-dcgm，并增加主 benchmark 精确起止标记。
+
6.2 GPU
测试期间持续记录：
nvidia-smi dmon -s pucvmt -d 1
6.2 CPU
+6.3 CPU
记录服务主进程与 Worker 线程：
pidstat -t -p <PID> 1
mpstat -P ALL 1
@@ -764,7 +786,7 @@ numastat -p <PID>
Worker 是否跨 NUMA 访问。
CPU 空洞是否对应 GPU 空洞。
-6.3 网络
+6.4 网络
Phase 1 正式 Run 已从两端 NCCL 日志确认
NET/IB 同时识别 mlx5_0/mlx5_3，跨节点 Channel
@@ -788,7 +810,7 @@ ethtool -S eth3
NCCL_DEBUG_SUBSYS=INIT,NET,GRAPH,TUNING
该日志开销较高，不应在正式性能结果中长期启用。
-6.4 NCCL_CROSS_NIC 快速 A/B
+6.5 NCCL_CROSS_NIC 快速 A/B
Phase 1 已证明 NCCL_CROSS_NIC=1 可以稳定完成端到端 Run，
但这不代表它是性能最优值。固定其余环境后比较 0/1/2，
@@ -800,12 +822,12 @@ Phase 1 已证明 NCCL_CROSS_NIC=1 可以稳定完成端到端 Run
6.5 与其他阶段的组合边界
+6.6 与其他阶段的组合边界
- Phase 1 保留一份不启用 Profiler 的端到端基线，避免 TPS 和时延被诊断工具污染。
- GPU、CPU 和网络的轻量采样可以伴随后续基线运行，但必须从 Case 开始前启动，并使用统一时间戳与 Case ID 对齐。
- Phase 1 已完整结束，其无 Profiler 结果作为后续 A/B 的请求层基线。 -
- Phase 2 重放五个固定代表负载和一组混合 A/B，并完整采集轻量指标；得到瓶颈方向后，再决定 Phase 3 捕获哪段短时间线。 +
- Phase 2 已重放五个固定代表负载和一组混合 A/B，并完成首轮轻量采集；下一步只需补齐 Worker DCGM 和精确时间窗，然后决定 Phase 3 的短 Timeline。
- 联合诊断 Run 的吞吐和时延只用于解释时间线；正式性能变化仍与 Phase 1 的无 Profiler 结果比较。
7. Phase 3：时间线 Profiling（Nsight Systems 为主）
@@ -814,15 +836,34 @@ Nsight Systems、PyTorch Profiler 和 NVTX 是三件不同的东西：Nsight Sys 记录系统级 CUDA/NCCL/CPU 时间线；PyTorch Profiler 由框架接口触发； NVTX 只是在时间线上添加可读标记。启用 NVTX 不等于已经启动 Nsight。 -7.1 捕获策略
+7.1 与 Phase 2 的分工
+| 问题 | 负责阶段或工具 | 是否在 Phase 3 重复 |
|---|---|---|
| GPU/CPU 平均利用率、功耗、频率、显存 | Phase 2 轻量采样 | 否；Phase 3 只保留最低限度健康检查 |
| 双 Rail 流量、均衡与错误计数 | Phase 2 HCA Counter | 否 |
| 机内 PCIe P2P 与 8/16 卡 Collective 峰值能力 | 一次性通信微基准：p2pBandwidthLatencyTest 与 all_reduce_perf | 只建立一次硬件基线，不随每个 Phase 重跑 |
| 真实请求中 NCCL Kernel 在何时发生、耗时多久 | Phase 3 Nsight Systems Timeline | 是，Phase 3 的核心 |
| 通信是否与 Attention/MoE Kernel 重叠、GPU 是否在等待 Rank | Phase 3 Nsight Systems Timeline | 是，Phase 2 无法回答 |
+因此 Phase 3 可以分析卡间通信，但分析的是真实请求里的时间与依赖关系， +不是再次统计平均网络带宽。通信微基准负责给出硬件上限，Phase 3 负责解释 SGLang +距离该上限有多远，以及通信是否落在关键路径上。 +
+7.2 捕获策略
- 只捕获预热后的 5 到 10 个 Engine Step。
- Prefill、Decode 和混合干扰分别生成报告。
- 两台机器分别保存原始报告。
- 优先保留所有 Rank；文件过大时至少保留代表 Rank 和跨机通信相关 Rank。
- 报告必须和对应 Benchmark Case ID 绑定。 +
- 不重复运行 Phase 2 的五点硬件采集矩阵，不同时开启高频
pidstat、mpstat、sar或 DCGM 全量采样。
7.2 vLLM
+7.3 vLLM
当前版本支持时，使用 CUDA Profiler 动态 Capture：
export VLLM_WORKER_MULTIPROC_METHOD=spawn
@@ -839,7 +880,7 @@ nsys profile \
压测端使用支持 Profile Trigger 的 Bench：
vllm bench serve ... --profile
-7.3 SGLang
+7.4 SGLang
以下 SGLANG_TORCH_PROFILER_DIR 与 /start_profile
属于 SGLang 的 PyTorch Profiler 路径，可用于框架级时间线，但不能把生成物