1. 从31款方案说起AI超节点到底在解决什么问题第一次看到31款国内AI超节点方案这个标题我脑子里冒出来的第一个念头不是哇好多方案而是为什么会有这么多方案同时冒出来。这背后一定有一个共同的痛点被反复戳中了否则不会有这么多团队在同一时间往同一个方向使劲。先把概念说清楚。所谓AI超节点本质上是一种把多台计算设备通过高速互联总线紧密耦合在一起、对外表现为一个逻辑整体的系统架构。它要解决的核心矛盾是单台服务器的算力、显存容量、互联带宽都已经摸到天花板了但大模型训练和推理对这三样的需求还在指数级往上走。你不可能无限堆GPU卡在一台机器里PCIe插槽有限、供电有限、散热有限所以必须把多台机器焊成一个更大的计算单元。这个焊字是关键。普通的分布式集群也能把多台机器连起来但那是松耦合的节点之间走的是传统以太网通信延迟高、带宽窄跑大模型训练的时候通信开销能吃掉一大半的有效算力。超节点走的是另一条路——用高速互联协议各家有各家的实现把节点间的通信带宽拉到接近板内总线的水平同时把延迟压到微秒级。这样一来原本需要跨网络传输的张量并行、专家并行通信就变成了近似内存访问的操作。那为什么是31款这个数字本身就说明了一个现实这个赛道还没有收敛。没有哪一家能拿出一个通吃所有场景的方案所以大家都在根据自己的技术积累和客户资源切不同的细分市场。有的主打训练场景的超大规模扩展有的专攻推理场景的低延迟响应有的走性价比路线用相对成熟的互联技术有的押注全光互联的前沿方向。这31款方案大致可以分成几个流派后面我会逐一拆解。这篇文章适合谁看如果你是做AI基础设施选型的技术负责人或者正在搭建训练/推理集群的工程师再或者你只是对这个领域好奇、想搞清楚各家方案到底差在哪那这篇内容应该能帮你省下不少翻文档和对比参数的时间。我会尽量把每个方案的核心思路、适用场景、关键参数和实操中容易踩的坑都讲清楚让你看完之后至少能判断出哪个方向适合我现在的需求。提示本文涉及的方案信息基于公开资料和行业常见实践整理具体产品参数请以各厂商最新官方文档为准。文中提到的实操经验来自实际部署中的常见问题总结供参考。2. 31款方案的整体格局与分类逻辑2.1 按互联技术路线分三大流派把这31款方案摊开来看最直观的分类维度是互联技术路线。这就像选车先看发动机类型一样互联技术决定了整个超节点的性能上限和成本结构。第一派基于PCIe Switch的Scale-Up方案。这是目前国内落地最多的路线。核心思路是在一台或多台服务器内部署PCIe Switch芯片把多张GPU卡通过PCIe总线连成一个高带宽域。优点是技术成熟、生态完善、成本相对可控缺点是PCIe的带宽扩展能力有上限当卡数超过一定规模后Switch的级联层数增加会带来延迟上升。这一派里又分两种做法一种是在单机箱内做8卡或16卡的全互联另一种是跨机箱用PCIe Cable做更大规模的扩展。第二派基于私有高速互联协议的方案。这类方案不依赖标准PCIe而是用自研或定制的互联协议和物理层把带宽和延迟做到比PCIe更好的水平。典型特征是配套专用的交换芯片和网卡形成一个相对封闭但性能更强的系统。优点是扩展性好、延迟低适合大规模训练缺点是生态相对封闭迁移成本高而且不同厂商之间的方案不互通。第三派基于以太网增强的方案。这一派走的是在标准以太网上做文章的路子通过RDMA over Ethernet或者类似的增强技术把以太网的通信效率提升到接近专用互联的水平。优点是兼容性好、运维体系成熟、成本最低缺点是极限性能不如前两派更适合对成本敏感或者规模不是特别大的场景。2.2 按应用场景分训练派 vs 推理派除了技术路线另一个重要的分类维度是目标场景。训练和推理对超节点的需求差异很大这直接影响了方案的设计取舍。训练场景的核心诉求是大规模并行效率。一个大模型训练任务可能要同时用到几百甚至上千张卡这些卡之间需要频繁同步梯度、交换激活值。如果互联带宽不够通信就会成为瓶颈卡越多效率反而越低。所以训练派的超节点方案通常追求极高的互联带宽和极低的延迟为此不惜成本。典型特征是支持大规模张量并行和专家并行互联拓扑设计复杂配套的通信库优化做得很深。推理场景的核心诉求则是低延迟和高吞吐的平衡。推理任务通常不需要那么多卡同时协作但对单次请求的响应时间很敏感。所以推理派的超节点方案更注重单节点内的计算密度和显存带宽互联规模可以小一些但节点内的数据搬运效率要极高。另外推理场景对成本更敏感因为要大规模铺开部署所以性价比是重要考量。2.3 按部署规模分从8卡到超大规模还有一个实用的分类维度是部署规模。这31款方案覆盖了从最小8卡节点到超大规模集群的全谱系。8卡节点是最基础的形态通常在一台服务器内通过PCIe Switch实现全互联。这种方案适合中小规模训练和推理部署简单、成本可控是很多团队起步的首选。16卡到32卡节点开始需要跨机箱互联对布线和散热的要求明显提高。64卡以上的超大规模节点就是真正的超节点了需要专门的机柜设计、液冷散热、定制化的供电和布线方案部署和维护的复杂度都上了一个台阶。下面这张表可以帮你快速定位不同规模方案的特点规模典型互联方式适用场景部署复杂度成本水平8卡板内PCIe Switch中小训练/推理低中16-32卡PCIe Cable/私有互联中等规模训练中中高64卡以上私有互联/光互联大规模训练高高注意规模不是越大越好。我见过不少团队盲目追求大规模超节点结果实际负载根本跑不满反而因为运维复杂度上升导致整体效率下降。选型时一定要先搞清楚自己的模型规模和并发量。3. 核心方案深度拆解几个典型路线的技术细节3.1 PCIe Switch路线成熟但需要精打细算PCIe Switch路线是这31款方案里占比最大的。它的核心组件是一颗或多颗PCIe Switch芯片负责把多张GPU卡连接起来。你可以把它理解成一个PCIe交换机就像网络交换机把多台电脑连在一起一样PCIe Switch把多张GPU卡连在一起。这里的关键参数是PCIe Lane数量和代际。目前主流是PCIe 4.0和5.0单条Lane的带宽分别是16GT/s和32GT/s。一张GPU卡通常需要x16的Lane宽度所以一个支持64 Lane的Switch最多只能直连4张卡。要连更多卡就需要多颗Switch级联。级联带来的问题是延迟增加和带宽收敛。假设你用4颗Switch做两级级联第一级Switch下面的卡要访问第二级Switch下面的卡数据需要经过两次Switch转发延迟自然比直连高。而且如果级联的上行带宽不够还会出现带宽收敛多张卡同时跨级通信时就会拥堵。实操中怎么选我的经验是8卡以内优先选单Switch全互联方案延迟最低、带宽最均衡。16卡以上就要仔细看Switch的级联拓扑了尽量选上行带宽充足的方案避免出现明显的带宽瓶颈。另外要注意Switch芯片的功耗和散热高性能Switch的功耗不低机箱散热设计要跟上。3.2 私有高速互联路线性能强但生态是门槛私有高速互联路线是这几年国内厂商发力比较猛的方向。核心思路是绕开PCIe的限制用自研的协议和物理层实现更高的带宽和更低的延迟。这类方案的技术细节各家差异很大但有几个共同的关注点。首先是物理层有的用铜缆有的用光模块。铜缆成本低、延迟低但传输距离短适合机柜内互联光模块传输距离远适合跨机柜甚至跨排互联但成本和功耗都更高。其次是协议层有的方案在PCIe协议上做增强有的完全重新设计。协议设计的好坏直接决定了通信效率和编程友好度。这类方案最大的优势是扩展性好。因为不依赖PCIe的层级结构可以通过交换网络实现更大规模的扁平化互联理论上可以扩展到几百甚至上千张卡。而且延迟可以做到比PCIe Switch更低对大规模训练场景很有吸引力。但门槛也很明显。生态封闭是最大的问题。你的训练框架、通信库、算子库都需要针对这套互联协议做适配迁移成本很高。而且不同厂商的方案不互通一旦选了某家的路线后续升级和扩展就被绑定了。另外这类方案的运维体系通常不如以太网成熟出问题排查起来更麻烦。3.3 以太网增强路线性价比之选以太网增强路线是这三派里最接地气的。它的核心思路是在标准以太网的基础上通过RDMA远程直接内存访问技术把通信效率提上去。RDMA允许一台机器直接访问另一台机器的内存不需要经过CPU和操作系统内核大大降低了通信延迟和CPU开销。具体实现上有的是RoCERDMA over Converged Ethernet有的是iWARP还有各家自己优化的版本。关键参数是带宽和延迟。目前主流的100G/200G以太网方案延迟可以做到微秒级虽然比私有互联略高但已经能满足很多训练场景的需求了。这条路线的优势很实在兼容性好、成本低、运维成熟。你可以用标准的以太网交换机和网卡运维团队不需要重新学习一套体系。而且以太网生态庞大各种工具和方案都很丰富。缺点是极限性能不如前两派当规模特别大、通信特别密集时以太网的 overhead 就会显现出来。我的建议是如果你的训练规模在几十张卡以内或者推理场景为主以太网增强路线是性价比最高的选择。只有当规模上百卡、且通信模式对延迟极度敏感时才需要考虑私有互联路线。4. 实操选型怎么从31款里挑出适合自己的4.1 先算清楚自己的需求账选型最怕的就是看着都好。我见过太多团队在选型时被各种参数晃花了眼最后选了一个参数最漂亮但实际用不上的方案。避免这个问题的唯一办法是先把自己的需求算清楚。需要算的账包括模型规模参数量、层数、注意力头数、训练/推理的并发量同时跑几个任务、每个任务用多少卡、通信模式是张量并行为主还是数据并行为主、预算范围硬件采购运维电力、机房条件供电容量、散热能力、机柜空间。举个例子。假设你要训练一个百亿参数级别的模型用张量并行切到8张卡数据并行切到4组总共需要32张卡。这种情况下通信主要发生在张量并行的8张卡之间需要高带宽低延迟的互联数据并行的4组之间通信频率低一些可以用普通以太网。那么选型时就应该优先考虑单节点内8卡全互联节点间以太网的方案而不是一上来就搞64卡超节点。4.2 关键参数对比别被峰值数字忽悠厂商宣传册上的参数往往都是峰值数字实际能跑到多少是另一回事。看参数时要重点关注这几个互联带宽注意区分单向带宽和双向带宽以及是理论峰值还是实测值。有些方案标称带宽很高但实际有效带宽可能只有标称的一半。延迟同样要注意是空载延迟还是满载延迟。空载时延迟很低一旦负载上来延迟可能翻几倍。有条件的话一定要看实测数据。扩展性支持的最大卡数、扩展时的带宽收敛比、级联层数对延迟的影响。这些参数决定了你未来能不能平滑扩容。功耗和散热高性能互联的功耗不低整机功耗可能比普通服务器高出一大截。机房供电和散热能不能跟上这是很多团队容易忽略的问题。下面这张表是我在实际选型中常用的对比框架评估维度关键问题权重建议性能实测带宽/延迟能否满足业务需求30%生态框架/库适配是否完善迁移成本多高25%成本硬件运维电力的总拥有成本20%扩展性未来扩容是否平滑上限在哪15%运维故障排查是否方便团队是否熟悉10%提示权重可以根据自己的实际情况调整。比如团队技术实力强、愿意折腾生态权重可以降低如果机房条件有限功耗和散热的权重就要提高。4.3 实操心得三个容易踩的坑第一个坑只看互联不看计算。超节点的核心价值是让多卡协同更高效但如果单卡的计算效率本身就不行互联再好也白搭。选型时要确保计算和互联是匹配的不要出现互联带宽过剩但算力不足或者反过来算力很强但互联拖后腿的情况。第二个坑忽略软件栈的成熟度。硬件参数再漂亮如果配套的通信库、算子库、训练框架适配做得不好实际用起来就是各种报错和性能不达标。选型时一定要问清楚支持哪些训练框架通信库的版本更新频率如何有没有实际客户的案例可以参考第三个坑低估运维复杂度。超节点的运维比普通集群复杂得多。互联链路的监控、故障定位、固件升级、拓扑管理每一项都需要专门的工具和技能。如果团队没有相关经验建议先从规模小一点的方案起步积累经验后再扩展。5. 部署与调优从开箱到跑满性能5.1 上架前的准备工作超节点上架不是把机器塞进机柜就完事了。供电是第一道关。一台满载的超节点服务器功耗可能达到几千瓦甚至上万瓦普通机柜的供电容量根本不够。需要提前确认机柜的PDU容量、线路规格必要时做电力改造。散热是第二道关。高密度部署意味着单位体积的发热量大幅增加风冷可能压不住需要考虑液冷方案。液冷又涉及管路设计、冷却液选择、漏液检测等一系列问题。布线是第三道关也是最容易被低估的。超节点内部的互联线缆数量远超普通服务器而且对线缆长度、弯曲半径、走线路径都有要求。线缆没布好轻则影响散热重则导致信号完整性下降、链路不稳定。我的经验是布线方案要在设备到货前就设计好最好让厂商提供参考布线图不要等到现场再临时发挥。5.2 系统初始化的关键步骤设备上架通电后第一步是固件和驱动的一致性检查。超节点涉及多个组件GPU、Switch、网卡、BMC每个组件都有自己的固件版本。版本不匹配是导致各种诡异问题的常见原因。建议在初始化阶段就统一固件版本并记录在案后续升级时保持一致。第二步是拓扑发现和验证。用厂商提供的工具或者自己写脚本把整个互联拓扑扫一遍确认每张卡、每个端口都正确识别链路带宽和延迟符合预期。这一步能提前发现布线错误或者硬件故障避免后面跑训练时才发现问题。第三步是通信库的配置和调优。不同的通信库有不同的调优参数比如NCCL的环境变量、RDMA的队列深度、拥塞控制算法等。这些参数需要根据实际负载反复调整没有一套通用的最优配置。建议先用小规模测试跑起来逐步调参找到适合自己业务的配置。5.3 性能调优的实操记录性能调优是个细活。我一般按这个顺序来先测单卡性能再测节点内多卡通信最后测跨节点通信。每一步都记录基线数据这样出问题时能快速定位是哪一层的问题。节点内多卡通信的调优重点是通信模式的选择。以NCCL为例它支持Ring、Tree、CollNet等多种通信算法不同算法在不同规模下的表现差异很大。小规模时Ring可能更快大规模时Tree或者CollNet更有优势。可以通过环境变量强制指定算法然后实测对比。跨节点通信的调优重点是网络配置。RDMA的队列深度、MTU大小、拥塞控制参数都会影响性能。另外要注意NUMA绑定确保GPU和网卡在同一个NUMA节点下避免跨NUMA访问带来的额外延迟。注意调优过程中一定要有耐心每次只改一个参数改完立即测试并记录。同时改多个参数出了问题根本不知道是哪个引起的。6. 常见问题与排查技巧实录6.1 链路类问题带宽不达标、延迟偏高链路问题是超节点部署中最常见的。表现通常是训练速度比预期慢、通信库报超时错误、某些卡之间的通信明显比其他卡慢。排查思路是先看物理层再看协议层最后看应用层。物理层检查包括线缆是否插紧、光模块是否正常、端口指示灯状态、误码率统计。协议层检查包括链路是否协商到了预期的速率和宽度、是否有降速降宽的情况、流控和重传统计是否正常。应用层检查包括通信库的日志、拓扑发现结果、实际通信带宽测试。一个常见的坑是线缆混用。不同规格、不同长度的线缆混在一起可能导致某些链路协商不到最高速率。建议同一批链路使用相同规格的线缆并且长度尽量一致。6.2 性能类问题跑不满、波动大性能跑不满的原因很多我整理了一个速查表现象可能原因排查方法整体性能只有预期的一半通信库配置不当检查NCCL环境变量、算法选择性能波动大散热降频/功耗墙监控GPU温度和功耗检查散热某些卡明显慢链路降速/硬件故障检查链路状态和误码率大规模时性能骤降网络拥塞/拓扑瓶颈检查交换机端口统计和拓扑结构散热降频是特别容易被忽略的问题。超节点密度高如果散热没做好GPU温度上来后会自动降频性能就下来了。建议部署后持续监控温度确保在满载时也能压在安全线以内。6.3 稳定性类问题偶发报错、训练中断偶发问题最难查因为复现困难。我的经验是做好日志收集和监控把每次报错的时间、节点、卡号、错误码都记录下来积累多了就能看出规律。常见的偶发问题包括ECC错误显存或互联链路的软错误、驱动超时GPU驱动无响应、通信超时链路瞬断或拥塞。针对ECC错误可以开启ECC日志并定期检查针对驱动超时可以调整超时阈值并关注是否有固件bug针对通信超时可以增加重试机制并优化拥塞控制。还有一个实用技巧保留一套最小复现环境。当出现偶发问题时能在最小环境里复现排查效率会高很多。这个环境可以是单节点8卡配置和正式环境一致但规模小、干扰少。7. 我个人的选型体会折腾了这么多方案我最大的体会是没有最好的方案只有最合适的方案。31款方案看着多但真正符合你需求的可能就那么两三款。关键是想清楚自己的核心诉求是什么然后围绕这个诉求去筛选。另外不要忽视软件和生态。硬件参数是看得见的软件栈的成熟度是看不见的但后者往往更影响实际使用体验。选型时多问问实际用户的反馈比看宣传册有用得多。最后分享一个小技巧如果拿不准先小规模试点。买几台设备搭一个小集群把实际业务跑起来看看性能、稳定性、运维体验到底怎么样。试点的成本远低于大规模采购后才发现不合适的代价。这个思路在超节点选型上尤其适用因为不同方案的实际表现和纸面参数之间的差距有时候真的挺大的。