diff --git a/README.md b/README.md index cccf281..6fc2a21 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,13 @@ # sskj — 多平台大模型推理性能基准测试项目 +> **更新(2026-07-30 17:54:30 CST)** +> +> 为 DeepSeek-V4-Pro 双机 TP16 quick-map 加入 RDMA fail-closed 启动保护。唯一 Shell 入口现在只允许计算网 `eth0/eth3` 与其 RDMA HCA `mlx5_0/mlx5_3`,在两端预检并透传 `rdma_cm/uverbs0/uverbs3`,服务健康后必须从两端 NCCL INFO 日志证明 `NET/IB` 和两条 HCA 均已启用,否则 benchmark 不会开始。运行清单新增 RDMA 开关、强制校验和设备路径;语法、结果解析器单测、完整 dry-run 及非法网卡/HCA 负例均已通过,真机 NET/IB 验证与 Phase 1 重跑尚未执行。 +> +> **更新(2026-07-30 17:45:18 CST)** +> +> 修正 DeepSeek-V4-Pro 双机 TP16 quick-map 的 NCCL Socket 网卡错误。控制组确认服务容器未暴露 `/dev/infiniband`,NCCL 实际回退 `NET/Socket`;旧 quick-map 又误选低速非计算网,导致冷 1K/32K Prefill 比 `eth0` 计算网 Socket 控制组慢约 10.9 倍/13.25 倍。默认 `NCCL_SOCKET_IFNAME` 已改为 `eth0`;旧约 65 token/s 结果降级为事故证据,Phase 2 暂停并等待修正后的 Phase 1。新增双机通信/NCCL 术语 HTML、网络审计报告,并保留原 `/data/qqt/sskj` TP16 脚本不变。 +> > **更新(2026-07-30 16:38:41 CST)** > > 完成 DeepSeek-V4-Pro 双机 TP16 新旧脚本 TTFT 口径审计。确认旧产物受到 16 条 Warm-up、跨 Case 固定 Seed 递增长度、未清 Prefix Cache 及前一轮残留服务状态影响;同配置冷请求稳定复现约 16 秒/1K。新增 Phase 1 结果、脚本审计和 Phase 2 设计 HTML 档案,后续 Cold/Warm Prefix 指标分开报告。 diff --git a/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html b/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html new file mode 100644 index 0000000..677257b --- /dev/null +++ b/docs/dsv4pro_pro6000d_2node_sglang/6000D双机通信与NCCL术语入门.html @@ -0,0 +1,696 @@ + + + + + + 6000D 双机通信与 NCCL 术语入门 + + + +
+
+

Two-node communication primer

+

6000D 双机通信与 NCCL 术语入门

+
+ 节点:174.1.51.5 + 174.1.51.7 + 规模:16 GPU / TP16 + 版本:2026-07-30 17:54 CST +
+
+
+ +
+ + +
+

1. 先建立一张总图

+

+ SGLang 不会自己搬运 16 张 GPU 之间的 Tensor。模型代码发起 TP/MoE 通信, + NCCL 决定用什么算法、经过哪条链路把数据送到其他 rank。 +

+ +
+
SGLang执行模型层、TP16 和 EP2
+
CollectiveAllReduce、AllGather、ReduceScatter、AllToAll
+
NCCL构造 rank、ring/tree 和 channel
+
Transport机内 P2P/IPC;跨机 NET/IB 或 NET/Socket
+
硬件GPU、PCIe、HCA、网卡、光模块、交换机
+
+ +
+ 最重要的区分: + NCCL bootstrap 是“启动时要完成的一件事”; + NCCL_SOCKET_IFNAME 是“选择 IP 网卡的一个参数”; + NET/IBNET/Socket 才是 NCCL 实际搬运数据的传输后端。 +
+ +

两类跨机路径

+
+
+

理想路径:RDMA

+

GPU → HCA → RoCE 网络 → HCA → GPU

+

日志应出现 NET/IB,支持时还会出现 GDRDMA

+
+
+

回退路径:TCP Socket

+

GPU/CPU → Linux Socket → ethX → TCP/IP → ethX

+

日志会出现 Using network Socket。这不是报错,但性能通常低得多。

+
+
+ +

2. eth0 和 mlx5_0 不是同一个设备

+
+ 400G 是物理 Ethernet 端口的标称链路速率。 + eth0 是该端口的 Linux netdev/IP 入口; + mlx5_0 是映射到该端口的 RDMA Verbs/HCA 入口。 + 二者相关联,但不相等,也不代表 TCP 或 RDMA 应用一定能跑到 400G。 +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
名字属于哪一层负责什么本机实例
eth0Linux IP 网卡接口配置 IP、TCP/UDP、路由;由 NCCL_SOCKET_IFNAME 选择400 Gbit/s 计算网
eth3Linux IP 网卡接口第二条计算网 Rail400 Gbit/s 计算网
mlx5_0RDMA HCA / Verbs 设备NET/IB 使用;由 NCCL_IB_HCA 选择对应 eth0,挂 switch 1
mlx5_3RDMA HCA / Verbs 设备第二条 RDMA Rail对应 eth3,挂 switch 2
/dev/infiniband/uverbs0Linux 字符设备容器进程访问 RDMA Verbs 的入口对应 mlx5_0
+ +
mlx5_0 port 1 ==> eth0 (Up)
+mlx5_3 port 1 ==> eth3 (Up)
+ +

+ 同一条物理端口可以同时暴露 Linux IP 接口和 RDMA HCA。 + eth0 是 IP/Socket 世界的入口,mlx5_0 是 RDMA + Verbs 世界的入口。ibdev2netdev 输出的是映射关系,不是等号。 + 本项目部署时只把 eth0/eth3 作为节点间计算网。 +

+
同一条 400G 物理 Ethernet 端口
+├── eth0   -> Linux netdev -> IP / TCP Socket
+└── mlx5_0 -> RDMA HCA     -> RoCE / Verbs / GDRDMA
+

+ 400 Gbit/s = 50 GB/s 只是单方向理论线速。协议开销、PCIe、 + CPU、Socket 线程、消息大小和 collective 算法都会让实际 + algbw/busbw 低于或采用不同统计口径。 +

+ +

3. 核心术语字典

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
术语通俗解释在本项目中的意义
NCCLNVIDIA 的多 GPU 通信库,负责高效实现 collective 和点对点通信。SGLang TP16 每层跨 GPU 通信最终大量落到 NCCL。
rank一个通信参与者的编号。TP16 communicator 有 rank 0–15。两台机器各 8 个 GPU rank,共 16 个。
collective一组 rank 共同参与的通信操作。TP 常见 AllReduce、AllGather、ReduceScatter;MoE 还可能有 AllToAll。
RDMA远端直接内存访问。网卡可直接读写远端内存,减少 CPU 和内核数据拷贝。双机 TP16 希望使用的高速数据路径。
IBInfiniBand。既是一套高速网络体系,也常被 NCCL 用作 Verbs/RDMA 后端的统称。NCCL 日志里的 NET/IB 也可承载 RoCE,不代表交换机一定是原生 IB。
RoCERDMA over Converged Ethernet,在以太网上承载 RDMA。本项目的 400G 计算网类型。
HCAHost Channel Adapter,提供 RDMA 能力的适配器。mlx5_0mlx5_3
GDRDMAGPUDirect RDMA,让 HCA 直接访问 GPU 显存,减少经 CPU 内存中转。跨机 GPU 通信的理想路径,日志可见 via NET/IB/.../GDRDMA
Socket / TCP普通 IP 网络编程路径。NCCL 找不到 RDMA 时会使用。本次脚本实际发生的回退路径。
Rail一条相对独立的网络通道,通常由一张 HCA 和一套交换路径组成。mlx5_0/switch 1mlx5_3/switch 2 是双 Rail。
ring / treeNCCL 对 collective 的通信拓扑组织方式。NCCL_CROSS_NIC 决定同一 ring/tree 能否跨不同 NIC。
PFC / ECNRoCE 网络控制拥塞和丢包的机制。RDMA 出现 retry、pause 或吞吐抖动时由运维检查。
+ +

4. NCCL bootstrap 到底是什么

+

+ NCCL 本身不是进程启动器。SGLang 先启动各个 worker,NCCL communicator 初始化时, + rank 之间需要交换地址、唯一 ID、拓扑和连接信息,这段“先认识彼此”的过程就是 bootstrap。 +

+ +
    +
  1. 每个 rank 启动并获得自己的 rank ID。
  2. +
  3. 通过 IP Socket 交换 NCCL unique ID 和连接信息。
  4. +
  5. NCCL 探测 GPU、PCIe、HCA 和节点拓扑。
  6. +
  7. 构造 ring/tree/channel。
  8. +
  9. 选择真正的数据传输后端:P2P、SHM、NET/IB 或 NET/Socket。
  10. +
+ +
+ 容易误解的地方: + NCCL_SOCKET_IFNAME 不保证“只用于 bootstrap”。 + RDMA 正常时它主要承担 bootstrap;RDMA 失败并回退 Socket 后,它也会决定大块 Tensor + 数据走哪张 IP 网卡。 +
+ +

5. 常见 NCCL 参数

+ +

NCCL_SOCKET_IFNAME

+

筛选 NCCL 可使用的 Linux IP 接口。精确指定接口时可写:

+
NCCL_SOCKET_IFNAME="=eth0"
+ + +

NCCL_IB_HCA

+

筛选 NCCL 的 RDMA HCA。推荐使用精确匹配:

+
NCCL_IB_HCA="=mlx5_0:1,mlx5_3:1"
+

+ 这个变量只是“允许选择谁”,不会自动把宿主机 RDMA 设备送进容器。 + 容器还必须看到 /dev/infiniband/rdma_cm、 + uverbs0uverbs3。 +

+ +

NCCL_CROSS_NIC

+ + + + + + + + + + + + + + + + + + + + + +
行为适用直觉
0尽量让同一 ring/tree 在不同节点使用对应的同一条 Rail。每张 NIC 接不同交换机、跨 Rail 代价高的 rail-optimized 网络。
1允许同一 ring/tree 在不同节点使用不同 NIC。所有 NIC 进入同一网络 Fabric,跨 NIC 不构成额外问题。
2优先对应同一 NIC,但必要时允许跨 NIC。NCCL 默认的折中策略。
+
+ 本项目的 mlx5_0mlx5_3 分挂 switch 1/2, + 拓扑直觉上更偏向 0 或默认 2。最终值必须在 + 真正启用 NET/IB 后用 all_reduce 和 SGLang 端到端 A/B 决定。 + 当 NCCL 使用 NET/Socket 时,这个参数不参与路径选择。 +
+ +

NCCL_DEBUG 与 NCCL_DEBUG_SUBSYS

+
NCCL_DEBUG=INFO
+NCCL_DEBUG_SUBSYS=INIT,NET,GRAPH,TUNING
+

用于确认实际路径,诊断完成后应关闭,正式性能数据不要长期带 INFO 日志。

+ +

6. NCCL 日志速查

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
日志含义判断
Bootstrap: Using eth0:...初始化控制连接选择 eth0。只说明 bootstrap,尚不能证明数据走 RDMA。
NET/IB : Using ... mlx5_0 ...NCCL 已识别 RDMA HCA。RDMA 数据后端可用。
via NET/IB/.../GDRDMA跨机边通过 GPUDirect RDMA。理想证据。
NET/IB : No device found容器没有可用 RDMA 设备或驱动/权限不完整。继续看是否回退 Socket。
NET/Socket : Using 非计算网...跨机数据由普通 TCP Socket 传输。若误入低速非计算网,性能会严重受限。
via P2P/IPC同机 GPU 通过 CUDA P2P/IPC。机内路径,不代表跨机路径。
+ +

7. 2026-07-30 Prefill 变慢事故复盘

+

已观测事实

+ + + + + + + + + + + + + + + + + + + + +
冷缓存 Shape原脚本网络:eth0 Socketquick-map:错误的非计算网差异
1K → 1, C=1TTFT 1.458s / 693.1 input tok/sTTFT 15.88–16.04s / 约 64 tok/s约 10.9×
32K → 1, C=1TTFT 38.062s / 860.5 input tok/sTTFT 504.44s / 64.96 tok/s约 13.25×
+ +
+ 根因判断: + quick-map 没有把 RDMA 设备透传进容器,却把 NCCL_SOCKET_IFNAME + 设成低速非计算网。NCCL 回退 NET/Socket 后,TP16 跨机数据没有进入规定的 + eth0/eth3 计算网。NCCL_CROSS_NIC=1 在没有 NET/IB + 的情况下不是致因。 +
+ +

为什么旧日志还会比 38 秒更短

+

+ 旧矩阵脚本还有第二个独立因素:warmup_requests=16、固定 + seed=42、ISL/OSL/C 升序运行,而且从不 flush Prefix Cache。 + 因此旧日志混入缓存命中,不能直接与冷 Prefill 比较。 +

+ +
+ quick-map 现在只允许 eth0/eth3 和 + mlx5_0/mlx5_3,并会透传精确 RDMA 设备、强制检查两端 + NET/IB 日志。代码与 dry-run 已通过;下一步是真机启动验证, + 在拿到运行时证据前不进入 Kernel 归因。 +
+ +

8. 从宿主机到 NCCL 的排查清单

+
    +
  1. + 宿主机链路: + ethtool eth0ethtool eth3。 +
  2. +
  3. + HCA 映射: + ibdev2netdev,确认 mlx5_0→eth0、 + mlx5_3→eth3。 +
  4. +
  5. + 宿主机设备: + ls -l /dev/infiniband。 +
  6. +
  7. + 容器设备: + docker exec CONTAINER ls -l /dev/infiniband。 + 宿主机有、容器没有,NCCL 仍然用不了 RDMA。 +
  8. +
  9. + 运行时证据: + 用一次 NCCL_DEBUG=INFO 启动,搜索 + NET/IBNET/SocketGDRDMA。 +
  10. +
  11. + 硬件计数器: + 同时观察 eth0/eth3 流量和 RDMA 端口计数;不能只看环境变量。 +
  12. +
  13. + 端到端 A/B: + 冷缓存、同一 prompt、同一模型参数,仅改变一个网络变量。 +
  14. +
+ +

最小 RDMA 设备透传验证

+
docker run --rm \
+  --device=/dev/infiniband/rdma_cm \
+  --device=/dev/infiniband/uverbs0 \
+  --device=/dev/infiniband/uverbs3 \
+  IMAGE \
+  ls -l /dev/infiniband
+

+ 能看到设备只是第一关。最终仍必须从 NCCL INFO 中看到 NET/IB, + 并通过通信基准与 SGLang 结果确认。 +

+ +

9. 官方资料

+ + +

+ 返回推理优化主计划 +

+
+
+ + + + diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase1_dsv4pro_pro6000d_2node_sglang_quick_map.html b/docs/dsv4pro_pro6000d_2node_sglang/phase1_dsv4pro_pro6000d_2node_sglang_quick_map.html index 668a11b..7c6b70f 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/phase1_dsv4pro_pro6000d_2node_sglang_quick_map.html +++ b/docs/dsv4pro_pro6000d_2node_sglang/phase1_dsv4pro_pro6000d_2node_sglang_quick_map.html @@ -228,7 +228,7 @@
节点:174.1.51.5 + 174.1.51.7 拓扑:SGLang TP16 / EP2 - 更新:2026-07-30 15:46 CST + 更新:2026-07-30 17:54 CST
@@ -237,15 +237,19 @@ 返回推理优化主计划

- 阶段状态:提前结束,已进入硬件归因。 + 阶段状态:网络错误已定位,RDMA fail-closed 代码已完成,等待真机验证和重跑。 第一次真机 Run dsv4pro-pro6000d-2node-sglang-quick-20260730-140026 已验证双机服务可用,但因发现请求量和 Prefix Cache 口径问题而主动停止。 精简后的第二次 Run dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625 - 完成 3 个 Prefill 固定点后,发现输入吞吐稳定锁定在约 - 65 token/s。继续扫描 Decode 和混合流量不能解释该异常, - 因此用户决定中止第 4 个 Case,直接进入 Phase 2。 + 完成 3 个 Prefill 固定点后曾观察到约 65 token/s。 + 后续控制组确认 quick-map 容器看不到 RDMA,NCCL 回退 + NET/Socket,同时脚本把 Socket 接口设成了低速非计算网。 + 因此这 3 个结果不能作为模型、算子或 TP16 的性能基线,Phase 2 暂停, + 当前入口已固定计算网 eth0/eth3 与 + mlx5_0/mlx5_3,完成设备透传、日志强校验和 dry-run; + 只有真机日志证明 NET/IB 后才会重跑 Phase 1。 Manifest 终态为 ABORTED_EARLY_FOR_PHASE2; 两节点容器和 16 张 GPU 已清理。

@@ -261,7 +265,7 @@
  • 只测试 SGLang,不测试 vLLM。
  • 使用双机 16 卡完整实例,不做 PD 分离。
  • 不启用 MTP、EAGLE、DSpark 或其他投机解码。
  • -
  • 本轮不启用 Profiler;三个已完成 Case 可作为对应 Shape 的端到端基线。
  • +
  • 本轮不启用 Profiler;受错误 Socket 网络影响的三个旧 Case 仅保留为事故证据,不再作为端到端基线。
  • 不修改或调用旧的全天全量 Benchmark 脚本。
  • @@ -351,14 +355,19 @@ bash run_quick_map.sh stop 覆盖固定矩阵中的 Decode C64 - NCCL bootstrap - eth1 - 普通 TCP 建连接口 + NCCL Socket 接口 + eth0 + RDMA 失败回退时也承载跨机 Tensor,不只是 bootstrap RoCE HCA mlx5_0,mlx5_3 - 双 Rail 数据面,NCCL_CROSS_NIC=1 + 启动器只透传对应的 uverbs0/uverbs3rdma_cm + + + 传输后端门禁 + REQUIRE_NCCL_IB=1 + 两端日志未证明 NET/IB + mlx5_0 + mlx5_3 时禁止开始 benchmark 代码分支 @@ -565,38 +574,43 @@ wait "${background_pid}" -

    9.1 可以下的结论

    +

    + 这些数值已被降级为“错误网络路径复现”。 + 它们可以证明低速 Socket 路径近似随输入长度线性增长,但不能用于判断 + DeepSeek-V4-Pro、SGLang Kernel、GPU 算力或正确 TP16 数据面的性能。 +

    + +

    9.1 对错误网络 Run 可以下的结论

    9.2 现在还不能下的结论

    9.3 为什么提前结束

    - Phase 1 的目标是发现值得归因的关键异常,而不是机械完成九个格子。 - 三个独立长度已经给出同一个稳定信号;第 4 个并发 Prefill 在 922 秒后仍表现为 - 单序列 Chunk 推进。继续执行剩余矩阵预计还需数小时,却不能回答 - “这 65 token/s 到底卡在哪里”。因此第 4 个 Case 被写入 - EARLY_STOP_FOR_PHASE2,其余固定点和混合 A/B 保留为未执行。 + 当时根据约 65 token/s 的稳定信号提前停止第 4 个 Case,并写入 + EARLY_STOP_FOR_PHASE2。后续网络控制组表明这个停止动作仍然避免了 + 无效算力消耗,但调查方向需要修正:不是立即进入 Kernel/硬件归因,而是先校正 + NCCL 数据面并重跑快速地图。

    -

    9.4 为什么旧脚本的 TTFT 短很多

    +

    9.4 为什么旧脚本的 TTFT 短很多:缓存与网络两个因素

    2026-07-30 对旧目录 /data/qqt/sskj/experiments/pro6000/dsv4_pro6000_sglang_tp16 - 做了逐项审计。结论是:旧结果与本轮冷 Prefill 不是同一缓存口径, - 不是 quick-map 把相同请求跑慢了。 + 做了逐项审计,并追加原网络配置冷请求控制组。最终结论是: + 旧结果与 quick-map 既不是同一缓存口径,也不是同一 Socket 网络路径。

    @@ -606,8 +620,8 @@ wait "${background_pid}" - - + + @@ -645,10 +659,10 @@ wait "${background_pid}" - - - - + + + +
    服务端配置 同一镜像,TP16 / EP2,8K Chunk,FlashInfer MXFP4 MoE相同排除明显的启动参数回归模型参数相同,但 NCCL/IP 接口不同不能排除网络启动参数回归
    正式请求数
    最小复现Mean TTFTP95 TTFT解释
    1K→1,首次冷缓存16.04 s16.04 s清 Prefix Cache,1 条正式请求
    1K→1,原样再次冷缓存15.90 s15.90 s再次清 Cache,排除一次性 JIT 主导
    1K→128,冷缓存15.79 s15.79 s排除 OSL=1 特殊慢路径
    旧命令语义重新复现14.60 s15.97 s10 条正式请求、16 条 Warm-up、不清 Cache
    quick-map 错误网络,1K→1 冷缓存15.88–16.04 s15.88–16.04 s低速非计算网 Socket 路径
    旧原始网络,1K→1 冷缓存1.458 s1.458 seth0 400G 物理端口上的 Socket 路径
    旧原始网络,32K→1 冷缓存38.062 s38.062 s比 quick-map 的 504.44 s 快约 13.25 倍
    quick-map,1K→128 冷缓存15.79 s15.79 s排除 OSL=1 特殊慢路径,但仍受错误网络影响
    2026-07-28 旧产物0.455 s0.513 s服务已被前一次 Run 和后续递增长度预热
    @@ -659,9 +673,7 @@ wait "${background_pid}" Input TPS,因此会把只计算新增后缀的耗时除进完整 token 数,进一步放大吞吐。

    - 审计结论:Phase 1 的约 65 token/s 是冷 Prefix Cache 的完整 Prompt 路径, - 旧结果是热缓存/递增前缀路径。两者都可以测,但必须分成 Cold 与 Warm 两套实验, - 不能放在同一列直接比较。审计原始产物保存在: + 缓存审计原始产物保存在:

    /data/hzy/dsv4_script_audit_20260730/

    @@ -670,6 +682,42 @@ wait "${background_pid}" 及同目录原始 JSON/log。

    +

    9.5 NCCL 数据面控制组

    +

    + 原脚本控制组使用其默认 NCCL_SOCKET_IFNAME=eth0,不注入 + NCCL_IB_HCANCCL_CROSS_NIC。NCCL INFO 和容器设备 + 检查给出了直接证据: +

    +
    NET/IB : No device found
    +NET/Socket : Using [0]eth0:10.101.0.11
    +Using network Socket
    +
    +docker exec ... ls /dev/infiniband
    +# No such file or directory
    +

    + 宿主机本身存在 uverbs0/uverbs3/rdma_cm,且 + mlx5_0→eth0mlx5_3→eth3 均 Up。这说明问题位于 + 容器设备透传和脚本网卡选择,不是物理计算网缺失。quick-map 与原脚本使用相同 + Docker 设备边界,却把 Socket 接口设成了低速非计算网,造成 10–13 倍退化。 + 在 NET/Socket 路径上,NCCL_CROSS_NIC=1 不参与选择。 +

    +

    + 修正后的唯一入口已加入三层门禁:两端字符设备预检、Docker 精确 + --device 透传、健康后 NCCL INFO 传输后端验证。静态检查、 + 结果解析器单测和完整 dry-run 已通过;非法 eth1 或 + mlx5_1 会在加载模型前被拒绝。该结论仍属于代码验证, + 真机 NET/IB 成功证据要等下一次启动后补入。 +

    +

    + 网络控制组原始产物: +

    +
    /data/hzy/dsv4_oldscript_cold_control_20260730/
    +

    + 本地归档: + TP16 网络路径审计报告 + 及同目录 NCCL/benchmark 原始日志。 +

    + @@ -679,12 +727,13 @@ wait "${background_pid}" - + - + + - +
    服务健康通过端口 30002 已就绪,无 OOM、NCCL 或 Engine 异常
    服务健康通过端口可用且无 OOM/Engine 异常,但 NCCL 数据面未按预期进入 RDMA
    第一次固定点 Run主动停止发现 32K 单请求约需十余分钟;原协议的 4 次同形状请求会使整轮再次接近半天
    精简后九个固定点3 完成 / 1 中止 / 5 未执行Prefill 异常信号已足够清晰,停止继续消耗算力
    RDMA fail-closed 启动器静态验证通过仅允许两条计算网 Rail;设备透传、日志强校验与运行清单已加入
    精简后九个固定点旧 Run 作废,待重跑先完成真机 NET/IB 验证,再生成新的性能基线
    混合干扰 A/B未执行待 Prefill 根因明确后再决定是否重放
    阶段耗时约 65 分钟14:36:26 启动,15:41:52 完成进程与容器清理
    是否进入下一阶段用户决定立即进入 Phase 2 硬件指标归因
    是否进入下一阶段Phase 2 暂停;先证明双 Rail NET/IB 并重跑 Phase 1
    diff --git a/docs/dsv4pro_pro6000d_2node_sglang/phase2_dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution.html b/docs/dsv4pro_pro6000d_2node_sglang/phase2_dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution.html index 50ba21b..b75a520 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/phase2_dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution.html +++ b/docs/dsv4pro_pro6000d_2node_sglang/phase2_dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution.html @@ -135,7 +135,7 @@
    节点:174.1.51.5 + 174.1.51.7 拓扑:SGLang TP16 / EP2 - 更新:2026-07-30 16:35 CST + 更新:2026-07-30 17:54 CST
    @@ -144,53 +144,55 @@ 返回推理优化主计划

    - 当前状态:旧脚本口径审计完成,Phase 2 代码尚未开始。 + 当前状态:网络前置条件未满足,Phase 2 暂停,代码尚未开始。 本页从第一行 Phase 2 代码开始同步维护。每次代码改动、静态验证、真机运行和 结果判断都会在对应小节留下文件路径、命令和证据,不在阶段结束后凭记忆补写。

    -

    1. 为什么立即进入 Phase 2

    +

    1. 为什么现在不能直接进入 Phase 2

    - Phase 1 在没有 Profiler、没有 Prefix Cache 命中的条件下得到以下结果: + Phase 1 在没有 Profiler、没有 Prefix Cache 命中的条件下得到以下结果, + 但这些数值后来确认受错误 Socket 网络路径污染:

    - - - + + +
    ISL / OSL / C输入 TPSTTFT结果
    1K / 1 / 164.44 tok/s15.88 s完成
    32K / 1 / 164.96 tok/s504.44 s完成
    128K / 1 / 165.20 tok/s2010.38 s完成
    1K / 1 / 164.44 tok/s15.88 s错误网络证据,不作为基线
    32K / 1 / 164.96 tok/s504.44 s错误网络证据,不作为基线
    128K / 1 / 165.20 tok/s2010.38 s错误网络证据,不作为基线

    - 三个长度的输入吞吐几乎相同,TTFT 近似按 token 数线性增加。 - 这已经不是“继续扩充 Shape”能回答的问题。Phase 2 要回答: - 稳定的约 65 token/s 到底受 GPU 计算、显存、CPU 调度还是双机通信中的哪一项限制。 + quick-map 容器没有 /dev/infiniband,NCCL 回退 + NET/Socket;脚本又误选低速非计算网。原网络配置冷请求控制组中, + 1K/32K TTFT 分别只有 1.458s/38.062s,比 quick-map 快约 10.9×/13.25×。 + 因此约 65 token/s 不是待 profile 的模型现象,而是已定位的部署配置错误。

    1.1 Phase 2 前置审计

    - 旧脚本较短的 TTFT 已确认不是同口径反例。旧脚本固定执行 16 条同 Prompt + 旧脚本较短的 TTFT 包含两个因素。其一,旧脚本固定执行 16 条同 Prompt Warm-up,从不清 Prefix Cache,并按固定 Seed 递增长度;17:40 的失败 Run - 还在 18:01 正式 Run 前预热了同一批 1K 请求。全字段比较显示新旧 - server_info 的关键运行参数相同。 + 还在 18:01 正式 Run 前预热了同一批 1K 请求。其二,新旧模型参数虽相同, + NCCL Socket 接口不同,而二者容器都没有形成真实 RDMA 数据面。

    - 同一服务上的最小复现得到:两次独立清 Cache 的 1K→1 TTFT 分别为 - 16.04 秒和 15.90 秒;把 OSL 改为 128 后是 15.79 秒;按旧命令语义重新执行 - 仍为 14.60 秒,而不是旧产物的 0.455 秒。因此 Phase 2 将继续 profile - 清 Prefix Cache 后的完整冷 Prefill。Warm Prefix/Prefix Cache - 收益另立 A/B,不与本阶段混算。 + 网络控制组明确打印 NET/IB : No device found 和 + Using network Socket。Phase 1 入口现已加入 RDMA 设备透传与 + NET/IB fail-closed 校验,但真机验证尚未运行。Phase 2 只有在 + 双 Rail RDMA 得到运行时证据并重跑 Phase 1 后才会开始。Warm Prefix/Prefix Cache + 收益仍另立 A/B,不与冷 Prefill 混算。

    2. 本阶段的边界

    @@ -311,13 +313,15 @@ dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution/ 2026-07-30 15:46 CST创建 Phase 2 设计与档案代码尚未开始,等待按本页设计实现 2026-07-30 16:35 CST完成旧脚本与 quick-map 同口径审计排除服务参数、OSL=1 和一次性 JIT;确认旧产物被 Warm-up、跨 Case 与前一轮 Prefix Cache 污染 + 2026-07-30 17:30 CST完成原网络配置冷请求控制组确认 quick-map 误入低速非计算网 Socket;Phase 2 暂停,先修正并重跑 Phase 1 + 2026-07-30 17:54 CST完成 Phase 1 RDMA fail-closed 代码与 dry-run只允许 eth0/eth3 与 mlx5_0/mlx5_3;等待真机 NET/IB 证据

    10. 真机结果

    - 尚未运行。代码实现、静态验证和 Dry-run 完成后,将先向用户说明具体代码改动, - 再启动真机诊断。 + 尚未运行,也不应立即运行。先获得修正网络后的 Phase 1 冷 32K 基线; + Phase 2 代码实现、静态验证和 Dry-run 完成后,再向用户说明具体改动并等待阶段门。

    返回 Phase 1 实施记录

    diff --git a/docs/dsv4pro_pro6000d_2node_sglang/results/network-path-audit-20260730/report.md b/docs/dsv4pro_pro6000d_2node_sglang/results/network-path-audit-20260730/report.md new file mode 100644 index 0000000..99a8d34 --- /dev/null +++ b/docs/dsv4pro_pro6000d_2node_sglang/results/network-path-audit-20260730/report.md @@ -0,0 +1,104 @@ +# DeepSeek-V4-Pro TP16 网络路径审计 + +- 时间:2026-07-30 +- 节点:`174.1.51.5 + 174.1.51.7` +- 模型:DeepSeek-V4-Pro +- 引擎:SGLang nightly +- 拓扑:TP16 / EP2 / 2 nodes + +## 结论 + +Phase 1 quick-map 的约 65 input token/s 不是可直接归因给模型、Kernel 或 GPU +的性能基线。它同时受两个独立因素影响: + +1. quick-map 容器没有 RDMA 设备,NCCL 回退 `NET/Socket`。 +2. quick-map 的 `NCCL_SOCKET_IFNAME` 误选低速非计算网,Socket 数据没有进入 + 部署规定的 `eth0/eth3` 计算网。 + +`NCCL_CROSS_NIC=1` 不是本次 10 倍以上退化的原因。该参数只有在 NCCL +真正使用多个 RDMA HCA 时才影响 ring/tree 的 NIC 选择;本次实际后端为 Socket。 + +## 设备关系 + +部署时只使用两条节点间计算网: + +| 物理端口 | Linux netdev/IP 入口 | RDMA Verbs/HCA 入口 | 状态 | +|---|---|---|---| +| 400G Rail 1 | `eth0` | `mlx5_0` | Up | +| 400G Rail 2 | `eth3` | `mlx5_3` | Up | + +`eth0` 与 `mlx5_0` 不是同一个软件设备。它们是同一条 400G 物理 Ethernet +端口的两种入口:前者服务 IP/TCP Socket,后者服务 RoCE/RDMA Verbs。 + +## 运行时证据 + +宿主机存在: + +```text +/dev/infiniband/rdma_cm +/dev/infiniband/uverbs0 +/dev/infiniband/uverbs3 +``` + +按原脚本启动的容器内: + +```text +ls: cannot access '/dev/infiniband': No such file or directory +``` + +NCCL INFO: + +```text +NCCL_SOCKET_IFNAME set by environment to eth0 +Bootstrap: Using eth0:10.101.0.11 +NET/IB : No device found. +Failed to initialize NET plugin IB +NET/Socket : Using [0]eth0:10.101.0.11 +Using network Socket +``` + +## 冷缓存对照 + +共同条件: + +- 同一模型、镜像、TP16/EP2 和 serving 参数。 +- `random` 数据集,`seed=42`。 +- `warmup_requests=0`。 +- 测量前 `--flush-cache`。 +- `num_prompts=1`、`max_concurrency=1`。 + +| Shape | 原脚本网络:`eth0` Socket | quick-map 错误网络 | 退化 | +|---|---:|---:|---:| +| 1K -> 1 | TTFT 1.458s;693.1 input tok/s | TTFT 15.88-16.04s;约 64 tok/s | 约 10.9x | +| 32K -> 1 | TTFT 38.062s;860.5 input tok/s | TTFT 504.44s;64.96 tok/s | 约 13.25x | + +## 旧矩阵为什么还能更快 + +旧矩阵结果还有 Prefix Cache 污染: + +- 每个 case 固定 16 条相同首个 prompt 的 warm-up。 +- benchmark 默认 `seed=42`,每次使用相同 ShareGPT shuffle 顺序。 +- ISL、OSL 和并发升序运行。 +- 从不传 `--flush-cache`。 +- 17:40 的失败 Run 已执行过首个 1K case,18:01 正式 Run 复用同一服务。 + +所以旧 1K 的 0.455s、32K 的 32.03s 和 128K 的 130.44s 不是完整冷 +Prefill,不能与任一冷缓存结果直接比较。 + +## 修复顺序 + +1. 当前 Socket baseline 默认改为 `NCCL_SOCKET_IFNAME=eth0`。 +2. 重跑 Phase 1 的冷 1K/32K/128K 代表点。 +3. 单独给容器透传 `rdma_cm`、`uverbs0`、`uverbs3`。 +4. 用 `NCCL_DEBUG=INFO` 确认出现 `NET/IB`,不能只看环境变量。 +5. 真正启用双 Rail RDMA 后,再比较 `NCCL_CROSS_NIC=0/1/2`。 +6. 以修正后的端到端结果决定是否进入 Phase 2 硬件归因。 + +## 产物 + +- `head_server.log` +- `worker_server.log` +- `oldscript_network_cold_1k_o1.log` +- `oldscript_network_cold_1k_o1.jsonl` +- `oldscript_network_cold_32k_o1.log` +- `oldscript_network_cold_32k_o1.jsonl` diff --git a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html index 8e1bbec..af9af15 100644 --- a/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html +++ b/docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html @@ -400,7 +400,7 @@
    节点:174.1.51.5 + 174.1.51.7 资源:16 × RTX PRO 6000 Blackwell - 版本:2026-07-30 15:52 CST + 版本:2026-07-30 17:54 CST
    @@ -415,7 +415,7 @@

    6000D 双机 DeepSeek-V4-Pro 推理优化计划

    -

    适用环境:174.1.51.5 + 174.1.51.7,每台 8 张 RTX PRO 6000 Blackwell Server Edition
    当前部署:DeepSeek-V4-Pro,16 张 GPU 组成一个完整实例
    当前约束:模型暂时只能使用全部 16 张 GPU,无法额外复制一套模型进行 PD 分离
    计划版本:2026-07-30 15:52 CST

    +

    适用环境:174.1.51.5 + 174.1.51.7,每台 8 张 RTX PRO 6000 Blackwell Server Edition
    当前部署:DeepSeek-V4-Pro,16 张 GPU 组成一个完整实例
    当前约束:模型暂时只能使用全部 16 张 GPU,无法额外复制一套模型进行 PD 分离
    计划版本:2026-07-30 17:54 CST

    当前执行状态与阶段档案

    @@ -428,16 +428,57 @@ + + + + + - + - +
    6000D 双机通信与 NCCL 基础已建立;覆盖计算网、RDMA、Bootstrap、NCCL 参数和日志判读打开通信术语入门
    DeepSeek-V4-Pro / 双机 Pro6000D / SGLang TP16 快速性能地图提前结束;3 个冷 Prefill 点完成,输入吞吐稳定约 65 token/s;旧脚本缓存口径审计已完成网络错误已定位;RDMA fail-closed 代码与 dry-run 已完成,待真机 NET/IB 验证后重跑 打开实施记录
    DeepSeek-V4-Pro / 双机 Pro6000D / SGLang Prefill 硬件指标归因设计已固化;代码尚未开始设计已固化、代码尚未开始;等待修正后的 Phase 1 基线 打开 Phase 2 档案
    +

    0. 先看懂双机通信

    +

    +在分析 TP16 性能前,先区分设备、传输后端与 NCCL 参数。 +完整解释和本次网络误配置复盘见 +《6000D 双机通信与 NCCL 术语入门》。 +

    + + + + + + + + + + + + + + + +
    术语一句话解释本项目实例
    NCCLNVIDIA 多 GPU 通信库,执行 collective 和点对点通信SGLang TP16 的跨 GPU 通信层
    RDMA网卡绕过常规 TCP/内核拷贝直接访问远端内存双机高速数据面的目标路径
    IB / RoCEIB 是高速网络/Verbs 体系;RoCE 在以太网上承载 RDMANCCL 日志统一显示为 NET/IB
    eth0/eth3400G 物理端口的 Linux netdev/IP 入口仅这两个接口用于节点间部署通信
    mlx5_0/mlx5_3映射到上述物理端口的 RDMA Verbs/HCA 入口eth0/eth3 有映射关系,但不是同一个软件设备
    NCCL bootstraprank 启动时交换身份、地址、拓扑和连接信息的阶段先建连,再选择真正的数据后端
    NCCL_SOCKET_IFNAME选择 NCCL 可用的 IP 接口RDMA 失败时也决定 Socket 数据走哪张网卡
    NCCL_IB_HCA选择 NCCL 可用的 RDMA HCAmlx5_0,mlx5_3
    NCCL_CROSS_NIC控制同一 ring/tree 能否在节点间跨不同 HCA只有真正使用多 HCA NET/IB 时才有意义
    +

    +400G 是每条物理 Ethernet 链路的标称线速,不是“TCP 速度”或“RDMA +速度”。同一条链路可以承载 TCP,也可以承载 RoCE/RDMA; +400 Gbit/s ≈ 50 GB/s 只是单向理论上限,NCCL 的 +algbw/busbw 与端到端模型吞吐都不能直接等同于该数字。 +

    +
    +

    +2026-07-30 已确认:当时容器内没有 /dev/infiniband,NCCL 日志显示 +NET/IB : No device found 并回退 NET/Socket。quick-map 又误选 +低速非计算网,因此 1K/32K 冷 Prefill 比原脚本的 eth0 Socket 路径慢约 +10.9×/13.25×。这不是 NCCL_CROSS_NIC=1 导致的。 +

    +

    1. 目标与原则

    1.1 最终目标

    在不做 PD 分离的前提下,定位 DeepSeek-V4-Pro 在双机 6000D 上的端到端瓶颈,并提高:

    @@ -469,7 +510,7 @@ H1 TP16 每层跨机通信暴露过多 -两台机器没有跨机 NVLink,TP Collective 需要经过 RoCE +两台机器没有跨机 NVLink;应先确保 Collective 真正经过计算网/RDMA,而不是 Socket 回退 H2 @@ -725,6 +766,20 @@ numastat -p <PID>
  • CPU 空洞是否对应 GPU 空洞。
  • 6.3 网络

    +
    +

    +2026-07-30 控制组已确认:宿主机具备 mlx5_0/eth0 与 +mlx5_3/eth3 两条 400G Rail,但原服务容器没有 +/dev/infiniband,NCCL 实际使用 NET/Socket。 +当前第一优先级是校正容器数据面并重做 Phase 1,不再把约 65 token/s 当作模型或算子瓶颈。 +

    +
    +

    +唯一启动入口现已在两端预检并透传 +rdma_cm/uverbs0/uverbs3,且服务健康后强制从两端 NCCL INFO +日志确认 NET/IB 同时识别 mlx5_0/mlx5_3。代码、 +单测与 dry-run 已通过;真机服务尚未启动,因此这里仍不宣称 RDMA 已验证成功。 +

    当前拓扑中需要分别观察两条 Compute Rail,确认: