MWC 2026 现场华为由周红伟对外发布了新一代 8192 卡超节点算力集群。我看到这条消息时最在意的不是“8192”这个数字本身而是“超节点”这三个字。从 AI 基础设施的角度看这意味着一次根本性的架构变化不再把几千张加速卡当成一个松散集群来管理而是把它们当成一台机器来设计。换句话说这不是堆卡是换一种组网和计算协同的方式。这篇文章我会把这件事拆开讲讲为什么需要把 8192 张卡做成一个超节点、背后的技术难点在哪、对普通 AI 团队和算力中心来说意味着什么以及它对整个大模型产业会带来哪些影响。适合正在做模型训练、买算力、设计数据中心或者单纯想搞清 AI 算力方向的人看。1. 8192卡超节点为什么这是算力分水岭1.1 超节点和万卡集群是两种完全不同的逻辑先理清一个容易被混淆的概念。过去几年大家常听到“万卡集群”说的是把一万张加速卡通过数据中心网络连起来。这种集群的组织方式和传统 IDC 里的服务器集群没有本质区别单机 8 卡是第一个通信域机架顶部交换机 TOR 是第二层再到脊交换机、核心交换机一层一层往上走。跨机通信要经过的网络跳数很多一跳到 TOR再跳跨机架再跳到汇聚延迟从几百纳秒一路涨到几微秒甚至更高。对传统 HPC 任务来说这种多级网络完全够用。但大模型训练恰恰是所有并行计算里对通信最苛刻的场景之一每个训练迭代里所有卡都要把各自计算的梯度同步一遍然后再开始下一步。语义上跟“全局规约”一样所有卡每几十毫秒就要做一次全员通信。网络层数越多、跳数越多、延迟越高GPU 等通信的时间就越长算力浪费就越严重。超节点的思路反过来了它把所有加速卡放在一个高带宽、低延迟的物理域里卡与卡之间尽量走机箱内部的高速互联而不是外部交换网络让通信行为无限接近“单机内多卡通信”。8192 卡超节点表面上是数量刷新本质上是回答了“物理上能不能把这么多卡做成一台机器”这个问题。到了这个规模单机和集群的边界被抹掉了你手里拿着的是一台拥有 8192 个计算单元的逻辑主机。从部署角度看万卡集群是横向扩展模型超节点是纵向扩展模型。前者的瓶颈在骨干网带宽后者的瓶颈在卡间互联和集合通信效率。1.2 一次梯度同步背后藏着多少数据为什么数量到了这个级别通信就成了最大瓶颈我用一组数字说明。假设单卡用于训练的显存规模是 144GB8192 卡凑在一起总显存规模大约 1.18PB。训练一个 1.8 万亿参数的 MoE 模型如果参数按 BF16 格式存储一份模型参数就是 3.6TB。理想情况下一次全局梯度 AllReduce 至少要把 3.6TB 的数据在所有卡之间同步一轮才算完成信息交换。这个量级打个比方3.6TB 的数据相当于 700 多张蓝光光盘的内容。如果跨 8192 卡做一次同步网络层面需要搬运的数据量会放大到接近 29PB。就是网络带宽再好如果互联设计不配套每一次迭代都是灾难性的等待。所以 8192 卡超节点的真正门槛不是服务器采购清单而是卡间网络能不能撑住这种数据吞吐。业界通常要求单卡对外等效带宽在几百 Gbps 以上才敢谈万亿级模型的稳定训练。华为这次发布的新一代超节点通信域规模达到 8192 卡等于把这条“路”修到了可以跑大规模梯度同步的宽度。这也解释了为什么超节点都在强调“高维互联”和“全互联”通信不是等模型算完才开始的而是在训练过程中每一层计算结束后就要启动。算得快还是慢很大程度取决于同步瓶颈。2. 把8192张卡拧成一张卡四个关键环节2.1 网络拓扑全互联是理想高维部分是现实如果要求 8192 张卡两两之间都有独立链路形成一个完全图那链路数量大约是 8192×8191 除以 2也就是 3355 万条。这个数字根本不现实线缆、交换芯片、功耗和机房空间都扛不住。所以超节点架构里设计者普遍采用“高维部分互联”的思路卡与卡之间不追求两两互通而是让任意两张卡之间的逻辑距离尽量短。具体实现有很多路线常见的是把卡分成多个子组组内做高基数全互联或高维 Torus组与组之间再通过高速链路互连。好处是通信密度最高的部分被限制在物理域内部跨域通信只承载相对低频的数据交换。这在效果上接近“把原来放在数据中心核心交换机里的功能搬进机箱内部”。从网络设计者的角度看超节点网络可以类比成一座城市的路网不可能每两栋楼之间修一条专用路但可以让每栋楼快速接入主干道再配合立交桥实现低延迟切换。8192 卡超节点的拓扑设计说到底就是做一张覆盖一万个节点的“城市级快速路网”。现实中的数据中心网络管理员如果维护过大型 AI 训练集群一定清楚跨交换机通信的队列延迟有多折磨人。超节点把这种痛苦大幅压缩但也把网络设计工作从“机架-交换机”层面下沉到了“封装-互联”层面。2.2 集合通信让数据交换更快更早硬件网络修得再宽软件不知道“怎么高效地用”也是白搭。超节点架构的第二根支柱是集合通信库。大模型训练里最常用的两个操作是 AllReduce 和 AllGather。AllReduce 是把所有卡的梯度加起来再分发回去AllGather 是把每张卡的数据拼到一起供全体使用。这些操作的执行效率直接影响训练速度。硬件带宽只能给出理论上限实际能逼近多少要看软件能不能生成好的通信算法比如用环形、树形还是分层模式来执行规约还要看通信与计算的重叠程度。在传统集群里开发者经常用“梯度切块 多流通信”来缓解计算和通信的串行等待。到 8192 卡超节点这种重叠已经不只是优化技巧而是必需的基线能力。比如模型反向计算到某一层时通信库可以先发出已算完部分的梯度而不是等所有层算完再发起一次大同步。数据在路上跑的时候计算单元继续算下一块流水线才不空转。华为做通信设备出身对“怎么在链路上高效传数据”有很深的积累。超节点里集合通信库的调度、重传、组播、容错都延续了这些经验。这也是为什么很多传统 ICT 厂商做 AI 集群时反而有后发优势——网络的底层规律是相通的。2.3 算力池化一台逻辑机器多套动态切分超节点和传统集群的另一个关键差别是支持“节点内动态切分”。8192 张卡并不一定要始终作为一个整体对外提供服务。它可以把 8192 卡切成多个逻辑域比如切成 4 份各 2048 卡同时分给 4 个团队训练不同模型也可以临时合并成一个超大域供某个万亿参数模型独占训练。传统集群不是不能做资源池化但物理隔离的约束很强。分组管理只能按物理机架或交换机域来划不同组之间的跨界通信性能非常差基本不会让跨组任务互相访问。超节点因为网络拓扑和高带宽互联是内生设计的逻辑域的拆分和合并可以在毫秒级完成而且拆完之后的子域依然享受低延迟和高带宽。对平台运营方来说这是很大的商业模式优势。租一台超节点中的一块算力和在传统集群里租一堆服务器在性能保证上完全是两个概念。前者能给出明确的通信性能承诺后者只能“尽力而为”。2.4 容错设计万卡级设备“不坏”是不可能的万卡规模下故障不是概率问题是时间问题。一块加速卡、一根线缆、一个交换芯片任何一个部件出问题都可能让整个训练任务停滞。业内常用的一个数据是千卡集群每运行一天出现一次硬件故障都很正常8192 卡只会更多。超节点必须有完整的故障检测、任务迁移、断点续训机制否则理论算力再高也用不起来。具体来说至少包含三个环节硬件健康检查要实时发现故障并隔离训练框架要能在故障发生后在剩余可用卡上继续训练还要定期对模型权重和优化器状态做检查点存储这样即使大面积故障也能恢复到最近状态重新跑。在很多大模型团队里断点续训是工程成熟度的重要标志。新架构发布后我最关心的其实不是峰值性能而是它是否能在万卡规模下保持稳定可用。8192 卡超节点如果能把故障自愈做成默认能力那它对训练工程化的意义会比单纯堆卡更大。3. 普通团队如何评估并落地8192卡级算力方案3.1 先从目标模型倒推算力预算对绝大多数团队来说买 8192 卡不太现实但可以评估是否租用这种超节点算力或者为所在机构做选型分析。评估的第一步是从目标模型反推需求。假设一个团队要训练 1.8 万亿参数的 MoE 模型目标是在合理时间内完成训练。先把账算明白模型参数总量 3.6TB训练数据可能达到 2 万亿 token。如果采用混合并行策略真实可用算力取决于总峰值算力乘一个“扩展效率”。经验上传统千卡集群扩展到 8192 卡后扩展效率如果能保持在 0.5 以上就已经是非常好的水平。如果目标是让训练周期缩短到原来的十分之一那么需要的总卡数不能简单按等比例放大要留有更多的冗余和效率缓冲。实操建议是先把两组数字列出来一组是模型规模、并行策略、收敛所需的训练 token 总量另一组是单卡算力、显存大小和互联带宽。两者匹配再谈采购或租用。3.2 并行策略怎么配看看这张表大模型训练不是简单地把数据切成多份分发下去而是多种并行方式叠加。到了 8192 卡规模并行策略的组合直接决定通信压力分布选错了就是大规模资源空转。并行维度通信频率通信数据量合理建组范围数据并行DP每个迭代一次梯度同步取决于模型大小可跨超节点域张量并行TP极高逐算子通信高尽量限制在物理就近域内流水线并行PP较低只在边界同步中可以跨卡组部署序列并行SP高长序列下显著中高与 TP 配合使用同类就近专家并行EP中高MoE 路由token 相关建议放节点内从这表里能看出一个规律通信频率越高、数据量越大的并行维度越要放在物理互联条件最好的区域。部署 8192 卡超节点时通常会把 TP、SP、EP 放在超节点内部把 DP 放在超节点之间形成“通信适配拓扑”的组合。这是沿用已久的工程准则超节点把它变得更顺理成章而已。3.3 数据与存储别让数据管线拖后腿算力越强存储和数据处理越容易变成瓶颈。8192 卡同步训练时每个迭代消耗的样本数量相当可观。假设全局 batch size 是 8192每个训练样本平均 3KB 文本一个迭代读入的原始数据就有 25MB 以上而且这只是“入口”训练过程中的随机采样、预取、tokenize 都会把 I/O 压力放大很多倍。建议参考的配置是三点第一原始数据集放在并行文件系统或者高性能对象存储里第二训练节点配置本地高速缓存比如 NVMe 缓存池把高频读取的数据尽量放在离卡近的地方第三数据加载采用异步流水线边训练边预取下一批数据而不是等一个 batch 读完再开始计算。在这些基础上还要考虑检查点存储。万亿参数模型的检查点动辄 TB 级每 N 分钟存一次存储的写带宽消耗也很可观。这些细节在千卡集群里容易被忽略到 8192 卡会被无限放大。新集群第一次大规模训练最常出问题的不是算力而是数据管线。3.4 机房、供电、散热与运维细节8192 卡超节点对整个基础设施的要求和普通机柜机房完全不同。以单卡 700W 到 1kW 计算整节点的功耗大约在 3.5MW 到 4MW 之间加上互联交换、存储和制冷一个逻辑超节点可能逼近 5MW。这个功率密度已经不是风冷能处理的液冷基本是必选方案。供电层面要关注的不只是总功率还有机柜级功率密度和冗余配置。很多传统机房的单机柜功率上限在 10kW 左右超节点可能要按单柜 30kW 甚至更高设计。承重、散热、母线容量都要提前做进规划。运维层面我特别强调一点管理网络和计算网络一定要做物理隔离。很多千卡集群的故障追到最后都是管理网段被训练流量打爆、设备失联。超节点因为规模更大这种问题会更严重。运维自动化也要提前做故障检测、自动告警、节点替换流程都不能依赖人工登机操作。在接触过不少大型训练集群之后我的体会是规划算力时至少要留出 20% 的资源作为通信冗余、故障缓冲和重试开销。不然理想算力算得再漂亮真实产出都会低一大截。4. 超节点路线和传统集群、主流方案有什么不同4.1 传统千卡集群的“三堵墙”传统集群在大模型训练中遇到的主要问题可以归纳为三点。第一是带宽墙。跨机通信带宽远低于卡间带宽多级网络收敛比设计不好梯度同步就成了瓶颈。第二是延迟墙。交换机转发延迟虽然只有微秒级但万卡规模下通信链路层层叠加累积延迟对同步频繁的训练任务伤害很大。第三是管理墙。几千台服务器各自独立运维故障率、配置一致性和任务调度复杂度都呈指数上升。这些问题很早就有只是模型规模小的时候不明显。模型从百亿涨到万亿之后传统集群的扩展效率一路下探。很多团队发现卡加到一定程度后再往上加训练提速非常有限连线性增长都做不到。4.2 行业里的超节点路线对比超节点不是哪一家的独创概念行业里已经有多种技术路线在做同一个方向。一种思路是“小规模、高密度”的紧凑超节点比如把几十张卡通过超高带宽背板或正交结构互连成一个机柜级计算域再用较小规模的高性能网络把这些机柜域串联。好处是工程难度相对低能较快落地。另一种思路是直接向上做大规模物理域追求在一个逻辑节点内集成更多卡这就要在互联芯片、封装、散热、软件栈上做更深的定制。华为这次走的是后者直接把通信域放大到 8192 卡。这需要解决的不只是网络带宽问题还有配套的集合通信库、运维系统和平台软件。技术量级完全不同。虽然不同路线各有适用场景但在超大规模万亿模型训练这件事上更大的超节点意味着更清晰的性能边界和更少的跨域通信开销。4.3 华为方案的一体化基因在哪里为什么华为做超节点有一种天然的适配性这要从它的技术栈说起。超节点表面上是计算问题但底层是网络问题。华为在数据中心网络、交换机、存储和运维体系上有很长的积累这些能力直接迁移到 AI 集群里就非常顺畅。比如在交换网络里做拥塞控制、在链路层做故障切换、在管理面上做设备监控这些经验在超节点设计里都是刚需。再加上自研加速卡、自研集合通信库、云平台调度系统华为做了一个垂直整合的方案。这种“什么都自己做的全栈模式”好处是各层之间配合紧密但压力也大每一层都要做到足够成熟才能在 8192 卡规模下稳定运行。对用户来说一体化方案的吸引处在于交付效率和故障责任边界清晰。出了问题不用在不同厂商之间踢皮球找一家就能解决。这在超大规模算力场景里价值相当明显。5. 8192卡超节点到底会改变什么5.1 直接受益的是万亿参数模型训练8192 卡超节点对模型训练的影响首先体现在“能力上限”上。过去很多团队不敢设计 1.8 万亿、5 万亿参数的大模型不是因为算法不支持而是算力集群支撑不住这样的并行规模和通信开销。现在超节点把通信天花板抬高模型设计的约束变小了。训练时长也会显著缩短。假设原来一万亿参数模型需要 24 小时一个迭代超节点配合高效集合通信迭代时间可以压缩到只剩原来的几分之一。更短的迭代时间意味着可以做更多的实验、更快验证想法。对在大模型一线调模型的人来说这就是实实在在的竞争力。5.2 云厂商和算力中心的算力供给模式会变超节点这种形态天然适合算力池化。原来按服务器租赁的模式用户拿到的是一堆物理机网络性能没有保障。现在按超节点切分算力平台可以给出更明确的性能承诺比如“这块逻辑域拥有 2048 卡卡间带宽某级别延迟某级别”用户能像挑云主机一样挑超节点切片。这会推动算力供给市场从卖“裸金属”转向卖“性能切片”。对中小团队来说原本租不起的整集群算力现在可以租一个子域性价比反而更高。5.3 开发者生态、赛事与学习路线都在变华为这些年围绕开发者群体投入了很多像各类数学建模大赛、ICT 大赛里AI 算力调度、并行训练优化等考题越来越多。超节点发布之后我预计会有更多赛事和课程围绕“如何高效利用超节点训练大模型”展开。对开发者个人来说以前学习和上手大模型训练重点在前向、反向、优化器这些算法层面。以后多了一项重要内容理解通信与算力之间的关系知道在不同规模的节点里怎么调整并行策略。这个能力以后会变成大模型工程师的基本功就像几年前熟练掌握 Linux 命令一样。5.4 下一代超节点往哪里走8192 卡不是终点后面还可能有支持更大规模、更高带宽互联的超节点版本。方向大致有三个一是继续扩大单一通信域的卡数量二是在互联技术上升级从传统电互联走向光互联或光电混合互联解决带宽和功耗的矛盾三是在软件层面更智能让通信调度、资源切分和故障自愈完全自动化。对产业来说下一步真正激动人心的地方不是又多了多少张卡而是“卡之间的墙”被推倒之后模型和应用的创新空间到底能开出什么花。我最后说一个自己实操中的体会评估任何新一代算力集群别只看卡数先问三个问题。第一通信拓扑是什么任意两张卡之间的最大跳数是多少第二集合通信在真实模型上的效率是多少而不是厂商宣传的理论值第三故障自愈和断点续训能不能在万卡级规模下无缝运行。这三个问题都通过了再谈算力有多强。因为在大模型训练的现场决定项目进度的往往不是算力峰值而是通信和稳定性的每一分细节。