企业官网建设流程全解析

开头

做“万卡AI集群组网”这几年，最常被问的一句话不是“用哪家交换机”，而是“你手上那批迈络思网卡和线缆，到底是不是正品”。

这问题背后是血泪。万卡规模不是把几千张网卡插进服务器、再接上交换机就完事，它考验的是从采购、组网、驱动调优到故障排查的全链路能力。迈络思早就被NVIDIA收编，现在大家在商场里看到的ConnectX系列，基本都挂着NVIDIA的标，但市场流通的“水货”“拆机件”“翻新卡”比想象中多。我作为直接供货、直接下场陪客户调集群的设备经销商，今天就把这些年在万卡AI集群组网里踩过的坑、跑通的经验、以及线缆和网卡的选型逻辑一次说清楚。

这篇东西适合三类人看：正在规划AI智算中心的基础设施工程师，在IDC里天天跟网卡驱动和光模块较劲的运维，以及想搞明白“为什么别人买的正品卡跑满速，我买的卡老是丢包”的采购和技术负责人。我不会讲太多PPT层面的概念，重点全部放在能落地的选型、配参数、排故障这些事上。

1. 先把组网思路拆明白：万卡集群到底在“组”什么

1.1 万卡规模不是“一张卡接一根线”，是分层拓扑

很多第一次接触万卡项目的人，第一反应是“不就是把服务器里的网卡都连到交换机上吗”。真到现场就发现完全不是这么回事。万卡集群里，“万卡”指的是GPU卡，不是网卡，一张GPU服务器节点通常配一到两块高速网卡，所以网卡数量级也在万张左右。把上万张网卡全部平铺到一台交换机上是不现实的，交换机的端口密度、背板带宽、功耗、散热都撑不住。

实际组网会分成几个层次：GPU服务器接入层、Leaf交换机汇聚层、Spine核心层，再往上还有管理网、存储网和业务网。接入层负责把服务器里的高速网卡（比如单端口400G的ConnectX-7）接到Leaf交换机上，这一层对线缆需求最大，也是DAC和AOC用得最多的地方；Spine层负责把整个集群的南北向流量跑起来，带宽预算主要砸在这里。分层的核心目的只有一个：让流量路径可控，避免东西向流量在某个点被卡死。

实操里有个很重要的观念：先把流量模型算清楚，再定交换机端口速率和线缆数量。比如你有1024个GPU节点，每个节点一块400G网卡，跑的是大模型训练，那么通信模式基本是AllReduce和AllGather这类东西向流量，接入层到Spine层的收敛比就不能按传统的“接入带宽大一倍”来设计，得按1:1甚至更高配才算稳妥。

1.2 InfiniBand还是RoCE，选型不是秀参数

万卡集群现在的主流组网方案就两个：InfiniBand和RoCE（RDMA over Converged Ethernet）。作为经销商，我见过太多客户在这上面纠结，本质是没搞清楚自己的业务和预算。

InfiniBand的强项在于无损网络、原生RDMA、端到端流控，NVIDIA的Quantum交换机加ConnectX网卡是最经典的“全家桶”组合，GPU Direct RDMA支持也好。DA最好、延迟最低，适合纯AI训练跑分场景。缺点是贵，交换机、网卡、线缆全部被绑定在生态里，后期扩容基本只能升NVIDIA。RoCE的优势是跑在以太网上，可以跟你现有的数据中心网络共用一套运维体系，线缆和交换机选型自由度高，成本肉眼可见地低。但RoCE要跑满性能，必须把PFC优先级流控、ECN、缓冲区这些参数全部调对，否则丢包一旦出现，RDMA性能会断崖式下跌。这类参数调优虽然没有技术封锁，但对运维团队的经验要求极高，建议预算里留出至少两周专项调优时间。

给个我常用的简单判断逻辑：如果项目定位是“纯AI训练集群”，未来三五年内也不打算跑太复杂的混合业务，InfiniBand闭眼上；如果既要训模型又要兼顾存储、业务虚机，而且团队对以太网熟悉，RoCE其实更划算。更重要的是，别把两类混在一个物理平面里跑，不然排障会排到怀疑人生。

1.3 计算平面、存储平面、管理平面要提前分开

万卡集群的拓扑里，我强烈建议把三类流量分成三个平面。GPU之间跑训练流量走RoCE或InfiniBand，存储访问流量走独立的存储网络，IPMI、SSH、监控这些管理流量走千兆管理网。很多中小规模项目图省事，把存储流量和管理流量跟训练流量放一起，结果一个存储节点抖动，整个训练任务就降速，损失远大于省下的那几台交换机。

分平面不只是物理上分开，IP规划、VLAN、路由策略也要分开。实际操作中，我的做法是把管理网放在独立网段，存储网单独划VLAN，业务/训练网走大二层或BGP动态路由。这里涉及到一个很现实的问题：线缆数量会翻着倍涨。比如原本一个节点只需要一根高速线缆，分平面之后可能变成一根训练网线、一根存储网线再加一根管理网线。但这点线缆成本，跟一次集群故障的损失比，完全不值一提。

1.4 万卡场景下迈络思产品线的定位速查

遇到新客户，我一般直接甩一张表让他们对照选型，省得来回沟通扯皮。

注意，表格不是唯一标准，网卡具体的OPN号要跟服务器型号做兼容性验证。比如ConnectX-7在不同代际的PCIe插槽上的跑速差异很大，插在PCIe 4.0 x16上能跑满400G，插在PCIe 3.0 x8上可能只能跑到200G左右，这个坑我见过不止一次。

2. 采购环节的门道：为什么“正品直供”不是一句口号

2.1 拆机卡、刷号卡和正品之间的差价陷阱

迈络思网卡在二手市场极多，很多“看起来全新”的卡其实是拆机翻新麦克风。这行有个术语叫“刷号卡”，就是把原厂的SN、MAC、PN等信息重新刷一遍，让系统读出来的信息看起来像正规渠道货。问题是，这类卡往往不是固件整体更新，而是部分信息被改，升级固件时极容易出现验证失败，甚至直接变砖；更关键的是，NVIDIA官方售后根本不认刷号卡，出问题只能自己承担。

我遇到过客户贪便宜，在电商平台拿了一批低价“代码卡”，上机一跑，发现设备管理器里显示正常，但MLNX_OFED装不上，VPD信息全是乱的。所以在这里说句得罪同行的话：万卡规模的项目，采购网卡和线缆一定要走正品直供渠道，别赌人品。正品直供的好处是能拿到原厂完整固件、可查的序列号记录、官方兼容性列表，以及换货保修服务。

2.2 采购必查的三样东西：OPN号、固件版本、兼容性列表

有些采购会觉得“型号对了就行”，这是另一个坑。同样叫ConnectX-7，不同OPN号对应的端口速率、挡板高度、散热器类型、PCIe接口都可能不同，比如双端口和单端口、短挡板和长挡板之间的OPN就完全不一样。上架之前一定要核对NVIDIA官方兼容性列表（一般叫“Supported Hardware”清单），确认该卡在目标服务器型号和驱动版本下被正式支持，不然就可能出现能识别但跑不满的问题。

固件版本也是老生常谈的坑。新出厂的卡固件版本一般没问题，但如果库房压货超过一年，固件可能落后。建议到货后第一时间烧录到该型号匹配的最新固化版本。烧固件这个操作要胆大心细，过程中断电必变砖，务必在UPS上操作。

2.3 线缆是万卡组网里最容易被低估的环节

万卡集群的线缆数量多到惊人，一根线有问题就可能导致一个GPU节点掉线。线缆主要分几类：DAC、AOC和光模块加光纤、以及InfiniBand生态里的HFA（混合光纤铜缆）。

DAC被动铜缆的优点是成本低、功耗低、延迟低，适合机柜内短距离互联，一般3米以内最稳。AOC有源光缆的优势是轻、细、传输距离远，适合跨机柜甚至跨机房场景，但价格和功耗都比DAC高。光模块+光纤的组最灵活，但需要找到与交换机/网卡兼容的模块型号，有个很不舒服的经验：原厂模块贵，兼容模块得逐型号测试，某些第三方的400G模块在部分交换机固件版本下会直接显示“不支持模块”，所以这部分的采购耐心极其重要。

选线缆这事我给个最朴素的建议：别只盯着速率看，还要看线缆的弯曲半径、拉力和接口类型。万卡集群走线密集，机柜里弯折太狠容易造成内部损伤。另外，正品线缆每条都有独立序列号和标签，验收时把这些标签归档，排查时会省很多事。

2.4 验收不只是“点亮”，要验速率、验误码、验温度

正品设备到货验收，不要插上能通就签收。我司对标准流程，一般包括以下几项：固件版本校验、VPD信息读取、ppc链路速率协商结果检查、持续压测误码率、以及温度场监控。新卡的散热片和机箱风道是否匹配也要注意，如果机箱的前后风向跟卡上的散热片方向冲突，长时间跑训练任务后会出现热飘移，导致链路质量下降。

3. 从驱动到参数：网卡侧真正的实践硬功夫

3.1 先装驱动还是先烧固件？我的顺序建议

刚到手的迈络思网卡，第一步不是插进服务器就完事。我推荐的操作顺序是：先在单机环境里更新固件，再装MLNX_OFED驱动，最后做链路测试，之后再批量交付。很多售前图省事，整批卡直接插进机架，结果有些节点驱动报错、有些固件版本不一致，后面挨个返工，时间成本远超“先测一台”的功夫。

MLNX_OFED在NVIDIA官网上有对应系统的编译版本，下载时留意内核版本匹配。安装过程中如果遇到“内核头文件缺失”，多半是系统版本和内核开发包不匹配。装完后用mst status能看到设备，用ibstat或ibstatus能看到链路状态和速率。Intel或AMD平台的BIOS设置里，记得开启SR-IOV和IOMMU，不然虚拟化场景后面的虚拟机直通会缺能力。

3.2 Linux下网卡开机自启、设备丢失、线缆“已拔出”这类问题

运维日常碰到的绝大部分问题，其实不是卡坏了，而是系统配置和驱动层的小事。“Linux网卡开机自启”失效，常见原因是没有用NetworkManager配置好连接或ifcfg文件里的ONBOOT没设成yes。迈络思网卡的接口名一般类似enp3s0f0，如果系统里看到但起不来，先看ethtool enp3s0f0的Link detected是什么状态，再查/var/log/messages里驱动上报的链路事件。

“ubuntu虚拟机 网络 线缆已拔出”这个问题，先确认宿主机上的PCI passthrough是否成功，虚拟机里看到的网卡是不是真的来自迈络思设备，而不是虚拟化的默认设备。如果虚拟网卡“不存在或被禁用”，打开VMware或KVM的虚拟网络编辑器，确认虚拟网卡没有被禁用、没有被防火墙拦截。牢记一条：物理链路正常不等于虚拟机内链路正常，中间还隔着宿主机虚拟交换机和驱动。

3.3 链路聚合和trunk：Realtek能做，迈络思怎么做更稳

不少人在“网卡 属性设置”或“realtek网卡trunk”这些词里找答案，其实链路聚合的标准做法是通用的。在Linux里做Bond，可以用ip link add bond0 type bond mode 802.3ad，然后把两张网卡加入bond，配合交换机的LACP链路聚合组。迈络思网卡跑bond的稳定性很好，关键是注意两点：一是两张物理网卡要插在不同的PCIe控制器上，避免共享同一个上行造成瓶颈；二是bond模式选择上，万卡训练场景更推荐balance-xor或802.3ad，别用主备模式，不然带宽直接减半。

另外在华为、锐捷、思科这些交换机上做trunk口，要放行正确的VLAN ID。我在现场帮客户排查过一个问题：业务VLAN是100，交换机trunk口没放行，结果服务器侧网卡显示链路通、IP也能配上，但就是ping不通网关。这类问题不是驱动问题，是VLAN放行的事，先看交换机配置，再抓包确认tag是否一致。

3.4 性能参数：MTU和流控才是跑满速的关键

迈络思网卡默认MTU一般是1500，但万卡集群内部通信强烈建议开启巨帧，把MTU调到9000甚至更大的值。原因很简单，大模型训练动不动就要搬几百GB的权重，帧越大、帧数越少，CPU处理开销和协议开销都越小。RoCE场景下还必须在交换机上开启PFC和ECN，网卡侧要开启RDMA的拥塞控制参数。这些配置出问题时，典型现象是：IB或RoCE链路100G协商成功，但实际吞吐只有20G。

流控方面，很多时候网卡“没有电源管理”反而重要，因为省电模式会触发链路降速。在服务器BIOS和网卡属性里把电源管理关掉或设为最高性能，是万卡场景下的默认操作。网卡监听模式（混杂模式）在抓包诊断时很有用，tcpdump -i eth0 -e可以抓到带VLAN tag的帧，但在生产链路上长时间开混杂模式会带来额外的CPU开销，排查完记得关掉。

3.5 虚拟化场景：ESXi装不上、虚拟机没虚拟网卡、直通要注意什么

ESXi安装提示没有网卡，多半是网卡不在ESXi官方HCL列表里，或者ISO镜像缺驱动。常见办法是，找一个包含对应社区驱动的定制ISO，安装时把驱动注入进去。还有一类问题是在VMware里做PCI直通，把迈络思网卡直通给虚拟机，前提是宿主机的IOMMU/SR-IOV功能打开，否则直通列表里根本看不到网卡。

飞牛USB网卡、联想小新Pro这类个人设备上遇到的“网卡驱动下载”问题，多数是设备芯片不被当前系统识别。解决思路是一样的：确认芯片型号，下载对应厂商驱动，然后在系统里卸载默认失败驱动再安装。USB 2.0接口跑千兆网卡是跑不到满速的，这是硬件限制，不是网卡问题。

4. 高频故障记录：从“网卡灯不亮”到“虚拟网卡不存在”

4.1 网卡灯不亮但“网线确认是通的”

这是最经典的排查场景。记住一句话：网线通不等于网卡协商成功。先确认网卡是否被系统识别，再确认对端设备是否强制开启了某种速率或双工模式。有些交换机端口配置了shutdown状态或者只允许特定VLAN通过，网卡灯就不会亮。还有很常见的原因：用的是不合格的RJ45水晶头，屏蔽层没接好，导致链路协商失败。光纤/DAC线缆同理，检查光模块收发光功率、检查DAC线缆是否插到位，偶尔还有端口脏污的问题，拿专用清洁笔擦一擦就好了。

4.2 设备管理器里网卡正常，但系统里就是没有IP

Windows下出现这问题，先看网络适配器有没有被禁用、驱动服务是否启动；设备管理器正常但网络连接里连“本地连接”都没有，常见原因是网卡未被系统分配PCI资源，去BIOS里确认PCIe插槽是否设置为启用。Linux里用lspci | grep Mellanox确认设备可见，再查dmesg里有没有报firmware failed to load的信息，如果固件加载失败，需要重新烧录固件或重新安装驱动。

4.3 链路协商了，却跑不到标称速率

一台服务器网卡显示400G协商成功，但实际传输只能跑200G，这种现象在万卡集群里很刺眼。先排查PCIe瓶颈，比如网卡插在了PCIe 3.0 x8的槽位上；接着看交换机端口是否配置了速率限制，再看网卡驱动的队列数量，RSS队列只开了一个，单流吞吐就会卡死。还有一个隐蔽的问题“网卡 信道宽度”——无线网卡里的“信道宽度”和有线网卡的信道不是一回事，有线网卡关注的是上下行速率和FEC模式，必要时在交换机侧与网卡侧把FEC模式配成一致。

4.4 虚拟网卡在Linux里“不存在或被禁用”

这类问题多出现在Ubuntu的NetworkManager管理策略上。nmcli device status里看到设备状态是unmanaged，NetworkManager就不会自动配置，解决方式是nmcli device set enp3s0f0 managed yes，或者写netplan配置。

4.5 Realtek、USB网卡、个人电脑网卡的常见兼容性问题

万卡集群里面不会用Realtek网卡，但分布式存储节点、管理节点经常用到。Realtek网卡在Linux下驱动一直被人吐槽，新的8125/8126芯片建议直接用厂家最新的r8168/r8126驱动，别依赖内核自带模块。USB千兆网卡和笔记本网卡驱动的问题，大多是USB控制器和网卡芯片兼容性不好，优先确认主板USB接口是否支持USB 3.0，再用系统更新工具把网卡固件和驱动更新到最新。ax201这类WiFi网卡无法启动，常见原因是内核驱动iwlwifi版本不匹配，升级内核或安装对应linux-firmware包即可解决。

4.6 常见故障速查表

5. 拿来就能用的避坑清单，以及部署流程复盘

5.1 到货后的标准化验收步骤

先说结论：万卡项目的网卡和线缆验收动作越早做，后面故障越少。我把验收固定成四个动作：清点序列号并入库，逐卡烧录固件到统一版本，单机压测链路误码，并将合格批次打标归档。不要只抽检，万卡规模没有“抽检”的容错空间。

5.2 布线规范决定排障效率

线缆标签就是排障地图。在万卡集群里，每根DAC或AOC线缆两端都要贴上同一编号的标签，标签上写明对端设备端口号和IP段，走线按机柜排列顺序捆扎。我有一次帮客户排查断链，几千根线里找到一条两端标签不一致的，最后定位是有人换线后没同步改标签，从此每次进场都强制推行双人复核。

5.3 驱动和固件版本管理要像管代码一样

给营业中的集群升级驱动或固件属于高风险动作，升级前必须先在测试节点跑完整压测。正确做法是，把版本信息记录进资产台账，升版前从正品经销商拿到对应的固件包和释放说明，再按“单节点验证→小批量灰度→全量滚动”的流程操作。千万别直接在万卡集群里一口气全量升级，一旦某个Switch的固件和HD卡固件不兼容，整个集群训练任务会全部中断。

5.4 关于“经销商”的实话：我为什么愿意把这些写出来

作为迈络思网卡和线缆的经销商，我完全可以把这些经验藏起来、让客户多跑几趟售后，但那不是我的做事方式。设备硬件本身的利润其实越来越透明，真正有价值的服务是谁能帮客户把组网一次做对、把故障时间压到最短。这批正品直供的网卡和线缆只是载体，让万卡集群真正稳定跑起来才是交付物。

6. 最后分享一点个人体会

做这么多项目下来，我最大的感受是，万卡集群组网的难点从来不在某一个单一设备，而在所有环节的咬合。采购端选对了正品网卡和线缆，只是把基础打牢；真正的差距在于工程人员对硬件的理解和对细节的执行。你在实机上调过的每一个MTU值、每一组bond模式、每一条VLAN放行，都会在集群跑起来的那一刻得到回报。

现场调试时我最喜欢把一句话挂在嘴边：网络是沉默的，它不会在你出错时抱怨，只会用掉速和丢包来报复你。多留一分耐心做固件版本对齐，多花一分钟翻兼容性列表，多给线缆做一次标签检查，这些动作看起来不起眼，但攒下来的稳定性，最终会以训练任务的按时完成率回报你。希望这些踩过的坑和攒下的经验，能在你下一次组网时派上用场。