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。代码输出的是“当前部署实现的经验模型”，不是由参数量单独推导出的理论通信量。