阶段已完成。正式 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. 证据与清理
- 自动 RDMA 需求报告
- 机器可读模型
- 全部逐点指标
- Run Manifest
- Scout Head 服务命令 / Worker 服务命令
- Confirm Head NCCL 路径 / Worker NCCL 路径
Worker 在最后一个 Case 完成后随 Head 主动关闭进程组出现 Gloo peer-close Traceback；它发生在测量结束与结果落盘之后，不是实验失败。最终 tmux、服务容器和 GPU 进程均已退出。