背景概述

在基于 Atlas 900 A3 SuperPoD 架构的分布式训练场景中，集合通信（HCCL）是实现多节点高效协同训练的核心机制。为验证系统通信能力，通常采用 hccl_test 工具进行多机打流测试。测试过程中，若出现超节点内通信正常，但跨超节点通信失败的情况，需结合日志、链路状态及运行环境深入排查。本文针对此类典型问题，从现象分析、根因定位到解决方案进行系统性梳理，为开发者提供可复用的排查思路与应对策略。

问题现象

在执行 hccl_test 多机打流测试时，观察到以下现象：

同一超节点内的卡间通信正常，数据传输稳定；

跨超节点的卡间通信无法建立，打流失败，日志中出现连接超时或通信中断。

故障排查过程

1. 日志分析：卡间 Socket 建链超时

通过分析 plog 日志，发现跨超节点的卡间通信在建立 Socket 连接阶段出现超时，提示 socket connect timeout，初步判断为通信链路或协议选择异常。

2. 链路连通性验证：RoCE 链路正常

使用 hccn_tool 工具对跨节点卡间进行 Ping 测试，结果显示所有节点间均可通，说明物理 RoCE 网络链路无异常。

# 检查各卡 IP 地址
for i in {0..15}; do echo "device $i"; hccn_tool -i $i -ip -g; done

# 单卡 Ping 其他节点 NPU IP
hccn_tool -i ${card_id} -ping -g address ${npu_ip}

3. 通信路径分析：误走 HCCS 链路

进一步在 run 日志中搜索关键词 HCCS，发现跨超节点通信实际使用了 HCCS（High-speed Communication Channel Switch）链路。同时，两个节点的日志中均显示 superpod id 相同，表明 HCCL 认为所有节点属于同一超节点。

4. 环境变量检查：超节点 ID 配置异常

物理上跨超节点部署时，各节点应具有不同的 superpod id。经检查，发现两个节点均配置了 HCCL_LOGIC_SUPERPOD_ID 环境变量，且值相同。

export HCCL_SOCKET_FAMILY=AF_INET
export HCCL_SOCKET_IFNAME=enp23s0f3
export HCCL_DEBUG=INFO
export ASCEND_PROCESS_LOG_PATH=/tmp/ascend_log/$(date "+%Y-%M-%d_%H:%M:%S")
export HCCL_BUFFSIZE=2048
export HCCL_CONNECT_TIMEOUT=360
export HCCL_EXEC_TIMEOUT=360
export HCCL_OP_EXPANSION_MODE=AIV
export HCCL_NPU_SOCKET_PORT_RANGE=16666
export HCCL_ALGO="level0:NA;level1:ring"
hostfile=$1
hosts_num=$(wc-l hostfile | awk '{print $1}')
npus_num=((hosts_num * 16))

5. 启动方式影响：环境变量被同步

排查任务启动命令，发现使用 mpirun 方式执行测试，命令如下：

mpirun -np $npus_num -f $hostfile /usr/local/Ascend/ascend-toolkit/latest/tools/hccl_test/bin/all_reduce_test \
  -b 8K -e 16G -f 2 -d fp32 -p 16 -c 0 -n 100 -w 20

由于 mpirun 会将主节点的全部环境变量同步至从节点，导致所有节点的 HCCL_LOGIC_SUPERPOD_ID 被强制设置为相同值，HCCL 因此判定所有节点处于同一超节点内，自动选择 HCCS 通信路径。

注意：HCCS 仅支持超节点内部通信，不适用于跨超节点场景，导致跨节点通信失败。

问题根因

在使用 mpirun 启动 hccl_test 时，若主节点设置了 HCCL_LOGIC_SUPERPOD_ID 环境变量，该变量将被自动同步至所有从节点。由于所有节点的 superpod id 相同，HCCL 误判为所有节点属于同一超节点，从而选择 HCCS 通信路径。而 HCCS 不支持跨超节点通信，导致跨节点打流失败。

解决方案

方案一：取消环境变量设置（推荐）

若无需手动指定超节点 ID，建议在启动前 取消 HCCL_LOGIC_SUPERPOD_ID 环境变量，避免因变量同步导致误判。

unset HCCL_LOGIC_SUPERPOD_ID
mpirun -np $npus_num -f $hostfile /usr/local/Ascend/ascend-toolkit/latest/tools/hccl_test/bin/all_reduce_test \
  -b 8K -e 16G -f 2 -d fp32 -p 16 -c 0 -n 100 -w 20

✅ 适用于所有节点使用默认超节点划分的场景。

方案二：使用 OpenMPI 替代 mpirun

若需保留 HCCL_LOGIC_SUPERPOD_ID 的差异化配置，建议改用 openmpi 启动方式，其环境变量同步机制更可控，可避免主节点变量被强制传播。

参考官方文档：使用 OpenMPI 执行 hccl_test

最佳实践建议

1. 避免在主节点全局设置 HCCL_LOGIC_SUPERPOD_ID，除非明确需要跨节点统一配置；
2. 跨超节点部署时，确保各节点 superpod id 不同，以正确触发 RoCE 通信路径；
3. 优先使用 OpenMPI 进行多机测试，尤其在需要差异化环境变量的场景下；
4. 测试前确认所有节点路径、环境变量、工具版本一致，避免因配置不一致引发异常。

总结

本问题本质是环境变量同步机制与通信路径选择逻辑的耦合问题。通过合理管理 HCCL_LOGIC_SUPERPOD_ID 的设置范围，并结合合适的启动方式，可有效规避跨超节点通信失败的风险。在大规模分布式训练部署中，理解 HCCL 的通信路径决策机制，是保障系统稳定性和性能的关键。