超节点火了一年后，“算力不够就加机器”的扩张逻辑正在被改写

作者｜冬梅

编辑｜蔡芳芳

几十卡、数百卡、上千卡，AI 算力基础设施的规模竞赛，正在进入一个新的阶段。

过去，大模型厂商展示算力实力，最直观的方式是拥有多少张 GPU、建设了多大规模的计算集群。如今，随着超节点成为 AI 基础设施领域的热门方向，厂商展示实力的方式又多了一个：能够把多少颗 AI 芯片连接起来，让它们像一台计算机一样协同工作。

从英伟达的 GB200 NVL72，到华为的数百卡、千卡级超节点，再到各家国产厂商陆续推出的紧耦合计算系统，超节点的规模不断扩大。72 卡、384 卡、1024 卡，这些数字也越来越频繁地出现在产品发布和技术讨论中。

乍看之下，这似乎是过去算力竞赛的延续：以前比谁拥有的 GPU 更多，现在比谁能把更多 GPU 连接在一起。

但超节点真正试图解决的，恰恰是过去那种依靠增加机器数量扩充算力的方式所暴露的问题。

当模型规模越来越大，计算不再是唯一的瓶颈。芯片之间的数据交换、不同计算任务之间的同步，以及内存资源能否被高效使用，都开始影响最终的运行效率。增加更多芯片固然能够提高理论算力，但如果大量时间被消耗在数据搬运和等待上，硬件投入就未必能够转化为相应的性能收益。

超节点由此受到关注。它希望通过更高带宽、更低时延的互联，以及计算、内存和软件系统的协同设计，让更多芯片成为一个紧密协作的计算整体。

不过，一个值得追问的问题也随之出现：当超节点本来是为了提高计算效率而出现，为什么卡数又成为最受关注的竞争指标？连接的芯片越多，就一定意味着模型运行得越快吗？

从“堆机器”到“重构连接”， 超节点为什么突然火了？

超节点并不是简单地把过去的多卡服务器做得更大，它在试图改变计算资源的组织方式。

传统 AI 集群通常以多卡服务器为基本单元。以常见的八卡服务器为例，服务器内部通过 NVLink 等高速互联技术实现 GPU 之间的数据交换；当模型或训练任务需要更多资源时，再将多台服务器通过 InfiniBand 或以太网连接起来。

这种架构具有很强的扩展能力，也支撑了过去几年的大模型训练。但问题在于，服务器内部和服务器之间的通信并不处于同一个性能层级。

当模型能够在一台服务器内部完成主要计算时，数据可以依靠相对高速的内部互联进行交换。一旦模型规模超过单台服务器的承载范围，就需要把计算和数据分布到更多服务器上，频繁跨越节点边界。

对于需要大量同步和数据交换的任务而言，这些边界会直接影响效率。GPU 一方面负责执行计算，另一方面还要等待其他芯片完成计算、传回数据，才能继续下一步工作。

这就意味着，计算集群拥有多少理论算力，与模型实际能够获得多少有效算力，并不是一回事。

2024 年 3 月，英伟达在 GTC 发布 Blackwell 平台及 GB200 NVL72，为这道难题提供了一个醒目的新解法。

GB200 NVL72 将 72 颗 Blackwell GPU 连接进同一个 NVLink 域，把紧耦合计算的范围从传统多卡服务器进一步扩大到整个机柜。

它的出现，改变了增加资源的组织方式。过去，模型超出一台服务器的承载范围，就要更多地依赖服务器间网络；如今，更多 GPU 可以进入同一个高速互联域，在更紧密的连接范围内协作。超节点希望减少的，正是模型跨越这些边界时产生的通信和数据搬运开销。

对于大模型，这种变化有直接吸引力：更多芯片参与计算，也提供更多显存资源；更快的互联则为模型并行、专家间数据交换等操作创造了更好的条件。能否将这些条件转化为性能，仍要依靠模型切分、算子和调度优化，但系统设计已经有了新的空间。

后来公开的模型研发实践，进一步解释了这种需求。

2025 年 5 月，DeepSeek 团队发表架构论文，披露其使用的 H800 系统中，按论文的有效带宽口径，节点内 NVLink 通信约为 160GB/s，跨节点 InfiniBand 通信约为 40GB/s，相差约四倍。为控制混合专家模型的通信成本，团队限制了每个 Token 所访问的专家跨越多少个节点，并利用更快的节点内连接转发数据。

这项实践说明，芯片怎样连接，已经会反过来影响模型怎样设计。

超节点之所以受到关注，正是因为行业需要把更多资源用起来，同时减少资源之间的协作负担。

厂商很快沿着这一方向推出产品。

华为、浪潮信息、阿里云……几乎各大厂商都在布局超节点。2025 年 4 月，华为云发布 CloudMatrix 384，并宣布已在芜湖数据中心规模上线，将超节点推向数百卡规模。2026 年 7 月，华为公开展示 1024 卡配置的 Atlas 950 SuperPoD，提供 256TB 全局统一内存编址空间。浪潮信息近期也发布了元脑 SD200 Ultra，以 128 芯本土 AI 芯片构建紧耦合系统，提供 8TB 统一编址显存，并围绕通信和模型算子进行优化，单机承载运行 2.8 万亿参数的 Kimi K3 大模型，Token 生成时延首次突破 5.85 毫秒，相当于单用户速度 170 Tokens/s。

不同产品的芯片能力、互联机制和部署形态并不相同，但它们共同推动了一种变化：AI 基础设施的竞争，从采购多少芯片，进一步走向如何组织芯片。

只是，超节点火起来之后，卡数又成为最醒目的数字。几十卡、数百卡、上千卡，高速互联域的规模不断扩大，发布会上最容易传播的，依然是“能连多少卡”。

超节点真正的较量是什么？

超节点火起来，是因为更多芯片需要更高效地协作。但如果把“高效协作”简化成“连接更多芯片”，很容易又回到过去的规模竞争。因为，支撑大参数量模型究竟能“跑多快”才是超节点更值得较量的能力。

以 Kimi K3 为例，作为全球最大开源模型，K3 拥有 2.8 万亿总参数、104B 激活参数，官方推荐 64 卡甚至更大规模的 AI 服务器才能装得下。可“装得下”并不意味着“跑得快”。有业内人士表示，一般未经优化的超节点运行 Kimi K3，初始性能可能仅在 10 tokens/s 左右。

这也暴露出超节点规模扩张背后的另一个问题：芯片多了，性能是否真的同步增长？

72 卡、384 卡、1024 卡，数字越大，越容易成为发布会的主角。但对于用户，一个更大的计算域也确实意味着更多资源，可以容纳更大的模型、更多中间数据，并为并行计算提供空间。问题是，这些资源要付出多少代价才能被用起来？新增一倍芯片，能否换来相应的性能提升？

所以，超节点真正需要解决的，并不是“还能连接多少芯片”，而是如何让更多芯片高效协同，把堆叠起来的算力真正变成全球前沿模型的推理速度。

当被问及 Scale-up 域是否越大越好时，浪潮信息首席 AI 战略官刘军给出了一个直接的回答：“规模不重要。核心是你的衡量标准是你要跑什么样的模型？你为这样的模型所匹配的计算架构是不是能让这个模型发挥出效果。”

这句话需要放在他的技术路线和产品定位下理解，但它提出了一个关键判断：超节点的价值，最终要回到具体模型的实际性能。

一个模型需要多少芯片，并不能只看参数量。权重采用什么精度、上下文有多长、同时承接多少请求，都会影响内存需求；采用怎样的并行策略、计算过程中需要交换多少数据，又会影响互联需求。对于混合专家模型，还要看专家如何分布、每个 Token 需要跨越哪些芯片。

能把模型放进一个计算域，只是选型的起点。放进去之后能否达到目标时延、支持所需并发，才决定这套配置是否合适。为了让单个请求更快，可能需要更多芯片共同处理；为了承接更多请求，也可能更适合把资源分成多个实例。两种需求，并不一定指向同样大的计算域。

如果模型在较小的域内已经能够高效运行，继续扩大单域，未必比增加服务实例更划算。反过来，如果模型的容量和通信需求已经超出较小系统的承载范围，更大的紧耦合域就可能是必要选择。不存在一个脱离模型和业务、普遍适用的“最佳卡数”。

规模扩大，还会把协作本身变成更复杂的工程。

刘军在采访中指出，规模大了，通信成本及问题的放大效应也会上升。如果数据和计算相隔过远，通信、调度的开销可能超过新增计算资源带来的收益。

高速互联可以降低这些开销，却不会让它们消失。即便资源已经统一寻址，访问远端显存也不意味着与访问本地显存具有相同成本。数据经过多少跳、链路是否拥塞、计算能否与通信重叠，仍然影响实际性能。统一地址空间让资源更容易被访问，软件还需要决定怎样访问才高效。

超节点越大，对拓扑和软件的要求也越高。它需要证明的，不只是所有卡都能连接起来，还包括资源能否灵活分配。大任务需要整个域时，系统能否高效协同；小任务只需要一部分资源时，剩余资源能否服务其他业务？不同任务之间是否会相互干扰？如果只能用满配跑出好成绩，却难以经济地承接日常负载，规模优势就可能变成闲置成本。

因此，超节点是否好用，不能只看它能容纳多大的模型，更要看目标模型在其中能否达到预期的时延和吞吐。

可靠性是另一笔不能略过的账。

刘军特别提到，长程 Agent 任务可能持续数小时甚至数天，运行中断会带来更大的损失。但这并不意味着大超节点必然不可靠，也不意味着一次底层故障一定让任务从头开始。最终影响取决于故障能否被隔离、任务状态是否保存，以及服务能否重试、迁移和恢复。

对用户来说，更值得追问的是：一条链路或一颗芯片出问题，会影响多少资源？维护一部分设备时，其他业务能否继续运行？恢复需要多久，会丢失多少进度？这些问题决定了规模扩张的风险能否被控制，不能用一次短时间性能测试代替。

最后，规模还要落实到机房和预算上。更多芯片需要相应的供电、散热和互联设施，也带来软件适配与运维成本。采购价只是投入的一部分。如果为了获得有限的性能提升，需要大幅改造机房，或者增加长期维护负担，那么更大配置未必具有更好的回报。

“超节点，难在统一寻址”

超节点真正的吸引力，在于把原本分散的计算和存储资源组织成一个更紧密的协作整体。问题是，“像一台计算机一样工作”是一种目标描述，背后仍有大量架构差异。

刘军在采访中特别强调统一寻址。他认为，如果只是将模型拆成多个部分，分别放到不同服务器上运行，那仍然属于节点集群，浪潮信息所理解的超节点，需要首先解决显存统一寻址，让多颗加速器之间能够更直接地访问数据。

这是理解其技术路线的一个重要入口，但不能把它直接当成所有厂商共同遵循的定义。判断一套系统，仍需要拆开几个经常被混用的概念：资源是否具有统一的地址表达，远端访问能否由加速器直接发起，访问路径经过多少层交换，以及软件如何管理数据放置和同步。

统一寻址首先解决的是“能否找到、如何访问”的问题，并不自动意味着远端显存与本地显存具有相同的访问成本，也不自动保证所有资源都能高效共享。即便从软件看来，它们属于同一个地址空间，物理距离、拓扑和链路拥塞仍然存在。数据放在哪里、什么时候搬、能否与计算重叠，依然决定最终性能。

刘军用“串门”解释浪潮信息的对称内存方案：过去访问另一颗 GPU 的数据，像先去物业拿门条；现在则希望直接到邻居家。他强调，在统一寻址之后，还要进一步减少通信中的调度和中转开销。

这个比喻的价值，在于把超节点真正要解决的问题从“连接更多卡”拉回到“让这些卡更有效地协同”。如果扩大了资源池，却没有降低访问和同步成本，软件看到的空间可能更大，计算单元等待数据的时间也可能更长。

因此，“能放下模型”只是第一道门槛，“放下之后能否高效运行”才是更难的一道。

超节点如何选型：先看业务，再定规模

还有个问题值得关注，不同模型对系统的需求，并不随着参数量按同一种比例增长。

权重的存储需求与参数量、数据精度有关；推理时还要考虑上下文、并发请求及 KV Cache 等额外开销。对采用混合专家架构的模型而言，总参数量、每个 Token 实际激活的参数量，以及专家之间的通信，也分别约束着容量、计算和互联。仅凭“支持多少万亿参数”，很难推导真实的服务能力。

训练和推理的规模选择同样不能混为一谈。训练通常更关注一次训练任务的扩展效率；推理还要同时兼顾首 Token 时延、后续 Token 生成速度、并发和总吞吐。在一个大域内让单个请求更快，与将资源拆成多个服务实例来承接更多请求，可能是不同的优化方向。

在这次采访中，刘军把需求分为“能力型”和“容量型”。前者用于支撑前沿模型，追求复杂问题的处理能力；后者用于大量日常任务，追求充分、经济的智能供给。

在他的观察中，客户往往两者都需要：探索、规划和关键判断希望用更强的模型，经过验证的重复流程则希望更快、更便宜地执行。

企业需要一个能力上限，但未必需要每项任务都使用同样昂贵的资源。能够运行前沿模型的配置，应当验证复杂任务的质量和完成时间；承接日常服务的配置，则要验证在既定质量与时延下，能够持续处理多少请求。

因此，超节点选型应从业务往下推：先确定目标模型、精度、上下文、并发和时延要求，再结合并行与部署策略，确定需要多大的紧耦合域。测试也应使用接近真实业务的请求长度和到达节奏，观察高峰期间的尾部时延，而不能只看少量请求下的最快生成速度。

随后，再逐步增加资源，检查新增芯片究竟改善了什么。如果模型已经满足要求，扩大单域却没有明显提高有效吞吐，就应该重新考虑资源分区或增加服务实例；如果瓶颈来自容量和跨芯片通信，更大的域才可能具有明确价值。

超节点的合理规模，应当从业务测试中推导出来。厂商给出的最大配置，说明系统能够扩展到哪里，用户自己需要验证的，是自己的业务在哪个规模上，能够以合理成本获得稳定、合格的产出。

超节点兴起，是因为行业逐渐发现，买来的芯片再多，也需要解决它们如何协作的问题。如今，当超节点本身进入规模竞赛，行业需要警惕的是：曾经希望通过架构创新解决的效率问题，会不会再次被更大的数字遮住。

超节点走向成熟的标志，或许不是“能做多大”，而是“能跑多快”。

当行业能够清楚解释为什么需要增加一张卡，也能坦然说明为什么不必再加，算力建设才真正从规模竞赛走向了系统效率判断。

声明：本文为AI 前线整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。

今日荐文

你也「在看」吗？