当万亿参数的多模态大模型成为一种常态，AI行业的“军备竞赛”早已转向：不再只是卷模型参数、堆叠服务器，而是深入底层计算架构，开启了一场“系统级对决”。

“超节点”由此成为计算产业的“新宠”。

截止到目前，国内已经有十多家企业推出了“超节点”，动作上却出现了“变形”：似乎只要把几十台服务器塞进一个机柜，用光纤连接在一起，就能贴上“超节点”标签，对外宣称打破了摩尔定律。

在对比多款“超节点”的技术逻辑后，我们发现了一个残酷的技术真相：倘若无法实现“内存统一编址”，所谓的“超节点”多少有些“李鬼冒充李逵”的嫌疑，本质上还是传统服务器的堆叠架构。

01 为什么需要超节点？根源在于“通信墙”

让我们先回到原点：为什么在互联网时代用了二十多年的Scale Out集群架构，在大模型时代却行不通了？

中国信通院在几个月前发布的《超节点发展报告》中已经给出了答案，将原因形象地归纳为“三堵墙”：

第一个是通信墙，在大模型训练场景中，通信频次随模型层数和并行度呈指数级增长，微秒级的协议栈延迟在万亿次迭代中累积，将导致计算单元长时间处于等待状态，直接限制算力利用率。

第二个是功耗与散热墙，为了解决延迟和等待，工程师们不得不绞尽脑汁提升算力密度，尽可能在一个机柜里塞更多的计算单元，代价则是恐怖的散热压力和供电挑战。

第三个是复杂度墙，“大力出奇迹”的硬件堆砌，让集群规模从千卡推向万卡乃至十万卡，但运维复杂度同步提升。在大模型训练过程中，每隔几个小时就要处理一次故障。

摆在面前的现实挑战是，大模型正从单模态走向全模态融合，上下文长度达到了兆级、训练数据高达100TB、金融风控等场景的时延要求小于20毫秒……传统计算架构已经是肉眼可见的瓶颈。

想要满足新的算力需求，打破“通信墙”注定是绕不过的一环。除了堆叠服务器，是否还有其他路径呢？

先来梳理下产生“通信墙”的技术原理。

在传统集群架构中，遵循的是“存算分离”与“节点互联”原则，每一块GPU都是一座孤岛，拥有自己独立的领地（HBM显存），并且只听得懂“本地话”，需要访问隔壁服务器的数据时，必须走一套繁琐的“外交程序”：

步骤一是数据搬移，发送端将数据从HBM拷贝到系统内存；

步骤二是协议封装，将数据切片封装TCP/IP或RoCE报文头。

步骤三是网络传输，数据包经过交换机路由至目标节点。

步骤四是解包与重组，接收端进行协议栈解析并剥离报文头。

步骤五是数据写入，数据最终写入目标设备的内存地址。

这个过程的学术名词是“序列化-网络传输-反序列化”，存在几毫秒的延迟。在处理网页请求时，这种延迟不会影响到用户体验。但在大模型训练中，模型被切分成成千上万块，每一层神经网络的计算都需要在芯片间进行极高频次的同步。就像做一道数学题时，每写一个数字都要给隔壁同学打电话确认一下，解题效率可以说“惨不忍睹”。

业界针对性地提出了“超节点”的概念，并规定了三个硬性指标——大带宽、低时延、内存统一编址。

前两个概念不难理解，简单来说就是路修宽点（大带宽），车跑快点（低时延），最核心、最难实现的恰恰是“内存统一编址”：目标是构建一个全局唯一的虚拟地址空间，集群内所有芯片的内存资源被映射成一张巨大的地图，不管数据是在自己的显存里，还是在隔壁机柜的内存里，对于计算单元来说，只是一个地址的区别。

同样是做一道数学题时，不用给隔壁同学“打电话”，而是直接“伸手”拿数据。“序列化与反序列化”开销被消除了，“通信墙”不复存在，算力利用率也就有了提升空间。

02 内存统一编址难在哪？通信语义“代差”

既然“内存统一编址”被证实是正确路径，为什么市面上的某些“超节点”，依然停留在服务器堆叠？

不单单是工程能力的差距，还在于“通信语义”的代际差，涉及到通信协议、数据所有权和访问方式。

目前有两种主流的通信方式。

一种是面向分布式协作的消息语义，通常由发送和接收操作体现，工作方式像“寄快递”。

假设要传递一本书，得先把书打包封箱（构建数据包）、填写快递单写上对方的地址和电话（IP地址、端口）、叫快递员送到物流中心（交换机）、对方收到快递后拆箱拿出书（解包）、最后对方还得回复“收到了”（ACK确认）。

一套流程下来，即使快递跑得再快（大带宽），打包、拆包和中间流转的时间（延迟和CPU开销）也是省不掉的。

另一种是面向并行计算的内存语义，通常由加载和存储指令体现，工作方式像“从书架上拿书”。

同样是传递一本书，直接走到公共书架旁，伸手拿下来（Load指令），并在看完后放回去（Store指令）。没有打包，没有填单子，没有“中间商赚差价”，效率上的提升不言而喻。

诸如TCP/IP、InfiniBand、RoCE v2等支持消息语义，也是通信墙存在的直接诱因，但灵衢、NVLink等协议已经支持内存语义。既然如此，为什么“伪超节点”仍然做不到内存统一编址呢？

因为内存语义的皇冠明珠是“缓存一致性”：如果节点A修改了共享内存地址0x1000的数据，而节点B的L2缓存中存有该地址的副本，必须确保节点B的副本立即失效或更新。

想要实现“内存语义”，必须满足两个条件：

首先是通信协议和缓存一致性。

通信协议传输的不再是笨重的“数据包”，而是包含内存地址、操作码（读/写）和缓存状态位的“Flit”。同时还需要缓存一致性协议，通过总线广播一致性信号，确保所有计算单元看到的信息是相同的。

其次是充当“翻译官”的交换芯片。

交换芯片扮演了“翻译官”的角色，让CPU、NPU/GPU等设备在统一的协议下互联互通，整合为一个统一的全局地址空间，不管数据存在哪块内存里，都只有一个“全局地址”，CPU、NPU/GPU之间可以直接通过地址访问。

无法满足上述条件的“伪超节点”，大多采用的是PCIe+RoCE协议互联方案，属于典型的“大字吸睛、小字免责”。

RoCE跨服务器内存访问需要RDMA，不支持统一内存语义、缺乏硬件级的缓存一致性，依然需要网卡、队列、门铃机制来触发传输，本质上还是在“寄快递”，只是快递员跑得快了一点。而PCIe的理论带宽单lane为64GB/s，比超节点的带宽要求低了一个数量级。

结果就是，以“超节点”的名义宣传，却不支持内存统一编址，无法做到全局的内存池化以及AI处理器之间的内存语义访问。集群只能实现“板卡级”的内存共享（比如单机内8张卡互通），一旦跨出了服务器节点，所有访存都需要通过消息语义通信，在优化上存在明显瓶颈。

03 超节点有何价值？大模型的完美“搭子”

可能有不少人会问，费这么大劲搞“内存统一编址”，到底有什么用，仅仅是为了技术上的“洁癖”吗？

先说结论：内存统一编址绝非“屠龙之技”，在大模型训练和推理的实战中，已经被证实存在巨大收益。

第一个场景是模型训练。

在训练万亿参数的超大模型时，HBM容量往往是首要瓶颈。一张卡80GB显存，塞进模型参数和中间状态后，往往所剩无几。

当显存不够时，传统的做法是“Swap to CPU”——利用PCIe把数据搬到CPU的内存里暂存。但存在一个大问题：PCIe的带宽太低了，而且需要CPU参与拷贝。数据搬来搬去的时间，比GPU计算的时间还长，训练速度大幅下降。

在真正的超节点架构下，CPU的内存（DDR）和NPU的显存（HBM）都在同一个地址空间里，可以采用“以存代算”的策略精细管理内存：将暂时不用的数据或权重offload到CPU内存上，需要的时候通过“大带宽&低时延”的能力快速拉回片上内存激活，NPU的利用率可以提升10%以上。

第二个场景是模型推理。

在多轮对话中，每轮对话都需要Put和Get，Put将KV数据存入内存池，Get从内存池取KV数据，需要更大的KV Cache空间进行频繁的数据存储。

传统集群的KV Cache通常是绑定在单张卡的显存上的，如果用户问了一个超长的问题，节点A的显存被KV Cache撑爆了，附近的节点B即使显存空着，没有内存统一编址也无法借用，必须把任务重新调度、重新计算。

有了内存统一编址，就可以实现KV Cache的全局池化，并支持Prefix Cache复用（前缀缓存）。比如“System Prompt”通常是固定的，只需要在全局内存里存一份，所有节点都可以通过“一存多取”的方式直接读取。在PreFix Cache命中率100%时，集群的吞吐性能可以提升3倍。

第三个场景是推荐系统。

搜索、广告、推荐是互联网的“摇钱树”，依赖超大规模的Embedding表。由于Embedding表通常远超单机内存，必须分片存储在不同服务器上。

在推理过程中，模型需要频繁地从Host侧（CPU内存）或远端Device侧拉取特定的特征向量。如果是RoCE等“寄快递”的方式处理小包，光是打包拆包的开销就占了大头，导致严重的门铃效应，延迟居高不下。

而利用内存统一编址，配合硬件级的内存传输引擎，计算单元可以直接向远端内存发起读取指令，自动处理数据的搬运。当第一个向量还在路上时，第二个请求已经发出了，极大地降低了通信延迟，提升端到端的推荐效率，有望实现最小化开销。

不夸张地说，“大带宽、低时延、内存统一编址”三大能力相互协同，才能真正实现让集群像一台计算机一样工作，才能实现真正的超节点，才是大模型训练与推理的完美“搭子”，才是AGI时代算力基础设施进化的必然方向。缺少“内存统一编址”能力，终归只是在蹭“超节点”的流量。

04 写在最后

当我们拆开“超节点”的层层伪装，可以看到AI基础设施的竞争已经从单纯的堆砌硬件，上升到了体系结构的竞争。

“内存统一编址”这个听起来晦涩难懂的技术名词，某种程度上等同于通往下一代计算范式的入场券：作为“One NPU/GPU”的必备能力，打破了物理服务器的围墙，让成千上万颗芯片的“灵魂”融为一体。而那些仍然停留在“服务器暴力堆叠”的产品，终将被淹没在摩尔定律失效的洪流中。