今年初一个做算力租赁的朋友来问，集群要扩到上万张卡，网络方案却还停在“先拿GPU再说”。结果几件事一核对，网卡、线缆、交换机的交付周期、预算、兼容性全都没着落，离计划上线只剩几个月。做这行久了，我越来越觉得，万卡AI集群的交付瓶颈，其实不在GPU，而在互联——从迈络思网卡到每一根线缆，哪个环节都得经得起拷问。这篇文章就围绕迈络思（现NVIDIA Networking）网卡、线缆在万卡AI集群组网里的选型思路、正品鉴别和实战经验，把能直接抄作业的内容捋一遍。不管你是算力服务商、平台运维，还是正准备进AI集群这个圈子的采购或硬件工程师，都应该用得上。
1. 万卡互联究竟卡在哪：网卡和线缆的代价为什么被放大一万倍
1.1 GPU堆上去之后，网络先撑不住
很多刚接触AI基础设施的朋友会有一个直觉：算力是大头，GPU采购方案定了，剩下都好说。这个直觉在几十张卡的实验环境里基本成立，但到了万卡规模，情况完全反过来。
大规模训练跑的是AllReduce、AllGather这类集合通信，每个GPU在每一轮迭代中都要跟其他GPU交换梯度数据。模型参数越多、并行度越高，通信数据量越夸张。一万张卡听起来是“一万张卡的算力”，但实际体验取决于这一万张卡能不能高效协同。训练过程中如果有几张卡的链路不稳，慢节点会拖住整个同步进程，万卡集群的实际算力利用率可能连50%都到不了。
我见过不止一个项目，Group时间降不下来，最后查出来不是GPU故障，而是某一批网卡的固件版本混乱，导致跨交换机链路的协商速度只有预期的一半。你算算这笔账：一张H系列的GPU卡，因网络问题空等一分钟，整个集群几千张卡跟着多等一分钟，累积的算力浪费就是天文数字。网络不像CPU或GPU那样能直观看到利用率，但它决定了算力的“成色”。
1.2 一根线缆的问题，在万卡规模会被放大
从物理拓扑看，每个GPU节点要经过网卡、线缆、交换机才能和其他节点通信。万卡集群通常意味着数千个计算节点、数百台交换机、几万根线缆。同牌号同批次设备如果在单点上出问题，大概率是批量问题。
拿DAC铜缆举例，正常一根线在机柜内跑400G，如果屏蔽层或者连接器工艺缩水，在高负载下就可能出现误码率飙升。单根线看起来只是“偶发丢包”，但如果你有几千根这个批次的线，出问题的绝对数量就非常可观。更麻烦的是，这类问题往往表现为间歇性，白天低负载没事，晚上一跑大规模训练就link flapping，极难定位。
迈络思网卡和线缆的价值，恰恰在这种场景下体现：它有一套完整的链路诊断机制，从网卡的link状态、线缆的EEPROM信息到光纤模块的光功率，都能通过标准工具看到。出了问题能定位到是网卡、线缆还是对端交换机端口的问题，而不是靠人去机柜里一根根拔插。
1.3 为什么绕不开Mellanox生态
AI集群里迈络思之所以出现频率这么高，不是纯粹的营销结果。NVIDIA收购Mellanox之后，GPU、网络、软件栈的配合越来越紧密。NCCL这类集合通信库对InfiniBand和RoCEv2有专门优化，驱动层面也在持续适配。
万卡集群如果走纯以太网做普通TCP通信，性能损失会很直接。真正跑大规模训练，IB或者RoCEv2几乎成了事实标准。而迈络思的ConnectX系列网卡，既能做IB，也能做RoCE，还能通过SmartNIC能力卸载一部分网络处理。选它的核心逻辑，恰恰是因为整个AI生态的软件和硬件都已经围绕它做适配。你可以不用，但你的运维团队和分布式训练框架的坑会多一些。
2. ConnectX系列网卡选型：照着算力规模和通信模型反推
2.1 先算带宽账，再定网卡型号
选网卡不能只看“接口是400G还是800G”，要先看单节点需要多少通信带宽，再看PCIe通道数是否够。
一个常见的AI服务器节点，8张GPU卡，一般配置1到8张网卡。典型做法是每GPU配一张400G网卡，或者两张GPU共享一张400G网卡，取决于跑的是大模型训练还是推理场景。如果每张GPU都配400G网卡，那一个节点的PCIe通道数、供电和散热都要对应升级。计算方式并不复杂：一张PCIe 5.0 x16的槽位理论带宽是64GB/s，约512Gbps，承载一张400G网卡刚好供需平衡，再往上到800G就需要检查平台是否真的支持PCIe 6.0或者多槽位绑定。
很多采购容易犯的错是：交换机速率升级到400G，但网卡还在用上一代200G，最后物理链路协商只有200G。你买的“400G集群”实际是“200G集群”，后期再升级网卡，线缆不一定都得换，但固件和驱动适配要花不少精力。所以选型时要有长期视角，按未来两年要跑的模型规模来定，而不是按今天的测试负载。
2.2 常见型号与端口速率的取舍
下面是目前AI集群里比较常见的几类迈络思网卡，我按实际接触到的选型情况整理一下：
| 型号 | 端口速率 | PCIe接口 | 典型场景 |
|---|---|---|---|
| ConnectX-6 Dx / ConnectX-6 HDR | 最高200G | PCIe 4.0 x16 | 中小规模集群、存储网络 |
| ConnectX-7 | 400G（NDR/400GbE） | PCIe 5.0 x16 | 万卡集群主力，RoCE/IB通用 |
| ConnectX-8 SuperNIC | 800G | PCIe 6.0（部分平台5.0） | 超大规模集群、GPU-to-GPU高速互联 |
| BlueField-3 / BlueField-4 | 400G/800G | PCIe 5.0/6.0 | 需要DPU卸载、云原生和安全的场景 |
表格只是参考，真正的配置必须跟你计算节点的PCIe拓扑、CPU型号、GPU卡数绑在一起看。比如你用的是PCIe 5.0平台，上ConnectX-7就比较顺；如果是老平台，强行上400G网卡，PCIe 4.0 x16的带宽就成了瓶颈。
另外，双端口网卡在集群里的用法值得单独说。很多运维为了节省PCIe槽位，会买双口网卡，一张卡跑两个100G或两个200G。这在通用服务器里没问题，但在AI训练节点里要谨慎：双端口共享PCIe带宽，如果两个口同时跑满，可能发生头阻塞，训练通信抖动就会变大。给AI集群的GPU节点配网卡，我个人的习惯是优先保证单口带宽和独占PCIe通道，而不是贪图接口数量。
2.3 固件、驱动和“正版”的隐性门槛
网卡硬件只是第一步，真正让工程师头疼的是固件和驱动。迈络思网卡要发挥完整功能，一般需要安装MLNX_OFED驱动包，固件也要刷到和驱动匹配的版本。很多人拿到网卡就装系统，默认驱动不识别，或者识别到了link状态却起不来，跑过来问我是不是网卡坏了。
实际情况多半是固件版本太老，跟交换机或者线缆的握手协议对不上。几千张卡的集群，如果固件版本不一致，后期维护就是灾难。我们有次帮客户做交付验收，一批卡出厂固件版本就差了三个小版本，虽然功能上都能跑，但一旦碰到特定交换芯片的兼容性问题，行为差异会很隐蔽。
所以采购时就该确认好三件事：这批卡是否原厂全新、固件版本是否统一、驱动是否能在目标OS上正常安装。这几个问题如果留到上架之后再去查，排查成本会被机房和网络规模放大无数倍。
3. 线缆选型决定交付成败：DAC、AOC、光模块到底怎么选
3.1 三种线缆的本质区别
AI集群组网里，线缆绝对是个被低估的环节。很多人把预算砸在网卡和交换机上，在线缆上能省就省，结果交付时全栽在信号完整性上。我先把三种主流线缆的区别讲清楚：
| 类型 | 传输介质 | 典型距离 | 功耗 | 成本 | 可靠性 |
|---|---|---|---|---|---|
| DAC（直连铜缆） | 铜缆 | 1-3米，极限5米左右 | 极低，无源 | 低 | 高，但弯曲半径敏感 |
| AOC（有源光缆） | 光纤+两端光模块 | 3-50米，可更长 | 中，两端需要供电 | 中 | 高，线缆轻、易布线 |
| 光模块+光纤 | 可插拔光模块+LC/MPO光纤 | 上百米甚至公里级 | 高，模块功耗明显 | 高 | 取决于模块质量和光纤端面清洁度 |
DAC的优势在短距离、低功耗、低时延，机柜内部GPU节点到TOR交换机之间，DAC是最稳的选择。AOC适合跨机柜、跨列的场景，线缆比铜缆柔软，布线方便，也不容易受电磁干扰。光模块+光纤适合从Leaf往上走到Spine甚至跨机房的长距离场景，但功耗和维护成本都比前两者高。
万卡集群里，这三类线缆通常会同时存在：服务器到TOR用DAC，TOR到Leaf用AOC或短光纤，Leaf到Spine用长距离光模块。选型的关键不是“哪种更好”，而是“哪个位置用哪种”。
3.2 别在DAC上看走眼：屏蔽、长度和弯曲半径
DAC铜缆有一个特别容易被忽略的问题：弯曲半径。很多机房布线师傅习惯像捋网线一样把DAC弯成直角，一次两次没关系，长期高负载下内芯损伤就会导致误码。高性能DAC通常比普通网线粗得多，设计上对弯曲半径有明确要求，布线时必须留足空间。
另外，DAC的“有效长度”和“标称长度”也可能有出入。有的标称3米的线，实际在服务器机柜里从网卡面板绕到交换机端口，中间要穿过理线架，3米很可能不够。我建议在机柜内布线时，DAC长度比你量的最远路径多加0.5到1米，不要卡着极限长度下单。
AOC和光模块则要注意“端口清洁”。光纤端面沾上灰尘，光功率就会下降，轻则降低协商速率，重则直接link down。机房施工环境里灰尘免不了，接插前用光纤清洁笔处理一下，能避免大量“莫名其妙”的链路问题。
3.3 线缆的“握手协议”和认证线问题
很多人不知道，现在的网卡和交换机在link training阶段，会通过线缆里的EEPROM读取线缆的厂商、型号、长度、序列号等信息。某些厂商的设备对非认证线缆会限制协商速度，甚至拒绝link up。
迈络思生态对线缆认证这件事比较上心。正品线缆在出厂时EEPROM信息是完整的，用标准诊断工具能看到线缆的速率等级和支持的能力集合；而一些仿冒线、公版线可能半兼容或者只能协商到低速率。这在单机测试时不容易暴露，因为在低速率下能正常通信，等整个集群进行大规模并行训练时问题才冒出来。
所以在采购线缆时，我始终强调“和网卡同生态”的思路：既然网卡和交换机都选了迈络思的，线缆也尽量选原厂认证列表内的型号。这样真的出链路问题，定位工具有完整信息可看；否则出了问题，网卡说是线缆问题，线缆说是交换机问题，谁都不认，现场运维就被夹在中间。
4. 正品直供背后的门道：翻新卡、假线缆和一套可落地的验收流程
4.1 低价“拆机卡”埋下的雷
做这行久了，听到过不少“超低价拿到了别人退下来的拆机卡”之类的故事。AI集群对一致性要求特别高，拆机卡和翻新卡的风险恰恰在于一致性不可控。
最常见的问题包括：序列号和MAC地址被反复刷写，同一批卡出现MAC冲突；水洗卡在某些温度湿度下工作正常，但高负载时稳定性没人能保证；还有把高于原厂功耗规格的固件刷进去，导致供电模块过热。这些隐患在单卡测试时基本看不出来，但在万卡集群的高并发通信下，任何一个不稳定网卡都可能拖慢一片训练任务。
你可能会说，价格便宜啊。但算一笔账就清楚了：翻新卡省下来的那点采购费用，在几次集群训练中断和现场排查工时面前，根本不值一提。更何况AI集群上线后的每一个空转小时，成本是以整集群规模计的。
4.2 一套能直接用的验收流程
不管你从哪个渠道采购，我建议收到货后都走一遍下面的流程，不要跳步：
- 核对SN和出厂标签：检查网卡上的SN贴纸、外包装标签、二维码是否一致。正品原厂卡的SN信息可以在NVIDIA官方渠道按正常流程核对出厂批次和保修状态。如果SN贴纸模糊、标签信息跟包装对不上，就要高度警惕。
- 上机前先查固件：用MFT或mst工具读取网卡当前固件版本，和出厂最新版本比对，确认固件没有被篡改或刷成非官方版本。这一步能筛掉一堆翻新卡。
- 上机后看link状态：装上驱动后，用ethtool工具或对应网卡诊断工具查看端口状态。确认协商速率、信号强度、线缆信息都能被正确识别。
- 批量跑压力测试：万卡集群不像单机，一定要小批量试跑。先拿一二十张卡组成一个小集群，压测通信吞吐，然后把结果跟同型号已验证卡做对比，偏差过大就排查。
- 统一固件和驱动版本：验收通过后，趁设备还没上架，赶紧统一刷新固件和驱动版本，避免集群里出现多个版本混跑的隐患。
4.3 线缆上一眼能看出的辨伪点
线缆的造假比网卡更容易，但辨伪也更“看细节”。原厂线缆的连接器做工通常很规整，丝印清晰，插拔阻尼适中，线身标签上有完整的型号和SN信息。仿冒品往往在这些细节上露怯：丝印粗糙、标签粘贴歪斜、连接器金属壳光泽不均匀。
还有一个小技巧：用诊断工具读取线缆EEPROM里的厂商字段，看看显示的厂商名和型号是否跟线身标签一致。如果字段显示异常或者读不出来，大概率不是原厂线。
另一个高发区是“型号描述对不上”。比如标称400G的AOC，实际芯片只支持到200G，单测也正常，但在高带宽场景下最高协商速率就到不了。所以线缆验收时，除了看标签，一定要在满速率条件下实际跑一下吞吐，别被“插上能亮灯”骗过去。
5. 万卡集群组网实操：架构、调优与三个高频排障
5.1 网络架构的两种主流选型
万卡集群的网络架构不是拍脑袋定的，通常围绕“无阻塞”这个核心目标展开。所谓无阻塞，就是任何一张网卡与任意其他网卡通信时，不会因为中间链路带宽不足而排队等待。
最常见的两种做法：一是传统的leaf-spine结构，流量从服务器到TOR叶子交换机，再上到Spine核心交换机，路径清晰、扩展方便；二是InfiniBand下的胖树结构，利用IB的自适应路由和拥塞控制，构建一个带宽充足的无损网络。
选以太网RoCEv2还是InfiniBand，是另一个绕不开的决策点。两者的底层扎实程度不同：IB在丢包、拥塞控制方面天生为高性能计算设计，但生态封闭、成本较高；RoCEv2跑在以太网上，能复用现有网络运维经验，成本相对可控，但对调优要求高，PFC、ECN这些参数配不好，性能波动非常明显。
万卡级别，我个人的建议是：如果是专门的AI训练集群，长期跑大模型，IB或者严格调优的RoCEv2都可以，但必须有一支懂无损网络的运维队伍；如果只是通用算力平台，训练和业务混跑，RoCEv2的灵活性更有优势。
5.2 RoCEv2与NCCL调优的几组关键参数
RoCEv2本质上是通过流控机制让以太网变成一个“不丢包”的网络。核心参数有三项：
- PFC（优先级流控）：保证无损队列在拥塞时不丢包，但对死锁和风暴比较敏感，必须限制在特定优先级队列。
- ECN（显式拥塞通知）：在交换机即将拥塞时标记数据包，让网卡主动降速，避免触发PFC。ECN和PFC要配合使用，只开一个效果都不完整。
- Buffer（缓冲区）：网卡和交换机的缓冲区大小，决定了吸收突发流量的能力。
我只给到一个调优方向，具体数值需要结合实测。生产环境里，一定要先在测试集群上对比不同参数下的训练性能曲线，再全量下发。
NCCL环境变量也是让很多人头疼的地方。常见的有网卡接口指定、IB和RoCE切换开关、以及一些超时设置。很多分布式训练报错，查出来其实是NCCL选错网卡接口，例如把管理口的IP当成数据面通信口了。这个事没有通用万能解法，但核心排查思路很明确：看训练日志里实际走的是哪个网卡的IP，然后对照路由表确认是不是数据面网段。
5.3 三个高频排障场景，我直接给排查链路
结合平时技术群里被问爆的问题，我挑三个典型场景展开。
场景一：网卡灯不亮，但网线确认是通的。
这大概是出现频率最高的问题。不要直接断定硬件坏了，按下面顺序走：
- 先看网卡驱动是否加载。
lspci能看到设备，但ethtool查不到，通常是驱动没装好。 - 再看对端交换机端口是否up。很多机房交换机的端口默认down，没做配置。
- 确认线缆类型和速率协商。DAC、AOC、光模块必须和两端端口能力匹配，400G光模块插在100G端口上，协商结果可能就是不亮。
- 最后才怀疑硬件，用同一条线换到另一个口，或者换一条已知正常的线交叉测试。
场景二：Ubuntu虚拟机里“虚拟网卡不存在或被禁用”，或网络显示“线缆已拔出”。
这个经常发生在KVM/VMware虚拟机环境下。如果是物理网卡直通（passthrough）给虚拟机，要注意宿主机是否先占用了这个网卡；如果是SR-IOV虚拟出来的VF，虚拟机的驱动必须支持对应VF类型。我见过不少案例，其实是虚拟机里没装对应网卡的驱动包，系统只认出了虚拟网卡但起不来。
场景三：Linux下网卡无缘无故“消失”，找不到了。
这种先查PCIe链路。用系统工具看设备是不是还在PCI总线上，如果还在但驱动加载失败，优先重刷固件；如果PCI层都看不到了，大概率是物理接触或供电问题，重新插拔一次往往就能解决。
排障的核心不是背命令，而是理解链路层级：物理层、数据链路层、驱动层、网络层，一层一层圈定，别一上来就带节奏换硬件。
6. 交付之后的功课：资产、备件和长期稳定
万卡集群不是“网卡插上去、线缆接好”就结束了。真正决定集群长期稳定性的，是交付后的运维习惯。
首先，网卡和线缆的资产管理要做得比GPU更细。每张网卡的SN、物理位置、固件版本、驱动版本、连到哪台交换机的哪个端口，最好都记清楚。我们曾经处理过一个问题，训练频繁中断，最后定位到一台服务器的某张网卡的散热风扇被堵了，温度上来以后网卡降速。如果没有资产台账，这种问题不知道要排查多久。
其次，线缆备件一定要留足。万卡集群几万根线，每季度坏个十几根是很正常的事。所有线缆尽量保持同一个批次和型号，不要随意混用不同认证级别的线。备件库里的线最好也是原厂认证型号，别拿几根便宜的“能用就行”的线应应急——应急线材混进生产环境，后续排查时就是干扰项。
最后，固件和驱动的更新节奏要稳。不要追求最新，要追求稳定。每次更新都在测试集群先验证，确认性能没有回退，再分批滚动上线。网卡固件不像手机系统那样天天有惊喜，有时候“不折腾”反而是最优解。
做网卡和线缆供应这些年，我见过三种客户。一种只比价，谁便宜买谁，最后在性能和稳定性上反复交学费；一种只看品牌，大牌拉满但完全不看拓扑和实际模型需求；还有一种，愿意花时间把带宽、线缆、架构、调优这些细节捋清楚，反而是交付最顺畅、后期最省心的。
AI集群组网这件事，说到底是把每一根线、每一张卡、每一个参数都放到整个系统里去算总账。迈络思的设备大概率不会让你“捡到便宜”，但它的价值是让你在出错时有据可查、在扩展时有路可走。如果你正准备上一个万卡级别的集群，我的建议很简单：先把上面这些选型和验收细节落实到位，再谈GPU的型号和数量。网络拖后腿的代价，远比你想的贵。
