木-Star去年下半年我们内部启动了一个代号叫 GB300 的集群互联项目。所谓 GB300，是我们对新一批计算节点的统称，这批节点以 GPU 算力为主，承担大模型训练、科学计算还有一部分推理业务。项目核心就一句话：把几十台甚至上百台算力节点用一套高性能网络高效地连起来，让它们像一台机器一样协同工作。这个"互联"两字听起来简单，真正做起来涉及网卡、交换设备、线缆、路由策略、流控机制、监控运维一整条链路，每一步都有不少坑。
这篇东西不是产品介绍，也不是厂商白皮书，而是一个一线实施人员对 GB300 集群互联从设计到落地的完整复盘。重点讲清楚四件事：设计思路怎么定、硬件和拓扑怎么选、部署配置怎么做、性能问题怎么查。如果你刚好要搭一套 GPU 集群，或者正在为现有集群的网络瓶颈发愁，这篇文章应该能帮你少走不少弯路。
1. 集群互联的设计起点：先搞清楚算力需要什么样的网络
1.1 GB300 集群的业务画像
动手选设备之前，我通常先问一个问题：这批集群跑什么？GB300 集群在实际项目里主要有三类负载。
第一类是大模型训练。训练任务非常依赖集合通信，典型的就是 AllReduce，每迭代一步，所有 GPU 要把梯度同步一次。假设集群有 64 个节点、每个节点 8 张 GPU，那就是 512 张卡在同步。如果网络带宽不够或者时延抖动厉害，整个训练效率会被通信拖死，GPU 利用率只能干瞪眼。第二类是科学计算，比如流体力学、分子动力学、电磁场仿真，这类任务除了点对点通信，还大量使用 MPI 的全局规约和广播操作，数据量大、突发性强。第三类是推理和微服务，特点是消息密集、消息体积小，对时延更敏感。
三种业务画像对网络的需求并不完全一样。训练任务追求的是"高带宽 + 低时延 + 无丢包"，科学计算追求的是"大报文吞吐稳定"，推理类则讲究"低时延 + 高并发连接数"。好在大部分需求可以归一成一个目标：构建一张高带宽、低时延、无损的集群内部网络。GB300 集群互联方案的核心，就是围绕这个目标去做取舍。
1.2 用分层思维拆解互联需求
理解集群互联，我习惯把它拆成三个层次：物理层、链路层、传输层。物理层解决"线怎么接"，链路层解决"数据怎么走"，传输层解决"数据怎么可靠高效地送达"。很多新手一上来就纠结该买 A 家还是 B 家的交换设备，其实应该先把这三个层次想清楚。
物理层关注的是端口速率、线缆类型、光模块型号、链路距离。GB300 节点大多支持高带宽网卡，比如单端口 400Gb/s 或 200Gb/s，那交换设备就必须有对应速率的端口，而且端口数量要够。链路层要考虑是不是采用 RDMA 网络，使用什么拥塞控制机制。传输层则是最终体现业务效果的地方，比如训练任务里走 GPUDirect、绕过 CPU 内存拷贝，直接把数据从一张 GPU 网卡搬到另一张 GPU 网卡，靠的就是 RDMA 技术栈。
分完层次之后再回头看选型，思路就特别清晰：物理层决定性能上限，链路层决定稳定性上限，传输层决定应用体验。GB300 集群的整体网络设计，本质上是在这三个层次之间找最优解。
1.3 选型时躲不开的硬约束
除了业务和技术需求，实际项目中还有三个硬约束。
第一个硬约束是成本。高性能网络设备单价很高，同样是 400Gb/s 端口，不同厂商、不同代际的设备差价可能达到数倍。预算不够的时候，就得在"全万兆互联"和"核心高速 + 边缘低速"这类混合方案之间反复权衡。GB300 集群最终选择了全高速互联方案，是因为训练任务占比太高，网络短板会直接变成业务天花板，省下的钱远不够弥补算力浪费。
第二个硬约束是机房条件。包括机柜空间、供电、散热、布线距离。我曾经吃过亏：设备选型时没算好光模块的功耗，结果机柜功率超限，现场只能临时调整。GB300 项目里每台交换设备的功耗预算都提前做了表，保证每个机柜的供电余量都在安全范围。
第三个硬约束是交付周期。当时市场上高端交换设备供货周期很长，而且配套的光模块、线缆也要一起到货。所以我们在设计阶段就锁定了两三家备选供应商，并且要求线缆和光模块同批次下单，避免设备到了没线用的尴尬。这个细节看起来小，但在实际交付中真的能卡你两周时间。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 网络架构与硬件选型的核心决策
2.1 选 IB 还是 RoCE：没有最好，只有最合适
GB300 集群互联面临的第一道选择题，是用 InfiniBand（IB）还是 RDMA over Converged Ethernet（RoCE）。
简单说，IB 是专用高性能网络技术，端到端设计，天然支持无损传输、RDMA、硬件流控，非常适合超大规模 HPC 和 AI 集群。RoCE 则是在以太网基础上实现 RDMA 能力，好处是能和现有以太网生态无缝融合，设备选择多、成本相对低，但要做到无损需要额外配好流控、PFC 优先级流控、显式拥塞通知等一大堆参数，调优难度高一些。
GB300 集群最终选的是 IB 方案。原因有三：一是集群规模不算小，几十台节点并发做集合通信时，IB 的硬件拥塞管理更成熟，稳定性好；二是训练场景对时延极端敏感，IB 的低时延特性在实测中确实比 RoCE 表现更稳；三是我们运维团队对 IB 的管理工具链更熟，排障效率高。
但这不代表 RoCE 不值得考虑。如果集群规模小、业务以推理为主、想要复用现有以太网架构，RoCE 完全可以打，成本优势明显。选型时建议拿典型业务流量做一次实测，不要只看厂商宣传的理论峰值。
2.2 拓扑结构：两层还是三层
确定用 IB 之后，下一个问题是拓扑怎么设计。GB300 集群规模在几十个节点量级，按每个节点 8 端口网卡、每台边缘交换设备提供一定数量端口来算，最终选择了两层 Fat-Tree 结构。所谓 Fat-Tree，就是网络拓扑长得像一棵树，越往上带宽越粗，保证任何两个节点之间的通信带宽不会因为路径不同而打折扣。
两层 Fat-Tree 的规划方法是：底层是叶子交换机，直接连计算节点；上层是脊交换机，负责把不同叶子交换机连起来。节点数、叶子交换机数、脊交换机数之间要满足一个关系：
端口数 × 叶子数 ÷ 2 ≥ 节点数，同时 脊交换机数 ≤ 叶子交换机的可用上联端口数。
GB300 项目的实际参数：每个节点 8 张计算网卡，分成 8 个端口组，每 8 个节点一组接入一台叶子交换机。叶子交换机的下行端口正好把这 8 组节点全接住，上行端口分成 4 组接往 4 台脊交换机，形成一个典型的 2:1 收敛比网络。收敛比这个概念很关键，它表示进入交换机的流量与送出交换机的流量之比，2:1 意思是下行带宽是上行带宽的两倍，对大多数训练负载来说够用，想要更激进可以选择 1:1 无收敛，但成本几乎要翻倍。
三层结构一般是几百台节点以上的场景才需要，GB300 集群用两层 Fat-Tree 已经可以保证任意两点之间最多经过三跳（节点到叶子、叶子到脊、脊再到对面叶子），时延可控且故障域隔离清晰。这是我在多个项目里验证过的经验阈值：节点数在 100 台以下，两层拓扑往往比三层更优，因为少一层交换，时延更低，运维也更简单。
2.3 线缆、光模块与端口速率的细节坑
拓扑定了，线缆和光模块的配置看起来是小事，但坑特别多。
GB300 集群使用的端口速率是 400Gb/s。选择光模块时，我第一个考虑的是传输距离。机柜内相邻设备用短距离模块即可，跨机柜、跨列间则要选中距离模块。这里有个容易踩的坑：光模块标称距离和实际工作距离不是一回事，如果光模块的发光功率和光纤的衰减不匹配，链路虽然能 link 起来，但误码率会悄悄升高，跑大流量时就出问题。
GB300 项目里我们统一使用了某个厂商的多模光纤 + 短距离光模块方案，并且要求布线施工队做端到端的光衰测试，所有链路光衰值必须落在模块规格书标定的范围内才验收。为什么这么较真？因为 RDMA 网络对丢包极度敏感，而链路误码导致的重传，表现起来和网络拥塞几乎一样，都是带宽骤降、时延抖动。如果不把物理层指标先卡死，后面所有调优都会变成玄学。
另外还要注意端口速率协商。某些交换设备端口支持 400G 和 200G 两种模式，如果计算节点网卡配置成了 200G，交换机端口还是 400G 自适应，他们能正常通信但是速率减半，很容易被忽略。GB300 部署时我们专门做了端口速率核对清单，逐个端口确认协商结果，才避免了这种静默性能损失。
3. 部署实录：从物理布线到集群网络可用
3.1 三网分离：管理网、存储网、业务网
正式部署 GB300 集群网络之前，我们做了一个重要的架构决策：把网络分成三张独立的网。
- 管理网：用于带外管理、SSH 登录、监控采集，带宽要求低，千兆就够，但要求链路稳定。
- 存储网：负责节点与存储集群之间的数据交换，走专用网络，避免和训练流量互相干扰。
- 业务网：也就是计算网，承载 GPU 之间的集合通信和训练数据流，高性能 IB 网络。
三张网物理隔离，而不是靠 VLAN 逻辑隔离。为什么这样做？因为在千卡级训练集群里，训练流量一旦因为拥塞占满链路，管理指令就被堵死，想 SSH 上去排查问题都做不到。物理隔离之后，即使业务网完全拥塞，管理网仍然畅通，排障窗口始终存在。GB300 集群的管理网用了普通的万兆以太网交换机，便宜、稳定、够用。存储网用的也是低延迟以太网，容量规划按峰值带宽的 1.5 倍预留。
这三张网在服务器侧要分配不同的物理端口。GB300 节点通常有板载网卡和高速计算网卡，操作系统里会看到多个网络接口。部署时必须写清楚端口接线表，哪个口接管理、哪个口接存储、哪个口接计算网，用不同颜色的线缆标记。这个习惯帮我们省了很多排查时间。
3.2 IB 子网划分与分区配置
IB 网络里有一个重要的概念叫分区（Partition），你可以理解成以太网里的 VLAN，作用是隔离不通的 IB 节点。GB300 集群默认把计算节点全部放在一个默认分区里，同时给存储网关节点单独划了一个分区，然后配置基于服务 ID（Service ID）的路由规则，让两边的数据只能通过指定的网关节点互通。
分区配置通过子网管理器（Subnet Manager，SM）来做。IB 网络里必须有 SM 节点存在，它负责发现所有 IB 设备、分配 LID（Local Identifier）、计算路由表。GB300 集群跑了两台 SM，一台主用一台备用，配置了主备切换策略。这里有个细节值得注意：SM 最好跑在单独的管理节点上，或者跑在不会频繁重启的计算节点上，不然一旦 SM 抖动，整个 IB 网络的路由都要重新计算，所有节点之间会短暂断流，训练任务直接中断。
我贴一段简化格式的 SM 主备切换配置示意：
ini复制# 子网管理器配置片段
[global]
subnet_prefix = 0xfe80000000000000
sm_priority = 15
[sm]
node = managed_node_primary
priority = 15
state = ACTIVE
[sm_standby]
node = managed_node_backup
priority = 7
state = STANDBY
生产环境和测试环境的区别在于：测试时 SM 挂了，等几分钟无所谓；生产环境训练任务跑了一半，几秒钟的断网就是几小时 GPU 算力的浪费。所以我们做了脚本监控 SM 进程状态，一旦主用 SM 无响应，备用 SM 自动接管，同时发出告警。这个机制在 GB300 集群稳定运行期间真的触发过一次，备用 SM 接管成功，业务侧几乎没有感知。
3.3 流控参数与无损网络的调优
IB 网络号称无损，但这个"无损"不是天生的，它有赖于链路层的流控机制。GB300 集群部署后，我重点调了三个参数：链路层流控的缓冲区大小、拥塞控制的相关阈值、队列调度参数。
先说缓冲区。IB 交换设备内部有大量缓冲区用于吸收突发流量，如果缓冲区配置过小，微突发一到就直接丢包，即使流量均值远未达到端口上限。我当时参考了厂商的推荐值区间，结合 GB300 集群的实际拓扑做调整：叶子交换机面向下行方向的缓冲区尽量调大，因为训练场景多是"多打一"模式，比如多个 GPU 同时向同一个 GPU 发数据，瞬间流量非常猛。
拥塞控制参数也需要调。IB 的拥塞控制目标是限制注入到网络里的流量，防止局部拥塞蔓延成全网拥塞。参数不能一次设到最大，否则带宽利用率反而下降。GB300 项目里我们用了"先保守、后激进"的方法：刚开始用厂商默认值，跑一轮集合通信基准测试，观察带宽和时延，然后逐步调整拥塞阈值，每调一次跑一次测试，最终找到了一组在带宽和时延之间平衡较好的参数。
这些参数的配置文件在 IB 交换设备上通常以文本形式导出。我建议每调一轮参数就备份一个配置版本，记录当时的测试结果。别偷懒，光记"今天调了参数"不够，一定要记"为什么调、调到多少、对比效果如何"。后期排查问题时，这些记录就是救命稻草。
3.4 监控体系：网络状态要看得见
没有监控的集群网络就像没有仪表盘的飞机，飞得再快心里也虚。GB300 集群的网络监控我分了三层做。
第一层是设备层监控，用 SNMP 拉交换设备的端口流量、错误计数、丢弃计数、温度、光模块功率。端口错误计数是最重要的指标，一旦出现持续上升的 CRC 错误或链路错误，物理层基本可以断定有问题，要立刻查光模块和光纤。
第二层是节点层监控，在每台计算节点上采集网卡状态、RDMA 计数、带宽时延统计。这里要说一个技巧：光看带宽不够，还要看等价队列深度和重传计数。如果带宽波动时伴随重传计数上升，说明网络里发生过拥塞丢包，需要回到流控层去排查。
第三层是业务层监控，直接采集训练任务的集合通信耗时，或者 MPI 作业的各阶段时间分布。这一层最容易发现"网络看起来健康但业务很慢"的问题。GB300 集群有一次现象是训练每轮的通信时间从正常的两秒涨到五秒，设备层监控却显示链路利用率不足百分之五十，最后查下来是一台节点网卡的 PCIe 链路降级了，数据从 GPU 到网卡的搬运速度被卡住，RDMA 再快也没用。
监控告警的阈值设置也是一门学问。带宽类告警我通常设成"连续五分钟超过端口速率的百分之八十"，避免被瞬时尖峰骚扰；错误计数类告警则设成"一分钟内新增错误大于某个值"就触发，因为错误计数代表了物理层风险，越早发现越好。GB300 集群上线后我对告警规则做了两轮收敛，把真正影响业务的告警保留，把无关紧要的噪音告警屏蔽掉，运维响应效率提升不少。
4. 性能验证与调优：数字不会骗人
4.1 基准测试工具组合
网络部署完成后，必须用工具做基准测试，不能"接上线就算完"。GB300 集群用的测试工具组合包括：
- 点对点带宽和时延测试：用 RDMA 写和 RDMA 读两种模式分别测，得到单链路极限带宽和延迟值。
- 集合通信性能测试：模拟训练场景的 AllReduce、AllGather、Broadcast 操作，测试集群整体通信效率。
- MPI 基准测试：跑标准 MPI 通信模式，验证大规模并行应用的通信表现。
测试不是只跑一遍就够，至少要覆盖不同的消息大小。比如小消息（4 字节到 64 字节）测时延，中消息（1KB 到 64KB）测延迟带宽中间区域，大消息（1MB 到 16MB）测峰值带宽。每一档消息大小都测多次取稳定值，记录最大值、平均值和 P99 值。有很多集群调优前后带宽看起来差不多，但 P99 时延差出一倍，这是隐藏的性能风险。
还有一个测试细节：测试时必须关闭防火墙和系统的节能策略，否则结果完全没参考价值。GB300 集群第一次跑带宽测试时，某个节点因为系统安装时默认启用了节能模式，性能只有同配置节点的七成，排查了好几个小时才发现。
4.2 实测数据解读：哪里掉链子
GB300 集群最终的实测数据，点对点 RDMA 带宽在 400Gb/s 端口上能跑出标称值的九成以上，时延在微秒级别，集合通信性能在 64 卡规模下线性扩展良好。但这不是最值得说的，值得说的是数据背后的解读。
我拿到测试结果后会做两个判断：第一，带宽是不是"平台期"而不是"峰值"。意思是测试结果的最高点可能只是因为消息足够大，真正衡量集群性能的是带宽随消息大小增长的曲线是不是平滑，有没有突然断崖。第二，时延数据的分布是否集中。如果 P99 时延远高于平均时延，说明网络里有间歇性的拥塞或抖动，业务表现会不稳定。
有一次测试发现 AllReduce 时间随节点数增长从线性变成了超线性，一查发现有两台节点之间的路径存在链路聚合负载不均，部分流量被挤到了一条物理链路上，出现瓶颈。调整链路聚合策略后，扩展性恢复。这种情况如果只看平均带宽，根本发现不了，必须结合分位数和扩展性曲线一起看。
GB300 集群调优最终做到了一个比较理想的状态：各节点间带宽差异小于百分之三，时延标准差控制在很小的范围，集合通信时间随节点数增长保持接近线性。这个状态意味着网络没有明显的短板链路，业务流量调度基本均衡。
4.3 三个典型瓶颈的定位方法
实际调优过程中，GB300 集群出现过三个典型瓶颈，它们的定位方法有共性。
第一个瓶颈是单链路带宽不达标。排查步骤是：先用点对点测试确认协议层没问题，再检查网卡固件、驱动版本，然后检查光模块发光功率和光纤衰耗，最后检查 PCIe 链路速率是否降级。这个顺序不能乱，先软件后硬件、先配置后介质，能少走很多弯路。
第二个瓶颈是收敛比导致的集合通信瓶颈。Fat-Tree 架构如果收敛比过高，某些通信模式下会明显掉速。定位方法是做不同节点数下的 AllReduce 测试，观察带宽是否在某个规模后不再增长。如果确实是因为收敛比，那就得在硬件规划阶段就避免，比如提高脊交换设备端口数，或者在应用层面做通信调度优化，把跨叶子交换机的通信尽量转化成叶子内的通信。
第三个瓶颈是 CPU 参与数据搬运导致的时延升高。如果消息大小不大，CPU 处理开销占比会明显影响总时延。解决方案是启用 GPUDirect，让 GPU 网卡直接访问 GPU 显存，跳过 CPU 和系统内存拷贝。GB300 集群全面启用了 GPUDirect 后，小消息时延降低了约一个数量级，这个优化收益非常明显，强烈建议任何 GPU 集群在部署时都把 GPUDirect 作为必选项排查。
5. 常见问题与排障技巧实录
5.1 故障现象速查表
GB300 集群从部署到现在，我遇到的典型故障逃不出下面这几种。我把现象和直接排查方向整理成了一张表，与所有做集群运维的朋友分享：
| 故障现象 | 直接排查方向 | 关键检查项 |
|---|---|---|
| 带宽只有预期的一半 | 端口速率协商、PCIe 降级 | 网卡速率、PCIe 链路宽度 |
| 训练时快时慢 | 链路拥塞、流控参数 | 重传计数、等价队列深度 |
| 点对点测试丢包 | 光模块、光纤、缓冲区 | 光衰、CRC 错误计数 |
| 集合通信时间突增 | SM 切换、路由变化 | SM 状态、路由表变化 |
| 节点间歇性断连 | 电源功耗、光模块过热 | 光模块功耗、温度告警 |
| 监控显示端口利用率不高但业务慢 | CPU 搬运、PCIe 瓶颈 | GPUDirect 是否启用、top 排查 |
这个表是 GB300 项目里我们团队的排障手册浓缩版。你可能注意到，每一个现象后面都至少有两个备选方向，这说明网络故障很少只有一个原因，排障时要抱着"多个因素叠加"的心态去查。
5.2 实战排查思路：从物理层向上逐层剥
面对一个"网络很慢"的反馈，我的固定套路是自下而上逐层排查。第一件事是看物理层：登录交换设备查所有相关端口的 CRC 错误计数、链路翻转计数、光模块功率。这一层如果有问题，后面都不用查，先换线换模块。GB300 集群遇到过多次光模块功率高但告警没触发的情况，原因是我给监控平台设置的功率阈值过于宽松，实际已经接近临界值。
第二层查链路配置：端口速率、 FEC 配置、MTU 设置。FEC（前向纠错）这个参数很重要，某些编码模式能纠错，但对速率有一定开销；某些模式下不支持 400G。配置不一致时，交换机和网卡能链接上，但性能大打折扣。对比两端的实际配置是最容易发现问题的。
第三层查传输层和协议层：查看是否有重传、拥塞窗口是否异常、路由是否经过预期路径。IB 网络可以用管理工具查看路径信息，确认数据走的是最短路径还是绕路了。有一次 GB300 集群出现跨叶子通信延迟特别高的情况，最后查出来是子网管理器计算的路径不是最优路径，重启 SM 后重新计算才恢复正常。
最后一层才是应用层。如果前三层都正常，再考虑是不是业务进程本身的问题，比如线程绑定、CPU 频率、GPU 之间的拓扑关系。很多"网络问题"最后都定位到 GPU 通信库的拓扑感知没开启，导致数据走了非最优路径。这类问题的排查顺序如果不固定，极容易在应用层浪费大量时间。
5.3 固件和驱动升级里必须知道的坑
GB300 集群运行半年后，遇到过一次比较头疼的故障：一批节点在升级网卡驱动后，点对点测试带宽下降到原来的八成，但设备侧完全看不到错误。排查发现是驱动升级后，默认的 MTU 和 QP 大小参数发生了变化，需要重新配置才能匹配交换设备侧的策略。
这类教训让我养成了一个铁律：固件和驱动的升级必须遵循三个步骤。第一步，先在测试环境升级，跑完整基准测试并对比升级前后的数据，关键指标不能向下波动超过百分之五。第二步，生产环境按批次灰度升级，一批不超过总节点数的五分之一，观察至少一个训练周期。第三步，升级过程中保持旧版本的回退包在手边，一旦出现兼容问题立刻回退，不要在现场现找旧版本。
还有一个细节：升级 IB 交换设备固件之前，一定要确认子网管理器的兼容性。交换设备固件和 SM 的版本存在严格的对应关系，版本错配轻则告警噪音、重则全网路由不稳定。GB300 项目有两次计划内维护都是因为版本兼容性排查没做到位，硬生生把维护窗口拉长了一倍。
最后分享一个经验：每次升级前，导出全网设备的配置文件和当前版本清单，存到固定的备份目录。这个动作成本很低，但真出了事故，它可能是你唯一的救命稻草。我们有一次升级后某台交换设备的配置被自动改写了，如果没有前一天导出的备份，根本不可能对比出差异常参数。
GB300 集群互联这个项目做下来，我最深的体会有两点。第一点，高性能网络是一个完整的系统，不是买几台交换机插上线就完事。从业务需求分析到硬件选型、拓扑规划、参数调优、监控运维，每一环都会影响最终的实际性能，任何一个环节偷懒，都会在某个业务高峰时刻加倍还给你。第二点，所有的调优和排障经验都要靠记录沉淀下来，每一次故障、每一轮参数调整、每一个"这个配置一定要这样设"的细微直觉，都值得写成文档。技术变量太多，人的记忆太不可靠。这套网络我们跑到现在还算稳定，靠的不是某一个天才的灵光一现，而是一份能追溯每一步决策的、真实完整的工程文档。