From e1719bd575a5d86cb4fe1c05fde333740f74a782 Mon Sep 17 00:00:00 2001
From: Zhiyi Hong <2497491955@qq.com>
Date: Sat, 1 Aug 2026 15:29:09 +0800
Subject: [PATCH] [Docs] finalize Phase 2.5 RDMA demand model
---
README.md | 4 +
.../6000D双机通信与NCCL术语入门.html | 20 +
.../phase2_5_code.html | 167 +++
.../phase2_5_exp.html | 166 +++
.../phase2_exp.html | 1 +
.../commands/confirm.cmd.txt | 1 +
.../commands/scout.cmd.txt | 1 +
.../confirm/bench_summary.csv | 7 +
.../confirm/case_rdma_summary.csv | 25 +
.../confirm/case_windows.csv | 7 +
.../confirm/collector_status.csv | 37 +
.../confirm/service/head_nccl_transport.log | 1012 +++++++++++++++++
.../confirm/service/head_server_cmd.txt | 1 +
.../confirm/service/worker_nccl_transport.log | 918 +++++++++++++++
.../confirm/service/worker_server_cmd.txt | 1 +
.../rdma_case_metrics.csv | 12 +
.../rdma_demand_model.json | 205 ++++
.../rdma_demand_report.md | 37 +
.../recommendation.env | 1 +
.../run_manifest.txt | 13 +
.../scenarios/confirm.tsv | 4 +
.../scenarios/scout.tsv | 6 +
.../scout/bench_summary.csv | 6 +
.../scout/case_rdma_summary.csv | 21 +
.../scout/case_windows.csv | 6 +
.../scout/collector_status.csv | 37 +
.../scout/service/head_nccl_transport.log | 1012 +++++++++++++++++
.../scout/service/head_server_cmd.txt | 1 +
.../scout/service/worker_nccl_transport.log | 918 +++++++++++++++
.../scout/service/worker_server_cmd.txt | 1 +
.../推理优化计划.html | 20 +-
31 files changed, 4661 insertions(+), 7 deletions(-)
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/phase2_5_code.html
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/phase2_5_exp.html
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/commands/confirm.cmd.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/commands/scout.cmd.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/bench_summary.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/case_rdma_summary.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/case_windows.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/collector_status.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/service/head_nccl_transport.log
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/service/head_server_cmd.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/service/worker_nccl_transport.log
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/confirm/service/worker_server_cmd.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/rdma_case_metrics.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/rdma_demand_model.json
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/rdma_demand_report.md
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/recommendation.env
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/run_manifest.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scenarios/confirm.tsv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scenarios/scout.tsv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/bench_summary.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/case_rdma_summary.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/case_windows.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/collector_status.csv
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/service/head_nccl_transport.log
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/service/head_server_cmd.txt
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/service/worker_nccl_transport.log
create mode 100644 docs/dsv4pro_pro6000d_2node_sglang/results/dsv4pro-phase2_5-20260801-130007/scout/service/worker_server_cmd.txt
diff --git a/README.md b/README.md
index e001456..3c0913a 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,9 @@
# sskj — 多平台大模型推理性能基准测试项目
+> **更新(2026-08-01 15:24:52 CST)**
+>
+> 完成 DeepSeek-V4-Pro 双机 Pro6000D SGLang Phase 2.5 RDMA 需求建模。正式 Run `dsv4pro-phase2_5-20260801-130007` 完成 Scout 5/5 与 Confirm 6/6;64K Prefill 在 C=16 已进入约 2,984 input tok/s、79.90 Gbit/s/rail 的平台,C=32/64 不再显著增长。拟合通信强度为 3.332 MB/input-token/rail,单 Rail 400G 需约 15,006 input tok/s,约为当前平台的 5 倍,因此当前是模型计算/实现吞吐先饱和,不是 RDMA 先饱和。新增 `phase2_5_exp.html`、`phase2_5_code.html`、精简证据集和可复用的模型部署 RDMA 需求评估流程;实验结束后双节点容器与 16 张 GPU 已清理。
+>
> **更新(2026-08-01 02:40:00 CST)**
>
> 新增 DeepSeek-V4-Pro 双机 Pro6000D SGLang Phase 2.5 RDMA 需求建模唯一入口。实验保持现有 TP16/EP2 服务参数不变,先以 `64K -> 1` 的 C=1/4/16/32/64 建立 Input TPS 与每 Rail HCA 带宽关系,再自动选择平台前、拐点和最大稳定并发,对 `64K -> 1K` 重复确认。结果将给出每 Token 跨机字节数、400G 所需 Token TPS、并发饱和曲线和“模型计算先饱和还是 RDMA 先饱和”的机器可读结论;正式结果尚未生成,因此暂不创建 Phase 2.5 HTML 档案。
diff --git a/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html b/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html
index e24993e..8a7dbd2 100644
--- a/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html
+++ b/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html
@@ -547,6 +547,26 @@ mlx5_3 port 1 ==> eth3 (Up)
查看系统或进程在各 NUMA 节点上的内存分布。 |
Phase 2 每 5 秒保存结构化 Node0/Node1 MiB,寻找跨 NUMA 内存放置。 |
+
+ | HCA Counter |
+ 网卡硬件维护的发送、接收、等待、丢弃和错误累计计数器。 |
+ Phase 2.5 用 mlx5_0/mlx5_3 的 counter 差值计算正式 benchmark 窗口内的 RDMA Gbit/s。 |
+
+
+ | bytes/input-token/rail |
+ 模型每处理一个输入 token,平均要在一条 Rail 上发送的字节数。 |
+ 当前 DSV4-Pro TP16/EP2 Scout 拟合为约 3.332 MB/token/rail;换模型或并行策略必须重新标定。 |
+
+
+ | 带宽平台 / 拐点 |
+ 继续增加并发后,吞吐与网络带宽都几乎不再增长的位置。 |
+ Phase 2.5 以相邻点的 Input TPS 和 Rail Mean 增益同时低于 5% 判断,当前拐点为 C=16。 |
+
+
+ | 渐近线 / 饱和上限 |
+ 饱和曲线在并发继续增大时逼近、但不会明显超过的预测上限。 |
+ 当前 64K Prefill 的拟合上限约 80.32 Gbit/s/rail,表示模型产流量上限,不表示网卡硬件只能跑 80G。 |
+
diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_code.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_code.html
new file mode 100644
index 0000000..fbb01f6
--- /dev/null
+++ b/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_code.html
@@ -0,0 +1,167 @@
+
+
+
+
+
+ Phase 2.5 Code:DSV4-Pro 双机 SGLang RDMA 需求建模
+
+
+
+
+
+ 返回推理优化主计划 · 打开 Phase 2.5 实验档案
+ 边界:Phase 2.5 不复制模型服务和采集器。它复用 Phase 1 的双机 TP16 服务/benchmark 与 Phase 2 的精确窗口、GPU/RDMA 采集能力,只新增“并发 Scout → 自动选点 → 业务 OSL Confirm → 需求拟合”这一层编排和分析。
+
+ 1. 文件职责与调用关系
+
+ | 文件 | 职责 | 调用关系 |
+
+ config.env | 定义 ISL/OSL、Scout 并发、重复次数、平台阈值和 400G 目标 | 被唯一入口 source |
+ run_rdma_demand_modeling.sh | 生成场景、调用 Phase 2、串行运行 Scout/Confirm、清理服务 | 唯一人工入口 |
+ rdma_demand_model.py | 对齐 benchmark/HCA 窗口,计算 bytes/token,拟合平台并生成报告 | Scout 后选点;Confirm 后最终汇总 |
+ test_rdma_demand_model.py | 覆盖 HCA counter 单位、平台选择、线性换算和拟合输出 | 本地/CI 回归测试 |
+ Phase 2 run_hardware_contention_attribution.sh | 启动服务、采集 Head/Worker、切正式测量窗 | 由 Phase 2.5 以环境变量调用 |
+ Phase 1 run_quick_map.sh | 双机服务启停与 SGLang benchmark | 由 Phase 2 内部复用 |
+
+
+ run_rdma_demand_modeling.sh all
+ ├─ validate_config + write_manifest
+ ├─ run_scout
+ │ ├─ write_scenario_file(64K→1, C=1/4/16/32/64)
+ │ ├─ Phase 2 all(服务 + 18 个采集器 + 5 Case)
+ │ └─ rdma_demand_model.py scout → recommendation.env
+ ├─ run_confirm
+ │ ├─ 读取自动选择的 C=4/16/64
+ │ ├─ Phase 2 all(重启服务 + 18 个采集器 + 每点 2 次)
+ │ └─ rdma_demand_model.py final
+ └─ Phase 2 stop → 双节点清理
+
+ 2. 配置层
+ config.env:5-7 通过相对路径找到 Phase 1/2,不依赖执行命令所在目录。config.env:10-16 定义 64K Scout 与 1K Confirm;18-21 定义 5% 平台阈值、400G 物理目标和 360G 实用目标。
+ ISL=65536
+SCOUT_OSL=1
+CONFIRM_OSL=1024
+SCOUT_CONCURRENCIES="1 4 16 32 64"
+SCOUT_REPETITIONS=1
+CONFIRM_REPETITIONS=2
+PLATEAU_GAIN_PCT=5
+TARGET_RAIL_GBPS=400
+PRACTICAL_RAIL_GBPS=360
+ SAMPLE_INTERVAL_S=1 只决定 HCA/GPU 时间序列分辨率;SCENARIO_TIMEOUT_S=7200 是单个 benchmark 的保护上限,不是期望耗时。
+
+ 3. Shell 唯一入口
+ 3.1 参数检查与场景生成
+ run_rdma_demand_modeling.sh:42-71 fail-fast 检查依赖脚本、整数参数和并发列表。73-100 生成 Phase 2 能读取的 TSV,并为每个形状生成稳定的 case id。
+ 3.2 复用 Phase 2,而不是复制采集代码
+ 103-134 构造一个数组命令,把场景、Case、重复次数和采样周期作为环境变量传给 Phase 2。它显式关闭 mixed case 与通信 microbenchmark,因为 Phase 2.5 只测模型 RDMA 需求,不重复已完成的硬件基线。
+ RUN_MIXED_CASE=0
+RUN_COMMUNICATION_BASELINE=0
+SCENARIO_FILE=.../scout.tsv
+FIXED_CASE_IDS=rdma_scout_...
+bash run_hardware_contention_attribution.sh all
+ 3.3 两阶段控制流
+ 136-152 跑完 Scout 后立即调用 Python,并写出 recommendation.env;154-180 读取推荐并发,生成 64K→1K Confirm。217-225 的 run_all 严格串行执行,异常信号触发 stop 清理。
+ 为什么服务会启动两次:Scout 结束后 Phase 2 会清理服务;Confirm 使用全新的 Prefix Cache、采集器和服务生命周期,避免 Scout 状态污染确认结果。
+
+ 4. Python 如何从计数器变成需求模型
+ 4.1 精确时间窗与 HCA 单位
+ rdma_demand_model.py:87-115 以 (case_id,repetition) 对齐 benchmark、窗口和 RDMA 汇总。117-147 在正式窗口内计算相邻 HCA counter 的速率;IB port_*_data 单位是 4-octet,因此必须乘 4,再乘 8 转为 bit/s。
+ gbps = (counter_delta × 4 bytes × 8 bits) / duration_s / 1e9
+ 4.2 单 Case 指标
+ 171-281 汇总四条观测边(Head/Worker × 两个 HCA)的 Rail Mean/P95/Max、双 Rail 单向合计、Rail 不均衡、错误计数和 GPU 利用率。通信强度按每条 Rail 平均发送字节计算:
+ bytes_per_input_token_per_rail
+= mean(head/worker × mlx5_0/mlx5_3 xmit_bytes)
+ / total_input_tokens
+ 这里不把 TX+RX 相加,因为那会把同一份跨机数据重复计数。
+
+ 4.3 平台、拐点与自动选点
+ 362-392 比较相邻并发点。只有 Rail Mean 与 Input TPS 增益同时低于 5%,当前点才是平台候选。随后选择平台前一点、平台点和最高稳定点;本 Run 得到 4 16 64。
+ if bandwidth_gain < 5% and input_tps_gain < 5%:
+ plateau_c = current_concurrency
+
+ 4.4 线性通信强度与饱和曲线
+ 352-360 用过原点线性斜率拟合 rail_gbps/input_tps,再还原为 bytes/token。318-350 用双曲线 B(C)=B∞×C/(K+C) 拟合并发饱和曲线;394-447 组合两者,判断模型计算或网络谁先到平台。
+ required_input_tps
+= target_rail_gbps / linear_gbps_per_input_tps
+
+if fitted_bandwidth_asymptote < 360:
+ verdict = COMPUTE_OR_MODEL_THROUGHPUT_LIMITED_BEFORE_RDMA_SATURATION
+ 本 Run 的 RMSE 为 0.277 Gbit/s,五个 Scout 点与饱和曲线贴合良好;拟合上限 80.32 Gbit/s,与 C=16/32/64 的 79.90/79.93/79.97 一致。
+
+ 5. 输出文件如何阅读
+
+ | 输出 | 用途 |
+
+ rdma_case_metrics.csv | 每次重复的 benchmark + GPU + Rail 对齐数据,是审计主表 |
+ rdma_demand_model.json | 完整拟合参数、平台点、目标 TPS 和最终 verdict |
+ rdma_demand_report.md | 面向人的 Scout/Confirm 摘要 |
+ recommendation.env | Shell 可直接 source 的 Confirm 并发列表 |
+ {scout,confirm}/case_windows.csv | 每个正式 benchmark 的精确起止时间 |
+ {scout,confirm}/{head,worker}/rdma.csv | 原始 HCA counter 时间序列,仅保留在服务器完整结果中 |
+ commands/*.cmd.txt | 实际传给 Phase 2 的完整可复现命令 |
+
+
+
+ 6. 测试与验收门槛
+
+ python3 -m unittest test_rdma_demand_model.py:4/4 通过。
+ bash -n run_rdma_demand_modeling.sh 与 Python compile:通过。
+ DRY_RUN=1 ... all:展开 5 个 Scout 和 3×2 个 Confirm,不启动服务。
+ - 正式 Run:Scout 5/5、Confirm 6/6;两个阶段各 18/18 个采集器正常启停,共保存 72 条 STARTED/STOPPED 生命周期事件。
+ - 11 个测量结果全部
COMPLETED,rdma_error_delta=0。
+ - 结束后 Head/Worker 均无实验容器,16 张 GPU 为 0 MiB / 0%。
+
+
+ 7. 行号索引
+
+ | 功能 | 文件与行 |
+
+ | 配置与路径 | config.env:3-36 |
+ | 校验与场景生成 | run_rdma_demand_modeling.sh:42-100 |
+ | Phase 2 调用 | run_rdma_demand_modeling.sh:103-134 |
+ | Scout / Confirm | run_rdma_demand_modeling.sh:136-180 |
+ | 唯一 all 与清理 | run_rdma_demand_modeling.sh:206-264 |
+ | HCA interval rate | rdma_demand_model.py:117-147 |
+ | Case 对齐汇总 | rdma_demand_model.py:171-281 |
+ | 饱和拟合 | rdma_demand_model.py:318-350 |
+ | 平台选点 | rdma_demand_model.py:362-392 |
+ | 需求模型与 verdict | rdma_demand_model.py:394-447 |
+ | 报告输出 | rdma_demand_model.py:449-517 |
+
+
+
+ 8. 复用时必须重新标定的边界
+ 这套代码可复用,但 3.332 MB/token/rail 不是通用常数。换模型、量化、TP/EP、节点切分、backend、Prefill/Decode 形状或 Prefix Cache 策略后,都必须重新跑 Scout。代码输出的是“当前部署实现的经验模型”,不是由参数量单独推导出的理论通信量。
+
+
+
diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_exp.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_exp.html
new file mode 100644
index 0000000..0cd60c6
--- /dev/null
+++ b/docs/dsv4pro_pro6000d_2node_sglang/phase2_5_exp.html
@@ -0,0 +1,166 @@
+
+
+
+
+
+ Phase 2.5:DSV4-Pro 双机 Pro6000D SGLang RDMA 需求建模
+
+
+
+
+
+ 返回推理优化主计划
+ 打开 Phase 2.5 代码详解
+
+ 阶段已完成。正式 Run 用时 2 小时 14 分 04 秒;Scout 5/5、Confirm 6/6 成功,两阶段各 18/18 个采集器正常启停。所有测量窗 RDMA 错误增量为 0,结束后两节点容器和 16 张 GPU 均已清理。
+
+ 1. 要回答的问题
+ Phase 2 只看到代表负载约 83.5 Gbit/s/rail,不能判断继续增加并发是否会逼近 400G。Phase 2.5 专门回答三个问题:
+
+ - 固定模型、TP/EP 和输入形状后,Input TPS 与每 Rail RDMA 带宽是什么关系?
+ - 并发增加到哪里后,模型吞吐和 RDMA 带宽不再增长?
+ - 要达到 400G,需要怎样的 Input TPS;当前瓶颈先出现在模型计算还是网络?
+
+
+ 2. 实验设计
+
+ | 阶段 | 请求形状 | 并发 | 重复 | 目的 |
+
+ | Scout | 64K → 1 | 1 / 4 / 16 / 32 / 64 | 1 | 隔离 Prefill,找吞吐与带宽平台 |
+ | Confirm | 64K → 1K | 自动选择 4 / 16 / 64 | 2 | 验证真实长输出不会推翻需求模型 |
+
+
+ 服务参数沿用 Phase 1/2:SGLang nightly、TP16、EP2、双 Rail mlx5_0/mlx5_3、NET/IB + GDRDMA。每个 Case 使用冷 Prefix,并按 benchmark 正式测量窗口切片 HCA Counter。
+
+ 3. 实际启动命令
+ 只在 Head 174.1.51.5 执行,不需要 source 或 conda activate:
+ cd /data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_rdma_demand_modeling
+
+RUN_ID=dsv4pro-phase2_5-20260801-130007
+tmux new-session -d -s dsv4pro-phase2_5 \
+ "RUN_ID=${RUN_ID} bash run_rdma_demand_modeling.sh all \
+ 2>&1 | tee /data/hzy/${RUN_ID}.log"
+
+tmux attach -t dsv4pro-phase2_5
+ 实际展开后的 Scout/Confirm 命令分别保存在结果目录的 commands/scout.cmd.txt 与 commands/confirm.cmd.txt。
+
+ 4. Scout 结果:并发 16 已进入平台
+
+ | C | Input TPS | Rail Mean | Rail P95 | Rail Max | 双 Rail 单向合计 | MB/input-token/rail | GPU Util |
+
+ | 1 | 2,709.64 | 70.97 Gbit/s | 85.60 | 86.81 | 141.94 | 3.138 | 93.75% |
+ | 4 | 2,930.49 | 78.27 Gbit/s | 86.82 | 88.86 | 156.55 | 3.298 | 97.45% |
+ | 16 | 2,983.77 | 79.90 Gbit/s | 86.42 | 88.20 | 159.79 | 3.336 | 99.33% |
+ | 32 | 2,983.92 | 79.93 Gbit/s | 86.23 | 88.22 | 159.86 | 3.344 | 99.49% |
+ | 64 | 2,991.28 | 79.97 Gbit/s | 85.93 | 88.32 | 159.95 | 3.340 | 99.64% |
+
+
+ 观察结论:C=16→32 的 Input TPS 只增长 0.005%,Rail Mean 只增长 0.040%;C=32→64 也仅增长 0.247% / 0.057%。并发 16 已是平台拐点,继续加到 64 只会增加排队和 TTFT,不会增加网络压力。
+ 证据:/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_rdma_demand_modeling/results/dsv4pro-phase2_5-20260801-130007/rdma_case_metrics.csv;原始 HCA 数据位于同一 Run 的 scout/head/rdma.csv 与 scout/worker/rdma.csv,精确窗口位于 scout/case_windows.csv。
+
+ 5. Confirm 结果:加入 1K Decode 后仍由计算先饱和
+
+ | C | 重复 | Input TPS | Output TPS | Rail Mean | Rail P95 | 双 Rail单向合计 | TTFT P95 | TPOT P95 |
+
+ | 4 | 2 | 2,072.24 | 32.38 | 57.33 Gbit/s | 86.28 | 114.66 | 86.36 s | 95.63 ms |
+ | 16 | 2 | 2,582.13 | 40.35 | 71.64 Gbit/s | 86.30 | 143.29 | 336.85 s | 356.24 ms |
+ | 64 | 2 | 2,588.96 | 40.45 | 72.19 Gbit/s | 86.69 | 144.38 | 1,506.50 s | 418.58 ms |
+
+
+ C=16→64 的 Input TPS 仅增长 0.26%,Rail Mean 仅增长 0.76%,但 TTFT P95 从 336.85 秒升至 1,506.50 秒。对于 64K→1K,最大有意义并发仍约为 16;C=64 是容量压力点,不是推荐服务点。
+ 证据:同一 Run 的 confirm/bench_summary.csv、confirm/case_rdma_summary.csv、confirm/case_windows.csv;两轮逐点数据在顶层 rdma_case_metrics.csv。
+
+ 6. 400G 能否被模型负载打满
+ Scout 的线性比例为:
+ 每 Rail 带宽(Gbit/s)
+≈ Input TPS × 3.332 MB/input-token/rail × 8 ÷ 1e9
+
+ | 目标口径 | 需要的 Input TPS | 当前约 2,991 TPS 的差距 |
+
+ | 单 Rail 400G | 15,006 tok/s | 约 5.02× |
+ | 单 Rail 360G(90% 实用线) | 13,505 tok/s | 约 4.51× |
+ | 双 Rail 单向合计 400G | 7,503 tok/s | 约 2.51× |
+
+
+ 拟合得到当前模型负载的单 Rail 渐近上限约 80.32 Gbit/s,即物理 400G 的约 20.1%。瞬时 Max 也只有 89.53 Gbit/s。结论不是“网络只能跑 80G”,而是当前 DSV4-Pro TP16/EP2 实现最多只能产生约 80G/rail 的持续 RDMA 流量;Phase 2 的 NCCL microbenchmark 已证明链路本身能达到更高通信带宽。
+ 口径提醒:400G 是每条 Rail 的线速;双 Rail 单向总量是两条 Rail 的 TX 之和。不要把 TX 与 RX 相加后声称打满,也不要把 NCCL busbw GB/s 与 HCA Gbit/s 直接比较。
+
+ 7. 一套可复用的 RDMA 需求评估方法
+
+ - 固定部署变量。记录模型版本、精度/量化、TP/EP/PP/DP、节点数、Attention/MoE backend、chunked prefill 和网卡拓扑。任一项变化都要重新标定。
+ - 先选 Prefill Scout。固定 ISL,OSL=1,取稀疏并发点如 1/4/16/32/64;每点清 Prefix Cache,并保证请求文本实际达到目标 token 数。
+ - 对齐正式测量窗。从 benchmark 的 main-run 起止时间切片 Head/Worker 的
mlx5_* HCA Counter,不能用整个进程寿命,也不能只看 sar eth*。
+ - 计算通信强度。
bytes_per_input_token_per_rail = rail_xmit_bytes / total_input_tokens。这是该模型与并行策略下“每处理一个输入 token,要在一条 Rail 发送多少字节”。
+ - 找并发平台。同时观察 Input TPS 和 Rail Mean;连续一点的增益都低于阈值(本实验 5%)时,记为拐点。最大 C 不等于最大有效 C。
+ - 推导目标吞吐。
required_input_tps = target_rail_gbps × 1e9 / (bytes_per_token × 8)。若模型的实测/拟合 TPS 上限远低于该值,网络不会先饱和。
+ - 用业务 OSL 复测。在平台前、拐点、最高压力点各重复至少两次,确认 Decode、KV Cache 和调度没有改变结论。
+ - 最后做链路对照。模型负载未打满时,用 NCCL microbenchmark 验证网络能力,把“模型产流量不足”与“网络本身跑不满”分开。
+
+
+ 7.1 哪些变量会改变 bytes/token 与平台
+
+ | 变量 | 可能改变的原因 |
+
+ | 模型架构与层数 | 每 token 触发的 TP collective、MoE dispatch/combine 和激活尺寸不同 |
+ | TP / EP / PP / DP | 通信参与 rank、跨机边界、collective 类型和频率改变 |
+ | Prefill / Decode、ISL / OSL | 计算强度、chunk 调度、KV 访问和 collective 消息粒度不同 |
+ | 并发与 batch | 决定 kernel/batch 效率和 Input TPS;超过平台后只增加排队 |
+ | 量化与 backend | 改变计算速度;通信字节可能不同比例变化,因此会移动“计算先饱和还是网络先饱和”的边界 |
+ | Prefix Cache | 命中会绕过大量 Prefill,必须单独作为另一类业务场景建模 |
+
+
+
+ 8. 最终结论
+ 在两台 Pro6000D、DSV4-Pro、SGLang TP16/EP2 的当前实现中,RDMA 不是吞吐瓶颈。64K Prefill 在 C=16 已达到约 3K input tok/s 和 80 Gbit/s/rail 的平台;继续增加并发到 64 不会显著增加吞吐或带宽,只会令 TTFT 急剧上升。要打满单 Rail 400G,模型侧 Input TPS 需提高到约 15K,约为当前上限 5 倍。因此后续优化应先看 GPU Kernel、MoE/Attention 执行和 rank 同步,而不是扩容计算网。
+
+ 9. 证据与清理
+
+ Worker 在最后一个 Case 完成后随 Head 主动关闭进程组出现 Gloo peer-close Traceback;它发生在测量结束与结果落盘之后,不是实验失败。最终 tmux、服务容器和 GPU 进程均已退出。
+
+
+
diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html
index 88a8cca..32b87e1 100644
--- a/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html
+++ b/docs/dsv4pro_pro6000d_2node_sglang/phase2_exp.html
@@ -805,6 +805,7 @@ tmux new-session -d -s dsv4pro-phase2 \
返回 Phase 1 实验档案
+ 继续 Phase 2.5 RDMA 需求建模
返回推理优化主计划