2026-08-01 15:29:26 +08:00

167 lines
14 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Phase 2.5DSV4-Pro 双机 Pro6000D SGLang RDMA 需求建模</title>
<style>
:root { --ink:#18202a; --muted:#5b6570; --line:#d8dde3; --paper:#fff; --page:#f3f5f7; --blue:#1769aa; --green:#16734a; --amber:#9a5a00; --code:#f0f3f6; }
* { box-sizing:border-box; letter-spacing:0; }
body { margin:0; background:var(--page); color:var(--ink); font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","PingFang SC",sans-serif; font-size:16px; line-height:1.68; }
header { background:#202a34; color:#fff; border-bottom:5px solid #34a17a; }
.header-inner, main { width:min(1120px,calc(100% - 32px)); margin:0 auto; }
.header-inner { padding:36px 0 30px; }
h1 { margin:4px 0 12px; font-size:clamp(27px,4vw,42px); line-height:1.2; }
h2 { margin:38px 0 12px; padding-bottom:7px; border-bottom:2px solid var(--line); font-size:24px; }
h3 { margin:26px 0 8px; font-size:19px; }
.eyebrow { margin:0; color:#8fd8bd; font-size:13px; font-weight:700; }
.meta { display:flex; flex-wrap:wrap; gap:8px 22px; color:#d7dee5; font-size:14px; }
main { margin-top:24px; margin-bottom:48px; padding:30px 38px 42px; background:var(--paper); border:1px solid var(--line); border-radius:6px; }
a { color:var(--blue); }
.back { display:inline-block; margin:0 16px 10px 0; font-weight:650; }
code { padding:1px 5px; background:var(--code); border-radius:3px; font-family:"SFMono-Regular",Consolas,monospace; font-size:.92em; overflow-wrap:anywhere; }
pre { overflow-x:auto; padding:14px 16px; background:#202a34; color:#f4f7fa; border-radius:5px; line-height:1.5; }
pre code { padding:0; background:transparent; color:inherit; }
table { width:100%; margin:14px 0 22px; border-collapse:collapse; font-size:14px; }
th,td { padding:10px 11px; border:1px solid var(--line); text-align:left; vertical-align:top; }
th { background:#edf1f4; }
.status,.decision,.warning { padding:14px 16px; }
.status { border-left:4px solid var(--green); background:#eef8f3; }
.decision { border-left:4px solid var(--blue); background:#edf5fb; }
.warning { border-left:4px solid var(--amber); background:#fff7e7; }
.metric { font-size:20px; font-weight:750; color:var(--green); }
li+li { margin-top:5px; }
@media (max-width:720px) { main{padding:22px 18px 30px} table{display:block;overflow-x:auto;white-space:nowrap} }
</style>
</head>
<body>
<header>
<div class="header-inner">
<p class="eyebrow">FINAL EXPERIMENT RECORD / PHASE 2.5</p>
<h1>DeepSeek-V4-Pro 双机 Pro6000D SGLangRDMA 需求建模与并发拐点</h1>
<div class="meta">
<span>Rundsv4pro-phase2_5-20260801-130007</span>
<span>拓扑TP16 / EP2 / 双 Rail RoCE</span>
<span>完成2026-08-01 15:14:11 CST</span>
</div>
</div>
</header>
<main>
<a class="back" href="./推理优化计划.html">返回推理优化主计划</a>
<a class="back" href="./phase2_5_code.html">打开 Phase 2.5 代码详解</a>
<p class="status"><strong>阶段已完成。</strong>正式 Run 用时 2 小时 14 分 04 秒Scout 5/5、Confirm 6/6 成功,两阶段各 18/18 个采集器正常启停。所有测量窗 RDMA 错误增量为 0结束后两节点容器和 16 张 GPU 均已清理。</p>
<h2>1. 要回答的问题</h2>
<p>Phase 2 只看到代表负载约 83.5 Gbit/s/rail不能判断继续增加并发是否会逼近 400G。Phase 2.5 专门回答三个问题:</p>
<ol>
<li>固定模型、TP/EP 和输入形状后Input TPS 与每 Rail RDMA 带宽是什么关系?</li>
<li>并发增加到哪里后,模型吞吐和 RDMA 带宽不再增长?</li>
<li>要达到 400G需要怎样的 Input TPS当前瓶颈先出现在模型计算还是网络</li>
</ol>
<h2>2. 实验设计</h2>
<table>
<thead><tr><th>阶段</th><th>请求形状</th><th>并发</th><th>重复</th><th>目的</th></tr></thead>
<tbody>
<tr><td>Scout</td><td>64K → 1</td><td>1 / 4 / 16 / 32 / 64</td><td>1</td><td>隔离 Prefill找吞吐与带宽平台</td></tr>
<tr><td>Confirm</td><td>64K → 1K</td><td>自动选择 4 / 16 / 64</td><td>2</td><td>验证真实长输出不会推翻需求模型</td></tr>
</tbody>
</table>
<p>服务参数沿用 Phase 1/2SGLang nightly、TP16、EP2、双 Rail <code>mlx5_0/mlx5_3</code><code>NET/IB + GDRDMA</code>。每个 Case 使用冷 Prefix并按 benchmark 正式测量窗口切片 HCA Counter。</p>
<h2>3. 实际启动命令</h2>
<p>只在 Head <code>174.1.51.5</code> 执行,不需要 <code>source</code><code>conda activate</code></p>
<pre><code>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&gt;&amp;1 | tee /data/hzy/${RUN_ID}.log"
tmux attach -t dsv4pro-phase2_5</code></pre>
<p>实际展开后的 Scout/Confirm 命令分别保存在结果目录的 <code>commands/scout.cmd.txt</code><code>commands/confirm.cmd.txt</code></p>
<h2>4. Scout 结果:并发 16 已进入平台</h2>
<table>
<thead><tr><th>C</th><th>Input TPS</th><th>Rail Mean</th><th>Rail P95</th><th>Rail Max</th><th>双 Rail 单向合计</th><th>MB/input-token/rail</th><th>GPU Util</th></tr></thead>
<tbody>
<tr><td>1</td><td>2,709.64</td><td>70.97 Gbit/s</td><td>85.60</td><td>86.81</td><td>141.94</td><td>3.138</td><td>93.75%</td></tr>
<tr><td>4</td><td>2,930.49</td><td>78.27 Gbit/s</td><td>86.82</td><td>88.86</td><td>156.55</td><td>3.298</td><td>97.45%</td></tr>
<tr><td>16</td><td>2,983.77</td><td>79.90 Gbit/s</td><td>86.42</td><td>88.20</td><td>159.79</td><td>3.336</td><td>99.33%</td></tr>
<tr><td>32</td><td>2,983.92</td><td>79.93 Gbit/s</td><td>86.23</td><td>88.22</td><td>159.86</td><td>3.344</td><td>99.49%</td></tr>
<tr><td>64</td><td>2,991.28</td><td>79.97 Gbit/s</td><td>85.93</td><td>88.32</td><td>159.95</td><td>3.340</td><td>99.64%</td></tr>
</tbody>
</table>
<p class="decision"><strong>观察结论:</strong>C=16→32 的 Input TPS 只增长 0.005%Rail Mean 只增长 0.040%C=32→64 也仅增长 0.247% / 0.057%。并发 16 已是平台拐点,继续加到 64 只会增加排队和 TTFT不会增加网络压力。</p>
<p><strong>证据:</strong><code>/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_rdma_demand_modeling/results/dsv4pro-phase2_5-20260801-130007/rdma_case_metrics.csv</code>;原始 HCA 数据位于同一 Run 的 <code>scout/head/rdma.csv</code><code>scout/worker/rdma.csv</code>,精确窗口位于 <code>scout/case_windows.csv</code></p>
<h2>5. Confirm 结果:加入 1K Decode 后仍由计算先饱和</h2>
<table>
<thead><tr><th>C</th><th>重复</th><th>Input TPS</th><th>Output TPS</th><th>Rail Mean</th><th>Rail P95</th><th>双 Rail单向合计</th><th>TTFT P95</th><th>TPOT P95</th></tr></thead>
<tbody>
<tr><td>4</td><td>2</td><td>2,072.24</td><td>32.38</td><td>57.33 Gbit/s</td><td>86.28</td><td>114.66</td><td>86.36 s</td><td>95.63 ms</td></tr>
<tr><td>16</td><td>2</td><td>2,582.13</td><td>40.35</td><td>71.64 Gbit/s</td><td>86.30</td><td>143.29</td><td>336.85 s</td><td>356.24 ms</td></tr>
<tr><td>64</td><td>2</td><td>2,588.96</td><td>40.45</td><td>72.19 Gbit/s</td><td>86.69</td><td>144.38</td><td>1,506.50 s</td><td>418.58 ms</td></tr>
</tbody>
</table>
<p>C=16→64 的 Input TPS 仅增长 0.26%Rail Mean 仅增长 0.76%,但 TTFT P95 从 336.85 秒升至 1,506.50 秒。对于 64K→1K<strong>最大有意义并发仍约为 16</strong>C=64 是容量压力点,不是推荐服务点。</p>
<p><strong>证据:</strong>同一 Run 的 <code>confirm/bench_summary.csv</code><code>confirm/case_rdma_summary.csv</code><code>confirm/case_windows.csv</code>;两轮逐点数据在顶层 <code>rdma_case_metrics.csv</code></p>
<h2>6. 400G 能否被模型负载打满</h2>
<p>Scout 的线性比例为:</p>
<pre><code>每 Rail 带宽Gbit/s
≈ Input TPS × 3.332 MB/input-token/rail × 8 ÷ 1e9</code></pre>
<table>
<thead><tr><th>目标口径</th><th>需要的 Input TPS</th><th>当前约 2,991 TPS 的差距</th></tr></thead>
<tbody>
<tr><td>单 Rail 400G</td><td class="metric">15,006 tok/s</td><td>约 5.02×</td></tr>
<tr><td>单 Rail 360G90% 实用线)</td><td>13,505 tok/s</td><td>约 4.51×</td></tr>
<tr><td>双 Rail 单向合计 400G</td><td>7,503 tok/s</td><td>约 2.51×</td></tr>
</tbody>
</table>
<p>拟合得到当前模型负载的单 Rail 渐近上限约 <strong>80.32 Gbit/s</strong>,即物理 400G 的约 20.1%。瞬时 Max 也只有 89.53 Gbit/s。结论不是“网络只能跑 80G”而是<strong>当前 DSV4-Pro TP16/EP2 实现最多只能产生约 80G/rail 的持续 RDMA 流量</strong>Phase 2 的 NCCL microbenchmark 已证明链路本身能达到更高通信带宽。</p>
<p class="warning"><strong>口径提醒:</strong>400G 是每条 Rail 的线速;双 Rail 单向总量是两条 Rail 的 TX 之和。不要把 TX 与 RX 相加后声称打满,也不要把 NCCL <code>busbw GB/s</code> 与 HCA <code>Gbit/s</code> 直接比较。</p>
<h2>7. 一套可复用的 RDMA 需求评估方法</h2>
<ol>
<li><strong>固定部署变量。</strong>记录模型版本、精度/量化、TP/EP/PP/DP、节点数、Attention/MoE backend、chunked prefill 和网卡拓扑。任一项变化都要重新标定。</li>
<li><strong>先选 Prefill Scout。</strong>固定 ISLOSL=1取稀疏并发点如 1/4/16/32/64每点清 Prefix Cache并保证请求文本实际达到目标 token 数。</li>
<li><strong>对齐正式测量窗。</strong>从 benchmark 的 main-run 起止时间切片 Head/Worker 的 <code>mlx5_*</code> HCA Counter不能用整个进程寿命也不能只看 <code>sar eth*</code></li>
<li><strong>计算通信强度。</strong><code>bytes_per_input_token_per_rail = rail_xmit_bytes / total_input_tokens</code>。这是该模型与并行策略下“每处理一个输入 token要在一条 Rail 发送多少字节”。</li>
<li><strong>找并发平台。</strong>同时观察 Input TPS 和 Rail Mean连续一点的增益都低于阈值本实验 5%)时,记为拐点。最大 C 不等于最大有效 C。</li>
<li><strong>推导目标吞吐。</strong><code>required_input_tps = target_rail_gbps × 1e9 / (bytes_per_token × 8)</code>。若模型的实测/拟合 TPS 上限远低于该值,网络不会先饱和。</li>
<li><strong>用业务 OSL 复测。</strong>在平台前、拐点、最高压力点各重复至少两次,确认 Decode、KV Cache 和调度没有改变结论。</li>
<li><strong>最后做链路对照。</strong>模型负载未打满时,用 NCCL microbenchmark 验证网络能力,把“模型产流量不足”与“网络本身跑不满”分开。</li>
</ol>
<h3>7.1 哪些变量会改变 bytes/token 与平台</h3>
<table>
<thead><tr><th>变量</th><th>可能改变的原因</th></tr></thead>
<tbody>
<tr><td>模型架构与层数</td><td>每 token 触发的 TP collective、MoE dispatch/combine 和激活尺寸不同</td></tr>
<tr><td>TP / EP / PP / DP</td><td>通信参与 rank、跨机边界、collective 类型和频率改变</td></tr>
<tr><td>Prefill / Decode、ISL / OSL</td><td>计算强度、chunk 调度、KV 访问和 collective 消息粒度不同</td></tr>
<tr><td>并发与 batch</td><td>决定 kernel/batch 效率和 Input TPS超过平台后只增加排队</td></tr>
<tr><td>量化与 backend</td><td>改变计算速度;通信字节可能不同比例变化,因此会移动“计算先饱和还是网络先饱和”的边界</td></tr>
<tr><td>Prefix Cache</td><td>命中会绕过大量 Prefill必须单独作为另一类业务场景建模</td></tr>
</tbody>
</table>
<h2>8. 最终结论</h2>
<p class="decision"><strong>在两台 Pro6000D、DSV4-Pro、SGLang TP16/EP2 的当前实现中RDMA 不是吞吐瓶颈。</strong>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 同步,而不是扩容计算网。</p>
<h2>9. 证据与清理</h2>
<ul>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/rdma_demand_report.md">自动 RDMA 需求报告</a></li>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/rdma_demand_model.json">机器可读模型</a></li>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/rdma_case_metrics.csv">全部逐点指标</a></li>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/run_manifest.txt">Run Manifest</a></li>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/scout/service/head_server_cmd.txt">Scout Head 服务命令</a> / <a href="./results/dsv4pro-phase2_5-20260801-130007/scout/service/worker_server_cmd.txt">Worker 服务命令</a></li>
<li><a href="./results/dsv4pro-phase2_5-20260801-130007/confirm/service/head_nccl_transport.log">Confirm Head NCCL 路径</a> / <a href="./results/dsv4pro-phase2_5-20260801-130007/confirm/service/worker_nccl_transport.log">Worker NCCL 路径</a></li>
</ul>
<p>Worker 在最后一个 Case 完成后随 Head 主动关闭进程组出现 Gloo peer-close Traceback它发生在测量结束与结果落盘之后不是实验失败。最终 tmux、服务容器和 GPU 进程均已退出。</p>
</main>
</body>
</html>