From 5096661ce33e7ccb673d38f4e20ced56b4c7a972 Mon Sep 17 00:00:00 2001 From: Zhiyi Hong <2497491955@qq.com> Date: Fri, 31 Jul 2026 17:05:19 +0800 Subject: [PATCH] [Docs] gate phase archives on completed results --- README.md | 4 + .../phase1_exp.html | 7 +- .../phase2_code.html | 419 ---------- .../phase2_exp.html | 769 ------------------ .../推理优化计划.html | 16 +- .../推理优化计划.md | 5 +- 6 files changed, 14 insertions(+), 1206 deletions(-) delete mode 100644 docs/dsv4pro_pro6000d_2node_sglang/phase2_code.html delete mode 100644 docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html diff --git a/README.md b/README.md index 41967e1..d5baa83 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,9 @@ # sskj — 多平台大模型推理性能基准测试项目 +> **更新（2026-07-31 17:01:56 CST）** +> +> 固定阶段档案生成门禁：某个 Phase 在实验结束、结果汇总并完成汇报确认前，不创建或维护 `phaseN_exp.html` 与 `phaseN_code.html`；进行中只维护代码、原始结果和主计划状态。阶段确认完成后再一次性生成两份最终 HTML。Phase 2 尚待最终正式复跑，因此暂时撤下其两份 HTML 及导航；已完成的 Phase 1 档案继续保留。 +> > **更新（2026-07-31 16:46:05 CST）** > > 统一 DeepSeek-V4-Pro 推理优化档案命名与导航：Phase 1/2 实验页分别更名为 `phase1_exp.html`、`phase2_exp.html`，代码页保持 `phase1_code.html`、`phase2_code.html`。主计划中的入口统一为“打开 Phase N 实验档案 / 代码详解”，并为实验页与代码页补齐双向链接。Phase 1 状态同步为固定点 11/11、混合 A/B 3/3、阶段总结果 14/14。 diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase1_exp.html b/docs/dsv4pro_pro6000d_2node_sglang/phase1_exp.html index baab43d..9bfd9a5 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/phase1_exp.html +++ b/docs/dsv4pro_pro6000d_2node_sglang/phase1_exp.html @@ -843,12 +843,7 @@ curl -fsS http://10.101.0.11:30002/health || true docker ps --filter name=dsv4pro_pro6000d_2node_sglang_tp16_quick_map nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv -

- 下一阶段： - - 打开 Phase 2 实验档案 - -

+

下一阶段：Phase 2 正在进行，完成最终复跑与汇报后生成实验档案。

返回推理优化主计划

diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_code.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_code.html deleted file mode 100644 index f2c62b8..0000000 --- a/docs/dsv4pro_pro6000d_2node_sglang/phase2_code.html +++ /dev/null @@ -1,419 +0,0 @@ - - - - - - - Phase 2 Code：DSV4-Pro 双机 Pro6000D SGLang 硬件竞争归因 - - - -
-
-

Standalone Code Walkthrough / Phase 2

-

DSV4-Pro 双机 Pro6000D SGLang 硬件竞争归因：代码详解

-
- 行号基线：39fc2ba565a3　 - 生成时间：2026-07-31 15:25:00 CST　 - 唯一入口：run_hardware_contention_attribution.sh all -
-
-
- -
-

- 返回推理优化主计划 · - 打开 Phase 2 实验档案 -

-
- 文档边界：本文只解释提交 39fc2ba565a3 的 Phase 2 - 代码和文件调用关系。Phase 1 负责模型服务与请求；Phase 2 负责通信基线、 - 两节点监控、精确时间切片和逐指标报告。 -
- -

1. 阅读导航

- - -

2. 总体控制流

- 
main "$@" → run_all
-  ├─ validate_config
-  ├─ preflight_node_tools
-  │    └─ 两节点 dcgmi discovery -l 必须成功
-  ├─ preflight_clock_sync + preflight_gpus_idle
-  ├─ run_communication_baseline
-  │    ├─ 两节点 CUDA P2P 全矩阵
-  │    ├─ 两节点各自 8-rank AllReduce
-  │    └─ 16-rank AllReduce，CROSS_NIC=0/1/2
-  ├─ start_service → Phase 1 start
-  ├─ capture_static_snapshots before
-  ├─ start_collectors → Head/Worker 同时采集
-  ├─ idle → fixed cases → mixed A/B → cooldown
-  ├─ check_collectors + stop_collectors
-  ├─ capture_static_snapshots after
-  ├─ stop_service → Phase 1 stop
-  ├─ summarize_results
-  │    └─ 按正式 benchmark 窗口生成第 5 节逐项数据表
-  └─ finish_manifest
-

- all 是唯一正式入口。communication、summarize - 和 stop 是排错/恢复 action，不需要在正常执行前手工调用。 -

- -

3. 文件职责与调用关系

- - - - - - - - - -
文件行数职责
config.env61节点、Case、分层采样周期、通信尺寸、NCCL 选择和 fail-closed 策略。
run_hardware_contention_attribution.sh1036唯一 Shell 编排器：预检、通信文件分发、通信基线、Phase 1 委托、采集器、Case 和清理。
communication_baseline.py227CUDA P2P 全矩阵及 PyTorch/NCCL AllReduce 正确性、延迟和带宽测试。
hardware_contention_attribution.py1480解析所有原始采集器，按 Case 切片，聚合通信并生成 CSV/JSON/report.md。
tests/test_hardware_contention_attribution.py3229 项纯 Python 单元测试，覆盖 worker 无仓库依赖、精确窗口、解析器、RDMA 单位和通信聚合。
- - 
用户
-  └─ Phase2/run_hardware_contention_attribution.sh all
-       ├─ source Phase2/config.env
-       ├─ docker/torchrun → Phase2/communication_baseline.py
-       ├─ env ... bash Phase1/run_quick_map.sh start/fixed/mixed/stop
-       │    └─ Phase1/quick_map_results.py 写 benchmark meta
-       ├─ Shell 采集 Head/Worker 原始时间序列
-       └─ Phase2/hardware_contention_attribution.py summarize
-            ├─ 读取 Phase1 bench/cases/*/meta.json
-            ├─ 读取 Head/Worker 原始监控
-            ├─ 读取 communication/COMM_RESULT
-            └─ 输出逐 Case、逐节点、逐指标表和 report.md
- -

3.1 Phase 1 与 Phase 2 的边界

- - - - - - - - -
问题由哪个文件负责证据
模型路径、镜像、TP16、EP、显存比例Phase 1 config.env + run_quick_map.shservice/head_server_cmd.txt、worker_server_cmd.txt
ISL/OSL/C、random 请求和 mixed A/BPhase 1 场景表与 benchmark 函数bench/*/bench_cmd.txt、bench.json
通信基线、监控周期、Case 选择Phase 2 config.envPhase 2 manifest.json
硬件归因和数值报告Phase 2 Python 汇总器case_*_summary.csv、report.md
- -

4. 配置来源

- - - - - - - - - -
行号配置组关键变量
config.env:L3-L16入口与节点PHASE1_ENTRY、Head/Worker、端口和容器名。
L18-L21诊断 Case五个 fixed Case、mixed A/B 开关。
L23-L39采样与严格性GPU/DCGM/RDMA 1 秒；CPU/进程/网络/NUMA/perf 5 秒；精确窗口和采集器 fail-closed。
L40-L55通信基线镜像、消息尺寸、迭代次数、P2P 大小、CROSS_NIC 列表、Socket/HCA。
L57-L61路径与模式RESULT_BASE、Runtime、Dry-run、是否允许部分采集器。
-

- MEM_FRACTION_STATIC 不在 Phase 2 重复定义。它仍来自 Phase 1， - 最终展开为 SGLang 的 --mem-fraction-static。判断某次 Run 的真实值， - 应读取 service/head_server_cmd.txt，不能只看默认配置。 -

- -

5. 通信微基准

-

5.1 Shell 如何编排

-

- run_hardware_contention_attribution.sh:L281-L513 负责源码暂存、 - Docker 命令、两节点同步和清理。所有命令先写入 commands/*.txt： -

- -

- Docker 使用和 SGLang 一致的 CUDA 13 nightly 镜像，并显式透传 - rdma_cm、uverbs0、uverbs3。 - NCCL_DEBUG=INFO 只在微基准中打开，用于证明 NET/IB/GDRDMA 路径。 - Worker 不要求存在 Git 仓库；容器只读挂载自动分发的 - /tmp/.../<RUN_ID>/communication_baseline.py。结果目录同时保存 - 当次源码副本和 SHA256，避免两个节点 checkout 不一致造成版本漂移。 -

- -

5.2 P2P 代码

-

- communication_baseline.py:L45-L106 遍历所有源 GPU 和目标 GPU， - 先调用 torch.cuda.can_device_access_peer，再对 256 MiB FP16 Tensor - 做预热和 CUDA Event 计时。输出包括方向、P50/P95 latency 和 GB/s。 - 汇总器按拓扑拆成同 PCIe Switch 的 PIX 与跨 NUMA 的 SYS。 -

- -

5.3 AllReduce 代码

-

- communication_baseline.py:L107-L198 初始化 NCCL process group， - 对 1 MiB、64 MiB、1 GiB 分别预热和重复测量。每轮先把各 rank latency - gather 到 rank 0，使用最慢 rank 作为 collective 完成时间，并检查归约结果： -

- 
algbw = message_bytes / latency
-busbw = algbw × 2 × (world_size - 1) / world_size
-wrong_values = count(output != expected_sum)
-

- 这样不会用某个提前返回 rank 的时间美化结果；wrong_values=0 - 才算正确完成。 -

- -

6. 两节点采集器

-

6.1 启动前门禁

-

- Shell L67-L199 完成配置、工具、时钟和 GPU 空闲检查。 - preflight_node_tools 不只检查 dcgmi 文件存在， - 还实际运行 dcgmi discovery -l；两节点任一 Host Engine 不可用即退出。 -

- -

6.2 采集器包装

-

- start_stream_collector 位于 Shell L517-L551。 - 它保存完整命令、PID、唯一进程 tag 和日志；check_collectors 在 - L722-L740 检查采集器是否提前退出，默认不允许部分成功。 -

- - - - - - - - - - - - - -
采集器Shell 位置周期输出
nvidia-smiL552-L5651 秒gpu_samples.csv
RDMA HCA countersL566-L5921 秒rdma.csv
DCGML645-L6551 秒dcgm_dmon.log
mpstatL656-L6635 秒mpstat.log
pidstat -durwL664-L6715 秒，进程级pidstat.log
sar -n DEV,EDEVL672-L6785 秒sar_net.log
perf statL680-L6895 秒perf_stat.log
numastatL618-L6445 秒numa_samples.csv
-

- CPU、进程、perf 和 sar 的每行均由 Shell 增加 - wall_time_ns TAB node TAB payload。NUMA 直接转成结构化 CSV， - 避免旧版线程级 1 秒日志过大，也让所有指标能按 Case 切片。 -

- -

7. 精确测量窗口

-

7.1 Phase 1 如何标记主测量

-

- Phase 1 run_quick_map.sh:L547-L564 每 100 ms 观察 bench 日志； - 发现 Starting main benchmark run 后调用 - quick_map_results.py mark-measurement-start。 - quick_map_results.py:L340-L385 用这个起点和 - bench.json.duration 生成： -

- 
measurement_started_at
-measurement_ended_at
-measurement_duration_s
-measurement_window_source = bench_main_marker_plus_duration
- -

7.2 Phase 2 如何使用

-

- hardware_contention_attribution.py:L509-L560 优先读取上述字段。 - 只有兼容旧结果时才可能使用进程级窗口；正式配置 - REQUIRE_PRECISE_WINDOWS=1 会拒绝任何 fallback。 - L561-L841 对 GPU、DCGM、CPU、进程、perf、NUMA、netdev 和 RDMA - 使用同一个 started_ns ≤ sample ≤ ended_ns 条件。 -

- -

8. 逐指标报告

-

- Python summarize 位于 - hardware_contention_attribution.py:L1036-L1378。 - 它不只生成一个抽象结论，而是按 Phase 2 第 5 节依次写出： -

- - - - - - - - - - - - - -
指标解析函数Case 汇总文件
GPUsummarize_gpu_rows L377-L413case_gpu_summary.csv、case_gpu_node_summary.csv
DCGMparse_dcgm L167-L192case_dcgm_summary.csv
CPUparse_mpstat L193-L222case_cpu_summary.csv
进程parse_pidstat L223-L289case_process_summary.csv
perfparse_perf L290-L310case_perf_summary.csv
NUMA结构化 CSV + summarize_case_metricscase_numa_summary.csv
Linux netdevparse_sar_net L311-L358case_netdev_summary.csv
RDMAsummarize_rdma_rows L424-L484case_rdma_summary.csv
P2P/NCCLload_communication_rows + aggregate_communication_rows L842-L928communication_summary.csv、communication_aggregate.csv
-

- report.md 对每组都打印有效样本数、Mean/P95/Max、Head/Worker - 或 Case 间比较和源文件。解析不到的值保留为 -，不会被写成 0。 -

- -

9. 结果目录

- 
results/<RUN_ID>/
-  manifest.json
-  commands/
-  communication/
-  service/
-  bench/<phase1-sub-run>/
-  head/
-    gpu_samples.csv
-    dcgm_dmon.log
-    mpstat.log
-    pidstat.log
-    perf_stat.log
-    sar_net.log
-    numa_samples.csv
-    rdma.csv
-    collector_commands/
-  worker/
-    ...同上...
-  case_windows.csv
-  bench_summary.csv
-  case_gpu_summary.csv
-  case_gpu_node_summary.csv
-  case_dcgm_summary.csv
-  case_cpu_summary.csv
-  case_process_summary.csv
-  case_perf_summary.csv
-  case_numa_summary.csv
-  case_netdev_summary.csv
-  case_rdma_summary.csv
-  communication_summary.csv
-  communication_aggregate.csv
-  summary.json
-  report.md
- -

10. 函数行号索引

-

10.1 Shell 编排器

- - - - - - - - - - - - - - - -
行号函数组职责
L26-L66日志、远端执行、命令证据基础设施。
L67-L199配置、工具、时钟、GPU 空闲门禁正式运行前 fail-fast。
L200-L268Manifest、marker、Phase 1 委托运行身份与复用边界。
L281-L513通信基线按 Run 分发源码、P2P、8/16-rank AllReduce、CROSS_NIC A/B 与清理。
L448-L516服务和静态快照启停 Phase 1 双机服务并保存环境。
L517-L710采集命令与启动两节点分层采样。
L711-L772采集器检查和停止fail-closed 与残留清理。
L782-L835fixed/mixed Case代表负载编排。
L836-L858汇总、Manifest、trap结果收口。
L859-L928run_all完整状态机。
L929-L968辅助 action 与 maincommunication/all/summarize/stop 分发。
- -

10.2 Python 文件

- - - - - - - - - - - - - - -
文件/行号职责
communication_baseline.py:L20-L44尺寸解析、分位数和 JSON 结果协议。
L45-L106CUDA P2P 全矩阵。
L107-L198NCCL AllReduce 与正确性。
hardware_contention_attribution.py:L76-L166时间、CSV、数字统计基础函数。
L167-L358DCGM、mpstat、pidstat、perf、sar 解析器。
L359-L508通信、GPU、RDMA、bench 读取与汇总。
L509-L841精确窗口和全部 Case 指标切片。
L842-L1035通信聚合、CSV、Marker、Manifest。
L1036-L1378全部输出表和逐指标 report.md。
L1379-L1480CLI 子命令。
- - -
- - diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html deleted file mode 100644 index 8fc7ab1..0000000 --- a/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html +++ /dev/null @@ -1,769 +0,0 @@ - - - - - - Phase 2：DeepSeek-V4-Pro 双机 Pro6000D SGLang 硬件与资源竞争归因 - - - -
-
-

Design, Implementation & Result Record

-

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

-
- 节点：174.1.51.5 + 174.1.51.7 - 拓扑：SGLang TP16 / EP2 - 更新：2026-07-31 16:46:05 CST -
-
-
- -
- 返回推理优化主计划 - 打开 Phase 2 代码详解 - -

- 当前状态：Phase 2 最终采集代码已完成，等待最终双机复跑。 - 首次 Run dsv4pro-phase2-20260731-130125 的 8/8 个 benchmark - 均成功；提交 30664faa41f8 已补齐正式测量窗口、双节点 DCGM 门禁、 - 低开销进程采样、机内 PCIe P2P、单/双机 AllReduce 与逐指标自动报告。 - 本阶段复跑完成并汇报后才进入 Phase 3。 -

- -

1. Phase 1 交接结果

- - - - - - - - - - - - -
代表负载关键结果Phase 2 用途
128K → 1，C=1Input TPS 2,710.16；TTFT P95 48.344 s纯长 Prefill 的计算、显存与通信归因
32K → 1，C=16Input TPS 3,112.77；TTFT P95 162.087 s并发 Prefill 的排队、Chunk 调度与节点均衡
1K → 1K，C=32Output TPS 461.68；TPOT P95 63.31 ms普通 Decode 的 GPU、CPU 与通信基线
1K → 4K，C=16Output TPS 310.02；TPOT P95 50.33 ms持续 Decode、KV 增长和稳态资源占用
128K → 1K，C=1TTFT 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. 本阶段的边界

- - -

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

-
    -
  1. 确认 16 张 GPU 空闲，先跑两节点 PCIe P2P、单机 8 rank AllReduce 和双机 16 rank AllReduce；双机分别测试 NCCL_CROSS_NIC=0/1/2。
    2. -
  2. 保存两节点静态快照：GPU/NIC/NUMA 拓扑、驱动、CUDA、镜像与服务命令。
    3. -
  3. 复用 Phase 1 已验证的 run_quick_map.sh start 启动同配置双机服务。
    4. -
  4. 在 Head 和 Worker 同时启动 GPU、CPU、网卡与 RDMA 采样，先记录 15 秒空闲基线。
    5. -
  5. 依次重放 128K → 1, C=1、32K → 1, C=16 与 1K → 1K, C=32。
    6. -
  6. 重放 1K → 4K, C=16 和 128K → 1K, C=1，观察持续与长上下文 Decode。
    7. -
  7. 重放 1K → 1K, C=32 Control 与 128K Prefill 注入 Treatment，保留相同注入时序。
    8. -
  8. 请求结束后继续采样 15 秒，再停止采集器和服务。
    9. -
  9. 按时间戳将请求、GPU、CPU 和双 Rail 指标对齐，生成摘要与判定。
    10. -
- 
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、 - 静态快照、采样和清理组成一次完整 Phase 2 Run。 -

- -

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 内部执行顺序：

- 
配置、工具、DCGM 与 GPU 空闲门禁
-  → 通信基线：两节点 P2P、两组单机 8-rank AllReduce、
-                三组双机 16-rank NCCL_CROSS_NIC A/B
-  → Phase 1 start：启动同配置 TP16 服务
-  → 两节点静态快照
-  → 启动两节点采集器并记录 15 秒 idle
-  → 五个固定 Case
-  → 混合 Prefill/Decode A/B
-  → 15 秒 cooldown
-  → 停止采集器并保存后快照
-  → Phase 1 stop：停止 Head/Worker
-  → 生成按第 5 节逐项对应的 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/。 -

- - - - - - - - - - - -
层级连续采样静态或前后快照
GPU利用率、Memory Utilization、显存、功耗、SM/Memory Clock、温度、P-statenvidia-smi topo -m、Compute Process
CPU每核利用率、上下文切换、服务进程 CPU/内存NUMA 拓扑、容器 PID 与 CPU Affinity
Networketh0/eth3 RX/TXethtool -S 错误计数前后差
RDMAmlx5_0/mlx5_3 port_xmit/recv_data 差分Port State、GID 与错误计数
DCGMSM Active、DRAM Active、Tensor Active、PCIe工具版本与可用 Field
- -

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
- - - - - - - -
数据含义为什么需要
wall_time_nsUnix Epoch 纳秒时间把 GPU、CPU、RDMA 与 Benchmark 放到同一时间轴
case_start/case_end一个 Case 的编排边界从整段连续采样中切出对应负载
CLOCK_SKEW_TOLERANCE_S=2两节点允许的最大秒级时钟差避免 Head/Worker 的同一时刻被错位比较
-

- 最终实现由 Phase 1 监听 bench.log 中的 - Starting main benchmark run，立刻写入 - measurement_start.json；再使用 SGLang bench.json - 的正式 benchmark duration 计算结束时间。Phase 2 优先读取 - measurement_started_at/measurement_ended_at，不会把数据生成和 - Warm-up 混入硬件均值。REQUIRE_PRECISE_WINDOWS=1 时，任何 Case - 缺少精确窗口都会让汇总失败，而不是悄悄回退。 -

- -

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 和节点角色。

- - - - - - - - - - -
字段代表什么
utilization.gpu采样周期内至少有一个 Kernel 在执行的时间比例
utilization.memory采样周期内显存控制器处于忙碌状态的时间比例
memory.used/total当前总显存分配量与设备显存容量
power.drawGPU 当前功耗，用于比较不同负载的能耗状态
clocks.sm/clocks.memSM 与显存当前工作频率
pstateGPU 性能状态，P0 通常是最高性能态
-

- 原始输出为 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
- - - - - - - - - - - -
Field IDField Tag含义
1001gr_engine_activeGraphics/Compute Engine 活跃比例，接近整体 GPU 执行忙碌度
1002sm_activeSM 至少有一个 Warp 活跃的比例
1003sm_occupancy活跃 Warp 相对硬件可容纳 Warp 的比例
1004tensor_activeTensor Core 指令活跃比例
1005dram_active设备显存接口活跃比例；Pro6000D 为 GDDR7，用于判断设备显存带宽压力
1009pcie_tx_bytesGPU 经 PCIe 发出的字节速率
1010pcie_rx_bytesGPU 经 PCIe 接收的字节速率
-

- sm_active 高而 sm_occupancy 低，表示 SM 经常有工作， - 但同时驻留的 Warp 不多；后续通过 Kernel Timeline 区分小 Kernel、 - 寄存器/共享内存约束和同步。DCGM 是 NVIDIA Data Center GPU Manager： - nvidia-dcgm/nv-hostengine 是后台 Host Engine， - dcgmi 是客户端，Field ID 是指标编号。最终代码在两节点预检 - dcgmi discovery -l，任一 Host Engine 不可用即 fail-fast； - 正式结果必须同时包含 Head 和 Worker 的 case_dcgm_summary.csv。 -

- -

5.4 CPU、进程与 Kernel Launch 侧证据

- 
# 全部逻辑 CPU，每 5 秒输出一次
-mpstat -P ALL 5
-
-# 找到容器内进程对应的宿主 PID
-docker top <container> -eo pid,ppid,psr,pcpu,pmem,stat,comm,args
-
-# 最终命令：进程级 CPU、I/O、缺页、上下文切换，不展开全部线程
-pidstat -durw -p "<comma-separated-host-pids>" 5
-
-# 每 5 秒输出一次硬件/软件计数器增量
-perf stat -p "<comma-separated-host-pids>" -I 5000 \
-  -e cycles,instructions,cache-misses,context-switches,\
-cpu-migrations,page-faults
-
-# mpstat/pidstat/perf 每行都由包装器增加：
-# wall_time_ns TAB node TAB 原始输出
- - - - - - - - - - - - -
命令/字段回答的问题
mpstat -P ALL整机是否 CPU 饱和，是否只有少量核心接近 100%，是否存在 I/O Wait
docker top把容器进程映射为宿主 PID、CPU 核 PSR 和进程状态
pidstat -u服务进程的用户态、内核态 CPU 时间
pidstat -d进程块设备 I/O
pidstat -r内存和 Page Fault 行为
pidstat -w主动/被动上下文切换，辅助发现线程阻塞或调度抖动
perf cycles/instructionsCPU 周期与指令执行量，可计算近似 IPC
cache-misses/migrationsCPU Cache 压力和线程跨核迁移
-

- 最终实现使用进程级 5 秒采样，避免首轮线程级 1 秒采样产生数百 MB 日志。 - case_cpu_summary.csv、case_process_summary.csv 和 - case_perf_summary.csv 都按正式测量窗口切片；只有先发现异常进程， - 才在后续短窗口单独开启线程级采样。 -

- -

5.5 NUMA 与 CPU/内存亲和

- 
# 静态 NUMA 节点、CPU 和内存布局
-numactl --hardware
-numastat -m
-
-# 每 5 秒按容器宿主 PID 查看本地/远端 NUMA 内存
-numastat -p <host-pid>
-# 解析为：
-# wall_time_ns,node,node0_mib,node1_mib,total_mib,process_count
-
-# 同时保存 GPU、CPU、NIC 的拓扑关系
-nvidia-smi topo -m
-

- NUMA 是多路 CPU 机器的“本地内存”结构。进程长期从远端 NUMA Node 取内存， - 或 GPU/NIC 对应的 CPU 线程被调度到另一侧，可能增加 Host 侧延迟。 - 最终采集器把 numastat -p 解析为 - numa_samples.csv，再按正式测量窗口生成 - case_numa_summary.csv。这样可以直接比较 Node0/Node1 MiB， - 而不是依靠人工阅读不断刷新的文本。 -

- -

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

- 
# Linux netdev 层，每 5 秒采样吞吐与错误
-sar -n DEV,EDEV 5
-
-# 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
- - - - - - - - - - - -
Counter含义
port_xmit_data/port_rcv_dataHCA 发送/接收数据累计量；IB Counter 单位是 4 Octets，脚本用 delta × 4 × 8 / seconds 换算 Gbit/s
port_xmit_wait端口因缺少发送 Credit 等原因等待的时间，持续增长可能指向拥塞
port_xmit_discards/port_rcv_errors发送丢弃和接收错误增量
req_transport_retries_exceededRDMA Transport 重试耗尽
req_rnr_retries_exceededReceiver Not Ready 重试耗尽
roce_adp_retrans*RoCE 自适应重传及超时相关计数
np_ecn_marked* / *cnp*ECN 标记和拥塞通知包，用于辅助判断 RoCE 拥塞
-

- 原始数据为 head|worker/rdma.csv； - case_rdma_summary.csv 按 Case、节点和 HCA 计算吞吐及错误增量。 - 它说明双 Rail 的实际流量、均衡性和错误增量； - case_netdev_summary.csv 同时保留 Linux netdev 层的 - eth0/eth3 RX/TX 与错误。Phase 3 再把 NCCL Collective - 放到请求 Timeline 中分析持续时间和计算重叠。 -

- -

5.7 机内 PCIe 与 NCCL 通信基线

- 
# 由 all 入口自动执行；不需要用户手工运行 torchrun
-# 每个节点：所有 GPU 源/目标对，FP16 256 MiB CUDA P2P copy
-python3 communication_baseline.py p2p \
-  --size 256M --warmup 3 --iterations 10
-
-# 每个节点：8 rank NCCL AllReduce
-torchrun --standalone --nproc-per-node=8 \
-  communication_baseline.py all-reduce \
-  --sizes 1M,64M,1G --repetitions 3 --warmup 5 --iterations 10
-
-# 双节点：16 rank；分别设置 NCCL_CROSS_NIC=0、1、2
-torchrun --nnodes=2 --nproc-per-node=8 \
-  --master-addr 10.101.0.11 --node-rank <0-or-1> \
-  communication_baseline.py all-reduce \
-  --sizes 1M,64M,1G --repetitions 3 --warmup 5 --iterations 10
-

- P2P 结果按 same_pcie_switch（PIX）和 - cross_numa_sys（SYS）分别汇总，不用一个平均值掩盖跨 CPU 路径。 - AllReduce 同时报告 P50/P95 latency、algbw、 - busbw、正确性错误数和实际 NCCL 路径。1 MiB、64 MiB、1 GiB - 分别覆盖小消息延迟、中等消息和大消息带宽；双机 A/B 直接给出 - NCCL_CROSS_NIC=0/1/2 的数值比较。 -

- -

5.8 静态快照与结果关系

- 
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
- - - - - - - - - - - - - - - - - - -
结果文件内容主要用途
static_before.log / static_after.logGPU、CPU、NUMA、NIC、RDMA、容器前后快照证明运行环境，并比较错误计数和清理状态
collector_status.csv每个采集器的启动、停止或提前退出状态防止把缺失采集器当作 0 值
case_windows.csv每个 Benchmark Case 的起止时间从连续硬件日志中切片
bench_summary.csvTPS、TTFT、TPOT、ITL、E2E把硬件现象与用户侧性能对应
case_gpu_summary.csv每 Case、节点、GPU 的利用率、显存、功耗、频率比较负载与节点/GPU 不均衡
case_dcgm_summary.csv每 Case、节点、GPU 的 SM/Tensor/显存接口/PCIe 指标区分计算、设备显存和 PCIe 活跃度
case_cpu_summary.csv整机与逐核 CPU 利用率、I/O Wait识别整机饱和和少数热点核
case_process_summary.csv服务进程 CPU、I/O、缺页、内存与上下文切换定位 Host 进程开销与阻塞
case_perf_summary.csvcycles、instructions、cache miss、迁移与缺页计算 IPC 并判断 Cache/调度压力
case_numa_summary.csvNode0/Node1 进程内存分布识别跨 NUMA 放置
case_netdev_summary.csveth0/eth3 吞吐与错误与 RDMA HCA Counter 做分层核对
case_rdma_summary.csv每 Case、节点、Rail 的吞吐和错误增量判断双 Rail 使用、均衡和数据面错误
communication_summary.csv每次 P2P/AllReduce 原始测量保留每条 GPU 对、消息尺寸、CROSS_NIC 和重复实验
communication_aggregate.csvPIX/SYS P2P 与单/双机 AllReduce 聚合提供 P50/P95、algbw、busbw 和正确性比较
- -

5.9 最终结果如何逐项汇报

-

- 最终 report.md 的章节顺序与本节一一对应。每一项必须同时给出 - 原始文件、有效样本数、Head/Worker 数值、Case 间变化和解释； - 不能只写“GPU 较忙”“网络未饱和”这类抽象结论。 -

- - - - - - - - - - - -
第 5 节指标报告中的数值最小分析动作
5.1 时间窗窗口来源、开始/结束、duration、采样数确认全部为 bench_main_marker_plus_duration
5.2 GPU利用率/显存/功耗/频率的 Mean、P95、Max比较两节点、8 卡离散度和不同 Case
5.3 DCGMSM Active/Occupancy、Tensor/DRAM Active、PCIe TX/RX比较计算、设备显存和 PCIe 哪一侧随负载上升
5.4 CPU/进程/perf整机/热点核、进程 CPU/I/O/缺页/切换、IPC/Cache miss区分整机容量、单线程热点和 Host 调度开销
5.5 NUMANode0/Node1 MiB 与比例比较服务内存是否偏离 GPU/NIC 所在 NUMA
5.6 Network/RDMAeth0/eth3、mlx5_0/mlx5_3 Gbit/s 与错误增量计算双 Rail 均衡比例并核对丢弃/重试
5.7 CommunicationPIX/SYS P2P、8/16 rank AllReduce P50/P95、algbw/busbw比较跨 NUMA 损失与 CROSS_NIC 0/1/2
-

- 某个采集器无数据时报告显示 - 并附失败状态，不会把缺失值写成 - 0。正式 Run 默认 ALLOW_PARTIAL_COLLECTORS=0， - 因此必需采集器提前退出会让 Run 失败。 -

- -

6. 精简代码设计

-

已新增目录：

- 
/data/hzy/sskj/experiments/pro6000/
-dsv4pro_pro6000d_2node_sglang_hardware_contention_attribution/
- - - - - - - - - - - - -
文件职责当前状态
run_hardware_contention_attribution.sh唯一 Shell 入口；按 Run 分发通信代码、通信基线、服务启停、双节点采集器、Case 编排、门禁和 Trap 清理已实现
config.envPhase 1 相对路径、节点、代表 Case、分层采样周期、通信基线与 fail-closed 策略已实现
communication_baseline.pyCUDA P2P 全矩阵与 PyTorch/NCCL 8/16-rank AllReduce 微基准已实现
hardware_contention_attribution.py精确窗口、全部采集器解析、逐 Case 汇总、通信聚合和逐指标报告已实现
tests/test_hardware_contention_attribution.pyWorker 无仓库依赖、GPU/RDMA、精确窗口、DCGM/CPU 解析、通信聚合和结果生成测试9/9 通过
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
-  communication/
-    communication_baseline.py
-    communication_baseline.sha256
-    p2p_head.log
-    p2p_worker.log
-    allreduce_head_8gpu.log
-    allreduce_worker_8gpu.log
-    allreduce_two_node_x0.log
-    allreduce_two_node_x1.log
-    allreduce_two_node_x2.log
-  head/
-    gpu_samples.csv
-    dcgm_dmon.log
-    mpstat.log
-    pidstat.log
-    sar_net.log
-    perf_stat.log
-    docker_top.log
-    numa_samples.csv
-    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
-  communication_summary.csv
-  communication_aggregate.csv
-  case_gpu_summary.csv
-  case_gpu_node_summary.csv
-  case_dcgm_summary.csv
-  case_cpu_summary.csv
-  case_process_summary.csv
-  case_perf_summary.csv
-  case_numa_summary.csv
-  case_netdev_summary.csv
-  case_rdma_summary.csv
-  summary.json
-  report.md
- -

8. 验收结果

- - -

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
2026-07-31 13:27:51 CST完成正式双机 RunRun dsv4pro-phase2-20260731-130125：8/8 benchmark 成功，总用时 26 分 26 秒，无 OOM
2026-07-31 13:40:03 CST完成首轮结果归因排除原始双 Rail 带宽饱和、整机 CPU 饱和和频率塌陷作为首要原因；锁定 TP16 Kernel、调度与同步时间线
2026-07-31 15:25:00 CST完成最终 Phase 2 代码提交 30664faa41f8：精确主测量窗口、双节点 DCGM 门禁、5 秒低开销 Host 采样、PCIe/NCCL 基线和逐指标自动报告均已通过本地验证
2026-07-31 16:18:35 CST修复 Worker 通信代码路径提交 39fc2ba565a3：通信脚本按 Run 自动分发并校验哈希，Worker 不再要求存在同路径 Git 仓库；9/9 回归测试通过
2026-07-31 16:27:58 CST双节点通信 smoke test1 MiB 最小功能验证完整通过 P2P、8-rank 和 16-rank AllReduce；仅验证链路，不作为正式带宽数据
- -

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 代表负载

- - - - - - - - - - - -
CaseInput TPSOutput TPSTTFT P95TPOT P95
128K → 1, C=12,618.530.0250.036 s—
32K → 1, C=163,116.200.10161.899 s—
1K → 1K, C=32447.41447.4110.144 s65.63 ms
1K → 4K, C=1679.35317.411.727 s50.01 ms
128K → 1K, C=11,610.8912.5948.489 s32.12 ms
- -

10.2 混合 Prefill/Decode

- - - - - - - - - - -
Decode 指标Control注入 128K Prefill变化
Output TPS454.39345.20-24.03%
TTFT P959.437 s9.869 s+4.58%
TPOT P9566.17 ms110.36 ms+66.79%
E2E P9572.225 s117.941 s+63.30%
-

- 这再次证明 Prefill 会明显干扰正在进行的 Decode。ITL P95 仍约为 - 62 ms，并不与 TPOT 恶化矛盾：少量同步长停顿可能不足全部 token 间隔的 5%， - 因而会被全局 token 级 ITL P95 隐藏，而请求级 TPOT 和 E2E 会暴露它。 -

- -

10.3 GPU、CPU 与通信

- - -

10.4 卡间通信路径

- - - - - - - - -
范围实际路径本轮是否测量
单机 8 卡内部无 NVLink；NCCL P2P/IPC 走 PCIe。GPU0–3、GPU4–7 各自在 PCIe Switch 内为 PIX，两组之间为 SYS首次 Run 仅有 DCGM PCIe 指标；最终代码已加入所有 GPU 对的 256 MiB P2P 微基准
两机之间mlx5_0 + mlx5_3 双 Rail NET/IB + GDRDMA已测量每 Case HCA 流量、均衡性和错误增量
-

- 最终代码使用当前 SGLang 镜像内的 PyTorch/CUDA/NCCL 实现等价微基准： - 两节点 P2P 全矩阵、两组单机 8-rank AllReduce 和三组双机 16-rank - NCCL_CROSS_NIC A/B。结果统一写入 - communication_summary.csv 与 communication_aggregate.csv； - 完成 Phase 2 后，后续阶段不重复跑这些微基准。 -

- -

10.5 首轮结论与最终代码修正

-

- 当前证据支持把下一步缩到 TP16 的 Kernel、Scheduler、PCIe/RDMA Collective - 和 Rank 同步时间线。Phase 3 只分析真实请求中通信出现的位置、耗时和与计算的 - 重叠关系，不重复 Phase 2 的平均 GPU/CPU/RDMA 采集。原始双 Rail 带宽、整机 - CPU 容量和降频都不像首要瓶颈；Phase 3 将继续定位具体 Kernel 和同步根因。 -

- - -

返回 Phase 1 实验档案

-

返回推理优化主计划

-
- - diff --git a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html index 591781c..79e1a71 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html +++ b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html @@ -443,15 +443,14 @@ DeepSeek-V4-Pro / 双机 Pro6000D / SGLang 硬件与资源竞争归因 最终采集代码已完成；首轮 8/8 成功，Worker 分发修复与双节点通信 smoke test 已通过，等待最终正式复跑 - -打开 Phase 2 实验档案
-打开 Phase 2 代码详解 - +Phase 2 进行中；完成最终复跑与汇报后生成实验档案和代码详解

-阶段档案规范：正文只保留最终成功实验、有效结果和结论； -失败尝试压缩到末尾的经验教训。阶段完成时删除“暂不能下结论”等过渡内容。 +阶段档案生成门禁：Phase 在实验结束、结果汇总并完成汇报确认前， +不创建或维护 phaseN_exp.html 与 phaseN_code.html； +进行中只维护代码、原始结果和本页状态。阶段确认完成后再一次性生成两份最终 HTML， +正文只保留成功实验、有效结果和结论，失败尝试压缩到末尾的经验教训。

0. 先看懂双机通信

@@ -737,9 +736,8 @@ TPOT P95 增加 66.55%。Phase 2 将围绕这两个现象采集硬件时间序 不伪装成当前已有能力；它们分别由后续硬件指标与 Profiling 阶段补齐。

6. Phase 2：同步采集轻量硬件指标

-本阶段的设计、代码改动与结果同步维护在 - -Phase 2：硬件与资源竞争归因实验档案。本阶段重放长 Prefill、并发 Prefill、 +本阶段尚在进行中，按照阶段档案生成门禁，暂不生成实验档案和代码详解 HTML。 +当前代码与原始结果保留在仓库实验目录；本阶段重放长 Prefill、并发 Prefill、 普通 Decode、长输出 Decode、长上下文 Decode，以及 1K → 1K, C=32 的混合 A/B。首轮 Run dsv4pro-phase2-20260731-130125 在 26 分 26 秒内完成 8/8 个结果； diff --git a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.md b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.md index 9016a3d..46a842b 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.md +++ b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.md @@ -212,9 +212,8 @@ C = 16, 32, 48, 64, ... ## 6. Phase 2：同步采集硬件指标 -详细实现与运行命令见 -[Phase 2 实验档案](./phase2_exp.html)，实现说明见 -[Phase 2 代码详解](./phase2_code.html)。 +Phase 2 尚在进行中。按照阶段档案生成门禁，在最终正式复跑、结果汇总和汇报确认前， +不生成 `phase2_exp.html` 与 `phase2_code.html`。 首轮 8/8 benchmark 已完成；最终采集代码、Worker 分发修复和双节点通信 smoke test 已通过，等待最终正式复跑。