目 录
前言································· 1
超节点技术基础···························· 2
超节点核心技术架构·························· 19
1 硬件架构设计 ······································ 19
i
2.1 物理层及 SerDes 技术 ······························ 64
软件栈与协同优化·························· 214
操作系统和超节点·························· 228
超节点技术选型与部署实践······················ 257
1 选型方法论 ······································ 257
ii
新华三超节点介绍·························· 299
全球标准/生态格局和进展 ······················ 309
1 专有生态 ······································· 309
iii
未来技术趋势与展望························· 333
附录-关键词 ···························· 338
iv
当前，大模型训练已从单机计算演进为超大规模集群的协同工程。随着模型参数量向万亿级迈进，万卡级集群 已成为头部算法厂商的标配。在这一演进过程中，底座架构的瓶颈正在从单卡的算力峰值（TFLOPS）转向 集群维度的通信效率（MFU-Model FLOPs Utilization）。当训练任务分布在数千甚至上万个加速节点上时， All-to-All、All-Reduce 等集合通信操作产生的流量呈几何倍数增长，如何降低长尾延迟、提升有效算力利 用率（MFU），成为大规模工程落地中首要解决的硬核课题。
传统的服务器架构在应对超大规模并发训练时，正面临严重的扩展性挑战。受限于标准机架的物理空间与功耗 限制，单机内部的互联带宽虽高，但跨机通信仍主要依赖于 RDMA 网络。在万卡规模下，多级交换机带来的 跳数增加（Hops）以及网络拥塞，会导致计算单元在等待参数、数据的同步时出现严重的“气泡”。传统“1 机 8 卡”的结构，机内 TB 级总线与机间 Gbps 网络存在量级带宽差，且协议转换引入微秒级延迟。这种内 存共享空间（HBM P2P）和互联带宽之间明显的物理断层，难以支撑千亿级以上参数模型对低延迟数据对撞 的苛刻要求，制约了集群算力扩展。
“超节点”架构的出现，本质上是对计算、网络与存储边界的一次系统性重构。它不再局限于传统的单机物理 框限制，而是通过高密度的背板互联或高速互联协议（如高性能 NVLink 扩展或自研互联架构），将多个计算 单元在逻辑上整合成一个超大规模的计算实例。超节点的技术核心在于将“Scale-up”域从单机扩展至机柜 级甚至更大规模，利用拓扑结构设计和统一的内存寻址能力，显著缩短通信路径。这种架构在保持高吞吐的同 时，有效缓解了大规模线性扩展时的性能损耗。
本白皮书旨在通过对超节点产品的系统性拆解，从硬件拓扑、互联协议、系统工程以及软件栈协同等维度，探 讨如何构建下一代 AI 算力底座。我们希望通过对技术细节的深入剖析，为构建高性能、高可靠的 AI 基础设施 提供切实可行的参考路径，支撑大模型走向超大规模生产化应用。
超节点技术基础
AI 算力需求爆发式增长驱动
国际数据公司（IDC）发布的《2025 年中国人工智能计算力发展评估报告》显示，中国智能算力将保持高速 增长态势：2025 年规模预计达到 1037.3 EFLOPS，同比增长 43%；2026 年将达到 1460.3 EFLOPS， 为 2024 年的两倍。2023-2028 年期间，智能算力五年复合增长率预计达到 46.2%，远超通用算力 18.8% 的增长率。这一差距反映出 AI 专用计算需求的独特性和紧迫性。
与此同时，推理算力占比将持续提升，预计到 2028 年达到 73%的市场份额。这一结构性变化表明，AI 应用 正从训练为主向训练推理并重转型，对计算基础设施的功耗、时延等指标提出了更高要求。Epoch 的《AI in 2030》预测更为激进：按照当前发展趋势，2030 年最大的人工智能模型将需要数千亿美元投资，其计算量 将是当今最大模型的 1000 倍，训练运行所需的电力将需要数十亿瓦特的电力，接近整个大型城市的平均需求。
从数十亿到万亿级，大模型参数规模的快速扩张已超出单卡甚至单服务器的承载能力。2024 年 12 月发布的 DeepSeek V3 参数量达到 671B，2025 年 7 月的 Kimi K2 突破万亿大关。以 GPT-4 的 1.8 万亿参数为例， 模型部署需要超过 10TB 显存占用，远超单卡显存 HBM 容量。这种规模的部署必须依赖多维混合并行策略， 如张量并行（TP）、流水线并行（PP）、专家并行（EP）、序列并行（SP）和数据并行（DP）的组合使用。 如此规模的并行化带来的巨大通信挑战，巨大的集合通信量对网络基础设施提出极端要求：既要大带宽（单批 次数百 GB），又要低时延（并行域内通信更为迫切）。
算力与网络联接必须协同发展、相互匹配，才能支撑新一代 AI 系统。英伟达在 GTC 2026 中提出了 7 芯片 极致协同的集群架构，正是这一思想的典型体现。这 7 类芯片包括：核心算力芯片 Rubin GPU、系统调度与 控制芯片 Vera CPU、芯片间 Scale UP 高速互联芯片 NVLink 6 Switch、芯片间 Scale OUT 高速互联网 卡芯片 ConnectX-9 SuperNIC、负责存储与基础设施卸载芯片 BlueField-4 DPU、大规模高速 Scale OUT
交换芯片 Spectrum-X CPO Switch、低时延推理专用 FFN 引擎 Groq 3 LPU。通过多芯片分工协作、深 度融合，可以释放出远超单一芯片的整体算力。
超节点正是这一理念的工程化实现：一方面，提供极致性能的 AI 算力；另一方面，构建大规模、高带宽、低 时延的 AI 芯片高速互联网络。通过让 AI 芯片算力与 AI 芯片互联能力最优匹配，形成“强算力 × 强互联”的 高效架构，从而稳定支撑超大参数模型的训练、PD 分离推理、AF 分离解码（Attention-FFN 分离）等。这 一架构最终指向智算中心的两大核心目标：
大模型后训练的人类反馈强化学习（RLHF）流程包括监督微调（SFT）、奖励模型训练（RM）和强化学习 训练（RL Training，强化学习算法通常选择近端策略优化 Proximal Policy Optimization，PPO）三个阶段， 每个阶段都需要维护百亿甚至万亿参数规模的大型模型。以 ChatGPT 和 Claude 等系统为例，RLHF 过程 需要同时运行策略模型、价值模型、奖励模型和参考模型，总参数量可达数万亿级别。
RLHF 需要在策略网络推理、奖励计算、优势估计和策略更新之间进行复杂的数据流转需要进行大量模型参 数传输和梯度同步。以 GPT-3 的训练配置为例，当使用 175B 参数的策略模型和 6.7B 参数的奖励模型时， 单次 PPO 迭代的模型间通信量可达 500GB 以上。传统服务器堆叠集群的网络带宽瓶颈往往导致整体训练效 率下降 60%（NSDI '23 论文《TOPOOPT》）。
大规模 RLHF 训练需要为每个提示生成数十个候选响应，可达数万个样本。这要求系统能够高效处理大规模 的序列生成和并行推理任务，同时奖励模型的评分结果需要及时反馈给策略优化过程。任何通信时延都会直接 影响训练的收敛速度和稳定性，对通信基础设施的时延特性提出极高要求。
传统 Scale-out 集群面临跨节点通信开销（网络延迟>1μs vs 单机<100ns）、分布式训练并行效率衰减 （Amdahl 定律约束）以及资源碎片化与能耗问题。大模型预训练的 Scaling Law 曲线持续攀升，SP/TP/ EP 总通信数据量相较中小模型提升近百倍，单批次达到数百 GB，但模型跨节点通信带宽增长速率仅为算力增长 速率的 1/5，造成通信墙，通信瓶颈愈发突出。
多模态模型正从静态生成向实时生成演进，部署形态从单卡单机走向多机并行，对并行带宽的需求达到百 GB/s 级别。此外，不同任务（生成/编辑/理解）对算力及访存的需求差异较大，驱动部署方式走向高算力与 高带宽 AI 芯片组合的异构部署。在自动驾驶和具身智能等场景，3DGS （3D Gaussian Splatting，三维高 斯泼溅）技术成为主流，其 Tokenization、以及其 3D 识别和 3D 生成应该对 GPU 并行提出了更高要求。
千万级高斯球重建场景下，单轮迭代需压缩至数十毫秒，同步百万级椭球梯度（位置/协方差/透明度等）需要 GPU 间通信达到百 GB/s。梯度数据分散在离散显存空间，需要支持数十个字节级别的细粒度通信，这对小 包低时延通信能力提出严峻挑战。
2026 年 1 月，北京智源人工智能研究院推出的多模态大模型“悟界·Emu”登上 Nature 正刊，成为继 DeepSeek 之后第二个达成此成就的国内大模型团队研究成果，也是中国首篇围绕多模态大模型路线的 Nature 论文。悟界·Emu3.5 进一步通过大规模长时序视频训练，学习时空与因果关系，展现出随模型与数 据规模增长而提升的物理世界建模能力，并观察到多模态能力随规模扩展而涌现的趋势，实现了“预测下一个 状态”的范式升级。多模态研究领域也将继续遵循规模扩展定律，对算力的需求将继续不断攀升。
如前所述，IDC 的报告中预测，推理算力的占比将在未来几年大幅增长，2028 年达到 73%。MoE 模型推理 场景下，以 DeepSeek V3 为例，每 Token 推理需要 58 轮 Dispatch 和 Combine 跨节点动态通信，最小 粒度仅为 KB 级，通信量随 Batch Size 线性增加，最大可达百 MB。推理服务需要在令牌生成时间（Time Per Output Token）TPOT 10ms 甚至更低情况下做大 Batch Size，对跨节点网络通信构成巨大挑战。阿里在 SPC 2026 的演讲中指出，超级节点方案在 LLM 推理的解码阶段带来显著的性能提升（30%）。
PD 分离是大模型推理中一种"分工协作"的优化策略。简单来说，就是把生成回复的两个阶段拆开：先让一部 分 GPU 负责"快速理解"（Prefill 阶段），另一部分 GPU 专门负责"逐字生成"（Decode 阶段）。这样做的好处 是，可以针对两个阶段的不同特点分别配置资源——前者需要强算力，后者需要大内存，从而在保证响应速度 和流畅度的前提下，大幅提升整体处理效率。目前，vLLM、Mooncake、Dynamo 等主流推理框架都已支 持这一方案，成为大规模部署大模型服务的高效选择。但是，在 Prefill 阶段和 Decode 阶段两个阶段之间需 要传输中间数据（KV Cache），需要有高速网络和优化传输，这点超节点相比服务器节点集群有更大的优势。
智能体的成熟使 AI 从对话进展到工作层面。长期记忆以键值缓存（KV Cache）形式实现，保存推理阶段的 上下文信息。
随着序列长度增长，KV Cache 呈线性扩张，需在多个步骤中复用扩展。智能体的出现对 GPU 的压力大增， 大量智能体所在机器以远高于人类的调用速度，大量调用 LLM，与传统的人机交互对 LLM Token 的生成速 度、成本提出了更高要求，对超节点系统与大模型的极致协同提出了更高要求。
多智能体系统（LLM-MA）将 LLMs 专业化为具有不同能力的智能体，通过互动模拟复杂现实世界环境。智 能体间的通信主要采用合作、辩论和竞争三种范式，通信内容通常以文本形式存在。多智能体系统间的通信。 比单智能体内部的通信复杂度更高，通信带宽和时延对系统性能产生重大影响，单一节点内的高速网络为 LLM-MA 提供更好选择。
云计算使得资源池化成为运营的关键。包括计算、存储、数据处理、高性能计算等都需要高效的资源池化方式。 当前的资源池化仍然存在一些挑战有待提升。
当前通用计算业务主要部署在虚拟机或容器，传统虚机 30%-50%内存未被使用，设备无法在节点间池化， 整体资源利用率低。虚拟机热迁移时间若达到 100-200ms 量级，客户将感知到业务中断。业务连续性要求 RPO 指标为 0，RTO 指标小于 50ms，以实现虚机热迁移场景业务无损。资源碎片化、内存资源利用率低 下、固定资源配置限制灵活性等问题，进一步加剧了资源浪费。传统云平台采用预留分配机制，导致接近半数 虚拟机内存未充分利用。
传统分布式存储存在硬件资源离散化、软硬协同能力薄弱等问题。每台服务器的 SSD 容量被独立分配，利用 率很低。以 CPU 为中心的架构设计存在根本性缺陷：EC 编解码、CRC 校验、数据跨节点搬移等关键任务 抢占主机 CPU 算力，使其成为系统性能瓶颈。分布式存储系统垃圾回收任务中，CPU 将数据从源盘读出并 重新写入目的盘，产生多次网络栈和 I/O 栈开销，导致有效 IOPS 下降很多。
数据处理的大数据平台和数据库也存在资源池化挑战。传统大数据平台面临资源配置失衡与浪费、数据交换效 率制约整体性能两大瓶颈。跨节点数据混洗（Shuffle）过程中的数据读写与交换效率成为系统性能的主要瓶 颈，导致 CPU 平均使用率低。为提升数据库线性度，达到峰值性能最优，数据库需要分层解耦的资源池化架 构，需要大规模和低时延 的内存共享。只有实现百 ns 量级的跨节点内存访问时延（低于当前 RDMA 的 1/10）， 才能匹配数据库架构发展趋势。
近十年 AI 技术快速发展催生 AI4S（AI for Science）新范式，带来高性能计算与智算融合。通信性能挑战、 超大规模集群网络拥塞和组网可靠性挑战、存储 I/O 多次内存拷贝问题，共同构成对高性能计算架构的新要求。
以世界模型为首的新兴 AI 模型对算力有更多的需求。世界模型与大语言模型 LLM、多模态模型存在范式层面 的根本差异，本质上是从"理解和生成"向"模拟和交互"的跨越。大语言模型的核心任务是在离散符号空间中进 行统计建模，通过给定历史文本来预测下一个 token 的概率分布，本质上是一个语言生成器。世界模型则要 求构建一个能够生成或预测环境完整状态的概率模型，包括观测（完整的视觉/听觉等多感官数据）、奖励（行 为产生的价值反馈）以及隐藏状态（环境的潜在表征）。这种转变使得世界模型从单一的语言生成工具升级为 完整的环境仿真器。
世界模型必须满足因果连贯性硬指标，即任何动作产生的后果必须符合物理逻辑。当前的大语言模型和多模态 模型主要学习数据中的统计相关性，能够生成看似合理但可能违背物理规律的内容，而世界模型则需要理解牛 顿力学的基本规律、掌握因果关系的时间依赖性并建立连贯的物理世界模型。这种因果推理能力要求模型具备 更深层次的抽象和推理能力，而不仅仅是模式匹配。同时，世界模型要求环境具有三维层面的持久性。多模态 模型主要处理 2D 图像序列，缺乏对三维空间的持久性理解，而世界模型需要建立内在的 3D 表征，能够从不 同角度识别同一物体、在被遮挡后恢复其完整状态。3D 几何处理的计算密集性是世界模型算力需求的另一个 重要来源。世界模型则需要处理 3D 几何计算，包括 3D 高斯溅射的梯度计算、点云或体素网格的处理、光线 追踪和物理模拟等。这些 3D 操作的计算密集度远超 2D 操作，对计算架构的并行能力和内存带宽都提出了更 高要求。
在交互性方面，世界模型需要实时响应来自外部的动作指令，形成"动作→状态更新→新观测"的持续交互循环， 这与大语言模型和多模态模型主要进行的离线生成形成鲜明对比。这种交互性要求模型具备毫秒级的推理延迟、 支持在线学习和持续更新，并能够处理不确定性和随机性，对系统的实时性和动态适应性提出了更高要求。
世界模型的算力需求显著增长，主要源于状态空间规模的指数级扩张。大语言模型的输出空间相对有限，词表 大小通常在 5 万到 10 万之间，每次只需预测一个 token。而世界模型需要生成完整的高维状态表征，观测空 间可能是百万级的像素向量（如 512×512×3 的 RGB 图像），隐藏状态可能包含位置、速度、物理属性等数 百个连续变量，奖励信号虽然通常是标量但需要基于复杂状态计算。这种状态空间的扩张带来了计算复杂度的 指数级增长，使得世界模型在单次推理中的计算量远超传统模型。
时间推理的深度依赖是算力需求增长的另一个关键因素。大语言模型的推理主要依赖上下文窗口内的历史信息， 通常涉及几千到几万 token。世界模型则需要进行多步预测和长期推理，为了评估一个动作序列的效果，可 能需要模拟数十甚至数百步的环境演化，每步预测都涉及复杂的状态转移计算，同时需要维护长期记忆来跟踪 环境的持续演化。这种时间依赖性导致计算量随预测深度线性甚至指数增长，对算力的持续消耗提出了极高要 求。
多模态融合的复杂度也在世界模型中显著提升。当前多模态模型主要处理静态对齐（如图文配对），而世界模 型需要处理动态多模态融合，包括视觉、听觉、触觉等多种感官信息的实时整合、不同模态之间的时空对齐以 及多模态状态的一致性维护。这种实时动态融合要求模型具备更复杂的融合机制和更大的参数规模，进一步推 高了算力需求。
因果推理的计算开销同样不容忽视。大语言模型的注意力机制主要捕捉统计关联，而世界模型需要进行显式的 因果推理，包括构建因果图或结构化模型、进行反事实推理（例如"如果当时做了另一个选择会怎样"）以及维 护物理定律的约束满足。这类推理需要结构化的计算（如图神经网络、符号推理），其计算复杂度远超纯神经 网络的统计学习，对算力资源构成了巨大压力。
实时交互的延迟约束进一步加剧了算力挑战。大语言模型推理可以容忍数百毫秒甚至更长的延迟（用户打字本 身就慢），但世界模型需要满足实时交互约束，智能体决策通常需要 10ms 级的响应时间，在交互过程中需要 持续推理而不能离线批处理，同时支持在线学习和参数更新。实时约束要求更高效的并行计算和更低的通信开 销，这使得高带宽低延迟互联特性成为必需。
综合来看，LLM 只是让 AI 会说话，世界模型则是构建完整的世界，目前其研究虽然还处在早期，但其算力需 求可能是当前大语言模型的 10 到 100 倍，在极端场景下甚至可能达到 1000 倍以上。这种跨越式的算力需求 增长，对计算基础设施提出了革命性的要求。世界模型在输出空间、推理深度、状态维度、多模态融合、推理 类型和延迟要求等多个维度上都对传统架构构成了挑战，需要更强大的计算密度、更高效的互联技术、更灵活 的编程模型以及更精细的资源管理能力。
更大规模的超节点架构，凭借其高密度集成、高速互联、全局编址、资源池化等核心技术特征，能够有效破解 传统架构面临的通信墙和内存墙瓶颈。通过提供 1TB/s 以上的互联带宽、低于 500ns 的通信延迟、TB 级统 一内存空间以及细粒度的资源池化能力，超节点为大模型训练和推理提供了高效的计算平台。对于世界模型这 类对通信时延和带宽要求极高的应用，超节点的高带宽低延迟互联成为必需，而其多 OS 协同架构、统一编 程模型和高效的跨组件资源调度，则能够支撑世界模型所需的复杂计算任务。
超节点的出现不是偶然，而是 AI 计算需求持续增长和架构持续优化的必然结果。其演进路径清晰地体现了从 分散到集中、从松耦合到紧耦合的技术趋势。
第一阶段（2020-2022）：基础互联探索期
这一阶段以 PCIe 和 NVLink 早期版本为代表，实现基础的 GPU 互联能力，主要支持 8 卡机配置，集群规模 限制在 32 卡以内。这一时期的架构特征是：节点间通信依赖标准网络协议，互联带宽有限，主要满足小规模 模型的训练需求。虽然初步实现了多卡并行，但由于缺乏系统级的架构设计，通信效率低下，无法应对大规模 分布式训练的需求。
第二阶段（2023-2024）：专用协议崛起期
随着大模型参数规模从百亿级迈向万亿级，专用互联协议开始崛起。NVLink 4.0 等专用互联总线等技术成为 主流，集群规模扩展到 64-512 卡。这一阶段的特征是：引入专用于 GPU-GPU 通信的高带宽低延迟协议， 显著提升节点内和节点间的通信效率，开始支持中等规模的大模型训练。然而，这一阶段更大规模的集群仍然 以 Scale-out 为主，节点间的通信瓶颈尚未完全解决。
第三阶段（2025+）：开放生态与万卡级互联
进入 2025 年后，超节点架构进入百家争鸣阶段。NVLink 5.0、UB 2.0、SUE、OISA、ETH-X、ESUN 等多种互联技术并存，形成异构兼容与开放生态。这一阶段的标志性特征是：支持万卡级互联，实现真正的" 单节点化"管理，多 OS 协同成为可能。超节点不再只是硬件集成，而是形成了完整的系统级解决方案，包括 统一的编址空间、资源池化能力、以及跨 OS 的协同调度机制。
超节点架构通过破解传统架构局限，实现全局资源抽象，超节点内硬件逻辑一体化，OS 成为算力统一底座：
传统分布式计算主要依赖 Scale-out 横向扩展，通过增加节点数量来提升整体算力。这种方式的优势是灵活 性好、成本低，但缺点是通信开销大、编程复杂度高、资源利用率低。随着大模型对通信时延和带宽要求的不 断提高，Scale-out 的局限性愈发明显。
超节点代表了 Scale-up 纵向扩展的新范式。通过在单节点内集成更多的计算资源，并提供高速的互联机制， 超节点能够在保持单一系统逻辑的前提下提供大规模计算能力。这种转变不仅是硬件形态的变化，更是编程模 型和系统架构的根本性变革。
传统集群采用消息传递（MPI，Message Passing Interface）编程模型，开发者需要显式管理节点间的通 信和数据分发，开发复杂度高且容易出错。超节点采用统一内存地址空间的编程模型，开发者可以像访问本地 内存一样访问远程资源，Load/Store 语义极大简化了并行编程的复杂度。这种统一化的编程模型是超节点区 别于传统集群的关键特征，也是其能够提升开发效率的重要原因。
超节点与传统集群在多个维度上存在本质差异，这些差异决定了它们各自适用的场景和边界。
传统集群（Scale-out）：通过横向扩展增加节点数量，将任务分配到多个独立的物理服务器上。这种方式的 优势是理论上可以无限扩展，但缺点是随着节点数量增加，通信开销和协调成本呈指数级增长，扩展效率快速 衰减。
超节点（Scale-up）：通过纵向扩展在单节点内增加计算资源，在逻辑上保持单一系统。这种方式的优势是 通信开销小、资源调度高效，缺点是单节点的扩展上限受限于物理集成密度和散热能力。
传统集群：主要采用 InfiniBand 或 RoCE 等标准网络协议，单向带宽通常低于 400Gb/s，网络延迟在微秒 量级。这些协议设计用于通用网络通信，没有针对 GPU-GPU 通信进行特殊优化。
超节点：采用 NVLink/UB 等专用互联技术，已经商用的第 5 代 NVlink 双向带宽达到 1.8TB/s，延迟在亚微 秒量级。这些协议针对 GPU 通信特性进行了深度优化，在联接上支持高密度的高速连接和低时延交换，功能 上支持 Load/Store 语义，能够提供接近片内通信的效率。通过专用互联技术，提供了单一逻辑巨型 AI 计算 节点，比如在 NVIDIA Vera Rubin NVL72 超节点系统中，通过 NVLink Switch 将 72 颗 GPU 互联为单一
计算单元，实现 130 TB/s 的总带宽，极大提升了万亿参数模型的训练与推理效率。同时配合集合通信加速功 能 SHARP™技术，在网络层直接处理聚合运算，使 All-Reduce 等集合通信性能提升 4 倍，显著减少了 GPU 等待同步的时间。
传统集群：采用消息传递编程模型，不同节点间的数据交换需要显式的发送和接收操作。这种模型适合任务级 并行，但对于数据级并行和细粒度同步支持不足，编程复杂度高。
超节点：采用统一内存地址空间编程模型，所有计算资源共享同一个地址空间，支持 Load/Store 语义进行数 据访问。这种模型极大简化了并行编程，支持更细粒度的并行和更高效的资源共享。
| 维度 | Scale-up（超节点） | Scale-out（传统集群） |
|---|---|---|
| 扩展哲学 | 纵向扩展：单机柜内高密度集成 | 横向扩展：多机松耦合堆叠 |
| 互联技术 | NVLink 5.0（双向＞1800GB/s，亚μs延 迟） | InfiniBand NDR/RoCE v2（400Gb/s，1-10 μs延迟） |
| 编程模型 | 统一内存地址空间（UMA），Load/Store 内存语义 | 消息传递接口（MPI），显式网络通信 |
| 一致性机制 | 硬件级缓存一致性（可选） | 软件管理，弱一致性模型 |
| 资源粒度 | GPU/内存/NVMe细粒度池化（可切分至 1%级别） | 整机/整卡分配，资源碎片化严重 |
| 适用场景 | 万亿参数以上模型训练、实时推理、内存密 集型计算 | 中小规模模型（或大模型，但需要更多的GPU 管理和任务调度）、批处理任务、通用云计算 |
| 拓扑特征 | 收敛比1:1 | 大规模集群时收敛比通常小于1:1 |
并非所有场景都需要超节点，超节点的适用存在明确的"单点有效算力"阈值。当任务的通信占比超过一定比例 （通常为 20%-30%）时，超节点的高带宽低延迟互联才能带来明显的性能收益。如果任务的通信占比很低， 超节点的优势无法充分发挥，反而可能因为成本和复杂度增加而不经济。
超节点的硬件成本通常高于传统集群，但在长期运行成本上可能具有优势。需要进行 TCO （Total Cost of Ownership）综合评估：包括硬件采购成本、电力成本、运维成本、软件适配成本等多个维度。一般来说， 对于持续运行的大模型训练任务，超节点通过提升资源利用率和降低通信开销，可以在短期内收回额外的硬件 投资 ；对于间歇性或小规模任务，传统集群可能更具成本优势。
超节点和云计算并非替代关系，而是可以形成互补协同。超节点可以作为云服务商提供的高性能计算实例，为 特定用户提供极致性能；同时，云计算的弹性资源调度和按需付费模式，可以降低用户使用超节点的门槛。未 来的方向是形成"超节点即服务"（Super Pod as a Service）的新模式，让用户能够像使用虚拟机一样便捷地 使用超节点资源。
超节点是 AI 时代的新型基础设施，支持高密度算力芯片（CPU、GPU/NPU、DPU、内存、外存中的一种 或多种组件）通过 AI 优化高速互联的特定交换机进行互联，从而实现资源池化和平等协同，组建起来的逻辑 上的统一内存语义与一体化基础设施构成的机柜级紧耦合算力单元。 超节点凭借超高带宽互联、内存统一编 址等技术特征，以及大规模灵活组网、高可靠运行等系统优势，同时支撑大模型高效训练与低时延高并发推理 等场景，突破算力、内存、通信三大瓶颈。
包含了几个关键要素：
图1 超节点系统架构
超节点虽然逻辑上表现为单一节点，但在技术实现上相比传统的单机系统做了较多升级和扩展。
传统单机通常集成 1-8 块 GPU 卡，而超节点的计算板卡物理集成密度远超传统单机，单节点可集成数十块、 数百块 GPU/NPU 卡，甚至成千上万块。这种高密度集成对物理设计提出极高要求：包括供电能力、散热能 力、信号完整性、机械结构等多个方面。
高密度集成的优势在于缩短物理距离、降低互联延迟、提升通信带宽，但同时也带来了散热和供电的挑战，需 要采用液冷、高功率密度供电（>50kW/机柜）等先进技术。
传统单机采用单一操作系统进行统一管理，所有硬件资源由同一个 OS 内核调度。超节点则采用多 OS 协同 架构，不同的计算组件可运行独立的操作系统，通过管控平台进行协调和管理。
多 OS 协同的优势在于：更高的灵活性、更好的隔离性、更强的容错能力。不同组件可以选择最适合的操作 系统版本和配置，某个组件的故障不会导致整个系统崩溃。但也带来了跨 OS 资源调度和状态同步的新挑战， 需要设计专门的调度策略和安全隔离机制。
传统单机的内存空间是独立的，跨节点访问需要通过网络传输。超节点实现全局编址（Global Address Space），将所有计算组件的内存统一编址到同一个地址空间中，支持 Load/Store 语义直接访问远程内存。
这种机制的实现依赖于高速互联协议，部分场景还需要缓存一致性协议的支持。全局编址的优势在于简化编程 模型、提升访问效率、降低通信开销，通过预取等手段减少访存等待等，但也需要处理页错误、内存映射、缓 存一致性、访存顺序等复杂的技术问题。
传统单机的扩展受限于物理边界，扩展到更大规模需要增加独立的节点，导致系统逻辑复杂度增加。超节点实 现了从"设备内扩展"到"节点级扩展"的光滑过渡，可以在不改变编程模型的前提下，通过增加计算组件平滑扩 展算力。
这种扩展性依赖于模块化设计和灵活的拓扑结构，支持计算层、互联层、存储层的独立扩展和灵活组合。
超节点的核心技术特征可以从多个维度进行刻画，形成完整的技术特征矩阵。
超节点提供极高的计算密度，单节点算力可达千 PFLOPS 以上。高密计算不仅意味着更多的 GPU/NPU 数 量，更意味着这些计算资源能够高效协同，避免通信瓶颈制约性能发挥。
高密计算的关键技术包括：紧凑的板卡设计、高效的散热方案、高功率密度的供电系统、以及优化的拓扑结构。
高速互联是超节点的核心优势，互联带宽超过 1TB/s，延迟低于 500ns。如此高的带宽和如此低的延迟，使 得跨组件通信接近片内通信的效率，为大规模并行计算提供了坚实基础。
高速互联技术栈包括：NVLink 5.0（双向 1800GB/s）、CXL 3.0（内存语义扩展）等。这些技术共同构成了 超节点的互联基础设施。
全局编址提供 TB 级统一内存空间，将所有计算组件的内存统一到一个地址空间中，支持 Load/Store 语义直 接访问。全局编址的优势在于简化编程模型、提升访问效率、降低通信开销，是超节点区别于传统集群的关键 特征。
资源池化实现计算/存储/内存的解耦，将不同类型的资源统一管理，按需分配给任务。资源池化的关键在于细 粒度的资源管理、动态调度策略、以及跨组件的状态同步。
资源池化提升了资源利用率和系统弹性，但也带来了更复杂的资源调度和状态管理需求，需要专门的调度算法 和管理软件。
超节点作为新兴技术，其技术成熟度和生态建设情况对其推广应用至关重要。
超节点的各项技术特性需要与具体的应用场景需求相匹配。对于通信密集型的大模型训练推理任务，超节点的 优势最为明显；对于万亿规模的大模型训练和推理，需要大规模的并行技术，突破算力、内存、通信墙，也是 超节点的优势所在；对于计算较离散且通信需求较低的任务，超节点的优势可能无法充分发挥。因此，在应用 超节点技术时，需要仔细评估场景需求的匹配度，避免技术能力的浪费或不足。
超节点的长期发展依赖于开放互联标准的建立。目前市场上存在多种互联技术标准（NVLink、CXL、UB、 SUE 等），各有优势但也存在兼容性问题。建立统一的开放互联标准，促进不同厂商设备的互操作性，对于构 建健康的超节点生态至关重要。
开放互联标准的建立需要产业界的共同努力，包括技术标准组织、硬件厂商、软件开发商和用户等多个利益相 关方。
超节点的性能和能力可以通过多个维度的指标进行评估，形成完整的指标体系。
算力密度衡量单位空间或单位功耗提供的算力能力，是超节点性能的重要指标。
单位体积算力（PFLOPS/m³）：表示在单位体积内提供的算力，反映硬件集成的紧凑程度。高算力密度意味 着可以在有限的数据中心空间内部署更多的计算资源，这对于寸土寸金的数据中心尤为重要。超节点通过高密 度集成和优化的物理设计，可以显著提升单位体积算力。
单位功耗算力（PFLOPS/kW）：表示在单位功耗下提供的算力，反映能源利用效率。在碳中和和能源成本上 升的背景下，能效比成为评估计算基础设施的重要指标。超节点通过优化供电和散热系统，降低单位算力的功 耗，提升能效比。
互联带宽衡量不同计算组件之间的数据传输能力，是超节点性能的关键瓶颈。 单向/双向带宽（GB/s vs Gbps）：表示在单位时间内可以传输的数据量。带宽越高，数据传输越快，对通信 密集型任务的性能提升越明显。超节点的互联带宽通常超过 1TB/s，远超传统集群的 400Gb/s 水平。 带宽密度（GB/s/GPU）：表示平均每块 GPU/NPU 可用的带宽。带宽密度越高，每块卡的通信能力越强， 系统的并行扩展性越好。超节点通过优化拓扑结构和互联协议，提升每块卡的可用带宽。
延迟衡量数据传输的时间开销，对于实时性要求高的任务至关重要。 P2P 延迟（GPU 间）：表示两块 GPU 之间进行点对点通信的延迟。低延迟能够更快速地完成同步和协作， 对细粒度并行任务尤为重要。超节点的 P2P 延迟通常低于 500ns，远低于传统集群的微秒级延迟。 内存访问延迟（NUMA 距离）：表示访问远程内存的延迟，反映全局编址的效率。内存访问延迟越低，跨组件 内存访问的效率越高，对需要频繁共享内存的任务性能提升越明显。
扩展能力衡量系统能够支持的计算规模和扩展效率。 纵向扩展极限（单机卡数）：表示单节点能够集成的最大 GPU/NPU 卡数。纵向扩展极限越高，单节点的算力 越强，能够处理的任务规模越大。 横向扩展效率（多超节点互联）：表示多个超节点互联时性能扩展的效率。横向扩展效率越高，系统能够支持 的规模越大，能够处理的任务越复杂。超节点通过优化的互联协议和拓扑结构，实现高效的多节点互联。
能效比衡量能源利用效率，对运营成本和环境影响有重要影响。 PUE（电能利用效率）：数据中心总能耗与 IT 设备能耗的比值，PUE 越低，供电、散热等基础设施的能耗占 比越小，整体能效越高。超节点通过优化散热和供电系统，降低 PUE 值。 算力功耗比（每瓦性能）：单位功耗提供的算力，反映硬件的能效特性。算力功耗比越高，每度电能够完成的 计算量越大，运营成本越低。
生态兼容性衡量系统能够支持的软件生态和迁移成本。 软件栈支持：主流深度学习框架和科学计算库的支持程度。良好的软件栈支持意味着开发者可以使用熟悉的工 具和框架，降低学习和使用成本。 迁移成本评估：从传统集群迁移到超节点需要投入的成本，包括代码改写、软件适配、人员培训等。迁移成本 越低，超节点的推广越容易。
随着模型进入千亿至万亿参数、万卡级集群时代，传统分布式架构面临跨节点通信带宽不足、时延过高导致算 力利用率长期偏低，单卡显存无法承载超大模型等诸多问题，大模型预训练是高算力密集、高通信密集、高内 存密集等特点，对基础设施提出了挑战。
在万亿参数模型训练中，梯度同步和参数交换的数据量呈指数级增长，大模型训练依赖 All-Reduce、 All-to-All 等集体通信操作，千亿参数模型单次梯度同步会产生 TB 级数据量，传统基于 PCIe + 以太网的架 构，其带宽（通常<400Gbps）远低于计算单元的吞吐能力，导致 GPU 大量时间处于等待数据的空转状态， 有效算力利用率 MFU 往往难以突破 50%，尤其在 MoE 等稀疏模型训练中，负载动态变化加剧了通信不均 衡问题，进一步放大了带宽压力。
大模型训练对内存容量的需求呈指数级增长，而单卡显存容量如 H100 HBM3 仅 80GB，模型参数、优化器 状态和激活值所需的显存容量远超单卡甚至单机上限，单 GPU 算力不足、内存不足，大模型必须通过大规模 并行计算实现，增加了跨 GPU 的通信负载，同时跨卡访问显存需经过复杂的拷贝流程，速度极慢，数据搬运 延迟成为训练效率的核心瓶颈。在训练过程中，频繁的权重读取、梯度回传和激活值交换导致数据搬运时间远 超实际计算时间，导致 GPU 需要等待数据从显存或其他节点传输到位。
针对上述主要挑战，超节点通过硬件架构革新与软件协同优化，实现超大规模模型高效训练：
极致通信性能：超节点采用高速互联架构，通过 NVLink 或 HCCS 等私有互联技术，节点内聚合带宽达到 TB/s 级别，例如 NVIDIA NVL72 达 130TB/s，华为昇腾超节点达 PB/s 级聚合带宽；通信延迟从微秒级μs 降低至纳秒级 ns，实现了内存级的远程访问体验；在万亿参数 MoE 模型训练中，模型算力利用率（MFU） 从传统的 40%-50%提升至 60%-65%以上，同等规模模型训练时间缩短 30%-40%，加速了模型迭代速 度。
内存池化突破：超节点构建了以全局共享异构内存池为核心的内存访问体系，基于 NVLink/HCCS 等专用低 延迟高速互联总线，为节点内所有并行计算单元提供连续、统一编址的 PB 级全局虚拟地址空间，各计算单元 通过 Load/Store 原生指令实现全局内存透明访问，消除跨节点数据拷贝开销，实现跨 GPU 的远程内存直接 访问与统一调度。使得万亿甚至十万亿参数的稠密模型或稀疏 MoE 模型可以在更少的节点数上运行，减少了 模型切分带来的通信开销，优化了显存利用率，显存碎片率降低 90%，支持更大的 Batch Size，提升训练收 敛速度。
整体应用效果来看，超节点全面突破传统集群的技术瓶颈，将万亿参数模型训练周期从数月缩短至数周，通信 损耗从 30%-40%降至 10%以内，算力利用率从 60%-70%提升至 90%以上，模型微调效率提升 80%、 开发适配成本降低 90%；可高效支撑 LLM、MoE、多模态等各类超大规模模型的训练与迭代，同时为政务 决策、应急预测等行业专属超大规模模型，提供低延迟、高效、高可靠的核心算力支撑，成为超大规模模型训 练的优选算力底座。
高性能计算在科学模拟、气象预测、药物研发三大场景中，核心需求是大规模并行计算、海量数据实时处理、 高精度模拟迭代，随着人工智能发展，带来了 AI+HPC 超智融合的需求，对超节点也提出了更多挑战：
针对上述 HPC 与智算融合场景的核心挑战，超节点的应用效果如下：
通信性能数量级跃升，破解带宽时延瓶颈：超节点通过专用高速互联总线，超高速正交架构或全光互联提供 TB 级带宽，打破通信瓶颈，实现百纳秒级端到端时延、TB/s 级双向带宽，较传统超算集群的 Infiniband 集 群时延降低 90%、带宽提升 10-20 倍。
全局内存池化重构访存体系，破解数据访问瓶颈：超节点构建 PB 级统一编址全局异构内存池，通过硬件级地 址映射，实现跨设备内存的原生指令级透明访问，不规则随机访存延迟降低 80% 以上，降低数据搬运开销降 低，支撑 PB 级海量数据集的全内存级处理，减少频繁磁盘 IO 带来的性能损耗。
高密度异构算力集成，突破物理极限约束：超节点采用单机柜高密度异构算力集成设计，单柜可整合近百个 AI 芯片（GPU/NPU）与海量 CPU 核心，异构算力密度较传统风冷 HPC 集群提升 8-10 倍；通过算力池化， 实现 CPU 与 GPU/NPU 的无缝协同，提升异构算力协同效率。
异构算力灵活调度，破解精度适配难题：超节点通过统一的 Scale up 互联架构（如 UB-Mesh），将支持不 同精度的 CPU、GPU、NPU 等异构芯片池化。系统可以按需调度，让高精度任务跑在 FP64 强的芯片上， 低精度任务跑在 FP16/FP8 强的芯片上；让一套系统既能高效支持 AI 训练，又能精确完成科学模拟，避免了 为不同任务建设多套系统的浪费。
整体上，超节点通过专用高速互联、全局异构内存池化、高密度算力、异构算力智能调度的架构级革新，相比 传统超算通信性能、访存效率、算力密度的数量级跃升，同时兼顾 HPC 双精度高精度模拟与 AI 低精度训练 的双重需求，将成为智算融合时代超算基础设施的核心底座。
政务、金融、能源等关键行业的 AI 基础设施，这类行业往往涉及敏感数据与核心业务流程，不仅需满足大规 模 AI 训练、推理及数据处理的高算力需求，更需具备自主可控的核心特性，以保障核心业务的合规性和数据 安全性，防范核心技术受限风险与业务中断带来的重大损失，对软硬件自主化、安全防护能力及运行稳定性的 要求远高于普通场景。
自主可控是这些关键行业 AI 基础设施共同面临的根本性挑战。超节点技术的核心价值之一，就在于它提供了 一个完全自主、开源开放的技术体系。开放的超节点参考架构，目标是构建一个不受单一厂商制约的、开放的 智算生态，这使政务、金融、能源等行业能够基于国产技术，打造从芯片到系统、从硬件到软件的全栈自主可 控的 AI 基础设施。
政务领域，政务数据涉及公民隐私与国家机密，要求算力设施必须自主可控，高度重视数据安全风险，同时在 业务高峰期能够高效处理海量市民的并发请求，对推理系统的吞吐能力和响应时延要求高；超节点可基于鲲鹏、
昇腾、海光等国产芯片，结合国产操作系统、与自研高速互联协议，构建全栈自主可控的算力集群；超节点在 模型训练及微调中的性能表现比传统 AI 服务器产品提升 2.5-3.5 倍，可以作为政务智能化升级的强劲算力引 擎，总体看，超节点采用国产芯片和全栈技术，满足国家信息安全和自主可控的要求的同时确保了高并发下业 务系统的流畅运行，让市民享受到更快捷的服务。
金融领域作为国家经济命脉，面临核心交易系统自主化率达 80% 的刚性政策要求，同时叠加强监管合规与业 务连续性的极致约束，针对金融场景的核心痛点，超节点深度整合国产异构算力资源，依托自主研发的高速互
联技术与全局共享内存池，实现国产异构算力的无缝协同，解决国产芯片适配性差、算力碎片化问题；算力调 度与响应延迟方面，超节点构建无阻塞全对等高速互联架构，精准适配高频交易、实时风控的低延迟需求；通 过整机柜冗余设计与硬件级故障自愈机制，将 MTTR 从小时级缩短至分钟级，核心系统可用性达 99.999%， 满足金融核心业务连续性要求；通过芯片级软硬件协同优化，国产芯片算力利用率提升至 85% 以上，千亿参 数金融风控大模型训练效率提升 3 倍，实时交易反欺诈推理时延从 50ms 缩短至 5ms，欺诈识别率提升 40%
能源行业，传统基于通用服务器堆叠的算力集群，在面对新型电力系统、智能勘探、流程优化等复杂场景时， 遭遇性能、效率、安全与可靠性的多重瓶颈；在电网调度领域，超节点提供的超高带宽和极低时延的互联能力， 使得电网调度中心能以 15 毫秒内的极快速度完成全网状态感知，结合自主研发的电力智能调度引擎，实现电 网负荷实时分析、故障精准预判、调度方案快速生成的技术突破。国家电网相关研究院的测试显示，基于超节 点架构的 AI 服务器，在电网最优潮流计算任务上，性能可达传统服务器的 3-10 倍，有效支撑了“沙戈荒” 大基地等新能源外送场景下的动态稳定控制。
混合负载场景核心需求是实现训练与推理协同调度、异构芯片集群高效适配，兼顾算力利用率、任务响应速度 与资源集约化，支撑 AI 模型快速迭代与实时服务落地。当前混合负载场景普遍面临负载适配、异构协同、资 源复用等核心瓶颈，具体挑战如下：
针对上述核心挑战，超节点通过架构级革新实现全维度突破，核心应用效果如下： 针对训练与推理负载适配瓶颈，超节点搭建智能负载感知调度引擎，依托硬件级任务监测模块与实时数据采集 单元，实时捕捉训练、推理任务的算力消耗、带宽占用、时延需求等核心指标，结合业务 SLA 优先级算法， 动态区分任务优先级（推理任务优先保障低时延，训练任务采用弹性优先级），支持负载动态感知与资源自适 应调整，空闲时段推理并发量低、算力冗余时，自动将冗余算力调度至训练任务，提升训练效率、缩短训练周 期；高峰时段推理并发激增时，优先为推理任务分配足额算力与带宽资源，锁定推理时延稳定性，从技术层面 彻底避免负载间资源抢占与闲置浪费，实现混合负载的高效协同。
超节点优化异构算力协同协议，深度优化异构算力协同协议，先后出现 NVLink、UB、HSL、PCIe/CXL 等 主流异构芯片通信标准，实现 x86/ARM 架构 CPU、GPU、NPU 等多品类、多架构算力芯片的统一纳管与 无缝适配，解决传统异构集群协议不互通、适配门槛高、协同兼容性差的行业痛点。
训练与推理资源复用瓶颈，超节点构建全局共享内存池，实现训练中间数据、模型参数与推理所需资源的统一 存储、高效复用，无需重复传输与存储；构建 PB 级全局异构内存池，实现 CPU/GPU/NPU 等异构内存统 一编址与统筹调度，实现异构芯片间内存的原生指令级透明访问，内存利用率提升至 75%以上，破解训练内 存不足与推理内存闲置矛盾。依托内存池实现训练-推理数据实时同步，模型迭代效率提升 60%以上，推理 精度提升 30%
超节点核心技术架构
1 硬件架构设计
随着大模型参数规模迈入万亿级（Trillion-parameter），智算基础设施的架构设计逻辑，正发生自通用计算 时代以来最为深刻的系统性重构。计算单元的互联架构已完成核心范式转移，由传统以中央处理器（CPU， Central Processing Unit）为核心的互联模式，转变为以图形处理器（GPU，Graphics Processing Unit） 为核心的新型互联架构。
在该新型计算架构中，GPU 作为核心算力载体，其功能定位已超越传统服务器单一硬件组件的物理范畴。超 节点（Super Pod）组网方案是突破高性能计算领域内存墙与通信墙核心技术瓶颈的关键手段。该方案依托 超高带宽、超低延迟的纵向扩展（Scale-Up，南向组网） 互联技术，将数十至数百个 GPU 计算模组在逻辑 层面整合为统一的高性能计算单元，最终实现算力资源的深度池化与一体化调度。
本章将系统剖析超节点硬件技术架构：研究维度覆盖宏观整机柜级互联形态、超节点内部硬件架构设计；技术 层面将对比封闭的 NVLink 协议与开放式标准化互联协议的技术路径；同时重点分析超高功率密度场景下，超 节点在高速互联、供电系统、散热设计三大方向的基础设施工程化挑战与核心设计要求。
AI (Artificial Intelligence) 超节点是高性能计算与 AI 大模型基础设施的核心架构形态。在组网架构层面，超节 点互联架构与传统 CPU 集群组网存在本质差异：传统 CPU 集群以通用计算为核心设计目标，采用以太网或 InfiniBand（IB）网络为主的横向扩展（Scale-Out） 架构，聚焦通用算力的分布式聚合与多业务通用调度， 计算单元间依赖 CPU 调度、操作系统内核完成数据包级数据交换。而 AI 超节点以突破大模型算力瓶颈为核 心目标，其内部 GPU 集群采用纵向扩展（Scale-Up）南向互联架构，这也是超节点最核心的组网特征；超 节点通过基于内存语义（Memory Semantics）的极高带宽、极低时延内部互联协议，将数十甚至数百个 GPU 模组在逻辑上整合为一个统一系统集群 1’2。其内部业务带宽密度通常是传统通用计算以太网组网方案的 10 倍 以上，核心定位是专为解决大模型训练（Training）和推理（Inference）场景中内存墙与通信墙技术瓶颈而 构建的高密度算力集群。
超节点作为 AI 时代新的算力范式，在技术实现层面通常具备以下特征：
超节点从定义上，属于逻辑上的集群系统，业界超节点的具体形态也非完全一致，但其演进上呈现出两大主流 趋势。
整机柜超节点形态是当前高性能 AI 算力的主流载体，这类系统通过定制化的铜缆背板 (Cable Tray) 实现机柜 内的算力全互联。
作为面向万亿级参数模型训推场景的超节点产品，H3C UniPoD S80000 实现了更高性能、更高密度、更高 效率的三重进化。面对客户追求极致性能的需求，S80000 以网强算，全面释放算力矩阵动能，柜内卡间全 互联通信。密度方面，S80000 单柜支持部署 64 卡，采用液冷方式散热，整柜功率可支持到 120KW，同时 兼容下一代高性能 AI 加速模组设计。此外，三总线全盲插、全面的漏液检测等方面的设计，能极大简化运维 流程、提升能效产出。
H3C UniPoD S80000 系列通过 2 层无阻塞交换架构，支持 256 卡集群组网。未来，新华三还将基于超节 点整机柜形态推出 1024 卡超节点集群。
图2 新华三 256 卡整机柜超节点集群
整机柜超节点 Rack as a Computer 的设计，创造性地解决了单机 GPU 的内存容量与通信带宽瓶颈，是当 前追求极致性能最成熟的规模化路径。
图3 新华三 S80000 整机柜超节点
如图所示，整机柜超节点系统通常由计算节点（Compute Tray）、交换节点（Switch Tray）、互联铜缆 (Cable Tray) 组件、电源插框 (Powershelf) 供电系统和液冷管路 (Manifold) 组成。
正视图：通常采用对称式布局。计算节点围绕交换节点上下分布，以确保所有计算节点到交换节点的走线长度 保持较高一致性，保证对时延敏感的信号时序统一。顶部或底部配置高密度的 Powershelf 集中供电，支持 N+N 或 N+1 冗余及动态均流。
后视图：核心是盲插（Blind-mate）接口区域。中央为直流汇流排 (BusBar) 为柜内设备提供输入电源，两侧 分布高密 Cable Tray 模组及 Manifold 接口，支持计算/交换节点统一插拔维护。
交换节点
计算节点
图4 整机柜超节点组网示意图
业界如 NVIDIA 基于 BlackWell 和 Rubin 系列的 NVL72 系统架构、AMD 基于 MI4XX 系列的 Helios 整机 柜、阿里云基于 UALink 推出的 ALS 整机柜架构、昆仑芯天池架构、字节跳动大禹架构等都属于整机柜超节 点形态。
Scale up NetWork
SWITCH
图5 计算节点示意图
如图所示，为业界通用整机柜超节点的计算节点板，物理形态上通过 Cable Tray、正交背板或正交网板直连 方案实现与柜内交换节点互联，形成更大规模的整机柜高带宽域 (HBD, High Bandwidth Domain)。未来随着 Serdes 速率进一步突破 224GT/s，光互联也可能成为超节点集群扩展的形态选项。
整机多框超节点形态，通常由整机算力节点、交换机节点、互联传输介质（铜缆或光缆）构成。该架构在机框 内部实现算力资源的高密度集成部署，通过外部交换单元完成跨机框的远程组网；亦可采用机内交换汇聚后二 级扇出的拓扑方式，实现分级远程扩展，从而为大规模纵向扩展（Scale-Up）集群的建设，提供了高弹性的 物理部署方案。
图6 新华三 F80000 超节点
依托国产算力平台，H3C UniPoD F80000 采用创新的光互联技术拉远集群组网，突破整机内高速互联瓶颈， 实现了跨机箱/跨机柜的超节点集群互联，实现模型训练性能提升 35% 以上。基于灵活开放的产品理念，H3C UniPoD F80000 支持基于不同形态的 AI 整机服务器及 AI 加速模组灵活构建超节点产品，支持灵活按需部署。
Scale up NetWork
SWITCH SWITCH
图7 超节点机内示意图
如图所示为业界整机多框超节点常见的机内计算模块，整机系统内通过 Scale Up 交换芯片的高速信号全部扇 出，再通过外部交换机实现拉远组网，完成更大规模 Scale Up 集群构建。
华为基于 Ascend 910C 系列 CM384 正交架构、NVIDIA Rubin Ultra 正交背板架构等超节点，在整机系统 中机内通过交换汇聚后再扇出，也是整机多框超节点组网的另一种物理形态选择。
在具体的底层硬件互联层面，超节点的发展正面临着严峻的物理制约。随着 SerDes（串行器/解串器）传输 速率逐步向 224GT/s 的超高标准演进，传统的铜缆传输介质在信号完整性保障与整体功耗控制方面的挑战， 已经无限逼近其物理极限 。 在此背景下，为了突破算力传输的物理瓶颈，未来数据中心及超节点集群内的光 互联技术将完成从“可选项”向“必选项”的根本性转变 3。
图8 未来高速 Serdes 的演进以及传输介质的变革 4
除了互联介质的转变，超节点的物理形态演进同样深度受制于供电与散热这两项核心工程约束。传统的高密度 集中式算力单体，往往受困于这两大物理极限而难以实现规模的无限扩展。引入先进的光互联技术，不仅能够 在物理层面实现大规模组网的服务器拉远部署，更具战略意义的是，它能够有效地将高度集中的供电与散热工 程设计约束进行物理分离。这种硬件形态的解构与重组，为打破传统物理单体的空间限制提供了切实可行的路 径，是支撑未来构建更大规模、更高效率算力资源池化的核心技术手段。
图9 光互联组网解耦架构演进 5
超节点技术的持续演进过程，在很大程度上映射了通用计算集群的发展规律。在这一宏观演进周期中，通用服 务器的组网模式呈现出明显的“集中”与“分布”交替演进的特征。这种架构形态的更迭，其本质并非盲目的 技术堆叠，而是在不同的技术历史阶段下，系统设计在性能释放、建设成本、系统扩展性以及部署复杂度等多 维度指标之间所进行的综合权衡（Tradeoff）。因此，未来超节点技术的发展必然不是依赖于某一项单一技术 的孤立突破，而是需要依托多项技术的深度融合，从而实现算力集群向着体系化、可持续的方向进行迭代。
计算节点作为超节点系统的核心算力单元，其架构已从通用计算转向极致的并行加速与异构协同。CPU 的角 色正经历从控制者到协同者的转变。
在深度学习爆发初期，数据中心主要依赖标准的 PCIe 插卡 (Add-In Card, AIC) 来扩展 GPU 算力。然而，随 着模型训练从单纯的计算密集型任务转向通信密集型任务（如 All-Reduce 集合通信），金手指插卡形态暴露 出了难以克服的物理缺陷。
首先，AIC 的接入方式和 PCB 边缘连接器（Edge Connector）限制了高速接口的扩展。传统服务器中 GPU 依赖 PCIe P2P 特性的交互，也严重影响系统通信效率。其次，AIC 形态对散热器的体积限制使得单卡功率 很难突破 400W-500W 的物理极限，制约了算力密度的进一步提升。
图10 OAM 模组示意图
开放计算项目 (OCP) 推出的开放加速器基础设施 (OAI) 6不仅仅是定义了一个算力模组形态，而是构建了一个 完整的硬件生态层级，确保了不同供应商芯片的物理互操作性：
这种分层设计使得超节点集群能够独立升级 OAM 算力单元或 UBB 基板，而无需更换整个机架基础设施，极 大地降低了 TCO (Total Cost of Ownership) 成本。
图11 OAI 标准的演进
OAM 规范的演进史，本质上是对抗物理极限（功耗、信号完整性、散热）的工程实现。参考 OAI 规范演进 路线图，我们可以清晰地看到技术指标的指数级跃迁。
图12 UBB 互联拓扑示意图
随着算力需求的增长，OAI 1.5 作为中间版本，重点解决了高功耗下的供电与信号挑战。
展望未来，技术演进将触及现有材料科学的边界，推动物理架构的彻底重构。
表1 OAI 标准下的拓扑及硬件规格
| 特性 | OAI 1.0 | OAI 1.5 | OAI 2.0 | 未来演进 |
|---|---|---|---|---|
| 时间 | 2020 | 2022 | 2023 | 2026+ |
| OAM功耗 | 450W | 700W | 1000W | > 1000W (1800W+) |
| 互联速率 | 56G PAM4 | 112G PAM4 | 112G PAM4 | 224G PAM4 |
| 特性 | OAI 1.0 | OAI 1.5 | OAI 2.0 | 未来演进 |
|---|---|---|---|---|
| OAM尺寸 | 102mm * 165mm | 102mm * 165mm | 102mm * 170mm | 保持或更大 |
| 拓扑结构 | FC, HCM, FC+HCM | FC, HCM, FC+HCM | 新增Retimer, Switch | 无阻塞全交换 |
| 集群扩展 | 8 * QSFP-DD | 8 * QSFP-DD | 32 * QSFP-DD/OSFP | 机柜级Cable Tray或机柜间 光互联 |
| Host Link | PCIe 4.0 | PCIe 5.0 | PCIe 5.0 / 6.0 | PCIe 6.0 / 7.0 |
超节点中 CPU 与 GPU 的组合，需要从硬件互联总线形态以及具体 AI 业务形态的维度展开。 业界 GPU 与 CPU 互联总线中，主要有以下几种形态：
PCIe (Peripheral Component Interconnect Express) 接口：每个 GPU 模组作为从设备 (Device) 挂载在 CPU 或者以 CPU 为根节点 (Root Complex，RC)的 PCIe Switch 主机设备 (Host) 下，CPU 主要负责预 处理与任务调度。
NVLink-CC 私有接口协议：以NVIDIA Grace Hopper为代表的架构 10，打破了传统的PCIe接口连接方案， 通过 C2C（Chip-to-Chip）互联技术实现了 CPU 与 GPU 的统一内存寻址，该架构彻底消除了 Host 与 Device 之间的 PCIe 带宽吞吐瓶颈，支持高达 900 GB/s 的芯片间双向带宽，使得 GPU 可以直接访问海量 系统内存，为万亿参数模型的单机加载提供了可能。未来基于 NVLink Fusion 进一步实现与 X86 架构的 CPU 对接，共享通算侧业务生态。
此外，AMD 基于 Infinity Fabric 高速互联总线协议 11、海光基于 HSL (Hygon System Link) 高速互联总线 协议 12，实现自家的 GPU 和 X86/C86 处理器对接；华为基于统一总线 (Unified Bus，UB) 架构 13，提出异 构资源 CPU/GPU/内存等资源池化的概念。
从业务角度，伴随着 AI 智能体（Agent）应用兴起，其将进一步加快大模型基础设施架构的演进和发展。这 一过程中，推理过程不再是单纯的矩阵计算，还包含复杂的逻辑判断、工具调用、环境交互和检索增强生成 (Retrieval-Augmented Generation，RAG) ，进而导致推理负载中 CPU 密集型任务（如 Prompt 解析、 API 调度、向量数据库检索）比例显著上升，尤其是需要支持超大规模并发的 Agent 执行和独立操作（通常 Agent 代理在通算的 CPU 侧部署业务），这就要求多租户隔离以及以 GPU 为中心的集群与 CPU 通算集群间 实现更为弹性的交互，随之而来的是超节点中就近部署的 CPU 可用资源出现瓶颈。
未来的超节点设计可能需要更弹性的 CPU:GPU 配比，甚至出现专门的 Agent 处理节点，以处理复杂的推理 规划（Reasoning/Planning）任务。
人工智能迈向万亿参数大模型的时代，AI 计算单元作为超节点基础设施的核心，其选型标准早已超越了单纯 的理论算力比拼。当前，芯片的效能上限还受到物理制程、封装工艺、算力/IO 带宽/存储介质间 Tradeoff 等多重制约。
本章节旨在介绍算力芯片的一些选型指标的演进历程。首先从封装技术的演进切入，探讨后摩尔时代算力提升 的底层逻辑。随后展开 GPU 与领域专用架构 DSA (Domain Specific Architecture) NPU (Neural Processing Unit) 芯片在生态兼容性与能效上的架构博弈，进而尝试介绍混合精度如何通过算法与硬件的协 同实现算力倍增。最后聚焦打破内存墙的关键——HBM 技术的代际演进以及 HBF 新介质形态的业界探索。
回顾以 NVIDIA 及 AMD 为首的过往 GPU 发展历程，可清晰地看到一条由封装技术主导的演进轨迹。每一个 架构的飞跃，本质上都伴随着封装技术的突破。AI 计算单元的最终效能，正日益受限于芯片的算力密度、显 存频宽、接口规格及功耗 14。
图13 先进封装制程的演进 15
在此阶段之前，GPU 的内存通常以 GDDR (Graphics Double Data Rate) 等形式表贴焊接于印制电路板 PCB (Printed Circuit Board) 板卡，这种传统方式导致带宽吞吐性能严重受限于布线长度与信号完整性 。
2016 年，NVIDIA Pascal 架构 16的 Tesla P100 成为封装技术的转折点。作为首款采用 CoWoS （Chip-on-Wafer-on-Substrate）封装并合封 HBM2 的 GPU，成功将存储介质的带宽从 GDDR5 时期 的约 300 GB/s 跃升至约 720 GB/s 。这一变革标志着 GPU 正式由图形渲染核心转变为数据吞吐型 AI 加速 器。
随后的 2017 年，NVIDIA Volta (V100)17延续了 CoWoS 架构并引入 Tensor Core，封装技术的成熟使得 HBM 堆叠成为可能，进一步提升了高性能内存介质的吞吐性能 。
掩膜版（Photomask）又称光罩 (Reticle)，是微电子制造过程中的图形转移工具或母版，是图形设计和工艺 技术等知识产权信息的载体。在光刻过程中，掩膜版是设计图形的载体。通过光刻，将掩膜版上的设计图形转 移到光刻胶上，再经过刻蚀，将图形蚀刻到衬底上，从而实现图形到硅片的转移，功能类似于传统照相机的底 片。
图14 先进封装制成下的光罩原理示意图
台积电基于其先进制程工艺，将 1 个光罩定义为光刻机一次曝光的最大有效面积，约为 830∼858mm2（通 常指约 26mm×33mm 尺寸面积）。这是目前光刻机制造能力的极限，先进封装（如 CoWoS）常以该面积的 倍数（如 3.3 倍、5.5 倍、9 倍）来衡量其封装晶片的尺寸。
随着 AI 模型参数量呈指数级增长，对算力与显存的需求迫使晶片面积不断增大，直至逼近物理制造的极限—
—光罩设计极限。
2020 年 NVIDIA 发布 Ampere (A100) 18采用了台积电 7nm 制程，其晶片面积达 826mm2，已极限接近光 罩允许的最大曝光面积。为提升性能，A100 80GB 版本利用 CoWoS-S 技术整合了 6 颗 HBM2e，将 HBM 带宽推向 2TB/s，此时 CoWoS 中介层的尺寸已扩大至接近 2 倍光罩大小。
到了 2022 年，NVIDIA Hopper (H100)19采用了台积电 4N 制程，整合了惊人的 800 亿个晶体管，晶片面积 达 814mm2。H100 利用 CoWoS-S 新一代技术继续整合 6 颗 HBM3，尺寸达到光罩的 3.3 倍。这被视为单 晶片（Monolithic）设计的巅峰之作，预示着单晶片封装已经达到极限。
与 NVIDIA 坚持单晶片不同，AMD 在 MI200 系列上率先探索了 MCM（Multi-Chip Module）设计，将两颗 算力芯片进行合封，为后续的 Chiplet 路线积累了经验。
第三阶段：Chiplet 封装技术演进 (2023-至今) 这一阶段标志着 GPU 合封技术正式成为架构设计的核心驱动力，多晶片互联成为主流。
图15 AMD MI300 的 Chplet 封装示意图 20
AMD 在 MI300 系列 21上为了追求性能极致，采用了 3D Hybrid Bonding + 2.5D Silicon Interposer 的复杂 封装技术。
面对物理极限，NVIDIA 在 B20022上最终放弃了对单晶片的坚持，转向 Chiplet 架构。B200 由 2 颗全光罩尺 寸的计算晶片组成，二者通过高达 10 TB/s 的 NVLink-C2C 进行互联 。为了承载这两颗巨大的芯粒及 8 颗 HBM3e，传统 CoWoS-S 技术因光罩面积需大于 3.5 倍而面临良率瓶颈。因此，NVIDIA 转向了 CoWoS-L 技术，利用有机基板提供更大的光罩面积支撑，进而打破物理尺寸的束缚。
展望未来，GPU 封装技术将在材料、结构与光学整合三维度上发生革命性变化，随着先进制程的进一步演进 以及 chiplet 技术的持续成熟，GPU 的算力指标/HBM 规格/IO 带宽还将继续螺旋式提升。
图16 未来 GPU 封装技术演进与挑战
然而，随着封装密度的提升，功率密度也呈指数级上升，散热与供电也必将成为制约 GPU 性能的最大物理瓶 颈。未来的超节点基础设施架构，必须在封装极限（Reticle Limit）、高吞吐存储介质功率墙（Power Wall） 与 IO 带宽规格之间寻求最优解。因此，下一代计算单元的选型，必须充分考量系统级的散热设计与供电冗余， 以应对即将到来数千瓦甚至数千瓦级别芯片时代。
AI 计算单元是超节点的算力核心。选型不能仅关注理论峰值算力 (FLOPS) 也需要关注算力的生态产业发展。
此处主要指以 Google TPU、AWS 亚马逊 Trainium 及华为昇腾系列 ( Ascend ) 为代表的领域专用架 构。
图17 AI 芯片架构对比（GPGPU vs DSA NPU）
随着大模型参数量从千亿向万亿迈进，单纯依赖晶体管微缩带来的算力增长已无法匹配模型规模的指数级膨胀。 算力的提升路径已从暴力堆叠逻辑单元转向算法与硬件协同的数值精度优化。通过降低计算精度来换取吞吐量 的倍增，成为提升 AI 算力的关键路径。
尽管 FP32 (Single-precision floating-point) 依然是高精度科学计算的基准，但在 AI 大模型训练中，混 合精度（Mixed Precision）已成为主流。
相比于传统的 FP16 (Half-precision floating-point)，BF16 (Brain Floating Point 16) 通过截断尾数位 （Mantissa）保留了与 FP32 相同的 8-bit 指数位（Exponent）。这种设计确保了足够的动态范围 （Dynamic Range），有效避免了深度神经网络在梯度累加时的数值溢出或下溢问题。
随着 NVIDIA Hopper 架构引入 Transformer Engine，FP8（8-bit Floating Point，遵循 IEEE 754 或 OCP 标准）开始在训练环节发挥作用。
相比 BF16，FP8 在同等显存容量下支持更大的 Batch Size，实现了理论算力翻倍的效果。
传统的整数量化（INT4）在处理大模型（如 LLM 特征值）时会导致显著的精度崩溃，而标准的 FP4 由 于位宽极窄，其动态范围和精度极难平衡。
针对这些挑战，Blackwell 等新一代架构引入了微缩放技术（Micro-scaling）。其核心思想不再是对单个数值 进行量化，而是引入块浮点（Block Floating Point）概念，实现：
这种技术在数学上实现了伪高精度，即在保持模型精度几乎无损的前提下，将内存占用压缩至 FP16 的 1/4， 并将理论推理吞吐量提升至 FP8 的 2 倍 。这可能成为未来芯片架构设计中，考量其是否具备大模型原生推理 能力的关键指标。
AI 负载中，内存带宽往往比计算峰值更早成为瓶颈。在这种背景下，高带宽内存 HBM 标准的发展成为了行 业焦点。
随着技术的演进，HBM4 将成为 2026 年推出的下一代 AI GPU 的核心内存。AMD 和 NVIDIA 均已确认在 其新一代产品（如 NVIDIA 的 Rubin 和 AMD 的 Instinct MI400）中采用 HBM4 技术。NVIDIA 的 Rubin GPU 规划封装了 8 颗 HBM4，而高端的 Rubin Ultra 则会配备 16 颗 HBM4E，其搭载的 HBM4E 内存总容量可能 超越 512GB 。预计 Rubin Ultra 功耗将超 2200W，其中 HBM4 的功耗接近 600W（高性能内存功耗占比 接近 30%）。
表2 HBM 的技术演进 23
| 规格 | HBM2E | HBM3 | HBM3E | HBM4 | 演进 |
|---|---|---|---|---|---|
| 时间 | 2020 | 2022 | 2024 | 2026 | 2029 (预计) |
| 单引脚速率 (Gbps) | 3.2 | 6.4 | 8 | 8 | 8 |
| 接口位宽 (bit) | 1024 | 1024 | 1024 | 2048 | 4096 |
| 单Stack带宽 | 460 GB/s | 819 GB/s | 1 TB/s | 2 TB/s | 4 TB/s |
| Capacity/die | 16 Gb | 16 Gb | 24 Gb | 24 Gb | 40 Gb |
| #of die Stack | 4/8-Hi | 8/12-Hi | 8/12-Hi | 12/16-Hi | 16-Hi |
| 容量 | 8/16 GB | 16/24 GB | 24/36 GB | 36/48 GB | 80 GB |
| Power/HBM | 19 W | 25 W | 32 W | 43/75 W | 100 W |
JEDEC 关于 HBM 下一代技术演进还在讨论和定义中，未来 HBM 的规划不仅是速率和容量提升，更涉及到 底层架构的根本性变革 24：
当前，HBM 是解决介质带宽问题的绝对主力，但其物理扩展性、成本及功耗限制了其在超大规模模型推理场 景中的普及。正是在这一背景下，基于 NAND Flash 技术的高带宽闪存（High Bandwidth Flash, HBF）介 质也被业界厂商所提及 25。HBF 并非传统 SSD 的简单加速，而是一种全新的存储层级，它试图通过 3D 堆叠、 TSV（硅通孔）互联以及异构键合技术，将非易失性存储的密度优势与 DRAM 级别的接口带宽相结合。其旨 在填补 DRAM 与传统 SSD 之间巨大的性能鸿沟。
表3 三种存储介质的技术指标对比
| 技术指标 | HBM3E (当前主流) | HBF Gen 1 (HBF1) | NVMe SSD |
|---|---|---|---|
| 介质类型 | DRAM (易失性) | 3D NAND (非易失性) | 3D NAND (非易失 性) |
| 单堆栈/设备容量 | 24GB - 36GB | 512GB - 1TB | 3.2TB - 30TB+ |
| 读取带宽 | 1.2 TB/s | ~1.6 TB/s | ~14 - 28 GB/s |
| 介质响应延迟 | ~14 ns | ~10 - 20 µs | ~70 - 100 µs |
| 接口技术 | TSV / 1024-bit Wide I/O | TSV / CBA Logic Interface | PCIe / NVMe 协议 |
| 功耗特性 | 需持续刷新 (高静态功耗) | 零待机功耗 | 低 |
| 应用场景 | 训练热数据、模型激活值 | 推理 KV Cache、冷权重、 CheckPoint | 数据集存储、冷归档 |
HBF 之所以能被称为高带宽，并非仅仅因为其堆叠了更多层数，其核心在于对 NAND 架构的颠覆性重构。传 统的 NAND 设计受限于 IO 接口速度和内部并行度，而 HBF 引入了以下关键技术突破。
在传统 3D NAND 中，负责控制读写电压、逻辑寻址的外围电路，通常位于存储单元阵列周边。这种设计迫 使外围电路必须使用与存储单元相同的制造工艺，这通常是针对存储密度优化而非逻辑性能优化的传统制造工 艺，导致 I/O 接口速度受限。
并行子阵列架构 (Parallel Sub-Array Architecture)。 为了达到 TB/s 级的带宽，HBF 彻底改变了 NAND 的内部数据通路。
TSV 垂直互联与封装。 与 SSD 采用引线键合（Wire Bonding）不同，HBF 直接沿用了 HBM 的封装工艺。
表4 传统存储介质与 HBF 的内部原理对比
| 技术支柱 | 传统 NAND/SSD | HBF | 收益 |
|---|---|---|---|
| 外围电路 | CuA (Circuit Under Array) | CBA (Wafer-to-Wafer Bonding) | 解耦存储与逻辑工艺，提升 I/O 速度 |
| 内部架构 | 2-4 Planes / Die | Massive Parallel Sub-Arrays | 极大提升数据并发度，以空间换时间 |
| 互联方式 | Wire Bonding | TSV (Through-Silicon Via) | 缩短信号路径，降低功耗，提升频率 |
| 封装形式 | BGA | HBM-like Stack on Interposer | 极高密度集成，靠近 GPU 部署 |
在 Transformer 架构中，为了生成下一个 Token，模型需要计算当前输入与所有历史 Token Attention。 为了避免重复计算，历史 Token 的 Key 和 Value 矩阵会被缓存下来。
HBF 大容量大带宽的特性与 KV Cache 的访问模式相契合：
在 AI 超节点架构中，HBF 未来支持扮演关键的分级存储角色，特别是作为 KV Cache 的巨型容器，释放被 存储束缚的计算潜能。对于架构设计而言，未来的关注点也支持从如何封装更多 HBM 转变为如何优化 HBM 与 HBF 之间分级存储 ，HBF 有望成为继 HBM 之后，AI 硬件领域的又一次革命性突破 27。不过从新技术走 向产品的成熟应用，HBF 还需要解决 NAND 介质目前 10 万次写入寿命的问题。
后摩尔时代，AI 算力芯片的选型已彻底脱离了单点性能的线性比拼，转而进入系统工程的综合比拼。当前的 技术演进呈现出清晰的制约关系：
人工智能训练需求正推动高性能计算基础设施经历范式转移的这一进程中，除了核心的算力节点，互联带宽 （Interconnect Bandwidth）与网络拓扑（Network Topology）也已成为决定集群训练效率、可扩展性及 经济可行性的关键变量。当单一大模型训练任务需要跨越数百甚至千卡集群协同工作时， 智算中心网络架构 面临前所未有的“通信墙”挑战。
本章节旨在探讨支撑现代 AI 算力底座的几种互联拓扑——CLOS（多级交换架构）、Torus（环面直接互联） 与 DragonFly（高基数分层互联）。
评估一个互联架构是否适用，通常需考察以下几个关键指标，在 AI 组网中，网络拓扑也与其上层业务的开展 形式相关：
CLOS 网络 28，尤其是其折叠形式（Folded Clos）或胖树（Fat-Tree），是目前大多数商业 AI 集群的业界 主流选择（如 NVIDIA 的超节点集群解决方案、AMD 即将发布的基于 UALink 的组网解决方案、博通主导的 ESUN 的 Scale Up 组网解决方案）。
2-LAYER CLOS
Spine(L2)
Leaf(L1)
Server
图18 CLOS 架构组网拓扑示意图
采用单级或者多级交换机（Leaf，Spine）构建。在理想的无阻塞（Non-blocking）设计中，任意两台服务 器之间的带宽恒定，通信交互路径具有高度的多样性。考虑到链路端到端时延（包括芯片多级转发时延）的综 合影响，业界 AI 集群 Scale up 网络部署交换通常不超过两级。考虑到集群组网的流控机制的复杂性，支持 故障场景下更加高效的重传能力，超节点在协议层面更聚焦在单级交换的实现，技术上宣称更大规模组网条件 下支持二级交换。
不过 Scale up 域内的 GPU，在高带宽吞吐和低时延转发诉求的客观背景下，节点规模一般受限在千卡以内， 最大支持两层交换实现全互联，一层交换实现百卡以内规模全互联规模，支持超节点训推业务。
NVIDIA GB200 NVL576 采用机架级液冷设计：柜内 NVL36 实现 18 颗 Grace CPU 和 36 颗 Blackwell GPU 组网。该架构采用第五代 NVLink 互联技术，配合专用的 NVSwitch 交换芯片，支持 36 颗具有 1.8 TB/s 的双向互联带宽的 GPU 实现 NVIDIA NVLink 高带宽域，作为一个 GPU 大集群开展业务部署。
图19 GB200 NVL576 组网拓扑示意图
NVIDIA 基于 NVL36 构建 NVL576 超级集群，支持 HBD 域内扩展至 576 颗 GPU。在其超级集群架构中， 通过 NVSwitch 的高密度端口交换能力，系统利用 2 层 Clos 网络拓扑实现 BlackWell GPU 的全互联：
通过高效的两层 Clos 组网，构建了一个统一的高带宽 NVLink 域，确保集群内任意两个 GPU 之间均能以 1.8 TB/s 的高速互联，最大化释放 Blackwell 架构在超大规模模型训练中的效率。
Torus（环面）是一种直接互联拓扑 29，节点直接连接到其在 n 维空间中的相邻节点。
3D Torus Topology Z
Y
X
图20 3D Torus 架构组网拓扑示意图
每个节点有 2n 个相邻节点，其中 n 代表维度（例如 3D Torus 中 n=3，就有 6 个相邻节点，包括上下/前后/ 左右）。边缘节点通过环绕链路（Wrap-around links）连接到对侧，形成闭环。
Google 的张量处理器单元 (Tensor Processing Unit，TPU) 集群 ( v2/v3/v4 ) 采用了 2D/3D Torus 互联。 Google 通过编译器优化，将模型切片放置在相邻节点，利用 Torus 的邻节点高带宽特性，避开了全局通信 的短板，同时创新性利用 OCS 光交换机，实现业务故障快速恢复 30。
图21 TPU v4 板级接口示意图
图22 TPU v4 集群示意图
OCS 光电路交换。 作为 TPU v4 网络的核心，OCS 光交换机具备以下技术特点：
图23 Google 3D Torus 组网示意图
每个机架内的 64 个 TPU 在逻辑上被互联为一个 4×4×4 的立方体（Cube），这意味着机架内部主要 依靠铜缆（DAC/AEC）或背板 PCB 互联，形成一个紧密的计算节点。
图24 Google TPU v4 集群接口示意
得益于 OCS 的特性，TPU v4 集群可以动态改变拓扑结构（例如从 3D Torus 变为 Twisted Torus）， 以绕过故障节点或为特定模型训练优化数据流路径。
DragonFly 由 John Kim 等人于 2008 年提出 31，旨在利用高基数路由器打破延迟与成本的权衡，在 HPC 网 络中有大量应用（如 Cray Slingshot 互联）。
图25 DragonFly 架构组网拓扑示意图
卡间带宽收敛。
华为发布的 UB-Mesh（Unified Bus Mesh）架构 32，提出了分层局部化 nD-FullMesh (Hierarchically Localized nD-FullMesh) 概念，在大规模组网条件下，该拓扑理论上与 DragonFly 有着一定层度的同源性， 但在工程实现上基于 AI 业务调度进行了局部优化，其利用 AI 训练流量的局部性特征，在机柜内、机柜间构建 多维全互联网络。
UB-Mesh 利用自研 Switch 芯片的高端口密度，构建了一个扁平化网络实现高性能、大规模和高可靠组网， 其通过时空均衡技术充分利用最短和非最短路径、逐包/逐流动态路由等技术，减少网络拥塞，在处理 All-to-All 等复杂流量模式时，能获得较高有效带宽。在同等规模下，相比于 CLOS 拓扑，UB-Mesh 减少交换机层级 和光模块数量的同时，通过编排调度支持提供更低的端到端延迟。
图26 Huawei UB-Mesh 架构组网拓扑示意图
三种互联拓扑综合对比：
| 特性维度 | CLOS (Fat-Tree) | Torus (3D) | DragonFly |
|---|---|---|---|
| 互联类型 | 间接互联 (Switch Fabric) | 直接互联 (Direct) | 分层直接互联 (Hierarchical Direct) |
| 网络直径 | 低且恒定 (3-5跳) | 高 (𝑂(𝑁1/3)) | 极低 (最大3跳) |
| 对分带宽 | 极高 (Full Bisection) | 较低 (受限于维度切面) | 中等 (依赖自适应路由) |
| 扩展成本 | 高 (超线性增长) | 低 (线性增长) | 中低 (利用高基数芯片) |
| 光缆依赖度 | 较高 (尤其是二级跨 柜交换) | 极低 (相邻节点主要用铜缆) | 较低 (仅组间互联需要) |
| AI负载适应性 | 通用性强，MoE (All-to-All) 最佳 | TP/PP (局部通信) 最佳 | 平衡型 (需配合路由优化) |
CLOS 架构：作为 NVL72 等超节点的核心拓扑，其优势在于全对分频宽带来的无阻塞交换性能。尽管随着 规模扩大其交换芯片成本呈超线性增长，但在 Scale-Up 域内，它是处理 MoE 等 All-to-All 流量的最佳方案。
Torus 架构：以 Google TPU 为代表，其极致的近邻节点通信效率在 TP 与 PP 中表现优异。然而，由于其 网络转发跳数较长，在应对 MoE 这种需要全局大频宽交换的流量时，极易产生拥塞，需要特殊的业务预编排 规划实现性能最优。
DragonFly 架构：该架构利用高基数交换芯片实现极低跳数，主要应用于 HPC 场景。华为 UB-Mesh 引入 了 nD-FullMesh 概念，针对 AI 业务调度进行了局部优化，平衡了组网成本与 TP/PP 通信的局部性需求。
在以互联为中心的时代，交换芯片的基数与频宽直接定义了超节点的扩展边界。在这种架构中，数十甚至上百 个加速器通过高带宽、低延迟的内存语义互联网络紧密耦合。此过程反映了算力需求的爆发式增长与数据传输 瓶颈之间的博弈，整体呈现出 GPU 的互联协议从通用兼容向私有协议追求极致性能，再到开放生态的演进探 索。
图27 交换协议底层 SERDES 技术演进
在早期，GPU 仅作为外设存在，PCIe 是唯一的选择。但随着 AI 模型参数量激增，PCIe 固有 Serdes 速率 低以及对应交换芯片带宽吞吐受限，成为多卡并行训练的瓶颈。而且传统 PCIe 总线协议报文头部开销大，不 支持原子操作和缓存一致性，导致其在处理细粒度、高频次的 GPU 间同步时效率低下，也无法支持 GPU 之 间实现高效显存共享，数据必须在 CPU 和内存间反复搬运，造成算力资源的极大浪费。与此同时 CXL (Compute eXpress Link) 作为 PCIe 物理层上构建的缓存一致性系统协议，旨在解决数据中心内存扩展和性 能瓶颈问题的 GPU 生态尚未成熟。
不过 PCIe 作为 GPU 与 CPU 处理器的关联纽带，依然会持续影响 AI 的生态发展。未来，PCIe 技术正朝着 Gen 7.0(128 GT/s)演进，单端口最大吞吐双向带宽突破 512 GB/s，其在大模型训练的影响力还在持续。
为了打破 PCIe 的瓶颈，NVIDIA 利用以太协议底层生态成熟的互联技术，推出了 NVLink 私有协议，实现接 口 Serdes 速率和交换带宽的超越及持续引领。
2025 年 NVIDIA 成功推出基于 200 GT/s、吞吐带宽性能支持双向 1.8TB/s 的 GPU 产品 BlackWell 以及配 套 NvSwitch 5.0 交换芯片（支持 72 个端口，总吞吐性能达到 7.2TB/s），实现整机柜 72 张 BlackWell 模 组支持统一 HBM 内存共享，定义了业界 GPU 高性能互联的标杆。
面对 NVIDIA 的技术主导，业界巨头（AMD, Intel, Google 等）组建联盟，推出了 UALink (Ultra Accelerator Link) 及相关的开放标准。预计 2026 年 Q3，AMD 将推出业界首款基于 UALink 的超节点整机柜 Helios， 双宽 ORW（Open Rack Wide）标准机柜，实现 72 颗 AMD Instinct MI455X 互联。
Meta、博通等也基于开放计算项目(Open Compute Project，OCP)组织，组建了 ESUN（Ethernet Scale-Up Network）工作组，并基于以太为底层，推出了博通主导的 SUE-T（Scale-Up Ethernet Transport）协议。
国内，以中移动牵头的 OISA（Omni-directional Intelligent Sensing Express Architecture）、新华三牵 头的 GLink、华为牵头的 UB 以及在此基础上，中电标准化研究院联合产业上下游共识推出的 CLink 计算互 联总线协议及相关标准体系，为大规模智算集群提供高效、智能且开放的 GPU 卡间互联标准提供了新的选择。
表5 当前 Scale-Up 互联芯片指标对比
| 接口总线 | PCIe | NVLink / NVSwitch | SUE-T / TF1 |
|---|---|---|---|
| 典型交换芯片 | PF320L | NVSwitch 5 | Tomahawk F1 |
| 交换带宽（双向） | 5.12 TB/s | 7.2 TB/s | 12.8 TB/s |
| 最大端口数 | 80 Ports（X4） | 72 Ports | 512 Ports |
| 网络拓扑 | 机内/机柜级 | 72-BlackWell 机柜级 | 512-XPU 单跳全互联 (集群 级) |
| 可靠性机制 | ECC/奇偶校验、 DPC、热插拔 | 硬件级重传，端到端ECC | LLR (链路重传), CBFC (信 用流控) |
| 优势 | 开放生态，支持异构 处理器与内存直连、 高效低时延 | 生态成熟，极低延迟。业界率先 实现GPU通过200G Serdes互 联产品落地 | 开放生态，支持超大带宽和更 大规模扁平化集群组网 |
随着 GPU 间高速互联 Serdes 及吞吐带宽不断提升，同时单机柜功率也开始迈向 100kW 甚至 120kW 时代 （如 NVL72 单柜约 120kW，未来也将朝着更大功率密度演进），传统风冷散热已接近物理极限。基础设施的 工程化创新成为超节点能否稳定运行的决定性因素。
长期以来，基于铜线的电气互联是数据中心内部通信的核心。然而随着信号传输数据速率的不断攀升，这一传 统技术正面临着根本性的“功耗-性能墙”。当 SerDes 速率攀升至 224G PAM-4 甚至更高的 448G 时，铜 走线的物理损耗由于趋肤效应，呈指数级增加，信号衰减问题将变得异常严峻和难以逾越。
为了补偿这种严重的信号衰减，传统的可插拔光模块（或者相应 Retimer 驱动芯片等器件）必须集成数字信 号处理器（DSP）进行信号补偿。其虽然能够维持信号完整性，但也伴随着大量供电损耗。在未来的高速网 络交换中，I/O 功耗甚至可能超过处理器核心本身的功耗。这无疑形成了一个无法避开的话题：为提升带宽而 增加的功耗，反过来限制了系统的整体扩展能力，以及由此带来能效瓶颈。
研究人员运用 Roofline 模型分析，为这一瓶颈提供了有力的数据证明。模型揭示，当前主流的大语言模型工 作负载，如最新发布的 GPT5 和 Llama 模型，实际上是带宽受限而非计算受限。如图所示，光学互联将极大 提升通信带宽（相较于以 NVLink 为代表的现有技术），从而提升大语言模型整体性能天花板。
图28 算力密度与性能瓶颈的 RoofLine 模型 33
电气互联在物理定律面前已显现出其性能瓶颈。正是这一根本的物理极限，正推动着整个行业向一场革命性的 技术转变迈进——将光学器件以前所未有的紧密度集成到芯片封装之中，从而开启一个全新的光互联时代。
不过，现阶段电互联作为芯片可靠通信的载体，依然承载着超节点互联各种工程落地实现，未来随着光互联技 术的逐步成熟，电互联和光互联也必将在各自领域相辅相成，共同推进超节点高速互联技术进一步向前演进。
在高性能数据中心架构中，信号传输距离与能效，对互联技术路线之间的核心制约关系。
当传输距离拉长至跨多机柜或跨节点集群（数十米至数百米）时，高速 Serdes 下电信号无法克服急剧增 加的损耗。因此，跨柜的长距离高带宽互联只能通过光互联（传统光模块，未来通过共封装光拉远）得以 实现。光互联虽然在光电转换端存在一定的功耗损耗，但在长距离传输中展现出了无可替代的优势和带宽 扩展性。
图29 各种互联技术的传输距离以及能效对比示意图
在整机工程交付领域，跨芯片到跨主板的连接是核心应用场景。工程实现主要通过 PCB Layout、板内线 缆（Flyover Cable）或板间电缆来实现系统级的互联互通。
以当前主流的超节点互联架构为例，SerDes 信号正处于 112GT/s 的普及期，并向未来 224GT/s 的技术 关口迈进。在这个频率下，即便采用超低损耗的 PCB 板材，电信号的传输距离也被极度压缩。为了突破 传统背板的物理瓶颈，业界在电互联技术上也衍生出了多种创新的高阶板材背板或者无背板直连解决方案：
图30 Cable Tray 组网方案示意图 − 优势：机柜液冷和电源盲插设计更容易实现；机柜深度要求低，突破背板物理尺寸的限制。 − 劣势：长期维护成本高，线缆故障率随密度提升而上升；未来 Serdes 突破 400GT/s，演进上
难以实现可靠连接。
− 典型应用：NVIDIA NVL72 超节点。
图31 整机背板组网方案示意图
− 优势：相比 Cable Tray 成本降低；大幅减少外部线缆数量，释放空间；大幅度缩短传输路径， 传输损耗低，符合 AI 大模型对带宽和延迟的极致要求；可维护性好，支持连接器级别故障定位 以及节点板卡维护，Cable Tray 需要整体更换。
− 劣势：定制化设计 PCB 背板，量产难度大。节点的深度被压缩，协调空间成为难题，研发成本
高。
− 典型应用：NVIDIA Rubin Ultra NVL144。
图32 正交直连组网方案示意图 − 优势：彻底消除背板损耗，适用于追求极致性能场景。 − 劣势：系统复杂度高，机柜架构和节点单板基于不同方案需重新设计，硬件设计可复用性差，研
发成本高。
− 典型应用：中兴超节点。
以上三种超节点高速信号电互联，在业界都有工程实现案例，但是从未来演进以及通用解耦设计角度，正交直 连以及正交背板方案侧重点主要在于解决极大带宽和高速互联速率下的端到端电气信号可靠性上，在架构设计 的通用性上存在一定瓶颈。而 Cable Tray 的方案，虽然设计兼容性上更优，但未来随着 Serdes 速率以及高 速带宽密度的进一步提升，系统的可维护性以及可演进性还需要更多工程领域技术创新。
解决互联瓶颈的核心，是在物理空间上将光学器件与 GPU 拉近。距离越短，电气链路的损耗就越低，系统的 整体能效也就越高。从当前主流的可插拔模块，到近封装光学 (NPO)、共封装光学（CPO），再到革命性的 封装内光 I/O（OIO）34’35，未来将逐渐成为光学集成的技术演进路线。
核心价值与局限：标准化的接口和现场可维护。然而，随着速率提升，其功耗急剧增加，并且面板物理空 间限制了端口密度，成为带宽扩展设计的瓶颈。
图33 可插拔光模块互联示意图
NPO 作为光互联技术演进路径上的重要中间形态，将光引擎从传统的前面板移至主板上，通过 Socket 插座或直接贴装的方式，紧邻交换芯片或 xPU 等核心组件放置。
核心价值：NPO 在物理空间上将光学器件与主芯片拉近。通过缩短物理互联距离，实现低损耗的电气互 联条件下，通过光互联拉远。NPO 保持了光引擎与核心芯片的独立封装，不仅降低了制造工艺门槛和高 功耗带来的散热挑战，也规避了封装制造低良率的风险，是当前兼顾性能与工程可实现性的可行方案。
图34 NPO 互联示意图
核心价值：其主要目标是通过将光学引擎与芯片并排放置，极大地缩短电信号传输路径。这一变革直接规 避了可插拔光模块方案中为补偿长距离信号衰减而必需的高功耗 DSP，从而显著降低了功耗，提升高速 信号传输质量。
图35 CPO 互联示意图
核心价值：OIO 专为高密度、低延迟芯粒间互联而设计。其目标是实现与封装内电气互联（如 UCIe）相 当的带宽密度、能效和延迟，同时具备光信号长距离传输的独特优势。
图36 OIO 互联示意图
在下一代智算中心超节点集群的演进中，基于铜缆的电气互联与近芯片光互联（CPO/OIO）必将相辅相成、 互为补充。
随着 AI 大模型规模的爆炸式增长，集群的数据互联能力已成为决定整体性能的关键瓶颈。当系统网络向 224G 甚至 448G SerDes 演进时，传统电气互联受物理定律制约，严重的信号衰减以及补偿损耗所需的 DSP 引入 了难以逾越的 “功耗-性能墙”。因此，在物理空间上拉近光学器件与计算核心距离的共封装技术，成为了突 破大规模组网带宽密度和能效极限的必然选择。
然而，现阶段光互联的大规模工程化部署仍面临显著瓶颈：
• 热管理与封装制约：对热高度敏感的光子集成电路与极高功耗的 GPU 共封装会产生严重的热串扰，这使
得液冷成为未来超节点机柜强制性的物理基建要求。
• 制造成熟度限制：需要加速 2.5D 和 3D 异构集成工艺的成熟，特别是高精度的光纤对准、键合和封装技
术，目前成本高昂且良率有待提升。
• 生态与运维博弈：深度集成的光学元件增加了底层硬件故障排查与维护的复杂性，且存在开放生态标准与
定制化封闭系统之间的路线博弈。
未来的硬件架构将基于传输物理距离进行重塑：在芯片封装内部或极短距离的板级节点内，电气互联继续发挥 其低成本与亚纳秒级极低延迟的优势；而在跨节点、集群大规模组网中，光互联主导数据交换。两者深度协同， 共同支撑智算中心算力的持续演进。
AI 推动 GPU 服务器功耗快速上升，供电技术随之快速发展，业界以往的分布式供电架构已遭遇瓶颈，集中 式整机柜供电迎来技术发展热潮。
与此同时，随着单机柜功率越来越大，供电电压正在从传统的低压交流电向高压直流电演变。
突破束缚与瓶颈
在以 GPU 计算为主的高功耗数据中心，PowerShelf 方案通过集中化、模块化的设计，在能效、运维、功率 密度上体现了显著优势。
整机柜 PowerShelf 正在快速发展，新架构、新需求、新方案不断涌现
800V 解决方案的成熟度持续提升并日趋完善
当前通用解决方案依托 800V PowerShelf 转 54V 实现阶段性过渡，随着技术的进一步发展和演进，未来也 可能出现采用电源板 PDB ( Power Distribution Board ) 将 800V 直接引入计算节点的实现方案。
图41 800V 高压直流柜内供电方案演进
在分布式供电系统的 PDB 板上，配置了输入电压为 800V DC 的砖型 DC/DC 电源变换模块，该模块采用 16:1 的电压变换比设计;当前技术规划中，半砖封装的模块额定输出功率可达 6kW，全砖封装的模块额定输出功率 可达 10kW。
图42 分布式供电系统高压直流电的转换示意图
随着 AI 需求日益增长，GPU 作为 AI 时代的核心部件技术不断迭代，功耗不断增长，目前已达 1000W+；板 级供电引入中间总线 48V 供电架构，大幅降低母线传输损耗，是应对千瓦级功率的核心趋势。为应对功率密 度的增加以及 PCB 的空间限制，板级电源方案由板载分立方案演进为集成模块方案。
图43 GPU 供电方案技术对比示意图
开环分立方案是一种基于分立元件构建的电源控制方案，其核心特点是控制环路中不存在反馈机制。即系统根 据预设的输入信号直接控制电源的输出，而不根据实际输出结果进行调整。
分立方案 开环模块
对数据中心、GPU 加速卡等功率密度要求高、开发周期短、批量一致性要求高的场景，相较于分立方案，固 定变比开环砖模块是首选方案，其在多指标对比上更优：
表6 固定变比的两种供电方案对比
| 指标 | 固定变比模块 | 固定变比分立方案 |
|---|---|---|
| 功率密度 | 极高 | 高 |
| BOM成本 | 高 | 低 |
| 开发周期 | 短 | 长 |
| 效率 | 高 | 中高 |
| EMI | 优 | 中 |
| 可靠性 | 高 | 中 |
当前 4:1 开环模块是中间总线架构(1BA)中的主流方案;面对 GPU 等高性能计算硬件持续增长的功率需求，业 界正积极开发 8:1、10:1 乃至更高变比的电源转换方案，这些技术被认为是应对未来挑战的更优选择。
当前电源模块(Power Block)的性能提升正迎来关键突破--电流承载能力已从传统的 1A/mm^2 跃升至 2A/mm^2，同时封装体积持续微型化，功率密度也随之显著攀升。在性能持续跃升的 GPU 架构中，对高效、 紧凑的供电解决方案的需求日益迫切。新一代电源模块通过提升电流密度与缩小封装，恰好回应了这一需求： 它能够在更小的物理空间内，以更高效率输送稳定而强大的电力，直接助力 GPU 突破性能与能效瓶颈。随着
模块化、集成化设计成为趋势，此类高密度电源方案为 GPU 的芯片布局释放出更多空间，使得运算单元、内 存与其他关键组件得以更紧密排布，进一步优化整体系统架构。
图44 电源模组的技术演进
现阶段两相 Power Block 为主流应用，而主流厂商 MPS 新一代方案已将集成度提升至 4 相 (见下图)。这意 味着，在单个高度优化的封装内，可整合更多相的 MOSFET、驱动器和电感。其直接优势在于：
功率密度倍增：单位面积或体积内可承载的电流能力大幅提升。 封装极致缩小：显著节省 PCB 板面积，为 GPU 核心或显存留出更多布局空间。 性能与效率优化：集成设计减少了寄生参数，提升了开关频率与响应速度，同时降低了功率损耗。
图45 常见 Power Block 电源的方案演进
由于 GPU 电流不断上升，计算功率的散热会被 PDN (Power Delivery Network) 损耗限制，垂直供电无疑 是未来供电方案的趋势。如图，现阶段市场预研以模块背面垂直供电为主，未来随这 GPU 计算能力进一步加 强，供电电流会指数级上升，为进一步减小 PDN，可能会将 VR module 嵌入到 GPU 的基板中。
图46 垂直供电技术示意图
在过去十年间，数据中心计算经历了从通用计算向异构加速计算的深刻转变，GPU 芯片的广泛部署成为关键 驱动力。伴随这一进程，GPU 的热设计功耗持续攀升：从 2016 年英伟达 P100 的 300W，到 2020 年 A100 的 400W，再到 2022 年 H100 的 700W，芯片功率密度增速显著超越传统 CPU。
为应对这一趋势，传统框式 GPU 服务器普遍采用以空间置换散热的设计思路，典型物理高度为 4U 至 8U， 从而为散热系统留出关键设计裕度。在此空间内，风冷方案通过多重强化手段实现：
高性能风扇系统：采用 80mm 及以上规格的大尺寸风扇或多风扇阵列，以产生高静压与大风量，强制气流穿 越高风阻散热模组。
大型化散热模组：配备 2U 至 4U 高度的强化散热器，其核心由传统热管阵列演进为覆盖全芯片的均热板，并 进一步发展为 3D-VC 架构——通过三维堆叠的均热板与热管复合结构，将导热路径从二维平面扩展至三维 空间，显著降低芯片结到散热鳍片的热阻。
通过上述极致工程优化，传统风冷方案在特定阶段内艰难维系了对400W至750W级别单芯片的散热可行性。 然而，该方案亦伴随显著代价：高噪音水平、高风扇功耗占比，且因结构强度与振动要求导致服务器重量与成 本大幅上升。这实质上是一种趋近物理极限的“强制散热”模式，其可持续性已面临严峻挑战。
超节点整机柜架构通过资源池化、模块化与高密度集成，追求极致的能效与算力密度。该架构对散热系统提出 两类截然不同却同样严峻的挑战，共同标志着风冷方案的能力几乎已达上限。
部分超节点设计允许单个计算节点占据 4U 至 8U 高度，以容纳多达 8 颗高性能 GPU。即便在此相对充 裕的空间内，面对下一代 GPU 功率向 1500W 以上跃升(甚至如业界预测的 Rubin 架构 GPU 可能达到 2300W，甚至 Rubin Ultra 或高达 3600W 级别)，风冷方案亦陷入理论困境。
1500W 单芯片的风冷散热已经逼近物理极限，且叠加核心矛盾“级联散热效应”。在密闭节点内，多个 超高功率热源线性排列，下游散热器必然吸入已被上游加热的空气。即便采用最优的分区风道设计，气流 的温升累积仍无法消除。当单芯片功耗超过 1500W 且节点内级联排列 2 颗芯片时，即使该区域级联风量 达 200CFM，下游芯片进风温度可能较环境温度升高 13°C 以上。为确保芯片结温处于安全范围，所需 风量与静压将驱使风扇功耗呈指数增长，导致系统能效比急剧下降，从工程与经济性角度已几乎不具备可 行性。
超节点演进的另一路径是追求极致空间效率，将计算节点压缩至 1U 高度。在此极端约束下，即便应对当 前普遍超过 500W 的主流高性能 GPU，风冷方案也已完全丧失物理可行性。
1U 高度仅 44.45 毫米，扣除 PCB、结构件及必要间隙后，可用于散热器的垂直空间通常不足 30 毫米。 在此条件下：
综上所述，超节点架构的发展已从两个维度将风冷散热推至不可逾越的瓶颈： 在高功率多卡节点中，级联散热效应与风扇功耗的指数增长构成了其经济性与工程可行性的天花板。在 1U 超 高密度节点中，物理空间的绝对限制构成了其基础热传导定律上的天花板。
面对 GPU 功率向千瓦级乃至更高层级迈进的确切趋势，风冷方案在服务器散热领域，特别是超节点与高性能 计算场景中，已近乎完成其历史使命。散热技术的范式转移近乎势在必行，液冷技术凭借其更高的比热容与导 热系数，成为突破上述双重困境、支撑未来算力持续发展的唯一工程可行路径。
面对风冷方案在超节点架构中遭遇的物理极限，液冷技术凭借其介质固有的高热容与高导热特性，成为必然的 替代方案。其中，冷板式液冷，因其在性能、兼容性与可维护性之间的卓越平衡，已发展成为当前超节点整机 柜架构中绝对主流的散热解决方案。
卓越的单芯片解热能力：冷板配合优化的微通道或歧管流道设计、更高性能的导热材料如相变材料、液态金属 等，可稳定支持 1500W 以上的芯片功耗，对于采用多芯片/多 die 封装 (扩大芯片面积) 的 NVIDIA-Rubin 架 构 GPU，可支持 2300-3600W 级别的散热需求。
与超节点架构的高度兼容：冷板式液冷本质上是对服务器内部散热模块的替换，而非对计算节点或整机柜架构 的颠覆性重构。其冷却回路(CDU、管路、快接接头)能够完美适配超节点的模块化、高密度部署理念。
渐进式的全液冷演进路径：该方案天然支持从“混合冷却”(CPU/GPU 等核心高热器件液冷，其余部件风冷) 向“全液冷”(所有发热元件均由液冷覆盖)的演进。通过为内存、电压调节模块(Voltage Regulator Module， VRM)、光模块等次级热源设计集成式或辅助冷板，可逐步消除系统内所有风扇，最终实现机房级的极致 PUE。
冷板液冷方案的普及，离不开强劲的产业需求牵引与快速成熟的生态系统建设。以英伟达为代表的芯片与系统 厂商，通过其产品路线图与参考设计，为行业树立了清晰的液冷化标杆。
产品化引领：从 A100 的液冷选项，到 H100 及 GH200 Grace Hopper 超级芯片对液冷的强力推荐，再到 最新发布的 GB200 NVL72 平台及规划中的 GB300、Rubin 架构，英伟达已在其高端数据中心产品线中全 面拥抱冷板式液冷。这些系统级设计不仅验证了液冷的性能，更定义了冷板、连接器、流量分配单元等关键组 件的规格，推动了供应链的规模化和成本下降。
图47 NVIDIA 产品液冷技术演进示意图
标准化进程加速：开放计算项目、开放数据中心委员会(Open Data Center Committee，ODCC)等产业组 织正积极推动冷板液冷组件与接口的标准化工作，涵盖冷板尺寸与安装、盲插式快接接头、冷却液特性以及监 控管理协议等。标准化是降低部署复杂度、实现多厂商互操作性的关键，进一步巩固了冷板液冷的主流地位。
综上所述，在强大的技术优势、与现有架构的兼容性以及日益完善的产业生态共同作用下，冷板式液冷已成为 支撑当前及下一代超节点整机柜算力密度的基石性散热技术。
面对千瓦级 CPU/GPU 芯片及其非均匀热源带来的挑战，冷板式液冷技术的优化正尝试沿着一条从宏观流场 调控到微观材料集成的路径纵深发展。其演进方向可系统性地划分为五个关键方向，共同尝试推动散热能力迈 向新高度。
基于热源分布的针对性流道优化 此方向的核心在于打破均一化设计，使冷却液的分配与芯片的真实热负荷精确匹配。
基础材料创新 此方向的核心在于突破传统金属的导热极限，并优化界面传热效率。
• 冷板本体材料：研发重点集中于高导热复合材料，如掺金刚石铜、高定向热解石墨与金属的复合基板。这
些材料在特定方向上的导热系数远超纯铜，能更快地将芯片热量横向扩散。
• 热界面材料：TIM 是散热链路中的关键瓶颈。优化方向包括更高性能相变材料及液态金属的应用，目标是
在低安装压力下实现极低的热阻，并保证长期可靠性。 基板均热技术强化 当芯片尺寸增大或存在多热源时，仅靠基础材料传导不足以避免局部过热。此方向为引入均热元件。
• 嵌入式均温板：在冷板底座内部、紧贴芯片接触区域的下方，集成均温板。其内部的相变工质能实现近乎
等温的二维平面超快热扩散，将集中热源迅速摊平，为上层对流换热提供均匀的热负载。 微通道结构深化与系统化 这是提升对流换热系数的核心战场，焦点从“有无"转向“最优”。
微通道与芯片封装的集成 此为前沿探索方向，旨在消除所有中间热阻，将散热器作为芯片的一部分进行设计。
• 近芯片冷却/直接-on-chip 冷却：将精密的微通道冷板作为芯片封装的上盖或中介层，通过先进工艺与芯
片直接集成。冷却液在距晶体管仅毫米甚至微米级的通道内流动，实现最短传热路径和极限散热能力。
• 向 3D-IC 与异构集成的融合：在未来 3D 堆叠芯片中，微通道冷却层可能被设计为主动式夹层，嵌入在不
同芯片层之间，直接对堆叠内部产生的“体积热”进行提取。
总结而言，冷板技术的演进呈现清晰特征:从基于热源的智能流场设计，到材料的物理属性改良，再到基板内 部的相变均热强化，进而到流道结构的系统化设计，以及尝试迈向与芯片封装一体化的深度融合。目前这些优 化方向部分还处于研究和探索阶段，必须解决新材料物理属性不稳定、一体式均热板冷板工艺不稳定、微通道 导致的高流阻和易堵塞等问题，才能让这些技术真正落地量产。
尽管冷板式液冷占据主导，但其他液冷技术路径也在持续发展中，各自具有独特的潜力与当前面临的技术或工 程挑战。
图48 各种液冷技术对比示意图
本章节主要是围绕超节点核心的硬件技术架构展开：
随着半导体先进制程的演进红利逐渐放缓，单芯片算力的线性增长已逐渐触及物理极限（算力墙），且算力的 持续演进，也不可避免地伴随着数据吞吐的严重滞后（内存墙）以及极端物理条件下的能效危机（功耗墙与散 热墙）。
面对错综复杂的瓶颈，算力增长的未来不再是 GPU 芯片的单点暴力堆叠，超节点技术未来发展必然走向软硬 件一体的深度优化，并通过基于高速互联的异构算力的全局协同，实现性能与能效的进一步突破。
| 阶 段<br><br> | 时代 | 核心技术 | 单 GPU 单链 路带宽<br><br> | 单节点/单机 柜 GPU 数量<br><br> | 最大集群/ 超节点规模<br><br> | 集群/超节点 总互联带宽<br><br> | 核心互联方案 |
|---|---|---|---|---|---|---|---|
| 1 | Pascal/Volta | NVLink<br><br>1.0/NVLink<br>2.0，第一代 GPU直连技 术，摆脱PCIe 转发瓶颈<br> | NVLink 1.0： 80GB/s；<br>NVLink 2.0： 300GB/s<br> | 8 | 8（单机柜上 限） | 约2.4TB/s（8 卡全互联峰 值） | 节点内NVLink， 节点间仅支持普 通以太网/IB |
| 2 | Ampere (A100) | NVSwitch 2.0芯片， GPU专用交 换架构，实现 节点内无阻塞 全互联 | NVLink 3.0： 600GB/s | 16 | 128（第一 代Super Pod集群） | 约9.6TB/s （16卡节点峰 值） | 节点内NVLink 3.0，节点间 InfiniBand HDR/NDR |
| 3 | Hopper (H100/GH20 0) | NVSwitch 3.0， NVLink-Net 机柜级组网， 打破单机箱物 理边界 | NVLink 4.0： 900GB/s | 32（单节点） | 256（单机 柜统一超节 点） | 约28.8TB/s （单机柜256 卡峰值） | NVLink 4.0全柜 直连，小范围替代 IB，形成单一 NVLink域 |
| 4 | Blackwell (GB200) | NVLink 5.0 + NVLink-C2 C芯粒互联， Grace+Blac kwell超级芯 片，全局统一 内存 | NVLink 5.0： 1.8TB/s； C2C芯粒互 联：1.8TB/s | 72 / 单机柜 | 576（多柜 组合Super Pod） | 130TB/s（单 机柜72卡超 节点总带宽） | 全局NVLink 5.0 全柜无阻塞互联， 跨柜InfiniBand Quantum-2 |
| 5 | Rubin（Vera Rubin，下一 代） | NVLink 6.0 + NVSwitch 6.0，HBM4 高带宽内存， Vera CPU+Rubin GPU芯粒， Kyber机架架 构， ConnectX9 SuperNIC | NVLink 6.0： 3.6TB/s； C2C互联带 宽同步升级 | NVL72：72 / 单机柜； NVL144： 144 / 单机柜 | NVL72： 576； NVL144： 1152（翻倍 扩容超节 点） | 260TB/s （NVL72单 机柜）； 520TB/s （NVL144单 机柜） | 全局NVLink 6.0， 单链路带宽翻倍， 跨柜 Quantum-X80 0 IB/Spectrum-6， 全光低延迟互联 |
Scale UP 总线大部分采用物理层、链路层、事务层三层架构，部分协议（如 UB）在此基础上增加了网络层 和传输层，并可以基于网络环境灵活启用关闭。总线的分层设计是应对设备互联需求升级与技术复杂度的必然 选择。早期 ISA、EISA 等总线采用单一架构，信号传输、数据校验、逻辑交互功能混编，难以适配从 MB/s 到 GB/s 级的带宽跃升，在可靠性与兼容性上瓶颈凸显，可参见本书 PCIe 章节。
为破解困境，分层设计应运而生：物理层定义信号规范、传输介质等底层基础，解决数据如何传的问题；链路 层通过 CRC 校验、流量控制保障数据完整性，解决数据准确传送的问题；事务层明确请求 / 响应协议、地址 映射等逻辑，解决传给谁和传什么的问题。
这种架构的核心价值在于解耦：各层可独立迭代升级，故障精准定位，同时兼容异构硬件，让总线得以支撑从 单机外设到超节点 Scale up 通信场景，成为现代计算系统高效运行的关键基础。
以下就 Scale UP 总线三层架构的功能和发展进行剖析。
总线物理层（PHY）是高速串行总线实现数据传输的核心硬件层，也是 SerDes 技术的核心载体，主流高速 总线（PCIe、Ethernet、UCIe、CXL 等）均遵循分层解耦设计（如遵循 PCI-SIG/IEEE 规范）。其核心分 为三层：PCS 层、PMA 层、PMD 层，部分架构会集成独立的 PLL/CDR 时钟模块。各层功能边界清晰、协 同工作，既实现高速串行传输的核心需求，又能适配不同协议、不同物理介质的差异化要求，同时大幅降低协 议升级和工艺迭代的研发成本。
图49 物理层位置 36
表7 物理层各子层功能说明
| 层级 / 模块 | 核心定位 | 核心功能 |
|---|---|---|
| PCS 层 物理编码子层 | 纯数字层，SerDes协议数字 核心，对接上层协议（事务层 / MAC 层） | • 调制编码 / 加扰解扰、FEC<br>• 串并 / 并串转换（SerDes 数字实现）<br>• 帧同步 / 定界、多通道帧对齐<br>• 链路训练协商（LTSSM）、速率协商<br>• 多协议格式适配 / 切换<br> |
| PMA 层 物理介质附加子 层 | 数模混合层，数字 - 模拟桥 梁，SerDes 信号优化核心， 与协议解耦可复用 | • CDR 时钟数据恢复，抵消时钟漂移 / 抖动<br>• DAC/ADC 数模 / 模数转换<br>• 自适应均衡（发送预加重 / 接收 CTLE/DFE）<br>• 单端 - 差分信号转换，抗共模干扰<br> |
| PMD 层<br><br>物理介质相关子 层 | 纯模拟层，物理介质直连接 口，功能与介质强绑定，不可 跨介质复用 | • 差分阻抗匹配，避免信号反射<br>• 发送端高速驱动放大、接收端低噪声放大（LNA）<br>• 物理介质（PCB / 铜缆 / 光纤 / 同轴）适配<br>• EMC/EMI 优化，抑制电磁辐射<br> |
| PLL/CDR 核心配套模块（时 钟核心） | 独立时钟模块，SerDes高速 传 输 节 拍 器 ， 部 分 架 构 将 CDR 归入 PMA 层 | • PLL：生成低相位噪声高速参考时钟<br>• CDR：从接收信号中提取同步时钟，实现收发端 时钟同步<br>• 抖动抑制 / 滤除，保证采样精度<br> |
数据发送的流程为：上层并行数据 -> PCS 层（编码 + 串化）->高速串行数字流 -> PMA 层（数模转换 + 预 加重 + 差分转换）-> 模拟差分信号 ->PMD 层（驱动放大 + 阻抗匹配）-> 物理介质（PCB / 铜缆 / 光纤）传 输。接收端为反向流程。
物理层分层设计，如同其他协议的分层设计一样，松耦合的分层结构使各层都有独立进化的可能，其核心价值 体现在如下方面：
PCS 层（数字）与 PMA/PMD 层（数模 / 模拟）完全解耦，数字工程师可专注于协议编码和串并转换，模拟 工程师可专注于信号完整性和介质适配；协议升级可仅需修改单一层级，如修改 PCS 层，PMA/PMD 层直 接复用（PCIe 6.0 -> CXL 3.0），从而大幅降低研发周期和技术风险。
同一套 PMA/PMD 层可搭配不同的 PCS 层，实现多协议兼容：如一款高速 SerDes PHY，可通过配置 PCS 层，同时支持 PCIe 6.0、CXL 3.0、UCIe 1.0 Standard PHY 模式；同一套 PCS/PMA 层，可通过更换 PMD 层，适配不同物理介质（如 PCB 背板、高速铜缆、光纤）。这也是 SerDes 技术能在主机内、数据中心、5G 等多场景应用的基础原因。
在 PCS 子层中，FEC（前向纠错）通过在发送端添加冗余校验比特（一般为 Reed-Solomon RS 编码）、 在接收端利用纠错码算法自动检测并纠正一定数量的传输误码，从而在不重传的情况下提升通信可靠性。FEC 广泛应用于高速 SerDes 系统中，能显著降低误码率、提升链路可靠性并延长传输距离，但会引入额外延迟、 增加功耗与带宽开销（冗余比特），并可能掩盖信道劣化问题。亦即更多的冗余位能带来更好的纠错能力，但 同时也会引入更大的延迟和更大的带宽开销。因此根据应用场景需求，选择合适的 FEC 算法是各 Scale up 协 议 SerDes 重点关注的问题。轻量级 FEC（如下图的 KR4）硬件实现简单，能有效消除字节级的传输错误， 同时不引入过多时延，减少因错误导致的重传和等待。 其纳秒级处理与 Scale up 的低延迟需求完美匹配，是 唯一能在不破坏性能前提下提供的硬件可靠机制，基本为 Scale up 协议标配。
图50 轻量级 FEC（IEEE Draft） PAM8 使用 802.3bj KR4 FEC 在误码率（BER）为 1E-15 时可提供 11.67dB 编码增益 37
SerDes（串行器/解串器）是物理层的核心载体，通过“并行转串行”发送、“串行转并行”接收的双向转换，解 决高速传输中的引脚占用、时序干扰、距离限制等痛点，是高速数据传输领域不可或缺的数据大动脉。其技术 重点围绕架构设计、调制方式、时钟同步等核心模块展开，当前技术要求聚焦于高速率、低功耗、高可靠几大 方向。
图51 SemiWiKi 的 SerDes 分代 38
SerDes 技术诞生于在 20 世纪 80 年代中期的光传输网络（SONET），用于长距离数字信号传输。将该技术 应用于主机信号互联的标志性事件是 PCIe 1.0（2003）标准的推出。
早期计算系统数据量小，并行传输以架构简单、时序易控的优势成为主流，如 ISA/PCI 并行总线。但随着计 算机、通信等领域向高速化、小型化演进，并行传输的短板愈发突出，需要新的解决方案。并行总线主要存在 如下问题：
这些瓶颈催生了 SerDes 技术。SerDes 最早于 20 世纪 80 年代末至 90 年代初，美国贝尔系统（AT&T/Bell Labs）主导开发 SONET 标准，将多个 E1/T1 信号通过 SerDes 芯片串行化后送入激光器驱动电路，经光 纤发送后在对端由 Deserializer（解串器） 恢复为并行数据流供交换机处理，解决了并行信号在单光纤的长 距高速通信（SONET/SDH 光纤骨干网）需求。后续接口迭代中，SATA 取代 PATA（Parallel ATA，并 行高级技术附件，也即 IDE 接口）、PCI-Express（PCIe）取代传统并行 PCI，其中 2003 年推出的 PCIe Gen1， 作为首个在计算机外设互联领域规模化采用 SerDes 的标准，彻底突破 PCI 并行总线高频短板，推动 SerDes 向多场景延伸，在机内总线（PCIe、USB），存储（NVME），显示（HDMI）、网络等领域已广泛应用。
如今 AI 算力集群、超节点互联等场景的高速 Scale up/ Scale out 互联需求，进一步驱动 SerDes 向更高速 率、更高可靠性迭代。
图52 SerDes 可在不同介质场景中应用
SerDes 技术的核心价值的是破解传统并行传输在高速场景下的多重瓶颈，同时适配多领域差异化传输需求， 具体解决了如下关键问题：
图53 差分信号抑制共模干扰 39
SerDes 系统由五大核心模块构成，各模块协同保障信号完整性与传输效率：
图54 SerDes 系统构成 40
并行数据接口：图示中的 Data in 接口，对接 CPU/GPU/DPU/FPGA/ASIC 内部总线（如 AXI、AHB 协议）， 支持 8/16/32bit 等位宽，负责并行数据收发，关键指标包括接口电压、时序稳定性及数据吞吐量，是芯片内 部与串行链路的桥梁。
串/并转换器：串行器（Serializer）通过移位寄存器、FIFO 缓冲将并行数据压缩为高速串行流，高端方案集 成预加重电路补偿高频信号衰减；解串器（Deserializer）则反向还原串行信号，内置均衡器抵消传输线码间 串扰，同时解决时序对齐问题。
图55 并行数据串行化传输 41
PLL 时钟模块：生成低相位噪声、高稳定性的高速时钟，决定传输速率上限，支持动态频率调整以适配多协 议需求，同时为接收端提供同步参考，是高速传输的“节拍器”。
物理传输接口（PHY）：包含发送驱动器与接收缓冲器，采用差分信号传输减少共模干扰，关键参数涵盖输出 摆幅、差分阻抗及传输介质适配能力（铜缆、PCB、光纤等）。
CDR（Clock and Data Recovery，时钟数据恢复）：从不含独立时钟的高速串行数据流中提取时钟信号并 同步采样数据，确保接收端能准确还原发送端的比特序列。
调制技术直接决定传输速率与带宽利用率，协议体系则适配不同应用场景：
调制方式演进：主流采用 NRZ（Non-Return-to-Zero 不归零码，1 符号 1bit，结构简单，适用于 PCIe 5.0 及以下）和 PAM4（4-Level Pulse Amplitude Modulation 4 电平调制，1 符号 2bit，带宽翻倍，用于 PCIe 6.0、DDR5、112\224GT/s 等高速场景），在更高的速率下如 448GT/s，正在分析引入更复杂的调制方式 如 PAM6 或 PAM 8 等的可行性。
图56 NRZ（PAM2）调制及眼图
图57 PAM4 调制及眼图 42
主流协议分类：按 SerDes 的应用场景，可以将其进行如下场景简单分类，在各类场景的 SerDes 速率选择 中，更关注的是满足场景及周边器件配合的应用要求。需注意的是 SerDes 本身是通用高速串行收发电路， 不和特定协议绑定。链路物理层通过搭配不同的 PCS（编码/控制逻辑）和链路训练机制，同一 SerDes 可支 持多种协议。
按应用类型分类：
| 接口标准类型 | 典型代表 | 核心技术参数 | 应用对象 |
|---|---|---|---|
| 总线类 SerDes | PCIe SerDes | 版本覆盖 1.0~6.0；PCIe 6.0 采用 PAM4 调制，速率 64GT/s；支持 x1/x2/x4/x8/x16 链路宽度 | CPU、GPU、网卡等外设互 联 |
| CXL SerDes | 基于 PCIe 5.0/6.0 演进，兼容 PCIe 物理层；支持缓存一致性协议；速 率 32GT/s（CXL 2.0）~64GT/s （CXL 3.0） | 异构计算集群、内存池化设备 | |
| USB SerDes | USB 3.2 速率 20Gbps；USB4 速 率 40Gbps；支持雷电 3/4 兼容 | 消费电子、外设扩展 | |
| 网络类 SerDes | 以太网 SerDes | 覆盖 10G/25G/100G/400G/800G 以 太网；200G 以上多采用 PAM4； 支持 IEEE 802.3 标准 | 交换机、路由器、网卡、光模 块 |
| InfiniBand SerDes | 速率 200\400Gbps；支持无损传 输和 RDMA | 高性能计算集群、AI 超算互联 | |
| Chiplet类 SerDes | UCIe SerDes | 3.0 版 64 GT/s（PAM4）/48 GT/s，2.0 版 32 GT/s（NRZ）； 128b/130b 编码；支持 2D/2.5D/3D 封装 | 小芯片（Chiplet）间互联，如 CPU+GPU、CPU + 内存、 AI 加速芯片组合 |
| 显示类 SerDes | HDMI SerDes | HDMI 2.1 速率 48Gbps；支持动态 HDR、8K 视频传输 | 电视、显卡、显示器 |
| DisplayPort SerDes | DP 2.0 速率 80Gbps；支持多流传 输（MST） | 电竞显示器、笔记本扩展坞 |
| 接口标准类型 | 典型代表 | 核心技术参数 | 应用对象 |
|---|---|---|---|
| 存储类 SerDes<br><br> | NVMe over Fabrics SerDes | 基于 PCIe 或以太网物理层；支持 TCP/RDMA 协议；速率与底层接 口一致 | 分布式存储、全闪存阵列 |
| Fibre Channel (FC) SerDes | FC-NVMe 速率 32Gbps/64Gbps；专为存储区域 网络（SAN）优化 | 企业级存储、数据中心备份 | |
| SATA/SAS SerDes | SATA 3.0 速率 6Gbps；SAS 4.0 速率 22.5Gbps；采用 8b/10b 编码 | 机械硬盘、固态硬盘、磁盘阵 列 |
按协议分类：
| 序号 | 协议 | SerDes Role |
|---|---|---|
| PCIe Gen 1–6 | 使用 SerDes 实现双向高速通道 | |
| Ethernet (10G/25G/100G/400G) | 使用基于 SerDes 的物理层（PHY）用于光 / 铜介质传输 | |
| SATA/SAS | 用于存储设备的串行数据传输 | |
| USB 3.x/4 | Type-C 接口和 DP模式 | |
| DisplayPort, HDMI | 多媒体 SerDes 传输 | |
| JESD204B/C | ADC 与 DAC 和 FPGA/ASIC 之间的高速串行链路 | |
| UCIe, BoW, XSR, AIB | 基于 SerDes 的芯粒互联标准 |
应注意“PCIe SerDes”或“Ethernet SerDes”并不是严格意义的分类方式，指的是为特定协议优化的完 整 PHY 解决方案，其中 SerDes 是核心模拟前端。
Scale up 协议的发展，基本借用现有成熟连接器件和生态，如 PCIe 或 802.3 物理层：兼容现有 PCIe PHY （CXL3.0\4.0）或以太网 PHY(UALink\UB )及其光模块（如 QSFP-DD、OSFP）和铜缆，无需定制硬件； 支持 802.3 标准的速率协商、链路训练机制，降低硬件适配成本。如协议完全复用标准以太网 PHY，仅在链 路层扩展相关字段，现有交换机通过固件升级，无需全新进行开发即可实现对新协议的支持。目前除了 CXL （兼容 PCIe）和 NVLink（私有）外，其余主流 Scale up 协议（UALink、UB、ETH-X、SUE 等）均在 物理层兼容 802.3 标准。
高速化带来三大核心瓶颈：信号完整性（串扰、时钟抖动、电源噪声导致失真）、功耗热管理（高速处理占系 统总功耗比例高，密集封装散热难度大）、多通道同步（温度、功耗波动易引发通道不一致，影响多链路协同）， 同时协议兼容性对材料和供应链提出更严格要求，需跨厂商协同优化。
传输速率持续跃升，从成熟的 32GT/s（PCIe 5.0）向 64GT/s（PCIe 6.0）和 112GT/s 规模化过渡，头部 企业已加速布局 128GT/s（PCIe 7.0）及 224GT/s 技术。英伟达 GB200 NVL72 服务器即使用了 224G SerDes 铜连接方案；400G 双向 SerDes（200G+200G，待进一步技术披露）技术也在 2026 年初的 CES 大会上作为英伟达下一代 Rubin NVL72 超节点的关键技术，计划在 2026 年中落地发布。
英伟达使用的 NVLink SerDes 为其私有标准，OIF（Optical Internetworking Forum，光互连论坛）正在 联合 UALink（Ultra Accelerator Link，超加速器链路联盟）、UEC（Ultra Ethernet Consortium，超以太 网联盟）、SNIA（Storage Networking Industry Association，存储网络行业协会）、OCP（Open Compute Project，开放计算项目）和 IEEE 802.3 等组织，积极制定开放的 448G SerDes 标准，有望在 2026~2027 形成标准落地。
在以太三代高速互联技术（56G、112G 和 224G）和 PCIe 6.0（64G）上，PAM4 调制方式已经成功应用。 对于 448G SerDes 更高速率的技术，为降低奈奎斯特采样频率和缓解信道带宽限制，正在考虑使用更高阶 的 PAM6 和 PAM8 调制方案，但由此带来的信噪比（SNR）降低及接受端时延容差窗口变窄，对电缆和连 接器、PCB 提出了极高的要求。同时，使用新的调制方式也带来了和原有 PAM4 的后向兼容性问题，但为 减轻 448G 高速带来的 SI（信号完整性）挑战，使用 PAM6 和 PAM8 是个很现实的选择。
图58 PAM8 眼图，对容差带来更大挑战 43
截至 2025.11，OIF 的 CEI LR（CEI：Common Electrical I/O）历史项目及 448G 项目的进展如下，后者 还存在较多的待定项，预计在 2026 年能确定：
表8 OIF SerDes 项目进展 44
| OIF CEI 项目 | CEI-56G-LR | CEI-112G-LR | CEI-224G-LR | CEI-448G-LR |
|---|---|---|---|---|
| 时间线 | 2014-2017 | 2017-2021 | 2021- | 2026- |
| 对应以太网速率 | 50/100/200G | 100/200/400G | 200/400/800/16 00G | 400/800/1600G/ 3200G |
| 以太交换机容量 | 12.5T | 25T/50T | 50T/100T | 100T/200T |
| 每通道数据速率 | 56 Gbps | 112 Gbps | 224 Gbps | 448 Gbps |
| 调制方式 | PAM4 | PAM4 | PAM4 | 待定 |
| 传输距离目标 | 3 米铜缆 | 2 米铜缆 | 1 米铜缆 | 待定 |
| OIF CEI 项目 | CEI-56G-LR | CEI-112G-LR | CEI-224G-LR | CEI-448G-LR |
|---|---|---|---|---|
| 前向纠错（FEC）前 误码率（BER）目标 | 1e-4 | 1e-4 | 1e-4 | 待定 |
| 串 行 器 / 解 串 器 （SerDes）架构 | 模拟/数字信号 处理器（DSP） | 模拟/数字信号处 理器（DSP） | 数 字 信 号 处 理 器 （DSP） | 待定 |
作为下一代高速互联关键技术，448G SerDes 支持多种物理介质连接方式：
图59 448GT/s SerDes 可能采用的多种连接方式 45
CPC（Co-packaged Copper）：共封装铜缆（CPC）是将高性能铜缆直接集成到芯片封装附近的互连技 术，通过缩短电气路径、利用低损铜缆，在短距实现高带宽、低功耗、低成本的数据传输，是高速计算系统中 替代传统 PCB 走线和可插拔模块的重要方案。
CPO（Co-packaged Optics）：共封装光学（CPO）是面向高速系统的互连架构，其核心思想是将光学引 擎（光模块）与 ASIC 芯片（如 GPU、TPU、交换机芯片）共同集成在同一封装基板或中介层（Interposer） 上，从而大幅缩短电通道长度，解决“功耗墙”和“带宽墙”问题。成本显著高于 CPC 方案。
LPO（Linear-drive Pluggable Optics，线性驱动可插拔光学）,LRO(Linear Receiver Optics)：是一种 省去传统光模块中 DSP 芯片、采用直驱线性电路的低成本低功耗光互连方案，适用于短距、高密度数据中心 场景，在性能与成本之间取得新平衡。
DAC（Direct Attach Cable，直连铜缆）：是电接口的高速无源铜缆组件，用于短距离（通常≤7 米）设备 间高速互联，具有低延迟、低功耗、低成本优势，广泛应用于数据中心机架内服务器与交换机连接。
AEC（Active Electrical Cable）：在铜缆中集成 Redriver/Retimer 的有源高速互连方案，兼具铜缆的低成 本与光缆的延伸能力，是高速短距互连的重要选项，也称为 Active DAC。
机架内的电气链路因其低功耗、低延迟和低成本特性而至关重要，网络运营商严重依赖这些链路在未来速率下 的持续可用性。共封装铜缆（CPC）解决方案有望显著改善损耗，但 SerDes 可实现的实际传输距离（无需 或仅需少量中继器）将决定铜缆互联是否仍适用于此类应用，或者即使在机架内也需要采用光学解决方案。如
224G SerDes 最先在 NVLink 落地一样，英伟达有可能最先实现 448G SerDes 落地，其是否使用 CPC 方案可能成为重要方向参考。预计 IEEE 等公共标准也会使用 CPC 作为机架内首选互联方案。
共封装光学（CPO）是最大限度减少电气信道损耗的有效方式，因此也成为高速互联架构的热门选择。其生 态系统仍在发展中。同时也存在集成复杂性、可靠性和可维护性担忧以及初始成本较高等因素的限制。随着这 些挑战得到解决以及技术成熟，CPO 可能在 448G 及其后的超高速时代获得更广泛的应用。
SerDes 正在走向 224GT/s 规模产业化，448GT/s 标准落地的发展道路上，预计 2026~2027 年 OIF 会完 成 CEI-448G（CEI：Common Electrical I/O）规范草案。同时 Broadcom、Marvell、Intel 等已开展 448G SerDes IP 原型设计，向更低功耗、更强兼容性演进。低损耗 PCB 材料、100+GHz 连接器、先进封装等周 边技术在同步推进。其中高阶调制技术（如 PAM6/8）、AI 自适应均衡算法、铜光融合互联方案将成为研发 重点。PCI-SIG 也已于 2025 年 8 月启动 PCIe 8.0 规范制定，目标实现 256GT/s 信令速率，进一步推动超 高速 SerDes 技术迭代。
表9 海外主要 SerDes IP 供应商 46
| 公司 | 主要 SerDes IP 产品 |
|---|---|
| Synopsys | Industry leader in PHY IP for PCIe, Ethernet, USB, UCIe |
| Alphawave Semi | Specializes in 56G/112G SerDes for AI/HPC/datacenter |
| Cadence | Offers SerDes IP and PHYs (USB4, PCIe, 112G) |
| Rambus | High-speed memory and SerDes PHY IP |
| Credo, eSilicon (Inphi) | Optical SerDes PHY IP, CPO |
| Siemens EDA | Offers simulation and verification of SerDes systems |
| AnalogX, Kandou, Marvell | Focused on ultra-low-power or chiplet-centric SerDes designs |
高速 SerDes 的发展面临如下瓶颈：224GT/s 及以上速率场景下信号完整性优化难度呈指数级递增，功耗控 制与量产良率待突破。同时，国内高速 SerDes IP 及先进工艺、先进材料距离国际先进技术还有差距，尚需 潜心追赶突破。
Scale up 总线链路层是总线协议栈（物理层->数据链路层->事务层）的核心中转层，核心职责是衔接物理层 信号传输与事务层地址映射/内存访问逻辑，保障事务包（TLP，Transaction Layer Packet）在链路内的 可靠、有序、高效传输。对于 Scale Up 总线，如 UALink、PCIe（含 CXL）、Infinity Fabric 等，其聚焦节 点内高密度高速互联场景。链路层需在通用功能基础上，满足极致低延迟、高带宽、高容错及缓存一致性（部 分协议要求）适配需求，其中 LLR（Link Layer Retransmission，链路层重传）、CBFC（Credit-Based Flow Control，基于信用的流量控制）、虚拟通道（VC）是核心支撑功能。本章以成熟的 PCIe 生态为主，阐述链 路层的主要功能。各 Scale up 协议的具体实现可参见具体协议，但主要关键功能类似。
图60 链路层位置 47
总线链路层的设计核心是解决物理层（下层）信号不稳定性与事务层（上层）高效交互的矛盾，功能围绕“可 靠传输、流量管控、链路运维”三大维度展开，主要包括以下五个功能，其中重点细化 LLR、CBFC、VC 的技术实现。流控和 VC 是事务层和链路层共同参与完成，在 PCIe 规范中将其功能放在事务层。为结合链路 层实现，本文将流控和 VC 功能在链路章节进行展开描述。同时，部分协议（如 UB）也将流控和 VC 管理放 在链路层实现。
图61 数据链路层主要功能（UB）48
负责总线链路从初始化到故障恢复的全生命周期管理，确保链路长期稳定运行，核心流程包括初始化协商、链 路训练、状态监控及低功耗管理。
链路层负责将事务层下发的 TLP 封装为链路层帧，接收端解封装后传递至事务层，帧结构设计直接影响传输 效率与兼容性。
一般封装流程为：为 TLP（事务层报文）添加链路层帧头、帧尾，形成完整链路帧。帧头包含链路标识、事 务包类型、长度信息及 LLR 重传序列号，用于接收端识别帧边界、事务属性及重传定位；帧尾包含 CRC 校 验码，用于差错检测。与网络链路层（如以太网）不同，总线链路层帧一般依赖事务层的 ID（GPU-ID，设 备 ID）或 BDF 地址（PCIe：总线-设备-功能）实现寻址，无需节点间路由，精简帧头字段、简化帧结构并 降低解析延迟。
在 Scale Up 总线低延迟设计中，普遍采用 FLIT（Flow Control Unit，流控制单元）技术优化封装与传输效 率，其核心是将可变长度的 TLP 拆分为固定长度的 FLIT 单元进行传输，而非直接传输完整可变长帧。FLIT 单元通常包含数据 FLIT、控制 FLIT 及尾 FLIT 三类：数据 FLIT 用于承载核心数据，控制 FLIT 用于传输链 路控制信息（如 LLR 重传指令、CBFC 信用交互信号），尾 FLIT 用于标识一个完整 TLP 的 FLIT 流结束， 确保接收端可精准重组原始 TLP。
FLIT 技术的核心优势的是适配低延迟与高效流控需求：
部分从以太演进来的 Scale up 协议，如 ETH-X、SUE、ESUN 等，为保持和以太报文的兼容性，没有使 用 FLIT 技术，而使用变长的报文结构。
该功能通过“差错检测-重传纠正”二级机制，解决物理层信号衰减、串扰、噪声导致的数据位翻转问题，LLR 是链路层重传的核心实现方式，区别于事务层重传，具备更精细的链路级控制能力。
方式。此外，LLR 支持重传优先级调度，高优先级事务（如 GPU 间梯度交换）的重传请求可抢占带宽， 避免低优先级事务阻塞关键数据传输。
虚拟通道是链路层实现单一物理链路承载多逻辑事务流的核心技术，通过在物理链路内划分独立逻辑通道 （VC，Virtual Channel），实现不同类型事务的并行传输与隔离调度，避免低优先级事务阻塞高优先级事务， 是 Scale Up 总线支撑多并发事务的关键优化手段，需与 LLR、CBFC、FLIT 技术深度协同。
图62 PCIe / CXL 使用转发优先级（TC）配合虚拟通道（VC）进行转发 49
事务层、链路层、物理层在 VC 转发中的作用： 表10 PCIe 虚拟通道控制各层功能
| 层级 | VC 相关操作 |
|---|---|
| 事务层（Transaction Layer） | • 决定 TLP 使用哪个 VC<br>• 在 TLP 头部设置 TC（Traffic Class）字段（3 位）<br>• TC 通过 TC/VC 映射表 转换为具体 VC ID<br> |
| 数据链路层（Data Link Layer） | • 为每个 VC 维护独立信用计数器和缓冲区<br>• 调度器按策略选择 VC 发送 TLP<br> |
| 物理层（Physical Layer） | • 透明传输：不感知 VC，仅串行化比特流 |
基本过程为：
CBFC 是总线链路层的核心流量管控机制，相较于网络链路层的 PFC（优先级流控），其适配总线“短距、 高速、低延迟”特性，通过信用额度动态分配，实现无阻塞传输，是 Scale Up 总线高带宽利用率的关键。
图63 链路层流控过程
为更合理、充分地使用接收缓冲区空间，PCIe 6.0 版本正式引入新的 VC 流控机制，即将缓冲区进一步 拆分为VC专用缓冲区和VC共用缓冲区（池），同理将Credit分VC通道专用（Virtual Channel Credit） 和池共用（Pool Credit）两种类型，多个虚拟信道可共用 Pool Credit。使用共享流控（Shared Flow Control）有如下优势：50
UALink 1.0 协议也借鉴了该机制，在数据流每一次转发过程中均依靠 Credit 机制进行流控，并将 Credit 按是否公用分为专用（Virtual Channel Credit）和共用（Pool Credit）。在单颗 Switch 芯片中，在不 同的转发阶段也需要进行 Credit 流控，如下图，芯片内部的转发流程中存在多个 Credit Loop。
图64 UALink 转发过程中的流控环（Credit Loop）51
UB 协议的 Credit 流控机制也采用类似机制，UB 使用 VL（Virtual Lane）替代了 VC 概念。其流控特 点：
图65 UB 信用流控过程 52
UB 数据链路层的信用流控过程示例（Credit 独占模式）：
对于变长的报文发送，发送方要攒够足够发送一个报文的 Credit 后，比如 5 个 Credit，才能发送这个报文。 取决于 Credit Cell（一个 Credit 对应的定长数据量）大小和报文长度。最后一个 Cell 发送时，通常只有部 分是有效数据，需对无效数据进行填充（一般为补零）处理。
基于 Credit 的流控（CBFC）是 Scale up 协议的主要流控方案，将缓冲区分为虚拟通道独享及通道共享两 种类型并分别进行 Credit 流控，可以更有效地使用有限的缓冲区资源，该方式越来越多地被高速互联协议用 于点对点流控。同时也有部分协议扩展 Credit 流控方式用于端到端的流控（如 ETH-X），核心原理均为发送 端基于接收端提供的 Credit 决定发送的 FLIT 数量，实现数据流量按需发送。
总线链路层的通用功能以“可靠传输、流量管控、链路运维”为核心，LLR、CBFC 与虚拟通道（VC）构成 三大支柱，分别承担链路级重传纠错、无阻塞流量控制、多事务并行隔离的关键作用；Scale Up 总线链路层 大都建立在此基础上，通过 LLR 低延迟优化、CBFC 动态调度、VC 级隔离与带宽分配、容错强化及缓存一 致性适配（部分协议支持），实现“极致低延迟、高带宽、高可靠”的场景化需求。其本质是为节点内高密度 高速互联量身定制的轻量高效传输层，区别于 Scale Out 总线的通用性设计，最终支撑 GPU 间直接内存事 务传输，成为超节点、高性能计算等场景的算力互联基石。
Scale up 总线的事务层（Transaction Layer）位于传输层之上、功能层之下，是协议栈的顶层核心层，负 责将上层应用的内存访问（Load/Store、URMA 异步访问）、消息传递（Send/Recv）等操作封装为标准 化的网络事务（如内存读写事务、消息收发事务）传递给传输层，并处理事务的排序（避免乱序导致的逻辑错 误）、流量控制（防止缓冲区溢出）等关键问题，确保事务的一致性和可靠性。
硬件总线领域的“事务层”概念，其来源是英特尔公司 2001 年提出的 PCIe 总线协议，核心是通过高速串行 点对点双通道传输技术，解决了旧有并行总线在信号干扰、频率提升瓶颈和带宽限制等方面的问题。
PCIe 总线采用分层协议架构（物理层、数据链路层、事务层），其中事务层是连接设备核心与总线的关键层， 其核心功能包括：
图66 PCIe 分层
Scale up 总线事务层的主要功能如下：
接收上层发起的 Load/Store、RDMA 读写等 IO 操作，将其转换为标准化、硬件可识别的事务语义，主 流实现均支持 Memory Read、Memory Write、Atomic 原子操作、Message 控制消息四大类基础事 务，屏蔽底层传输细节，为上层提供统一的内存访问抽象，实现跨节点显存/内存的直接、透明访问。
发送侧：为每个事务分配唯一标识，完成地址转译、事务头封装、数据块打包，生成符合协议规范的事务 层微片（TL Flit），交付给下层数据链路层；
接收侧：完成事务报文的解析、头信息校验、地址解码，还原为上层可识别的操作指令，同时完成请求与 响应报文的配对，形成完整的事务闭环。
负责事务的发起、并发调度、超时管理与状态机维护，跟踪每个事务的执行状态，处理异常事务的重传、 终止与错误上报；同时支持多虚拟通道、多优先级事务的调度，优化链路带宽利用率，保障时延敏感类事 务的优先传输。
与数据链路层紧密配合，实现端到端的基于信用的流控（CBFC）、拥塞管理与 QoS 调度，区分不同业 务流量的优先级，同时保障同路径事务的保序传输，避免乱序带来的上层开销，实现高可靠传输。
部分协议还在事务层扩展了 RDMA 语义兼容、集合通信加速、报文聚合、端到端序保证等能力，以适配大模 型训练/推理的多样化通信需求。
内存语义请求处理是事务层的核心功能，本节对内存语义、消息语义相关概念进行说明，集合通信是分布式训 练的高层通信模式，依赖事务层提供的功能实现，在本节一并介绍。流控和 VC 是事务层和链路层共同协同 完成，相关概念已在链路层章节进行介绍。
在计算机组成原理中，内存语义是指用于控制对共享内存区域或变量访问的一系列操作逻辑。内存语义就是定 义了一套规则，告诉计算机系统中的各个部分，在什么时候、以什么方式可以访问或修改内存中的数据，确保 数据的一致性和准确性。英伟达定义的超节点特征为节点内部处理器（GPU/CPU）通过 Scale up 网络互联， 处于同一个 HBD（High Bandwidth Domain，超带宽域）。HBD 域包含了软硬件两个层面，在硬件互联层面， 超节点 HBD 域内采用 NVLink、UALink 等专用 Scale up 互连协议，在加速卡（GPU/NPU）之间构建了 高带宽、低延迟的通信域。解决了传统架构中 GPU 间通信必须经由 CPU/PCIe 总线的通信瓶颈，为海量数 据并行处理奠定了物理基础。在软件与系统层面，HBD 内的计算节点资源管理也有所改变，计算节点可以基 于内存语义直接通过内存地址空间访问 HBD 内的内存地址，计算节点间的高速通信通常直接绕过 OS 内核协 议栈，使用专用硬件完成数据读写，显著降低通信开销。
传统服务器间的通信互联依赖网络技术（如以太网或 InfiniBand），相对于系统内部总线，网络复杂的协议栈、 额外的转发开销、微秒甚至毫秒级的延迟，传输效率存在数量级差异。内存语义允许 CPU、GPU、加速器之 间像访问本地内存一样直接操作对方内存，处理器直接使用最基础的 Load（读取）和 Store（写入）指令访 问远端数据，大大简化了编程模型。省去消息机制（如 RDMA）使用的 “数据拷贝 - 封装 - 传输 - 解封装 拷贝” 的中间环节，大幅降低跨设备数据交互延迟及提升了访问效率。
图67 UALink 通过 MMU 进行地址转换，实现全局访问
因硬件级 Cache 一致性协议（如 MESI）在读写数据时，须确认和修改 Cache Line 状态，此过程存在 多次和 Cache 端的交互。当 HBD 规模较大时，维护一致性的通讯与同步开销可能抵消并行效率，尤其 在高并行密集访问场景下易降低数据吞吐量，导致链路的有效利用率降低。
同时，因需要复杂硬件逻辑维护一致性，会额外增加芯片面积与功耗，Scale up 协议可能有选择地部分支 持一致性。即通过纯软件方式来保证读写的顺序（Fence 操作），保证数据操作的完整性（如 ETH-X 实现）；也可以减小一致性的作用范围，仅限于 CPU 及和其直联的 GPU 间保证 Cache 一致性（如英 伟达 NVLink C2C），在此范围外的一致性由软件保证，如在软件开发时避免出现可能导致 Cache 不一 致的读写操作，可以使用 Fence 等机制来保证读写顺序。
UB 使用对特定地址块的 Ownership 机制，提供对共享内存的读写控制访问权限，来保证跨节点数据一 致性，也是一种值得借鉴的方式，但需考虑权限控制带来的管理复杂性。
| 协议名称 | 误码率要求 | 关键技术手段 |
|---|---|---|
| NVLink | 1e-12 | CRC 校验 + 自适应 FEC |
| PCIe | 1e-12 | LCRC、ECRC 校验 + FEC (Gen6) |
图68 CXL 的数据读取过程，需进行多次 Snoop 报文（红圈）交互来确认数据一致性（过程解读详见 CXL 章节）
超节点 Scale up 网络的亚微秒级延迟要求是支撑 AI 大模型训练和推理的技术底线，其实现依赖于 协议栈精简、硬件架构革新和系统协同优化的综合方案。通过内存语义支持、专用交换架构和低延 迟 FEC 等关键技术，实现了从传统消息机制的数据包传输到内存直接访问的转变，为超节点数据低 延时读写提供了物理基础。
超节点中 GPU 等加速器常进行张量并行、专家并行等操作，编译器与运行时会将设备间通信和计算 过程重叠优化，此优化依赖稳定可预测的通信延迟。若抖动过大，会打破这种优化平衡，导致计算 资源相互等待，训练或推理效率大幅下降，合理要求是将抖动控制在 0.1μs 内。
控制延迟抖动的实现路径一般围绕硬件架构、协议设计和流量管理等多维度进行优化。如广泛采用 的 Flit（Flow Control Unit，流控单元，即定长数据片）机制，配合 Credit 流控机制管控缓冲区， 可有效降低避免了拥塞导致的抖动。同时，无损传输是低抖动的底线，频繁的重传虽可兜底数据完
整性，但会引入更多的延迟抖动。因此低抖动要求本质上还需配合无损传输需求，将抖动控制在避 免触发频繁重传的范围内，防止重传与抖动形成恶性循环，避免 GPU 或加速器上下文中断等严重问 题。
Scale up 网络的高可靠性是保障 AI 大模型长时间稳定训练、多 GPU 协同计算数据一致的关键，其可靠 性要求聚焦数据一致性、传输稳定性和任务连续性，实现路径则贯穿物理层、链路层等多层架构优化，超 节点高密度互联场景下，单丢包可能导致训练任务中断和阻塞，这要求 Scale Up 网络具备无损传输的特 性。
表11 主流互联协议要求的 BER
| UALink | 1e-12（推测） | CRC + 可选重试 + FEC |
|---|---|---|
| ETH-X | 1e-12（推测） | 以太网基础 + 增强可靠性机制 |
| UB | 1e-12（推测） | CRC + 多FEC动态切换 |
为保证 GPU 间低延迟、高带宽数据传输可靠性，Scale up 网络协议的误码率（Bit Error Ratio，BER） 要求为 1e-12 或更低。这一标准已成为行业共识，原因如下：
英伟达的 NVLink 是内存语义典型代表，通过软硬件协同实现内存语义的核心机制。
硬件层：在每个 GPU 的 MMU（内存管理单元）集成 NVLink 专用的地址翻译模块，识别远端内存地址。使 用这种方式将所有连接的 GPU 的本地内存、显存、甚至 CPU 内存映射到同一个虚拟地址空间，实现统一虚 拟地址（UVA）。每个 GPU 的 L2 缓存集成 NVLink 一致性代理（Coherence Agent），当一个 GPU 修改 某块远端内存时，硬件会通过 NVLink 链路发送 “无效化 / 更新” 信号，保证其他 GPU 看到最新数据，在硬 件层面保证缓存一致性。
软件层：通过 CUDA 将底层语义抽象为简单 API，CUDA 的 nvcc 编译器会根据 NVLink 的内存语义优化代 码：比如将“本地写 + 远端读”优化为 NVLink 直接传输，避免冗余同步；自动选择弱一致性模型提升性能。
CXL（Compute Express Link） 是由 CXL 联盟制定的开放标准的高速互连协议，是在 PCIe 物理层和电 气接口之上，定义了一套全新的、支持缓存一致性和内存语义的高层协议栈。
超节点架构中，内存语义和消息语义协同工作， 如大模型训练中频繁的参数同步操作，无需经过传统的“序 列化-网络传输-反序列化”流程，直接通过内存语义通信完成，可满足大模型训练/推理中的小包通信需求，
提升专家网络小包数据传输及离散随机访存通信效率。消息语义负责超节点内设备间的控制指令传递、任务调 度与状态同步，保障系统整体协调运行，支撑大数据块传输与跨超节点通信。
消息语义指的是传统的、基于显式发送（Sand）/接收（Recv）操作实现数据交换的通信模式，数据在计算 节点（如 GPU）之间传输时，被视为一个个独立的“消息”或“包”。消息传递语义的核心是“数据移动”： 发送方需将数据序列化（转换为可传输格式）、通过网络协议（如 TCP/IP、RDMA）发送，接收方需反序列 化（还原为本地格式）并存储到本地内存。这种模式通信过程是主动且显式的：
好信封（封装）、投递（发送）、等待邮差运输、对方签收（接收）。 消息语义常见类型：
集合通信（Collective Communication）是并行计算 / 分布式系统中多个进程（或计算节点）共同参与的一 组通信操作（参考下节通信原语），用于实现进程间的数据交换、同步或聚合。集合通信是为了解决点到点通 信在多节点场景下 “编程复杂、性能低下、同步困难” 的问题。现代高性能网络硬件开始原生支持某些集合 通信操作。例如，InfiniBand 网络和 NVSwitch 能够在交换机层面直接执行归约操作，大幅降低了 CPU 开 销和通信延迟。
集合通信的概念起源于高性能计算（HPC）领域，其标准接口规范由 MPI（消息传递接口，Message Passing Interface） 定义。随着深度学习的发展，它已成为分布式训练的核心技术。
集合通信最为基础的操作有发送、接收、复制、节点间进程同步等，这些基本的操作经过组合构成了一组通信 模板，也称为通信原语。
| 原语名称 | 核心功能 | 典型场景 |
|---|---|---|
| 广播（Broadcast） | 1 个主进程将数据发送给组内所有其他进程 | 模型参数分发、配置同步 |
| 散射（Scatter） | 根进程将一份数据分片，分发给组内所有进程 | 数据并行的任务分片分发 |
| 聚集（Gather） | 所有进程将本地数据发送给根进程，根进程汇总 | 任务结果收集、分片数据合并 |
| 原语名称 | 核心功能 | 典型场景 |
|---|---|---|
| 归约（Reduce） | 所有进程将本地数据按指定规则（求和 / 最大值） 计算，结果返回根进程 | 梯度求和、统计指标计算 |
| 全归约（All-Reduce） | 归约的基础上，将最终结果分发给所有进程 | 分布式训练的全局梯度同步 |
| 全聚集（All-Gather） | 汇总所有进程将本地数据到全部进程 | 模型并行参数同步 |
| 归约散射（ReduceScatter） | 先归约再将数据分片，分发给组内所有进程 | 张量并行梯度分摊 |
| 全交换（All-to-All） | 进程间全对全数据交换 | MoE（专家混合）模型中的 数据分发 |
| 屏障同步（Barrier） | 所有进程到达该点后等待，直到全部到达再继续 | 多节点阶段执行同步 |
图69 通信原语示意图
事务层的为协议栈顶层核心，承担语义转换与事务抽象、报文封装解析、全生命周期调度、端到端传输保障（部 分协议由传输层实现此功能）等核心功能，为上层应用屏蔽底层传输细节，提供标准化的跨节点内存 / 显存访
问抽象。同时，事务层为集合通信提供底层支撑，满足大模型分布式训练的数据同步与聚合需求。是超节点实 现高性能高可靠运行的核心基础。
在计算机系统的发展长河中，内部组件之间的互联技术始终是推动性能跃升的核心动力。在 PCI Express （PCIe）成为主流之前，计算机经历了从早期并行总线到高速串行互连的深刻变革。这段历史记录了技术和 工程设计在带宽、延迟、可扩展性与信号完整性之间不断寻求平衡的智慧。
计算机内部互联的雏形可追溯至 20 世纪 80 年代。1981 年，IBM 在其 PC XT 机型中引入了 ISA （Industry Standard Architecture）总线，这是最早的标准化扩展接口。最初的 8 位 ISA 提供约 4.77 MB/s 的带宽， 随后 16 位版本将带宽提升至 8 MB/s。尽管在当时已属先进，但随着图形处理和数据存储需求的增长，ISA 的带宽迅速成为瓶颈。
为应对这一问题，IBM 于 1987 年推出了 MCA（Micro Channel Architecture），试图通过 32 位宽度和更 高时钟频率提升性能。MCA 在技术上优于 ISA，但由于其封闭性和高昂成本，未能广泛普及。与此同时，行 业开始寻求开放、兼容且高性能的替代方案。
为打破 IBM 在 MCA 上的事实主导，以康柏（Compaq）为首的九家 IBM 竞争对手迅速联合，于 1988 年推 出 EISA 总线（扩展工业标准架构），在保持 32 位性能的同时，完全兼容 ISA 设备，赢得了广泛支持。但其 架构陈旧，性能提升有限，很快被后起的 PCI 总线替代。
同期，在运行图形用户界面和简单三维游戏时，显卡性能被严重束缚。为解决这一瓶颈，视频电子标准协会 （VESA）于 1992 年推出了 VLB 总线标准。它并非取代 ISA，而是作为其高速扩展，直接连接到 80486 处理器的本地总线，从而实现与 CPU 近距离数据交换。因后续奔腾（Pentium）处理器，其总线架构与 80486 截然不同，VLB 无法直接适配，该技术也迅速没落。
1991 年，Intel 提出 PCI（Peripheral Component Interconnect）总线标准，并联合多家厂商成立 PCI-SIG （PCI 特殊兴趣组），推动其标准化与普及。PCI 采用 32 位并行架构，工作频率为 33 MHz，理论带宽达 133 MB/s，显著优于 ISA 和 MCA。它支持即插即用、多设备共享总线，并迅速成为台式机、服务器和工作站的 主流扩展接口。
随着应用需求进一步提升，特别是服务器领域对高吞吐量的需求，PCI 的带宽再次面临挑战。为此，业界在 1998 年推出了 PCI-X（PCI Extended），将总线宽度扩展至 64 位，时钟频率提升至 133 MHz，最大带宽 可达 1 GB/s。PCI-X 在服务器和高端工作站中得到广泛应用，成为 PCI 的高性能延伸。
其间，20 世纪 90 年代中期，随着 3D 游戏、三维建模和多媒体应用的兴起，图形处理对带宽的需求呈指数 级增长。传统的 PCI 总线采用共享架构，所有外设争用带宽，且其 32 位/33MHz 的规格仅提供约 133MB/s 的带宽，已无法满足显卡对大量纹理、帧缓冲数据传输的迫切需求。为突破这一瓶颈，英特尔公司于 1996 年 7 月正式推出 AGP 总线标准。AGP 并非替代 PCI，而是作为其补充，专为图形加速卡设计。它基于 PCI 2.1 规范进行扩展，采用点对点连接方式，直接连接显卡与北桥芯片，从而独享通道，避免了 PCI 的带宽争用问 题，但该技术也随着 PCIe 的成熟而被替代。
尽管 PCI 和 PCI-X 在当时取得了巨大成功，但它们基于并行总线架构的本质缺陷逐渐显现：
为解决这些问题，Intel 于 2001 年提出新一代 I/O 架构——3GIO（Third Generation I/O），并于 2003 年正 式命名为 PCI Express。PCIe 摒弃了传统的并行总线，转而采用高速串行、点对点的连接方式，每个链路由 独立的差分信号对组成，彻底摆脱了并行总线的时钟同步和信号干扰的困扰。
PCI Express(PCIe)自诞生以来，已历经二十余年发展，从最初的串行总线标准演进成为现代计算平台的核心 互连技术。这一演进路径体现了从传统并行总线向高速串行架构的革命性转变，同时通过持续提升带宽、降低 延迟、增强可靠性和可扩展性，为现代计算架构提供了高效、灵活的互连解决方案。以下为总线历史的大致发 展路径。
图70 PCIe 前计算机总线发展
作为当前应用最广泛使用的高速互联标准，PCIe 凭借成熟、标准化、高性能的架构设计，其若干特性被其他 高速总线和 Scale up 协议借鉴。主要影响在于如下方面：
下表展示了 PCIe 各版本的核心参数与技术演进。每一代 PCIe 的带宽基本实现翻倍，同时通过改进编码方式 和信号处理技术，显著提高了带宽利用率。这种持续演进不仅满足了当前应用需求，也为计算架构创新预留了 发展空间。
表12 PCIe 各版本核心参数与技术演进
| PCIe版本 | 规范发布时间 | 单通道速率 | x16 双向带宽 | 调制及编码方式 | 核心技术改进 |
|---|---|---|---|---|---|
| 1.0 | 2003年 | 2.5 GT/s | 8 GB/s | NRZ+8b/10b | 串行架构替代并行总 线，点对点连接设计 |
| 2.0 | 2007年 | 5.0 GT/s | 16 GB/s | NRZ +8b/10b | 速率翻倍，链路训练优 化，兼容性提升 |
| 3.0 | 2010年 | 8.0 GT/s | 32 GB/s | NRZ<br><br>+128b/130b | 编码效率提升，链路训 练增强，低功耗状态管 理 |
| 4.0 | 2017年 | 16.0 GT/s | 64 GB/s | NRZ<br><br>+128b/130b | 速率翻倍，电气规范强 化， |
| 5.0 | 2019年 | 32.0 GT/s | 128 GB/s | NRZ<br><br>+128b/130b | 速率翻倍，电气规范升 级， |
| 6.0 | 2022年 | 64.0 GT/s | 256 GB/s | PAM4+1b1b | PAM4调制技术，固定 大小Flit编码，低延迟 FEC |
| 7.0 | 2025年 | 128.0 GT/s | 512 GB/s | PAM4+1b1b | 光互连支持，增强 FEC，能效比优化 |
| 8.0 | 2028年（预计） | 256.0 GT/s | 1024 GB/s | 待定 | 可能探索 PAM6/PAM8 或新型 调制方案 |
PCIe 1.0 作为首个串行 PCI 标准，解决了传统 PCI 并行总线的信号衰减和时钟同步问题，通过点对点串行连 接为后续发展奠定了基础。PCIe 6.0 是 PCIe 标准诞生以来变化最大的版本，引入了 PAM4 调制和固定大小 Flit 编码，使单通道速率从 32 GT/s 提升至 64 GT/s，同时通过轻量级前向纠错(FEC)技术显著降低了误码 率和延时。PCIe 7.0 和 8.0 则进一步将速率提升至 128 GT/s 和 256 GT/s，并引入光互连支持和新型连接器 技术，为超大规模数据中心和边缘计算提供了更强大的互连能力。
PCIe 的架构设计遵循分层原则，通过事务层、数据链路层和物理层的三层结构实现了高效、可靠且易于扩展 的互连系统。这种分层设计使 PCIe 能够无缝集成到现有计算架构中，同时为未来创新提供灵活性。
图71 PCIe 分层结构 54
事务层 (Transaction layer) ：PCIe 协议栈的最高层，负责定义事务类型和流控制机制，为上层软件提供统 一的编程接口。
数据链路层（Data Link Layer）：位于事务层和物理层之间，主要负责确保数据包在物理链路上的可靠传输， 通过序列号和 LCRC 校验码实现选择性重传。
物理层（Physical Layer）：PCIe 的最底层，直接与物理媒介打交道，负责比特流的发送和接收，通常被细 分为 PCS（物理编码子层）、PMA（物理媒介接入子层）和 PMD（物理媒介相关子层）三个子层。 这种分层架构使 PCIe 能够同时满足高性能与高可靠性的需求，为显卡、存储设备、网卡等外设提供了远超传 统 PCI 的传输带宽与更低延迟，也更进一步扩展用途，实现了除外设互联外的计算节点 Peer to Peer 互联。 目前一些超节点方案即使用 PCIe P2P（PCIe fabric）技术来实现。Scale up 分层架构的详细讲解可参见前 Scale up 协议核心技术解析章节。
TLP 构造与解析：将读写请求、完成包等封装成事务层数据包(TLP)，如 Memory Write、Memory Read Request 等。TLP 包含头信息和有效载荷，头信息定义了事务类型、地址、源/目标标识等关键信息。这种 封装方式使事务层能够抽象化底层物理链路的复杂性，为操作系统和驱动程序提供与传统 PCI 相似的编程模 型。
流量控制机制：采用信用(Credit)机制确保发送方不会因接收方缓冲区溢出而导致数据丢失。每个接收端维护 发送端的信用计数器（配合链路层实现），发送方只有在获得足够信用时才能发送数据，从而实现无损传输。 这种机制在 PCIe 6.0 中进一步优化，引入了固定大小的流控制单元(FLIT)，提高了带宽利用率。
事务排序规则：定义了不同类型的内存、I/O 和配置事务之间的排序规则，保证系统的一致性和正确性。例如， Memory Read 完成包必须按请求顺序返回，而 I/O 写操作可能允许乱序完成。这种排序机制确保了多设备 并发访问共享资源时的数据一致性。
地址路由方式：支持基于地址、ID 和隐式等多种路由方式，使 PCIe 能够灵活适应不同拓扑结构。在树状拓 扑中，路由通常由根复合体控制；而在点对点（Peer to Peer）拓扑中，路由可能由交换机或终端设备自主 完成。这种灵活性使 PCIe 能够支持从简单的台式机到复杂的服务器集群的各种应用场景。
数据包可靠性：为每个 TLP 添加序列号和 LCRC 校验码，形成数据链路层数据包(DLLP)。序列号用于追踪 数据包顺序，LCRC 用于检测数据包传输过程中的错误。这种机制确保了即使在物理链路上可能出现比特错 误或数据包丢失的情况下，数据链路层仍能保证数据的完整性和正确性。
ACK/NAK 协议：接收方通过发送 ACK(DLLP)确认正确接收的数据包，或通过 NAK(DLLP)请求重传错误 或丢失的数据包。这是一种选择性重传机制，仅重传出错或丢失的数据包，提高了传输效率。
流量控制扩展：除事务层的信用机制外，数据链路层还提供额外的流量控制机制，如流量控制信用计数器和流 控制状态机，确保链路不会过载。数据链路层的流量控制与事务层的信用机制形成互补，共同保障了数据传输 的可靠性。
错误恢复机制：支持多种错误恢复策略，如自动重试、链路重训练等，确保在物理链路出现不稳定时，系统仍 能保持高可靠性。这些机制在 PCIe 6.0 中进一步增强，通过低延迟 FEC 技术实现了更高效的错误检测与纠 正。
数据链路层的核心目标是为事务层提供一个可靠、有序、无差错的通信通道。通过强大的错误检测和恢复机制， 数据链路层确保了 PCIe 在各种应用场景下的高可靠性。
物理层是 PCIe 的最底层，直接与物理媒介打交道，负责比特流的发送和接收。它通常被细分为三个子层： PCS（物理编码子层）、PMA（物理媒介接入子层）和 PMD（物理媒介相关子层）。这三个子层协同工作， 实现了 PCIe 的高速串行通信。
PCS 层负责将事务层和数据链路层的并行数据转换为适合物理传输的格式。其核心技术包括：
PCS 层的特点是实现了逻辑与物理的映射，通过编码技术将高可靠性要求的数据包转换为适合高速传输的格 式，同时保留了足够的冗余信息用于错误检测和恢复。
PMA 层包含串行器/解串器(SerDes)，负责将并行数据转换为高速串行比特流。其核心技术包括：
• 串并转换：在发送端，将来自 PCS 的并行数据流转换为高速串行比特流；在接收端，将接收到的高速串
行比特流转换回并行数据流供上层处理。PMA 层的 SerDes 技术是实现 PCIe 高速传输的核心。
6.0 中，PMA 层进一步优化了均衡技术，支持更长距离的信号传输。
PMA 层的核心功能是实现高速串行通信的基础，通过 SerDes 技术将数据速率提升至传统并行总线难以企及 的水平，同时通过 CDR 技术解决了时钟信号传输的难题。
PMD 层直接适配物理介质，是物理层中最接近实际传输媒介的部分。其核心技术包括：
PMD 层的设计高度依赖于所使用的物理介质，通过优化模拟信号特性，使 PCIe 能够在不同传输距离和环境 条件下保持高可靠性和高带宽。这种设计使 PCIe 能够灵活适应铜缆、光纤等多种物理传输介质。
PCS、PMA 和 PMD 三个子层通过紧密的协作共同实现了 PCIe 的高速串行通信：
这种分层设计使 PCIe 能够灵活适应不同的物理介质和传输环境，同时保持协议栈的统一性和兼容性。PCS、 PMA 和 PMD 层的协同工作确保了 PCIe 能够在从几厘米到几十米的多种距离范围内实现高速、可靠的串行 通信。
PCIe 系统启动后，首先由 BIOS/OS 完成初始化，核心是设备枚举与配置空间配置： 枚举阶段：BIOS/OS 通过 PCIe 根复合体（Root Complex）发起扫描，识别总线上所有 PCIe 设备（如显 卡、网卡），为每个设备分配唯一的总线号、设备号、功能号（BDF），建立设备拓扑结构。
配置阶段：每个 PCIe 设备都有独立的配置空间（用于存储设备信息），初始化时 BIOS/OS 读取配置空间的 设备 ID、厂商 ID 等信息，确定设备类型与功能，同时配置设备的传输参数（如链路宽度、速率），完成设备与 根复合体的链路协商，确保设备正常通信。
初始化完成后，PCIe 通过地址映射实现设备间寻址，分为两步： 地址分配：BIOS/OS 为每个 PCIe 设备分配独立的物理地址空间（避免地址冲突），该地址空间被映射到系统 的物理内存地址域。
地址解析与访问：当 CPU / 其他设备需要访问 PCIe 设备时，先将目标设备的虚拟地址转换为系统物理地址， 根复合体根据物理地址中的 BDF 信息，定位到目标 PCIe 设备，再通过 PCIe 链路发起访问请求，实现数据 交互。
在 PCIe 应用于 Scale up 领域中时，常使用 Peer to Peer 工作模式，也称为 P2P 对等模式，该模式的核心 是 PCIe 设备（GPU）间无需 CPU / 根复合体中转，直接通过 PCIe Switch 传输数据，简化流程、降低时延， 工作过程简要如下：
PCIe P2P 作为较为成熟的 Scale up 技术，使用该技术构建的超节点在当前超节点架构中具备一定代表性， 可实现统一编址、内存语义访问和低时延等超节点关键特性，但互联带宽受到 PCIe 自身带宽的限制，以及不 支持 Cache 一致性等，和 NVLink 相比还有较大差距。
CXL（Compute Express Link）是一种建立在 PCIe 物理和电气规范之上的开放互连技术，旨在解决异构 计算中的内存一致性、资源共享和池化问题，所以和 PCIe 章节放在一起进行说明。与 PCIe 相比，CXL 不 仅关注带宽和延迟，更强调内存一致性、资源共享和安全性，为高性能计算和 AI 应用提供了更强大的互连解 决方案。
CXL（Compute Express Link）是由 CXL 联盟（Intel 主导，主要大厂均参与）制定的开放高速互连标准， 核心目标为保持 PCIe 物理层兼容的前提下，实现计算、内存、存储资源的高效协同与池化，解决 AI/HPC 时 代“内存墙”与资源孤岛问题。主要解决 PCIe 仅作为数据通道，不能提供从内存资源协同的问题，即解决了 远端内存的硬件缓存一致性、直接 Load\Store 访问、池化共享问题。
图72 CXL 版本发布时间线 55 如下图，CXL 技术的出现，驱动计算架构从“单机集成”迈向“资源服务化”转变，实现三大突破： 资源解耦池化：内存（Type 3 设备）、计算（Type 2 加速器）可跨服务器构建共享池，单机内存瓶颈被打破， 资源利用率提升； 异构协同简化：CPU 与 GPU/FPGA 通过硬件一致性无缝协作，消除数据拷贝与软件同步开销，训练通信延 迟显著降低；
分解式架构落地：计算、内存、存储独立扩展与动态调度，优化数据中心 TCO，支撑云原生与大模型弹性需 求。
图73 使用 CXL 技术实现的计算资源池化 56
缓存一致性是多核与异构计算架构的效率基石，硬件层面通过协议（如 MESI）实时同步各处理单元私有缓存 中共享数据的状态：在多核系统中，当任一核心修改数据，其他核心的 Cache 旧副本自动失效或更新，确保 所有处理器看到统一、最新的内存视图。一致性的核心价值在于：
M（已修改，Modified）：本地处理器已经修改缓存行，即是脏行，它的内容与内存中的内容不一样，并 且此 cache 只有本地一个拷贝(专有)；
E（专有，Exclusive）：缓存行内容和内存中的一样，而且其它处理器都没有这行数据； S（共享，Shared）：缓存行内容和内存中的一样, 有可能其它处理器也存在此缓存行的拷贝； I（无效，Invalid）：缓存行失效, 不能使用。
图74 MESI 协议
MESI 状态迁移与操作处理
MESI 协议中，Snoop（窥探）是保障多核心/多设备缓存一致性的核心机制，核心作用是监控总线或互联链 路中的缓存操作，同步各核心/设备的缓存行状态。当某核心对缓存行执行读写、修改操作时，Snoop 会广播 该操作至所有相关核心及设备，各核心原理是根据自身缓存行的 MESI 状态（修改态、独占态、共享态、无 效态）响应，确保同一缓存行在不同节点中状态一致，避免脏数据读取、数据不一致等问题。
在 CXL 所涉及的多 CPU、多 TYPE 1\2\3 设备协同场景中，Snoop 是实现全局缓存一致性的基础，但其无 差别的 Snoop 广播极易产生大量的无效窥探、占用链路带宽、增加时延，所以需要对传统 Snoop 广播进行 改进。
在 Intel 的早期 CPU 设计中，在多核场景，同样需通过 Snoop 机制保障缓存一致性（遵循 MESI 协议），但 大量无效窥探（如访问不同缓存行、无数据依赖的窥探请求）会占用 CPU 内部互联链路带宽、增加核心处理
开销，影响低时延传输性能。同样在多路（多 CPU）服务器中，为了保持各个 CPU 插槽间缓存（Cache） 的一致性，系统需要通过互联链路（如 Intel 的 UPI 或 AMD 的 Infinity Fabric）发送监听请求（Snoop Requests）。
随着核心/CPU 数量增加，广播式的监听会产生巨大的通信流量，导致互联带宽被大量垃圾流量占据，增加访 问延迟。
Intel 在 Nehalem 架构时引入了 Snoop Filter（SF）机制，在 CPU 互连子系统中增加硬件目录（Directory）， 即 Snoop Filter。其充当一个目录，记录了哪些缓存行存储在哪个 CPU 中，当发生内存访问时，它能精确判 断是否需要跨 CPU 监听，从而避免无效的广播。此架构后续不断演进，在最新至强 6 （Intel Xeon 6）CPU 一致性保证机制中仍占据关键地位。
SF 的关键作用和价值在于：
Intel 宣称优化的 Snoop Filter 可以过滤掉 90% 以上 的无效监听。这意味着 CPU 不再需要等待每个远端 CPU 返回确认信号，直接将本地访问延迟降低，对性能的提升有极大帮助。
CXL（Compute Express Link）技术的诞生，核心是为解决异构计算兴起带来的设备互联瓶颈。随着 AI、 HPC 等场景发展，CPU 需与 GPU、FPGA 等加速器高效协同，但传统 PCIe 协议存在带宽不足、时延较高、 缓存一致性难以保障的短板，且不同厂商加速器接口不统一，导致设备互联兼容性差、资源利用率低。解决的 思路也很清晰：在 PCIe 的基础上，引入多核 CPU 的 Cache 硬件一致性机制，使用 PCIe 数据报文来承载 Snoop 功能，使远端内存（TYPE 1、2、3）能和 Host 保持缓存一致性。主要体现在：
CXL 总线在 PCIe 总线上针对一致性访问需求进行了如上改进，并保持了对 PCIe 总线的兼容，修改后的总 线命名为 Flex 总线。
图75 Flex Bus57
总线关键特性：
图76 CXL 使用和 PCIe 一样的分层设计 58
表13 CXL 协议对 PCIe 协议的扩展和复用情况
| PCIe 层级 | CXL 层级 | CXL 关键技术复用细节 |
|---|---|---|
| 物理层 (PHY) | 全复用 | • 电气特性、连接器、速率（PCIe 5.0/6.0 完全复用<br>• PAM4 信令、FEC、SerDes 等完全继承<br> |
| 数据链路层 | 大部分复用 | • 链路训练流程扩展协商字段（序列中新增 CXL Capability 标识）<br>• ACK/NAK、CRC、流量控制和 PCIe 机制保持一致<br> |
| 事务层 | 协 议 多 路 复 用 | • CXL.io：直接复用 PCIe TLP 格式（配置/中断/DMA），OS 驱动零 修改<br>• CXL.cache/mem：定义新型 TLP（含 Snoop 请求、内存 Load/Store 等）<br>• 通过 TLP 头中 Format 字段区分流量类型（PCIe TLP 及 CXL TLP）<br> |
按 CXL 接入设备的主要功能，设备按 TYPE 1、2、3 分为 3 类，定义如下：
图77 CXL 设备分类 59
图78 CXL 各版本发布时间及关键规格 60
图79 CXL Fabric61
当多个 Host 和 Device 通过 CXL Switch 组成 Fabric 时，整个 Fabric 的管理需要一个专属的管理组件 FM （Fabric Manager）进行管理。如上图，Fabric 由一个或多个互联的 CXL Switch 组成。Switch 端口可连 接至 CXL 主机（Host）端口或 CXL 设备（Dev）。
Fabric 管理器（FM）在 CXL 网络（Fabric）中不可或缺，但角色可以被其他具备类似管理功能的组件替代。 FM 可通过带外对 Switch 网络进行管理。FM 组件也被其他 Scale up 协议借鉴，如 UB 的 UBFM。
FM 的主要功能：
2025 年 11 月发布的基于 PCIe 7.0 的 CXL 4.0 规范，除速率提升一倍以外，在原 3.0 规范基础上继续继续了 特性增强，以下对 CXL 3.0 及 4.0 规格进行一些解析：
直至 CXL 3.0 协议发布，CXL 才进入了成熟期。CXL 3.0 于 2022 年 8 月发布，基于 PCIe 6.0 物理层(64 GT/s)，其核心创新包括：
图80 Host 访问 Accelerator（GPU）过程 62
DCOH：Device Coherency Operation Handler，设备端一致性操作处理器，执行 Snoop Filter 管理（分 配/释放/Victim 流程），处理 BISnp/BIRsp 交互，生成 Cmp/MemData。
Snoop Filter (SF)：侦听过滤器，位于设备端的轻量级元数据结构，记录哪些主机缓存持有设备内存副本。 是 CXL 协议的关键性设计。SF 因容量限制，记录满了以后如果需要记录新的信息，就要清理旧的记录（类 似于老化）。要被清理的记录对应的，在 Peer Cache 中被修改的数据将写回至内存，同时标记 Peer Cache 中的数据为 Invalid，再在 SF 中消除该条记录。
HA：Home Agent，主机归属代理，CPU 中负责特定地址范围一致性的硬件模块。 Peer Cache：对等设备缓存，Fabric 拓扑中其他设备的缓存，此次可为 Host 的 Cache。 HDM：Host-managed Device Memory，主机管理的设备内存，由 OS 统一编址映射至系统物理地址空 间 上图流程解读如下：
如前述，Snoop（侦听）是缓存一致性协议中的基本机制，多核 CPU 的 Snoop 广播机制，随着核心数量增 加会产生严重的带宽瓶颈和延迟问题，严重影响性能，因此诞生了 SF 机制。
CXL 要解决的是跨系统、多节点的缓存一致性问题，Snoop 广播带来的带宽消耗和延时更加不能容忍，CXL 引入 SF 机制，消除了一致性判断所要进行 Snoop 广播，仅针对包含了设备内存数据的 Peer Cache 进行定 向通信，极大优化了 Snoop 机制。但因芯片成本原因导致 SF 容量有限（SF 容量大占用芯片的面积也大）， 工作过程中 SF 内容需根据访问目的进行不断刷新，如图解，刷新过程也增加了额外的通信流量和延时。CXL 系统将在 SF 容量和性能间选取一个合理的平衡。
内存池化：CXL 支持服务器级内存池化，通过 MLD 和 Type-3 设备，多个主机可以共享同一块设备内存。 超算中心可以将内存资源集中管理，根据工作负载需求动态分配，提高了资源利用率和系统弹性。
内存共享：全局 FAM（G-FAM）特性支持跨节点内存共享，多个 GPU 可以使用共同的内存池。这为推理 所需的大规模 KV-Cache 内存需求带来了可扩展的解决方案，根据推理过程中 KV-Cache 的需求，可以动 态扩展其所需的池化内存，完成以存代算的性能提升。
在 AI 领域，CXL 有望成为类似 NVLink C2C 的用于连接 CPU 与 GPU、加速器的关键技术，显著提升访问 带宽和降低数据传输延迟，并能提供 Cache 一致性能力。
相对于当前已使用的 NVLink 5.0\ 224GT/s SerDes 传输速率，CXL 3.0\ 64GT/s 的速率存在代差。即便 到了 CXL 4.0\128GT/s 的速率仍然和 NVLink 存在差距。得益于 PCIe 广泛的生态，未来基于 PCIe 的 CXL 用于 CPU-GPU，或 GPU-GPU Scale up 互联仍然存在较大的可行性。
CXL 是构建分解式数据中心和云原生架构的核心技术，使计算、内存和存储资源可以独立扩展和按需组合。 CXL 支持服务器分解和池化，使原服务器独享的资源（如 CPU、GPU、内存、网卡、存储等）可以通过池 化，根据应用需求灵活地进行组合，很好地契合了云原生架构。
PCIe 和 CXL 代表了互连技术的两个不同维度：PCIe 关注物理传输的极限性能，而 CXL 关注逻辑层面的资 源协同与一致性。两者的结合将为未来计算架构提供更强大的互连能力，推动计算性能的不断提升和能效比的 优化。
从 PCIe 1.0 到 8.0，带宽持续翻倍，从最初的每 Lane 2.5GT/s 到预计的 256GT/s 以上，同时通过不断改进 的编码方式（8b/10b -> 128b/130b，PAM4 -> PAM6?）和信号处理技术（均衡、预加重、FEC 等），显 著提高了带宽利用率和信号完整性。其三层架构（事务层、数据链路层、物理层）设计合理，各层职责明确， 相互解耦，为现代计算平台提供了高效、可靠、可扩展的互连基础。
CXL 3.0 通过多对多连接和增强型一致性协议，使内存共享和池化成为可能；而 CXL 4.0 则通过通道捆绑、 CXL Fabric 和光互连支持，进一步扩展了内存共享的范围和能力，为超大规模计算架构提供了坚实基础。两 者均基于 PCIe 物理层构建，但通过协议扩展实现了内存一致性与资源共享功能。
面向未来，PCIe 和 CXL 将继续协同演进，PCIe 将不断突破物理传输的极限，如更高的速率（PCIe 8.0 的 256 GT/s）、更远的传输距离（百米级光互联）和更低的延迟；而 CXL 将不断扩展资源协同的边界，如更复 杂的内存拓扑（CXL Fabric）、更强大的一致性协议（G-FAM）和更广泛的安全保护机制。
对于 AI、HPC 等高性能计算领域，CXL 或将成为连接 CPU、GPU 和内存扩展器的关键技术，支持超大规 模模型的训练和推理；而对于传统数据中心和企业应用，CXL 将提供足够的内存共享和池化能力，优化资源 利用率。两者的协同应用将使计算架构更加灵活、高效和可扩展，为数字经济时代的创新提供坚实基础。
GLink 为新华三公司为满足超节点互联要求，自行研制的 Scale up 互联方案。本章节旨在介绍 GLink 技术 方案，该技术方案专为高性能计算、人工智能训练和推理、大数据处理等场景，加速卡(如 GPU)超节点架构 中跨芯片高带宽、低时延、高可靠的通信需求而设计，也适用于对数据传输效率和系统扩展性有严格要求的其 他场景。
GLink 旨在提供智能、灵活、高效、可靠的加速卡卡间互联技术，协同多个加速卡的算力以及域内互联的资 源池，使集群像一个超级加速卡一样工作。通过互联实现加速卡智算集群性能的纵向扩展，为大模型训练、推 理以及高性能计算等 AI 应用场景提供互联技术支撑。基于此，GLink 互联技术的核心目标：
支持 Scale Up 域内多种加速卡互联方式：支持直连拓扑，为加速卡间搭建直接的、低延迟的通信路径，不需 要交换芯片参与，能降低系统整体成本与功耗，简化物理布线与系统管理流程；支持基于交换芯片互联的单级 拓扑，在交换拓扑架构下，支持源加速卡与 Scale Up 域内任意目的端加速卡的全向通信，无需经过主机 CPU 或者其他加速卡绕转；支持机柜间的背靠背互联拓扑，通过此背靠背互联，系统可将 2 个机柜聚合为一个统 一的 Scale Up 高带宽域；支持两级交换的互联拓扑，通过两级交换的互联拓扑突破单机柜或双机柜直连架构 的规模瓶颈，构建能支持更多加速卡计算节点的全互联高带宽域。有关互联拓扑的具体示例，请参见互联拓扑 章节。
基于 Scale Up 互联规模必然会继续扩大的需求，GLink 互联技术支持通过二级 Switch 互联架构实现网络规 模扩展，最大可支持 2K 规模的加速卡 Scale Up 互联网络，满足超大规模计算集群的互联需求。同时基于二 级 Switch 互联设计，GLink 互联技术可以支持从 8 卡互联规模平滑扩展至千卡级互联，适配不同阶段的算力 需求增长。
GLink 互联技术在二层网络架构上实现技术创新，通过数据细分确保数据包在 HASH 计算后的负载均衡，避 免因 HASH 极化导致的链路利用率不均问题；采用端到端 Credit Base 流控和点到点 Credit Base 流控， 双维度 Credit 流控机制确保数据传输无丢包；以及通过链路重传、端到端重传、链路故障自动隔离等技术提 升网络健壮性。
图81 1024 卡互联示意图
为实现加速卡间的协同计算和互联通信的高效，在通信语义方面，GLink 互联技术支持内存语义和通道语义， 以应对加速卡在不同应用场景下多样化的内存交互需求，其目标是在统一的互联架构上，为不同粒度的内存操 作提供最优化的执行路径。
内存语义场景：GLink 互联技术与系统加速卡通过全局虚拟地址空间与低延时传输协议的协同，实现了细粒 度数据访问的高效、可靠，提升并行算法的执行效率，降低开发者的编程复杂度。
通道语义场景：GLink 互联技术为实现批量数据的高效移动提供一条硬件路径，将一块大规模、连续的内存 区域作为一个整体，从一个源高效地拷贝至一个目的，通过“传输-计算”重叠，系统可最大化利用硬件资源， 提升整体效率。
为支持加速卡间高效互联与极致通信带宽利用率需求，GLink 互联技术方案支持细粒度的逐链路 Hash 负载 均衡，以及端到端基于 Credit-Based 的流控机制，通过“负载均衡+动态流量控制”的协同作用，GLink 互联技术实现了对网络资源的主动式、无拥塞管理，提升了互联网络的传输效率，大模型训练构筑了一个高效、 可靠的数据传输平面。
逐链路 Hash 负载均衡：GLink 互联技术通过逐链路 Hash 算法，将数据流动态解构为细粒度数据单元，均 匀地喷洒到所有可用物理链路上，确保了每一条链路带宽都能被充分利用，消除了因流量不均而产生的网络热 点，同时 GT-Link 和 GT-Fabric 进行深度协同，严格保障数据接收顺序与发送顺序一致，确保加速卡接收 保序。
图82 逐链路 Hash 负载均衡
端到端 Credit-Based 流控：针对传统网络中因拥塞导致的丢包与延迟抖动问题，GLink 互联技术通过将网 络资源管理从“事后补救”变为“事前规划”，通过源端发送数据请求和目的端根据当前处理能力，向源端授 予 Credit 方式，进行带宽分配，从数据源头精确管控数据注入速率，确保网络传输不会出现因缓存溢出而导 致的延时增大或者丢包问题。
|无拥塞|
|---|
GT-Fabric 0
|GT-Link 1|
|---|
GT-Link 0
|GT-Fabric 1|
|---|
图83 端到端 Credit-Based 流控
要充分发挥超节点算力，可靠性、稳定性是决定系统计算效率及成本的重要指标之一，为应对这一挑战，GLink 互联技术设计了分层可靠协同机制。
GLink 互联技术物理层支持 FEC(RS272/RS544)，作为保障数据完整性的第一道防线，在接收端自动检测 并纠正传输过程中发生的特定数量的比特错误。当前出现无法纠错的数据时，会在接收端产生错误报文，GLink 互联技术支持链路层点到点重传，保证链路误码等错误报文，通过链路重传快速恢复。
|GT-Link|
|---|
RSFEC
SerDes
SerDes
RSFEC
Get CWID 10 Get UE Codeword,send NAK CWID, drop following Codeword
L1重传
|GT-Fabric|
|---|
GLink 互联技术，针对硬件链路故障场景，设计了完整的处理机制，确保在单条或多条物理链路发生故障时， 系统能够自动、快速地实现路径切换。
链路层发现链路异常后，会立即进行自动隔离，同时网络层会自动整网同步故障信息，后续的数据转发会被硬 件自动、无缝地引导至其他可用链路上。
在传输层，GLink 互联技术支持端到端重传机制，作为其分层可靠性架构中的最终保障层。该机制与下层的 链路级故障隔离、链路重传等功能构成了多层级可靠性协同体系：链路层重传高效解决绝大多数链路瞬态错误， 而端到端重传则专注处理极罕见的异常场景（如硬件链路故障）。当发生此类故障时，系统首先通过链路自动 隔离机制实现快速切换，再通过端到端重传完成数据无损恢复，从而确保即使在最极端异常情况下，网络仍能 保障 100%的数据可靠交付，为关键业务提供终极可靠性保障。
端到端报文重传
|GT-Link|
|---|
|GT-Fabirc|
|---|
|GT-Link|
|---|
Packet Tx
SerDes
One Link Down
SerDes
Pack Packet
SerDes
SerDes
Drop ID 12 Drop ID 13 Drop ID 14 Drop ID 15 Drop ID 16
Other link normal
图86 端到端重传
通过从物理层到事务层的多个层级上部署系统性的容错与故障处理策略，GLink 构建了一个具备高度韧性的 通信架构，将可靠性从单一的链路属性提升为整个系统的架构级能力。它确保了即使在组件不可避免发生故障 的情况下，超节点系统依然能够维持稳定运行。
图87 多层级可靠性保障
为应对大规模分布式 AI 应用中的通信瓶颈，GLink 引入了创新的集合通信加速能力。该技术通过将部分集合 通信计算任务（如 Reduce、All-Reduce、Broadcast）从加速卡节点卸载至网络交换芯片，实现通信范式 的根本性变革。
图88 集合通信
集合通信在网计算核心价值：
这一机制从根本上重塑了网络的角色：交换芯片从一个被动的数据管道，转变为一个主动参与计算的协同处理 器。这不仅有效降低了通信延迟、提升了有效带宽，更将网络从基础设施的“成本中心”转变为赋能系统算力 提升的“价值中心”，为千卡级集群的极致扩展提供了关键支撑。
互联拓扑
为满足小规模 AI 集群对成本与效率的极致追求，GLink 互联技术提供灵活的直接互联拓扑。这类拓扑的核心 目标是为加速卡间搭建直接的、低延迟的通信路径，其核心优势：
受限于加速卡芯片封装面积与 I/O 引脚数量等物理条件，直接互联所能支持的加速卡数量存在明确上限（例如 典型场景下最多支持 8 颗加速卡互联）。
GPU
GT Link
GT Link
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 GT Link
12345678
GPU
GTLink
GPU
1 2 3 4 5 6 7 8 GT Link
12345678
GPU
GTLink
GPU
8 7 6 5 4 3 2 1 Link GT
8 7 6 5 4 3 2 1 Link GT
GPU
GPU
图89 加速卡直连拓扑
GLink 互联技术支持通过单级互联拓扑，构建大规模且高效的 Scale Up 集群拓扑网络。该拓扑采用多交换芯 片协同架构，在逻辑上构建统一的交换层，实现加速卡节点间高效、灵活的数据转发与互联。
其核心设计通过模块化交换单元的组合，实现系统规模的线性扩展，具备优异的扩展能力。在通信过程中，任 意两个加速卡节点间建立连接后，数据可在预设的高带宽路径中高效传输，从而最大限度利用加速卡端口的完 整 I/O 带宽。由于数据包仅需经过单次交换转发即可到达目的节点，端到端通信延迟可控制在微秒级。结合硬 件级的流量调度机制，系统能够为每个加速卡通信分配专属带宽资源，确保高效的通信效率，满足高并发计算 场景的需求。
单级互联拓扑通过交换芯片直连架构，实现了带宽最大化、延迟优化和线性扩展性的三重突破，为构建下一代 高性能计算网络提供了坚实的技术基石，适用于需要超大规模加速卡互联的 AI 训练、科学计算和实时数据分 析等前沿领域。
|GPU0
1 2 3 M
GPU1
1 2 3 M
GPU N-2
1 2 3 M
GPU N-1
1 2 3 M
……
Link Link Link Link
|Fabric 0|
|---|
Fabric 1
|Fabric 2|
|---|
|Fabric M|
|---|
POD
…… …… …… ……
……|
|---|
图90 多加速卡单级互联拓扑
为突破单机柜在供电、承重与空间上的物理限制，同时适配现有数据中心环境，GLink 互联技术提供支持背 靠背互联拓扑。该架构旨在将 Scale Up 的高性能域无缝扩展至多个机柜，构建逻辑统一的跨机柜紧耦合高带 宽计算域。
背靠背互联拓扑架构关键优势：
GLink 的背靠背互联拓扑，在物理限制与算力需求之间取得了平衡。将 Scale Up 的优势成功延伸至多机柜环 境，为在标准数据中心内部署高效能、紧耦合的 AI 计算集群提供了关键且可行的技术路径。
图91 多加速卡背靠背互联拓扑
|GPU0
Link|
|---|
|GPU N-2
Link|
|---|
|GPU N-1
Link|
|---|
……
Link
…… …… …… ……
1 2 3 M
1 2 3 M
1 2 3 M
1 2 3 M
|Fabric 0|
|---|
|Fabric 2|
|---|
|Fabric M|
|---|
……
Fabric 1
POD
|Fabric 0|
|---|
|Fabric 1|
|---|
|Fabric 2|
|---|
|Fabric M|
|---|
……
|GPU N|
|---|
|GPU N+1|
|---|
|GPU|
|---|
|GPU 2N-1|
|---|
……
为突破单颗交换芯片在端口密度与转发带宽上的物理极限，满足千卡级加速卡计算集群对全互联高带宽域的迫 切需求，GLink 引入支持两级互联拓扑。此架构标志着从机柜级 Scale Up 向数据中心级 Scale Up 的关键演 进，是满足未来更大规模 Al 模型及复杂并行计算任务需求的核心网络基石。
在此架构下，通信路径根据加速卡的相对位置而确定：Pod 内通信，数据流仅在单个接入交换机内部完成转 发，实现一跳的超低延迟通信；Pod 间通信，数据流需要通过三个交换芯片转发完成。尽管 Pod 间通信引入
了额外的跳数，但 GLink 通过其高带宽互联技术与低延迟交换芯片，确保其在规模化扩展中仍能保持极高的 效率。
GLink 支持的细粒度逐链路负载均衡机制，以及端到端基于 Credit-Based 的流控机制，实现了两级互联网 络链路带宽均衡利用，消除了流量热点，是保障超大规模网络无阻塞运行的关键。
GLink 的两级互联拓扑，通过其清晰的分层架构与智能的流量管理机制，将 Scale Up 的边界从单个机柜扩展 到数据中心级别。它代表了高性能网络技术在 AI 驱动下的前沿演进，为构建超大规模 AI 集群提供了坚实且面 向未来的互联解决方案。
||GPU0
Link|
|---|
1 2 3 M
|GPU1
Link|
|---|
1 2 3 M
|GPU N-1
Link|
|---|
1 2 3 M
……
|Fabric 0|
|---|
|Fabric 1|
|---|
|Fabric 2|
|---|
|Fabric M|
|---|
POD
…… …… ……
……|
|---|
|POD X|
|---|
||GPU0
Link|
|---|
1 2 3 M
|GPU1
Link|
|---|
1 2 3 M
|GPU N-1
Link|
|---|
1 2 3 M
……
|Fabric 0|
|---|
|Fabric 1|
|---|
|Fabric 2|
|---|
|Fabric M|
|---|
POD
…… …… ……
……|
|---|
|Fabric 0|
|---|
|Fabric 1|
|---|
|Fabric 2|
|---|
|Fabric X|
|---|
……
图92 多加速卡两级互联拓扑
GLink 互联技术通过创新的“端侧+网侧”协同设计，为下一代 AI 基础设施构建高带宽、低延迟、无阻塞且 具备大规模扩展能力的互联底座。
GTLink 为 GLink 互联技术加速卡端侧高速互联接口，负责芯片级的高速数据收发与协议处理。 GTFabric 为 GLink 互联技术网侧高性能交换芯片，支持拥塞控制、自适应路由、负载均衡、在网计算等功 能。 GLink 通过端网协同为加速卡提供智能、灵活、高效、可靠的卡间互联技术解决方案，高效协同多个加速卡 的算力以及域内互联的资源池，赋能合作伙伴快速打造具有竞争力的智算产品。
图93 GLink 互联技术
GLink 技术栈遵循分层化设计准则，构建了一个由物理层、链路层、网络层、传输层和事务层组成的完整通 信体系。这种清晰的分层架构不仅定义了严格的功能边界，更通过各层级的高效协同，为整个互联系统提供了 坚实的结构性基础。
事层务
网层络
链层路
物层理
图94 GLink 技术栈
物理层是 GLink 互联技术栈的最底层，承担着数字逻辑与模拟信号之间转换的职能。它通过在物理介质上， 高效、可靠地传输与恢复原始比特流，向上为链路层提供数据收发服务，向下通过高速 SerDes 串行通道与 对端设备建立物理连接。支持 56G、112G 及 224G 等高速 SerDes 串行通道，为持续提升单端口及系统聚 合带宽提供底层支撑。集成 FEC（前向纠错）编解码，支持 RS(544, 514) 与 RS(272, 257) 等，能够自动检 测并纠正传输过程中产生的比特错误，提升链路稳定性。
链路层位于物理层与网络层之间，为网络层提供点到点的可靠通信。链路层主要功能如下：
接口链路状态管理：监测与维护其所属端口的连接状态，将链路状态变化上报，供上层设备驱动软件或网络管 理软件处理。迅速感知链路状态异常事件（如 Down），为路由收敛、故障切换提供决策依据。
数据包发送与接收：数据发送方向，为数据包添加链路层头和 CRC 后，交付物理层发送；数据接收方向，从 物理层接收的数据，在完成 CRC 校验后，剥离链路层头和 CRC，将数据包传递下一级处理。
CRC 校验：发送端计算添加 CRC 校验码，接收端重新计算校验码并比对。CRC 校验失败后触发链路重传 机制，确保错误数据不会被向上传递。
信用流控：根据接收端缓存能力生成“信用”，发送端必须持有信用，才能发送数据，从而避免接收端缓存过 载而导致的丢包。
链路重传：发送端在本地缓存已发送但未被确认的数据副本，当数据出现 CRC 错误或者丢失，链路层会自动 启动重传。
网络层位于链路层与传输层之间，它建立在链路层提供的可靠单跳传输能力之上，是互联架构的“指挥中心”， 负责将数据从源节点，按照规划路径准确、高效地送达目的节点。
拓扑发现：网络启动或设备状态发送变化（如新增节点、链路故障）时，系统会自动探测并学习设备间互联的 物理结构(即哪个端口连接了哪个设备)，实时绘制出一张“网络地图”。
路由管理：不同设备间同步互联拓扑关系后，会为探测到的目的节点生成转发路由表，并自动下发到芯片硬件 中。 基于硬件自动的拓扑发现和路由生成功能，可以支持新加速卡节点的自动识别和无缝加入，极大简化了运维。 当发生故障时，能毫秒级感知并重新计算路径，实现业务的快速自愈，保障任务不中断。 负载均衡：通过将数据流动态拆分为更小的数据单元，并对每个单元进行独立哈希，将其动态地“喷洒”到所 有可用的物理链路上。确保每条链路带宽都能被充分利用，消除因流量不均而产生的网络热点。 保序传输：GTLink 和 GT Fabric 深度协同，基于端口+通道，严格按照原始顺序向加速卡传输数据。
图95 保序传输示例
事务层是 GLink 互联技术栈中直接与加速卡计算生态交互的最高层次，它承担着 NOC 总线协议与网络事务 报文之间双向转换的核心职责。并管理网络事务报文的端到端可靠交付。
为适应不同加速卡内部互联架构的差异化需求，端侧 GTLink 可以支持不同 NOC 总线的事务转换，内存语 义场景，以 AXI 总线为例：
加速卡发送方向：AXI 总线输入事务(如内存访问、原子操作等)->打包成网络报文->由 Tx Path 数据通路发 送出去。
加速卡接收方向：Rx Path 输入数据->从 Header 中解出通道信息->恢复成事务输出到 AXI 总线。 即事务层在发送端将加速卡发起的内存访问、原子操作等转换为网络事务报文；在接收端则执行逆向转换，将 网络报文还原为加速卡可执行的指令格式，从而实现跨节点内存访问操作。
|Ctrl|
|---|
AXI Pack/Unpack 0
AW+W pack
S AW&W
B unpack
S B
TX ENC
AR pack
S AR
TX MUX
R unpack
S R
RX FIFO RESP
RX FIFO REQ
RX DEC
AW+W unpack
M AW&W
B pack
M B
AR unpack
M AR
R pack
M R
AXI Port1 AXI Pack/Unpack
Config
TX
RX
图96 AXI 和数据报文转换示例 通道语义场景，以 AXI-Stream 为例： 加速卡使用专用的拷贝引擎，通过 AXI-Stream 通道，将数据从一个加速卡的显存直接、大批量地拷贝至另 一个加速卡的显存；避免对数据块进行不必要的切分和重组，可以使用大包直接传输以提升网络有效载荷率。
加速卡总线事务转换成网络报文格式示例如下，其中 GTLink Header 为精简网络头，包含目的加速卡 ID 和 通道信息，用于网络转发使用，Ext Header 为总线事务信息，目的端根据此信息将数据报文恢复成事务输出 到总线。
| GT Link Header | Ext Header | Payload |
|---|
除了协议转换，事务层还提供端到端控制功能，这些功能在网络层和链路层之上，提供了最终的可靠性保障。
端到端 Credit-Based 流控：加速卡发送端 Link 根据队列状态向目的端申请 Credit，目的端根据接收能力向 源端分发 Credit，通过该机制控制源端发送的数据量在 GT Fabric 和目的端加速卡处理的能力范围内，避免 GT Fabric 和目的端加速卡出现拥塞情况。
端到端重传：尽管链路层重传解决了大多数单跳瞬时错误，但系统仍可能面临诸如硬件链路永久性故障、交换 机故障等罕见异常场景。针对此类故障场景，GTLink 和 GT Fabric 组成的系统可以进行路由自动隔离，切 换使用正常链路，故障窗口期间的数据丢失，可以通过端到端重传完成数据无损恢复。
当前，为应对超越单卡算力极限的挑战，国内外加速卡厂家都在通过类似 NVLink+NVSwitch 方案实现卡间 互联，然而该领域正处于起步、多种技术方案并存的阶段，技术路线演进存在不确定性。这种局面为整个行业 带来了共同的挑战与新的机遇。
将互联协议 IP 直接集成到加速卡芯片中，是初期的自然选择，但随之暴露出诸多劣势：
采用封装技术将加速卡计算芯粒与专用通信芯粒进行合封，已成为业界公认的突破性路径。芯粒封装集成的模 式，使用户可以自主选择 IO 芯粒的数量和类型，针对不同的市场区间做出不同的权衡。
|NOC|
|---|
|S e
r
d
e
s
|
|---|
U C I e / H i P i
U C I e / H i P i
GPU Main Die
IO Die
Connect to Switch
图97 芯粒互联示例 GTLink 支持通过 UCIe 标准接口，与加速卡计算芯粒在同一个封装内进行紧耦合互连。 加速卡计算芯粒：专注于执行矩阵运算、CUDA 核心等核心计算任务，无需集成复杂的高速 SerDes 和网络 协议栈，从而最大化其面积用于提升算力密度和能效。 GTLink 通信芯粒：作为专业的“网络接口芯粒”，其内部集成了 GTLink 协议栈的全部功能，包括物理层（PHY）、 控制器及与外部 GT-Fabric 交换网络对接的高速接口。 通过 UCIe 互联方案，核心价值与优势： 开放互联生态：UCIe 作为由行业巨头共同推动的开放标准，为不同厂商的“计算芯粒”与“通信芯粒”提供 了互操作的基础。GTLink 通信芯粒是一个标准化的“网络接入模块”，赋能更广泛的 AI 加速器。 解耦技术路线：如前所述，加速卡厂商可通过更换不同的通信芯粒，灵活支持 GTLink 或其他互联协议，从 根本上消除了技术路线选择风险。
极致性能：UCIe 提供了远超传统板级 PCIe 的超高带宽和超低延迟的裸片间互连。这使得加速卡计算核心与 GTLink 通信单元之间的数据交换几乎无瓶颈，确保了外部互联网络的极致性能能够无损地传递至计算核心。
工艺与成本优化：计算芯粒可采用最先进的制程节点追求极致算力，而通信芯粒可采用更适合模拟/混合信号 设计的成熟或专用工艺。在优化整体性能的同时，有效控制制造成本。
快速迭代：通信芯粒可独立于加速卡进行快速设计和流片，以适配新一代 GT-Fabric 网络或新的传输协议， 使得加速卡产品线能快速跟进网络技术的演进。
GLink 是一套完整的高性能、可扩展互联技术体系，专为满足下一代 AI 算力集群中千卡乃至万卡级加速卡的 高效协同而设计。它通过创新的技术架构与灵活的部署模式，旨在消除大规模分布式训练中的通信瓶颈，释放 集群的整体算力潜力。
GTLink 提供了两种关键的实现路径，以适应不同的产品战略与供应链需求： IP 集成模式：将 GTLink 协议 IP 内核集成到加速卡主芯片中。此路径适合追求高度集成化、对功耗和成本有 极致要求的场景，能够提供最优的片上互联效率。 IO Die/Chiplet 芯粒互联模式：GTLink 可作为独立的通信芯粒，通过 UCIe 等先进互连标准与加速卡计算芯 粒在封装内集成。此模式具有显著优势： 解耦与敏捷：使加速卡计算芯粒专注于算力提升，通信芯粒可独立快速迭代，灵活适配多种网络协议与拓扑。 工艺优化：计算芯粒与 IO 芯粒可采用最适合的半导体工艺，实现性能、成本与能效的最佳平衡。 降低行业风险：为加速卡厂商提供了互联技术路线的灵活性，规避了技术锁定风险，促进了产业生态的开放与 协作。
总结而言，GLink 互联方案提供 AI 计算基础设施的端网协同解决方案。GTLink 与 GTFabric 交换系统协同， 共同构成了从芯片到集群的完整高性能网络平面。GLink 通过其全栈技术能力、极致的性能与可靠性设计， 以及前瞻性的芯粒化部署策略，为业界提供了一个强大、开放且可持续演进的大规模互联选择。它致力于将分 散的加速卡算力资源整合为一台高效的“虚拟超级计算机”，从而加速万亿参数大模型的创新与落地，赋能 AI 产业的持续跨越式发展。
当前针对以太网的技术路线主要有 ODCC 的 ETH-X 标准和 OCP 建立的 ESUN(SUE)标准，两者相关区 别和联系可参考如下：
| 维度 | ETH-X | SUE/ESUN |
|---|---|---|
| 生态与主 导方 | ODCC社区，信通院联合腾讯等多家国内 厂商联合制定；据称可支持开放的UALink 和OISA等scale-up的协议。 | OCP基于博通的SUE是成立ESUN，旨在建立 统一的以太网交换和帧技术协议框架，SUE-T 是ESUN兼容的协议之一。 |
| 维度 | ETH-X | SUE/ESUN |
|---|---|---|
| 特点 | 通过PAXI实现极致低延迟 全局释放一致性内存模型 支持内存语义 | 通过头部压缩和多实例部署提升带宽 共享内存机制 支持单边内存语义+跨 XPU 直接内存访问 |
| 寻址能力 | 二次译址：GPU ID->编码AXI User ID-> 映射到目的 GPU 的MAC 地址 | 由 XPU 在 SUE 实例之外完成 |
| XPU指令 层接口 | 基于AXI 4和APB3优化的PAXI 数据和控制通过DAXI、CAXI区分 | 信号线接口和AXI 4 接口两者可选 数据和控制通过接口不同字段区分 |
| 底层技术 | 事务层流控：基于次数Credit流控机制 链路层流控: 增强CBFC + 基础PFC FEC：KP4 FEC（IEEE RS-544） | 链路层流控：UEC-CBFC + PFC FEC：IEEE RS-272<br><br> |
| 适配规模 | 256/512卡互联（一次交换转发） | 最大1024卡互联（单跳） |
| 协议实用 测试 | 样机点亮，出具测试报告 | 理论推测阶段 |
通过上述对比可以发现，这两种协议的核心思想，均建立在两大成熟的工业标准之上：AXI 和以太网 （Ethernet）。AXI（Advanced eXtensible Interface）作为芯片内高性能、高可靠性的片上总线，定义了 模块间数据与控制交互的“普通话”；而以太网（Ethernet）为芯片间无处不在的网络基础，其标准数据帧格式 构成了物理链路上信息传递的“通用载体”。理解 AXI 的事务模型与以太网帧的结构，是洞悉 ETH-X 与 SUE 如何将片内总线语义“翻译”为可在片间网络高效、可靠传输的数据包的基石。
APB 和 AXI 作为 ARM 高级微控制总线（AMBA）协议家族的关键成员，是片上系统（SoC）设计中连接 和管理功能模块的核心标准。AMBA， Arm Advanced Microcontroller Bus Architecture，作为一个开放 的片上互连规范，定义了各模块间通信的规则，确保系统高效运行。APB 协议专门针对低带宽的控制访问场 景设计，重点优化外围设备的低功耗要求，如系统外设的寄存器接口。而 AXI 协议则通过集成多种特性，支 持高速亚微米级芯片内部的互联需求，广泛应用于连接 CPU、GPU 以及高速外设（如 DDR 内存和 PCIe 控 制器），是高性能系统互联的基础。
APB3（Advanced Peripheral Bus 3） 于 2003 年随 AMBA 3.0 发布，专为访问外设的可编程控制寄存器 而设计，其特点如下：
AXI4(Advanced eXtensible Interface 4) 作为 AMBA4.0 规范的一部分，于 2011 年正式发布，AXI 互联 接口采用标准化信号进行规范，显著简化了不同 IP 核之间的集成与互联，从而提高了设计的互操作性和灵活 性。
相比 AXI3，AXI4 增加了 QoS 信号、多 region 信号和用户自定义信号三种信号类型，最大突发长度（Burst Length）也从 16 增大到 256，使得 AXI4 更加高效、灵活和可靠。
图98 AXI 互联组件接口的实现方法（左）和 AXI 的五种独立通道（右）64
以太网数据帧的结构包含几个关键字段：目的 MAC 地址（DMAC）、源 MAC 地址（SMAC）、类型、数据 以及帧校验序列（FCS），这些都由 IEEE-802.3 标准详细定义。在此标准中，数据链路层被细分为两个子层： 媒体接入控制子层（MAC）和逻辑链路控制子层（LLC）；数据帧在 MAC 子层被封装，因此通常被称为 MAC 帧。
在需要增强网络安全隔离的场景下，交换机必须具备识别不同 VLAN 报文的能力，这就要求它能够解析报文 中的 VLAN 信息字段。IEEE 802.1Q 协议对此进行了规定，通过在以太网数据帧的 MAC 地址域后、协议类 型字段前加入一个 4 字节的 VLAN 标签（VLAN Tag）来标识数据帧所属的 VLAN。如图所示，VLAN 标 签中最重要的是 VLAN ID（VID），它是一个 12 位的字段，取值范围从 0 到 4095；另外，优先级（PRI）表 示数据帧的 802.1P 优先级，标签协议标识符（TPID）占用 2 字节用来指示数据帧类型，而标准格式指示位 （CFI）则用来表明 MAC 地址在不同传输介质中是否以标准格式封装，从而确保与以太网和令牌环网的兼容 性。
基于优先级的流量控制（PFC）应用于以太网中，旨在应对网络拥塞并提供无损链路。该功能定义在 IEEE 802.1Qbb 标准中，并通过使用 802.1Q 报头中的优先级（PRI）来控制特定优先级的流量。如果数据包中没 有 IEEE 802.1Q 的 VLAN Tag 头，许多 PFC 实现会使用 IP 报头中的 DSCP 值映射到相应的 IEEE 802.1P 优先级值。
66
图99 普通数据帧和 VLAN 数据帧
在中国通信标准化协会的指导下，致力于打造具有竞争力的生态圈和开放平台开放数据中心委员会（ODCC） 成立，推动统一规范和标准的形成。目前，ODCC 的决策组由腾讯、阿里巴巴、百度、中国电信、中国移动、 中国信通院、京东和美团组成，会员单位已超过 200 家。
为促进算力产业的发展，ODCC 网络组于 2024 年 5 月启动了 ETH-X 超节点系列项目。该项目由中国信通 院与腾讯牵头，联合快手科技、燧原科技、华勤技术、锐捷网络、新华三、云豹智能、云合智网、立讯精密和 光迅科技等合作伙伴共同推动，旨在通过产品化样机和相关技术规范，构建大型多 GPU 互联算力集群系统。
ETH-X 是基于以太技术扩展的 Scale Up 互联技术，支持 ETH、UALink 和 OISA 等多种协议。项目输出 的规范涵盖了机架、计算节点、交换机节点和互联设计规范，并发布了《ETH-X Scale Up 互联协议白皮书》； 2025 年 4 月，ETH-X 超节点首台原型机成功点亮。2025 年 6 月，中国信通院与腾讯联合合见工软等单位 成立了“ODCC AI 网络实验室”，并发布了《ETH-X 协议测试报告》，进一步推动了相关技术的发展和应用。
ETH-X 协议聚焦于“超节点”（Super-Pod）架构中跨 GPU 的高效数据访问，采用 “事务层 - 数据链路层
• 事务层：定义 PAXI（Peer-to-Peer AXI）协议，实现 AXI 总线在以太网上的传输，支持直接访存
（Direct Access）和 直接拷贝（Direct Copy）语义。
• 数据链路层：包含 PRI（Packet Rate Improvement，报文速率提升）、LLR（链路层重传）、CBFC
（基于信用的流控）等机制。
• 物理层：支持 50G/100G/200G 单通道速率，接口速率涵盖 100G/200G/400G/800G。
当 IO 实现为独立的 Die 时，可 Die-to-Die 互联，即基于标准 UCIe 实现计算芯粒（Compute Die）与 IO 芯粒（IO Die）解耦互联。
图100 ETH-X 协议栈概览图（参考整理）68
图101 PAXI 整体架构图 69
PAXI 系统总共包含两组标准 AXI4.0 接口和一组 APB 3 接口，这两组 AXI 接口分别被命名为 CAXI 和 DAXI， 它们具备高度的相似性，除了信号位宽可根据具体设计而不同外，并无其他显著区别。其中，CAXI 接口实例 化与否完全依据 GPU 的实际需求而定；而 DAXI 接口则是系统运行的必备组件，必须进行实例化以确保系统 的正常运行和高效性能。这种设计不仅确保了系统的高度灵活性和可扩展性，还为设计提供了定制化的可能性。
GPU 上的 AXI NOC 可直接连接到 PAXI 上，而 APB 接口通常需要一个 APB Bridge 实现协议转换后才可 连接到总线上。
图102 PAXI 发送端（上）和接收端（下）事务层处理流程 70
当 GPU 发送远端 GPU 内存访问请求事务或响应事务时，该事务到达 PAXI 事务层时，会呈现为 DAXI 或 CAXI 接口信号，发送处理流程如下：
图103 DAXI/CAXI 对应的 TL Flit 包格式 71
在 APB 事务处理过程中，Scale Up 内部的一系列状态控制寄存器起到了关键的触发作用。这些寄存器的交 互通过 APB 接口协调完成，确保各类事务能够顺畅进行。在 APB Message 事务中，首先需要对 Message Control Register 进行设置，然后将相关信息打包成 APB Message TL flit；这类事务不仅承载着信息传递 的功能，还在配置 Credit 寄存器中发挥重要作用，从而实现对事务层信用的有效管理。对于 APB Access 事务（包括读和写操作），则需要依赖 Remote APB Control Register 和 Remote APB R/DATA Register 的协同工作。最终，这些操作会被封装为 APB Access TL flit。
在 TL flit 进行仲裁并组装成 MAC 包的过程中，采用了严格的优先级（Strict-Priority）仲裁机制。这种机制 确保了APB TL flit具有最高的优先级，即在同一周期内，如果同时存在APB TL flit以及CAXI、DAXI TL flit，
仲裁器会优先选择 APB TL flit 进行 MAC 包的组装。这种设计保证了 APB 事务在系统资源竞争中的优先处 理地位，从而提高了系统的整体效率和响应速度。
图104 APB TL Flit 格式 72
PAXI 架构支持全面的端到端流量控制，专门设计了一组 32 比特的 Credit 配置寄存器，每个目的 GPU 一个 Credit 寄存器，其中高 16 位用于 AR Credit，低 16 位用于 AW Credit。这一机制为每个 GPU 维护了当前 剩余的 AR Credit 和 AW Credit 数目，以监控并限制未完成的以及当前并发的读事务和写事务数量。当 DAXI 或 CAXI 接口有事务待发送时，仅在 Credit 充足的情况下，该事务才能被传输至目的 GPU，从而确保流量的 平稳流动。
PAXI 通过 Credit 动态更新来进行流控。在系统启动阶段或者准初始化态阶段，PAXI 对剩余 AR credit、剩 余 AW credit 配置初始值，即最大 AR credit、AW credit 数目。每当 PAXI 发送一笔新的读事务请求时， 会将对应目的 GPU 剩余 AR credit 数量减 1，每当收到读事务响应时，会将对应目的 GPU 剩余 AR credit 数 量加 1。同样每当 PAXI 发送一笔新的写事务请求时，会将对应目的 GPU 剩余 AW credit 数量减 1，每当收 到写事务响应时，会将对应目的 GPU 剩余 AW credit 数量加 1。
| |
|---|
| |
|---|
图105 利用 Credit 控制访问请求（左图：Credit 数量减 1）、响应（右图：credit 数量加 1）的流程图 73
GPU-Switch 互通协议层面，Eth-X定义了PRI帧头格式，采用了UEC 的 L2 LLR增强可靠性，允许与 PFC、 CBFC 等流控技术进行协同流控。
Eth-X 通过重新定义网络报文格式，即帧头 PRI 格式，显著优化了转发效率并提升了整体性能。新的 PRI 统 一转发头，由 12 字节组成，取代了传统的 DMAC 和 SMAC，并保留了“Network DeviceId（路由字段）、 TTL（生存时间）、DSCP（差分服务代码点）、ECN（拥塞标识）”等核心字段。PRI 使用设备地址，在 DA 域（UDA，即 User Defined Address，共 10 字节）中进行设备内部寻址。其中包含的流标识（Flow Entropy）， 其字段位置、长度及掩码由 GPU 上层实现指定，这可能因不同的 GPU 实现而有所差异，目的是用于后续的 负载均衡。值得注意的是，DA 域会被网络转发节点忽略，而对流标识的解析则需要交换机侧针对不同 GPU 进行定制化处理。
图106 ETH-X PRI 帧格式 74
在 Eth-X EtherType 之前，增加四字节的 VLAN Tag，从而实现 Eth-X 增强帧（VLAN+PRI）。这一格式 不仅最大程度地兼容了现代以太网交换机，而且 GPU 可以利用这种增强帧来实现报文的压缩，以及安全隔离 与多租户双重功能，为系统解决方案提供更大的灵活性与扩展性。在 Eth-X 增强帧中，PCP（Priority Code Point）的码点对应 IEEE 802.1Q 标准中 VLAN tag 的 PRI 部分。当 GPU 端发出增强帧时，VLAN tag 内 的 PCP 字段和 PRI 域内的 DSCP 字段都需要写入相应的 QoS 标识，确保 QoS 信息的一致性。
图107 ETH-X VLAN+PRI 帧格式 75
数据链路层的 CBFC 和 LLR 机制，参考 UEC 的相关机制实现。数据链路层的 CBFC 是基于虚拟通道 VC 进行的，每个 VC 的信用释放数量（CF，Credit Freed）和消耗的信用数量（CC，Credit Consumed） 用 2 组循环计数器记录，通过跟踪 CF 和 CC 进行流控。事务层和数据链路层 CBFC 机制说明可参考下表：
| 协议层次 | 事务层 | 链路层 |
|---|---|---|
| 作用对象 | 端到端（Peer-to-Peer） 的内存读写事务 | 逐跳（Hop-by-Hop） 的物理链路传输 |
| 协议层次 | 事务层 | 链路层 |
|---|---|---|
| 控制变量 | 每个GPU的AR Credit、AW Credit | 每个VC的CC、CF |
| 影响维度 | 并行度（Outstanding 能力） | 吞吐量（Throughput） |
依据《ETH-X Scale Up 互联协议规范》，ODCC AI 网络实验室基于全场景硬件验证系统 UVHS，搭建超节 点组网的原型测试平台。该平台完整实现了 ETH-X 事务层、链路层及物理层协议，并与国内领先的 51.2T 交 换机通过 400G 接口组网，全面验证了 PAXI（包括 PRI） 增强承载在典型场景下的可行性及性能指标。
| 维度 | 设计目标 | 实测结果 |
|---|---|---|
| 协议延迟 | PAXI + 以太网MAC/PCS/FEC + Serdes < 150 ns | ETH-X PAXI IP时延为157.41 ns |
| 带宽利用率 | 以太网带宽利用率可达99%以上 | 1K报文读写分别达到91.25%和 91.5% |
| 协议承载效率 | 支持内存语义操作 | 小荷载(128Byte)时承载效率优于RoCEv2 |
| 组网验证 | 支持通用以太网交换机实现 256/512卡组网 | 4台主机,400G端口,端到端单向时延经间接测量 为893.91 ns |
图108 ETH-X 原型测试平台（左）和测试路径时延说明（右）
在 2024 年 4 月，博通 Broadcom 首次提出了 SUE（Scale-Up Ethernet）架构。该架构倡导以标准以太 网为基础，通过强化链路层和传输层来实现高性能的 Scale-Up。到了 2025 年 10 月，在开放计算社区 OCP （Open Compute Project）的全球峰会期间，Broadcom将SUE规范贡献给了OCP。OCP成立了SUE-T （Scale-Up Ethernet-Transport）工作组，致力于将其推动为开放标准。与此同时，OCP 启动了更底层
的 ESUN（Ethernet for Scale-Up Networking）项目，重点关注 L2/L3 层，而 SUE-T 则被定位为 ESUN 之上的可选传输层协议。ESUN的成立得到了AI领域几乎所有关键厂商的支持，其工作组创始成员包括AMD、 Arista、ARM、Broadcom、Cisco、HPE、Marvell、Meta、Microsoft、NVIDIA、OpenAI 和 Oracle 等 12 家企业。
图109 OCP 的 ESUN 和 SUE-T 项目 78
技术架构上，SUE 采用类 AXI 的双工数据接口，通过虚拟通道（VC）将事务映射到不同流量类别，支持两 种传输模式严格有序模式（保序模式）和无序模式（多端口负载均衡）。其标准的 SUE 协议栈分为三层：
SUE Lite 旨在将 SUE IP 的面积最多减少 50%，移除了 SUE 的可靠传输层（因此拥塞控制功能也随之被移 除），改用节点间 LLR（链路层重传）。为进一步减小面积，数据包大小被限制为 标准 SUE 的 1/4，即 1KB； 并且仅保留一个信号接口而不支持 AXI4 协议接口了。
| |
|---|
| |
|---|
图110 SUE 标准协议栈（左图）和 SUE Lite 协议栈（右图）79
图111 SUE 标准协议和 SUE Lite 协议对比 80
图112 SUE 接口示意图 81
每个 SUE 实例均包含三个接口，如图 所示：
XPU 命令接口在实现 CBFC 上是有区别的。为了兼容部分不支持 AXI4 的 XPU，FIFO 信号用 6bit 的信用 字段为每个 VC 维护信用值；而在 AXI4 接口中，每个主从通道都关联一个独立的信用接口，为了防止接收方 缓冲区溢出，接收方通过信用接口将信用额度传递给发送方。
SUE Lite 处理流程上没有 Reliability 处理步骤，其他与标准 SUE 处理流程相同。下面以标准 SUE 处理流程 为例进行说明：
图115 封装后的 SUE PDU 格式
SUE 会根据情况将接收到的事务打包到同一 {目标地址, VC}，从而创建 PDU 单元。封装后的标准 SUE PDU 单元最大长度 4096 字节，而 SUE lite 由于没有传输层所以没有 RH 头，进一步将 R-CRC 也优化掉了，SUE Lite PDU 单元最大长度为 1K 字节。标准 SUE 支持灵活的网络封装，支持三种模式，
表14 三种 AFH 模式对比
| 特性 | 标准以太网头 | AFH Gen1（重定义未压缩） | AFH Gen2（深度压缩） |
|---|---|---|---|
| 典型用途 | 兼容传统网络 | 初代 SUE GPU 互联 | OCP 2025+ 主流 AI 集群 |
| 基础格式 | IEEE 802.3 | 保留MAC域，并替代IP、UDP | 在Gen1基础上通过FLAGS压 缩头 |
| XPU寻址方式 | 标准 MAC | 标准 MAC | AAI 编码 MAC (SLAP) |
| 特性 | 标准以太网头 | AFH Gen1（重定义未压缩） | AFH Gen2（深度压缩） |
|---|---|---|---|
| 识别SUE包 | 用UDP端口号 | 特定Ethertype标识SUE包 | 通过FLAGS识别SUE包 |
| 基础PFC承载 （有无VLAN）<br><br> | 有VLAN标识，用VLAN Tag的PRI | ||
| 用IP包头DSCP | 有Shim，Shim头的DSCP；否 则无承载 | 无具体承载 |
标准以太网头格式
图116 标准以太网格式和携带 VLAN 的格式 83
第一代 AFH 使用标准的以太网 MAC 目标地址和源地址，但交换机硬件只需查看地址中的 16 位到 32 位即可 执行转发决策。因为 XPU-id 被映射到 16 位目标地址，用于提升转发查找效率。如果需要区分多种传输层头 部，可在封装包中添加第二个可选的 Ethertype 字段，例如 Shim 头（Etype L4）；而对非 Shim 格式的流量 进行优先级映射，需要向帧中添加 IEEE 802.1Q VLAN 头部。其中 Shim 头定义通过 F 位区别字节头大小， F 为 0 时对应 2 字节 Shim 头，F 为 1 时对应 3 字节（增加了 1 字节的 Flow Label）。
图117 AFH Gen1 标准格式和携带 Shim 头格式报文框架 84
图118 AFH Gen1 中 Shim 头格式定义 85
AFH Gen 2 是基于 AFH Gen1 优化的报头，旨在提供更小的网络报头。AFH Gen2 压缩字段包括 MAC DA、 SA、Etype 域、IP 和 UDP，参考下图；而在 AFH Gen2 中 Etype 字段是用于区分多种不同的传输层报文 头。AFH Gen2 中使用符合 IEEE 标准的编码的管理分配标识符 (AAI)，XPU 标识符被映射到标准 32 位或 压 缩的 16 位值，对应 12 字节和 6 字节报头。AFH Gen2 在 MAC DA 位置定义了 FLAGS 标志位，定义如下：
图119 AFH Gen2 头的报文框架和 Gen2 头压缩字段示意 86
图120 AFH Gen2 头，上图：6 字节 (16 位 XPU ID), 下图：12 字节（32 位 XPU ID）87
XPU 与 SUE 的接口速度往往高于 SUE 与以太网接口速度，这种速度上的不匹配往往会导致事务在 SUE 中 每个目标地址的队列中不断累积。为防止 SUE 内部缓冲区溢出，SUE 在多个虚拟通道（VC）之间实现了流 量控制机制。事务依据目标地址和流量类别，在 SUE 中的缓存队列中分别排队等候处理。SUE 的调度器会
逐一检查这些队列，寻找满足条件的事务队列进行优先处理。SUE 并不会等待队列中的事务累积到某个预设 的大小（例如 2K，最大 4K），而是依据当前实际情况将事务进行打包处理：当某个队列中存在多个事务时， SUE 会将它们合并至同一个协议数据单元（PDU）中；如果目标地址的队列中仅包含一个事务，则会直接发 送该事务。通过这种灵活的调度机制，以及 AFH Gen2 对帧头开销的优化，SUE 有效提升了网络传输效率， 并最大限度降低了事务处理的延迟。
下面通过图示进一步说明这一打包过程：XPU 向 SUE 发送事务 A 至 E，这些不同的事务携带有不同长度的 数据。在 SUE 内部，这些事务依据其目标地址进行排队，由于事务 E 和事务 C 的目的地相同，因此它们被 排入同一队列中，并随后一起被打包发送。调度器首先选择符合条件的事务队列，即包含事务 A 的队列，并 为这些事务添加资源头（RH）和冗余校验码（R-CRC），从而形成 PDU 单元，再经过以太网帧封装 AI 头 和帧校验序列（FCS）后，通过网络接口发送出去。在发送完事务 A 后，调度器接着选择包含事务 B 的队列 并发送事务 B。随后，调度器选择包含事务 C 和事务 E 的队列进行处理，并继续选择包含事务 D 的队列发送 事务 D。在接收端，SUE 负责解封装接收到的以太网头部，提取出其中的命令和数据序列，并将其通过 XPU 命令接口转发给目标 XPU。这种高效的处理流程确保了数据传输的顺畅与高效。
图121 SUE 封装包流程和包格式示意图 89
SUE 的性能设计指标 E2E 延迟为 2us（即 2000ns），还特别规定了 SUE 到交换机的线缆长度不能大于 10m。而根据线缆延迟估算，10m 空心光纤的延时为 35ns，SUE NOC 到以太延时 小于 100ns，以太链 路到 PHY 延时小于 100ns，交换机内部延时小于 250ns，则 SUE 端到端协议延时为 100 + 100 + 35 + 35 + 250 = 520 ns。
图122 理论延时推演示意图 90
在 2026 年 1 月的超节点大会上，合见工软宣称已完成与博通 Tomahawk Ultra 交换芯片的 SUE 协议对接 测试，验证了 LLR、CBFC、AFH 等功能，首家完成 SUE 认证的商业 IP。
图123 合电工软底层 IP 框架示意 91
作为国家信息基础设施核心之一，中国移动希望突破对单一外部互联技术的依赖。打造 OISA 是其构建自主 可控算力技术栈的关键举措，旨在防范供应链中断与风险，确保在国家关键领域的 AI 算力服务安全、连续、 可靠，履行央企的战略责任。
面对千卡/万卡集群的通信延迟与扩展性难题，传统方案无法满足 AI 训练的超低时延与高并发需求。中国移动 必须通过 OISA 重构高速互联架构，实现对算力系统从芯片层到调度层的端到端深度优化，从而将网络资源 优势转化为可交付的、具备确定性性能的高效算力服务。
若仅采用或改良现有标准，将持续处于产业跟随者地位。主动定义 OISA 这一开放互联协议，可促进中国移 动深入产业链核心，有效牵引 GPU、NPU、交换芯片及软件生态协同发展。中国移动通过构建以自身标准与 服务为核心的繁荣生态，亦可实现从成本中心到价值与规则输出中心的升级。
基于前述三点，面对人工智能从单节点向万亿参数规模异构集群的演进，计算架构的重心正从“提升算力”转 向“优化连接”，中国移动希望通过 OISA 刺破“瓶颈”，为业界提供一种开放的、能够支撑超级节点大规模 协同的互连标准。
在中国移动规划中，OISA 旨在成为新一代智算互联的标准化协议体系，其核心是构建一个扁平化、去中心化、 高效开放的 GPU 卡间互联架构。OISA 将专注于突破 GPU / CPU 间内存数据交换的瓶颈，通过联合伙伴共 研 Scale-UP 协议标准实现大规模 AI 训练与推理提供有力支撑。
图124 OISA 技术设计六大原则
OISA 协议体系的总体设计原则体现了中国移动及其合作伙伴面向未来 AI 算力需求的前瞻性思考和系统化理 念。这些原则包括全向连接、极致访存、无损传输、协同计算、智感互联与开放生态构建，为构建高效、智能、 开放的智算互联生态奠定坚实基础。
OISA 的六大总体设计原则形成了完整的技术闭环：从全向连接的架构设计到极致访存的性能优化，从无损传 输的可靠性保障到协同计算的效率提升，再到智能随路感知的动态优化和开放生态的产业共建，共同构成了支 撑新一代 AI 算力互联的核心技术框架。
图125 OISA 技术体系五大特征
OISA 协议体系在设计上充分考虑了 AI 算力集群的特殊需求，通过与多项核心技术特征的有机结合，构建了 一套高效、智能、可靠的 GPU 互联解决方案。这些关键技术特征从协议架构、传输性能、可靠性保障到智能 化感知等多个维度，全面支撑了大规模分布式 AI 计算场景下的高性能互联需求，为构建下一代智算基础设施 奠定了坚实基础。
OISA 的关键技术特征体现了全栈协同的设计理念，通过多模内存访问满足多样化应用需求，借助集合通信加 速实现计算与网络的深度融合，利用智能感知和流量控制构建可靠无损网络。各项技术相辅相成，共同实现了 低延迟、高带宽、高可靠性的互联目标，为大模型训练、推理等 AI 核心场景提供了强有力的底层支持，展现 出卓越的技术先进性和产业适用性。
OISA 协议框架是整个技术规范的核心基础，截至 OISA2.0 版本规范发布，已定义出协议的分层结构、功能 组成、访问流程和互联拓扑等关键要素。该框架为构建高性能、低延迟、高可靠性的 GPU 互联系统提供了架 构指导，确保了从硬件实现到软件应用的全栈协同。
图126 OISA 三层架构及核心功能划分
OISA 协议体系采用清晰的三层分层架构设计，分别为事务层（TL / Transaction Layer）、数据层（DL / Data Layer）和物理层（PL / Physical Layer），各层级职责明确、协同高效。
事务层位于协议栈顶层，主要负责处理内存访问请求与集合通信操作，支持多模内存访问模式（ODLS 和 ODMA），并实现报文聚合分解、即时反馈及硬件集合通信加速功能。该层直接面向计算任务需求，提供低延 迟、高吞吐的访存能力，是实现 GPU 间高效协同的核心支撑。通过统一地址空间管理，事务层使系统内任意 计算单元可像访问本地资源一样操作远程显存或系统内存，极大提升了编程便捷性与运行效率。
数据层作为承上启下的关键中间层，专注于保障数据在 Scale-UP 域内的可靠、有序、无损传输，具备流量 感知、流量控制和数据层重传（DLR）等核心机制。它通过随路感知技术实时收集路径状态信息，结合 BFC/PFC 双模流控策略预防拥塞，并利用 GBN 滑动窗口机制实现快速点对点重传，确保高带宽环境下的传 输稳定性。
物理层则基于 IEEE 802.3 标准演进，兼容多种 SerDes 速率与传输介质，支持从 50Gb/s 到 1.6Tb/s 的端 口聚合能力，采用 PAM4/NRZ 编码与 RS 前向纠错技术，为上层提供高速、低误码率的物理信号传输通道， 支撑 OISA 全向智感互联的高性能需求。
OISA 协议在设计之初就充分考虑了不同规模和应用场景下的互联需求，通过支持多种灵活的互联拓扑结构， 为构建高效、可扩展的 GPU 集群提供了坚实的技术基础。OISA 技术体系支持常见的四种主要互联拓扑类型， 涵盖了从简单的小规模直联到复杂的大规模多层互联等多种场景，确保能够满足不同规模集群的部署需求。
表15 OISA 支持四类联接拓扑及主要能力比较
| 直接互联拓扑 | 单级互联拓扑 | 背靠背互联拓扑 | 叶脊互联拓扑 | |
|---|---|---|---|---|
| 拓扑 形式 | ||||
| 联接 方式 | GPU间直连 | 单级网络 | 单级网络+背靠背 | 叶-脊两级网络 |
| GPU 规模 | 8 | 256 | 256 | 1024 |
| 交换 芯片 | 无 | 8 | 16 | 192/L-128+S-64 |
| 端口 配置 | 无 | 固定端口映射 | 机柜间通过背靠背链 路连接 | Pod结构，支持多路径 转发 |
| 卡机 联接 | 无 | 多轨 | 多轨 | 多轨 |
| 有效 带宽 | 理论高，实际聚合带 宽有限 | 带宽确定，聚合带宽随 芯片数量线性增长 | 带宽确定，但背靠背带 来跨柜瓶颈 | 带宽最高，有效带宽受 LB算法影响 |
| 延迟 情况 | 最低：单跳直达 | 较低：固定1-2跳，路径 确定 | 较低：多一跳背靠背链 路 | 较高：至少2跳，路径可 变 |
| 容错 能力 | 无冗余，任意链路故 障导致失效 | 冗余度低，依赖交换芯 片可靠性 | 可靠性提升，机柜级链 路冗余 | 冗余度高，支持多路径， 容错性最佳 |
| 扩展 能力 | 无法扩展 | 扩展成本低（按需增加 芯片/交换机） | 扩展成本高（需成对增 机柜） | 扩展成本可控（按Pod 扩展） |
| 直接互联拓扑 | 单级互联拓扑 | 背靠背互联拓扑 | 叶脊互联拓扑 | |
|---|---|---|---|---|
| 能效 情况 | 能效比优 | 能效比良好 | 能效比中等 | 能效比一般 |
| 存在 优势 | 成本低、功耗低、布 线简单 | 扩展性好、确定性转发、 避免乱序 | 适配机房环境、突破单 机柜限制 | 支持千卡规模集群、可 扩展性强 |
| 存在 限制 | 扩展性差 | 需要固定端口映射关系 | 需双倍交换芯片数量 增加了成本 | 数据转发跳数多，更依 赖负载均衡 |
中国移动联合业界伙伴共同研发 OISA 协议并非对现有网络协议的修补，而是面向 AI 智算业务这一特定领域 开展重新设计，建立以内存为中心（Memory-Centric）的技术体系。通过 OISA，超节点系统将分散的 GPU 显存与内存系统映射为统一寻址的全局共享空间，使跨节点协同回归为标准的内存读写语义，将实现百纳秒级 别的极低延迟。这一逻辑最终通过 OISA 统一报文格式进行了落地。
图127 OISA 报文结构
OISA 协议通过标准化的报文结构设计，实现了高效、可靠的数据传输。其报文由事务层头、数据载荷和 CRC 字段三部分组成。事务层头采用强制性头部结构，通过支持灵活的可选字段配置，确保了在不同通信场景下都 能提供最优的传输效率和可靠性保障。数据载荷为条件可选字段，由事务层头中的特定字段定义是否携带。 CRC 字段为强制性字段，用于整个报文完整性校验。
为了适应 AI 智算场景中的多种应用需求，OISA 基于协议报文特质定义了三种各自独立的报文访存模式。GPU 与交换芯片可根据报文格式类型、事务类型、系统配置等信息，识别并区分不同类型的通信事务，进行相应转 发或依策略处理。
在该模式下报文基础结构由 20 字节强制必选字段构成，包括 16 字节的统一报文头与 4 字节的 CRC 校验， 为所有 OISA 报文必须遵循的最小格式要求。
为网络交换设备和端侧设备提供报文分类、路径决策及事务跟踪的核心信息。其定义的字段支持（但 不限于）以下能力：
通过格式与类型字段解析事务语义；通过源/目标 ID 实现路径寻址；通过虚拟通道（Virtual Channel, VC）和标签 ID（Tag ID）提供服务质量保障与事务匹配等。
用于保障报文在物理介质中的可靠传输。源端在将报文传输至物理层前，需在数据层对完整内容进 行校验计算，生成 32 位 CRC 值并填入此字段；目的端通过校验该值，判定报文在传输过程中是否 发生比特错误，从而确保端到端传输的完整性与正确性。
条件可选字段根据事务类型动态包含，由内存地址（Memory Address）和变长数据载荷（Data Payload） 组成。其存在与否及长度由 16 字节统一报文头中的事务类型（Packet Type）决定，并通过 Format 字 段具体指示是否携带：
该字段紧跟 16 字节统一报文头之后，为 64 位精确地址，仅在需要内存寻址的事务中出现，如内存 读请求（Memory Read Request）、内存写请求（Memory Write Request）等，用于指定目标 内存位置。变长数据载荷
用于承载事务相关的事务数据，例如内存写请求 (Memory Write Request) 中待写入的数据、内存 读响应 (Memory Read Response) 中返回的目标数据等。Data Payload 的长度由统一报文头的 Length 字段明确描述；当事务无需携带报文数据时，Length 字段设置为 0。部分定义字段支持能 力如下。
用于承载事务相关的事务数据，例如内存写请求 (Memory Write Request) 中待写入的数据、内存 读响应 (Memory Read Response) 中返回的目标数据等。Data Payload 的长度由统一报文头的 Length 字段明确描述；当事务无需携带报文数据时，Length 字段设置为 0。Format 用于指示该 数据载荷字段是否携带。
部分定义字段支持能力如下： − Virtual Channel（虚拟通道）字段支持 8 个虚拟通道，为不同类型的事务提供精细化的服务质
量管控与流量隔离能力。Packet Type（报文类型）字段用于描述事务层报文操作语义，指导 目的端解析、执行与应答流程。
− Entropy（熵值）字段为多路径互联环境提供高效的负载均衡辅助机制，作为交换芯片等价多路
径算法的高质量随机化输入，解决哈希碰撞问题。目前支持源端 GPU 填充方式。
GPU 或 交互芯片的 OISA 端口通过识别 OISA 报文中的 Sensing Protocol Type 字段判断当前传输模式为 智能访存模式，随即开启随路智能感知功能，并探测收集相关信息。每当报文到达 OISA 端口或从 OISA 端口 发出时，相应的端口设备会根据感知标签将自身的关健状态信息通过比较替换的方式，实时更新到报文的感知 标签中。
智感模式下的报文与极致访存模式报文相比，主要在于协议类型字段和新增的感知标签字段。OISA 定义了一 种简单、低开销的感知标签字段。感知标签内包含由跳数（Hop Count）和设备端口号（Device Port ID） 组成的设备位置信息，以及感知信息类型（Sensing Type）和状态程度值（Degree Value）。在报文中部 分定义字段如下：
智感访存模式中，OISA 定义的反馈报文是网络状态信息回传的核心机制。当携带感知标签的探测报文到达目 的端 GPU 后，GPU 会解析其中的路径状态信息，并在状态劣化至预设阈值时，触发生成一个标准反馈报文。 反馈报文有单独的协议类型，其数据结构中包含了反馈信息对应的位置和内容，通过设备类型、编号、端口及 VC 通道号精确定位问题路径位置，并将量化后的 Degree Value（状态程度值）回传给源端 GPU，从而实 现网络状态的闭环感知与优化，同时通过阈值触发机制有效避免了频繁反馈对链路带宽的占用。反馈报文主要 定义字段如下：
CCA 模式的转发报文基于极致访存模式基础之上进行了扩展，此模式下必须用到 32 字节强制性必选字 段：包含 28 字节的报文头和 4 字节的循环冗余校验 CCA 报文。
Memory Address（内存地址）字段：与极致访存模式不同的是，集合通信加速过程交换芯片需要确认 来自不同 GPU 的数据中哪些数据需要做同一批归约操作，以及确认组播需要发送到哪些地址空间中。这 需要依靠 Memory Address 指定数据对应内存的映射地址确认这些数据之间是否对齐，保证交换芯片计 算和组播操作准确，所以在 CCA 模式下 Memory Address 为必选字段。
CCA 报文字段：在 CCA 模式下，通过 Format 指示该报文是否开启 CCA 功能，OISA 头部字段需要 额外携带的 CCA 扩展头（CCA Group ID、CCA RSV、CCA Data Type、CCA OP Type）。
在 CCA 模式下，OISA 报文头部分字段基于极致访存模式增加专用说明，并增加额外 CCA 报文字段， 所涉及主要报文字段定义如下：
所有参与同一集合通信加速任务下的 GPU 和 Switch 必须使用相同的数据类型，否则可能导致通信 失败或结果错误。
支持 OISA 的设备在通信过程中，源端设备的协议引擎将上层数据封装成 OISA 报文并发送，经过物理层编 码传输至交换芯片或目的端设备，目的端设备接收后解析报文并处理，整个过程通过 T(X)和 R(X)接口实现全 双工通信。
比特序定义了在协议报文封装与解析过程中，每个字节内部各个二进制位的传输与解读顺序。OISA 明确规定 采用最低有效位（Least Significant Bit）优先的传输机制。
事务层接口定义与功能：通过 OISA 协议实例化单元（OPE）作为关键桥接角色，负责将芯片内部总线事务 与 OISA 协议在外部物理链路上定义的报文格式进行双向转换。该接口包括了 OISA“上行”的主机接口负责 与 GPU 核心或交换矩阵等芯片内部功能模块交互；以及 OISA“下行”的链路接口负责与物理层收发器 （PHY/SerDes）连接，处理串行化数据的收发。OISA 主机接口的通信由一组逻辑上的事务原语构成，而 非简单的物理信号集合。协议定义了六类核心事务原语，包括：
物理层接口定义与功能：对 OISA 协议实例化单元（OPE）的"下行"链路接口进行规范性定义。该接口负责 OPE 与物理层收发器之间的信号交互，是实现 OISA 报文在物理介质（如光纤或铜缆）上传输的逻辑边界。 其核心功能是处理待发送报文的并行到串行转换，以及目的端串行比特流的串行到并行转换。OISA 对物理层 接口设计上仅定义接口信号的功能、方向和交互逻辑，并不限制具体的位宽或通道数量。
OISA 核心功能与关键技术
OISA 事务层核心功能与关键技术
OISA 协议在事务层定义了四项核心能力，旨在解决高性能计算与 AI 训练中数据传输的延迟、带宽和处理器 利用率等核心瓶颈问题，支撑高效、灵活的互联通信。包括：
多模内存访问技术旨在解决高性能计算（HPC）与人工智能（AI）训练集群中，计算节点间（尤其是 GPU 间）高效数据通信的根本需求。所有场景都围绕一个核心：让数据在分布式内存间快速、透明地移动，使大规 模并行计算如同在单一大内存机器上运行。
目前 OISA 的 2.0 协议事务层在架构上支持一个多模内存访问模型，为不同粒度的内存操作提供最优化的执行 路径。此模型融合了用于细粒度访问的指令驱动 Load / Store 语义（ODLS），以及用于粗粒度数据搬运的直 接内存访问（DMA）模式（ODMA）。同时，为保障在并行计算环境中内存操作的顺序性与可见性（内存一 致性），OISA 协议在事务层定义了一套标准的内存栅栏 (Memory Fence) 操作，该操作是一种强制性的同步 原语，其在并发执行数据报文中建立一个严格的排序点。
图128 OISA 共享内存访问模型
ODLS（指令直驱访问 Load/Store）：通过向计算核心提供统一虚拟地址空间，屏蔽底层内存的拓扑差异， 在 GPU 计算核心直接发起的细粒度远程内存访问过程中，实现透明化的低延迟数据交互。协议对此模式处理 流程如下：
ODLS 技术需要考虑如何让一次远程内存访问在微秒级内完成，并且对程序员而言，其代码看起来就像访问 本地变量一样简单。基于该技术理念，OISA 需要实现：
图129 OISA 消息传递的模型
ODMA（直接内存访问）OISA 规范需要 GPU 应包括包 OISA 直接内存访问（OISA Direct Memory Address, ODMA）引擎。该引擎的核心职责是独立于计算核心，在源端 GPU 准备好数据后，将一块连续的 内存区域通过互联端口传送至目的端 GPU 的指定内存地址主要面向需要高带宽和异步、粗粒度数据搬运的场 景应用。协议对此模式处理流程如下：
ODMA 技术需要考虑如何在不干扰 GPU 核心计算的前提下，以接近线速的带宽搬移海量数据，并简化编程。 基于这种“将大块数据搬移任务卸载给专用引擎”的技术理念， OISA 建议实现：
通过在协议中同时规范这两种访问模式，OISA 架构确保了无论是延迟敏感的精细化操作，还是带宽敏感的批 量数据搬运，都能在统一的互联链路上找到最高效的执行路径。
OISA 协议定义了内存栅栏（Memory Fence），旨在解决 Scale-up 架构中跨 GPU 内存访问的一致性挑战： 操作顺序的不可预测性与结果可见性的延迟。内存栅栏是一种同步原语，它强制要求：在栅栏指令之后的内存 操作执行之前，所有在其之前的操作必须完成，并确保其结果对其他处理器可见全局。
Fence 作为强制性的同步原语，为程序员提供了明确的“顺序点”与“可见性点”。协议对 Fence 操作的行 为提出如下强制性要求：由任意远端 GPU 发起的 Fence 操作，能够使其在该 Fence 之前提交的所有内存 写操作，在 Scale-up 域的范围内完成并且其结果对其它指定范围内的设备可见之后，该请求方的后续任何内 存操作方可开始执行。
OISA 协议支持的 GPU 内存栅栏设计具备多级作用域，包括用于较小范围同步的局部（local）栅栏、用于更 大范围同步的全局（global）栅栏，以及面向更大规模同步需求的集群（cluster）栅栏。这种分级机制允许 应用程序根据实际交互的范围和粒度来选择合适的同步强度，从而避免不必要的性能开销。
以下三种作用范围的栅栏指令：
此分级机制旨在允许应用程序根据其实际的同步粒度，灵活选择开销最小的栅栏类型，从而避免因使用非必要 的大范围栅栏而导致的性能损失。通过分级机制具备的可扩展性，以高效支持高带宽域内 Scale-UP 全局同 步需求。
集合通信加速技术主要面向大规模分布式 AI 训练和高性能计算（HPC）场景中的集合通信操作，包括 Reduce、 Broadcast、ReduceScatter、AllGather、AllReduce 等核心通信原语。这些操作在大模型训练中频繁出 现，是影响整体训练效率的关键瓶颈。
表16 训练过程中涉及的各类通信情况
| 通信 | 联接 | 过程 | 特点 | AI 训练场景 |
|---|---|---|---|---|
| Broadcast | 一个节点将相同的 数据发送给所有其 他节点。 | 1对N通信，根节点 出口带宽压力高，带 宽受限操作。网络拓 扑和根节点位置对 性能影响高。 | 初始状态同步。在训练 开始前，将全局一致的 参数、数据从主节点分 发到所有工作节点。 | |
| Reduce | 所有节点都向一个 节点发送数据，该节 点对所有数据进行 运算（如求和），并 保留结果。 | N对1通信，对目标 节点入口带宽和算 力有要求。数据被节 点汇总后，其他节点 无法直接获取。 | 中心化聚合：将各节点 评估指标、损失值汇总 回主节点，记录日志或 监控，或在小规模参架 构中收集梯度。 | |
| Reduce Scatter | 1. 规约阶段：每个节 点的完整数据（如梯 度张量）被切分成N 块。所有节点对第i 块数据规约（如求 和）。<br>2. 散射阶段：规约后 第i块结果被唯一发 送给第i个节点。最 终，每个节点只持有 一个片段。<br> | 将全量规约的计算 和通信压力分散到 了所有节点。每个节 点既是数据的发送 者也是接收者，但只 处理全量数据的一 部分。能有效利用所 有节点的聚合带宽 和计算力，通常比简 单的Reduce更高 效。 | 分散式规约的第一步： 通常与AllGather配对 使用，以实现高效的 AllReduce。在一些模 型并行策略中，直接用 于在不同设备间分配 及规约部分激活值或 梯度。 |
| 通信 | 联接 | 过程 | 特点 | AI 训练场景 |
|---|---|---|---|---|
| All Gather | 每个节点都向所有 其他节点发送自己 持有的唯一数据块。 最终，所有节点都收 集到来自所有其他 节点的数据块，拼凑 成一份完整的数据 集。 | 每个节点的出口数 据量较小（一个数据 块），但需要从所有 其他节点接收数据。 通信量随节点数增 加而线性增长。是典 型的多对多、全连接 通信。 | 数据整合与同步：作为 高效AllReduce的第 二阶段，用于将 ReduceScatter后分 散在各节点的结果片 段收集成全量结果。也 用于整合不同节点上 计算出的不同数据分 区。 | |
| All Reduce | 所有节点都提供输 入数据，并最终获得 完全相同的规约结 果（如梯度求和）。 这是分布式训练中 最核心、最频繁的通 信操作。 | 让所有节点结果一 致。其实现是由更基 本的原语组合而成 （ReduceScatte r+ AllGather）。性 能优化核心在于平 衡所有节点计算和 通信负载，最小化瓶 颈。 | 全局梯度同步：在数据 并行训练中，每个训练 步（Step）结束后， 将所有工作节点计算 出的局部梯度进行运 算，并将更新后的全局 梯度同步回所有节点， 以保证模型参数的一 致性。 |
OISA 的集合通信加速功能由硬件层（GPU、Switch）与软件层（OISA 管理器、集合通信库）共同定义了 技术架构。
软件层组件包括 OISA 管理器、集合通信库（Collective Communication Library, CCL）。在集合通信 加速中的主要功能为：
GPU 及其配套的 OISA GPU 管理组件、Switch 及其配套的 OISA Switch 管理组件之间依托标准 OISA 协议，不同类型事务报文以及 LLDP 报文进行通信，实现流程的协同和信息的交互。集合通信加速各组件 存在以下接口：
| 接口 | 接口描述 |
|---|---|
| GPU管理器--GPU | 管理 GPU 及 Switch 间的拓扑关系，对GPU进行配置管理、状态监控、 硬件维护等 |
| Switch管理器--Switch | 对Switch进行配置管理、状态监控、硬件维护等 |
| GPU管理器--集合通信 库 | OISA GPU管理器为集合通信库维护并提供了GPU与Switch之间的拓扑 信息及链路状态，使能集合通信库得以建立集合通信和集合通信加速所需 要的最短路径 |
| 集合通信库--GPU | 集合通信库作为GPU上运行的软件库，响应应用框架的调用，实现内核 （Kernels）启动、集合通信函数和集合通信加速功能调用等操作 |
初始化配置用于协同 GPU 及 Switch，使其将 GPU 和 Switch 分别配置为能够支持对本次 AI 任务进行 集合通信加速的状态。初始化配置由应用框架发起，集合通信库响应，生成内存语义报文通过 GPU Header 的所有端口传递给对端 Switch 处理器完成配置，包括建立对应 GPU 组、分配 Switch 缓存等。
在集合通信加速实现过程中，交换芯片不再只是被动的数据管道，而是成为主动的协同处理器，通过在转 发路径中直接执行聚合、归约等计算操作，减少数据在网络传输中的总量，主要通过下列关键技术实现：
为实现集合通信加速的目的，针对不同集合通信原语，交换芯片可以实现不同的加速操作，包括：
为应对分布式应用中高频次、小报文通信带来的高开销问题，OISA 协议在事务层定义了标准的报文聚合和分 解机制，支持最多 64 个报文进行聚合。该机制需要相应的硬件逻辑予以支持，并在链路上源端 GPU 进行聚 合、目的端 GPU 进行分解。通过这种方式，最大限度地减少单次传输的协议头开销，提升小报文场景下的有 效数据吞吐率与系统整体效率。
源端聚合要求：通过设设定一个聚合控制器将多个去往统一目的地的报文拼接成单个 OISA 事务层报文的数 据载荷并记录聚合报文数量。不能聚合不同目的地的报文。
目的端分解要求：是聚合机制在目的地的逆操作，需要通过检查聚合报文标记确定报文数量，并发送至剥离控 制器还原为独立的报文，报文完整还原后再进行处理。
OISA 协议将源端 GPU 的聚合操作定义为机会性的，旨在平衡传输效率与处理延迟。为实现这一目标， 协议要求合规实现必须提供可配置的聚合上限参数，包括成员报文数量上限（MNSP）、聚合包长上限 （MLAP）。
聚合调度器在构建聚合包时，一旦满足以下任一条件即应立即发送：队列中可聚合报文数量达到 MNSP、 聚合包总长度达到 MLAP，或队列中已无可聚合报文，以此避免无故延迟。
调度器行为需遵循严格约束：若虚拟通道（VC）未启用聚合模式，则发送单个标准报文（Packing Number 为 0）；若启用聚合模式，则根据可聚合报文数量（NSP）决定——当 NSP 大于 MNSP 时，最多聚合 MNSP个报文发送；当NSP在1到MNSP之间时，聚合所有报文发送；即使仅有一个可聚合报文（NSP=1）， 也必须将其封装为聚合包（Packing Number 为 1）发送，确保逻辑一致性。
首先，通过 Packing Number 字段明确标识报文状态——值为 0 表示非聚合的单事务报文，值大于等于 1 则表示聚合报文，且该数值精确等于其包含的成员报文（Sub-packets）的数量。
其次，为确保目的端能正确解析，每个被聚合的成员报文都必须封装在一个独立的成员报文头之后，该头 必须包含诸如 Tag ID 等该报文独有的标识信息。
最后，聚合策略需根据报文类型进行差异化配置：
OISA 协议的报文聚合配置与操作的核心在于对聚合上限参数（如 MLAP 和 MNSP）的合理设定，避免 因过于激进的策略（如设置过高上限或长时间等待）而牺牲事务的端到端延迟。在设定这些参数时，实现 方必须综合评估以下系统级因素：
在高并发场景中，即时反馈机制（Early response）可以降低延迟，是优化数据传输效率的重要功能。该机 制的核心是通过在 GPU 本地提前返回响应，提前释放相关操作的上下文 Cache 资源，避免计算核心因等待 而产生大量停顿，减少业务的计算时间和片上存储资源的浪费，解决系统性能和扩展性的瓶颈，提高集群资源 的利用率。
即时反馈机制要求：将事务通信的“逻辑完成”与“物理完成”解耦。物理完成指一个 TLP 穿越物理链路， 目标 GPU 的应用层返回响应。逻辑完成指源端 GPU 的计算任务完成。该机制旨在提升系统性能和扩展性。
OISA 的即时反馈机制仅适用于投递型写请求（Posted Write），必须在 GPU 内部事务保序性得到保证的前 提下，由集群管理系统统一全局启用。实现时，发送端 GPU 需在请求发出后立即本地生成响应以快速释放资 源；同时，目的端 GPU 在完成实际写入后，必须丢弃其内部的完成响应，避免产生冗余网络流量。该机制通 过缩短响应路径，有效提升高并发场景下的系统吞吐与计算效率。
OISA 协议在数据层主要通过以下三种能力建立数据传输可靠性保障体系，为高性能计算和 AI 训练提供了稳 定、高效的网络支撑。
这些能力共同构建了 OISA 协议的数据传输可靠性保障体系，为高性能计算和 AI 训练提供了稳定、高效的网 络支撑。
为确保在 AI 突发流量场景下的传输质量，并对 Scale-up 高带宽域内的互联环境进行优化，OISA 协议在数 据层支持一套标准的流量感知机制。该机制的架构目标是，使源端 GPU 能够获取数据传输路径上所有交换设 备及目的端 GPU 端口的状态信息，从而精确识别性能瓶颈。基于这些信息，源端 GPU 应能够主动调整其后 续的数据报文发送策略，例如调整发送速率或选择新的传输路径，以实现高效、无损的数据传输。此流量感知 功能在报文被配置为智能访存模式时方可启用。
OISA 协议定义了两种互为补充的流量感知操作模式，以确保 GPU 之间互联状态信息能够被及时有效地收集。
源端 GPU 通过向数据报文嵌入感知标签（Sensing Tag）发起带内探测。传输路径上的每个 OISA 交换芯 片必须遵循“最差状态保留”原则：比较本地量化状态与报文携带值，并用更差的状态及自身位置信息更新标 签。目的端 GPU 负责解析最终标签，并根据状态程度值与预设阈值的比较结果，决定是否触发反馈。
作为对源端探测的补充，目的端 GPU 必须持续监控本地关键性能指标（如缓冲区占用率）。当任何指标突破 其预设告警阈值时，即使未收到对应探测请求，目的端也必须立即主动生成并发送告警报文至源端。该报文需 通过高优先级队列发送，并应包含基于定时器的重传机制以确保可靠性。
目的端生成反馈报文需遵守严格规则：①反馈抑制—仅当状态劣于对应类型配置阈值时才触发；②位置报告在拓扑确定时采用直接报告模式反馈准确设备信息，在复杂拓扑导致无法唯一定位时采用间接报告模式，并设 置熵有效位指示源端结合自身上下文完成最终解析；③特殊规则—对二层交换芯片的拥塞，目的端不向源端反 馈。
协议不规定具体调控算法，但所有调整必须遵循基础约束，必须保障强保序数据流的顺序性。对此类数据流， 禁止采用可能引发报文乱序的路径切换策略（如改变 Entropy），仅允许进行发送速率调整等不影响路径的策 略。
OISA 数据层通过两种协同的流量控制机制保障高速互联中的无损传输。 第一种是缓存感知流量控制（BFC），其核心在于源端根据实时感知到的目的端虚拟队列剩余缓存空间来动态 调控发送数据量，实现逐跳的精准反压，从而从根本上避免因接收端缓存溢出导致的数据丢失。
第二种是基于优先级的流量控制（PFC），它在链路拥塞时为不同业务流量提供差异化的管控。该机制为每个 虚拟通道（VC）设置独立的 XON/XOFF 阈值，当接收端队列占用达到阈值时，可暂停或恢复特定优先级的
数据流，而非中断整个链路，从而确保关键业务的高优先级流量不受低优先级拥塞的影响。这两种机制相互配 合，共同实现了高效且精细的链路级资源管理。
OISA 数据层支持重传机制，当接收方（GPU 或 OISA-Switch）检测到数据层报文出现错误或丢失时重传 丢失的数据帧，可实现点对点快速重传，保障数据链路之间的可靠传输。
OISA 数据层报文分为 DLR 报文（需要重传保护）和非 DLR 报文（不需要重传保护），只有 DLR 报文丢失 或出错时候需要进行重传。对于 DLR 报文，OISA 数据层将在其报文前导码中按照报文发送顺序添加序列号 （Sequence Number，SN），同时将报文数据缓存至数据层重传缓冲区。对于非 DLR 报文，无需在其前导 码中添加报文序列号，接收端也只需对其进行 CRC 校验即可。
OISA 数据层重传基于 GBN 机制实现，发送方可连续发送多个数据帧，不需等待每个帧确认。发送端收到 NACK 或预期时间内没有收到相应的 ACK 时，将重传对应序列号后的全部报文。
数据层重传与流控是保障数据层报文无损传输的两种机制。二者相辅相成，流量控制从源头预防丢包或降低丢 包的发生概率，重传则在丢包或者数据传输出错发生后弥补损失，共同保障链路层数据传输的可靠性与效率。
BFC 机制下，对于重传数据包的发送，既不需要再次判断目的端缓存空间是否足够，源端也不应再次扣除其 占用的缓存空间大小。PFC 机制下，在重传期间 PFC 暂停帧只暂停新的数据报文的发送，而不影响重传报 文的发送。BFC 的缺点是需要收发双方均支持该机制，否则无法实现互通。BFC 与 PFC 都是 OISA 支持的 数据层流量控制机制，需在设备初始化阶段选择流量控制机制并配置相关参数。
OISA 在物理层端口和通道上支持多种数据传输速率，满足不同性能与成本需求：
OISA Gen2.0 物理层定义了完整的信号处理链以实现高速可靠互连。其核心特色在于采用了高效的 256B/257B 编码，相比传统 64B/66B 编码进一步降低了开销，并结合自同步扰码与周期性对齐标志插入机 制，以抑制抖动、辅助通道同步与纠偏。在纠错方面，PCS 子层支持 RS(544,514)与轻量级 RS(272,257) 两种前向纠错方案，在提供强大纠错能力的同时兼顾不同场景对延迟与复杂度的要求。
在物理媒介适配层，PMA 负责数据的串并/并串转换与时钟恢复。它支持从 NRZ 到 PAM4 的多阶调制，并 采用 Gray 编码与(1+D)模 4 预编码等技术优化信号完整性。SerDes 模块集成自适应均衡器、锁相环型时钟 数据恢复电路及高性能驱动器，以补偿通道损耗、抑制码间串扰并确保信号在接收端被准确采样与恢复。
物理层对外提供了广泛的高速接口能力，支持从 25.78125Gb/s 至 212.5Gb/s 的多种单通道信号速率，并全 面兼容从 500BASE 到 1.6TBASE 的 IEEE 以太网接口家族。其关键性能指标要求严格：在进入 FEC 解码 前，链路误码率须优于 1E-6；针对不同速率，对通道插入损耗（从 TP0 到 TP5）规定了具体门限，例如对 于 112Gb/s PAM4 信号，损耗需控制在 28.5dB@28GHz 以内。
为保障在真实封装与 PCB 环境下的稳定工作，OISA 对 SerDes 的驱动能力提出了明确要求。其设计目标是 在计入封装损耗并预留 2dB 余量后，芯片间（Bump-to-Bump）的总通道损耗在特定频点下仍需满足 BER 要求，例如对于 56Gb/s PAM4 信号，需能支持高达 37dB 的总损耗，体现了其对恶劣信道条件的适应性与 鲁棒性。
支持 OISA 的超节点从物理上电到业务就绪采用分层递进的方式，依次建立并验证各层级平面的功能： 带外管理平面：首先通过 BMC 建立独立于操作系统的硬件远程管控通道，完成安全加固、网络配置及所有组 件（计算/交换/电源托盘）的固件对齐与统一纳管。 固件/平台层：随后执行系统上电，通过 BIOS/UEFI 配置关键参数（如高位地址空间、PCIe 链路），完成硬 件枚举与自检，确保 CPU、内存、GPU 等核心硬件可被正确识别且资源无冲突。 带内管理平面：在操作系统内部配置网络、时间同步并进行安全加固，构建主机级的可观测性与安全管理能力。 带内控制平面：将节点安全注册到上层集群控制器（如 Kubernetes），注册硬件资源但暂时阻断业务调度， 同时安装并待命 OISA Fabric Manager。 带内数据平面：配置并验证高性能网络、存储及 GPU P2P 等核心数据传输通路，为应用通信奠定基础。 拓扑发现与建链：最后由 OISA Fabric Manager 自动探测并构建 OISA Link 物理连接拓扑，协商建立链路， 并计算分发全局最优转发路径，形成高带宽、低延迟的 GPU 互连网络。 整个过程强调前置条件检查、安全合规、配置标准化与阶段性验证，确保系统最终以稳定、可控、高性能的状 态交付给业务。
OISA 管理框架的设计遵循三大核心原则，旨在构建一个统一、高效且适应未来发展的管理体系： 开放性：严格基于主流开放标准构建接口与数据模型。带外管理采用 gNMI 协议，数据模型与 Redfish 标准 兼容，确保能够无缝集成到现有数据中心管理生态中。 互操作性：通过对管理组件间的接口、协议和数据模型进行确定性定义，保障来自不同厂商的 OISA 设备能 够在统一管理平面下协同工作，实现“即插即用”，降低集成复杂度。
可扩展性：采用“集中式控制，分布式执行”的架构。集中的 OISA 管理器负责复杂决策，分布式代理负责 本地执行。这种设计确保管理复杂度随集群规模呈线性增长，从而能够有效管理从单个节点到超大规模 GPU 集群的各种部署场景。
OISA 管理架构是个层次化、基于标准协议的分布式系统，各组件及交互定义如下：
OISA 管理器：作为逻辑集中的唯一控制平面，是整个管理域的“大脑”。其核心职责包括：进行全局拓扑发 现、集中计算并分发转发表、执行租户子域管理与隔离策略、汇总全集群监控与告警信息，并协调故障处理等 RAS 流程。
管理代理：分为交换芯片代理和计算节点代理。它们是 OM 在硬件设备侧的“执行臂”，负责接收 OM 的抽 象指令，并将其转换为对本地硬件的具体操作。SA 通过 gNMI/Redfish 与 OM 通信，并通过标准化的南向 接口控制交换芯片。
受管硬件：主要包括 OISA 交换芯片和符合规范的 OISA GPU。它们通过代理暴露管理接口，执行具体的转 发和计算任务。 该架构通过清晰的职责分离（OM 决策、代理执行）和标准的开放接口，实现了对复杂异构硬件资源的统一、 自动化管理。
OISA 推荐两种典型的物理部署模型，以满足不同规模和应用场景的需求：
分离式架构：计算节点与交换平台在物理上分离部署于不同的机箱或机架。这种模型适用于追求极致扩展性的 大规模 AI 训练集群，支持成千上万个 GPU 跨机架互连，便于计算和网络资源的独立扩容与维护，但布线和 管理网络相对复杂。
集成式架构：将 GPU 计算单元与 OISA 交换芯片高度集成在同一台物理服务器或机箱内。这种模型提供了更 高的密度和更优的成本效益，减少了外部线缆和占用空间，适用于规模稍小、对部署紧凑性和总拥有成本有更 高要求的场景，如企业级 AI 推理或中等规模训练集群。
OISA 交换芯片是实现高速 GPU 智算互联的核心引擎，其设计超越传统数据交换，深度融合了网络控制、计 算卸载与深度感知能力，以满足大规模 AI 集群对自动化、确定性及高可靠性的严苛要求。
在基础转发与网络自治层面，交换芯片需具备完整的 OISA 协议处理能力。这包括对数据报文及拓扑发现等 控制平面报文的精准识别与解析，后者需上送本地 CPU 以支撑全局拓扑的自动构建。转发时，必须依据目的 ID 查找转发表，并强制使用报文头中的熵值字段在多路径中执行确定性的、无状态的负载均衡，确保流内报 文不乱序，保障 RDMA 等高性能通信效率。同时，芯片需集成 PFC 及更先进的缓存感知流量控制（BFC）， 并建议与 GPU 端实现协同一致的 BFC 缓存管理框架，从根本上避免缓存死锁，实现稳定无损传输。
在性能与高级特性上，交换芯片须以高带宽 SerDes 为基础，提供无阻塞的线速转发与端到端的超低延迟。 其特别强调深度感知与带内遥测能力，能够实时采集链路时延、队列深度等信息，并通过 Sensing Tag 直接 写入转发中的数据报文，为全局拥塞控制与性能调优提供实时数据。此外，强制性的硬件状态监控（如光模块 功率、芯片结温）及 Link Down 等事件的即时硬件中断上报，是保障超大规模集群运维可视性与高可用的关 键。
面向 AI 计算的核心优化体现在硬件级集合通信加速（CCA）。交换芯片需内嵌专用引擎，能卸载并执行包括 FP8、FP4 在内的多精度归约计算，明确支持单次最多 128 节点、4KB 数据包的集合操作。为此，它需分配 专用缓存与虚拟通道，并实现从超时检测、生成异常报文到上报 GPU 的完整容错链，从而将 GPU 从通信协 调负担中解放出来，显著提升分布式训练效率。
OISA 对 GPU 的核心要求，旨在将其从一个孤立的高性能计算单元，彻底转变为深度集成、可全局调度、具 备网络感知能力的智算节点。其重点并非仅提升单卡算力，而是确保 GPU 能在一个庞大、统一的集群中高效、 可靠、透明地协同工作。
首要重点是实现硬件级的通信与计算融合。GPU 必须内嵌完整的 OISA 协议栈，其通信行为需严格遵循规范， 例如生成的报文载荷不得超过 8KB。尤为关键的是对集合通信加速（CCA）的硬件支持：GPU 需能作为成 员参与多达 128 个节点的归约操作，直接生成和处理包括 FP8、FP4 在内的多种低精度数据，并与交换芯片 协同完成计算卸载。这要求 GPU 具备专用的缓存管理与地址映射机制，以配合网络侧完成高效的归约计算， 从而将自身从繁重的通信协调开销中解放出来。
其次，OISA 强制要求 GPU 支持全局统一内存寻址（UMA）与 I/O 一致性模型。这是实现“内存池化”和简 化编程模型的基石。GPU 必须能够识别并访问集群中任何其他设备（如其他 GPU）的内存，此过程依赖于 全局地址映射表，并通过 MMU/IOMMU 进行安全的地址转换与权限检查。为确保数据一致性，GPU 硬件必 须原生支持针对远程地址的原子操作，并严格执行分层级的内存栅栏指令，以保障跨设备数据操作的顺序与可 见性，为分布式训练提供如同单机一样的编程语义。
最终，所有这些能力的实现都依赖于深度的软硬件协同。GPU 的硬件负责高效执行底层操作，如协议封装、 地址转换和原子性保证；而驱动、运行时等软件栈则负责管理系统级的资源映射、同步原语并提供简洁的 API。 OISA 通过这一整套设计，使 GPU 超越了传统的“加速卡”角色，成为可被网络智能调度、具备全局内存视 角、并能与交换芯片协同完成计算任务的核心智能算力单元，从而支撑起大规模 AI 集群的高效运转。
NVLink 是英伟达（NVIDIA）开发的一种高速互连总线及通信协议，采用点对点结构与串行传输技术，主要 用于实现 CPU 与 GPU 之间，以及多个 GPU 之间的高效互联，显著提升数据传输带宽与通信效率，广泛应 用于高性能计算（HPC）、人工智能训练和数据中心等领域。NVlink 是英伟达的专有协议，没有标准化组织 支持，英伟达 2025 年开始通过 NVlink Fusion 计划向部分合作伙伴授权 NVlink 技术，但其核心协议仍保持 私有性质。本章节仅对 NVlink 已公开的技术特性进行介绍。
英伟达于 2014 年推出 NVLink 技术，历经六代演进，从第一代 160GB/s 带宽到第六代 3.6TB/s 带宽，NVLink 实现了超过 22 倍的性能提升。第六代 NVLink 于 2026 年 1 月随 Rubin 架构的 R200 GPU 正式发布，是当 前最新的 NVLink 技术版本。同时衍生出 NVLink-C2C 等专用版本，适配不同异构计算场景。
表17 NVLink 各代技术参数对比
| 参数 | NVLink 1.0<br><br> | NVLink 2.0<br><br> | NVLink 3.0<br><br> | NVLink 4.0<br><br> | NVLink 5.0<br><br> | NVLink 6.0<br><br> |
|---|---|---|---|---|---|---|
| 发布时间 | 2016年 | 2017年 | 2020年 | 2022年 | 2024年 | 2026年(预 计) |
| 支持架构 | Pascal | Volta | Ampere | Hopper | Blackwell | Rubin |
| SerDes速率 | 20Gbps | 25Gbps | 50Gbps | 112Gbps | 224Gbps | 双向 224Gbps |
| 参数 | NVLink 1.0<br><br> | NVLink 2.0<br><br> | NVLink 3.0<br><br> | NVLink 4.0<br><br> | NVLink 5.0<br><br> | NVLink 6.0<br><br> |
|---|---|---|---|---|---|---|
| 编码方式 | NRZ | NRZ | NRZ | PAM4 | PAM4 | PAM4 |
| 单链路双向带宽 | 40 GB/s | 50 GB/s | 50 GB/s | 50 GB/s | 100 GB/s | 200 GB/s |
| 每GPU最大链 路数 | 4 | 6 | 12 | 18 | 18 | 18 |
| 每GPU总双向 带宽 | 160 GB/s | 300 GB/s | 600 GB/s | 900 GB/s | 1,800 GB/s | 3,600 GB/s |
| NVSwitch 支 持 | 无 | 第一代 (32 端口) | 第二代 (64 端口) | 第三代 (64 端口) | 第四代 (72 端口) | 第五代 (72 端口) |
| 主要特点 | 首次推出， 支持 GPU-CPU 互联 | 引入 NVSwitch, 支持 8GPU 全 连接 | 速率翻倍， 链路数翻 倍 | 采用 PAM4, 带 宽提升 50% | 速率翻倍，带 宽翻倍，支持 NVLink-C2C | 速率再次翻 倍，带宽达 3.6TB/s |
NVLink 采用精简的三层协议栈设计（物理层、数据链路层、事务层），基于专有的高速信令互连 NVHS （NVLink High Speed）技术构建。
物理层核心依赖高速 SerDes（串行器/解串行器）技术，采用差分信号对传输，支持多速率自适应与极性/通 道反转，减少 EMI 干扰。链路基础单元为 sub-link（8 对差分线，单向），多条 sub-link 可堆叠形成双向 link， 提升带宽；编码方式随版本升级，NVLink 1.0 和 2.0 使用 NRZ 编码， 4.0 以后使用 PAM4 编码，实现带宽 翻倍；引入时钟数据恢复（CDR）与自适应均衡技术，确保高速传输下的信号完整性。
图130 NVLink 示意图 94
如上图所示，每个 NVLink 是一个双向接口，由 8 个差分对组成，总计 32 条线。
数据链路层位于物理层之上，负责数据的可靠传输、错误控制与链路管理，采用 CRC 校验和选择性重传机制。 数据链路层采用 flit（flow control digit） 作为基本传输单元，基于信用机制 (credit-based flow control)的 双向流量控制，防止接收端缓冲区溢出，确保链路高效利用。
数据链路层特性参数：
事务层负责事务包封装、地址映射与一致性协议管理。采用“固定包头+可变数据”的事务包（TLP）格式， 支持内存事务（读/写，64 位寻址）、I/O 事务（兼容 PCIe 生态）与原子事务；基于目录式 MESI-like 协议， 以 GPU 的 L2 缓存作为一致性节点，实现 GPU 间全版本缓存一致性，NVLink 2.0+支持 CPU-GPU 基础 一致性，NVLink-C2C 实现完整系统级一致性；配合 CUDA 统一内存，自动管理数据迁移与一致性。
2018 年，英伟达 推出了 NVLink Switch 技术，实现了在 8 个 GPU 的网络拓扑中每对 GPU 之间高达 300 GB/s 的 all-to-all 带宽，为多 GPU 计算时代的 scale-up 网络奠定了基础。随后，在第三代 NVLink Switch 中引入了 NVIDIA 可扩展分层聚合与归约协议（SHARP）技术，进一步提升了性能，有效优化了带宽性能并 降低了集合操作的延迟。
2022 年，英伟达将 NVSwitch 芯片独立出来，并制作成 NVLink 交换机，用于连接主机之间的 GPU 设备。 NVSwitch 物理交换机将多个 NVLink GPU 服务器连接成一个大型 Fabric 网络，即 NVLink 网络，解决了 GPU 之间的高速通信带宽和效率问题。每个服务器都有独立的地址空间，为 NVLink 网络中的 GPU 提供数
据传输、隔离和安全保护。NVLink 在系统启动阶段执行连接建立，也可以在软件通过运行时 API 调用时建立 连接。实现网络随服务器上下线、用户接入与退出实时动态重配置。
英伟达 NVL72 互联如下所示： 每个 B200 芯片有 18 个 NVLink 端口，每个端口连接一个 NVSwitch 芯片，整个系统 18 颗 NVLink Swtich 芯片 72 个端口，72 颗 B200 芯片实现全互联。
图131 NVL72 互联拓扑 95
NVLink-C2C （Chip-to-Chip）是指基于 NVLink 协议的、用于芯片到芯片 极近距离高速互连的物理封装 和连接技术。它能够在单个封装中将两个处理器连接成一块超级芯片。例如可以通过连接两块 CPU 芯片，使 Grace CPU 超级芯片具有 144 个 Arm Neoverse V2 核心。还可以将 Grace CPU 和 Hopper GPU 连接 成 Grace Hopper 超级芯片，将 CPU 和 GPU 的计算能力集合到一块芯片中。它提供了统一的缓存一致性 内存地址空间，将系统和 HBM GPU 内存融合在一起，极大简化了编程体验。通过先进封装和单端并行信号 设计，实现 900GB/s 双向带宽。
关键特性：
NVLink Fusion 技术可让定制芯片（包括 CPU 和 XPU）与 NVIDIA 的 NVLink scale-up 网络技术以及机 架级扩展架构相集成，从而实现半定制化的 AI 基础设施部署。
NVLink Fusion 为定制 CPU、定制 XPU 或两者的组合配置提供了灵活的解决方案。作为模块化开放计算项 目（OCP）MGX 机架架构的一部分，NVLink Fusion 可与任何网卡（NIC）、数据处理器（DPU）或横向扩 展交换机集成，使客户能够根据需求灵活构建理想的系统。技术的核心是“有控制的开放”，既允许合作伙伴 定制芯片，又通过 NVLink 的技术绑定保持 NVIDIA 在 AI 生态中的主导地位。
NVLink Fusion 的技术架构基于 NVIDIA 的 NVLink 5.0，通过两种方式实现异构芯片的互联：
第三方定制 CPU（如富士通 Monaka、高通定制 CPU）可通过 NVLink IP集成到 CPU 设计中，实现与 NVIDIA GPU 的高速互联。例如，富士通的 Monaka 处理器通过 NVLink Fusion 与 NVIDIA GPU 连接，带宽可达 PCIe 5.0 的 14 倍（约 128GB/s），显著提升 CPU-GPU 协同效率。2026 年 1 月，英特尔宣布其定制 CPU 将支持 NVLink Fusion。
NVIDIA 的 Grace 或未来的 Vera CPU 可通过 NVLink Fusion 与第三方加速器（如 ASIC）互联。这需要 在加速器设计中集成 NVLink IP，或在封装中加入支持互联的 chiplet（小芯片）。例如，NVIDIA 的 Grace CPU 可与第三方 ASIC 通过 NVLink 互联，构建“NVIDIA CPU+定制 ASIC”的混合系统。
需要注意的是 NVLink Fusion 并非完全开放：
• 必须使用 NVIDIA 的 NVLink IP 或芯片（如 Grace CPU、NVLink Switch），否则无法实现高速互联； • 无法将非 NVIDIA 芯片（如 Intel CPU）直接连接到非 NVIDIA 芯片（如 AMD GPU），必须有至少一方
是 NVIDIA 芯片。
NCCL 是 Nvidia Collective multi-GPU Communication Library 的简称，NVIDIA 集合通信库 (NCCL) 可 实现针对 GPU 和网络进行性能优化的多 GPU 和多节点通信基元。NCCL 提供了 all-gather、all-reduce、 broadcast、reduce、reduce-scatter、point-to-point send 和 receive 等例程，这些例程均经过优化， 可通过节点内的 PCIe 和 NVLink 高速互联以及节点间的 IB 网络实现高带宽和低延迟。
主要特性：
NCCL 中，每个参与通信的进程被定义为一个 “rank”，并分配全局唯一的 rank ID 作为身份标识。多个可互 相通信的 rank 共同组成通信器（communicator）。单个进程可同时加入多个 communicators，且在不同 communicators 中可拥有不同的 rank ID；每一个参与通信的 GPU 设备，都必须创建对应的 NCCL communicators 对象实例，才能进行通信操作。
NCCL 面向用户主要提供 4 大模块：
NCCL 针对单节点内的多 GPU 通信，设计了分层化的传输架构，核心原则是优先选用同物理机内 GPU 间延 迟最低、带宽最优的传输路径。这套传输策略的核心基础是 NVIDIA 的 GPUDirect P2P 技术，该技术可让 GPU 直接读写节点内其他 GPU 的显存空间，无需经过 CPU 系统内存做中转拷贝。
图132 节点内数据传输路径 97
节点内数据传输主要包含三类核心路径，分别为 P2P (DIRECT)、P2P (IPC/CUMEM) 和 SHM 共享内存传 输：
节点间通信负责协调不同物理服务器节点上 GPU 之间的数据交互，完整的通信流程涉及三大核心组件：GPU 端负责执行 NCCL 通信内核、CPU 端的代理线程负责管理网络操作，以及底层网络硬件与驱动构成的通信底 座。
图133 节点间数据传输路径 98
节点间主要包含两种核心传输路径，分别为基于 InfiniBand (IB) 的高性能传输，与基于 Socket 的通用传输， 其中 IB 路径可通过 GPUDirect RDMA 实现 GPU 显存与网卡之间的直接数据传输，而 Socket 路径则需要 通过主机内存作为中转完成数据拷贝。
NCCL 可智能识别集群的网络硬件拓扑，为多 GPU 分布式环境动态选择最优的通信策略。
Ring 算法是 NCCL 中实现多 GPU 通信的基础核心算法。该算法会为参与通信的 GPU 构建一个逻辑环形拓 扑，每个 GPU 仅与环上直接相邻的两个上下游 GPU 完成数据收发。这种设计让数据在环上逐跳传递，直至 完成完整的通信流程，凭借其简洁的实现逻辑与对等的通信特性，为中小规模 GPU 集群提供了高效稳定的通 信方案。
但 Ring 算法并非适用于所有场景，实际使用中需要在通信延迟与带宽利用率之间做针对性权衡。例如基于 Ring 实现的 AllReduce 操作，在小数据量传输场景下，往往会出现延迟偏高、带宽利用率不足的问题。同时， GPU 间的物理连接拓扑存在显著的异构性，也会直接影响 Ring 算法的表现：单节点内的 GPU 通常通过 NVLink 高速互联，而节点间则多依赖 InfiniBand 网络，不同硬件厂商的服务器拓扑设计差异，也进一步提升 了 Ring 算法的优化难度。
Tree 算法的核心实现为双二叉树（double binary tree）架构，其设计核心是利用二叉树中近半数节点为叶 子节点的特性，通过节点角色的转换构建出两棵互补的二叉树，确保每个节点在其中一棵树上为叶子节点，在 另一棵树上则为非叶子节点。偶数节点数时，第二棵树通过镜像第一棵树生成；奇数节点数时，则通过单位置 偏移的方式构建。这种设计让 Tree 算法在理论上能获得比 Ring 算法更低的通信延迟（时间复杂度 log2N 远 低于 Ring 算法的 N），适合小数据量的低延迟通信场景。
图134 节点间数据传输路径 99
CollNet 算法是基于 NVIDIA SHARP 技术打造的专用算法，专为 InfiniBand（IB）高性能网络场景设计，通 过优化数据在网络中的传输与处理流程，大幅提升超大规模 GPU 集群的通信效率。
CollNet 算法的核心优势，在于其支持将集合通信中的计算任务卸载到网络交换机硬件中执行。该技术让交换 机直接参与数据的聚合（Reduce）计算过程，无需在 GPU 间完成全量数据的端到端传输，不仅大幅降低了 GPU 的计算与通信负载，还能显著优化网络带宽资源的利用率，降低集合通信的整体延迟。
NVLS 系列算法专为搭载 NVSwitch 硬件的平台设计，可深度调用 NVSwitch 内置的 SHARP 功能，实现更 高效率的集合通信操作。
标准 NVLS 与 NVLS Tree 算法，均会调用 NVSwitch 的 SHARP 计算引擎完成节点内的数据归约计算：以 AllReduce 操作为例，节点内的 GPU 只需将数据写入 NVSwitch 的输入端口，由 SHARP 引擎完成硬件级 的归约计算后，再通过硬件多播能力将最终结果同步至所有 GPU。二者的核心差异体现在跨节点通信的处理 逻辑上：NVLS 算法会继续通过 CollNet 协议与支持 SHARP 的交换机，完成跨节点的归约计算；而 NVLS Tree 算法则在节点间采用 Tree 算法完成数据分发。这种设计让 NVLS Tree 既保留了 NVLS 算法极致的单 节点通信性能，又解决了大规模集群下跨节点通信的扩展性问题。
NCCL 内置了 Simple、LL、LL128 三种核心通信协议，分别针对不同的通信场景做了深度优化，以平衡传 输带宽与通信延迟的核心需求，运行时会根据硬件环境与数据规模自动选择最优协议。
Simple：这是 NCCL 的基础通信协议，核心设计目标是最大化带宽利用率，专为大数据量传输场景优化。通 过大分块的数据传输策略，充分释放网络与 GPU 显存系统的吞吐能力，能实现接近链路峰值的带宽利用率， 是 NCCL 处理大消息时的默认选择。
LL（Low Latency）：即低延迟协议，专为小数据量传输场景优化。当传输数据量较小时，传统协议的同步开 销会成为性能瓶颈，LL 协议通过轻量化的基于标志位的同步机制，大幅降低同步耗时。该协议基于 CUDA 的 8 字节原子存储操作实现，将传输单元封装为 “4B Data+4B Flag” 的结构，接收端通过校验标志位即可确认 数据有效性。
LL128：这是在 LL 协议基础上的增强优化版本，专为 NVLink 高速互联场景设计，同时兼顾了低延迟与高带 宽两大核心需求。和 LL 协议一致，它同样采用标志位同步机制，但将传输单元扩大至 128 字节，其中 120 字 节为有效数据，仅 8 字节为标志位，有效数据占比可达 93.75%，带宽利用率最高可接近链路峰值。在带有 NVLink 的机器上，NCCL 会默认使用该协议。
NCCL 的拓扑检测流程以 ncclTopoGetSystem () 函数为入口启动，全面采集当前节点内 GPU、网卡等各 类硬件设备的物理连接信息。会从 Linux 系统的 sysfs 虚拟文件系统中，读取完整的 PCIe 设备层级结构，包 括 PCI 域号、总线号、设备号、功能号（BDF 地址）等关键标识，同时会检测并记录设备的 NVLink 支持能 力、PCIe 链路速率与链路宽度等核心性能参数。
检查设备是否支持 NVLink、PCIe 链路速度和链路宽度等参数。
完成本地硬件信息采集后，NCCL 会通过 AllGather 集合通信原语，将集群内各个 GPU 进程采集的本地拓 扑信息进行汇总，构建出整个集群的全局硬件拓扑视图。最终集群内的每一个 rank，都能获取到全集群所有 GPU、网卡的物理位置与连接关系信息。
基于全局拓扑信息，NCCL 会构建出树形结构（通常以 XML 格式描述），完整还原设备间的物理连接关系。 同时会综合链路带宽、传输跳数等核心指标，计算出所有 GPU 与网卡之间的最短、最优通信路径，并精准识 别 NVLink、PCIe、InfiniBand、RoCE 等不同类型的互联链路，为后续通信优化提供依据。
基于完成的拓扑建模结果，NCCL 会为通信操作自动选择最优传输路径，例如优先选用 NVLink 链路而非 PCIe 链路完成数据传输；同时会根据实际的硬件拓扑结构，动态调整通信算法与通道分配策略，确保通信性 能与硬件能力最大化匹配。
SHARP 全称 Scalable Hierarchical Aggregation and Reduction Protocol（可扩展分层聚合与归约协议）， 是英伟达打造的网络内计算（In-Network Computing）技术。其核心目标是加速 AI/HPC 场景中高频的集 合通信操作（如 AllReduce、Reduce、Broadcast 等），通过将集合通信操作从 GPU/CPU 端侧完全卸载 到网络交换机（或 NVSwitch）硬件引擎中执行，减少网络数据传输量、降低延迟，提升分布式计算任务的 整体性能。 实现机制：
与 NCCL 集成：NCCL 可与 CUDA、网卡驱动、NCCL-SHARP 插件等配套软件栈联动，通过标准化的库 接口直接调用 SHARP 能力，将核心的集合通信操作卸载到网络设备中执行，实现通信性能的跃升。同时， NCCL 的拓扑感知能力可动态识别集群内的节点状态、链路状态，优化数据聚合路径与硬件卸载策略。
UALink 协议由 Ultra Accelerator Link Consortium 组织牵头开发，其核心成员汇聚了全球产业链各领域的 巨头企业，包括 AMD、Astera Labs、AWS、Cisco (思科)、Google (谷歌)、HPE (慧与)、Intel (英特尔)、 Meta、Microsoft (微软)、阿里云(Alibaba Cloud)、Apple (苹果)、Synopsys (新思科技)。
UALink 协议的核心使命十分明确：建立一套开放、可扩展、高性能、高可靠且低成本的 AI 加速器 Scale-up （纵向扩展）互联标准。它依托目前已非常成熟的以太网生态，打造能够跨厂商、支持大规模部署、实现高效 协同的 AI 集群互联体系，最终替代英伟达封闭的专有互联方案，重塑整个 AI 算力基础设施的格局。
UALink 协议与我们之前提到的 OISA、ETH-X、SUE 等 Scale-up 协议，虽然都基于以太网技术，但在技 术实现上有显著区别，主要集中在以太网层的使用、帧格式与相关机制，以及转发机制三个核心方面。
OISA、ETH-X、SUE 等协议在使用以太网时，会同时用到以太网的物理层（负责信号传输）和数据链路层 （负责数据帧的封装与传输控制），并且这些协议在数据链路层的帧格式、LLR（链路层重传机制）、CBFC （拥塞控制帧）的帧格式及实现机制上基本一致。
而 UALink 协议仅使用了以太网的物理层，其数据链路层的相关实现与上述协议完全不同——无论是帧格式， 还是 LLR、CBFC 的实现机制，都有自身独特的设计，这也是 UALink 与同类协议最基础的区别。
UALink 与 OISA、ETH-X、SUE 等协议的核心目标是一致的，都是实现 AXI 或 UPLI 操作在不同节点（如 GPU）之间的传递，但两者的转发方式差异极大。为了方便大家理解，我们用“交通运输”的场景做一个通 俗比喻，清晰区分两种转发机制的不同。
当 GPU 发出 AXI 操作指令时，这些协议会先识别每个指令的“目的地”——也就是目的 GPU 的 ID，然后 将去往同一个目的地的一个或多个指令，装载到不同的“小车”上（这里的“小车”对应协议中的事务层报文）。 需要注意的是，每一辆“小车”（一个事务层报文）只负责运送去往一个目的 GPU ID 的信号。
此时，Scale-up 交换机的作用就类似于交通路口的信号灯：它不需要拆开“小车”查看内部货物，只需要根 据每辆“小车”上标注的目的地（目的 GPU ID），将“小车”从进入交换机的端口，引导到去往对应目的地 的出端口，完成转发即可。
UALink 协议处理 GPU 发出的 UPLI 操作指令（功能类似 AXI 操作指令，可理解为 UALink 定义的“内存读 写（Read/Write/Atomic）指令”）时，采用了完全不同的处理思路：它不识别每个信号的目的 GPU ID，而 是将同一个端口收到的所有信号，全部装载到一辆“公共汽车”上（这里的“公共汽车”也是 UALink 的事 务层报文）。也就是说，一辆“公共汽车”（一个事务层报文）中，会包含去往多个不同目的 GPU ID 的指令。
对应的，Scale-up 交换机的作用也发生了变化：它不再是简单的“信号灯”，而是需要在“站台”（交换机入 端口）先将“公共汽车”上的所有“乘客”（指令）全部卸下来，逐一查看每个“乘客”的目的地（目的 GPU ID），再将这些“乘客”重新分配到去往不同目的地的下一辆“公共汽车”的站台上；下一辆“公共汽车”到 站后，再从对应的“站台”（交换机出端口），载上所有的“乘客”（指令），驶向下一个目的地，以此完成转发。
UALink 的“公共汽车运输模式”与同类协议的“小车运输模式”相比，有明显的优势，也存在一定的额外开 销，我们分别进行说明，方便大家全面理解。
导致交换机出端口瞬间拥塞，出现“头阻塞”（即前面的报文堵塞，后面的报文无法正常转发）。UALink 系统需要依靠交换机的 Buffer（缓冲区）来暂时存储拥堵的报文，平滑瞬间的 in-cast 拥塞，避免 影响整个 AI 集群中各 GPU 之间的正常通信。若出现持续的 in-cast 拥塞，需从应用软件设计层面 进行优化以规避该问题。
综上，UALink 协议在设计思路上，不仅与 OISA、ETH-X、SUE 等同类 Scale-up 协议存在显著差异，与 UB、CXL 等其他互联协议也有所不同。本章对 UALink 协议的开发背景、核心使命及与同类协议的差异进行 了详细讲解，目的是帮助大家从全新的视角理解 Scale-up 网络，掌握一种实现 Scale-up 网络的新方法， 为后续深入学习 UALink 协议的细节奠定基础。
UALink 协议作为 AI 加速器 Scale-up 互联的标准之一，其设计核心是实现不同系统节点之间，加速器与加 速器的高性能、低时延、无损通信，让 AI 集群中的多个加速器能够协同工作、高效配合。本章将详细介绍 UALink 协议的主要功能、组网方式，以及协议栈各层级的具体作用，帮助大家全面理解 UALink 协议的实现逻辑与 核心架构，为后续学习打下坚实基础。
UALink 协议的核心功能主要集中在内存语义处理和集合通信两大方面，具体可分为以下两点，大家结合 AI 集群的工作场景就能轻松理解：
第一，支持直接内存读、写及原子事务，这是加速器之间实现数据交互的基础能力。我们知道，AI 集群运行 时，不同加速器之间需要频繁地读取、写入彼此的内存数据（比如共享模型参数、交互中间计算结果）。而原 子事务的作用，就是保障跨加速器正确地访问内存，如同在一个加速器中，从而为 AI 模型的稳定、高效的并 行运行提供保障。
第二，协议处于持续迭代优化中，功能不断扩展。目前，UALink 2.0 版本正在开发中，相比现有版本将增加 “集合通信”功能，在交换机实现“在网计算”功能值得重点关注。简单来说，“在网计算”就是让数据在传 输过程中，直接在交换机上完成归约的计算，不用把所有数据都传到加速器后再进行运算。这样一来，能大大 减少数据传输的总量，进一步降低时延，让整个 AI 集群的处理效率再上一个台阶。
UALink 协议的组网拓扑，本质就是围绕“加速器与交换机如何连接”来设计的，目的是实现大规模加速器的 高效互联，满足 AI 集群对通信可靠性和带宽的需求。其结构特点非常清晰（可参考下图），我们分两点来拆解：
图135 UALink 多加速器系统
首先，每个加速器会配备 N 个端口，每个端口分别连接到不同的交换机。这种设计相当于为加速器之间的通 信，搭建了多个独立的“数据通道”（也就是我们说的交换平面）。这样做有两个明显的好处：一是提升可靠性， 即使其中一个“通道”（交换平面）出现故障，其他“通道”也能正常工作，不会导致整个通信链路中断；二 是提升带宽，多个“通道”可以同时传输数据，减少单一链路的拥堵，避免出现数据传输“排队”的情况。
其次，组网中使用的交换机，有一个关键参数——Radix（交换机总端口数），它的数值 M 决定了单台交换机 最多能连接多少个加速器。根据 UALink 协议的规定，目前 M 的最大值为 1024，也就是说，单台交换机最 多可以连接 1024 个加速器。根据当前 UALink 的组网设计，一个 UALink Scale UP 系统最多支撑 1024 个 加速器协同工作，当前可以满足超节点 Scale UP 组网需求，超过 1K 规模的超节点，可以考虑使用 Scale OUT 组网或未来协议的升级。
UALink 协议栈采用“分层设计”，每一层都有明确的分工，层层协同，完成从加速器到加速器 UPLI 所需要 实现的内存访问功能。协议栈从上至下，依次分为协议层（Protocol Layer）、事务层（Transaction Layer）、 数据链路层（Data Link Layer）和物理层（Physical Layer）（如下图）。下面我们逐一讲解每一层的具体作 用，大家重点记住“每一层做什么、和上下层如何配合”即可。
图136 UALink 协议栈
协议层是 UALink 协议的“顶层接口”，全称为 UALink 协议层接口，简称 UPLI，它的位置在 GPU 加速器 和 UALink 引擎之间，核心作用非常简单：搭建一个“桥梁”，实现加速器与 UALink 引擎之间的数据和控制 信息交互。
具体来说，UPLI 定义了一套标准的“沟通规则”（指令），设备之间通过这套规则，用“请求（Request）” 和“响应（Response）”的方式完成交互：比如加速器要发送向内存写数据的指令，就通过 UPLI 把请求传 给 UALink 引擎；UALink 引擎处理完请求后，再通过 UPLI 把写内存的结果反馈给加速器。
这里有一个小知识点可以帮助大家记忆：UPLI 的位置，和我们之前学习的 SUE、OISA、ETH-X 协议中 AMBA AXI 接口的位置是一样的，功能也基本相同，都是负责连接 GPU 内部的 NOC（片上网络）和 Scale UP IO 引擎。而 UALink 明确了 UPLI 接口的全部内容，便于不同厂商加速器只要都采用相同的 UPLI 接口， 就可以实现互联互通，如果定义不完整，就会导致因出现各厂商自己定义的私有接口，而无法互通。
事务层是整个协议栈的“核心环节”，相当于数据传输的“打包和解包中心”，主要负责读懂上层指令并封装为 报文，同时也可以把下层报文解封装为上层可以识别的指令。它的上下行接口分工明确，我们结合“数据流向” 来讲解，更容易理解：
一路连接 GPU 加速器的“UPLI 发起端”，负责“主动通信”：比如本 GPU 要向其他 GPU 发送数 据或请求，就通过这个接口发送 Request（请求）消息；同时，其他 GPU 对本 GPU 的请求做出 的 Response（响应）消息，也通过这个接口接收。
另一路连接 GPU 加速器的“UPLI 完成端”，负责“被动通信”：比如其他 GPU 要访问本 GPU 的 资源，发送的请求消息会通过这个接口接收；本 GPU 处理完请求后，再通过这个接口向对方返回 Response（响应）消息。
− 一是采用标准化格式，保证 Scale UP IO 引擎与 Scale UP 交换机能够正确识别报文，并依据 报文中的信息完成相应处理，在交换机正确分发，在目的端恢复源端送来的动作和数据，供加 速器执行；
− 二是在有限的报文长度内，完整且高效地传输操作指令； − 三是在报文中携带流控信息，实现拥塞避免，保障传输稳定可靠。
数据链路层位于事务层和物理层之间，相当于数据传输的“二次打包+链路管控中心”，核心作用是对数据片 进行二次封装/解封装，同时负责链路控制和固件传输。为什么需要二次封装/解封装，主要是通过打包构建 640 字节 DL FLIT 大报文，可以提升 LLR（Link Layer Retry）的效率，同时 640 字节负载与 RS（544,514） FEC 的效率相关，640 字节正好可以在一个 FEC 码块中承载，FEC 效率高。具体功能我们依然结合数据流 向来看：
物理层是 UALink 协议栈的“最底层”，相当于数据传输的“物理通道”，核心任务就是实现数据的物理传输 ——把数据链路层发送的并行数字信号串行化，并通过物理介质（比如网线、光纤），实实在在地传到目标设 备上。它的设计遵循明确的行业标准，具体要求我们重点掌握两点：
第一，兼容性强：物理层基于 IEEE 802.3dj 标准设计，这意味着它能和现有的以太网物理传输技术兼容，不 用重新搭建全新的物理传输环境，降低了部署成本。
第二，支持多种传输速率：为了适配不同规模 AI 集群的需求，物理层支持两类基于 Serdes（串行器/解串器， 作用是实现高速信号的串行传输与并行转换）的以太网速率，大家不用死记硬背，了解分类即可：
• 基于 200G Serdes 的以太网：包括 200GBASE-KR1/CR1、400GBASE-KR2/CR2、
800GBASE-KR4/CR4；
• 基于 100G Serdes 的以太网：包括 100GBASE-KR1/CR1、200GBASE-KR2/CR2、
400GBASE-KR4/CR4。
这种多速率支持的设计，让 UALink 协议可以根据 AI 集群的实际需求（比如传输效率要求、成本预算），灵活 选择合适的传输速率，兼顾实用性和经济性。
在大规模 AI 集群中，不仅单个系统节点内部的加速器需要通信，不同系统节点之间的加速器也需要交互数据、 共享资源。UALink 协议通过“跨域地址转换”，实现了这一需求。这部分内容稍显复杂，我们分步拆解，结 合示例理解核心逻辑即可。
UALink 网络的一大核心优势，就是能支持多系统节点间的数据交互——既可以实现单个系统节点内部的加速 器通信，也能支撑不同系统节点之间的加速器互通（如下图 UALink 跨域地址转换模型所示）。而要实现跨节 点通信，关键就是解决“地址定位”问题：加速器访问不同系统域的内存时，需要使用对应的地址类型，同时 通过地址转换，找到目标内存的准确位置。
− 系统物理地址（System Physical Address, SPA）：专门用于访问“单个系统域”（比如一个独 立的 AI 服务器节点）内部的内存资源，相当于本地内存的“专属地址”，只在本系统域内有效， 能确保本地内存访问的精准性。
− 网络物理地址（Network Physical Address, NPA）：专门用于访问“不同系统域”之间的内 存资源，相当于跨域内存的“专属地址”，里面包含了地址句柄（相当于内存的“索引”）和目 标标识信息，能精准定位到其他系统域的内存。
− 全局扁平寻址模型：它的好处是不用进行复杂的域间地址映射，能简化地址转换流程，降低协议
部署和实现的难度，适合对地址转换效率有较高要求的场景。
这里有一个重要提醒，大家一定要注意：本章介绍的跨域地址转换模型，只是为了帮助大家理解核心逻辑 的“示例”，并不是强制要求。因为 UALink 交换机采用的是“基于标识的路由”机制——交换机只需要 根据请求中的源加速器标识、目标加速器标识，就能完成数据转发，不需要依赖固定的地址转换方法。但 是在发起端需要实现 NOC 中对系统物理地址的访问，转换为全网可以认识的网络物理地址，并从网络物 理地址中，找到对应的加速器标识，这个地址转换的过程是必须的，同时在完成端实现从网络物理地址到 系统物理地址的转换，也是必需的。因此，UALink 协议规范中，把地址转换方式定义为“实现可选项”， 开发者可以根据实际需求，灵活选择合适的转换方案。
下面我们通过一个典型的示例，一步步拆解跨域地址转换的全过程，结合流程记忆，更容易掌握（结合协 议规范示例）：
这里有一个非常重要的设计特点，大家容易产生误解，需要重点说明：UALink 协议没有实现缓存一致性 （Cache coherency）机制。
这并不是协议的设计缺陷，而是基于实际应用场景的合理选择。在大模型运行的场景中，用硬件实现跨加速器 缓存一致性机制，带来的收益并不高——反而会大大增加协议实现的复杂度，提高硬件成本。因此，UALink 协议选择不支持缓存一致性机制，把精力集中在核心的通信功能（大规模、低时延、高带宽）上，优化加速器 之间的通信效率，更符合 AI 集群的实际需求。
本章围绕 UALink 协议的核心架构，重点讲解了协议的主要功能、组网拓扑，以及协议栈各层级的作用，核 心知识点可以总结为以下几点，帮助大家梳理记忆：
通过本章的学习，大家已经掌握了 UALink 协议的核心实现逻辑，接下来我们将深入学习协议的细节和实际 应用。
UPLI 协议层接口（UPLI）
UPLI（UALink Protocol Layer Interface，UALink 协议层接口）是 UALink 协议栈最靠近加速器的顶层接 口，也是 GPU 与 UALink 引擎之间进行事务交互的统一入口。
本章将详细介绍 UPLI 的主从通信模式、接口定义、通道划分、数据流路径、路由机制、流量控制以及读 / 写 / 原子三类事务的完整行为，帮助你从顶层理解 UALink 如何实现加速器之间可靠、有序、低时延的通信。
UPLI 接口定义
UPLI 采用主从式通信模型：一端主动发起事务，另一端被动处理并返回响应。协议中对两类设备的定义如下：
在实际系统中，一块 GPU 既要主动访问其他 GPU，也要响应其他 GPU 的访问，因此每个 GPU 会同时拥有 两类 UPLI 接口：
• UPLI 发起端
负责本 GPU 向其他 GPU 发出读、写、原子等请求，并接收对方返回的响应。每一条请求都必须收到响 应，发起端通过事务标签（Tag） 将请求与响应一一匹配，确保一次内存读写事务的可靠闭环。
• UPLI 完成端
负责接收并处理其他 GPU 发送来的请求，执行本地操作后，向对方返回响应。 同时，每一个 UPLI 接口包含四条独立通道，分别承担不同方向、不同类型的数据传输：
这四路通道的设计思想与我们熟悉的 AMBA AXI 协议非常相似，便于已有片上总线基础知识的同学快速理解。
UALink 引擎内部集成了完整的协议栈处理逻辑，结构清晰、层次分明，如图所示。
图140 UALink 协议栈
……
SM SM
HBM
HBM
内存控 制器
内存控 制器
NOC
HBM
HBM
UALink Engine #0
UALink Engine #N
……
……
Scale UP ETH 0
……
Scale UP ETH N
图141 GPU 加速器内部的逻辑
其中计算 Core、内存都挂在 NOC 总线完成 AI 计算，同时计算 Core 也需要通过 NOC 总线联接各种外设， 并对各种外设提供标准化的接口。同时 NOC 作为 GPU 系统的核心技术，不断迭代，不便于公开全部接口， 因此定义了标准化的 UPLI 接口，即保持外设接口的稳定性，也屏蔽了 NOC 总线的技术复杂性和版本迭代， 持续支持未来各种外设通过此标准化接口与 NOC 总线连接。
UPLI 发起端：处理本 GPU 访问其他 GPU 的请求与响应。 UPLI 完成端：处理其他 GPU 访问本 GPU 的请求与响应。 UALink 引擎内部实现 UALink 事务层、数据链路层、物理层，最终通过以太网接口与 UALink 网络连接。
可以看出： UPLI 是协议的 “用户界面”，下层所有封装、转发、纠错，最终都是为了可靠完成一次 UPLI 事务。
图142 加速器间端到端 UALink 联接
两个加速器之间的完整通信分为请求路径与响应路径，且完全对称。
交换机在整个过程中按照 UPLI 指令转发，根据 UPLI 的目的加速器决定出口，一跳一跳接力，最终完成源 加 速器到目标 加速器 的读 / 写操作。
图143 32 加速器系统样例
一个 GPU 会拥有多个 UALink 端口（Port），每个端口对应一条独立链路，连接不同交换机,构成不同的交换 平面。为了让请求与响应能在大规模集群中精准送达（包括源 GPU ID、源 Port 号，到目的 GPU ID 的请求 可以精准送到目的 GPU，同时响应可以请准地送回源 GPU 和源 Port，而不会被源 GPU 的其他 Port 的 UALink 引擎处理），因此 UPLI 在通道中需要携带以下关键路由信息。
RdRspSrcPhysAccID RdRspDstPhysAccID RdRspPortID
WrRspSrcPhysAccID WrRspDstPhysAccID WrRspPortID
Port ID 只在本地链路有效，每经过一段链路都会重新生成，仅用于节点内部调度。但是 Port ID 依然非常重 要，如下图所示，对于源 GPU，拥有多个 UALink 以太接口，一个以太接口（协议里面称为 Station）对应 一个 UALink 引擎，同时一个以太网接口可以工作在 1 个 800G，2 个 400G，4 个 200G 的模式，此时这 个 800G、400G、200G 以太端口称为 Port。对 Port ID 标识的是 UPLI Req 对应的一个唯一的 UALink 引擎，以及引擎内的一个实例，联接一个唯一 Port，一个唯一的 UALink 交换平面。当目的 GPU 收到 UPLI 请求时，虽然 Port ID 已经变为内部收到此 UPLI 的 Port ID，但也标识了一个唯一的 UALink 交换平面，一 个唯一的 UALink 引擎 + 实例。GPU 处理此 UPLI 时会记录此 Port ID，并在响应时使用此 Port ID，送回此 UALink 引擎 + 实例，以及此引擎 + 实例对应的唯一的 Port ID，对应的唯一的 UALink 交换平面。最终这个 交换平面，也会将响应送回源 GPU，以及这个交换平面联接的唯一的源 Port ID，唯一的 UALink 引擎 + 实 例。
以加速器 0 访问加速器 31 为例：
图144 端到端报文处理流程
两个 UPLI 之间采用基于信用（Credit）的流量控制机制，保证链路与缓冲不会溢出。如下图所示，源加速器 A 和交换机入接口建立 UPLI 和 UPLI 之间的流控，交换机出端口和目的加速器 B 再建立 UPLI 和 UPLI 的流 控。交换机入出接口之间的流控，是交换机内部实现。
图145 流控机制
核心机制：
流程：
UPLI 支持三类核心事务：
• 通过 请求通道（Req） 发送一拍请求，包含：
源 / 目的 ID、端口 ID、Tag、地址、长度、属性等。
原子操作分为两类：
UPLI 的信号定义
UALink 协议层接口应按以下信号组进行组织：
表18 Common Signals
| Name | Size | 描述 |
|---|---|---|
| UPLIClk | 1 | 接口时钟，由 SOC 通用逻辑提供。UALink 协议层接口信号与该时钟以及 UPLIReset_N、ClkReq 和ClkAck 信号同步。 |
| UPLIReset_N | 1 | 接口复位信号，低电平有效，其置位与撤销均与 UPLIClk 同步。 |
事务可以是读操作、写操作或原子操作。这些事务从内存读取、向内存写入，或以原子方式修改内存，并可选 择返回内存中的原始值。
一个 UPLI 事务由多个周期（也称为拍 /beat）组成。 根据 UPLI 事务类型（读、写、原子）的不同，这些拍会按照特定顺序，在 UALink 协议层接口的一组特定物 理通道上传输：
事务由 UPLI 发起端（Originator） 发出，并由 UPLI 完成端（Completer） 处理完成。UPLI 完成端会通过 读响应 / 数据通道或写响应通道其中之一向请求返回响应。具体使用哪个通道返回响应，取决于事务类型；对 于原子操作，还额外取决于原子操作是否返回修改前的内存初始值。
读事务
写事务 待写入的数据通过发起端数据通道，以 1∼4 个数据拍 从发起端传送到完成端。每个数据拍包含：
原子请求 原子操作分为两类：
UPLI 具体定义了请求通道 Request Channel、读响应 / 数据通道 Read Response/Data Channel、写响 应通道 Write Response Channel、发起端数据通道 Originator Data Channel 的信号，以实现前述的读、 写和原子事务。具体定义可以查询 UALink 规格书。下面具体使用 Request Channel 的定义，让大家理解 一下定义的内容。
表19 请求通道信号
| Name | Size (bits) | Driver | 描述 |
|---|---|---|---|
| 请求通道信息与控制信号 | |||
| ReqVld | 1 | Originator | 请求有效。该信号指示发起端正在该通道上呈现有效信息（一 个 beat）。驱动请求通道的源加速器 ID 指示与该 TL Beat 关 联的端口 ID，该 Beat 要在请求通道上呈现。 |
| ReqPortID | 2 | Originator | 请求地址空间标识符。对于所有发起端，ReqPortID 指示请 求通道上的 TDM 周期。 |
| ReqASI | 2 | Originator | 请求地址空间标识符。对于不是 UPLI 写消息请求的任何请求， 此字段指定特定地址空间的地址。对于 UPLI 写消息请求，此 字段标识其他保留或特定于 UPLI 写消息的特定功能（UPLI 写 消息的类型在 ReqMetadata 字段中指定）。 |
| ReqAuthTag | 64 | Originator | 请求授权标签。请求的授权标签。当授权处于活动状态时，发 起端为此请求提供授权标签。当授权不活动时，物理加速器 ID 被置为无效。 |
| Name | Size (bits) | Driver | 描述 |
|---|---|---|---|
| ReqSrcPhysAccID | 10 | Originator | 源加速器 ID。请求的源物理加速器 ID。源加速器是发起端（发 起 UPLI 事务的加速器）内的物理加速器。 |
| ReqDstPhysAccID | 10 | Originator | 请求的目的加速器 ID。UPLI 完成器的物理加速器 ID，该完成 器将满足该请求。 |
| ReqTag | 11 | Originator | 请求标签。此标签用于唯一标识每个未完成的 UPLI 请求（在 源加速器 UALink 端口内，所有与该请求关联的站都共享此标 签）。 |
| ReqNumBeats | 2 | Originator | 事务中的数据拍数。在 UPLI 写消息请求中，发起端将此值设 置为要传输的数据拍数。对于读、原子和 UPLI 写消息请求， 传输的字节数是 (ReqNumBeats + 1)。此字段仅对原子和 UPLI 写消息请求有效。对于原子写请求（ReqCmd [5] = 1） 和 UPLI 写消息请求，此字段用于确定要传输的数据拍数。对 于 ReqCmd [5] = 0（原子读）的请求，此字段驱动为 0。 |
| ReqAddr | 57 | Originator | 对于不是 UPLI 写消息请求的任何请求，此字段指定请求的地 址。对于 UPLI 写消息请求，此字段指定其他保留或特定于 UPLI 写消息的特定功能（UPLI 写消息的类型在 ReqMetadata 字段中指定）。除非 UPLI 写消息类型定义了 此字段并在携带此消息的请求中指定，否则此字段为 0。 |
| ReqCmd | 6 | Originator | 请求命令。此字段指定此请求和此事务中要执行的操作的类 型。 |
| ReqLen | 6 | Originator | 请求长度。对于不是 UPLI 写消息请求的任何请求，此字段指 定要从 ReqAddr 地址开始读取的 64 位双字数量。对于 UPLI 写消息请求，传输器必须在一个事务中传输 4 字节的有效载 荷，因此此字段驱动为 0。 |
| ReqAttr | 6 | Originator | 请求属性。对于不是 UPLI 写消息请求的任何请求，此字段指 定与该请求关联的内存属性。对于 UPLI 写消息请求，此字段 标识其他保留或特定于 UPLI 写消息的特定功能（UPLI 写消息 的类型在 ReqMetadata 字段中指定）。 |
| ReqMetadata | 8 | Originator | 请求元数据。对于 UPLI 写消息请求，此字段指定特定 UPLI 写 消息的类型。对于不是 UPLI 写消息请求的任何请求，此字段 驱动为 0。 |
| ReqPC | 2 | Originator | 请求处理类别。此字段指定请求的处理类别。此值在交换机中 用于路由。除了在源加速器 UALink 端口中驱动此值外，发起 端在整个交换机中都不解释此值。 |
| ReqPool | 1 | Originator | 请求池。指定请求是使用池信用还是虚拟信道资源（0 = 池，1<br><br>= 虚拟信道）。 |
| 请求通道信用返回信号 | |||
| ReqCredVld | 4 | Completer | 信用有效。当且仅当相应端口的信用被返回时，此信号置为高。 信用返回信号不是时分复用（TDM）的；任何端口的信用都 可以在任意周期返回。 |
| ReqCredPool | 2 | Completer | 信用池。指示是池信用还是虚拟信道（VC）信用被返回。如 果 “0”，则返回的是池信用；如果 “1”，则返回的是虚拟 信道信用。 |
| ReqCredPortVC | 2 | Completer | 指示为此请求返回的虚拟信道（VC）或池信用。如果 ReqCredPool 为 0，则此字段指示为此请求返回的池信用； 如果 ReqCredPool 为 1，则此字段指示为此请求返回的虚拟 信道（VC）。 |
| Name | Size (bits) | Driver | 描述 |
|---|---|---|---|
| ReqCredPortVC2Num | 3 | Completer | 指示为此请求返回的虚拟信道（VC）或池信用。如果 ReqCredPool 为 0，则此字段指示为此请求返回的池信用； 如果 ReqCredPool 为 1，则此字段指示为此请求返回的虚拟 信道（VC）。 |
| ReqCredPortVC3Num | 2 | Completer | 指示为此请求返回的虚拟信道（VC）或池信用。如果 ReqCredPool 为 0，则此字段指示为此请求返回的池信用； 如果 ReqCredPool 为 1，则此字段指示为此请求返回的虚拟 信道（VC）。 |
| ReqCredPortVC | 2 | Completer | 指示为此请求返回的虚拟信道（VC）或池信用。如果 ReqCredPool 为 0，则此字段指示为此请求返回的池信用； 如果 ReqCredPool 为 1，则此字段指示为此请求返回的虚拟 信道（VC）。 |
| ReqCredPortNum | 2 | Completer | 指示为此请求返回信用的端口号（最多 3 个）。仅当 ReqCredVld 指示的端口有效时，此字段才有效。 |
| ReqCredPort2Num | 3 | Completer | 指示为此请求返回信用的端口号（最多 3 个）。仅当 ReqCredVld 指示的端口有效时，此字段才有效。 |
| ReqCredPort3Num | 1 | Completer | 指示为此请求返回信用的端口号（最多 3 个）。仅当 ReqCredVld 指示的端口有效时，此字段才有效。 |
| 请求通道奇偶校验信号 | |||
| ReqVldParity | 1 | Originator | 对每个请求有效信号 ReqVld 进行奇偶校验，每周期检查一 次。 |
| ReqAddrParity | 1 | Originator | 对请求地址 ReqAddr 进行奇偶校验。仅当 ReqVld 置为有效 时检查。 |
| ReqParity | 1 | Originator | 对以下信号进行奇偶校验：ReqASI、ReqAuthTag、 ReqCmd、ReqLen、ReqAttr、ReqTag、ReqNumBeats、 ReqVld、ReqSrcPhysAccID、ReqDstPhysAccID、 ReqPortID。仅当 ReqVld 置为有效时检查。 |
| ReqCredVldParity | 1 | Completer | 对每个信用有效信号 ReqCredVld 进行奇偶校验，每周期检 查一次。 |
| ReqCredParity | 1 | Completer | 对以下信号进行奇偶校验：ReqCredVld、 ReqCredPortNum、ReqCredPort2Num、 ReqCredPort3Num、ReqCredPortVC、 ReqCredPortVC2Num、ReqCredPortVC3Num、 ReqCredPool。仅当 ReqCredVld 非零时检查。 |
本章重点讲解了 UALink 最顶层的 UPLI 接口，它是整个协议的 “用户入口”，核心内容可总结为：
事务层
UALink 事务层（TL 层）主要完成两类数据转换工作：
将两个 UPLI 接口传入事务层的 UPLI 拍（Beat），进行格式转换，封装成事务层微片（TL Flit），并从发送方 向的 TL Flit 通道输出。
将从接收方向的 TL Flit 通道收到的事务层微片（TL Flit），解析还原为 UPLI 拍（Beat），并输出到两个北向 UPLI 接口，供上层模块使用。
图146 TL FLIT 与 UPLI 的连接
每个 64 字节的事务层 FLIT（TL Flit）被划分为高 32 字节与低 32 字节两个半 FLIT（Half Flit）；同时，该 64 字节事务层 FLIT 也可划分为 16 个 4 字节扇区（Sector）。
图147 TL Flit 组织架构
事务层 Half Flit 分为四种类型：控制 Half Flit、数据 Half Flit、消息 Half Flit、认证标签（AuthTags）Half Flit。 本文重点介绍最常用的控制 Half Flit 和数据 Half Flit，消息与认证标签相关定义可查阅 UALink 规格书。
控制 Half Flit 用于编码以下信息：
某个Half-Flit 是控制Half-Flit、还是数据Half-Flit ，并不在Half-Flit内部携带标识，而是通过接口上Half-Flit 的时序与顺序推导得出。
若某控制 Half-Flit 要求携带数据 Half-Flit（包含读响应字段、写请求字段或 AtomicR/AtomicNR 请求字段， 下文统称为 “数据请求字段”），则后续 Half-Flit 将被解析为数据 Half-Flit，直至满足数据请求字段所需的 Half-Flit 数量。
数据 Half-Flit 的顺序与控制 Half-Flit 中数据请求字段的顺序一致，从低位开始。
一个特殊处理：若控制Half-Flit所对应的最后一个数据Half-Flit本应出现在事务层FLIT的低Half-Flit位置， 则该最后一个数据 Half-Flit 将交换到该事务层微片的高 Half-Flit 位置，而低 Half-Flit 则被解析为下一个控 制 Half-Flit。
下面是一些 TL-FLIT 报文的举例，用来理解事务层的封装格式，并且这个格式需要包含 UIPLI 指令中所有的 控制和数据信号。
图148 一个 Write Full 256 字节请求和一个流控控制 Half FLIT
地址缓存是 UALink 事务层用于提升传输效率、降低链路带宽开销的关键优化机制，通过缓存通信地址实现请 求报文压缩，分为发送端地址缓存（Tx Address Cache）和接收端地址缓存（Rx Address Cache），二者 成对工作、严格同步。
发送方向的请求会先进入请求队列，然后查询发送端地址缓存，判断该地址是否已经发送过，并且已经缓存在 对端 UALink 事务层的接收端缓存中。
地址缓存属于可选功能：
先将地址加载到发送端缓存，同时发送非压缩请求，并通知对端将地址加载到接收端缓存。加载完成后， 后续相同地址的请求即可使用压缩请求。
若发送端缓存无法加载，或设计上选择不缓存该地址，则直接发送非压缩请求，并指示对端不加载接收端 缓存。
• 接收端缓存完全由发送端控制，与发送端缓存严格同步。
• 发送端缓存可随时清空或失效；清空后，在重新加载前不再发送压缩请求，接收端缓存也会同步重新加载。
为保证发送端与接收端缓存状态完全一致，必须遵循以下时序规则：
发送 CLOAD=1（加载对端缓存）的非压缩请求前，对应索引（缓存行）可用，即 Cache 路（CWAY） 的表项必须已加载，且在请求“已发出”前不能被其他请求覆盖。
控制 Half-Flit 内的请求根据请求的到达顺序，按低字节到高字节排列，保证接收端与发送端对缓存按正确 的顺序处理。
发送端与接收端缓存的刷新逻辑保持一致，由 CLOAD=1 与 CWAY 共同控制：
UALink 事务层（TL）之间的流量控制，通过以下两类信用（Credit）机制进行管理：
流量控制字段包含四类信用信号，如下表所示：
| 信号名称 | 描述 |
|---|---|
| Request CMD | 用于未压缩或压缩的 TL 控制 Half-Flit 中请求的信用。 |
| Response CMD | 用于未压缩或压缩的读响应（不含数据）或压缩写响应的信用。 |
| Request Data | 用于 64 字节数据缓冲区的信用，用于存放写、全写（WriteFull）请求、原子读 / 原 子非写（AtomicR/AtomicNR）命令及 UPLI 写消息的数据。字节使能由关联的 请求或数据缓冲区缓冲，因此不占用独立的请求或数据信用。 |
| Response Data | 用于 64 字节数据缓冲区的信用，用于存放读响应数据（不含字节使能）。 |
为了支持最坏情况下的写例程（Write Example），流量控制字段必须至少能返回 20 个请求数据信用和 5 个 CMD 信用。因此：
四类信号共占用 28 位，加上高 4 位的字段类型（FTYPE）标识，共同组成一个 32 位的单扇区流量控制字 段。
表20 流量控制 / 空操作字段（Flow Control/NOP Field）
| 名称 | 大小（位） | 位置 | 描述（中文） |
|---|---|---|---|
| FTYPE | 4 | [31:28] | 字段类型。该信号值为 0 时，表示此字段为流量控制 / 空操作（Flow Control/NOP）字段。 |
| ReqCmd | 6 | [27:22] | 请求命令。返回请求命令信用（即来自 UPLI 读 / 写 / 原子请求通道的 请求信用）。字段格式为 “tvvccc”，其中：<br><br>• t = 0 表示池信用，t = 1 表示虚拟通道信用（仅当 t=1 时，vv 有效）<br>• vv = 信用所属的虚拟通道<br>• ccc = 待返回的信用数量（0 到 7）。<br> |
| RspCmd | 6 | [21:16] | 响应命令。返回响应命令信用（即来自 UPLI 读响应（不含数据）和写 响应通道的响应信用）。字段格式为 “tvvccc”，其中：<br><br>• t = 0 表示池信用，t = 1 表示虚拟通道信用（仅当 t=1 时，vv 有效）<br>• vv = 信用所属的虚拟通道<br>• ccc = 待返回的信用数量（0 到 7）。<br> |
| ReqData | 8 | [15:8] | 请求数据。返回请求数据信用（即来自 UPLI 操作数 / 数据通道的信 用）。字段格式为 “tvvcccc”，其中：<br><br>• t = 0 表示池信用，t = 1 表示虚拟通道信用（仅当 t=1 时，vv 有效）<br>• vv = 信用所属的虚拟通道<br>• cccc = 待返回的信用数量（0 到 31）。<br> |
| RspData | 8 | [7:0] | 响应数据。返回响应数据信用（即来自 UPLI 读响应 / 数据通道的信 用）。字段格式为 “tvvcccc”，其中：<br><br>• t = 0 表示池信用，t = 1 表示虚拟通道信用（仅当 t=1 时，vv 有效）<br>• vv = 信用所属的虚拟通道<br>• cccc = 待返回的信用数量（0 到 31）。<br> |
| TOTAL BITS | 32 | 1 扇区 | — |
四类信用信号可独立选择表示池信用或虚拟通道信用。
在初始化阶段，事务层（TL）会为每类信用分配初始信用，这些信用可以是：
数据或原子操作数的信用会直接继承对应请求或响应的池和虚拟通道值，这些值在数据 Half Flit 中不会单独指 示。
当流量控制字段返回四类信用的数量均为 0 时，该字段即为 空操作字段（NOP Field），其值为 x00000000。
在一个 TL 控制 Half-Flit（Control Half-Flit）中，可包含以下几种字段类型，每种类型占用固定数量的 4 字 节扇区（Sector）：
| 字段类型 | 占用扇区数 |
|---|---|
| 未压缩请求（Uncompressed Requests） | 4 个扇区 |
| 未压缩响应（Uncompressed Responses） | 2 个扇区 |
| 压缩请求（Compressed Request） | 2 个扇区 |
| 单拍读响应的压缩响应（Compressed Response for Single-Beat Read） | 1 个扇区 |
| 写或多拍读响应的压缩响应（Compressed Response for Write or Multi-Beat Read Response） | 1 个扇区 |
| 流量控制 / 空操作指示（Flow Control/NOP Indication） | 1 个扇区 |
每个字段的高 4 位用于标识字段类型（Field Type），共支持 16 种可能的字段类型，同时也隐含了该字段内 部包含的扇区数量。
下表列出了控制 Half-Flit 字段类型高 4 位的合法编码：
表21 TL 控制 Half-Flit 消息类型值
| 字段类型高 4 位值 | 消息类型（Message Type） |
|---|---|
| 0x0 | 流量控制池 / 空操作指示（Flow Control Pool/NOP Indication） |
| 0x1 | 未压缩请求（Uncompressed Request） |
| 0x2 | 未压缩响应（Uncompressed Response） |
| 0x3 | 压缩请求（Compressed Request） |
| 0x4 | 单拍读响应的压缩响应（Compressed Response for Single-Beat Read Response） |
| 0x5 | 写或多拍读响应的压缩响应（Compressed Response for Write or Multi-Beat Read Response） |
下面重点介绍 0x1 未压缩请求和 0x2 未压缩响应的报文格式定义，便于理解事务层报文的格式定义。其他事 务层报文的格式定义，请参考协议的具体介绍。从 TL 控制 Half FLIT 的格式定义中，可以看出其 4 或 2 个 Sector（16-Byte 或 8-Byte）中包含了对应 UPLI 指令中所有的内容。
| Name | Size (bits) | Position | Description |
|---|---|---|---|
| FTYPE | 4 | [127:124] | 字段类型。该信号值为 0x01，表示该字段是一个非压缩请求 字段（Uncompressed Request Field）。 |
| CMD | 6 | [123:118] | 命令。该信号携带此请求对应的 UPLI ReqCmd 信号值。 |
| VCHAN | 2 | [117:116] | 虚拟通道。该信号携带此请求对应的 UPLI ReqVC 信号值。 |
| ASI | 2 | [115:114] | 地址空间标识符。该信号携带此请求对应的 UPLI ReqASI 信号值。 |
| TAG | 11 | [113:103] | 标签。该信号携带此请求对应的 UPLI ReqTag 信号值。 |
| POOL | 1 | [102] | 池。该信号指示事务层（TL）是使用池信用（Pool Credit） 还是虚拟通道信用（Virtual Channel Credit）来发送此请求。 该信号的值与 UPLI 接口上的 ReqPool 信号无关（TL 信用 管理独立于 UPLI 信用管理）。 |
| ATTR | 8 | [101:94] | 属性。该信号携带此请求对应的 UPLI ReqAttr 信号值。 |
| LEN | 6 | [93:88] | 长度。该信号携带此请求对应的 UPLI ReqLen 信号值。 |
| METADATA | 8 | [87:80] | 元数据。该信号携带此请求对应的 UPLI ReqMetadata 信 号值。 |
| ADDR | 55 | [79:25] | 地址。该信号携带此请求对应的 UPLI ReqAddr [56:2] 信号 值。这是一个双字对齐的地址。 |
| Name | Size (bits) | Position | Description |
|---|---|---|---|
| SRCACCID | 10 | [24:15] | 源加速器 ID。该信号携带此请求对应的 UPLI ReqSrcPhysAccID 信号值。 |
| DSTACCID | 10 | [14:5] | 目的加速器 ID。该信号携带此请求对应的 UPLI ReqDstPhysAccID 信号值。 |
| CLOAD | 1 | [4] | 缓存加载。当该信号为 '1' 时，表示接收端事务层（Rx TL） 应将 ReqAddr [56:20]（ADDR [54:18]）加载到 Rx 地址缓 存中，该缓存位于由 CWAY 指定的路（Way），以及由 SRCACCID [9:0]（用于加速器上的 Rx 缓存）或 DSTACCID [9:0]（用于交换机上的 Rx 地址缓存）指定的 行（Row）。当该信号为 '0' 时，Rx 地址缓存不加载。 |
| CWAY | 2 | [3:2] | 缓存路。该信号指定要加载的地址缓存中的路（Way），仅 当 CLOAD='1' 时有效。 |
| NUMBEATS | 2 | [1:0] | 拍数。该信号指示为此请求传输的数据拍数（Beats）。当 CMD [5] 为 '1' 时，用于传输原子操作数、写数据或全写 （Write Full）数据，或用于任何厂商自定义命令。 |
| TOTAL BITS: | 128 | 4 Sectors |
| Name | Size (bits) | Position | Description |
|---|---|---|---|
| FTYPE | 4 | [63:60] | 字段类型。该信号值为 0x02，表示该字段是一个非压 缩响应字段（Uncompressed Response Field）。 |
| VCHAN | 2 | [59:58] | 虚拟通道。该信号携带此响应对应的 UPLI RdRspVC 或 WrRspVC 信号值（由读 / 写信号决定）。 |
| TAG | 11 | [57:47] | 标签。该信号携带此响应对应的 UPLI RdRspTag 或 WrRspTag 信号值（由读 / 写信号决定）。 |
| POOL | 1 | [46] | 池。该信号指示事务层（TL）是使用池信用（Pool Credit）还是虚拟通道信用（Virtual Channel Credit） 来发送此响应。该信号的值与 UPLI 接口上的 ReqPool 信号无关（TL 信用管理独立于 UPLI 信用管理）。 |
| LEN | 2 | [45:44] | 长度。该信号携带 UPLI RdRspNumBeats 信号值（由 UPLI 读响应管理器决定）。该字段仅对多拍读响应有 意义；单拍读响应和所有写响应的长度始终为 1 拍，因 此这些字段应设置为 b'00'。 |
| Name | Size (bits) | Position | Description |
|---|---|---|---|
| OFFSET | 2 | [43:42] | 偏移。该信号携带 UPLI RdRspOffset 信号值，用于 单拍读响应。对于无数据返回的写响应（写响应）和多 拍读响应（TL 负责重建总线传输），该信号应设置为 b'00'。 |
| STATUS | 4 | [41:38] | 状态。该信号携带 UPLI RdRspStatus 或 WrRspStatus 信号值（由读 / 写信号决定）。 |
| RD/WR | 1 | [37] | 读 / 写指示符。该信号指示该响应是读响应（读、 AtomicNR 请求导致写响应，注意：AtomicR 请求导 致读响应）还是写响应。 |
| LAST | 1 | [36] | 最后。该信号仅对读响应有效，携带 UPLI RdRspLast 信号值。对于写响应，该信号应设置为 b'0'。 |
| SRCACCID | 10 | [35:26] | 源加速器 ID。该字段携带 UPLI RdRspSrcPhysAccID 或 WrRspSrcPhysAccID 信号值，具体取决于响应是读、写、全写，还是 AtomicR/AtomicNR 请求（由 TAG 标识）。注意： 响应中的 SRCACCID 值（如果携带）应等于请求中的 DSTACCID 值，以确保响应被路由到正确的请求方。 SRCACCID 字段在功能上不是必需的，实现可以选择 不在 TL 和 / 或交换机上携带该字段。当信号不包含准 确值时，应在相应的 UPLI 接口上驱动为零。 |
| DSTACCID | 10 | [25:16] | 目的加速器 ID。该字段携带 UPLI RdRspDstPhysAccID 或 WrRspDstPhysAccID 信 号值，具体取决于响应是读、写、全写，还是 AtomicR/AtomicNR 请求（由 TAG 标识）。注意： 响应中的 DSTACCID 值应等于请求中的 SRCACCID 值，这用于确保响应被路由回最初发出请 求的加速器。 |
| SPARE(S) | 16 | [15:0] | 该字段格式中有 16 位未分配。 |
| TOTAL BITS: | 64 | 2 Sectors |
如图所示，数据链路层位于事务层与物理层之间，下行可以将来自事务层的 TL Flit 打包为 640 字节数据链路 层 DL FLIT，供物理层使用。同理，上行可以将物理层的 640 字节 DL FLIT 解包为事务层 TL FLIT。此外， 数据链路层还在链路伙伴之间提供消息服务，此类消息在数据链路层发起并终结，不需要传递给事务层。
图151 数据链路层架构
图152 数据链路层 640 字节 DL FLIT 格式定义
如图所示，共 640 字节，其中：
显式序号 FLIT 头（Explicit Sequence Number Flit Header）：显式序号 FLIT（简称 “显式 FLIT”） 的头格式如下所示。其中包含完整的 9 位序号，不包含应答（Ack）或重传请求（Replay Request）指 示信息。
| Field | Bit | Description |
|---|---|---|
| Op | 23:21 | 当 payload = 0（NOP）时： 0b000：空操作FLIT（NOP Flit） 其他值：保留 当 payload = 1 时：<br><br>0b000：净荷FLIT的原始传输（"org"）<br>0b001：净荷FLIT的重传（"rpy"） 其他值：保留<br> |
| payload | 20 | 1：净荷FLIT（payload Flit） 0：空操作FLIT（NOP Flit） |
| reserved | 19:17 | 保留（Reserved） |
| flitSeqNo | 16:8 | FLIT序号（Sequence number of Flit），为完整的 9 位值 |
| reserved | 7:0 | 保留（Reserved） |
命令 FLIT 头（Command Flit Header），应答（Ack）或重传请求（Replay Request）。其中包含待 应答或未应答 FLIT 所对应的完整 9 位序号，同时还包含 FLIT 序号 flitSeqNo 的低 3 位，记为 flitSeqLo。
| Field | Bit | Description |
|---|---|---|
| op | 23:21 | 0b010：应答（Ack）<br>0b011：标准重传请求（Standard Replay Request "rpy"） 其他值：保留（Reserved）<br> |
| payload | 20 | 1：净荷FLIT（payload Flit） 0：空操作FLIT（NOP Flit） |
| ackReqSeq | 19:11 | 待应答的应答FLIT的完整序号，或重传请求的序号。该值为完整的 9 位值。 |
| flitSeqLo | 10:8 | FLIT序号的低 3 位。 注：由于Header空间有限，无法同时表示确认接收或需要重传的SeqNo， 以及正在发送的SeqNo，所以对正在发送的SeqNo使用SeqLo来表示。 |
| reserved | 7:0 | 保留（Reserved） |
长度可小于 128 字节，且部分段可包含备选扇区，因此部分事务层 FLIT 序列会跨段延续至下一段。定义 如下
| Field Name | Position | Description |
|---|---|---|
| DLAltSector | [0] | DL 备选扇区（DL Alternative sector）<br><br>0b - 段中无备选扇区<br>1b - 段中存在 DL 备选扇区<br> |
| Reserved | [1] | 保留（Reserved） |
| Message[0] | [3:2] | 事务层FLIT 0（TL Flit [0]）消息位指示符 若事务层FLIT 0（TL Flit [0]）不存在，则为保留位；否则为消息位指示 符 |
| TL Flit[0] | [4] | 事务层FLIT 0（TL Flit [0]）存在标识<br><br>0b - 事务层FLIT 0（TL Flit [0]）不存在<br>1b - 事务层FLIT 0（TL Flit [0]）存在<br> |
| Message[1] | [6:5] | 事务层FLIT 1（TL Flit [1]）消息位指示符 若事务层FLIT 1（TL Flit [1]）不存在，则为保留位；否则为消息位指示符 |
| TL Flit[1] | [7] | 事务层FLIT存在标识<br><br>0b - 事务层FLIT 1（TL [1] Flit）不存在<br>1b - 事务层FLIT 1（TL [1] Flit）存在<br> |
| Segment Header<br><br> | Number of payload Sectors<br><br> | Number of payload bytes<br><br> | Half Segment Sector ranges<br><br> |
|---|---|---|---|
| SH0 | 32 Sectors | 128-bytes | [0:15], [16:31] |
| SH1 | 32 Sectors | 128-bytes | [32:47], [48:63] |
| SH2 | 32 Sectors | 128-bytes | [64:79], [80:95] |
| SH3 | 31 Sectors | 124-bytes | [96:111], [112:126] |
| SH4 | 30 Sectors | 120-bytes | [127:142], [143:156] |
DL 层有几个重要的机制，包括发送端速率调节、LLR 下面重点介绍一下：
链路层重传机制用于确保：在出现物理层 FEC 无法纠正的比特错误时，仍能保证 DL 微片按序可靠投递。发 送端会保留所有净荷 FLIT（Payload Flit）（不含空操作微片 NOP）的副本，直至接收端给出肯定应答。未 应答的 FLIT 存储在 TxReplay 缓冲区（发送重传缓冲区）中。
TxReplay 缓冲区的大小必须足够覆盖链路的往返时延（RTT），否则链路无法满带宽运行。 若 TxReplay 缓冲区已满（正在等待肯定应答 ACK），则不得发送新的 DL 净荷 FLIT，转而发送 NOP FLIT 替代。 若 TxReplay 缓冲区已满或处于重传状态，数据链路层（DL）需向事务层（TL）施加反压（back pressure）， 不再接收任何新的 TL FLIT，并确保已接收的 TL FLIT 不丢失。 PCS 接收端在将 FLIT 转发至 DL 之前先执行 FEC 纠错，仅通过 FEC 纠错的 FLIT 才会转发至 DL。 CRC 校验在 DL 层执行：若 CRC 校验失败，则该 DL 微片被判定为无效并丢弃。若 CRC 校验正确，则执 行以下操作之一：
FLIT 序号规则：有效 FLIT 序号范围为 1∼511，0 保留供未来使用。序号到达 511 后回绕至 1。
TX
Payload Flit add TXReplay Buffer
RX Flit是否In Order 如果In Order发送ACK
释放TXReplay Buffer中已经确认的Payload Flit。Buffer Size要考虑round-trip time (RTT) Remove all DL payload Flits with sequence number lower than or equal to Rx_last_ack from the TxReplay buffer.
如果Out of Order发送Replay Req
重传TXReplay Buffer中从ackReqSeq开始的所 有报文 Schedule replay with the ackReqSeq from the received Flit as the next Flit to transmit
图153 DL LLR 流程
本章介绍的数据链路层（DL）处于事务层与物理层之间，主要完成 TL Flit 与 640 字节 DL FLIT 之间的打包 与解包，并提供链路内部消息处理功能；其 DL FLIT 采用标准化 640 字节格式，由 3 字节 FLIT 头、5 个字 节段头、4 字节 CRC 及 628 字节净荷构成，支持显式序号、应答、重传请求等控制功能。
同时，数据链路层链路层重传机制，结合 FEC 纠错、CRC 校验、FLIT 序号、TxReplay 缓存、ACK 及重 传请求，实现物理层错误无法纠正时的可靠数据投递，确保 FLIT 有序、不丢失、不重复，最终为上层提供高 效、稳定、可靠的链路传输服务。
UALink 协议与 OISA、ETH-X、SUE 协议的核心目标完全一致，均是实现 UPLI 指令 或 AXI 指令在各节点 间的正常传递，二者的核心差异仅在于多消息聚合方式不同：
综合来看，这种设计 trade-off（权衡）的结果是：UALink 降低了 GPU 侧的实现复杂度，但相应提升了交 换机侧的实现复杂度；同时，基于端口的聚合方式也提高了 UPLI 消息的聚合概率，进而提升了链路传递效率。
第二，UALink 的设计核心之一是进一步降低 GPU 侧设计复杂度，将更多硬件资源留给 GPU 核心计算。为 此，UALink 去掉了可靠传输层协议，这也导致其在复杂拓扑（如多跳转发）场景中，在 CBFC（ Credit-based Flow Control）流量控制、数据保序这两方面做出了一定舍弃。因此，UALink 更适合简单拓扑的 Scale UP 网络，其设计理念就是最大限度减少 GPU 芯片中通信引擎占用的 DIE Size（芯片面积）。
第三，UALink 的多个 Station（站点）、多个端口，在 UPLI 接口层面是可见的，这也就意味着这些资源对 GPU 完全可见。这就要求 GPU 在设计时，需额外考虑如何合理使用 UALink 的多个 Station 和端口、如何实现负 载均衡等问题，且这些逻辑需要在 GPU 通信库的设计中予以体现。相比之下，OISA、ETH-X、SUE 三款 协议在端口使用上更为灵活：既可以将多个端口聚合使用，由通信引擎自动实现负载均衡；也可以让多个端口 独立工作，由 GPU 自身实现负载均衡，无需在通信库设计中额外增加过多复杂逻辑。
最后，UALink 对 UPLI 接口进行了详尽、统一的规范定义，完整规定了各类 UPLI 信号在事务层 TL FLIT 的 传递方式，最大程度提升了不同厂商 GPU 之间通过 UPLI 接口实现互通的兼容性。而很多协议对 AXI（与 UPLI 功能类似的接口）的定义则较为宽泛：虽然 AXI 本身有基础标准，但对于扩展字段（如负载均衡用的 Entropy 字段等）的实现方式缺乏统一细化要求；同时，AXI 信号到事务层（TL）的封装、解封装逻辑也没有明确规 范，需要各厂商自行定义。这种缺乏统一事务层报文标准的情况，导致不同厂商的 GPU 在尝试跨厂商通信时， 面临显著的兼容性困难。但是也由于 UPLI 的定义，虽增加了互通性，但是也限制了 NOC 总线对外设的接口 能力，也限制了很多 GPU 厂商对 UPLI 的私有化扩展。
软件栈与协同优化
1 超节点软件栈
超节点并不是一个硬件的堆砌，而是整合软硬件及平台的完整系统和方案。软件对于超节点的性能、易用性、 可维护性、长任务运行稳定性至关重要。一般来讲软件包含：
AI 框架及引擎位于超节点软件栈的中间层，承担从模型表达到计算执行的核心职责，是连接算法与硬件的关 键执行与调度层。其向上提供统一的模型开发与运行接口（如模型训练与推理业务），向下对接通信库与算子 库，在资源调度系统分配的资源范围内完成计算任务的组织与执行。
其核心作用主要在三个方面：
以大规模模型训练为例：模型在多个计算节点上并行执行，当完成一次前向与反向计算后，需要对各节点上的 梯度进行同步。此时，AI 框架会根据并行策略决定哪些设备参与同步、在何时触发通信操作，并将同步任务 编排进整体执行流程；随后，具体的数据交换由通信库完成，底层高速互联负责实际数据传输。整个训练任务 运行在集群调度系统分配的计算资源之上。通过这种分层协同，AI 框架实现了计算与通信的有序衔接，从而 提升整体执行效率。
在超节点架构中，面对大规模 GPU 与高速互联构成的复杂系统，AI 框架的执行调度与协同能力直接决定计 算效率与资源利用率，成为系统性能发挥的关键。
AI 框架及引擎围绕模型开发、训练与部署过程形成分层体系，主要从职责层面可以包括基础 AI 框架、训练扩 展框架与推理引擎三个部分，共同构成从模型表达到高效执行的完整技术链路。
基础 AI 框架（如 PyTorch、TensorFlow）提供模型定义、自动求导与基础算子能力，并对底层算力资 源进行统一抽象，是模型开发与执行的基础入口。其核心作用在于构建统一的计算表达与执行环境，使模 型能够在不同硬件平台上运行，同时为上层扩展能力提供基础。
训练扩展框架构建在基础 AI 框架之上，面向大规模模型训练场景，通过数据并行、模型并行、流水线并行 及混合并行等策略，将计算任务扩展至多节点环境。其核心职责包括并行策略实现、梯度同步机制、任务 编排与通信调度。
在大模型训练中，训练框架不仅决定计算任务的切分方式，也直接影响通信模式与系统扩展效率。例如， 通过分片参数（FSDP）或训练框架（Megatron-LM）等机制，可以在提升显存利用率的同时降低通信 开销，从而实现更高效的规模扩展。典型实现包括 DeepSpeed、Megatron-LM、PyTorch FSDP 等。
推理引擎面向模型部署与服务化场景，通过对计算图、执行路径及硬件特性的深度优化，实现低延迟、高 吞吐的推理能力。在大模型场景下，推理引擎还负责中间状态管理（如 KV Cache）与请求调度，以减少 重复计算并提升长上下文处理效率。
例如，通过 KV Cache 复用机制，可以避免重复计算历史上下文，从而显著降低长序列推理的计算开销； 通过动态批处理与请求调度机制，可以在多请求并发场景下提升整体吞吐能力。代表性推理引擎包括 vLLM、 TensorRT-LLM 及 HuggingFace TGI 等。
在上述分层体系之上，AI 框架及引擎的核心能力集中体现在以下三个方面：
因此，AI 框架及引擎不仅是模型开发与执行平台，更是面向大规模算力系统的统一调度与运行基础。
在超节点架构下，AI 框架及引擎从单机优化工具演进为系统级协同优化核心。超节点由大规模 GPU 与高带 宽、低延迟互联网络构成，这种高密度算力结构对框架提出了更高要求，主要体现在以下方面：
在此基础上，AI 框架及引擎的发展呈现出两大趋势： 第一，软硬协同持续深化。
框架将从“统一抽象硬件”进一步演进为“感知并利用硬件”，针对超节点的高速互联与内存体系优化通信调 度与数据访问路径，充分释放底层硬件能力。
框架逐步从训练或推理工具演进为统一的算力执行平台，在同一系统中支持多任务并行运行与动态资源调度， 实现训练与推理任务的协同执行与资源共享。
总体来看，AI 框架及引擎正从以开发效率为核心的软件工具，演进为超节点算力系统的核心调度与优化中枢。 一方面，其通过高效的执行调度与协同机制，将底层硬件能力转化为可用算力；另一方面，通过持续的软硬协 同优化，使上层应用能够高效利用超节点的计算与互联资源。作为连接算法与硬件的关键纽带，AI 框架及引 擎是实现超节点算力高效释放的核心基础设施。
无论训练还是推理，性能的极致优化都依赖于软硬件的紧密协同。其核心目标在于最大化算力效力，竭力消除 重复计算与数据等待的无效时间。常见的优化手段包括：提升通信带宽、优化通信算法、实现计算与通信的重 叠执行以减少等待；通过缓存 KV Cache 到加速卡之外，计算 KV Cache 的 P 节点与使用 KV Cache 的 D 节点分离来规避因显存不足导致的重计算。
在此基础上，超节点通过构建更大规模的 Scale-Up 域，提供了更高的互联带宽与更低的时延，从而奠定了 卓越的通信性能。再辅以集合通信优化、推理引擎调优等软件层面的加持，便能充分释放超节点硬件架构所带 来的全部潜能。
在大语言模型（LLM）推理中，一次完整的推理请求包含两个计算特征截然不同的阶段：
在传统的 LLM 推理系统中，Prefill 和 Decoding 在同一组 GPU 上交替执行。这带来严重的资源效率问题： Prefill 的大批量计算会抢占 Decoding 的 GPU 时间片，导致 Decoding 延迟（即用户感知的 Token 间延迟， TPOT）大幅波动；Decoding 阶段 GPU 算力大量空闲，但因需维持 KV Cache 而无法释放给 Prefill 使用； 两个阶段的 Batch Size 优化目标相互冲突：Prefill 倾向小 Batch 低延迟，Decoding 倾向大 Batch 高吞吐。
PD 分离（也称为 Prefill-Decoding Disaggregation）通过将两个阶段解耦到独立的硬件资源池中来解决上 述矛盾：
通过该架构，系统实现了计算路径与访存路径的解耦，使不同类型负载能够在各自最优资源环境中独立优化， 从而提升整体资源利用率与服务稳定性。
而超节点的高带宽互联为 PD 分离架构又提供了独特优势——KV Cache 的跨 Pool 传输瓶颈得到显著缓解， 从而支持更深入的系统级优化：
总体而言，PD 分离通过将 Prefill 与 Decoding 两类异构负载进行资源级解耦，从根本上解决了传统混合部 署下算力利用率与时延稳定性之间的冲突。在此基础上，结合超节点架构提供的高带宽互联与统一调度能力， 系统能够围绕资源配比、数据传输、缓存管理与全局调度等关键路径进行协同优化，进一步释放性能潜力。
单个超节点虽然极大的提升了单节点的算力，但是为了支撑大模型训练和高性能推理，仍然需要将大量的超节 点组成算力集群。集群内通信的核心意义在于突破单超节点的扩展瓶颈，使聚合更大算力。因此集群性能优化 对发挥整个集群的算力效率，有着至关重要的作用。集群性能优化需要从 Scale-Out/Scale-Up 融合的网络 设计、模型并行策略、集合通信软件等角度进行考虑。
在 AI 训练集群中，模型训练和推理过程会产生大量微突发流量。为避免 Spine-Leaf 网络架构中因带宽不足 造成网络瓶颈，当前主流设计采用收敛比为 1:1 的架构，即 Leaf 交换机的上行与下行端口数量相等。这意味 着每个 Leaf 交换机需配置一半端口下行连接 GPU 服务器/超节点，另一半端口上行连接 Spine 交换机。
以 H3C S9827 交换机为例，其最大支持 128 个 400Gbps 端口，作为 Leaf 交换机时，64 个端口用于下行 服务器接入，64 个端口上行连接 Spine 交换机。这种对称设计确保无阻塞转发能力，但也带来了流量分发策 略的挑战——当报文从 Leaf 转发至 Spine 时，如何选择最优的上行端口成为关键问题。超节点典型组网如 下：
最直接的选路方式是等价路由（ECMP，Equal-Cost Multi-Path routing）。Leaf 交换机根据报文特征（如 源目的地址、端口号、协议类型等）计算哈希值，并根据哈希值选择上行端口。该方法的优势在于保证相同流 走相同路径，避免报文乱序问题。
然而，ECMP 存在显著的负载不均缺陷。在 640 卡 GPU 进行 all reduce 测试中，不同上行端口的报文发送 分布呈现极不均匀状态。这种不均匀导致虽然总体带宽充足，但部分链路因拥塞造成整体网络性能下降，严重 时网络性能仅为理想情况的 60%左右。解决哈希不均带来的网络性能下降，成为大规模 Scale-Out 网络的 关键挑战之一。
SDN 路径导航利用集合通信的周期性特征，通过控制器进行全局路径规划，需 CCL 深度适配，可大幅提升 带宽利用率；逐包负载技术利用 RDMA 块协议特性，让交换机按实时负载分发报文；DDC 架构则将传统机 框解耦为分布式盒式设备，通过信元切片与重组技术，在网络侧实现精细化负载均衡。三者各有侧重：SDN 通过软件实现，只依赖交换机通用的能力硬件依赖小；逐包负载胜在透明性，相对成熟，但是需要网卡与网络 设备配合使用，需要依赖网卡恢复网络逐包负载均衡丢失的顺序；DDC 则以网络架构创新实现了端测网卡网 侧交换机的解耦与极致均衡，需要使用支持 DDC 的接入及核心交换机进行组网。
典型的 8 卡算力服务器中，多块加速卡通过 Scale-Up 方式实现节点内算力扩展。为保证每块加速卡的节 点间通信性能，服务器等量配置高性能 IB 或 RoCE 网卡用于 Scale-Out 扩展，当前网卡带宽已达 400Gbps 甚至 800Gbps。
服务器内部采用 PCIe Switch 将加速卡与 Scale-Up 网卡互联。集合通信库进行跨节点通信时，基于内 部拓扑感知，优先使用同一 PCIe Switch 的 Scale-Up 网卡进行通信。通过 RDMA、GDR（GPUDirect
RDMA）等技术，实现跨节点加速卡之间通信数据，直接从加速卡经过网卡传输，完全绕过主机内存和 CPU，最大限度降低时延和性能损耗。
模型训练流量具有周期性和强同步特征。周期性指每个迭代周期产生相同特征流量；强同步指同一阶段通 信为整个集群相关加速卡同时启动和结束，通信效率取决于性能最差的一个。考虑到 DP 流量的极大通信 量特点，需最大限度保证通信吞吐，避免不同加速卡通信路径相互干扰。在 Spine-Leaf 组网拓扑下，DP 流量能在同一 Leaf 下完成最为理想。由于 DP 通信为同编号加速卡之间，将同编号加速卡接入相同 Leaf 对 DP 流量最优——这正是多轨接入的核心优势。
AllReduce 算子将不同加速卡数据进行汇总并在所有卡间同步，常用操作包括 add、max、min、avg 等。 跨节点 AllReduce 最常用场景为 DP 训练中的梯度同步，一般为同轨通信。
NVIDIA NCCL 实现了多种 AllReduce 算法，包括 Tree、Ring、NVLS、NVLS Tree、CollNet Direct、 CollNet Chain 等。不同算法对网络流量模型产生显著影响：
Tree 算法分为两阶段：首先通过 Reduce 算子将所有数据汇总到根节点，再通过 Broadcast 将汇总数据同 步至整个通信域。在 Reduce 阶段，除最后一次外，每次均为两个加速卡向一个加速卡汇总数据，形成明显 的"二打一"流量模式。这种模式在加速卡入方向产生严重拥塞，且集群规模越大、数据量越大，拥塞越严重。 通过链路中 ECN 报文数量可定性判断拥塞程度。480 卡 NCCL Test 采用 Tree 算法进行 AllReduce 时， 单台 Leaf 交换机产生大量 ECN 报文；640 卡测试时 ECN 数量显著增加。对应地，640 卡测试中 4GB 数 据量的 busbw 带宽仅为 480 卡的 60%左右，充分说明大数据量操作时，更大规模集群使用 Tree 算法会在 加速卡接入端产生严重拥塞，对 AllReduce 性能造成极大影响。
Ring 算法将 AllReduce 分为 ReduceScatter 和 AllGather 两阶段。每个阶段将通信域加速卡串接成环， 从根本上避免了 Tree 算法的"二打一"拥塞。实测 ECN 数量极少甚至完全消除，意味着通过算法优化消除了 拥塞问题。640 卡集群测试中，4GB 数据量下 busbw 可达物理带宽的 95%。
• 算法选择策略
Ring 算法并非完全优于 Tree 算法。相同规模集群下，Ring 算法操作步骤为 2N-1，显著多于 Tree 算法的 2(log₂N)。因此，小数据量场景下，Tree 算法时延明显小于 Ring 算法；随着数据量增加，Ring 算法的高吞 吐优势逐渐显现。
480 卡实测数据显示，小数据量时 Tree 算法时延明显低于 Ring 算法。这表明不同算法适用不同场景——小 数据量场景宜选用 Tree 算法降低时延，大数据量场景宜选用 Ring 算法提升吞吐，具体选择需结合实际场景 权衡。
随着 DeepSeek V3 将 MoE（混合专家）模型工程化落地，越来越多模型采用 MoE 架构。MoE 模型的训 练和推理产生大量 All-to-All 流量，具有两大特点：大量跨轨加速卡通信和大量多打一流量模式。
为优化此类流量路径，NVIDIA 引入 PXN（PCIe x NVLink）技术。该技术先将跨轨流量通过高性能 Scale-Up 网络转发至同节点同轨加速卡，再通过同轨路径进行跨节点转发。据 NVIDIA 数据，采用 PXN 技术可减少 All-to-All 通信时延约 50%。同样，PXN 技术需在多轨接入组网下才能充分发挥效能。
从 AllReduce 和 All-to-All 通信算法的优化实践可以看出，优化集合通信算法能够有效改善流量模型，减少 甚至避免网络流量"多打一"带来的性能下降和不确定性，是构建高性能 AI 集群的关键技术手段。
在超节点（Super Pod）架构中，硬件性能决定了算力的“天花板”，而软件优化则决定了实际运行中的“有 效利用率”。即便拥有最顶级的互联拓扑，如果软件栈未能针对超节点的大带宽、低延迟特性进行深度适配， 系统依然会面临严重的通信开销和计算闲置。
本节将从底层库适配、内存管理、并行策略及监控诊断四个维度，探讨如何在软件层面榨取超节点的极致性能。
超节点的核心优势在于其非阻塞、全互联的通信能力。标准的通信库（如 NCCL 或 HCCL）在通用环境下表 现优异，但在超节点特定拓扑下，往往存在冗余的握手协议或通用的算法选择（如默认使用 Ring 算法）。
在大模型训练等超大规模计算场景中，内存带宽往往比计算频率更容易成为瓶颈。
超节点的强大算力需要高效的算子来驱动。标准的深度学习算子往往针对通用场景，缺乏对特定指令集的极致 压榨。
超节点不仅是物理上的集成，更是逻辑上的单体化。软件优化需重新定义张量并行（TP）、流水线并行（PP） 与数据并行（DP）的权重。
• 内聚型模型并行：由于超节点内部延迟极低，软件设计应倾向于将计算强度最高、通信最频繁的模型切片
置于同一台超节点内部。
再完美的算法也需要实际环境的校准。软件优化的最后环节是建立“毫秒级”的监控体系。
超节点作为大规模 AI 计算的核心载体，其系统复杂度呈指数级增长，芯片、机 柜数量的剧增，使得硬件故障 （如芯片损坏、链路中断）成为常态，性能监控已从“可选项”变为“生命线”。
首先，规避“静默故障”的毒化效应：这是超节点监控面临的最大挑战，在大规模分布式训练中，超节点中哪 怕只有一张 GPU 出现“静默故障”（即表面在线但性能大幅下降），就会像毒药一样污染整个训练任务的梯度;
其次，保障超节点规模下的线性加速比：超节点依赖 Scale up 高速互连实现大量 GPU 卡协同，任何单点的 性能衰减（如 PCIe 重传增加、Scale up 带宽波动）都会通过“木桶效应”拖慢整个训练任务。没有全栈、 全维度的监控，无法定位性能瓶颈究竟源于计算、显存、通信还是数据预处理；
第三，支撑超节点的精细化调度和运营：以监控作为依据，从而优化模型并行策略、数据流水线和作业调度， 超节点的功率密度极高，可追踪功耗与温度以优化 PUE，是实现“每瓦特每秒性能”最大化目标的前提。
超节点性能监控需构建“端到端、分层立体”的监控体系，覆盖从芯片到数据中心、从基础设施到 AI 作业的 全栈范围，如下为典型监控指标举例：
| 监控层级 | 监控范围 | 关键监控指标 |
|---|---|---|
| 硬件基础设施层<br><br> | GPU | 算力利用率、显存利用率、GPU温度/功耗、 ScaleUp/ScaleOut带宽利用率/错误计数、ECC错误计数 |
| CPU与内存 | CPU利用率、内存利用率/已用量、缓存命中率、NUMA 状态 | |
| 高速互连网络 | 端口发送/接收带宽、端口误码率、拥塞控制计数、延迟、 交换机温度/功耗 | |
| 存储 | IO带宽（读/写）、IOPS、延迟、存储池使用率、等并行文 件系统OST/MDT状态 | |
| 供电与散热 | 机架/节点功耗（PUE）、进出风温度、风扇转速、冷却水 流量/温度 | |
| 系统与平台层 | 操作系统 | 内核错误日志（dmesg）、进程/线程数、文件描述符数、 网络连接状态 |
| 集群调度器 | 作业队列状态、作业资源分配情况、Pending/失败作业数、 调度器性能 | |
| 容器运行时 | 容器资源限制与使用量、镜像拉取状态、运行时状态 |
| 监控层级 | 监控范围 | 关键监控指标 |
|---|---|---|
| AI框架与作业层<br><br> | 分布式训练框架 (PyTorch, Tensorflow) | 全局迭代速度（iterations/sec）、Loss曲线、梯度同步时 间、数据加载时间 |
| 集合通信库(CCL) | AllReduce、AllGather等集合通信操作耗时、算法选择、 通信吞吐量 | |
| 模型与算法 | 张量并行/流水线并行的负载均衡度、CheckPoint检查点 保存时长； 推理时延、请求队列长度、批处理大小 |
工具链通常由数据采集代理、时序数据库、可视化与告警平台及上层分析工具构成。
| 工具类别 | 关键作用 | 常用工具 |
|---|---|---|
| 数据采集 | 数据采集代理，负责超节点基础 设施、系统平台、到AI框架层的 指标采集，并输出到上层数据存 储工具 | Prometheus Node Exporter，是监控超节点服务器基 础指标的首选，其他 OpenTelemetry Collector、Telegraf等都支持对接 Prometheus后端。 NVIDIA DCGM，专为NVIDIA GPU设计，可监控 NVLink、SM利用率等关键指标 |
| 数据存储 | 提供多维监控数据存储，需要高 性能写入和查询能力，通常支持 时序数据的处理、支持跟踪 （Traces）、指标（Metrics） 和 日志（Logs） 类可观测性数 据<br><br> | Prometheus、OpenTelemetry是云原生监控的标准 工具，具有丰富的生态， VictoriaMetrics具有高压缩比和高性能特性，可作为 Prometheus的扩展，提供超大规模数据的长期存储 InfluxDB适合对写入吞吐量要求极高的时序数据存储场 景 |
| 可视化与告 警平台 | 提供超节点监控数据的可视化 和分析，支持丰富的数据源和、 提供仪表板编辑和告警功能 | Grafana，是监控栈可视化的事实标准，能够将全栈监 控数据在一个平台统一展示。 Kibana擅长日志数据的可视化分析，当需要将指标监控 与日志（如训练作业日志、内核日志）进行关联分析时 使用。 |
| 高级分析与 剖析 | AI框架的剖析工具，支持模型与 算法层的性能分析，跟踪模型前 向反向传播、算子耗时、CUDA 内核执行等，以优化超节点场景 中的模型计算图、数据加载和算 子实现 | PyTorch Profiler ，TensorBoard |
一个优秀的超节点监控系统，应能做到从物理功耗到模型 Loss，从单卡 SM 利用率到全局通信拓扑的全栈可 观测，并将数据转化为自动化的运维动作和性能优化建议，从而保障这座“AI 算力超节点”的稳定、高效运 行。
Prometheus + Grafana 性能监控组合成熟、开源、灵活，覆盖了 90%的监控需求，是构建自定义监控体系 的最常用选择。
另外为了适配不同超节点产品的特点，超节点算力资源提供商往往会提供私有的 Agent 代理采集器+分析工 具作为补充（比如 H3C 的 ADDC Agent 采集器+ADDC 分析器），提供更多差异化的监控指标，以支撑上 层资源调度和业务优化。
在超节点技术架构中，集群管理平台是实现物理资源池化与逻辑任务协同的核心中枢。该平台打破了传统数据 中心以“单台服务器”为最小调度单元的限制，通过深度整合高速互联拓扑与内存语义通信，实现了对整簇超 节点资源的高效编排与自动化调度。
不同于传统的分布式调度，超节点平台通过“穿透”物理边界，实现对 Scale-up 架构内内存语义通信与全互 联拓扑的极致利用：
超节点突破了传统单机柜物理边界，通过高速交换背板与低延迟内存语义协议，将分布在不同 Tray 中的计算 与存储资源深度重组，实现从“单设备池化”向“多 Tray 整体池化”的跨越：
针对千卡级以上的超大规模智算作业，集群管理平台提供了从部署、校验到执行的全流程自动化支撑。
为了满足高性能计算环境下的多租户诉求，平台在逻辑安全与物理资源分配上进行了深度定制，平衡了资源共 享的灵活性与任务运行的稳定性。
在人工智能进入万亿参数时代，超节点（Super Pod）已成为 AI 基础设施的核心构建单元。以 NVIDIA GB200 NVL72为代表的超节点系统，通过第五代NVLink域将72张Blackwell GPU互联成逻辑统一的“巨型GPU”， 提供 130 TB/s 以上的聚合带宽 1。在此架构下，操作系统不再是单纯的资源管理者，而是 Scale-up 互联（机 架内高速直连）的核心协调层，负责拓扑发现、链路管理、NUMA/CXL 感知、通信库优化、功耗热控、故 障域隔离等多维度功能。
操作系统同时也承担 Scale-out（跨节点集群）管理职责，例如通过 RDMA 子系统、GPUDirect 和 Fabric Manager 接口支持 InfiniBand/RoCEv2 的跨机架扩展。然而，本白皮书重点聚焦 Scale-up 场景下的 OS 作用——即如何让单个机架内的数十至数百 GPU 像单一大 GPU 一样高效协同，而非详尽探讨集群级网络优 化。
后续章节将从 AI 负载画像入手，逐步剖析 CPU-GPU 异构互联、单节点多 GPU、超节点 Scale-up 管理、 资源池化，直至统一内存语义演进，帮助系统架构师与运维工程师构建高效、可扩展的 AI Factory。操作系 统在超节点时代已从传统的资源管理器，彻底演变为 AI 基础设施的“神经中枢”与“互联大脑”。本白皮书主 要聚焦于单机架/单节点内的 Scale-up 场景——即如何通过 NVLink、CXL、PCIe 等高速直连技术，将数十 至数百张 GPU 融合为逻辑统一的“巨型加速器”，并由操作系统负责拓扑发现、NUMA/CXL 亲和调度、 Pinned Memory 优化、GPUDirect 路径管理、功耗热控与故障域隔离等核心功能。
同时需要说明的是，操作系统在更大规模的 Scale-out 场景（跨节点集群、万卡级分布式训练）中同样承担 关键职责，例如通过 RDMA 子系统、NCCL/SHARP 集成、GPU Direct Storage、CXL 内存池化驱动、 topology-aware 调度以及 Fabric Manager 接口，支持 InfiniBand/RoCEv2 的跨机架扩展、AllReduce 通 信优化、多租户资源隔离与动态借用。然而，Scale-out 涉及更复杂的网络 Fabric 管理、拥塞控制、SHARP in-network compute、UFM 遥测与集群级调度等内容，其深度远超单节点互联范畴，因此本白皮书将不作 为重点展开，而是将讨论重心严格限定在 Scale-up 场景下的操作系统角色与优化实践。后续章节将从 AI 负 载画像入手，逐步剖析 CPU-GPU 异构互联、单节点多 GPU 管理、超节点 Scale-up 资源池化，直至统一 内存语义演进，帮助系统架构师与运维工程师构建高效、可扩展的 AI Factory 单机架基础。
图154 OS 系统架构
AI 工作负载主要分为训练和推理两大类，前者涉及大规模参数优化（如大型语言模型 LLM 的预训练），需要 海量计算资源、数据并行和模型并行处理，对高速互联（如 NVLink、CXL、高性能 RDMA 网卡）依赖极高； 后者聚焦实时响应（如聊天机器人、图像识别、推荐系统），强调低延迟、高吞吐和高效的 KV Cache 访问， 内存带宽和内存容量往往成为瓶颈。
随着 AI Factory 概念的兴起，这些负载往往在共享基础设施中混合运行，形成一个高效的“工厂”式生态： 训练任务需要极致的计算密度和 AllReduce 通信效率，推理任务则追求高并发 QPS 和动态批处理能力。整 个生态从底层硬件到上层应用形成完整的垂直栈：
训练负载对带宽和同步延迟极其敏感，例如MoE模型的专家路由和AllReduce操作会放大跨节点互联瓶颈， 容易导致利用率下降；推理负载则更依赖 KV Cache 的快速内存访问和动态批处理，内存容量不足或跨 NUMA 延迟过高会显著影响首 token 延迟（TTFT）和 tokens/s 吞吐。AI Factory 通过动态调度、多租户 隔离和资源亲和性来缓解这些问题，但互联瓶颈（如跨 socket/跨节点延迟、CXL 内存池化效率、RDMA 网 络抖动）仍然是导致任务抢占、碎片化和整体利用率波动的核心挑战。未来，随着 CXL 3.0/PCIe 7.0、NVLink 5.0 和高密度 xPU 集群的普及，AI Factory 需要在系统级（内核、容器、调度）和硬件级（异构互联、内存 扩展）同时优化，才能真正实现“算力工厂”级的高效共享与弹性扩展。
图155 Scale up 拓扑
在单节点环境下，使用少量 GPU（如 2-8 个）的训练场景常见于原型开发或边缘 AI 应用，而高并发推理则 服务于生产环境，如 API 端点处理数千查询/秒。这里，互联问题主要体现在 CPU-GPU 数据传输和 GPU 间同步上。未优化的 PCIe 互联可能导致数据拷贝消耗大量时间，高并发推理则需借助多进程服务（MPS） 来隔离负载，确保资源利用最大化，而互联瓶颈如 NUMA 效应会进一步放大延迟。例如，在一个 4-GPU 节 点上运行 Llama-7B 模型的 Few-GPU 训练时，如果不绑定 CPU 亲和性，跨 socket 访问可能增加延迟； 在高并发推理中，处理 1000 TPS（Transactions Per Second）的服务，如果使用 Pinned Memory 优化， 可减少 CPU-GPU 拷贝时间。总体而言，单节点场景强调本地优化，如使用 NVLink 实现 GPU 间直连，以 最小化 PCIe 瓶颈，从而提升整体吞吐量和响应时间。
大规模分布式训练涉及数百甚至数千 GPU，如训练 GPT-like 模型，需要跨节点高效通信。LLM 和 MoE 的 并行策略（如数据并行、专家并行）高度依赖于网络 fabric 的带宽和延迟。在使用 InfiniBand 的万卡集群可 将 AllReduce 操作时间缩短至微秒级，但 RoCE v2 在高负载下易受拥塞影响。系统互联的挑战在于平衡计 算与通信开销，确保模型收敛速度不因网络瓶颈而放缓。例如，在一个 1024-GPU 集群上训练 MoE 模型时， 通过 NCCL 优化将通信开销降低，这涉及环状算法和分层 AllReduce 的结合。进一步地，分布式训练还需 考虑故障恢复，如 Checkpoint 机制依赖低延迟存储互联。MoE 模型的特殊性在于专家路由的动态性，这放 大了对 Fabric 可靠性的需求；在 LLM 中，长序列训练则测试带宽极限。
资源池化通过解耦计算、内存和存储来应对 AI 负载的动态性，例如 KV Cache 在推理中缓存键值对以加速生 成，RAG（Retrieval-Augmented Generation）则处理长上下文输入，导致内存需求激增。混合负载场景 下，训练和推理共存会产生资源碎片。CXL 技术可实现内存池化，允许动态分配资源，提高利用率。互联问 题在这里体现为跨设备访问延迟，需要精细的调度机制。例如，在 RAG 应用中，长上下文可能要求数百 GB 内存，如果不池化，单节点容易溢出；KV Cache 池化则允许共享缓存，减少重复计算。使用 CXL Switch 将内存从 DRAM 扩展到远程池，实现了推理延迟降低效果。进一步地，资源池化还涉及存储层，如 NVMe-oF 支持 GPUDirect Storage，实现零拷贝数据路径。这不仅提升效率，还降低功耗。
从 NUMA（Non-Uniform Memory Access）到网络 Fabric 再到 CXL（Compute Express Link），互联 瓶颈的核心在于非均匀访问延迟和带宽限制。NUMA 在多 socket CPU 中导致跨 socket 访问慢于本地，而 Fabric 扩展到集群级，CXL 则提供统一内存语义。这些瓶颈常导致 AI 训练的瓶颈转移从计算到 I/O，优化需 从硬件拓扑到软件栈的全链路考虑。例如，NUMA 效应在双 socket 系统中可增加访问延迟；在 Fabric 层面， InfiniBand vs Ethernet 的带宽差异影响 AllReduce 效率；CXL 则通过 Type-3 设备实现内存共享，缓解 瓶颈。共性问题还包括一致性开销和功耗，CXL 的演进正逐步解决这些。总体而言，这些技术从本地到全局 演进，共同构筑 AI 系统的互联基础。
本章剖析了 AI 各类负载，揭示其共同面临的核心约束：系统互联性能已成为比单点算力更关键的瓶颈。这一 瓶颈贯穿于节点内的 PCIe 与 NUMA 拓扑、集群间的 RDMA 网络效率，以及资源池化中 CXL 等技术引入 的非均匀访问延迟。其影响直接表现为训练周期延长、推理响应受损与资源碎片化加剧。
面对这一全景式挑战及异构硬件的复杂生态，操作系统的核心使命已发生根本转变：它必须从传统资源管理器， 演进为能够统一调度异构互联、智能管理非均匀资源并深度适配多元化算力底座的“AI 基础设施中枢”。这一 定位重塑了其所有技术演进的方向。
在人工智能（AI）工作负载中，中央处理器（CPU）扮演着多重关键角色，不仅作为系统的“指挥中心”负 责整体协调，还直接参与数据预处理、模型调度和后处理任务。这些角色在训练和推理阶段各有侧重：在训练 过程中，CPU 主要处理数据集的加载、增强和分发，例如通过多线程管道（如 PyTorch 的 DataLoader） 将图像或文本数据高效传输到 GPU；在推理阶段，CPU 则负责查询路由、批处理和结果聚合，如在高并发 聊天应用中协调数千个推理请求。
从负载模式来看，AI 场景下的 CPU 往往呈现出高 I/O 密集型和计算辅助型特征。高 I/O 模式常见于数据密集 型任务，例如在大型语言模型（LLM）预训练中，CPU 需从存储系统中读取 TB 级数据集，并进行 tokenization 和 shuffle 操作，这要求高效的内存管理和 I/O 调度。计算辅助模式则体现在模型并行中，CPU 辅助 GPU 进行参数同步或梯度聚合，尤其在混合精度训练中处理浮点转换。
进一步分析典型负载，可以看到周期性峰值模式：在训练迭代中，CPU 负载在数据准备阶段峰值，而在计算 阶段相对空闲；在推理服务中，负载更均匀，但突发查询可能导致瞬时峰值。举例而言，在处理 MoE（Mixture of Experts）模型时，CPU 需动态路由专家模块，这增加了分支预测和缓存利用的压力。
Non-Uniform Memory Access（NUMA）效应是多 socket CPU 架构的核心挑战，在 AI 工作负载中表现 为远程内存访问延迟远高于本地访问，导致性能瓶颈显著放大。具体而言，在双 socket 或多 socket 系统中， 跨 socket 访问需通过互联链路（如 UPI 或 Infinity Fabric），延迟可达本地访问的多倍，这在数据并行训练 中尤为突出：当一个 socket 的 CPU 线程访问另一个 socket 的内存时，会引入额外的一致性开销和带宽竞 争。
在 AI 场景下，这些瓶颈往往体现在几个关键方面。首先是数据加载瓶颈：在 LLM 训练中，数据集分布不均 可能导致跨 socket 拷贝总时间变长，未优化的 NUMA 配置使 ImageNet 数据管道效率下降严重。其次是同 步开销：在分布式框架如 TensorFlow 的 Horovod 中，跨 socket 的 AllGather 操作会因 NUMA 放大通信 延迟，影响模型收敛速度。第三是资源争用：高并发推理中，多线程竞争共享缓存会导致 L3 缓存失效率上升， 进而增加功耗和热量。
通过深入剖析，NUMA瓶颈还与负载特性交互：例如，在MoE模型的专家并行中，不均匀分配会放大跨socket 流量；在长序列 RAG（Retrieval-Augmented Generation）中，内存膨胀进一步压力测试 NUMA 带宽。 为缓解，建议采用亲和性绑定和内存交织策略。
图156 CPU NUMA 拓扑
Intel Ultra Path Interconnect（UPI）和 AMD Infinity Fabric 代表了当代 CPU 同构互联的两大主流技术， 前者强调高带宽点对点连接，后者采用模块化 chiplet 设计，提供更灵活的可扩展性。UPI 在每个链接上提供 高达 12.8 GT/s2的速率，支持双 socket 带宽达数百 GB/s，特别适合要求低延迟一致性的 AI 任务，如实时 推理调度；Infinity Fabric 则通过 die-to-die 链接实现更高聚合带宽，在多 socket 扩展中表现出色，尤其适 用于大规模数据预处理。
从 AI 性能视角看，这些技术的差异显著影响负载效率。UPI 在 NUMA 敏感的 PyTorch 训练中延迟更低，得 益于其优化的缓存一致性协议（MESIF 变体），但在高线程数场景下易受链接数限制；Infinity Fabric 则在 AMD 平台上展现出更好的均匀性，在 Mixtral 模型训练中吞吐量更高，因为其 fabric 支持动态路由和 GPU 集成。功耗方面，UPI 更高效（每 GB/s 功耗较低），而 Infinity Fabric 在 chiplet 架构下虽灵活，但需精细管 理热分布。
进一步对比拓扑和演进：UPI 采用环状或全网格拓扑，易于 OS 感知；Infinity Fabric 向 3D 堆叠演进，支持 未来异构集成。在 AI 应用中，选择取决于场景：Intel 平台适合一致性密集型负载，AMD 则青睐扩展性强的 集群。
Linux 内核通过 NUMA 节点抽象高效管理多 socket 系统，支持自动和手动优化机制，以最小化跨 socket 访问开销。核心组件包括内存策略（mpol，如 localalloc 确保本地分配）和迁移守护进程（numad），后者 动态监控负载并迁移页以平衡节点。在 AI 负载下，这些机制至关重要：例如，在高 I/O 训练中，localalloc 可将数据加载延迟降低很多。
内核的 NUMA 感知还体现在调度器中，CFS（Completely Fair Scheduler）考虑 NUMA 亲和性，避免线 程跨节点迁移；sysfs 接口（如/sys/devices/system/node）允许查询拓扑和统计。启用 numad 在 TensorFlow 多线程预处理中缓存利用率大大提高。高级特性如 weighted interleaving（在内核 5.x+引入） 预演 CXL 池化，支持根据权重分配内存，适用于混合 AI 负载。
AI 框架与 Linux NUMA 机制的集成是优化性能的关键，PyTorch 通过 torch.set_num_threads 和 torch.utils.cpu_affinity 绑定线程到特定 NUMA 节点，减少跨 socket 访问；TensorFlow 使 用 tf.config.threading.set_inter_op_parallelism_threads 结合 numactl 外部绑定；JAX 则原生支持 jax.config.update('jax_platform_name', 'cpu')并集成 numactl。在集成中，这些绑定可将 NUMA 开销降 低很多。
例如，在 PyTorch 的 DistributedDataParallel 中，未绑定时数据管道跨 socket 会导致瓶颈；TensorFlow 的 Eager 执行受益于本地分配，在高并发推理中响应时间大大缩短。
性能调优依赖工具链：hwloc 发现拓扑、likwid 测量带宽/计数、perf 跟踪事件。在 Llama 训练案例中，用 hwloc-ls 映射 NUMA 节点，再 likwid-perfctr 监控跨 socket 流量，结果显示优化后带宽利用上升；perf stat 捕获 L3 失效，揭示瓶颈。
在 Mixtral 中，工具链分析 MoE 路由：likwid 显示专家分配不均导致峰值流量，优化绑定后效率提升。
监控工具包括 numastat（节点统计）、numad（自动平衡）和 sysfs（拓扑查询）。故障排除流程：1. numastat 识别高远程访问；2. sysfs 查询节点；3. numad 或手动绑定修复；4. 验证性能。
在 AI 中，常见瓶颈如数据倾斜：在推理中，用 numastat 定位，修复后延迟降低。
图157 CPU 与 GPU 数据流向
在当代大规模人工智能系统中，CPU 与 GPU 的协同早已超越了传统的“主机+加速卡”简单分工，而是形成 了一种高度耦合、互为依赖的异构计算闭环。CPU 作为全局大脑，负责数据管道的构建、任务调度、I/O 协
调、预处理与后处理，而 GPU 则专注于张量运算、矩阵乘法和注意力机制的核心加速，这种分工在不同工作 负载下呈现出截然不同的数据流动特征。在大规模预训练场景中，典型路径从 CPU 侧开始：从分布式文件系 统读取原始海量数据集，经过多线程 tokenization、数据增强、shuffle 和 batch 打包后，通过 PCIe、 NVLink-C2C 或 CXL.mem 将数据高效传输到 GPU 的 HBM 中，随后 GPU 执行前向与反向传播，期间通 过 NCCL/RCCL 完成跨 GPU 的 AllReduce 同步，最后梯度或参数更新片段再回传 CPU 用于优化器步进或 Checkpoint 保存。
图158 推理数据流向
而在高并发在线推理（如 vLLM、TGI 或 TensorRT-LLM 部署）中，路径则更强调低延迟与实时性：CPU 首 先接收 HTTP/gRPC 请求，对 Prompt 进行分词、padding 和 attention mask 生成，同时查询或更新 KV Cache（部分 KV Cache 可能驻留在 CPU 侧 DRAM 或 CXL 池化内存），随后将 token 序列和必要状态指 针传输给 GPU 执行生成步骤，输出 logits 回传 CPU 进行采样、解码和安全过滤，整个过程需要在毫秒级内 完成数千 QPS。
在混合负载（如训练+推理共存、RAG+微调并行）下，数据路径进一步复杂化，CPU 必须同时管理长上下 文检索（FAISS/Milvus）、动态 batch 调度、资源隔离（MIG/MPS/cgroup）和跨设备内存迁移。这些画像 揭示了异构互联的核心价值：它不仅是带宽通道，更是决定 AI 系统整体效率与响应性的关键枢纽，CPU-GPU 协同已从单纯加速转向真正统一的内存语义与动态资源调度。
图159 CXL 拓扑
PCIe 与 CXL 代表了当前异构互联的两条主要演进路线，前者以原始传输带宽和通用性为核心，后者则通过 引入缓存一致性与内存语义扩展彻底改变了 CPU-GPU 协同范式。PCIe Gen5（32 GT/s）已成为 2024–
2025 年主流 AI 服务器的标准接口，x16 配置下双向有效带宽约 110–115 GB/s，受协议开销（FLIT、CRC、 重传）限制，实际 AI 负载中难以突破 120 GB/s 天花板；PCIe Gen6（64 GT/s）在 2025 年底开始规模量 产，x16 双向带宽翻倍至 256 GB/s，采用 PAM4 调制 + 前向纠错（FEC），虽然延迟略升 15–20 ns，但对 HBM↔系统内存大批量拷贝场景的缓解作用显著，尤其在多 GPU 单节点 All-to-All 通信中能大幅降低瓶颈， 并为 AI 训练提供更高吞吐。CXL 则从根本上重塑了互联语义：CXL 1.1/2.0 基于 PCIe 物理层引入 CXL.io（兼 容 PCIe）、CXL.cache（设备可缓存 CPU 内存）和 CXL.mem（CPU 可直接寻址设备内存），CXL 2.0 支 持 switch fabric 与多主机共享；到 CXL 3.0（截至 20226 未大规模落地）基于 PCIe Gen6 物理层，带宽翻 倍至 x16 256 GB/s，并新增 switch-based pooling、weighted interleaving、内存分级（near/far）、TSP 安全协议以及 Type-2/3 设备支持，实现多主机共享同一内存段的硬件一致性、P2P 传输绕过 CPU 以及多 级切换拓扑（支持数千节点 fabric）。
三大主流厂商在 CPU-GPU 异构互联上的实现路径各具特色，形成了鲜明的技术分化。NVIDIA 的 NVLink-C2C（Chip-to-Chip）是当前性能标杆，在 Grace-Hopper Superchip、GB200 和后续 Rubin/Blackwell Ultra 架构中提供 900 GB/s 至 1.8 TB/s 的双向带宽，延迟低至 15–20 ns3，并实现全硬件 缓存一致性（兼容 CHI 协议）；2025 年推出的 NVLink Fusion 进一步开放接口，允许 Fujitsu、Qualcomm、 Intel 等第三方 CPU 通过 NVLink-C2C 直连 Blackwell/Rubin GPU，形成半定制化 AI 基础设施，在 GB200 NVL72 等系统中实测显示 CPU-GPU 数据路径延迟比 PCIe Gen5 低 7 倍，能效比提升 5 倍以上。AMD 的 Infinity Fabric GPU 直连（XGMI）则依托 chiplet 架构的天然优势，在 MI300X/MI325X/MI355X 系列上实 现 448 GB/s–1 TB/s 的聚合带宽，通过第五代 Infinity Fabric 的 mesh-like 拓扑确保带宽均匀性，尤其在 MoE 模型的动态路由阶段表现平稳；2025–2026 年 AMD 通过 Helios 机架级 fabric 将 Infinity Fabric 从单 节点扩展到整机架，实现 CPU-GPU-加速器统一互联，其开放生态（ROCm）与高可扩展性成为吸引开源 社区的重要因素，MI325X 在 8-GPU 平台上提供 2 TB HBM3E 共享内存和 48 TB/s 聚合带宽。Intel 的 Xe Link（应用于 Data Center GPU Max 系列）基于 PCIe 物理层 + 专有协议，提供 128–512 GB/s 带宽，支 持硬件一致性，2025 年后通过与 NVIDIA 的合作开始兼容 NVLink Fusion，允许 Xeon CPU 与 NVIDIA GPU 混合部署，在 oneAPI 生态中表现出色，适合企业级混合工作负载。从实际性能对比看，NVLink-C2C 在极致延迟与带宽上领先（GB200 NVL72 在 Llama 3.1 405B 推理中达 224 tokens/s），AMD XGMI 在扩 展性和 MoE 负载中更均衡（MI325X 峰值 FP16 性能超 H100 30%+），Intel Xe Link 则在生态兼容性与企业 集成上占优。
操作系统与驱动层是异构互联从硬件到应用的桥梁，直接决定了实际可用性和性能天花板。NVIDIA CUDA Driver（R550/R560 系列及以上）全面支持 NVLink-C2C、GPUDirect RDMA over dma-buf（已无需 nv_peer_mem 模块）、HMM 扩展以及 cudaMallocAsync/cudaGraph 对长序列推理的零拷贝优化， 2025–2026 年重点增强了 GPUDirect Storage v3 与 NVMe-oF 集成，实现从存储直达 GPU 的端到端路 径，并在 Blackwell 平台上支持 NVFP4 量化加速推理。AMD ROCm 大幅补齐 Windows/Linux 双栈支持， XGMI 直连完整暴露给 HIP runtime，dma-buf 与 HMM 支持已趋成熟，但一致性开销仍略高于 NVLink-C2C。Intel oneAPI Level Zero 作为原生 API 直接映射 Xe Link 与 CXL 特性，2025 年后因与 NVIDIA 合作而增强跨厂商兼容性，在 dma-buf 和 HMM 支持上最完整（Intel 长期主导内核相关开发）。Linux 内核的 dma-buf 是用户态缓冲区共享的基础，HMM（Heterogeneous Memory Management，从内核
5.10 开始逐步完善）允许 GPU 直接访问系统内存页而无需显式拷贝，2025 年关键补丁包括对 device-private pages 的 P2P RDMA 支持以及页面迁移延迟的大幅优化，CONFIG_PCI_P2PDMA 已成 为现代 GPUDirect RDMA 的推荐路径，取代了旧的 nvidia-peermem 模块。这些驱动与内核机制的协同， 使得从传统显式搬运向统一内存访问的过渡成为现实，也为后续 CXL 池化与 NVLink-C2C 统一语义奠定了 坚实基础。
图160 GPU 拓扑
异构拓扑的准确发现与精细配置是单节点多 GPU 系统性能优化的起点，整个过程依赖多层工具与接口的协同。 在硬件层面，nvidia-smi topo -m、rocm-smi --showtopo 和 level-zero 的 zeDeviceGetProperties 可 直接输出 GPU 间的链路类型（NVLink、XGMI、PCIe）、带宽与延迟；在 OS 层面，hwloc（lstopo）结合 lspci -vvv | grep CXL 能完整映射 NUMA 节点、PCIe 总线和 CXL 端口拓扑，/sys/bus/cxl/devices 则提 供 CXL 设备的实时状态；在驱动与运行时层面，nccl-tests 的 all_reduce_perf -t cuda -b 8 -e 1G -f 2 可 量化实际带宽，/sys/kernel/debug/dma-buf 显示共享缓冲区信息。生产级配置流程通常包括：首先通过 hwloc-dump 生成 XML 拓扑文件供后续调度参考，然后使用 numactl --cpunodebind 和 --membind 绑 定 CPU 线程与内存节点，再通过 nvidia-smi nvlink --setenable 1 或 cxl-cli enumerate 激活高速链路，最 后 设 置 环 境 变 量 如 export NCCL_IB_DISABLE=0 （ 强 制 GPUDirect RDMA ）、 export NCCL_P2P_LEVEL=NV（优先 NVLink P2P）来引导通信库选择最优路径。在复杂多 GPU 节点中，还 需结合 nvidia-fabricmanager 守护进程动态管理 NVSwitch 状态，确保拓扑变化时（热插拔、MIG 重配置） 系统自动重新枚举。这些步骤看似琐碎，却能将实际通信效率从 50% 提升至 90% 以上，是所有单节点优化 的基石。
AI 工作负载的性能优化高度依赖于 CPU-GPU 数据路径的精细打磨，其中数据预取、Pinned Memory 和 GPUDirect RDMA 零拷贝路径是三板斧级别的核心技术。在训练场景中，数据预取通过 CUDA Stream +
cudaMemcpyAsync 实现计算与传输的重叠，Blackwell 平台的 Tensor Memory Accelerator 进一步引 入硬件预取引擎，根据历史访问模式自动预测下一批 token 或梯度块；在推理场景中，vLLM 的 paged attention 机制结合预取可将 KV Cache 加载延迟从数百微秒降至数十微秒。Pinned Memory （cudaMallocHost / cudaHostRegister）将主机内存页锁定在物理地址，避免页面故障和分页开销，在 PCIe Gen5 系统上可将主机到设备拷贝带宽从 50 GB/s 提升至 110 GB/s 以上，但会占用宝贵的系统 DRAM，需要结合 hugepages 和 cgroup 内存限额谨慎使用。GPUDirect RDMA 是零拷贝路径的巅峰， 通过 dma-buf 将 GPU 内存直接暴露给 NIC（InfiniBand/RoCE），实现从存储 → GPU 或 GPU → GPU 的 直接传输，绕过 CPU 内存拷贝，在万卡集群的单节点 AllReduce 中可将通信时间大大缩短，2025–2026 年 dma-buf 路径已成为 NCCL/RCCL 的默认选项，无需额外 nv_peer_mem 模块。这些优化技术的协同， 不仅大幅压缩了 I/O 瓶颈，还为统一内存语义的全面落地铺平了道路。
在人工智能基础设施中，单节点多 GPU 配置已成为从原型开发到生产部署的核心单元，通常涉及 4–8 张 GPU 的标准服务器（如 DGX H200 或 GB200），或扩展至 16–72 张的超节点系统（如 NVL72），这些场 景不仅支持中小模型的全参数训练，还能处理大模型的高效微调和高并发推理服务。在训练方面，典型画像包 括 7B–70B 参数规模的模型如 Llama-3-70B 或 Mixtral-8x22B，在 8×H200 平台上采用混合精度 （BF16/FP8）进行全量预训练或微调，batch size 范围 1–16，强调数据并行（DP）和张量并行（TP）的 结合，以最大化 GPU 利用率，同时应对显存压力通过 ZeRO-Offload 将部分参数迁移到 CPU DRAM 或 CXL 池化内存。
在推理场景中，高并发服务如 vLLM 或 TensorRT-LLM 部署针对 70B–405B 模型，支持 1000–5000+ QPS，采用 continuous batching、paged attention 和 KV Cache 量化技术，长上下文处理可达 128k– 1M tokens，混合负载则允许训练与推理共存，一部分 GPU 用于持续微调（如 LoRA/QLoRA/DoRA），另 一部分处理生产查询，需要精细的资源隔离以避免干扰。
进一步剖析这些场景的瓶颈与优化点，训练负载高度依赖 AllReduce/AllGather/ReduceScatter 操作的效 率，这些通信往往占大量的时间，在 MoE 模型中专家路由的动态性进一步放大 P2P 拷贝需求，而推理则更 注重 KV Cache 管理的低延迟，RAG 应用中长上下文会导致显存膨胀至数百 GB，迫使系统引入动态内存 tiering（HBM → DRAM → SSD）。在混合负载中，资源碎片化问题突出，MIG/MPS 隔离虽有效但引入额 外开销。总体而言，单节点场景的画像不仅反映了硬件演进（如从 H100 到 GB200 的带宽跃升），还强调软 件栈（如 PyTorch/DeepSpeed）的适应性，帮助从业者从实际痛点入手设计高效 AI 系统。
单节点 GPU 互联技术栈的核心在于实现高效的 GPU 间通信和数据共享，NVIDIA 的 NVLink 4th/5th Gen 结合 NVSwitch 是当前主导方案，NVLink 4（H100/H200）提供单链路 100–200 GB/s 双向带宽，全节点 聚合可达 3.2–4.8 TB/s，而 NVLink 5（Blackwell/GB200）翻倍至 200–400 GB/s4，支持更强的缓存一 致性和 P2P 原子操作，NVSwitch 作为专用交换芯片确保全互联拓扑，允许任意 GPU 间直接传输而无需 CPU 中转，在 Rubin 时代预计聚合带宽突破 20 TB/s。AMD 的 Infinity Fabric 3（XGMI）采用 chiplet 模 块化设计，在 MI300X/MI325X 上实现 128–256 GB/s 单链路带宽，全节点聚合 2–4 TB/s5，其 mesh 拓
扑在均匀负载下表现出色，尤其适合 MoE 专家并行，且与 CPU Infinity Fabric 无缝融合，支持异构直连。 PCIe Peer-to-Peer（P2P）作为通用 fallback，在无专用 Fabric 的服务器中依赖 dma-buf 和 GPUDirect， 实现 ~64 GB/s（Gen5 x16）或 ~128 GB/s（Gen6 x16）带宽，虽然延迟较高（~100 ns），但兼容性强， 适用于入门级或混合厂商系统。
在实际部署中，这些技术栈的演进还涉及功耗与热管理，NVSwitch 在高负载下功耗可达数百瓦，需要精细 的 OS 调度，而 AMD Fabric 的 chiplet 设计虽灵活但一致性开销稍高，PCIe P2P 则易受总线竞争影响。
图161 GPU 互联
单节点 GPU 拓扑类型直接决定了通信效率和可扩展性，全互联（All-to-All）是理想方案，在 DGX H200 上 通过 NVSwitch 实现，每对 GPU 独立链路带宽 200 GB/s，8 GPU 配置聚合 4.8 TB/s6，在 GB200 NVL72 中扩展至数十 TB/s（~130 TB/s），带宽计算公式为总聚合 = GPU 数 × (链路数/2) × 单链路双向带宽，实际 利用率依赖 NCCL 算法选择。树状拓扑常见于 AMD MI325X，采用分层多跳结构，同组 GPU 带宽高但跨组 衰减，适合层次化并行如 pipeline parallelism，环状拓扑在早期 A100/H100 部分配置中使用，通信 hop 数 多导致延迟累积，已被全互联取代。
进一步计算带宽时，需考虑协议开销和负载不均，全互联的均匀性在 DGX H200 上使 AllGather 操作时间从 200 μs 降至 50 μs，树状在大规模 GB200 中通过优化分支因子支持数千 GPU 扩展，环状则仅适用于小节 点以节省成本。
操作系统和通信库是单节点互联的软件基石，NCCL 2.x/3.x 是 NVIDIA 首选集体通信库，支持 NVLink/NVSwitch 的 topo-aware 算法（如 Ring/Tree/Double Binary Tree），NCCL 3.x 引入分层 AllReduce 和 NVLink P2P 优化，在 Linux 6.x 上与 ib_core 集成实现 GPUDirect RDMA。RCCL 作为 AMD ROCm 对应物，针对 XGMI 优化算法兼容 NCCL，oneCCL（Intel）则提供跨厂商接口，常作为
Horovod/DeepSpeed 的 backend。Linux ib_core + GPUDirect 提供底层 RDMA 子系统，通过 dma-buf 启用 GPU 间零拷贝 P2P，CONFIG_IB_GPU_DIRECT 在内核 6.8+ 中成熟，支持 CXL 扩展。
图162 CUDA 访问 CPU 过程
AI 框架如 PyTorch Distributed 以 NCCL backend 为基础，支持 torch.distributed.init_process_group(backend='nccl')，自动感知 NVLink 拓扑进行数据/张量并行。 Megatron-LM 和 DeepSpeed 深度优化单节点 AllReduce，DeepSpeed ZeRO-Infinity 通过 offload 减 少显存 4–8×，Megatron 的 flash attention 与 sequence parallel 降低通信量。框架优化的关键在于算法 选择，DeepSpeed 的 pipeline + tensor parallel 在 MoE 中将 AllReduce 开销降 25%，与 OS cgroup 协 同限制资源 7。
超节点和 Super POD 架构的强大效能并非仅源于硬件的简单堆砌。真正将这些异构、高速的组件——国产 CPU、各类 xPU、高速网络与池化内存——凝聚成一个高效、稳定、可扩展的“AI 算力工厂”的，是现代操 作系统中一系列深邃而关键的技术模块。
它们如同精密的神经系统与调度中枢，深入内核，驱动硬件，将物理上的复杂互联拓扑，转化为对上层应用简 洁、安全且高效可用的算力资源。接下来剖析一下这些构成 AI 时代操作系统核心竞争力的关键技术。
在超节点（SuperPOD）架构中，操作系统内核通过原生集成底层硬件协议，构建了支撑 GPU 间高速互联 的协议栈基础。这首先依赖于对 PCIe 管理这一复杂子系统的精确掌控。从开机自检开始，操作系统的 PCIe 核心层就负责枚举由 CPU、GPU、CXL 交换机及各类加速卡组成的复杂拓扑中的每一个设备，为它们分配 唯一的地址空间和中断资源，并优化数据通路，这是整个系统高速 I/O 的底层基石和拓扑感知调度的信息来源。 内核直接加载并管理 PCIe、RDMA 及 CXL 等物理接口的驱动模块，将底层能力抽象为统一的系统调用接口。 其中，P2P 权限控制 是实现设备间直接数据流通的“通行证管理器”。操作系统驱动负责探测并验证 GPU 之 间、GPU 与 CXL 设备间通过 NVLink 或 PCIe 的直连能力，在应用程序请求时建立安全的直接内存访问窗 口，确保数据能沿授权的“快速通道”流动，避免冲突或越界。
图163 PCIe 管理架构图
对于跨节点通信，GPU Direct RDMA 技术至关重要。它允许不同服务器上的 GPU，通过支持 RDMA 的高 性能网络直接读取彼此显存。这需要操作系统的网络驱动、RDMA 协议栈与 GPU 驱动深度配合，共同将 GPU 显存缓冲区安全地“注册”给本地的 RDMA 网卡，实现数据从 GPU 显存到远端 GPU 显存的直接传 输，完全绕过两端 CPU 和内存，将跨节点通信延迟降至最低，是构建万卡集群的关键。
图164 GPU Direct RDMA 架构图
这种抽象机制屏蔽了不同厂商硬件驱动的差异性，使得上层 AI Runtime 无需关心底层物理介质的具体实现， 仅需通过标准化的内核 API 即可发起跨节点的内存访问与数据通信请求，从而实现了异构硬件环境下的统一 视图与互操作性。
针对大规模分布式训练场景，内核态协议栈实现了全链路零拷贝（Zero-Copy）数据传输路径。通过优化 DMA 映射机制，内核能够直接将 GPU 显存物理地址注册至网络接口卡或 CXL 交换机的地址空间，数据包在传输 过程中完全绕过 CPU 内存缓冲区。DMA 作为“数据搬运的自动传送带”，允许外设在 CPU 指令下自行搬运 大批量数据，将 CPU 从繁重拷贝中解放出来。其高级形态 SGDMA（Scatter-Gather DMA）则能通过描 述符链表自动处理一系列不连续的数据块搬运，进一步减少了设备与 CPU 的交互次数，提升了 I/O 效率。配
合内核级的中断聚合策略与无锁环形缓冲区技术，系统有效降低了上下文切换频率与中断处理开销，显著减少 了微秒级的通信延迟，确保在万卡规模下跨机架、跨节点的 GPU 集群能够维持线速的数据吞吐能力。
此外，内核协议栈内置了自动化的拓扑发现与资源协商机制，能够动态识别 Super POD 内的 GPU 互联拓扑 结构，并根据硬件特性自动协商最优的传输协议参数与流控策略。系统通过标准化的内核对象模型，支持对不 同代际、不同架构的 GPU 及互联设备进行动态适配，自动处理地址空间映射冲突与权限校验，消除了因驱动 版本不一致导致的兼容性瓶颈。同时，内核集成了细粒度的 QoS 调度算法，依据 AI 训练任务的优先级动态分 配带宽资源，防止关键通信流受到背景流量干扰，为上层应用提供低延迟、高吞吐且具备强一致性的通信原语。
在超节点（Super POD）架构中，操作系统统一内存子系统通过深度集成 CXL 内存管理、UVM（统一虚拟 寻址）、xSHMEM 及 DMA-BUF 等关键技术，构建了跨越 CPU 与 GPU 边界的连续虚拟地址空间。CXL 驱动是将下一代异构内存生态接入系统的桥梁，它负责发现、初始化和管理通过 CXL 总线连接的池化内存设 备，将它们无缝集成到系统总内存资源池中，从而突破本地内存容量限制，缓解“内存墙”瓶颈。
内核内存管理器不再将 GPU 显存视为独立的物理设备，而是将其纳入系统全局虚拟内存（VMA）的统一调 度范畴，这背后离不开 SPM（统一内存分配器） 这一关键软件模块的智能调度。SPM 作为“全局内存调度 中心”，对上层应用抽象出巨大的统一地址空间，并根据数据的热度、访问模式及设备亲和性，智能地将数据 页面分配到最合适的物理位置（如本地显存或 CXL 内存池），最大化整体内存利用率和访问效率。它利用 UVM 机制实现 CPU 与 GPU 对同一内存区域的透明访问。当应用层发起跨设备内存访问时，内核自动处理页表映 射与缺页中断，确保数据在 CPU 内存与 GPU 显存之间按需迁移，从而为大规模 AI 训练任务提供逻辑上连续、 物理上分布的单一地址视图，彻底消除了传统模式下显式数据拷贝带来的性能损耗。
针对高性能数据交换需求，OS 内核通过 DMA-BUF 框架 实现了多设备间的零拷贝共享机制。该机制允许 GPU、RDMA 网卡及存储控制器直接共享同一块物理内存缓冲区，无需经过 CPU 内存的中转复制。内核在 分配内存时即预留 DMA 能力，并建立统一的物理地址到设备虚拟地址的映射表，使得不同硬件单元能够直接 通过物理地址进行读写操作。结合 CXL Type-3 设备特性，系统进一步支持了内存池化与扩展，允许 GPU 直 接访问远程 CXL 内存池，大幅突破了单卡显存容量限制，同时保持了极高的带宽利用率，满足千亿参数模型 训练对海量数据吞吐的严苛要求。
在内存生命周期管理与安全隔离方面，统一内存子系统提供了细粒度的分配、映射与回收策略，而 IOMMU 是 实现硬件资源安全隔离与高效直通的核心硬件保障。IOMMU 如同“交通警察”，位于 CPU 与 PCIe 设备之 间，负责将设备发起的物理地址请求转换为正确的系统物理地址并进行严格的权限检查，防止某个任务或用户 的 GPU 误访问或篡改其他任务的内存空间，为多租户环境下的虚拟化、容器化和安全隔离提供了硬件基础。 内核采用基于引用计数的共享内存管理机制，自动追踪 xSHMEM 等通信原语中的内存使用状态，确保在多 进程、多容器并发场景下内存资源的安全释放，防止内存泄漏。同时，系统支持大页（HugePage）与透明 大页（THP）的自动适配，减少 TLB 缺失带来的性能抖动，优化了页表遍历效率。通过智能预取算法与异步 页面回写机制，内核能够预测 AI 训练中的数据访问模式，提前将所需数据加载至高速缓存或显存中，显著降 低了内存访问延迟，为超节点集群提供了高效、稳定且可扩展的内存资源底座。
图165 OMMU 系统架构图
在超节点（SuperPOD）架构中，操作系统网络栈针对容器化环境下的 AI 训练场景进行了深度重构，以突破 传统 TCP/IP 协议栈的性能瓶颈。InfiniBand与RoCE 这两种高性能网络协议是构建低延迟集群的物理基础， 而操作系统的相关协议栈和驱动则是发挥其效能的“灵魂”。无论是专有的InfiniBand还是基于以太网的RoCE， 其核心在于提供超低延迟、高带宽和 CPU 零参与的 RDMA 能力。内核中的 OFED 或 RDMA_CM 等协议 栈实现了这些复杂网络的通信语义，使得 MPI、NCCL 等库能以近乎硬件极限的速度进行跨节点数据交换。
内核原生集成了对 RDMA-CNI 与 Multus-CNI 等容器网络插件的完整支持，使得 Kubernetes 容器能够直 接挂载高性能 RDMA 网卡，绕过内核协议栈的冗余处理路径。通过在内核态实现零拷贝数据路径，网络数据 包直接从应用层内存传输至网卡硬件，消除了用户态与内核态之间的多次上下文切换与数据拷贝开销。这种机 制确保了在大规模分布式训练中，容器内的 GPU 进程能够以微秒级延迟和线速吞吐量进行跨节点通信，满足 参数同步与梯度聚合的严苛时效要求。
为了进一步提升网络 I/O 效率，操作系统深度集成了 DPDK、io_uring 等高性能用户态网络库与内核接口。 通过 io_uring 提供的异步 I/O 提交与完成队列机制，应用层能够高效地批量处理网络请求，显著降低了系统 调用频率与 CPU 中断负载。同时，利用 DPDK 的用户态轮询驱动技术，关键通信路径完全脱离内核协议栈， 直接在用户空间完成数据包的分发与处理，实现了确定性的低延迟传输。
在容器网络隔离、资源调度及存储扩展方面，OS 网络栈通过命名空间与 cgroup 机制实现了精细化的流量控 制与资源保障。同时，NVMe-oF 技术作为操作系统的“空间折叠术”，通过内核客户端驱动，让计算节点能 够像访问本地硬盘一样访问网络存储池中的 NVMe 固态盘，实现了计算与存储的解耦。这使得 AI 工厂可以 弹性挂载不同性能等级的存储卷，实现存储资源的集中化管理与灵活扩展。系统支持基于硬件队列的流控策略， 能够为不同的训练任务分配独立的带宽配额与优先级。结合内核级的拥塞控制算法与动态路由选择机制，网络 栈能够根据实时网络拓扑与负载情况自动优化数据传输路径。此外，针对多网卡聚合场景，内核实现了智能负 载均衡与故障快速切换功能，确保在链路波动或设备故障时，AI 训练任务仍能保持高可用性，维持集群的整 体通信稳定性。
在超节点（SuperPOD）架构中，操作系统通过深度集成 cgroup v2 与容器运行时接口，构建了多维度的资 源隔离体系，确保多 GPU、多容器环境下的资源独占性与公平性。内核利用 cgroup 的 CPU 配额、内存限 制及 IO 带宽控制功能，将每个训练任务严格限制在指定的计算资源范围内，防止“嘈杂邻居”效应导致的资 源争抢。针对 GPU 资源，系统结合设备插件机制实现了显存与计算单元的精细化切分，支持将单张物理 GPU 逻辑划分为多个独立实例，或通过 MIG（Multi-Instance GPU）技术提供硬件级的隔离保障。这种隔离机制 不仅保障了关键 AI 训练任务的 SLA，还有效避免了不同任务间因资源竞争引发的性能抖动，为大规模集群的 稳定运行提供了基础约束。
为了最大化硬件利用率并降低通信延迟，OS 调度器实施了严格的 NUMA（非统一内存访问）感知策略与 CPU 亲和性（CPU Affinity）绑定机制。内核在进程调度时，优先将计算任务分配给与 GPU 位于同一 NUMA 节 点的 CPU 核心，确保数据访问走本地内存通道，避免跨 NUMA 总线带来的高延迟与带宽损耗。同时，通过 IRQ Balance 与中断亲和性设置，系统将网卡、RDMA 设备及 GPU 产生的硬中断精准绑定至特定的 CPU 核心， 避免中断风暴干扰计算线程的执行。这种细粒度的拓扑感知调度，显著减少了上下文切换开销与缓存失效 （Cache Miss），使得计算密集型任务能够持续保持高吞吐状态，充分发挥超节点硬件的峰值性能。
在负载均衡与故障恢复方面，操作系统内核引入了动态负载监测与智能迁移策略。系统实时监控各计算节点、 GPU 单元及网络链路的负载水位，当检测到局部热点或资源瓶颈时，调度器可依据预设策略将非关键任务迁 移至空闲节点，实现集群层面的全局负载均衡。针对关键训练任务，内核支持热迁移与快速故障恢复机制，一 旦检测到硬件异常或节点宕机，能够迅速将任务状态保存并重启至备用资源上，最小化训练中断时间。此外， 通过结合 QoS 优先级队列与实时调度策略（如 SCHED_FIFO），系统能够确保高优先级的参数同步与梯度 聚合操作优先获得 CPU 时间与 I/O 带宽，从而在复杂的并发场景下维持整体集群的高可用性与确定性性能表 现。
在超节点（SuperPOD）架构中，操作系统通过 VFIO（Virtual Function I/O）与 ZONE DEVICE 机制构建 了统一的异构计算资源抽象层，屏蔽了底层硬件厂商（如国产 CPU、NVIDIA GPU、AMD GPU）的私有指 令集与寄存器差异。VFIO 利用 IOMMU 硬件辅助功能，将物理设备直接映射到用户空间，提供安全的 DMA 访问通道，使得 AI Runtime 无需加载特定的内核驱动模块即可直接操控异构加速器。ZONE DEVICE 框架 则进一步将不同架构的计算单元抽象为标准的内存区域对象，内核统一处理这些设备的内存分配、地址翻译及 生命周期管理，从而在系统层面形成了一套标准化的设备访问接口。这种抽象机制有效解耦了上层应用与底层 硬件的强依赖关系，显著降低了多厂商硬件混部场景下的适配复杂度，提升了系统的可移植性。
针对异构环境下的内存访问效率问题，操作系统深度集成了 THP（透明大页）与 HugePage 技术，优化了 跨设备数据交换的页表管理。在混合架构中，不同硬件对内存页大小的支持存在差异，内核通过智能识别与自 动配置，为关键计算任务分配大页内存，大幅减少了 TLB（页表缓冲区）缺失率与页表遍历开销。对于国产 CPU 与异构 GPU 之间的数据共享，系统利用统一的虚拟地址空间映射机制，确保大页内存能够在不同设备间无缝 流转，避免了因页表碎片化导致的性能抖动。此外，内核还实现了针对异构内存带宽的自适应调度策略，根据 实时负载动态调整内存分配粒度，确保高带宽需求的数据流能够充分利用物理内存通道的峰值能力。
在设备管理与兼容性保障方面，OS 内核建立了标准化的设备枚举与属性查询接口，自动识别并注册接入系统 的各类异构计算单元。无论底层硬件是 NVIDIA 的 CUDA 架构、AMD 的 ROCm 架构还是国产加速卡，内 核均能通过统一的字符设备节点或网络接口暴露其计算能力与显存状态。系统内置的兼容性适配层能够自动协 商不同硬件间的通信协议与传输参数，消除因驱动版本不一致或指令集差异导致的运行错误。同时，内核提供 了细粒度的设备健康监控与故障隔离机制，当检测到某类异构设备异常时，能够自动将其从资源池中剔除并触 发任务迁移，确保集群在部分硬件故障情况下仍能维持整体服务的连续性与稳定性，为大规模异构算力集群的 长期稳定运行提供了坚实的软件基础。
在超节点（SuperPOD）架构中，操作系统通过深度集成 FUSE 框架与高性能并行文件系统（如 3FS、 X20000），构建了面向 AI 训练场景的持久化存储底座。内核利用 FUSE 的用户态扩展能力，将 3rd-Storage 等外部存储协议无缝挂载至本地文件系统命名空间，使得应用层能够以标准 POSIX 接口访问分布式存储资源。 针对大规模模型检查点（Checkpoint）与海量训练数据集的读写需求，系统采用 3FS 与 X20000 的元数据 分离架构，将元数据操作卸载至专用控制节点，大幅提升了小文件并发读写性能。这种架构设计消除了传统单 机文件系统在面对 PB 级数据时的元数据瓶颈，确保了在万卡集群环境下，模型参数的快速保存与加载能够线 性扩展，满足高频次断点续训的严苛时效要求。
为了进一步突破 I/O 性能极限，操作系统内核直接集成了 DIO（Direct I/O）与 SPDK（Storage Performance Development Kit）等用户态加速技术，构建了绕过内核缓冲区的零拷贝数据路径。这其中，GPU Direct Storage 是为化解数据供给瓶颈而开启的“存储直送专线”。传统流程中，训练数据需从 SSD 经 CPU 内存 再拷贝到 GPU 显存。GDS 通过在操作系统内核中引入新的驱动路径，让 GPU 能直接向 NVMe SSD 发起 DMA 请求，将数据块直接搬移到显存，极大地减轻了 CPU 负担，提升了数据加载吞吐量，使 GPU 能持续 处于高效计算状态。
图166 GPU Direct Storage 和传统技术对比图
通过 DIO 机制，应用程序能够直接将数据从用户空间传输至磁盘或网络存储设备，避免了内核页缓存（Page Cache）带来的内存拷贝与一致性维护开销，显著降低了 CPU 占用率。结合 SPDK 的用户态轮询驱动与 NVMe-oF 协议支持，存储子系统能够利用多核并行处理能力，实现微秒级的 I/O 延迟与线速吞吐量。这种全 链路加速机制有效解决了 GPU 计算速度远超传统存储读写速度的“木桶效应”，确保在大规模分布式训练中， 数据加载与模型持久化操作不再成为制约整体训练效率的瓶颈。
在存储资源调度与可靠性保障方面，OS 实现了智能 I/O 流控与多级缓存协同策略。内核根据训练任务的优先 级动态调整 I/O 队列深度与带宽配额，优先保障关键检查点写入任务的实时性，防止背景数据备份任务干扰核 心计算流程。同时，系统利用本地 SSD 作为高速缓存层，结合远程并行文件系统的持久化能力，构建了“本 地高速缓存 + 远程高可靠存储”的分级存储体系。针对突发的大规模数据读取请求，内核自动触发预读算法 与缓存命中优化，减少网络传输延迟。此外，存储子系统内置了数据校验与自动修复机制，能够在硬件故障发 生时快速恢复数据完整性，确保超节点集群在长期连续运行中的数据安全与业务连续性。
在超节点（SuperPOD）架构中，操作系统内核与 AI Runtime 层（包括 JEMALLOC、GCC、CUDA、 PTX 及 NCCL 等组件）建立了深度的协同优化机制，通过暴露底层硬件性能调优接口，打通了从应用逻辑到 物理硬件的端到端数据路径。内核提供了优化的 Pin Memory（锁定内存）分配策略，允许 Runtime 直接申 请物理连续且不可换页的内存区域，确保 GPU 在进行 DMA 传输时无需进行地址转换或数据拷贝。同时，系 统通过 LOCAL/REMOTE MEMORY 标识符，引导 Runtime 智能识别内存拓扑位置，自动将高频访问数 据调度至本地 NUMA 节点或显存中，减少跨节点访问延迟。这种紧密协作使得 NCCL 等通信库能够直接利 用内核提供的拓扑感知能力，动态选择最优的通信路径，显著提升了大规模分布式训练中的参数同步效率。
针对计算密集型任务，操作系统与编译器栈（如 GCC、CUDA 编译器）及 PTX 中间表示层进行了深度集成， 实现了指令级与线程级的上下文切换优化。内核通过细粒度的 CPU 亲和性绑定与中断屏蔽技术，为 Runtime 的关键计算线程提供独占的执行环境，避免操作系统调度器引入的上下文切换抖动。同时，系统支持大页内存 （HugePage）与透明大页（THP）的自动适配，结合 JEMALLOC 的内存池化策略，Runtime 能够以更 低的开销管理海量临时数据，减少页表遍历带来的 TLB 缺失。此外，内核提供的性能计数器（Performance Counters）接口被 Runtime 深度利用，用于实时监控缓存命中率、指令流水线停顿等指标，进而动态调整 PTX 代码的调度策略与寄存器分配，最大化硬件计算单元的利用率。
在内存布局与资源调度层面，OS 与 Runtime 共同构建了统一的虚拟地址空间管理模型，消除了用户态与内 核态之间的地址映射鸿沟。Runtime 层利用操作系统提供的共享内存机制（如 xSHMEM、CXL 共享），实 现多进程、多容器间的高效数据交换，而内核则负责维护这些共享区域的权限校验与一致性同步。系统通过智 能预取算法与异步 I/O 提交队列，协助 Runtime 提前加载下一轮迭代所需的训练数据，掩盖 I/O 延迟。这种 端到端的协同优化不仅降低了系统调用的开销，还确保了在复杂异构环境下，AI 应用能够始终运行在硬件性 能的峰值区间，实现了从底层驱动到上层算法的全链路性能提升。
在超节点（SuperPOD）架构中，操作系统利用 IOMMU（输入输出内存管理单元）、PRP（优先级重映射） 及 MMIO（内存映射 I/O）等硬件辅助机制，构建了严密的内存保护与访问控制体系。IOMMU 通过硬件级的 地址转换与权限校验，强制隔离了不同 GPU、网卡及存储设备之间的直接内存访问路径，防止恶意或故障设 备越界访问其他进程的物理内存空间，确保数据隔离的绝对安全。PRP 机制则对关键系统资源的访问请求实
施优先级重映射，保障高优先级的训练任务指令在总线拥塞时仍能获得确定的执行窗口。同时，内核严格管控 MMIO 区域的映射范围，仅允许授权驱动访问特定的寄存器空间，杜绝了非法指令注入导致的硬件状态异常， 从底层物理层面确立了系统的可信执行环境。
针对大规模并发场景下的实时监控与故障响应，操作系统深度集成了 eBPF（扩展伯克利数据包过滤器）技术 与 CXL Pooling 动态管理机制。eBPF 程序在内核态以沙箱模式运行，能够无侵入地采集网络流量、内存使 用率及设备健康度等关键指标，实时构建系统运行的全景视图，并在检测到异常行为（如内存泄漏、死锁或异 常流量）时触发自动告警或熔断策略。结合 CXL 内存池化技术，系统实现了对共享内存资源的细粒度监控与 动态回收，一旦检测到某个计算节点或内存池出现不可恢复的硬件错误，内核能够迅速将该资源标记为不可用 并触发隔离操作，防止故障扩散至整个集群，确保关键 AI 训练任务的连续性与数据完整性。
在系统稳定性保障方面，OS 内核实施了多层级的容错与自愈机制。通过硬件看门狗与软件心跳检测的双重校 验，系统能够实时感知节点状态，一旦主节点失效，备份机制将立即接管控制权并重新调度任务。针对高负载 下的资源竞争，内核利用动态 QoS 策略与流量整形技术，限制非关键后台任务对核心计算资源的占用，防止 因资源耗尽导致的系统雪崩。此外，系统支持配置的热补丁更新与无损重启功能，允许在不中断正在进行的 AI 训练任务的前提下修复内核漏洞或升级驱动版本，从而在保障数据安全与系统高可用的同时，满足超节点集群 7x24 小时不间断运行的严苛要求。
在超节点（SuperPOD）架构中，操作系统内核针对海光 DCU、昆仑芯 GPU 及各类国产 CPU 等硬件进行 了深度的指令集与微架构适配。内核通过集成专用的设备驱动模块与固件接口，实现了对国产加速器计算单元、 显存控制器及片上互联总线的原生支持。系统利用标准化的 PCIe 枚举机制与自定义的寄存器映射表，自动识 别并初始化异构国产设备，确保其能够无缝接入现有的内存管理与 I/O 调度框架。针对国产 CPU 特有的多核 拓扑与缓存一致性协议，操作系统优化了 NUMA 调度策略与中断处理路径，消除了跨架构通信中的性能损耗， 使得国产算力资源能够以接近理论峰值的效率参与大规模分布式训练任务。
为了构建完整的自主软件生态，操作系统提供了从底层驱动到上层工具链的全栈支持能力。内核模块深度集成 了国产硬件的特定扩展指令集，支持对海光 DCU 的张量计算单元及昆仑芯的 AI 加速引擎进行直接调用。同 时，系统构建了兼容性的设备管理器，统一暴露国产设备的状态监控、功耗管理及故障诊断接口，使得运维工 具能够以一致的方式管理混合异构集群。在编译与调试环节，OS 内置的工具链支持针对国产 CPU 架构的交 叉编译与性能分析，能够生成高度优化的机器码，并配合国产编译器栈实现从源代码到可执行文件的端到端构 建，显著降低了开发者在自主可控环境下的迁移成本与适配复杂度。
在系统完整性与高性能保障方面，操作系统通过内核级的资源隔离与动态负载均衡机制，确保了自主环境下的 稳定运行。系统能够根据国产硬件的实际性能特征，自动调整内存分配粒度、线程绑定策略及网络通信参数， 最大化利用国产芯片的计算带宽与存储吞吐能力。针对国产硬件可能存在的微架构差异，内核实现了自适应的 容错与降级策略，当检测到特定功能模块异常时，能够自动切换至备用执行路径或启用软件模拟模式，防止单 点故障导致整个训练任务中断。这种深度适配不仅满足了超节点方案在自主可控环境下的完整性要求，还通过 精细化的软硬件协同优化，确保了自主替代场景下的高性能表现与业务连续性。
当 GPU 集群规模从数十张扩展至数千上万张，系统可靠性的设计哲学便发生了根本性转向：从追求避免故障 转变为主动管理故障。传统架构中，单点故障可导致服务中断，其应对措施集中于本地冗余与事后恢复。而在
千卡级 AI 超算中，硬件故障因规模效应成为常态，因此以 SuperPOD 为代表的新一代操作系统，其核心使 命是构建一个能在持续局部故障中保持全局算力持续输出的韧性系统。这一目标通过一个多层协同的自愈体系 实现：在硬件层，依托热插拔 GPU 与冗余基础设施，实现故障组件的在线隔离与更换，奠定“不停机修复” 的物理基础；在软件层，通过异步增量式检查点技术，将训练任务状态持久化于共享存储，为任意故障提供精 准的回溯点；在调度层，融合被动迁移与基于预测的主动疏散，实现计算任务在健康节点间的无缝漂移；在网 络层，通过多轨物理冗余与智能路径切换，保障即使出现链路或交换机故障，集群内部的高速通信也不中断、 不降级。这套体系共同作用，将故障影响从传统的“整机停机、任务重启、算力空转”优化为“组件级隔离、 任务秒级恢复、算力无损”，从而将万卡集群的总体有效算力最大化，真正使可靠性转化为生产力。
图167 普通 OS 与超节点 OS 对比
超节点架构可采用 Scale-up 技术互连计算节点、加速器与内存扩展设备连接为统一的 Scale-up Fabric， 从而支持资源解耦、容量扩展与共享访问。释放硬件潜能的关键在于软件控制平面——Fabric Manage（FM）。
FM 作为管理实体，可采用集中式或分层/分布式部署，并可通过节点侧代理/本地管理组件配合完成发现、监 控与执行。FM 负责对底层 Scale-up Fabric 进行初始化、配置、监控与变更控制，核心功能通常包括：
Fabric 发现、枚举与拓扑/状态建模：在系统启动或结构变更时，FM 通过管理通道对 Fabric 内的交换设备、 端口与连接关系进行发现与枚举，采集组件能力与运行状态，形成可用于运维与自动化的 Fabric 视图（包括 设备清单、端口状态、链路属性、可用能力等）。当拓扑或组件状态发生变化时，FM 负责更新视图并触发相 应的配置校验与后续编排流程。
资源发现与资源编排（绑定、分配、映射）：FM 负责发现并管理 Fabric 内可被编排的资源，例如内存扩展（以 及相关的访问能力与约束。FM 根据策略完成资源的分配与编排，包括但不限于：将目标资源绑定到指定主机 /节点或主机集合;配置与下发与资源访问相关的参数（例如访问窗口、解码/映射、隔离域等）;在资源变更（扩 容、缩容、迁移、回收）时进行一致性控制，确保配置生效过程可控、可回滚、可审计。
安全、隔离与访问控制：FM 负责在 Fabric 范围内实施安全与隔离策略，确保资源共享场景下的边界清晰与 权限最小化，包括：多主机/多租户场景的访问控制与隔离域管理；设备接入与能力校验（合规性检查）；与安 全相关配置的统一下发、变更控制与审计。
可靠性、可用性与可服务性与事件处置编排：FM 负责汇聚并处理 Fabric 内的事件与错误信息（包括链路/端 口状态变化、设备告警、错误计数与健康状态等），并基于策略执行故障处置编排，例如：故障定位与影响域 评估（哪些主机/资源/连接受影响）；隔离/降级/资源替换（将受影响资源下线、切换到冗余资源或重新分配）； 触发恢复流程并维护一致性状态（确保恢复过程中资源绑定与映射关系正确）。
变更管理与一致性下发：针对设备上线/下线、资源增减、权限调整等操作，FM 负责统一的变更编排与一致 性下发，保证变更过程可控（顺序、依赖、校验）、对业务影响可评估，并支持回滚与审计。
在面向预填充与解码分离架构的跨节点通信加速领域，操作系统内核深度整合了 GPU Direct RDMA 与 GPU Direct Storage 两大核心技术。通过将 P 节点生成的中间激活值直接映射至 D 节点的显存空间，系统彻底绕 过了传统 CPU 内存拷贝路径，实现了数据在 GPU 间零拷贝、低延迟的传输。这种设计不仅显著压缩了 Token 生成过程中因数据搬运产生的网络开销，更将通信延迟从毫秒级降低至微秒级，为大规模并发推理场景下的实 时响应能力提供了坚实基础。
为进一步突破跨机柜通信的性能瓶颈，系统构建了基于 Scale-up 交换技术的虚拟统一内存空间。借助 Scale-up 技术提供的远程内存访问能力，D 节点可直接访问 P 节点的计算结果，无需进行序列化、反序列 化或数据复制操作，从根本上消除了传统通信模型中的“软件开销墙”。该架构将原本分散在不同物理节点上 的显存资源抽象为一个逻辑连续的内存池，配合高速互联协议如 InfiniBand 与 RDMA NIC，实现了跨机柜级 的内存共享与数据同步，极大提升了模型推理的整体吞吐量与资源利用率。
针对 PD 分离架构下负载动态波动的特性，操作系统网络栈引入了自适应路由调度与拥塞控制机制，对 P-D 节点间的通信流量实施精细化管理。系统优先保障控制面（如请求调度、状态同步）与关键数据面（如激活值 流）的 QoS 等级，通过动态调整带宽分配策略，在高负载环境下仍能维持通信通道的稳定性和低延迟特性。 结合 NUMA-aware 调度、内存共享与 GPU P2P DMA 等底层能力，OS 确保跨节点通信带宽能够随集群 规模线性扩展，从而满足 AI 推理服务对低延迟、高吞吐 SLA 的核心诉求。
在大语言模型推理日益成为计算核心负载的今天，Scale-up 超节点架构通过集成数十张高性能 GPU 和极速 内部互联，为处理这类任务提供了强大的硬件基础。在这一架构中，操作系统扮演着底层资源协调与保障的关 键角色，而像 NVIDIA NIXL 这样的专用库则构成了智能调度与执行的中枢神经系统。
NIXL 库的核心使命是优化生产环境中的 AI 推理吞吐与延迟。它并非简单的通信库，而是一个高级的推理服 务编排引擎。在超节点环境中，NIXL 动态管理着海量的并发请求，执行智能的批处理操作以填满 GPU 计算 单元，并将请求精准路由到部署在特定 GPU 上的对应模型实例。操作系统则为这一切提供了稳固的基石，它 通过容器化技术实现多租户 GPU 资源的强隔离与安全共享，通过内核驱动抽象硬件细节，并保障整个服务栈 的高可用性。
当前沿技术向大语言模型推理深度演进时，超节点内部的协同优化出现了新的范式。业界领先的解决方案已经 开始提供类似 NVIDIA NIXL 库中 NIXL_Transfer 这样的硬件级优化接口。该接口旨在直接解决 LLM 推理 中 Prefill（预填充）阶段与 Decode（解码）阶段之间的关键性能瓶颈，即庞大的 KV Cache 数据传输问题。 传统方式需要经过主机内存中转，而 NIXL_Transfer 支持 GPU 之间的直接异步传输，彻底规避了昂贵的主 机内存拷贝开销，有望将端到端推理延迟显著降低。
这一硬件协同优化趋势对操作系统提出了更深层次的要求。首先，操作系统必须与硬件驱动进行更深度协同， 其内核需要将 GPU 之间的高速物理互联能力，安全且可靠地抽象为一种标准化的服务，并向上层库开放可控 的访问接口。其次，系统的资源调度器，从操作系统本身的进程调度到 Kubernetes 的 Pod 调度器，都需要 进化出对 GPU 互联拓扑的感知能力。这意味着调度决策不仅要考虑“是否有 GPU”，更要理解“哪些 GPU 之间拥有最高的直接带宽”，从而实现计算任务与硬件拓扑结构的最优匹配。最后，当 GPU 间直接数据通道 成为常态，操作系统必须在硬件层面强化对这一新路径的安全隔离，例如依托 IOMMU 等技术，确保在云原 生多租户环境下，不同用户间的数据绝对隔离，这是 Scale-up 架构走向规模化商用的必要前提。
综合来看，以 NIXL_Transfer 为代表的技术是突破 LLM 推理性能瓶颈的关键路径，它标志着优化重点从单 一芯片计算效率转向了芯片间协同效率。这一方向必将引发所有 AI 硬件厂商的广泛跟进，从而推动从硬件互 联、设备驱动、操作系统内核到中间件和调度器的全栈协同标准化。未来一至两年，这将是 Scale-up 推理 软件栈最核心的优化方向，最终目标是将超节点从一台强大的硬件设备，彻底转变为一个高效、透明且易管理 的巨型推理算力单元。
Scale-up 架构中 IODIE 与高速交换网络的开发，其根本价值在于通过重塑硬件通信能力基本面，构建了一 条从底层物理优化直达大模型应用性能提升的完整技术链条。这一链条始于超节点内部提供的高带宽、低延迟 与硬件原子操作能力，为海量的 Read、Write、Atomic 操作设立了全新的性能上限。中间的软件栈，特别 是通信库与调度器，通过精密的算法将原始操作封装为高级语义接口，并借助流控、保序与负载均衡机制，确 保数据流能稳定、高效地逼近硬件极限。最终，这一整套协同优化使得大模型训练中的梯度同步时间急剧缩短， GPU 计算利用率得以持续饱和；在推理侧，则让 KV Cache 等关键数据的传输延迟被有效隐藏。其核心因 果逻辑在于，将网络从传统分布式计算中的性能瓶颈，转化为让数十张 GPU 凝聚为单一强大算力容器的“神 经束”，从而直接将底层的每一次比特移动，无损地转化为上层模型迭代速度的飞跃与推理服务质量的质变。
AI 工作负载的极端动态性和异质性导致传统紧耦合服务器架构下资源碎片化问题日益严重：在万卡级训练中， 模型参数、激活值、梯度、Optimizer 状态和 KV Cache 的显存占用极不均匀，MoE 模型的专家并行进一 步放大碎片，导致整体 GPU 利用率不高；推理场景中，长上下文 RAG 任务的 KV Cache 可瞬间膨胀数百 GB，而后续生成阶段又迅速收缩，单节点 HBM 无法弹性应对，造成大量显存浪费或频繁 OOM。在混合负 载 AI Factory 中，训练、微调、推理、embedding 生成等多租户并发，资源需求在时间和空间维度上剧烈 波动，传统静态分区方式（MIG/MPS）虽能隔离但无法实现细粒度动态复用，碎片化最终转化为算力浪费和 TCO 暴增。
资源池化本质上是 Disaggregated Infrastructure 在 AI 领域的落地实践，即将计算（GPU/CPU）、内存 （HBM/DRAM/CXL）、存储（NVMe-oF）和网络（RDMA Fabric）从物理紧耦合转向逻辑解耦，形成可 独立扩展、按需组合的资源池。计算池以 GPU/TPU 为核心，支持 MIG/SR-IOV 切分后按需分配；内存池
通过 CXL 或 PCIe Switch 实现远程 DRAM/HBM 共享，允许单个 GPU 访问远超本地容量的内存空间；存 储池借助 NVMe-oF + GPUDirect Storage 实现从远程 SSD/NVMe 直达 GPU 的零拷贝路径；网络池则 通过高性能 Fabric（如 InfiniBand 800G 或 RoCE v2）确保跨池访问延迟可控。真正有效的池化需满足三 个关键特性：一是语义统一（统一 Load/Store 访问模型），二是低延迟（<200ns 远程访问），三是强隔离（硬 件级加密+虚拟化）。解耦后，AI Factory 可实现真正的“计算即服务”：一个训练作业可动态借用空闲节点的 HBM 作为扩展 KV Cache，推理服务可瞬时扩展内存支持 1M+上下文，而无需重启或迁移整个容器。
CXL 2.0 与即将到来的 CXL 3.0 是内存池化的核心使能技术。CXL 2.0 基于 PCIe Gen6 物理层，提供 256 GB/s x16 双向带宽，支持 Type-2 设备（带缓存一致性的加速器，如 SmartNIC 或自定义内存控制器）和 Type-3 设备（纯内存扩展器），Switch-Based Pooling 允许数十至数百个主机共享同一内存池，通过 CXL switch fabric 实现多对多连接。Weighted Interleaving 是 CXL 3.0 的关键创新，根据权重动态分配内存访 问（例如将 80%访问分配给低延迟本地 DRAM，20%到远程 CXL 内存），极大缓解了 NUMA 效应。CXL 4.0（预计 2028–2030）进一步提升至 512 GB/s+带宽，并引入更强的 TSP 安全协议和光互联准备。
Linux 内核从 6.9 开始对 CXL 支持进入生产级成熟阶段，cxl driver 全面支持 CXL 2.0 的 Type-2/3 设备枚 举、端口管理和内存映射；weighted interleaving 通过/sys/devices/cxl/接口配置权重，实现异构内存的非 均匀访问策略；flat memory mode 将 CXL 内存暴露为统一地址空间，配合 HMM（Heterogeneous Memory Management）实现 GPU 直接 Load/Store 远程页。virtio-mem 提供动态热插拔能力，允许运 行时添加/移除内存段，结合 madvise(MADV_COLD)实现内存 tiering（DRAM → CXL → SSD）。
图168 内核 6.9 支持 CXL 图
控制平面集成 Kubernetes Dynamic Resource Allocation（DRA）从 1.26 开始支持 CXL 内存等可扩展 资源，通过 ResourceClaim 模板定义“cxl-memory-gb”资源类型，Custom Scheduler（Volcano/Kueue
扩展）根据拓扑、负载和内存需求实时分配。Liqid 和 GigaIO 的控制平面通过 REST API 与 Kubernetes 集成，实现运行时资源组装：Pod 启动时动态申请远程 DRAM，释放时归还池中。
AI 特有收益是资源池化的最大价值所在：KV Cache 池化允许将长序列生成的键值对从本地 HBM 溢出到 CXL 共享内存，按需加载回 GPU，在 1M 上下文 RAG 任务中，池化后单节点可支持原先更高的并发 QPS； RAG 长上下文的内存膨胀/收缩通过 virtio-mem + weighted interleaving 动态调整，膨胀时热插拔远程 DRAM，收缩时冷页迁移到 SSD，内存利用率提升。训练/推理混合负载下，池化实现动态分配：训练高峰 期借用空闲推理节点的 HBM，推理突发时反向借用训练节点的 DRAM，结合 Checkpoint/Restart 的无缝 迁移，整个集群在峰谷负载波动中保持较高利用率。
内存访问
未来 AI 工作负载下的统一内存访问需求画像
未来 AI 工作负载，尤其是 2026–2030 年间的万亿甚至十万亿参数模型，将对内存访问模型提出前所未有 的统一性要求：训练阶段需要无缝访问海量参数、激活、梯度、Optimizer 状态和 KV Cache；推理阶段要 求毫秒级响应长上下文生成，同时支持动态 KV Cache 膨胀/收缩和 RAG 检索；混合负载下，训练、微调、 推理、embedding 生成等多任务并发，内存需求在时间和空间上剧烈波动，单次生成可能瞬间需要数百 GB 额外内存，而下一迭代又迅速释放。传统 DMA Read/Write 模型下，这些需求导致频繁的显式拷贝、Pinned Memory 分配爆炸、页面故障抖动和编程复杂度指数级上升。在前瞻研究和多个前沿 AI Factory 项目中，统 一Load/Store语义已成为必然趋势：GPU/CPU/加速器像访问本地DRAM一样直接Load/Store远程CXL 内存或 Fabric 共享内存，编程模型接近单机统一内存（UMA），无需 cudaMemcpy、Pinned 分配或显式 同步。这种需求画像的核心痛点在于：当前异构系统下，内存仍是“私有孤岛”，而未来 AI 将要求“全局内存 湖”，任何设备都能以近似本地速度访问全集群内存池，实现真正的“内存即服务”。
传统 DMA Read/Write 模型是当前异构计算的主流路径，但其局限性在超大规模 AI 中已暴露无遗。首先， Pinned Memory（cudaHostRegister / cudaMallocHost）虽能加速主机→设备拷贝，但会锁定主机物理 页，导致系统 DRAM 碎片化严重，在高并发推理中 Pinned 分配往往耗尽主机内存，触发 OOM 或 swap 抖动。其次，复制开销巨大：训练中每迭代需多次主机↔设备、GPU↔GPU 拷贝，AllReduce 前梯度需显 式 Pinned 并拷贝，KV Cache 管理需反复搬运长序列数据。第三，编程复杂度爆炸：开发者需手动管理 Pinned 分配、流同步、异步拷贝、重叠计算、错误处理和内存释放，代码中充斥 cudaMemcpyAsync、 cudaStreamSynchronize 和 cudaHostUnregister，极易引入 race condition 或内存泄漏。在多租户 AI Factory 中，这种显式模型还导致隔离困难，租户间 Pinned 内存竞争引发性能噪声。
统一 Load/Store 语义的核心是构建一个全局地址空间，让 CPU、GPU、DPU、CXL 内存扩展器和 Fabric 共享内存像访问本地一样直接使用 load/store 指令，而无需显式 DMA。体系图从底层到上层可分为四层协 同：
硬件互联层：CXL.mem 提供远程内存的 Load/Store 语义，NVLink-C2C 实现 CPU-GPU 间统一地址空 间，InfiniBand/RoCE Fabric 通过 GPUDirect RDMA 扩展到跨节点。
硬件与互联层是统一 Load/Store 语义的物理基础。未来 CXL.mem（CXL 3.0+）允许 Type-3 设备作为系 统内存扩展，CPU/GPU 通过 load/store 直接访问远程 DRAM，支持 switch pooling 和 weighted interleaving，实现多主机共享。NVLink-C2C（Grace-Hopper/GB200/Rubin）在 CPU-GPU 间构建 全硬件一致性UMA域，带宽达1.8 TB/s+，支持原子操作和缓存一致性，GPU可直接load/store CPU DRAM， 反之亦然。HMM 扩展页表共享，让 GPU 页表映射 CXL/Fabric 内存，页面故障时内核触发迁移或就地访问。 UMA（Unified Memory Architecture）架构在硬件层面实现全局地址空间，Blackwell/Rubin 的 Tensor Memory Accelerator 进一步加速统一内存预取。
Linux 内核从 6.9 开始加速向统一内存演进，页表共享通过 HMM 的 device-private pages 和 multi-page table 支持 GPU 直接映射远程内存；远程内存注册为 NUMA 节点，cxl driver 提供/dev/cxl/接口，允许动 态添加/移除 CXL 内存段。内存分级（tiering）结合 damon、madvise(MADV_COLD/HOT)和 autonuma， 实现 DRAM（热层）→CXL（温层）→SSD（冷层）的自动迁移，weighted interleaving 根据负载权重分 配 访 问 比 例 。 virtio-mem 和 hotplug 内 存 支 持 运 行 时 扩 展 ， 结 合 numactl --membind 和 kernel.numa_balancing=0（生产环境常关闭自动平衡以防抖动）精细控制策略。
图169 Linux 内核 6.9 内存管理图
AI 框架对统一内存的适配是落地统一语义的关键一环。PyTorch 通过 torch.cuda.UnifiedMemory 和 torch.utils.checkpoint 实现托管内存分配，torch.compile + inductor 后端自动识别 load/store 模式，减少 显式拷贝；TensorFlow 的 UnifiedMemory API 和 tf.experimental.dlpack 支持直接共享 CXL 内存；JAX 的 jax.Array 在 pmap/shmap 下原生利用 HMM 映射远程页；XLA 编译器通过 Buffer Donation 和 Unified Buffer 优化统一内存访问路径，避免不必要的分配/释放。
操作系统在超节点时代已从传统的资源管理器，彻底演变为 AI 基础设施的“神经中枢”与“互联大脑”。在单 节点多 GPU 的 Scale-up 场景中，OS 负责拓扑发现、NUMA/CXL 亲和调度、Pinned Memory 优化、 GPUDirect 路径管理、功耗热控与故障域隔离，将数十至数百张 GPU 真正融合为逻辑统一的“巨型加速器”； 在跨节点万卡级的 Scale-out 场景中，OS 通过 RDMA 子系统、NCCL/SHARP 集成、GPUDirect Storage、 CXL 内存池化驱动和 topology-aware 调度，支撑 AllReduce、KV Cache 共享与动态资源借用，真正让 “cluster = giant GPU”从概念落地为生产级现实。
当前，OS 面临的挑战依然严峻：NUMA/CXL 异构内存访问的延迟非均匀性、跨节点通信的拥塞风暴、多租 户场景下的噪声与碎片化、异构 xPU 驱动的兼容性与稳定性，以及海量小文件 I/O 与长序列 KV Cache 的内 存膨胀压力，都在考验内核内存子系统、调度器、RDMA 栈与容器运行时的极限协同能力。自主化进程进一 步放大了这些挑战的紧迫性：从飞腾/海光/鲲鹏 CPU 到昆仑芯/沐曦/天数/寒武纪 xPU 等等，再到国产高性能 网卡与 CXL 内存扩展器，全栈自主可控要求 OS 在驱动适配、通信库优化、拓扑感知与安全隔离上实现端到 端国产替代。
展望未来 5–10 年，随着 PCIe 7.0/8.0、CXL 3.0/4.0、NVLink 5.0/6.0、光互联与片上光电混合计算的商用， 操作系统将迎来全面重构：统一内存语义（Unified Load/Store）将成为默认编程模型，HMM 与 CXL.mem 深度融合实现全局地址空间；内存分级与自动 tiering 演进为 AI 感知的智能分层（AI-driven tiering），根据模 型层级、注意力分布与访问热图动态迁移 KV Cache 与激活值；内核调度器将从 NUMA-aware 升级为 fabric-aware 与 memory-semantic-aware，支持跨节点、跨内存池的原生迁移与借用；容器与虚拟化层 通过 DRA、virtio-mem 与 runc/youki 的深度改造，实现亚秒级资源组装与热插拔；安全层面，硬件级 TSP （Trusted Security Protocol）与 eBPF 驱动的零信任隔离，将成为 AI Factory 多租户的标配。
最终，操作系统将从“基础设施”升华为“AI 原生操作系统”，与硬件、通信库、框架和调度器共同构成一个 自适应、自愈、自我优化的算力中枢。国产 AI Factory 的成功，不再仅仅取决于芯片算力密度，而将取决于 谁能率先在 OS 层实现全栈自主可控的互联统一、内存统一与调度统一。操作系统，正迎来它在 AI 时代最激 动人心的重生。
超节点技术选型与部署实践
超节点（Super Pod）作为支撑大规模人工智能模型训练与推理的核心基础设施单元，其技术选型直接关系 到系统性能、成本效率、长期演进能力及合规安全性。面对异构硬件生态快速演进、模型架构持续迭代、业务 场景日益多元的复杂环境，传统的“性能优先”或“成本导向”单一维度评估已难以满足实际需求。选型方法 论提出一套系统化、可量化、可复用的超节点技术选型框架，旨在通过“需求驱动—多维评估—动态决策”的 闭环流程，实现科学、稳健且面向未来的选型决策。
超节点作为 AI 时代智算基础设施的核心计算单元，其技术选型并非简单的硬件或软件搭配，其核心意义主要 体现在五个方面。
一，支撑超大规模 AI 任务高效落地。当前大模型参数已从千亿迈向万亿级别，MoE 等先进架构广泛应用，对 算力规模、通信带宽、延迟控制提出极高要求，合理的技术选型能实现计算、存储、网络资源的深度融合，破 解传统集群架构的扩展性瓶颈，确保超节点可高效支撑超大规模模型训练与推理任务，契合 Scale Up 架构的 性能提升需求，如英伟达 Blackwell 超节点 72 卡配置，基于任务需求实现性能与复杂度的均衡适配。
二，保障业务性能与体验的稳定性。超节点的核心价值的是通过一体化设计实现高性能、低延迟、高可靠的计 算能力，技术选型直接决定算力利用率、延迟控制精度、系统容错能力等关键指标，能否匹配业务的延迟敏感 需求、算力弹性需求，直接影响下游业务的运行稳定性，例如实时交互类场景的毫秒级延迟诉求、离线训练场 景的高吞吐量需求，均需通过精准选型实现落地。
三，优化全生命周期总拥有成本（TCO）。超节点部署涉及初始硬件投入、软件授权、部署实施、运营维护、 迭代升级等多环节成本，科学的技术选型可实现性能与成本的平衡，避免盲目追求高端配置导致的资源浪费， 同时降低后续运维难度与升级成本。
四，规避生态兼容与合规风险。超节点技术选型需兼顾现有技术生态的适配性与行业合规要求，合理的选型可 减少与现有系统、第三方工具的对接成本，避免出现生态碎片化或厂商锁定问题，同时满足数据安全、隐私保 护、行业监管等合规要求，为超节点长期稳定运行筑牢基础。
五，构建长期技术竞争力。超节点技术迭代速度快，硬件芯片、互联协议、软件框架持续升级，精准的技术选 型能兼顾当前需求与未来扩展潜力，确保超节点系统可适配技术迭代与业务增长需求，避免选型滞后导致的系
统淘汰或大规模重构，同时通过自主可控相关技术的选型布局，提升供应链安全性，构建差异化技术优势，为 业务长期发展提供算力支撑。
框架由两大核心模块构成：需求分析 与 业务指标，二者相互支撑、逐层递进。 需求分析 聚焦业务与技术场景的本质诉求，从五个关键维度对超节点的能力边界进行精准刻画：
业务指标 在明确需求基础上，围绕五大高阶维度对候选技术方案进行综合评估：
• 性能要求：不仅关注理论峰值性能，更强调实际工作负载下的有效吞吐、扩展效率与能效表现；
通过该框架，组织可在复杂技术选项中快速识别最优解，降低试错成本，提升基础设施投资回报率，并为 AI 系统的可持续演进奠定坚实基础。
在超节点技术选型过程中，模型规模是决定硬件资源配置与系统架构设计的核心前置条件。模型的参数量级与 架构复杂度直接决定了计算、内存、通信等资源的需求基线，而训练与推理两个阶段在资源使用模式上存在显 著差异，必须分别建模、精准评估。本节将从参数量级与架构特征出发，系统分析不同阶段的资源需求特点， 为后续算力匹配与系统设计提供依据。
模型的参数量级是衡量其规模最直观的指标，通常以“百万（M）”、“十亿（B）”或“万亿（T）”为单位。当 前主流大模型参数量普遍处于 7B 至 671B 区间，部分领先模型已突破万亿级别。参数量越大，对显存容量、 带宽和计算吞吐的要求呈非线性增长。
在评估参数量级时，需结合模型架构类型进行综合判断，常见架构包括：
此外，还需关注以下架构复杂度因素：
评估建议：在选型初期，应获取目标模型的完整架构文档或配置文件（如 config.json），明确参数总量、层数、 头数、隐藏维度、专家数量等关键信息，并结合架构类型预估实际资源消耗，避免仅依赖“参数量”单一指标 进行粗略估算。
推算模型在训练或推理过程中所需的显存（GPU Memory），是模型部署和优化中的关键步骤。显存消耗主 要来自模型参数、梯度、优化器状态、激活值（activations）以及临时缓冲区等。其中，模型参数本身的存 储是最基础的部分，其大小直接与参数数量和所使用的数值精度（如 FP32、FP16）相关。
临时张量=经验值为基础显存的 1-3 倍（与模型结构/batch size 相关） FP32训练基础显存(GB) = (参数数量 × (4+4+8)) / 1073741824 = (参数数量 ×16) / 1073741824 FP32 训练总显存 ≈ 基础显存 + 临时张量显存 示例：70 亿参数 FP32 训练基础显存 = (7×10⁹ ×16)/1073741824 ≈ 104.08 GB，加临时张量后需 100-300GB 显存。
FP32 与 FP16 的显存计算差异，本质是单参数字节数的 2:1 差异，在无额外显存开销的推理场景呈现严格 的 50% 显存占比；在有梯度、优化器开销的训练场景，因 Adam 优化器默认采用 FP32 存储，FP16 混 合精度的显存计算差异被稀释，最终比纯 FP32 节省 25% 左右的基础显存，这也是工业界选择 FP16 混 合精度训练的核心原因 ——以极小的精度补偿（如损失缩放），实现显著的显存节省。
FP8 单参数仅占 1 字节，与 FP32 形成 4:1、与 FP16 形成 2:1 的字节数差异，推理场景下显存可进一步压 至 FP16 的 50%、FP32 的 25%，且仍为浮点格式，精度稳定性远优于 INT8 量化。
| 组件 | FP32 | FP16（混合精度训练） | INT8 |
|---|---|---|---|
| 模型参数 | 4N | 2N（基于优化策略差异， 混合精度可能需再维护一 个FP32主副本 ） | 1N |
| 梯度 （Gradients） | 4N | 2N （通常与参数同精度） | 1N |
| 优化器状态 （如 Adam） | 8N （m + v 各 4N） | 若使用 FP32 主权重，则 仍需 8N | 若使用 FP32 主权重，则 仍需 8N |
| 激活值 （Activations） | 与 batch size、序列长度、 层数相关，通常远大于参 数 | 可减半（若用 FP16 计算） | 可减四分之三 |
有效算力（FLOPS，浮点运算次数/秒）= GPU 理论算力 × 算力利用率（η，0~1），需结合实际硬件 负载估算（避免仅用理论算力导致误差过大）。模型训练与推理的耗时计算逻辑完全通用，核心差异仅体 现在计算量的构成上：
单样本前向计算量（F_forward）：模型对单个样本（图像、文本 token 等）进行一次前向传播的浮点 运算总数（FLOPs），可通过 thop、torchprofile 等工具快速测算，无需手动推导。
硬件理论算力：GPU/TPU 等智算硬件的标称峰值算力（如 A100 FP16 理论算力 312 TFLOPS），需 匹配模型运行精度（FP32/FP16/INT8）选取对应算力值。
算力利用率（η）：硬件实际发挥的算力占理论算力的比例，受显存负载、数据加载、并行策略影响，训 练场景通常为 0.3~0.7，推理场景为 0.6~0.9（专用框架优化后可更高）。
Batch Size：单次运算处理的样本数，不影响总计算量，仅影响单步耗时和硬件利用率（合理增大可提升 利用率）。
推理仅需完成前向传播（无需反向传播和参数更新），单样本推理计算量=F_forward，场景分为批 量推理（离线处理）和实时推理（在线服务），公式可通用，仅关注指标不同。
已知：F_forward=1 GFLOPs，总推理样本数 100 万，A100 FP16 理论算力 312 TFLOPS， η=0.7（推理利用率）
计算过程：总计算量=10⁹×10⁶=1×10¹⁵ FLOPs；有效算力=312×10¹²×0.7≈218.4×10¹² FLOPS 推理总耗时=1×10¹⁵ ÷ 218.4×10¹² ≈ 4.6 秒；单样本延迟≈4.6 ÷10⁹≈0.0046 ms
训练的核心运算为“前向传播（计算预测结果）+ 反向传播（修正模型参数）”，其中反向传播计算 量约为前向传播的 2 倍（行业通用近似），因此单样本训练计算量≈3×F_forward；参数更新计 算量极小，可忽略不计。
简化推导：总计算量=3×F_forward×N_train×E，有效算力=GPU 理论算力×η，总耗时=总 计算量÷有效算力。
已知：F_forward=1 GFLOPs（单样本前向计算量），总训练样本数 100 万，训练轮数 10，A100 FP16 理论算力 312 TFLOPS，η=0.5（训练利用率）。
计算过程：总计算量=3×10⁹×10⁶×10=3×10¹⁶ FLOPs；有效算力=312×10¹²×0.5=156×10¹² FLOPS 训练总耗时=3×10¹⁶ ÷ 156×10¹² ≈ 192 秒 ≈ 3.2 分钟
业务指标基于具体场景区分核心指标，其中训练场景重点关注“算力效率、并行能力、训练周期”，核心指标 为训练吞吐量、训练并发量；推理场景重点关注“服务质量、用户体验、成本效益”，核心指标为推理吞吐量、 有效吞吐量、推理并发量，具体拆分如下：
训练场景的核心目标是“高效完成模型收敛、提升研发效率、控制训练成本”，核心关注 2 类指标：训练吞吐 量、训练并发量，具体细节如下：
定义
指超节点在单位时间内，能够完成的模型训练相关计算总量，是对硬件标称算力输出能力的直观度量，核心衡 量维度包括：
定义
指超节点在保持稳定性能、不出现明显算力瓶颈、不影响训练收敛效果的前提下，可同时承载的模型训练任务 数量，核心衡量维度包括：
推理场景的核心目标是“保障用户体验、提升服务效率、控制服务成本”，核心关注 3 类指标：推理吞吐量、 有效吞吐量、推理并发量，具体细节如下：
定义
指超节点在单位时间内，能够完成的模型推理相关数据处理总量，是衡量推理服务效率的基础指标，核心衡量 维度包括：
当前主流大模型（LLM）推理服务系统（如 vLLM、TensorRT-LLM 等），普遍将推理吞吐量作为核心基础 指标，其与服务成本（$/req）直接强相关，是工业界衡量推理服务效率的主流度量方式。
规模。
定义
推理场景特有的核心指标，指系统在满足预设延迟约束（如 TTFT/TPOT SLO）的前提下，真正完成的有效 推理请求数量。若一个请求因延迟过长被用户放弃、或超过服务约束而无效，即便产生了 Token，也不计入 有效产出。
大模型推理服务中最核心的延迟类 SLO（服务等级目标）包括：
DistServe 论文中明确了 Goodput 的核心价值：将吞吐量与延迟 SLO 绑定，是比单纯吞吐量更优的衡量指 标，贴合 LLM 在线服务的本质。以某应用为例：其要求至少 90%的请求同时满足 TTFT < 200ms 且 TPOT < 50ms，则该场景下的 Goodput 定义为——在保证 90%请求达标上述双延迟约束的条件下，系统所能维持 的最大每秒请求数（RPS）。
用途
定义
指超节点在保持稳定性能、不出现明显延迟飙升、满足 SLO 约束的前提下，可同时承载的模型推理请求数量， 体现超节点的多用户、多请求承载能力，核心衡量维度包括：
• 每秒处理的推理请求数（QPS）； 用途 衡量在线服务、AI 推理系统并发处理能力与业务承载能力的核心业务指标。 决定模型推理的关键表现 在大模型对话、AIGC 生成等场景中，QPS 表示系统每秒能够稳定处理并返回结果的用户请求数量。
客户业务为通用对话大模型在线推理服务，面向 C 端用户提供实时问答、文案生成能力，核心指标要求如下：
本次推理采用 INT8 精度部署：
结论：优先满足显存大于 800GB，总算力大于 51.9PFLOPS 的超节点，传统 GPU 服务器受 GPU 卡数限 制，总的显存池大小有限。以单卡显存 80GB 为例，8 卡只能达到 640GB，无法满足要求，需通过多 GPU 服务器级联显存，通信效率低，因此难以满足高 QPS 要求。超节点方案具备更大的显存池化、低延迟互联特 性，可完美匹配算力与显存双重需求。
客户为前沿科研机构，开展 1.4 万亿参数 MoE 大模型训练，目标为通用基座模型，指标如下：
随着大模型训练与推理场景的规模化落地，AI 集群正加速从传统通用分布式计算架构，向高密度、高功耗、 高互联的超节点架构深度演进，算力密度、供电负荷与散热需求呈指数级提升，单柜功率已从传统标准机柜的 数千瓦跃升至数十千瓦乃至上百千瓦。
传统数据中心以标准机柜为核心交付单元，采用低密度风冷散热、分散式供电的建设模式，在供电容量冗余、 机柜承重等级、制冷效率适配、布线空间预留等核心维度，已难以适配新一代智算场景下超节点的部署需求， 高功率密度部署过程中频繁面临供电瓶颈导致的算力输出受限、散热失效引发的设备稳定性下降、基础设施架 构与超节点集成需求不兼容等系统性难题，严重制约智算中心的算力交付效率与长期运维可靠性。
在此背景下，以大功率整机柜为基本交付单元的超节点方案，凭借其高集成度、高算力密度、高能效比的核心 优势，已成为当前智算中心提升算力规模化交付能力的主流选择，但其与生俱来的高功率负载、高度集成化设 计、风液混合制冷（部分场景为全液冷）的特性，对机房基础设施的顶层规划、方案设计、建设实施及全生命 周期运维，提出了更严苛、更体系化的要求，倒逼机房建设从传统“被动适配”向“主动协同”转型。
面向新一代智算中心高质量建设的核心需求，当前行业已逐步形成 “算电冷网一体化、预制模块化、机柜单 元化”的整体部署框架，通过供电架构升级、制冷模式革新、空间布局优化与机柜标准化设计的深度协同，实 现超节点从单柜部署到集群规模化落地的高效、有序推进。
结合国内多地大型智算中心的实践案例来看，以整机柜为核心的部署模式，并非简单的设备堆叠，而是需要在 机房规划初期，就同步完成基础设施与算力单元的一体化设计：
通过以上全链路协同设计，为超节点大规模、高可靠、快速交付提供稳定的基础设施基座，同时为后续算力扩 容、技术迭代预留统一接口，保障智算中心长期可持续发展。
本章节，目的是阐述数据中心机房液冷机柜与液冷机房的接口设计，通过标准化接口实现液冷机房对多厂家液 冷机柜设备的兼容部署，有效提升基础设施部署效率及运维灵活性。
机柜基础参数标准化
机柜设计可以满足 2000kg 静载及相关整机柜运输测试要求，机柜设计需要满足中国《建筑抗震设计规范》 （GB 50011-2010）和《YD 5083-2005 电信设备抗地震性能检测规范》8 烈度抗震要求或 NEBS 认 证 Zone 3 抗震要求。
图170 数据中心机房水电走管示意图
整机柜配电设计和选型：可采用列头柜配电方式和小母线等配电方式。配电方式的选用应考虑业务特性和 机柜容量分配、调度和未来扩容等需求。整机柜配电系统需考虑如下内容。
液冷机柜 manifold、排水水管均为下走管设计 ,机房地板需要预留对应的净空不小于 200mm（不允许布置其 他设施）和开孔位置，否则会影响液冷系统走管。
图171 机柜 Manifold 走管示意图
图172 二次侧管路示意图
底座高低示例：二次环路设计 4000LPM 总流量，需要 DN200 主管+DN50 支管，设计需要 800mm 地板为例：
图173 走水管路位置示意图
图174 机柜加强筋示意图
图177 机柜底座顶板开孔示意图
图178 机柜底座顶板盖板安装示意图
考虑到当前业界部分超节点通常采用风液混合散热模式，需保留辅助风冷能力。整机柜风冷散热：风冷空调末 端可采用远端风墙、近端风墙、列间空调等形式，对应的气流组织方式为数据机房内气流组织方式分为弥漫送 风、地板下送风、列级送风方式。均可满足液冷整机柜的风冷部分散热需求。机柜区域应设置冷热通道隔离措 施，宜设置封闭热通道实现整机柜风冷高效散热。 风冷散热需要考虑机柜演进和风冷散热能力需求。
• 风冷散热方案
超节点集群在数据中心的部署主要涉及三种网络，分别是 Scale Up 网络，负责高带宽域的 AI 算力组网；Scale Out 网络，负责 AI 算力集群大规模扩展组网；通用数据中心网络 Frontend，负责通算业务多租户隔离提供 主机侧管理和控制平面流量，同时为超节点提供高性能存储网络。集群带内/带外管理网络不在此赘述。
表22 超节点集群网络部署说明
| 网络类型 | 别称 | 硬件组网 | 物理互联特征 | 业务形态与流量映射 |
|---|---|---|---|---|
| Type 3: Scale-Up | Local (南向网络) 构建超节点内部的高 带宽域 (HBD) | CLOS组网，无 阻塞通信 | 超节点集群内，视集 群规模，支持电互联， 也支持光电混合 | 张量并行（TP） 专家并行(EP) 流量 |
| Type 2: Scale-Out | Backend (北向网络) 跨HBD域集群分布式 训练加速 | 多级以太交换， 视集群规模，支 持多轨组网 （Multi-rail） | 高性能交换机，光模 块互联 | 流水线并行（PP） 数据并行（DP）及全 局梯度同步 |
| Type 1: Frontend | DCN (数据中心网络) 数据吞吐、管理与存 储访问 | 标准DCN以太网 架构，通过智能 网卡接入 | 通用光电混合互联 | VPC网络支持多租户 隔离，提供主机侧管理 和控制平面流量 Checkpoint读写，提 供高性能存储网络 |
在纵向扩展层面，Scale-Up（Type 3）网络被定义为算力互联网络，其核心业务映射为承载张量并行及专 家并行流量，维持大带宽低时延组网，Scale-Up 网络的扩展范围通常约束在超节点集群内部。
在横向扩展层面，Scale-Out（Type 2）网络（即参数面网络）负责将超节点间组成万卡至更大规模集群。 该网络广泛采用 CLOS 架构，根据实际业务流量，多级交换中支持带宽收敛，也支持多轨组网（Multi-Rail） 设计。在多轨模式下，支持大规模集群组网中同轨流量仅需一级交换，极大减少多级交换引发的 Hash 冲突与 额外时延。硬件层面上，Scale-Out 网络高度依赖高性能大基数交换机，以实现跨 HBD 域互联。在业务映 射方面，负责数据并行和流水线并行流量。
在业务端接入层面，Frontend（Type 1）网络即传统的数据中心网络（DCN），通常搭配智能网卡 (Smart NIC) 以支持安全加密与多租户隔离功能。Frontend 网络在 AI 训练中，主要负责业务面的大容量存储交互，包括 海量训练样本文件的上载任务，以及训练过程中模型参数 Checkpoint 的周期性持久化存储。
|MGMT 域|
|---|
|Frontend 域
|
|---|
Scale Out域
|Storage|
|---|
RDMA NICs
MGMT NIC
DPU
|PCIE SW|
|---|
DPU
PCIE SW
CPU
GPU
|Scale Up域|
|---|
图179 超节点集群组网架构示意图
版本配套关注重点：智算环境的版本配套核心遵循全栈软硬件深度适配、层级组件强绑定原则，需兼顾服务器 硬件、操作系统及内核、算力加速卡的驱动与固件、网络适配卡的驱动与固件、分布式通信类组件、存储系统 及管理平台组件等全链路环节，确保各层级、各类型组件间版本适配，同时匹配智算场景的组网架构与业务运 行要求。
配套发布与测试：由于超节点形态目前尚未形成标准，因此智算相关配套版本由超节点整机厂商完成全链路多 阶段测试验证后正式发布，测试涵盖单机层面的软硬件兼容性、基础功能可用性，集群层面的多节点协同能力、 高负载下的稳定性，以及实际智算业务场景下的训练、推理等核心能力适配性验证，经多轮迭代优化，确认无 兼容性、稳定性问题后，才会发布标准化的配套体系。注意事项：需严格遵循厂商发布的标准化配套清单进行 软硬件搭配，禁止跨版本随意混用，避免因版本不兼容引发功能异常、业务运行故障。
超节点安装部署内容主要包括：
从上面看安装部分过程非常复杂且繁琐，对于超节点由于每个计算Tray均要完成这些工作，过程会更加负责。 因此一般需要有管理控制平台，实现对超节点的软件栈进行统一、自动的安装部署。
随着大模型训练、多模态计算、高性能科学计算等智算场景快速落地，高密度、紧耦合的超节点已成为新一代 智算中心核心算力载体。业界通用定义，超节点是基于专有 Scale-Up 高速互联网络，将多颗 AI 加速芯片集 成的紧耦合算力系统，分为单机柜高密度、跨机柜大规模协同两种形态，支持域内统一内存编址、芯片间 TB 级带宽互联与微秒级时延，可突破传统 Scale-out 集群通信瓶颈，支撑大模型长周期训练与大规模并行计算。 超节点整合计算、高速交换、高密度供电、液冷散热、带外集中管控五大模块，全 Mesh 紧耦合架构与高密 度部署模式，对运维体系提出了区别于传统集群的全新技术要求。
超节点的高密度、高耦合、高敏感特点，核心痛点集中在硬件、技术、业务、运维四大维度，各类痛点相互关 联、层层传导，形成了区别于传统运维的独特挑战。
超节点单柜因高功耗、高集成设计，对硬件可靠性和运维精度要求极高，一是供电压力大，单柜功耗达数十至 上百 kW，电压波动需严格控制在±5%以内，否则易引发芯片离线或训练任务中断，容错率极低。二是液冷 运维严苛，需精准控制温度、流量与压力，一旦漏液或温度超标，可能直接导致硬件损坏，属最高等级故障。 三是故障影响全局，单卡或互联链路故障会迅速扩散，造成整组算力性能下降甚至“雪崩”，对故障预防要求 远超传统集群。
超节点全链路技术栈耦合度极高，任何一环微小偏差都会引发连锁技术问题：一是全栈固件/驱动一致性要求 严苛，BMC、BIOS、加速芯片、交换机固件版本不统一，会直接导致通信异常、性能大幅衰减，甚至无法组 网运行，全集群同类型固件一致性需达到 100%；二是高速互联网络零容错，必须保证低时延、零误码、无拥 塞，普通网络运维手段无法适配专用 Mesh 互联与 IB/RoCE 高速网络的管控需求，误码率需控制在 10⁻¹²以 内；三是异构资源统一调度难，多芯片、多模块协同调度，对运维平台的智能化、自动化能力要求极高，传统 调度工具无法适配全局池化调度需求。
超节点核心承载万亿参数大模型训练、高端科学计算等高端算力业务，业务特性决定了运维特殊需求：一是大 模型训练周期长达数周甚至数月，任务中断重跑成本极高，不仅浪费算力资源，还会延误项目进度，对运维稳 定性要求近乎苛刻；二是算力利用率保障难度大，需兼顾多任务调度、多租户资源隔离，避免资源抢占、任务 冲突导致效率大幅下滑；三是断点续训、异常恢复能力刚需，需配套专项运维机制，保障训练成果不丢失、任 务可快速接续，降低业务损耗。
现有传统 IT 运维体系难以直接适配超节点需求：一是故障定位难，全栈深度耦合导致故障根因复杂隐蔽，传 统逐点排查效率极低，难以快速定位根源，需依托全栈可观测技术实现精准溯源；二是运维复杂度高，需同时 掌握智算硬件、液冷散热、高速网络、AI 平台、大模型基础等多领域专业技能，行业专业人才稀缺；三是自 动化运维刚需，人工运维无法满足秒级故障感知、快速自愈需求，智能化运维能力缺失会直接导致运维效率低 下、故障频发，必须搭建自动化闭环运维体系。
超节点运维，需面向高密度紧耦合算力单元的全生命周期技术保障，聚焦专有 Scale-Up 网络、一体化硬件、 长周期并行业务运维，承担硬件全生命周期管控、链路可靠性保障、故障闭环处置、算力与能效优化，确保超 节点可用性与算力释放效率。
超节点运维核心目标明确为四点：一是构建全维度监测体系，提前预判隐性故障、隔离全域风险，减少非计划 停机；二是建立标准化故障处置流程，实现精准定位、快速自愈、无扰动恢复，保障业务连续；三是严控非必 要变更，最小化运维扰动，适配长周期高稳业务需求；四是完善产品的运维框架，强化全链路遥测、自动化与 智能诊断能力，实现高可靠与高算力利用率兼顾，推动运维从被动抢修向主动预判转型，实现目标量化指标：
超节点作为软硬件深度耦合的一体化算力单元，其运维范围并非单一硬件或软件层面的零散管控，而是遵循“从 物理底座到业务输出”的全链路逻辑，结合主流超节点产品技术架构与国内智算中心实操运维经验，划分为硬 件基础设施层、高速互联网络层、系统与软件栈层、业务与算力服务层四大核心层级。
硬件基础设施运维是超节点算力输出的物理根基，也是全链路运维体系的底层核心支撑，其运维逻辑完全适配 超节点高密度集成、百 kW 级高功耗、芯片级紧耦合的专属特性，彻底摒弃传统服务器硬件运维“单机巡检、 粗放管控、被动抢修”的落后模式，推行全生命周期闭环、全参数精准管控、全隐患前置预防的精细化运维体 系，核心目标是筑牢物理层安全防线，杜绝单点硬件异常引发全局算力雪崩，保障超节点长期满负载稳定运行， 为上层网络、软件、业务运维奠定坚实物理基础。
硬件基础设施的核心运维对象，主要包含硬件算力核心、高密供电、液冷散热等，如下：
图180 硬件基础设施层运维模块架构图
| 模块名称 | 核心组成部件 | 核心监控指标 |
|---|---|---|
| 核心算力硬件模 块 | AI 加速芯片（GPU/NPU）、计算 tray、交 换 tray、正交无背板高密机箱、 200G/400G/800G 专用高速互联光模块、芯 片级直连专用线缆、硬件传感器模组 | 芯片温度、显存温度、实时功耗、功耗 偏差、ECC-UE/CE错误、算力降频 时长、利用率、在线状态、固件版本 光功率、模块温度、偏置电流、链路误 码率、时延抖动、端口利用率 |
| 高密供配电系统 模块 | 高密定制化 PDU、双路 UPS 不间断电源、高 压直流母线、智能精密配电模块、冗余备用电 源、供电电压电流监测单元 | 输出电压波动、模块负载率、双路均衡 度、支路电流、接口温度、冗余切换时 长 |
| 液冷散热与环境 硬件模块 | 冷板 / 浸没液冷散热模块、供液回液闭环管路、<br><br>分布式漏液检测传感器、精密温控单元、循环 泵组、机柜环境温湿度传感器、应急风冷备份 风机、液冷参数实时监测仪表 | 供水温度、供回水温差、流量波动、电 导率、水泵状态、漏液信号、露点温差 |
高速互联网络是超节点全栈架构的核心技术命脉，分为 scale-up 芯片级直连扩容网络（单集群内部）与 scale-out 跨机柜交换网络（跨集群级联）两大板块，其中 scale-up 网络是大模型分布式训练的核心通信底 层，采用 NVLink/Ulink/ 自研 Mesh 专属互联协议，运维优先级、管控精度、容错要求远高于传统网络，其 运维有如下特征：
针对 Scale-up 网络特点，提供如下运维能力
系统与软件栈层是衔接物理硬件底座与上层业务算力输出的核心枢纽桥梁，也是保障超节点全栈软硬件深度协 同、消除算力隐性损耗、规避通信故障的关键管控层级。相较于传统服务器集群零散化、单机化的软件运维模 式，超节点软硬件高度耦合的特性，决定了本层运维必须摒弃单点调试、人工逐台操作的粗放模式，全程围绕 “统一标准、全局一致、批量管控、版本刚性合规”核心逻辑，构建全生命周期闭环运维体系，从根源杜绝因 版本错乱、参数漂移、兼容性失衡引发的算力衰减、多芯片协同失效、训练任务中断等隐性问题，为高速网络 层、硬件层的稳定运行提供软件层面的刚性支撑。
图181 超节点系统与软件栈层运维架构示意图
| 模块名称 | 核心组成部件 | 核心监控指标 |
|---|---|---|
| 全链路固件统 一管理模块 | BMC基板管理固件、BIOS系统固件、高速交换芯 片固件、AI加速卡（GPU/NPU）固件、液冷/供电 模块控制固件 | 版本一致性指标：固件版本一致性 |
| 系统与专用驱 动运维模块 | 算力专属Linux优化系统、AI加速卡专用驱动、 RDMA通信驱动、硬件外设驱动 | 系统稳定性指标：系统 uptime、进 程存活率、漏洞率 版本一致性指标：驱动、系统参数 一致性 |
| 中间件与调度 平台运维模块 | NCCL/HCCL集合通信库、Docker/K8s容器平 台、全局资源调度平台、集中监控运维平台、虚拟 化隔离层 | 软件效率指标：通信库延时、调度 响应时长 |
业务与算力运维是智算超节点运维价值的最终体现，它承接着底层硬件与系统软件栈的稳定状态，直接面向大 模型训练、科学计算等高价值智算业务，构成了“资源就绪 -> 任务交付 -> 价值实现”的关键闭环。
与传统数据中心以设备监控和个体服务器可用性为中心的运维模式不同，超节点运维面临全域算力池化管理、 长周期无中断业务保障、高并发细粒度资源调度等核心挑战。因此，其核心目标演进为：保障复杂业务流的稳 定运行，实现全局算力资源的高效释放与最优利用，最终确保智算投资能够精准、无损耗地转化为业务成果。
为实现上述目标，超节点业务与算力运维依托智能化的运维管理平台，实现从自动化调度、智能预警到闭环处 置的全流程覆盖。其工作范畴主要包括以下几个层面：
为精准评估上述运维职能的有效性，建立以下核心指标体系，用于实时监控、异常告警与趋势分析：
| 运维维度 | 核心指标 | 监测要点 |
|---|---|---|
| 资源健康度 | 算力在线率、算力利用率、算力负载偏差、 冗余算力占比、HBM内存利用率 | 硬件可用状态、关键组件可靠性 |
| 资源效率 | 算力利用率(均/峰值)、负载均衡度、冗余 资源占比 | 资源使用效率、分配合理性、池化效益 |
| 业务效能 | 任务提交成功率、作业完成率、断点续跑 成功率、任务完成时间 | 业务流畅通度、连续性保障能力、性能 达标情况 |
| 调度与协同效能 | 调度决策时长、资源抢占冲突率、跨域故 障定位平均时间(MTTI) | 调度超时、根因定位失败、自愈失败 |
结合超节点高密度、高耦合、高敏感的特性，以及四大层级运维需求，整套运维体系围绕“感知-研判-执行保障-复盘”全流程，搭建四大核心技术支撑体系，四大技术相互联动、形成闭环，是破解超节点运维痛点、 实现高效稳定运维的核心抓手。
全栈可观测技术是超节点运维体系的基础感知核心，区别于传统数据中心零散式监控，针对超节点软硬件深度 耦合、故障传导快、根因隐蔽的特性，打造“全域覆盖、全维度采集、秒级告警、根因溯源”的一体化可观测 平台，打破硬件、网络、系统、业务各层级的数据壁垒，实现从单一部件到全局集群的全方位可视、可管、可 溯，彻底解决传统运维“看不见、查不清、定位慢”的核心痛点。
采用“数据采集层-数据归集层-分析决策层-可视化展示层”四层标准架构，自上而下对接运维管控平台，向 下穿透至物理硬件传感器与芯片级监控接口，实现秒级数据采集、实时分析、多级告警，架构逻辑清晰且适配 各类超节点方案，具体架构如下：
图182 超节点全栈可观测技术架构示意图
结合超节点运维痛点与业界通用规范，将核心监控指标分为四大类，每类指标明确阈值范围，实现可量化、可 考核，彻底告别模糊化运维，具体指标明细如下：
表23 超节点全栈可观测核心指标明细表
| 指标分类 | 核心监控指标 | 行业标准阈值 | 监控意义 |
|---|---|---|---|
| 硬件基础设施指标 | 算力芯片结温、液冷供回 液温差、机柜进风温度、 单柜功耗、供电电压波 动、液冷流量、漏液传感 器状态、硬件ECC报错 数 | 芯片结温≤85℃，液冷温 差≤5℃，电压波动 ≤±5%，漏液零告警 | 保障硬件稳定运行，提前 预警硬件老化、过热、漏 液等高危故障 |
| 高速互联网络指标 | 链路带宽利用率、端到端 时延、链路误码率、丢包 率、拓扑完整性、光模块 功率 | 时延≤百纳秒级，误码率 ≤10⁻¹²，丢包率=0，带 宽利用率合理区间 | 保障高速通信畅通，杜绝 网络瓶颈与链路故障引 发算力雪崩 |
| 系统软件指标 | 固件版本一致性、CPU/ 内存占用率、驱动运行状 态、进程存活状态、日志 异常条数 | 版本一致性100%，内存 占用≤85%，无异常报错 日志 | 保障全栈软件兼容稳定， 避免版本混乱、资源占用 过高引发异常 |
| 业务算力指标 | 算力有效利用率、单卡算 力输出、训练任务进度、 Loss波动值、任务运行 时长、断点保存状态 | 算力利用率≥90%， Loss无异常跳变，任务 无无故中断 | 保障算力高效输出，支撑 大模型长周期训练平稳 运行 |
全栈可观测平台配套三级分级告警机制，按照故障影响范围、严重程度划分为紧急告警（P1）、重要告警（P2）、 一般告警（P3），匹配不同的通知方式与处置时效，避免告警泛滥导致运维人员忽视核心风险：
• P1 紧急告警：涵盖液冷漏液、整机断电、全网链路中断、大面积算力离线等高危场景，通过电话、短信、
大屏声光同步告警，要求 15 分钟内响应，优先处置；
• P2 重要告警：涵盖单卡故障、局部链路误码超标、温度接近阈值、算力利用率骤降等场景，通过短信、
运维平台弹窗告警，30 分钟内响应处置；
• P3 一般告警：涵盖日志异常、非核心部件状态波动、备件余量不足等场景，通过运维平台消息推送，24
小时内处置即可。
同时平台支持告警抑制、告警合并功能，避免单点故障引发批量重复告警，帮助运维人员快速定位根因，提升 处置效率。
自动化与自愈运维技术是超节点全栈运维体系的核心执行引擎，也是承接全栈可观测技术感知结果、实现运维 闭环落地的关键环节，更是破解超节点运维复杂度高、人工依赖度大、故障传导快、操作风险高的核心技术支 撑。超节点集群规模动辄数百至数千张加速卡，软硬件组件数量庞大、耦合度极高，传统人工逐台巡检、单点 调试、手动故障处置的粗放模式，不仅效率低下、耗时耗力，还极易因操作失误引发配置偏差、算力中断、任 务崩溃等次生故障，完全无法适配超节点 7×24 小时高可用、秒级故障响应的刚性运维需求。
整体采用“三层感知+两层决策+一层执行”架构，自上而下对接业务调度层，向下穿透至硬件物理层，实现 全栈数据打通、统一管控，适配各类国产与国际通用超节点方案，架构如下：
图183 超节点智能运维整体技术架构图
行业基线标准、实时运行状态做出精准管控决策；
• 执行层：承接决策层指令，完成硬件上下电、链路切换、配置刷新、任务重启等实操动作，全程闭环无需
人工干预，实现秒级-分钟级快速响应。
摒弃传统人工逐点排查模式，依托自动化编排工具，实现超节点全维度定时+定点+触发式巡检，覆盖日常 运维全场景，是基础运维兜底能力，也是行业通用标配功能：
针对超节点“单点故障影响全局”的特性，业界主流超节点运维平台均内置故障自愈模块，实现故障秒级 感知、分钟级隔离恢复，避免大模型训练任务中断、重跑损耗，核心自愈场景与流程如下：
图184 超节点故障自愈全流程示意图
故障隔离机制 故障隔离的目标是防止故障扩散，将故障组件与正常组件隔离，保障超节点整体功能的可用性：
软件故障隔离：通过容器化技术（Docker、Kubernetes）隔离故障应用，重启故障容器；对于中
间件故障，关闭故障服务实例，启动备用实例； 故障恢复策略
故障恢复策略根据故障类型与严重程度，采用“自动恢复 + 手动恢复”相结合的方式，优先保障核心业务 的连续性：
是否在正常范围、网络连通性是否恢复、应用服务是否正常提供服务。 故障分级
| 故障分级 | 定义 | 在运行任务 |
|---|---|---|
| 硬件不可自愈 | 不在位；硬件功能不可用，如GPU掉卡， 设备掉电；反复重启等状态反复变化 | 任务主动或被动中断。故障件替换后 手工恢复；或重新调度资源，重启任 务 |
| 软件不可自愈 | 软件应用退出、进程终止、任务挂死等 | 任务主动或被动中断。手工恢复任务 或通过管理软件自动恢复任务 |
| 硬件降级 | 硬件功能可用，但是故障造成性能降低，比 如Lane故障 | 任务不主动中断。计划维护，故障件 替换后，手工恢复 |
| 软件可自愈 | 通过软件重试可以恢复的故障，可能是硬件 引起但表现在软件 | 软件可靠性保护，单次故障对任务无 影响或短暂抖动，连续多次故障有时 会带来系统性能降价 |
| 硬件可自愈 | 硬件能够自动恢复的短时( <秒级 )故障，且 可以通过软硬件可靠性设计，进行自愈。如 端口闪断、网络少量丢包等 | 硬件自行恢复，软件可靠性保护，对 任务无影响或短暂抖动 |
依托机器学习、大数据分析技术，基于超节点长期运行的历史指标数据，构建故障预测模型，实现潜在风 险提前预判，是头部智算中心与超节点厂商主推的进阶能力，核心应用场景：
采用数字孪生技术，1:1 还原超节点物理机柜、硬件布局、链路拓扑、液冷管路、供电走向，实现物理世界 与数字世界同步映射，运维人员可通过管控大屏直观查看全节点运行状态，精准定位故障物理位置，替代 传统纯数据监控模式，大幅降低运维操作难度，是当前高端超节点运维的标配可视化能力。
全局一致性管控技术是超节点运维体系的刚性合规中枢，也是破解超节点软硬件深度耦合场景下，版本错乱、 参数漂移、配置差异等核心痛点的关键支撑。超节点内部数千颗算力芯片、上百套网络设备、全栈系统软件与 固件高度绑定，哪怕单个节点的固件版本、驱动参数、网络配置出现微小偏差，都会引发软硬件不兼容、多芯 片通信异常、算力利用率骤降，甚至诱发全集群算力雪崩，这类隐性故障隐蔽性极强、排查难度极大，传统分 散式、人工校验的管控模式完全无法适配。
本技术核心聚焦“全栈统一、基线管控、偏差回溯、全程合规”四大核心目标，搭建覆盖固件、驱动、系统、 配置、参数的全维度一致性管控体系，将所有运维对象纳入统一标准基线，实现从上线预装、日常运行到变更 迭代的全生命周期闭环管控，彻底杜绝各类偏差隐患，保障全集群“万卡如一机、全栈同一规”，和全栈可观 测、自动化自愈技术深度联动，形成“偏差感知-自动校验-批量回溯-合规闭环”的完整管控流程，全程不重 复前文系统软件层的基础运维内容，聚焦专属管控架构、核心机制、落地流程与量化指标。
全局一致性管控覆盖超节点全栈软硬件，针对不同层级管控对象制定专属标准基线，所有基线均参照厂商原厂 规范、信通院行业标准与智算中心实操要求，严禁私自偏离，核心管控范围分为四大模块，每个模块均设定刚 性合规要求：
采用“基线定义层-全域校验层-偏差处置层-合规审计层”四层闭环架构，联动自动化运维平台与全栈可观测 平台，实现一致性管控全流程自动化，无需人工逐节点核查，彻底解放运维人力，具体架构与流程拆解如下：
高可靠灾备与业务连续性技术是超节点运维体系的最后兜底防线，核心应对极端故障、重大灾害、计划外停机 等突发场景，保障核心算力业务不中断、关键数据不丢失、长周期训练成果不损耗，彻底解决超节点业务中断 成本高、恢复难度大的行业痛点。超节点核心承载大模型长周期训练、高端科学计算等关键业务，单次中断可 能造成数天甚至数周的算力与时间损耗，单纯依靠故障自愈无法覆盖极端场景，必须搭建多层级冗余、多维度 备份、快速切换恢复的灾备与连续性保障体系，全程贴合超节点业务特性，区别于传统数据中心基础灾备模式， 聚焦“冗余前置、备份无感、切换快速、业务连续”核心目标。
遵循“多层冗余、分级备份、就近恢复、业务无感”核心逻辑，针对超节点硬件、网络、数据、业务四大维度， 搭建四级冗余保障架构，逐层提升可靠性，杜绝单点故障引发的全局性瘫痪，具体架构拆解如下：
自动断点保存：依托业务运维平台，按照预设周期（通常为每小时或每完成一个训练批次）自动保
存训练断点、进度数据、模型状态，保存过程无感，不占用核心算力资源，不影响训练效率； 故障后无缝接续：无论软硬件故障、断电还是机房切换，故障修复后，平台自动读取最新断点数据，
快速加载模型与进度，无需人工干预，直接接续任务运行，断点续训成功率 100%；
跨节点任务迁移：针对局部硬件损毁无法快速修复的场景，支持将任务断点数据迁移至冗余算力单 元，自动完成环境适配与配置同步，快速重启任务，最大限度压缩业务中断时长。
超节点单柜功耗高达 30-100kW，属于数据中心高功耗核心载体，传统固定功耗、粗放散热的运行模式极易 造成算力空载损耗、能耗冗余、PUE 超标等问题，既增加智算中心运营成本，也不符合绿色智算、低碳数据 中心的行业发展导向。结合高密度算力集群特性、液冷散热专属架构及国家双碳战略要求，超节点能效管理需 构建“全维度监控-智能动态调节-量化评估-闭环优化”的全链路绿色运维体系，打破硬件、散热、供电、业 务调度的能效割裂管控模式，实现算力输出与能耗消耗的精准匹配，在保障算力高可用、高性能的前提下，最 大限度降低综合能耗、优化 PUE 值、提升能源利用效率，打造高效低碳的智算算力运维新模式。本章节从功 耗监控体系、动态智能调节、能效评估优化、绿色节能落地细则四大维度，搭建完整的能效运维技术框架，配 套行业量化指标与实操规范，兼顾技术可行性与落地实用性。
能效管理的前提是精准感知，超节点高密度、高耦合的特性决定了功耗监控必须突破传统机柜级、机房级粗放 监控模式，搭建芯片级-模块级-机柜级-集群级四级联动功耗监控体系，实现全链路功耗数据可采集、可溯源、 可分析，杜绝能耗盲区，为后续动态调节与优化提供数据支撑。
依托四级功耗监控数据，联动硬件特性、业务负载与散热供电系统，推行算力负载联动、散热协同适配、供电 智能优化三大动态调节策略，摒弃固定功耗、满负荷运行的传统模式，实现“算力负载高则功耗拉满、负载低 则功耗下调、空载则深度节能”的精准匹配，杜绝无效能耗浪费，同时保障业务性能无衰减。
依托全栈可观测平台，搭建专属能效监控模块，实现 7×24 小时不间断能耗数据采集与分析，核心监控指标 全部量化，具体指标与阈值如下：
表24 超节点核心能效评估指标表
| 指标名称 | 计算公式 | 行业标准阈值 | 管控意义 |
|---|---|---|---|
| 数据中心能源效率 （PUE） | 总设备能耗/IT设备能耗 | ≤1.1 | 衡量整体散热、供电能效水平 |
| IT设备能源效率（ITUE） | IT设备能耗/总算力输出 | ≤1.05 | 分区管控，消除算力能耗短板 |
| 单位算力功耗 | 总功耗/总算力输出 （PFlops） | ≤25W/PFlops | 提升算力有效利用率，降低单位 能耗 |
| 指标名称 | 计算公式 | 行业标准阈值 | 管控意义 |
|---|---|---|---|
| 空载功耗占比 | 空载能耗/总能耗 | ≤5% | 杜绝长期空载、低负载运行浪费 |
| 功率因数 | 有功功率/视在功率 | ≥0.95 | 减少无功损耗，提升供电能效 |
AD-DC 智算版是专为智算场景打造的专属运维管控平台，针对超节点的运维摒弃通用服务器监控软件的粗放 式架构，深度适配 Scale-Up 全互联架构、高密度液冷供电、大模型长周期业务场景，核心聚焦超节点自动 化部署、全域纳管、Scale-Up 专属网络监控、智能故障根因分析、故障自愈五大核心能力，联动底层 RMC/BMC、专用交换芯片与算力硬件，实现全流程自动化、智能化、无扰动运维，并且通过与上层智算作 业调度平台深度联动，构建“故障感知-根因定位-资源隔离-任务自愈-进度接续”全闭环自愈体系，实现断 训无感知、任务不中断、进度零丢失，彻底解决长周期业务运维兜底难题。
通过对超节点的纳管，实现超节点 Scale-up 网络的拓扑可视化能力。
通过训前巡检能力，可以有效降低训练任务因环境问题引发的故障，提升训练效率。支持普通与深度巡检，针 对超节点支持 Scaleup 网络单独巡检，支持 ScaleUp 叠加 ScaleOut 网络整体巡检。
图187 训前巡检架构
图188 训前巡检指标
训中作业监控和故障分析，包含交换机、服务器、存储集群的端到端的整网全栈数据采集、调优能力及拥塞分 析等能力，保障训练任务的稳定运行。
监控指标：
| 监控模块 | 监控指标 |
|---|---|
| 交换机 | 电源、风扇、温度、CPU、内存等 |
| 网络 | 收发包、错报，pool缓存及水线，headroom缓存及水线，队列收发包、拥塞丢包、缓 存及水线 |
| GPU | 型号、功耗、温度、显存、利用率、ECC、xpulink状态 |
| 服务器 | 系统版本、驱动版本、固件版本、CPU、内存、网卡收发包等指标 |
未来运维的核心将从“工具辅助”转向“AI 主导”。通过构建超节点专用的运维大模型，融合实时数据与历史 知识，实现从异常检测、根因分析、策略生成到执行反馈的完整自治闭环。其高级阶段将体现为：
全链路数字孪生将成为运维智能体的“试验场”和“指挥沙盘”。1:1 高保真模型不仅实现状态同步，更关键的 是支持：
后续行业将出台更细化的超节点运维国家标准、技术规范，统一运维指标、操作流程、SLA 体系，打破厂商 壁垒；同时形成“厂商+智算中心+第三方运维”协同生态，共享运维技术、案例、备件资源，降低行业整体 运维成本，推动超节点运维规模化、规范化发展。
本白皮书系统构建了面向超节点的下一代运维范式。这一范式以“全栈可观测”为数据基石，以“智能闭环” 为核心引擎，以 “全局协同”为关键架构，旨在将复杂耦合的超节点基础设施，转化为稳定、高效、透明的 确定性算力服务。
展望未来，运维体系本身将进化为超节点的 “AI 赋能的价值中枢” 。通过内核智能化、对象数字化与目标价 值化的深度融合，运维不仅是大模型训练与科学计算的无损保障，更将成为优化算力成本、践行绿色责任、驱 动智算业务持续创新的核心支撑力量，护航智算产业迈向高质量发展新阶段。
新华三超节点介绍
1.1 产品简介
H3C UniPoD S80000 液冷机柜（以下简称 S80000 或液冷整机柜）是 H3C 针对通信开销大的 AI 场景打 造的 AI 整机柜，具有高密度、整机柜交付、液冷散热等特点，并深度集成了覆盖 AI 业务全生命周期的超节点 软件栈，是万亿级 MoE 模型训练与推理、以及下一代智能体（Agent）应用的理想基础设施。
S80000 通过硬件层面的柜内卡间全互联与高速网络拓展，构建了极致性能的算力基座；同时，其内置的智 能软件栈实现了对海量异构算力的统一抽象、智能调度与高效运维。这种软硬协同设计，旨在系统性解决大规 模智算中心在资源管理、性能调优与运维保障方面的核心挑战，为用户提供一站式、高性能、高可用的 AI 算 力服务。
液冷系统分别有 32 卡、64 卡和 256 卡，外观分别见以下图示。
新华三 S80000 AI 超节点采用整机柜设计，单柜可部署 32 张或 64 张高性能 AI 加速卡，并支持柜内卡间全 互联通信，卡间通信带宽相比传统 8 卡 OAM 服务器提升高达 4 倍。在此基础上，节点支持拓展至 256 卡全 互联，构建大规模算力集群。单柜形成的算力系统计算效率远超传统形态 8 卡服务器。针对 MoE 模型，单卡 推理性能可提升 100%以上，每 token 成本降低至少 50%。同时，系统支持基于负载感知的 PD 实例数动态 调度，进一步将推理效率提升 40%以上。
采用 Cable tray 互联方式，可靠性较传统方案提高 10 倍，硬件层面通过关键器件级冗余设计与生产期极限 压测，大幅增强设备韧性；软件层面支持 PD 实例的自动切换，全面提升系统级 RAS 能力，确保业务连续性 与稳定性。
支持水、电、网三总线盲插设计，极大简化现场部署与维护流程。整柜提供算、存、scale up/out 双网的统 一运维界面，实现资源部署、状态监控与故障处理的集中化管理。系统具备故障自动感知、隔离及恢复能力， 结合工厂预集成与整柜运输交付模式，显著降低部署周期与运维复杂度。
采用先进液冷散热方案，冷板覆盖 CPU、GPU 等核心热源，在保障极致算力密度的同时实现高效、静音的 热管理。
S80000 液冷整机柜（64 卡和 256 卡）产品规格和技术参数。
产品规格的计算，以产品支持的所有部件为基准。
| 功能特性 | 说明 |
|---|---|
| 机柜空间分布 （46SU） | 可用空间46SU： 1SU∼2SU用于安装假面板 3SU∼4SU、39SU∼40SU用于安装Power Shelf，其中安装电源模块及RMC模 6SU~7SU、10SU~13SU、16SU~17SU、26SU~27SU、30SU~33SU、 36SU~37SU用于安装计算节点 8SU~9SU、14SU~15SU、28SU~29SU、34SU~35SU用于安装交换节点 41SU~46SU用于安装TOR交换机（3SU）和理线架（3SU） 18SU~19SU、24SU~25SU用于2U毛刷+理线架 |
| 机柜单元 | 机柜宽600mmx深1200mmx高2300mm(可用槽位46SU) 冷板液冷为主，风冷辅助，支持漏液检测 Busbar集中供电方案，最大支持120kw供电能力 最大支持16个计算节点、8个交换节点 |
| 计算节点 | 最多可支持16台S8400 G7计算节点（具体规格请参见S8400 G7技术白皮书） |
| 交换节点 | 最多可支持8个交换节点 |
| CDU | 支持风液式CDU |
| 冷却液 | 去离子水、PG25丙二醇水溶液、EG25乙二醇水溶液 |
| 冷板 | CPU冷板采用钎焊工艺，密封可靠性高 |
| Manifold | Manifold设计顶部具备自动排气阀，泄漏液体可通过软管导入排液管、喷溅盒 节点鹰嘴泄漏液体，通过排液槽一同汇入机柜底部积液盘 |
| 快接头 | 快接头为计算节点中液冷模块与分水管（Manifold）的连接头。S8400 G7计算节点选 用的快接头，型号为UQDB06，其他型号快接头可根据需求适配 |
| 漏液检测 | 冷板模组集成漏液检测绳，通过服务器HDM管理漏液信号 Manifold连接漏液检测绳 |
| 管路设计 | 软管方案，方便布局 |
| 高冗余 | 单个Power Shelf的PSU支持11+1冗余 |
| 供电功能 | Busbar集中供电方案，最大支持120kW供电能力： 计算节点采用Busbar供电 每计算节点单槽位支持不低于8kW，每交换节点槽位支持不低于3kW 支持机柜内管理交换机AC 220V输入 |
| 管理功能 | 机柜级RMC管理模块，实现对整机和电源的状态监控、日志记录和故障报警，节点的 资产管理等功能 |
| 一体化交付 | 支持整柜运输，一体化交付，即插即用 |
表26 环境参数
| 类别 | 项目 | 说明 |
|---|---|---|
| 物理参数 | 尺寸（高x宽x深） | 2300mm*600mm*1200mm（含脚轮） |
| 重量 | • 空机柜重量：350kg<br>• 64 卡满配最大重量 1400kg（含包材 150kg）<br> | |
| 环境参数<br><br> | 温度<br><br> | 工作环境温度：5°C∼40°C |
| 贮存环境温度：-40°C∼70°C | ||
| 湿度 | • 工作环境湿度：8%∼90%（无冷凝）<br>• 贮存环境湿度：5%∼95%（无冷凝）<br> | |
| 海拔高度 | • 工作环境高度：-60 m∼3000m（海拔高于 1500m 时，每升高 100m，规格最高温度降低 0.33°C）<br>• 贮存环境高度：-60 m∼3000m<br> | |
| 运输坡度 | ≤10 度，建议 6 度 |
表27 液冷系统散热规格表
| 节点名称 | 整柜进液温度℃ | 整柜流量 L/min | 机柜工作压力 Bar<br><br> | 整柜压差 Kpa<br><br> |
|---|---|---|---|---|
| S8400 G7<br><br> | 5~40 | • CPU+GPU 液冷：<br>• 64 卡，16 计算节点，整柜总流量≥96<br> | ≤3.0 （推荐≤2.5） | ≥60 |
| • CPU+GPU+DIMM 液冷：<br>• 64 卡，16 计算节点，整柜总流量≥112<br> |
S80000 超节点软件栈是一个面向 AI 业务全生命周期的综合性管理平台，旨在实现对大规模智算资源的统一 纳管、智能调度与高效运维。该软件栈以“高易用、高可靠、高性能”为核心设计理念，通过深度软硬件协同 优化，为模型训练、微调及推理等核心场景提供从底层基础设施到上层业务应用的全栈支持。
超节点软件栈采用层次化、平台化的设计思想，整体架构自下而上可分为基础资源层、加速计算与通信层、框 架与平台层以及智能管控与运维层，如图所示。各层之间通过标准接口协同工作，共同构成一个完整、自治的 智算操作系统。
图192 分层架构
作为软件栈的基石，本层负责对物理硬件进行抽象与管理，确保计算资源的稳定供给与高效利用。
本层聚焦于释放硬件算力潜能，为大规模分布式 AI 任务提供核心的计算、通信与数据访问能力。
图193 通信平台
本层承接具体 AI 业务，提供模型开发、训练与推理所需的框架支持和平台服务。
• 训练与微调框架支持：全面兼容主流并行训练框架，如 Megatron、DeepSpeed 及 PyTorch 等，支撑
大规模模型的高效训练。
对计算、存储、网络资源的整合管理与调度。
该层实现对整个超节点集群乃至多个超节点的全域统管，保障系统的高可靠与高可用。
− 拓扑感知调度：感知硬件拓扑，实现负载亲和性调度，最小化跨节点通信延迟，显著提升大模型
训练效率。 − 训推一体调度：支持训练、推理、在线、离线任务的混合部署与分时复用，全面提升资源利用率。 − 故障感知调度：实现故障自动发现、业务重调度与恢复，防止故障扩散，保障业务连续性。 − 逻辑超节点调度：支持弹性切分超节点资源，灵活适配小模型推理与碎片化任务，提升资源利用
精度。
图194 业务平台
图195 管控平台
通过全栈、分层、协同的软件创新，构建了面向 Agentic 时代的智算操作系统。其核心特点可归纳为以下三 个维度：
超节点作为 ScaleUp 纵向扩展的系统，目前其标准和生态格局存在多样化发展的情况。英伟达目前已经构建 完整且封闭的生态系统，其产品在市场上被广泛接受。而其他厂商也在建立自有或开放联合的生态系统。在每 个生态系统中，我们都能看到三个关键要素，即算力、联接、软件栈。
• 算力：以 GPU/AI 加速芯片为代表的算力，是超节点被市场接受的直接要素，因此拥有最新最强的算力芯
片，并持续快速迭代，是当前驱动超节点生态成长的动力；
在英伟达的产品技术生态中，尤其是在超节点的范畴中，GPU、CUDA 和 NVLink 是英伟达三个关键技术。 从 2006 年至今，英伟达已经发布了几十款 GPU（见下表），其 GPU 已经占据了领先的市场份额，积累了最 大规模的用户生态。
截至 2026 年 2 月，英伟达 Blackwell Ultra 架构的 B300 是当前全球单芯片算力最高的 GPU，其 15 PetaFLOPS FP4 算力、288GB HBM3e 显存，以及在 AI 性能基准测试 MLPerf v5.1 中的全面领先，均获 得权威实证支持。
| 英伟达 GPU 架构<br><br> | 发布时间 | 产品型号清单 | NVLink 对应关系 |
|---|---|---|---|
| Tesla | 2006年 | C870, C1060, C1080, M1060 | - |
| Fermi | 2010年 | C2050, C2070, C2075, C2090, M2050, M2070, M2070Q, M2075, M2090, X2070, X2090 | - |
| Kepler | 2012年 | K8, K10, K20c, K20m, K20s, K20X, K20Xm, K40c, K40d, K40m, K40s, K40st, K40t, K80 | - |
| Maxwell | 2014年 | M4, M10, M40, M60 | - |
| Pascal | 2016年 | P4, P10, P40, P100, P100 DGXS | NVLink 1.0 |
| Volta | 2017年 | PG500-216, PG503-216, V100, V100 DGXS, V100 FHHL, V100S | NVLink 2.0 |
| Turing | 2018年 | T10, T4, T4G, T40 | |
| Ampere | 2020年 | A2, A10, A10G, A10M, A16, A30, A30X, A40, A100, A100X, A800, AX800, PG506-207, PG506-217, PG506-232, PG506-242 | NVLink 3.0 |
| Ada | 2022年 | L2, L4, L20, L40, L40G, L40S, L40 CNX | |
| Hopper | 2022年 | H20, H100, H100 CNX, H100 NVL, H200, H200 NVL, H800 | NVLink 4.0 |
| Blackwell | 2024年 | B100, B200, RTX PRO 6000 Server | NVLink 5.0<br><br> |
| Blackwell Ultra | 2025年 | B300 |
CUDA，即计算统一设备架构（Compute Unified Device Architecture），是英伟达在 2006 年推出的一种 并行计算平台和编程模型。CUDA 是 NVIDIA 的加速计算平台，为应用程序提供利用英伟达 GPU 算力的软 件层。开发者可以使用 C++、Python、Fortran 等语言编程，或借助如 PyTorch 等 GPU 加速库和框架， 将 GPU 计算灵活集成到软件栈的各个层面，以获得更佳的功能与性能表现。
CUDA 使得开发者能够利用 GPU 的强大计算能力，来加速各种科学计算、工程模拟、数据分析等任务。在 传统的计算模式中，CPU 是处理复杂逻辑和顺序任务的主力，而 GPU 则擅长处理大规模的并行计算任务。 CUDA 的出现，极大地简化了在 GPU 上进行编程的复杂性，使得开发者能够更加高效地利用 GPU 资源， 实现计算性能的飞跃。
CUDA 在软件方面由一个 CUDA 库、一个应用程序编程接口（API）及其运行库（Runtime）、两个较高级 别的通用数学库，即 CUFFT 和 CUBLAS 组成。CUDA TOOLKIT 包括编译和 C++核，CUDA DRIVER 驱 动 GPU 负责内存和图像管理。CUDA-X LIBRARIES 主要提供了机器学习（Meachine Learning）、深度 学习（Deep Learning）和高性能（High Performance Computing）计算方面的加速库，APPS & FRAMEWORKS 主要对接 Tensorflow 和 Pytorch 等框架。
CUDA 提供了几个较为成熟的高效函数库，可以直接调用这些库函数进行计算，常见的包括：
截至 2025 年的各类公开统计信息，在 AI 计算场景中，CUDA 生态覆盖了 80%~90%的市场份额，处于市 场的绝对领先地位。从 AI 训练和 AI 推理这两类主要的细分场景来看，在 AI 训练场景中超过 85%的模型训练 任务依赖于 CUDA 底座，以目前最流行的 AI 训练框架 PyTorch 为例，其默认的计算平台就是 CUDA，并 且其版本的演进与 CUDA 的有密切关系。
在另一个主流的 AI 训练框架为 TensorFlow，其计算层也以 CUDA 提供的 cuBLAS、cuRAND、cuDNN 为默认的数值计算层组件。
在目前全球的 AI 训练场景中，PyTorch 和 Tensorflow 合计已经超过 7 成的市场占比，紧随其后的是百度 的 PaddlePaddle，也同样将 CUDA 作为首选的计算层，仅华为的 MindSpore 出于商业的考虑，从 2025 年中期发布的 MindSpore 2.6.0 版本开始，才取消了对 CUDA 的支持。
在推理场景，虽然推理引擎体现出多元化发展的趋势，但除了桌面和移动端等有限的场景，多数推理引擎将 CUDA 作为默认的选项。
| 推理引擎 | CUDA 依赖性 | 适用硬件 | 部署难度 | 典型应用场景 |
|---|---|---|---|---|
| vLLM | 强依赖 | NVIDIA GPU | 中高 | 高并发API服务、企业级大模型 部署、RAG系统 |
| TensorRT-LLM | 强依赖 | NVIDIA GPU | 高 | 低延迟生产环境、金融/医疗实时 推理、边缘AI加速 |
| Hugging Face TGI | 强依赖 | NVIDIA GPU | 中 | OpenAI兼容接口服务、多轮对 话机器人、云原生部署 |
| SGLang | 强依赖 | NVIDIA GPU | 中 | Agent系统、工具调用密集型任 务、结构化生成 |
| LMDeploy / TurboMind | 可选 | NVIDIA GPU / 昇腾 NPU | 中 | 混合异构部署、私有云环境 |
| llama.cpp | 非必需 | CPU / NVIDIA GPU（可选） | 低 | 本地开发、笔记本推理、树莓派 等边缘设备 |
| MNN | 否 | ARM CPU / 骁龙/NPU | 极低 | 移动端App、嵌入式设备、手机 本地大模型运行 |
根据主流媒体的报导，截至 2025 年底，CUDA 生态目前已经拥有超过 450 万注册开发者的生态系统，值得 关 注 的 是 ， 上 述 数 据 仅 统 计 了 英 伟 达 官 网 的 注 册 开 发 者 数 量 ， 而 如 果 将 非 注 册 用 户 以 及 通 过 PyTorch/TensorFlow 调用 CUDA 的用户数量统计进来，则开发者的规模极可能提升一个数量级。
2025 年底，在 CUDA 的最新版本 CUDA 13.1 中，多个新特性与能力直接针对英伟达超节点（Super Pod） 架构进行了优化和适配，以充分发挥超节点中大规模 GPU 集群的并行计算潜力。这些特性不仅提升了编程效 率，也优化了资源调度与性能分析，确保在超节点环境下实现高性能、高效率的计算。
CUDA Tile 是 CUDA 13.1 的核心创新，其设计初衷之一就是简化大规模并行计算的编程复杂度，特别适 用于超节点中成百上千个 GPU 协同工作的场景。
超节点通常包含大量 GPU 资源，如何在多任务并发中合理分配资源是关键挑战。CUDA 13.1 引入的 Green Contexts 为这一问题提供了有效解决方案。
在超节点中，多个 GPU 协同工作时，内存访问模式的优化至关重要。CUDA 13.1 引入的 MLOPart 技术， 专为 Blackwell 架构优化，旨在提升内存访问效率。
为了帮助开发者在超节点环境中优化性能，CUDA 13.1 配套的 Nsight Compute 2025.4 工具也进行了 增强，支持对 CUDA Tile 内核的深度分析。
在超节点中，大规模模型训练和推理对计算结果的确定性要求极高。CUDA 13.1 的数学库（如 cuBLAS） 也针对此进行了优化。
2025 年 5 月 19 日，英伟达正式发布了 NVLink Fusion，这是英伟达针对其专有的 NVLink 技术的重大转变。 在过去的英伟达算力集群中，只能使用英伟达的芯片，但现在英伟达出让了一部分权限，将 NVLink 开放给 行业，客户可以把其他品牌的芯片也加入到算力集群里。需要关注的是，NVLink Fusion 仅开放了计算部分， 即 CPU 和加速芯片，而网络部分仍然是采用英伟达的全家桶方案。
NVLink Fusion 目前在 CPU 方面已经有 ARM、Intel、富士通、高通、SiFive 加入其中。CPU 的技术路线 覆盖了主流的 x86、ARM 和 RISC-V，但目前的 CPU 型号还相对有限。
| 厂商 | CPU 型号 | 架构路线 |
|---|---|---|
| ARM | 定制版Arm Neoverse处理器 | ARM |
| Intel | 定制版至强Xeon处理器 | X86 |
| Fujitsu | FUJITSU-MONAKA | ARM |
| Qualcomm | Oryon架构的定制CPU | ARM |
| SiFive | 待发布 | RISC-V |
至于 NVLink Fusion 所支持的 GPU/加速芯片，则包括了 Marvell、联发科、三星等厂商，对应的 GPU 芯 片的市场份额相对偏小。
从上述生态支持的情况看，英伟达的 NVLink Fusion 目前仍处于起步阶段，CPU、GPU 或加速芯片的选项 相对有限，目前市场上也尚未发布此类的超节点系统或集群方案，因此其生态的整体影响力目前还有待市场观 察。
AMD 是英伟达 GPU 领域的长期竞争对手，AMD 在 2017 和 2018 年曾经两次推出 Instinct MI 系列数据中心 GPU，但当时的几款型号 MI6、MI8、MI25 在性能上距离同期的 NVIDIA GPU 差距较大，这三款 GPU 的 FP64 算力均未超过 1TFLOPS，直到 AMD 在 2023 年发布了 MI300 系列才有所改变。
| 架构 | 发布时间 | AMD 产品型号清单 | 英伟达对标型号 |
|---|---|---|---|
| GCN3/GCN4 | 2014年 | MI6, MI8 | - |
| GCN5.0/ GCN5.1 | 2017年 | MI25, MI50 | - |
| CDNA | 2020年 | MI100 | - |
| CDNA 2 | 2021年 | MI210, MI250, MI250X | - |
| CDNA 3 | 2023年 | MI300A, MI300X, MI325X | H100/H200 |
| CDNA 4 | 2025年 | MI350, MI355X | B200 |
| CDNA 5 | 2026年待发布 | MI400, MI430X, MI440X | B200/B300 |
在 GPU 的 ScaleUp 互联技术上，Infinity Fabric（IF）是 AMD 提出并长期演进的一体化高速互连架构，用 于连接 CPU、GPU 以及 SoC 内部的多个计算与功能模块。
与 NVLink、UB、ICI 等主要面向系统级或超节点级 Scale Up 场景的互连技术不同，Infinity Fabric 最初的设 计目标并非专注于超大规模加速器互联，而是作为贯穿芯片内部、封装级以及节点内系统的统一互连骨干，支 撑 AMD 多核、多 Die 与异构计算架构的发展。在 AI 与高性能计算系统中，Infinity Fabric 被用于连接 AMD EPYC CPU、Instinct GPU 以及相关 I/O 与内存控制模块，为节点内多加速器协同提供较高带宽和一致的通 信语义。
从生态角度需要关注的是，Infinity Fabric 起初是作为 AMD 专有的互联协议，为了挑战英伟达的生态主导地 位，AMD 将 Infinity Fabric 技术部分贡献给了 UALink 联盟。
为了构建 AMD 自有的算力生态，AMD 也推出并开源了 ROCm（Radeon Open Compute），作为其对标 CUDA 的软件平台和方案。ROCm 在 2016 年发布，目前已经演进到 ROCm7 版本。
AMD ROCm 作为追赶者，具有与 CUDA 类似的定位和功能，也提供了一系列的计算库，为开发者提供统 一、抽象化的编程接口。
AMD ROCm 与 AI 训练框架的生态适配情况相比英伟达 CUDA 存在一定的差距。其中的主要差异是 PyTorch和TensorFlow目前仅支持Linux版本的ROCm，相比而言CUDA支持可支持Linux和Windows 系统。这个差异主要影响个人用户，而企业环境因为主要使用 Linux 因而不受影响。
至于推理引擎的支持情况，ROCm 所支持的推理引擎也相对偏少。
| 推理引擎 | 是否支持 ROCm |
|---|---|
| vLLM | 否 |
| TensorRT-LLM | 否 |
| Hugging Face TGI | 否 |
| SGLang | 否 |
| LMDeploy / TurboMind | 否 |
| llama.cpp | 支持 |
| MNN | 否 |
| Megatron-LM | 支持 |
| VERL | 支持 |
截至 2025 年，AMD 作为全球第二大 GPU 厂商，其 ROCm 生态相对英伟达的 CUDA 生态仍有较大的差 距，用户规模数量尚无确切的统计数量，根据公开信息显示，其 GPU 主要集中在微软等少量云巨头客户，而 缺少中小客户和个人客户，因为后者对于生态成熟度的依赖性远高于云巨头。
Intel 作为 GPU 市场的另一个主要追赶者，其对标英伟达的产品线为 Gaudi 系列 AI 加速芯片，它是由英特尔 2019 年收购的以色列 AI 初创公司 Habana Labs 设计的，采用 ASIC 架构，有别于 Intel 原有的通用 GPU 产品。目前英特尔最新一代的 AI 加速器是 Gaudi 3 ，该产品已于 2024 年发布，但截至 2026 年初，Intel 仍 无 Gaudi 4 的发布计划。
| Intel Gaudi 型号 | 发布时间 | 英伟达对标型号 |
|---|---|---|
| Gaudi | 2019年 | T4 |
| Gaudi 2 | 2022年 | A100 |
| Gaudi 3 | 2024年 | H100/H200 |
Intel Gaudi 芯片之间主要通过 基于以太网的 RDMA（Remote Direct Memory Access）技术 实现互联， 具体采用 RoCE（RDMA over Converged Ethernet）协议，这是英特尔在 AI 加速器互连架构中的核心设 计选择。
与 NVIDIA NVLink 或 AMD Infinity Fabric 等专有高速互连不同，Gaudi 系列（包括 Gaudi 3）坚持使用 标 准以太网基础设施 进行芯片间通信，具备良好的开放性和可扩展性。以下是其互联机制的关键特点：
为了打造 Intel 的算力生态，Intel 也在 2019 年发布了 oneAPI 平台，同样对标英伟达的 CUDA。为了体现出 Intel 的差异化优势，Intel 将 oneAPI 打造成了一个横跨 CPU、GPU、ASIC 和 FPGA 等其他专用加速硬件 的平台。
oneAPI 的核心理念是“一次编写，到处运行”。它提供了一套统一的编程接口和工具，使开发人员能够为 CPU、 GPU、FPGA 等不同类型的处理器编写单一代码库，而不需要为每种架构单独维护代码。 因此 oneAPI 不仅 是一套工具或平台，更是一项基于开放规范的行业计划。
但由于 Intel 在 GPU 算力市场的弱势地位，oneAPI 的理念虽好，但仍需要时间的考验，目前在市场的生态 规模仍相当有限。
UALink（Ultra Accelerator Link）包含了 AMD、Astera Labs、AWS、思科、谷歌、HPE、英特尔、 Meta、微软、字节、腾讯、中兴、新华三、ARM 等行业主要厂商的技术联盟。
UALink 核心战略是“通过利用现有的以太网基础设施，包括线缆、连接器、中继器和管理软件，来降低总体 拥有成本（TCO）”。目的是通过开放的生态，对抗英伟达的专有生态。
| 对比维度 | NVIDIA“专有生态” | UALink“开放联盟” |
|---|---|---|
| 核心哲学/模式 | 垂直整合的专有模式 | 专为AI优化的开放标准内存网络 |
| 优势 | 通过控制每一个环节，实现了无与伦比 的性能和优化。 | 生态协作带来的选择多样性和价格竞争力。 |
| 劣势/挑战 | 高昂的成本、深度的厂商锁定和单一的 创新来源。 | 管理一个多厂商联盟所固有的复杂性和潜在 的决策滞后。 |
2025 年，UALink 发布了 1.0 版本的规范，可连接 1024 个 GPU、单通道 200GT/s 带宽，四通道配置下可 达 800GT/s。UALink 的目标规格相对于英伟达的 NVLink Fusion 在有明显的优势。
虽然 UALink 的规划目标非常具有吸引力，但目前还没有采用 UALink 的整机系统上市，至少要等到 2026 年下半年甚至 2027 年，因此 UALink 在算力市场快速变化的背景下，需要跨过生态初期的重重困难。
2025 OCP（开放计算项目）全球峰会上，OCP 正式宣布全新网络项目工作组 —— ESUN（Ethernet for Scale-Up Networking，以太网纵向扩展网络）。ESUN 为 OCP 框架下的开放式技术协作平台，目标为： “利用标准以太网（Ethernet）的生态与成本优势，构建可扩展、低延迟、高带宽的 AI 加速器互联架构。”
ESUN 的成员包括 AMD、Arista、博通、思科、HPE、英特尔、Meta、微软、英伟达（NVIDIA）、OpenAI、 Oracle等，与UALink联盟相比最大的差异，在于英伟达也参与了ESUN联盟，并且增加了博通Broadcom， 因此相对于 UALink 的“反英伟达”特点，ESUN 体现出了更为广泛包容性。
UALink 与 ESUN 虽然都是为了改变英伟达一家独大的市场局面，但在彼此的生态发展过程中，UALink 和 ESUN 成为彼此最直接的竞争对手，也就是说两者决出的胜者，才有可能撼动英伟达的市场地位。
| 对比维度 | UALink | ESUN |
|---|---|---|
| 战略定位 | 合纵联盟，开放标准 | 统一以太网江湖 |
| 主要目标 | 打破NVLink锁定 | 统一Scale-up/out网络 |
| 主要推动者 | 汇集了NVIDIA主要竞争对手和客户（AMD、谷 歌、英特尔、微软、Meta等）；OCP 2025更新： 博通已退出董事会。 | 包括了几乎所有关键参与者：AMD、 Arista、ARM、博通、思科、HPE、 Marvell、Meta、微软、NVIDIA、OpenAI 和Oracle 。 |
| 对比维度 | UALink | ESUN |
|---|---|---|
| 架构哲学 | 基于标准PHY的全新协议： 在标准的以太网物理 层之上，设计一个全新的、为特定目的构建的协 议栈（DL/TL） | 模块化与标准化分工： ESUN（网络 交换结构）和SUE-T（端点传输协议） 双线并战 |
| OCP 2025关键 举措 | / | ESUN工作组正式成立 |
OISA（Omni-directional Intelligent Sensing Express Architecture，全向智感互联）是中国移动提出的 GPU 卡间互联协议体系，旨在提供 GPU 卡间高速互联标准，包括大规模 GPU 对等互联、极致报文格式、 数据层流控和重传以及高效物理传输等解决方案。
目前 OISA 联盟已经包含了 GPU 芯片、Switch 芯片、整机厂商等几十个成员单位，相关的产品和系统也有 做部分早期发布，但距离市场的实际场景落地仍待观察。
华为以昇腾芯片为基础，采取了与英伟达竞争的生态策略，在硬件、软件栈和系统级（含超节点）均进行了较 为深入的生态建设。
华为生态的基础是其昇腾系列 AI 芯片。在数据中心领域，华为与英伟达对标的产品线为昇腾 910 系列芯片， 目前已经发布到 910C 产品。
| 华为昇腾型号 | 发布时间 | 英伟达典型对标型号 |
|---|---|---|
| 910 | 2019年 | - |
| 910B | 2023年 | A100 |
| 910C | 2025年 | H100 |
由于多种客观原因导致，华为昇腾芯片的发布时间，基本上相对其对标的英伟达要晚上几年，因此华为需要在 生态建设上要做更多的投入，包括通过华为云、生态伙伴网络等多种模式和渠道。
华为作为国内主流的云计算厂商，具备公有云和私有云的方案，可以快速、规模化的进行昇腾芯片和配套 软件的推广。
截止 2025 年底，使用华为云昇腾 AI 云服务的全球客户增长到上千家，涉及昇腾芯片之上的大规模算力 集群、计算引擎 CANN、AI 开发框架 MindSpore、ModelArts AI 平台等多样化的云服务。
除了云计算，昇腾在应用软件、基础模型、基础软件、生态运营方面，也在构建其生态网络。根据华为的 官方信息，截至 2025 年底，昇腾已经培养较大规模的开发者和合作伙伴群体，推出了多个开源项目、硬 件产品和行业解决方案。
华为的 AI 软件栈包含了 CANN、MindSpore、AI 平台（ModelArts 系列产品）三类主要的组成部分，共同 构建了从底层的计算加速、AI 框架到平台使能的多层次软件栈。
CANN 是华为针对 AI 场景推出的异构计算架构，对上支持多种 AI 框架，对下服务 AI 处理器与编程，发 挥承上启下的关键作用，是提升昇腾 AI 处理器计算效率的关键平台。在华为的软件栈中，CANN 的定位 与英伟达软件栈的 CUDA 类似，是最基础的计算层软件。
作为计算层的基础软件，CANN 与 PyTorch 等 AI 框架的适配是首要的生态工作。截至 2026 年 1 月， CANN 与 PyTorch 的 2.90 版本完成了正式的适配。
| CANN 版本 | PyTorch 版本 |
|---|---|
| 商用版：8.5.0 社区版：8.5.0 | 2.6.0 |
| 商用版：8.5.0 社区版：8.5.0 | 2.7.1 |
| 商用版：8.5.0 社区版：8.5.0 | 2.8.0 |
| CANN 版本 | PyTorch 版本 |
|---|---|
| 商用版：8.5.0 社区版：8.5.0 | 2.9.0 |
值得关注的是，PyTorch 2.9.0 的正式发布时间为 2025 年 10 月，而 CANN 的在 2026 年 1 月就发布了 正式的适配版本，仅耗费约一个季度的时间就完成了快速适配，这对于生态而言是十分重要的能力。
同时我们也应当看到，在 PyTorch 的官方配套中，仍只有英伟达的 CUDA 和 AMD 的 ROCm，这意味 着 CANN 对 PyTorch 的适配工作主要由华为完成，从生态的长期发展而言尚未进入良性循环。
MindSpore（昇思）是华为公司于 2019 年发布并于 2020 年开源的 AI 框架，与 PyTorch、TensorFlow 对标。
根据行业研究机构 Omdia（Informa tech 集团旗下国际信息与通信技术研究机构）发布了《中国人工智 能框架市场调研报告》（2023 年），华为昇思 MindSpore 与 PyTorch、TensorFlow、PaddlePaddle 等人工智能框架在知名度与使用率市场份额上处于第一梯队。
而根据华为官方信息，截至 2025 年底，MindSpore 的社区用户已经达到 350 万+，已经具备了一定的 生态基础。
MindSpore 所支持的硬件平台和计算层，除了华为自己的昇腾 CANN 之外，还支持英伟达 CUDA，即 MindSpore 具备独立发展生态的技术条件。
| 硬件平台和计算加速 | 操作系统 | MindSpore 支持状态 |
|---|---|---|
| Ascend CANN | Linux-x86 | ✔ |
| Linux-aarch64 | ✔ | |
| Nvidia CUDA | Linux-x86 | ✔ |
根据面向的用户群体差异，华为在云上和云下提供了不同的 AI 平台方案。其中 ModelArts 平台是华为云 提供的面向开发者的一站式人工智能 AI 开发平台，以云服务的方式在公有云和私有云中提供，具有快捷易 用的特点，是华为云上 AI 业务的重要入口。
而在云下，华为提供了一套更偏向于基础的开发套件和工具，包含集群的管理、端边协同、训练加速、推 理引擎等部分，面向更为弹性变化的使用场景。
华为于 2019 年开始研究灵衢（UnifiedBus），随后发布灵衢 1.0 商用 验证，于 2025 年 9 月发布并开放灵衢 2.0 技术规范。
UB 协议栈由物理层、数据链 路层、网络层、传输层、事务层、功能层以及 UMMU、UBFM（UB Fabric Manager） 组成，对于内存交互，UB 支持 UBPU 中的计算单元直接发起同步和异步访存指令，减少控制命令交互，实 现百 ns~us 级低时延；对于集群大规模组网，UB 除了支持采 用多级 UB Switch 扩展组网之外，还支持通过 UBoE 与以太 Switch 对接，实现融合 组网，以及通过 OCS 组网，实现可变拓扑，助力集群规模扩张。
UB 协议已经完成 2.0 标准的设计，并通过开放标准和建设灵衢社区，硬件开放、软件开源，支持伙伴打造面 向行业的超节点场景化解决方案，加速开发者高效自主创新，共建繁荣生态。
| 灵衢®基础规范 | 定义灵衢基础规范2.0版本，包括灵衢系统组成、协议、以及编程模型等。本文 档帮助读者理解符合灵衢基础规范的设备和系统的交互行为、互操作要求、编程 模型、资源管理等 |
|---|---|
| 灵衢®固件规范 | 配套灵衢协议，定义灵衢设备固件的架构设计、交互逻辑、功能及接口，确保固 件在全生命周期内满足可靠性、安全性和兼容性要求灵衢固件规范 |
| 灵衢®使能操作系统参 考设计 | 介绍操作系统灵衢组件（UB OS Component）的架构、功能及外部接口，方便 应用开发者、驱动开发者以及OS开发者等了解操作系统灵衢组件和基于操作系 统灵衢组件进行开发 |
| 灵衢®系统高阶服务软 件架构参考设计 | 介绍支持面向智算和通算场景灵衢产品的系统高阶服务架构、所需的主要软件功 能模块及接口功能。便于软件开发工程师、技术支持、企业技术负责人等使用、 开发、管理和维护灵衢产品 |
| 灵衢®系统管控运维软 件架构与接口参考设计 | 介绍基于灵衢的超节点智算和通算场景管控运维所使用的软件架构和接口功能 参考。方便运维系统开发者、管控系统开发者、运维工程师和系统管理员等使用、 开发、管理和维护灵衢产品 |
| 基于灵衢®的超节点参 考架构白皮书 | 定义基于灵衢的超节点参考架构，其拥有总线级互联、协议归一、平等协同、全 量池化、大规模组网和高可用性六大特征，帮助您迎接智能化时代算力基础设施 挑战 |
UB 相关软件已经开源，包括操作系统软件组件，以及高阶服务软件等。
华为 UB 目前已经开源，并且绑定了华为自家的欧拉操作系统，以“木兰宽松协议 2.0”进行授权。因此华为软 件生态的范围，仍然还是华为原有的生态合作伙伴，软件生态仍处于萌芽状态。
虽然华为 UB 的协议标准已经发布，但在产品化落地中，仍高度依赖于华为的昇腾、鲲鹏、网络和存储等 ICT 产品，因此目前 UB 硬件生态仍高度集中于华为自身，尚无生态伙伴提供第三方硬件。
UB 目前仍处于从实验室走向商用的关键阶段，其核心价值在于为 AI 训练提供了一种高性价比、高可靠性的 专有网络方案。尽管尚未大规模落地，但华为在昇腾生态中的垂直整合能力可能加速其应用进程。未来 1-2 年将是观察其实际效能和商业化潜力的关键窗口期。
寒武纪、昆仑芯、摩尔线程、沐曦、璧仞、阿里平头哥等国产 GPU 厂商，随着国产算力产业的快速发展，在 生态建设上也在参考英伟达模式进行投入。
首先在软件栈上，以寒武纪为例，寒武纪重点提供计算层的软件，即与 CUDA 对标的计算软件，同时也提供 了兼容 CUDA 的解决方案。
在计算层之上的 AI 框架部分，寒武纪并未像华为提供 MindSpore 那样做 AI 框架的自研，而是以对接开源生 态为主要方案，形成了寒武纪自身发展的差异化生态路线，各有优点所在。
在 ScaleUp 互联领域，国产厂商均积极投身与开放技术联盟中，包括 UALink、ESUN、OISA 等技术方案， 借助联盟的力量共同打造互联生态。
由于多个国产厂商的崛起，以及大模型对算力的需求规模变化，异构 GPU 的生态集成变成了当前的重要需求 之一。
理想的情况下，基于 UALink 等 ScaleUp 技术联盟实现异构 GPU 的集成，在算力、内存等方面实现完全的 融合，可以构建出异构 GPU 组成的超节点系统。但目前上述工作仍有待于联盟各成员的共同推进，生态成熟 仍待时日。
因此当前主要的生态集成模式，是采用 AI 云的方式，即基于云计算的调度能力实现异构 GPU 之间的算力调 度，在云的层面实现异构集成。
以上述典型架构为例，每一类算力在微观上组成相对独立的集群，在集群内采用 ScaleUp 和 ScaleOut 技术 进行互联；多个算力集群之间通过云网络进行连接，并且使用云平台进行算力的资源池化和调度。这是当前较 为主流的生态集成模式，各大云厂商、垂直领域的 AI 云服务商基本上都采用思路相似的方案。
基于云实现的异构算力多集群，在大模型训练等场景时，如果算力需求超过单种算力计算的规模，则涉及单一 任务跨异构集群运行的情况。目前少部分云厂商提出异构混训的集成方案，即通过集合通信库改造等方案，将 训练任务进行拆解后分担到异构 GPU 上完成，目前在有限场景下已经取得一定的成果。但由于异构集成与单 个 GPU 厂商的利益存在一定矛盾，而集成厂商改造集合通信库又离不开 GPU 厂商的支持，因此从生态角度 看，上述方案的长期生态可持续性仍需观察。
总的来看，未来的异构 CPU 生态集成将两极化发展。一种是基于 AI 云的模型，进行松耦合的方式集成，这 是目前已经可落地的模式，未来会在异构迁移、统一管理等技术点上进行重点发展。另一种是基于类超节点的 紧耦合模式，依赖于各类 ScaleUp 互联技术和联盟的成熟和生态完善，仍需要一个较为长期的发展过程。
超节点作为大规模异构计算（GPU/CPU/XPU 协同）的核心载体，依托本书前面介绍的各类 Scale-up 互联 协议（NVLink、UALink、HSL、ETH-X、CXL、华为 UB、新华三 GLink 等）实现算力聚合与效率跃升， 已成为支撑人工智能大模型训练、推理及高性能计算等数据密集型场景的关键基础设施。当前，超节点正逐步 摆脱“单一算力堆叠”的发展模式，向“高效协同、灵活扩展、生态兼容”的高阶形态演进。结合现有技术实 践与行业发展需求，对其发展趋势与未来进行展望和总结。
超节点的性能演进核心在于“突破技术瓶颈、实现极致协同”，主要围绕带宽、时延、一致性、扩展性四大关 键指标，通过互联协议升级与架构优化，持续提升算力利用效率，具体呈现如下四大演进方向。
带宽是制约超节点算力聚合效能的核心瓶颈，当前各类 Scale-up 协议均以高带宽及高效率为核心演进目标。 其中，NVLink 作为 GPU 直连领域的标杆协议，GPU 互联带宽已从早期 V100 芯片的 300GB/s，提升至新 一代 Rubin GPU 的 3.6TB/s 双向互联带宽，其构成的 NVL72 可提供 260TB/s 的节点内互联带宽；CXL 4.0 协议依托 PCIe 7.0 技术基础，将数据传输速率翻倍至 128GT/s，通过捆绑端口（Bundled Ports）实现多物 理端口聚合，打破 16 Lane 传输限制，大幅提升设备间互联总带宽；ETH-X 协议针对超节点 10Tbps 级互 联需求，通过头部压缩、事务聚合等技术优化，有效提升 Load 指令传输效率，缓解以太网包头开销带来的带 宽损耗。未来，超节点内互联带宽将向单节点数百 TB/s 及更高的方向演进，同时通过协议层面的持续优化， 不断降低传输开销，推动带宽利用效率的突破。
低时延是超节点实现“算力协同如同单一设备”的关键前提，各类 Scale-up 协议通过缩短传输链路、优化 软件栈设计、引入事务代理机制等多种方式，持续压缩端到端传输时延。CXL 协议的物理延迟较传统 PCIe 协议时延降低 50%，同时通过自定义极简软件栈，进一步压缩应用层时延，挖掘出远超物理链路时延的优化 空间；NVLink 通过 GPU-XBAR 直连架构，实现 GPU 间 3.6TBps 双向通信的百纳秒级时延控制；ETH-X 协议引入 AXI 事务代理机制，针对 Push 类型事务实现本地快速响应，将跨 Scale-up 域的事务响应时延降 低近一个数量级；UALink、华为 UB 等协议也以百纳秒级时延为优化目标，持续优化链路传输与事务处理流
程。未来超节点时延将向百纳秒甚至亚百纳秒级方向演进，同时通过计算与通信 Overlap 技术，实现通信时 延的有效隐藏，提升算力与通信资源的综合利用效率。
缓存一致性是超节点实现异构设备（CPU/XPU/GPU）协同工作的关键需求，不同 Scale-up 协议结合具体 应用场景，形成“分级适配、灵活选择”的演进趋势。CXL 协议依托硬件 Cache 一致性技术，复用 PCIe 物理层实现异构设备协同，大幅简化编程模型；NVLink 通过物理地址寻址与硬件一致性检查机制，实现 GPU 间缓存数据的高效同步，支撑 NVL72 超节点作为单一巨型 GPU 的协同工作模式；ETH-X 协议支持释放一 致性内存模型（Release Consistency Model），通过 Acquire-Release 语义实现线程间同步，在保证系 统性能的前提下，有效平衡一致性开销。
因硬件一致性带来的复杂性和时延、成本开销，Scale up 协议也根据场景的需求，对是否支持硬件一致性进 行不同的选择。未来，超节点可根据应用需求（如小规模设备直连用硬件保证一致性、大规模集群组网用软件 保证一致性）动态切换一致性级别，在保障数据传输正确性的基础上，最大化降低一致性开销。
超节点的规模演进正从“单节点多设备”向“多节点互联集群”延伸，各类 Scale-up 协议通过架构优化， 持续突破规模限制。NVLink 通过 NVSwitch 构建 Fat-Tree 拓扑结构，支撑 72 个 GPU 组建单一 NVL72 超节点，多个超节点可通过 InfiniBand 协议进一步扩展为更大规模集群；ETH-X 协议支持直联与 Switch 互 联两种拓扑结构，通过 High Radix 交换机与多层 Clos 拓扑，可支撑 512 卡规模的超节点，同时兼容 Ethernet 生态，实现超节点与 Scale-out 网络的无缝衔接；CXL 4.0 协议支持最多四个重定时器，有效延长链路传输 距离，同时通过捆绑端口优化多主机环境下的扩展性，支撑多 CPU 与多设备的协同工作；华为 UB 协议以百 万卡级互联为核心定位，打造直连、Scale-up、Scale-out 一体化协议架构，突破现有协议的规模限制； UALink 则通过多厂商联盟协作模式，支撑千卡级加速器的互联需求。未来，超节点将可能实现“单超节点千 卡级、集群百万卡级”的规模目标，同时保持低时延与高带宽的协同优势，为万亿参数级超大模型的分布式训 练提供支撑。
当前，超节点的技术创新围绕“协议融合、架构优化、语义增强、生态兼容”四大核心方向展开，结合互联协 议升级与硬件设计创新，着力破解超节点协同效率不足、部署成本偏高、编程复杂度较高等行业痛点，形成了 多个技术创新热点。
传统超节点依赖 Scale-up 协议实现内部高速互联，通过 Scale-out 协议实现集群规模扩展，两者存在明显 的技术边界，导致数据传输效率降低、部署成本上升。当前，“协议融合”已成为超节点技术创新一个核心方 向，较多 Scale-up 协议兼容成熟的网络生态，实现 Scale-up 与 Scale-out 的无缝衔接。ETH-X 协议的 核心创新点在于将 AXI 事务封装为以太网数据包，依托成熟的 Ethernet 生态，实现超节点内部 Scale-up 互联与外部 Scale-out 扩展的一体化，同时引入 L2 LLR（链路层重传）、CBFC（信用流控）等机制，弥补 以太网传输可靠性不足的短板；海光 HSL 协议推出 HSLoE（HSL over Ethernet）解决方案，在保持 HSL
事务层不变的前提下，将事务封装至以太网中，充分复用现有网络基础设施，实现超节点与现有网络生态的兼 容，同时支持原生 HSL 与 HSLoE 模式并存，可灵活适配不同部署场景；华为 UB 协议直接定位为“直连、 Scale-up、Scale-out 统一协议”，无需进行协议转换，实现超节点内部高速协同与集群规模扩展的一体化； CXL 协议依托 PCIe 生态优势，实现 CPU 与异构设备的 Scale-up 直连，同时可通过 PCIe/CXL 网卡连接 以太 Switch 扩展支持 Scale-out 集群。此外，SuperNIC 架构的引入，成为协议融合的重要载体，通过硬 件加速技术屏蔽 Scale-up 与 Scale-out 的网络边界，简化网络迁移成本，提升数据传输效率，已成为超节 点部署的重要创新方向。
随着超节点异构协同（CPU/GPU/XPU/IO）需求的日益复杂，传统 IP 集成式设计模式存在工艺迭代缓慢、 研发成本偏高、灵活性不足等问题，IO 芯粒化（IO Die）已成为超节点架构创新的核心方向。ETH-X、GLink 等协议提出基于 IO 芯粒的实现方案，将计算芯粒与 IO 芯粒解耦，通过 UCIe 接口实现互联，计算芯粒采用先 进工艺追求极致性能，IO 芯粒采用成熟工艺降低研发与生产成本，同时支持 IO 芯粒数量的灵活配置，实现互 联带宽的动态适配；海光 HSL 协议同样依托 IO 芯粒方案，实现计算芯粒与 IO 芯粒的独立演进，减少 IP 移 植成本，缩短产品上市周期，同时支持多 IO 芯粒负载均衡，提升超节点运行可靠性；UCIe 协议的普及为 IO 芯粒化发展提供了重要支撑，其分层架构（物理层、D2D 适配器、协议层）可兼容 PCIe、CXL、AXI 等多 种协议，实现不同芯粒间的无缝互联，已成为超节点异构协同的核心接口标准。
超节点的应用场景日益多元化，涵盖人工智能大模型训练、高性能计算、云计算等多个领域，不同场景对数据 传输语义（同步/异步）的需求存在显著差异，语义增强已成为协议创新的重要方向，其核心目标为通过同步 保障数据正确性，通过异步提升传输效率。ETH-X 协议针对不同计算通信 Overlap 模式，定义两种访存语 义：Direct Copy（粗粒度、连续拷贝）依托专用拷贝引擎（SU-TMA），实现本地 HBM 到远端 HBM 的大 批量数据拷贝，适配结构化数据传输场景；Direct Access（小粒度、不连续访问）支持计算引擎直接读写远 端 HBM 数据，适配非结构化数据传输场景，同时通过内存屏障优化，提升跨卡同步操作性能；华为 UB 协议 也支持同步和异步协同，通过灵活的编程接口与运行时调度机制，支持两种模式的动态切换与混合使用。系统 可根据任务类型、网络负载与性能需求，选择最优的通信策略。
随着超节点规模的扩大与负载的提升，系统可靠性与运维效率面临更高要求，当前技术创新重点集中在硬件级 容错与智能化管控两大方面。ETH-X、ESUN 等基于以太物理层的 Scale up 协议，针对 Ethernet 传输可 靠性不足的问题，引入多重可靠性保障机制：L2 LLR 链路层重试机制，可针对 FEC 错误或 CRC 失败实现 数据包重传；CBFC 信用流控机制，通过信用分配与释放，确保接收方缓冲区资源充足，避免数据包丢弃； 聚合引擎与头部压缩技术，在提升传输效率的同时，减少误码带来的影响；此外，还支持多级负载均衡与事务 保序机制，避免数据传输错乱。NVSwitch 通过 hop-by-hop 错误检查、ECC 校验、SRAM 缓冲等硬件机 制，保障数据传输可靠性。在运维管控方面，超节点正逐步引入智能化监控与调度机制，通过实时采集链路带 宽、传输时延、设备负载等核心数据，动态调整负载均衡策略与资源分配方案；ETH-X、HSL 等协议均支持 集群控制器与标准化运维接口，简化超节点的部署、配置与故障排查流程，降低运维成本。
超节点的规模化发展离不开开放生态的支撑，传统封闭协议（如早期 NVLink）已难以适配多厂商异构协同需 求，支持协议开放和多厂商协作已成为行业创新热点。海光 HSL 协议已正式开放，面向 GPU、IO、OS、 OEM 等产业全链条，联动上下游合作伙伴共建计算生态，同时提供 PCIe 兼容性支持，降低厂商接入成本； CXL 协议由 CXL Consortium 主导，采用开放标准设计，支持多厂商设备互联，已成为异构计算互联领域 的主流标准之一；ETH-X 协议由 ODCC 发布，依托开放数据中心生态，推动超节点互联协议的标准化与产 业化，可适配不同厂商的 GPU、Switch 设备；UALink 通过多厂商联盟协作模式，打造开放的加速器互联协 议，打破单一厂商的技术主导；华为 UB 协议目前虽未完全开放，但其定位为开放兼容，预留了多厂商设备接 入接口。英伟达也开展了 NVLink Fusion 项目，对其 NVlink 生态进行了部分开放，开源和开放已成为超节 点领域和 NVLink 生态抗衡的唯一路线。
随着人工智能大模型、高性能计算、云计算等场景的持续升级，超节点作为核心算力载体，将迎来规模化部署、 多元化适配、绿色化发展、生态化协同的发展新阶段，同时在发展过程中仍面临协议标准化、成本优化、安全 保障等多重挑战，展望如下：
人工智能大模型（尤其是万亿参数以上级别模型）的训练与推理，需要大规模 GPU 协同算力与高速互联技术 的支撑，超节点正从高端小众向规模化部署方向演进。未来 3-5 年，单超节点规模将从当前的数十、数百卡 级别，提升至千卡级，集群规模将突破百万卡级，可支撑更大规模的分布式训练与推理任务；NVLink、CXL、 HSL、ETH-X 等协议将进一步普及，成为超节点互联的主流选择，其中 ETH-X、ESUN 等依托 Ethernet 生态优势，HSL、UB 依托国产生态优势，CXL 依托 PCIe 兼容性优势，将在不同应用场景形成差异化竞争 格局；超节点将广泛应用于 AI 算力中心、超算中心、云计算数据中心，成为支撑数字经济高质量发展的核心 算力基础设施，同时逐步向边缘算力中心延伸，适配边缘大规模异构计算需求（如自动驾驶、工业互联网等场 景）。
不同行业场景对超节点的性能、规模、成本等需求存在显著差异，通用化超节点已难以满足各行业的极致性能 与成本优化需求，定制化成为超节点行业的重要发展趋势。在人工智能大模型场景，核心需求聚焦于高带宽、 低时延、大规模协同，可使用用 NVLink、ETH-X 等协议，构建 GPU 主导的超节点，优化计算与通信 Overlap 效率，提升大模型训练速度；在高性能计算（HPC）场景，重点关注 CPU/XPU 协同与缓存一致性，可采用 HSL、CXL、UALink 等协议，构建异构协同超节点，适配气象预报、量子计算等大规模科学计算需求；在 云计算场景，注重灵活性、扩展性与成本控制，可使用 ETH-X、HSLoE 等协议，依托 Ethernet 生态实现 超节点与现有云网络的无缝衔接，支持资源按需扩容与动态调度；在自主化场景，海光 HSL、华为 UB 等国 产协议将加速成熟，结合国产 GPU、CPU、Switch 设备，构建自主可控的超节点生态，满足政务、金融等 关键领域的算力需求。此外，超节点将向“模块化、可配置”方向发展，通过 IO 芯粒数量、协议类型、设备 规模的灵活配置，适配不同场景的个性化算力需求。
超节点的规模化部署带来了高能耗、高成本等问题，绿色化发展与成本优化已成为行业发展的重要考量因素。 在能耗优化方面，将通过协议优化与硬件设计创新，持续降低传输能耗：CXL 4.0、ETH-X 等协议采用低功 耗物理层设计，优化链路唤醒与休眠机制，减少设备空闲状态下的能耗；IO 芯粒化方案通过工艺差异化选择， 降低整体功耗，同时减少芯片面积，提升芯片产量，降低硬件生产成本；负载均衡与智能化调度机制，可有效 避免资源闲置，提升算力利用效率，间接降低系统能耗。在成本优化方面，开放协议的普及将有效降低厂商研 发成本，CXL、ETH-X、ESUN 等开放协议，允许厂商复用现有 IP 与生态资源，缩短产品上市周期；ETH-X、 HSLoE 等协议对 Ethernet 生态的复用，可避免专用网络的重复建设，降低部署成本；模块化设计允许用户 根据实际需求配置资源，避免过度投资，提升超节点的性价比。未来，超节点将实现“高性能、低能耗、低成 本”的协同平衡，推动算力资源的普惠化发展。
超节点的异构协同需求，推动“协议标准化、设备互联互通”成为行业共识，生态协同将进一步深化。在协议 标准化方面，CXL Consortium、ODCC 等行业组织将牵头推动 Scale-up 协议的标准化进程，明确事务层、 链路层、物理层的接口规范，减少多厂商设备互联的兼容性问题； GLink、HSL、ETH-X 等协议将持续完 善，推动国产超节点互联协议与国际标准的兼容对接，提升国产生态的行业影响力；UCIe 协议将成为 IO 芯 粒互联的主流标准，推动计算芯粒、IO 芯粒、存储芯粒的标准化与模块化，加速超节点架构创新。在互联互 通方面，多厂商设备将逐步支持 CXL、HSL、ETH-X、GLink 等主流开放协议，实现 GPU、CPU、Switch、 存储设备的无缝互联，打破厂商技术壁垒；超节点将实现与 Scale-out 网络、云计算平台、人工智能框架的 深度融合，简化应用部署与调度流程；开源生态将进一步完善，开源编程模型、开源调度工具、开源运维平台 的普及，将降低超节点的应用门槛，吸引更多开发者参与生态建设。此外，产学研协同将进一步加强，高校、 科研机构与企业将联合开展超节点核心技术研发，突破协议优化、架构创新、可靠性保障等关键技术，加速技 术成果的产业化转化。
超节点在发展过程中，仍面临四大核心挑战，需通过技术创新与行业协同逐步破解。一是协议兼容性不足，不 同 Scale-up 协议（如 NVLink、HSL、ETH-X、GLink、UB）的接口规范存在显著差异，多协议共存导致 设备互联互通难度增加，未来需通过行业标准化建设与协议转换技术，破解兼容性瓶颈；二是核心技术仍有短 板，国产超节点协议（如海光 HSL、华为 UB、H3C GLink）在带宽、时延优化等方面，与国际主流协议（如 NVLink、CXL）仍存在差距，需加大核心技术研发投入，突破技术瓶颈，提升国产超节点的核心竞争力；三 是运维复杂度较高，超节点规模扩大与异构设备增多，导致系统调度、故障排查、性能优化的难度显著提升， 未来需通过智能化运维技术（如人工智能调度、故障预测预警），提升运维效率；四是安全风险凸显，超节点 作为核心算力载体，承载大量敏感数据，数据传输与存储的安全性面临严峻挑战，需加强硬件级安全设计与软 件级安全防护，构建全方位安全防护体系，保障超节点的安全稳定运行。
总体而言，超节点作为大规模异构计算的核心载体，依托 Scale-up 协议的持续升级与技术创新，将逐步突 破性能、规模、成本、生态等多重瓶颈，向“高效协同、灵活扩展、绿色低碳、开放兼容”的方向持续演进， 成为支撑人工智能、高性能计算、云计算等产业高质量发展的核心算力基础设施，推动数字经济进入算力驱动 的新阶段。
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| AEC（Active Electrical Cable） | 有源铜缆 | 在铜缆中集成Redriver/Retimer的有源高速互连方案， 兼具铜缆的低成本与光缆的延伸能力，是高速短距互连 的重要选项，也称为Active DAC。 |
| AER | 高级错误报告 | Advanced Error Reporting，即高级错误报告，是一种 用于详细报告硬件或软件错误信息的机制，便于问题定 位和排查。 |
| AFH：AI Forwarding/Fabric Header | AI 转发头 | SUE定义的以太网传输用的头结构，AFH gen2实现头 部的深度压缩，用于优化AI场景下的以太网数据传输效 率。 |
| AI | 人工智能 | Artificial Intelligence，智能计算与大模型技术的核心领 域，是研究、开发用于模拟、延伸和扩展人的智能的理 论、方法、技术及应用系统的一门新技术科学。 |
| AIGC | 生成式人工智能 | Artificial Intelligence Generated Content，即生成式 人工智能，是指利用人工智能技术自动生成文本、图像、 音频、视频等内容的技术。 |
| ALS | 阿里整机柜超节点架 构 | ALink System，阿里基于 UALink推出的整机柜超节点 架构，用于提升数据中心的计算效率和资源利用率。 |
| ALU | 算术逻辑单元 | Arithmetic Logic Unit，即算术逻辑单元，是计算机中 央处理器（CPU）的核心组件之一，负责执行算术运算 （如加、减、乘、除）和逻辑运算（如与、或、非）。 |
| APB (Advanced Peripheral Bus) | 高级外设总线 | 针对外设的慢速标准协议，是一种用于连接微控制器和 外设的低带宽、低功耗总线协议，适用于对传输速度要 求不高的外设。 |
| API | 应用程序编程接口 | Application Programming Interface，在 Agent 任务 中涉及的调度对象，是不同软件组件之间进行交互的接 口，规定了如何调用软件功能的方法和规范。 |
| ATS | 自动转换开关 | Automatic Transfer Switch，主要用于在主电源与备 用电源之间进行自动切换，以保证关键负载的连续运行， 提高供电可靠性。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| AXI | 高级可扩展接口 | Advanced eXtensible Interface，是一种高性能、高 带宽、低延迟的片上总线协议，主要用于连接芯片内部 的高速组件，如CPU、GPU、内存控制器等。 |
| BAR | 基地址寄存器 | Base Address Register，即基地址寄存器，用于存储 设备在内存映射空间中的基地址，CPU通过该寄存器访 问设备的内存或I/O空间。 |
| BDF 地址 | BDF 地址 | PCIe 设备的标识地址，包含 PCI 域号、总线号、设备号、 功能号，NCCL 通过该地址识别 PCIe 设备的物理位置， 便于设备间的通信和管理。 |
| BER | 误码率 | Bit Error Rate，即误码率，是指在数据传输过程中出现 错误的比特数与传输总比特数的比值，是衡量数据传输 可靠性的重要指标。 |
| BF16 | 浮点格式 16位 | Brain Floating Point 16，截断尾数保留 8 位指数的浮点 格式，大模型训练主流标准，兼顾了计算精度和存储效 率。 |
| BFC | 基于缓冲感知的流量 控制 | Buffer-aware Flow Control，即基于缓冲感知的流量 控制，是一种根据接收端缓冲区状态动态调整发送端数 据发送速率的流量控制机制，避免缓冲区溢出。 |
| BIOS | 基础输入输出系统 | Basic Input/Output System，即基础输入输出系统，是 计算机启动时运行的固件程序，负责初始化硬件设备、 引导操作系统启动。 |
| BIST | 内置自测试 | Built-In Self Test，即内置自测试，是芯片或设备内部 集成的测试电路，用于自动检测自身的硬件故障，提高 测试效率和可靠性。 |
| BMC | 基板管理控制器 | Baseboard Management Controller，即基板管理控 制器，是一种独立于主CPU的嵌入式控制器，用于远程 管理和监控服务器硬件状态。 |
| BusBar | 汇流排 | 机柜内提供集中供电的高压直流铜排，用于将电源分配 到机柜内的各个设备，具有低电阻、高载流能力的特点。 |
| C2C | 芯片间互联 | Chip-to-Chip，如 NVLink-C2C，实现芯片间统一内 存寻址的高速互联技术，用于提升芯片之间的数据传输 速度和效率。 |
| CAS | 比较并交换 | Compare-and-Swap，即比较并交换，是一种原子操 作，用于在多线程或分布式环境中实现数据的同步更新， 避免并发冲突。 |
| CBFC （ Credit-Based Flow Control） | 基于信用的流量控制 | 一种链路层的核心流控技术，用于解决物理链路拥塞与 接收端缓冲区溢出问题，通过信用机制实现发送端与接 收端的速率匹配。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| CCA | 集合通信加速报文头 | Collective Communication Accelerate，即集合通信 加速报文头，用于优化集合通信场景下的数据传输效率， 减少通信延迟。 |
| CCA Mode | 集合通信加速模式 | Collective Communications Acceleration Mode，即 集合通信加速模式，是一种专门用于提升集合通信性能 的工作模式。 |
| CCL | 集合通信库 | Collective Communication Library，即集合通信库， 是提供集合通信原语（如广播、归约、散射等）的软件 库，用于支持分布式计算中的多节点通信。 |
| CDR | 时钟数据恢复电路 | Clock and Data Recovery Circuit，即时钟数据恢复电 路，用于从接收的数据流中提取时钟信号和恢复数据， 确保数据的正确接收。 |
| CDU | 冷量分配单元 | Cooling Distribution Unit，液冷系统中的关键组件，负 责冷却液分配，将冷却系统产生的冷量均匀分配到各个 发热设备，实现高效散热。 |
| CFD | 计算流体动力学 | Computational Fluid Dynamics，热设计解决方案的一 种理论设计原理，通过数值模拟方法分析流体流动和热 量传递过程，用于优化设备的散热设计。 |
| CLOS | CLOS互联拓扑 | 多级交换架构，提供无阻塞带宽，AI 集群主流网络拓扑， 通过多级交换机实现大量节点之间的高速互联，满足AI 集群的高带宽需求。 |
| CM | 连接管理器 | RDMA 中用于在队列对（QP）建立之前，完成 QP 信 息交换的组件，是 QP 建立的前提，确保RDMA通信的 顺利建立。 |
| Coherence Agent | 一致性代理 | 集成在 NVLink 每个 GPU L2 缓存中的硬件单元，当 GPU 修改远端内存时，通过该单元发送 “无效化 / 更新” 信号，保证硬件层面的缓存一致性。 |
| Collective Communication | 集合通信 | 并行计算 / 分布式系统中多个进程 / 计算节点共同参与 的通信操作，解决点到点通信在多节点场景下的编程复 杂、性能低下等问题，是分布式训练的核心技术。 |
| CollNet 算法 | 集合网络算法 | NCCL 中基于 SHARP 协议设计的通信算法，专为 IB 网 络优化，可将数据聚合任务卸载到网络交换机，提升大 规模 GPU 集群的通信效率。 |
| communicator | 通信器 | NCCL 中由多个 rank 组成的进程集合，定义了可以相互 通信的进程范围，一个进程可属于多个通信器，且在不 同通信器中 rank ID 可不同。 |
| CoWoS | 晶圆级芯片封装 | Chip-on-Wafer-on-Substrate，台积电推出的 2.5D 先进封装技术，将芯片直接封装在晶圆上，再与基板连 接，提升芯片的集成度和性能。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| CPC（Co-packaged Copper） | 共封装铜缆 | 将高性能铜缆直接集成到芯片封装附近的互连技术，缩 短信号传输距离，降低信号损耗，提升传输速度。 |
| CPLD | 复杂可编程逻辑器件 | Complex Programmable Logic Device，即可编程逻 辑器件的一种，具有较高的集成度和灵活性，可通过编 程实现特定的逻辑功能。 |
| CPO（Co-packaged Optics） | 共封装光学 | 将光学引擎（光模块）与 ASIC 芯片（如 GPU、TPU、 交换机芯片）共同集成在同一封装基板或中介层 （Interposer）上的高速系统的互连架构，提升光互连 的效率和集成度。 |
| CPU | 中央处理器 | Central Processing Unit，传统计算核心，在超节点中 角色转向协同者，是计算机系统的核心，负责执行指令、 处理数据。 |
| CQ | 完成队列 | RDMA 中用于存放发送和接收请求处理完成通知的队 列，无论传输成功或失败，都会产生完成消息（CQE） 并存入该队列，供应用程序查询。 |
| CQE | 完成队列元素 | 完成队列（CQ）中存放的完成消息，包含传输状态等信 息，每个工作请求（WR）处理完成后都会生成对应的 CQE，用于告知应用程序请求的处理结果。 |
| CRC | 循环冗余校验 | Cyclic Redundancy Check，即循环冗余校验，是一种 用于检测数据传输过程中错误的校验方法，通过计算数 据的校验值来判断数据是否被篡改或出错。 |
| Credit | 信用 | 基于信用的流量控制机制中的核心计量令牌，本质是接 收端向发送端授予的缓冲区资源使用权限，用于量化接 收端当前可接收数据的存储能力。 |
| CTLE | 接收端连续时间线性 均衡 | Continuous Time Linear Equalizer，即接收端连续时 间线性均衡器，用于补偿高速数据传输过程中的信号衰 减和失真，提升接收信号的质量。 |
| CUDA | （英伟达）统一计算 架构 | Compute Unified Device Architecture，NVIDIA 的并 行计算平台和编程模型，用于开发利用GPU进行并行计 算的应用程序。 |
| CXL | 计算快速链路 | Compute eXpress Link，基于 PCIe 的缓存一致性互 联标准，由 Intel 牵头联合多家厂商推出的高速互联协议， 核心定位是解决 CPU 与 GPU、FPGA 等加速器间的互 联瓶颈，支持缓存一致性。 |
| DA （Destination Address） | 目的地址 | ETH-X 传输层定义的逻辑目的地址，用于标识数据传输 的目标节点，确保数据准确送达。 |
| DAC | 直连铜缆 | Direct Attach Cable，用于短距离高速互联的无源铜 缆，电接口的高速无源铜缆组件，用于短距离（通常≤7 米）设备间高速互联，无需额外的信号放大设备。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| DCB | 数据中心桥接 | 为数据中心网络设计的技术标准，包含 ETS、PFC 等子 技术，支撑以太网实现无损传输和 QoS 保障，提升数据 中心网络的可靠性和性能。 |
| DHCP | 动态主机配置协议 | Dynamic Host Configuration Protocol，即动态主机配 置协议，用于自动为网络中的设备分配IP地址、子网掩码、 网关等网络配置信息。 |
| DL | 数据层 | Data Layer，即数据层，是网络协议栈或芯片架构中的 一个层次，负责数据的封装、传输和接收。 |
| DLR | 数据层重传 | Data Layer Retransmission，即数据层重传，是数据 层用于确保数据可靠传输的机制，当数据传输失败时， 重新发送数据。 |
| DMA | 直接内存访问 | Direct Memory Access，即直接内存访问，是一种允 许外设直接访问系统内存的技术，无需CPU干预，提升 数据传输效率。 |
| DMMA | 动态组播加速 | Dynamic MoE Multicast Acceleration，即动态组播加 速，用于提升MoE（混合专家模型）场景下的组播通信 效率。 |
| DMR | 动态组播请求 | Dynamic Multicast Request，即动态组播请求，是用 于发起动态组播通信的请求信号。 |
| DMTF | 分布式管理任务组 | Distributed Management Task Force，即分布式管理 任务组，是一个致力于制定分布式系统管理标准的行业 组织。 |
| DNS | 域名系统 | Domain Name System，即域名系统，用于将域名（如 www.example.com）转换为IP地址，实现网络设备的 定位和访问。 |
| DP | 数据并行 | Data Parallelism，一种 AI 模型并行策略，将训练数据 分成多个部分，分配到不同的计算节点上并行训练，提 升训练速度。 |
| DPC | 下行端口遏制 | Downstream Port Containment，一种 PCIe/总线可 靠性机制，用于隔离下行端口的故障，避免故障扩散到 整个系统。 |
| DSA | 领域专用架构 | Domain Specific Architecture，专为特定领域（如 AI） 定制的硬件架构，具有更高的性能和能效比。 |
| DSCP | 差分服务代码点 | RoCE 中替代 IB 的 TRAFFIC CLASS 的技术，用于对 流量进行分类，实现服务质量（QoS）管控，确保高优 先级流量的传输质量。 |
| ECC | 纠错码 | Error Correction Code，内存或传输中的错误检查与纠 正机制，能够检测并纠正数据传输或存储过程中出现的 错误，提升数据可靠性。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| ECMP | 等价多径路由 | Equal-Cost Multi-Path，即等价多径路由，是一种路由 技术，当存在多条到达同一目标的等成本路径时，将流 量分散到多条路径上传输，提升网络带宽和可靠性。 |
| ECN | 显式拥塞通知 | RoCE 网络层采用的拥塞控制技术，用于实现端到端的 拥塞通知，让发送端及时调整发送速率，避免网络拥塞 加剧。 |
| ECPU | 嵌入式中央处理器 | Embedded Central Processing Unit，即嵌入式中央 处理器，是专门为嵌入式系统设计的CPU，具有低功耗、 小体积、高可靠性的特点。 |
| EP | 专家并行 | Expert Parallelism，一种 AI 模型并行策略（常用于 MoE），将模型中的不同专家分配到不同的计算节点上 并行计算，提升模型训练和推理效率。 |
| ESUN | 以太Scale-Up网络 工作组 | Ethernet Scale-Up Network，由 Meta、博通等组建 的工作组，基于以太网的互联标准，致力于推动以太网 在大规模计算场景中的应用。 |
| ETS | 增强型传输选择 | DCB 标准的一部分，IEEE 802.1Qaz 规范定义，将流量 分配到不同队列并为每个队列分配带宽权重，保证高优 先级流量的带宽资源。 |
| EXP Mode | 极致访存模式 | Extreme Performance Mode，即极致访存模式，是 一种用于提升内存访问性能的工作模式，优化内存读写 效率。 |
| FEC | 前向纠错 | Forward Error Correction，即前向纠错，是一种在数 据传输过程中自动检测并纠正错误的技术，无需接收端 反馈请求重传，提升传输效率和可靠性。 |
| Fence | 内存栅栏操作 | 软件层面保证内存读写顺序的操作，可避免乱序导致的 Cache 不一致，保障数据操作的完整性，常用于多线程 编程中。 |
| FFE | 发送端前馈均衡器 | Feed Forward Equalizer，即发送端前馈均衡器，用于 补偿高速数据传输过程中的信号衰减，提升发送信号的 质量。 |
| FIB | 转发表信息库 | Forwarding Information Base，即转发表信息库，是 路由器或交换机中用于存储路由信息和转发规则的数据 库，指导数据报文的转发。 |
| Flit | 流控单元 | 定长的数据片，配合 Credit 流控机制管控缓冲区，可有 效降低拥塞导致的延迟抖动，是实现低抖动的关键技术 之一；高速总线链路层的固定长度基本传输单元，用于 替代传统可变长度帧 / 包，适配高速传输的流控与信号完 整性需求。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| FLOPS | 每秒浮点运算次数 | Floating-point Operations Per Second，衡量计算机 性能的标准，用于表示计算机每秒能够执行的浮点运算 次数，数值越高性能越强。 |
| FP16 | 半精度浮点数 | Half-precision floating-point，传统的 16 位浮点格式， 用于在精度要求不高的场景下，减少内存占用和提升计 算速度。 |
| FP32 | 单精度浮点数 | Single-precision floating-point，32 位浮点格式，科 学计算基准，用于对精度要求较高的科学计算和工程应 用。 |
| FP4 | 4位浮点数 | 4-bit Floating Point，用于极致推理加速的低精度格式， 在保证一定精度的前提下，大幅提升推理速度和降低内 存占用。 |
| FP8 | 8位浮点数 | 8-bit Floating Point，包含 E4M3 和 E5M2 两种格式， 用于加速训练，兼顾精度和计算效率。 |
| FTP | 文件传输协议 | File Transfer Protocol，即文件传输协议，用于在网络 中实现文件的上传和下载，是互联网中常用的文件传输 标准。 |
| GBN | 回退 N 步协议 | Go Back N Frames Protocol，即回退N步协议，是一 种自动重传请求（ARQ）协议，当接收端检测到数据错 误时，要求发送端从错误帧开始重新发送后续所有帧。 |
| GDDR | 图形双倍数据速率存 储器 | Graphics Double Data Rate，传统的板载显存技术， 专门为图形处理单元（GPU）设计，具有高带宽、高速 度的特点。 |
| GEMM | 通用矩阵乘法 | General Matrix Multiply，AI 计算中最核心的数学运算， 是神经网络训练和推理过程中最主要的计算任务。 |
| gNMI | gRPC 网络管理接口 | gRPC Network Management Interface，即gRPC 网络管理接口，基于gRPC协议的网络设备管理接口， 用于实现网络设备的配置和监控。 |
| GPGPU | 通用图形处理器 | General-Purpose Computing on GPU，强调通用计 算能力的 GPU 架构，不仅用于图形处理，还可用于通用 并行计算。 |
| GPM-Req | GPU 投递型组播请 求 | GPU Posted Multicast Request，即GPU投递型组播 请求，是GPU发起的一种无需等待响应的组播请求。 |
| GPU | 图形处理器 | Graphics Processing Unit，AI 计算的核心产物，超节 点的核心单元，最初用于图形处理，现广泛应用于AI训 练和推理等并行计算场景。 |
| GPUDirect P2P | GPU 直接点对点通 信 | 英伟达的技术，让 GPU 能够直接访问彼此的显存，无需 经由 CPU 系统内存中转，是 NCCL 节点内高速通信的 基础。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| GPUDirect RDMA | GPU 直接远程直接 内存访问 | 英伟达的技术，让 GPU 内存可与 NIC 直接进行 RDMA 数据传输，无需主机内存中转，是 NCCL 节点间高速通 信的核心技术。 |
| GR-Req | GPU 归约请求 | GPU Reduce Request，即GPU归约请求，是GPU发 起的用于执行归约操作（如求和、求最大值）的请求。 |
| GR-Resp | GPU 归约响应 | GPU Reduce Response，即GPU归约响应，是对 GPU归约请求的响应消息，包含归约操作的结果。 |
| GUID | 全局唯一标识符 | Globally Unique Identifier，即全局唯一标识符，是一种 用于唯一标识对象的字符串，确保在全球范围内不重复。 |
| GVA | 客户虚拟地址 | 跨交换机访问对端内存时发起访问使用的地址，需经本 地 MMU 转换为网络物理地址，用于实现跨节点的内存 访问。 |
| HBD | 高带宽域 | High Bandwidth Domain，指超节点内部形成的高带宽 互联区域；超节点中由节点内部处理器（GPU/CPU） 通过 Scale up 网络互联形成的域，包含软硬件层面，硬 件采用专用互连协议构建高带宽低延迟通信域，软件层 面支持基于内存语义的直接内存访问。 |
| HBM | 高带宽内存 | High Bandwidth Memory，通过 3D 堆叠实现极高带宽 的存储介质，专门为高性能计算和AI场景设计，提供超 高的内存带宽。 |
| HPC | 高性能计算 | High Performance Computing，即高性能计算，是指 利用高性能计算机系统解决大规模、复杂的计算问题， 广泛应用于科学研究、工程设计、人工智能等领域。 |
| HSL | 海光超节点互联总线 协议 | Hygon System Link，海光超节点总线协议，用于海光 超节点内部各组件之间的高速互联。 |
| IB | 英伟达私有以太互联 协议 | InfiniBand，一种高性能计算机网络通信标准，专用高速 网络技术，支持全互联拓扑、高带宽、低延迟，硬件级 支持 RDMA，拥有独立的协议栈和专用硬件，内置完善 的流量控制和拥塞控制机制。 |
| ICI | 芯片间互联接口协议 | Inter-Chip Interconnect，Google TPU 的互联接口， 用于Google TPU芯片之间的高速互联。 |
| Infinity Fabric | AMD私有互联协议 | AMD CPU间、CPU与GPU模组对接的高速互联总线， 用于提升AMD处理器和GPU之间的通信效率。 |
| INS Mode | 智感访存模式 | Intelligent Sensing Mode，即智感访存模式，是一种智 能感知内存访问需求的工作模式，优化内存访问效率。 |
| INT4 | 4位整数格式 | 4-bit Integer，一种量化格式，用于AI推理场景，通过 降低数据精度来提升推理速度和降低内存占用。 |
| IOD | I/O 芯粒 | I/O Die，负责输入输出功能的独立芯粒，是芯片模块化 设计中的重要组成部分，负责处理芯片的I/O接口功能。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| IOMMU | 输入/输出内存管理 单元 | Input/Output Memory Management Unit，即输入/输 出内存管理单元，用于管理外设对系统内存的访问，实 现地址转换和权限控制。 |
| IPFIX | IP 流信息导出 | IP Flow Information Export，即IP流信息导出，是一种 用于收集和导出网络流量信息的协议，用于网络监控和 分析。 |
| IPMI | 智能平台管理接口 | Intelligent Platform Management Interface，即智能 平台管理接口，用于远程管理和监控服务器硬件，独立 于操作系统。 |
| LABR | 最小可用带宽比 | Least Available Bandwidth Ratio，即最小可用带宽 比，用于衡量网络中各链路的可用带宽情况，指导流量 分配。 |
| LACP | 链路聚合控制协议 | Link Aggregation Control Protocol，即链路聚合控制 协议，用于将多个物理链路聚合为一个逻辑链路，提升 链路带宽和可靠性。 |
| LID | 本地标识 | InfiniBand 子网内节点的唯一标识，交换机基于 LID 实现 子网内的包转发，确保数据在子网内准确传输。 |
| LL 协议 | 低延迟协议 | NCCL 的优化通信协议，针对小数据量传输优化，通过 减少同步延迟提升性能，依赖 CUDA 8 字节原子存储操 作，采用 4B Data+4B Flag 的传输形式。 |
| LL128 协议 | 128 字节低延迟协议 | NCCL 对 LL 协议的扩展优化版本，专为 NVLink 环境设 计，以 128 字节为单位进行原子存储操作，在低延迟的 同时实现更高的带宽效率，是 NVLink 环境的默认协议。 |
| LLDP | 链路层发现协议 | Link Layer Discovery Protocol，即链路层发现协议， 用于网络设备之间自动发现彼此的信息（如设备类型、 端口信息等），便于网络管理。 |
| LLM | 大语言模型 | Large Language Model，即大语言模型，是一种基于 深度学习的大型语言模型，能够理解和生成人类语言， 广泛应用于自然语言处理场景。 |
| LLR | 链路重传机制 | Link Level Retry，链路层的数据重传机制，链路层的核 心可靠性保障技术，用于解决 Scale Up 互联域（不可靠 传输）中链路错误（如 FEC 错误、CRC 错误）导致的 数据丢失问题。 |
| Load/Store | 加载 / 存储 | 计算机中基础的内存访问指令，内存语义下处理器可直 接使用该指令访问远端设备的内存数据，简化编程模型。 |
| LPO | 线性驱动可插拔光学 | 一种省去传统光模块中DSP芯片、采用直驱线性电路的 低成本低功耗光互连方案，用于降低光模块的成本和功 耗，提升光互连的性价比。 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| LSB | 最低有效位 | Least Significant Bit，即最低有效位，是二进制数中最 右边的一位，权重最小。 |
| MCM | 多芯片封装模组技术 | Multi-Chip Module，将多个芯片集成在同一个封装内的 技术，提升芯片的集成度，减少芯片间的连接距离，提 升性能。 |
| Memory Region | 内存区域 | RDMA 中提前注册到 RDMA 网卡的内存缓冲区，拥有 对应的本地密钥（local key），是 RDMA 操作内存的 基础 |
| MEMS | 微机电系统 | Micro-Electro-Mechanical Systems，光电路交换机 （OCS）的核心技术 |
| MESI | MESI 协议 | 经典的硬件级缓存一致性协议，通过确认和修改 Cache Line 状态实现缓存一致性，存在多次 Cache 端交互，大 规模场景下存在同步开销 |
| MLAP | Maximum Length of Aggregated Packet | 聚合包长上限 |
| MMIO | 内存映射 I/O | 内存映射 I/O（Memory-Mapped I/O），一种将 I/O 设 备地址映射到系统内存地址空间的技术，使处理器可通 过访问内存的方式操作 I/O 设备 |
| MMU | 内存管理单元 | 负责地址转换的硬件单元，可实现 GVA、NPA、SPA 之 间的地址转换，是实现全局内存访问的关键 |
| MNSP | 成员报文数量上限 | 成员报文数量上限（Maximum Number of Sub-packets），指一个聚合数据包中可包含的成员报 文的最大数量 |
| MoE | 混合专家系统（混合 专家模型） | 混合专家系统（混合专家模型，Mixture of Experts）， 一种稀疏大模型架构，通过多个“专家”模块分工处理不同 任务，提升模型效率和性能 |
| MPI | 消息传递接口 | 定义集合通信标准接口规范的协议，起源于高性能计算 领域，为集合通信提供统一的接口标准 |
| MPS | 最大数据包尺寸 | 最大数据包尺寸（Maximum Payload Size），指一次 数据传输中可携带的最大有效数据量 |
| MQDU | 最大已使用队列深度 | 最大已使用队列深度（Maximum Queue Depth Used），指在数据传输过程中，队列中被使用的最大深 度值，反映队列的负载情况 |
| MSB | 最高有效位 | 最高有效位（Most Significant Bit），指一个二进制数 中最左边的一位，权重最大，代表2的（位数-1）次方 |
| MSHD | 最大单跳时延 | 最大单跳时延（Maximum Single-hop Delay），指数 据在网络中经过单个节点跳转时的最大延迟时间 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| MTU | 最大传输单元 | 最大传输单元（Maximum Transmission Unit），指数 据链路层中可传输的最大数据包大小（不包含链路层头 部），超过该尺寸的数据包需分片传输 |
| NCCL | 英伟达集合通信库 | NVIDIA 推出的针对 GPU 和网络优化的多 GPU、多节 点通信库，实现了高性能的集合通信和点对点通信原语， 支撑分布式 GPU 计算 |
| ncclComm | NCCL 通信器对象 | NCCL 中参与通信的每个 GPU 维护的通信器对象，是 调用 NCCL 所有通信操作的执行载体，需先初始化并定 义参与通信的 GPU 集合 |
| NCSI | 网络控制器侧带接口 | 网络控制器侧带接口（Network Controller Sideband Interface），用于在主处理器与网络控制器之间传输管 理和控制信息的辅助接口 |
| NIC | 网卡 | 网卡（Network Interface Card），又称网络适配器， 是计算机与网络之间进行数据交换的硬件设备，负责将 计算机数据转换为网络可传输的信号 |
| NoC | 片上网络 | 片上网络（Network on Chip），是在芯片内部实现多 个处理器核、内存控制器等模块之间通信的互连架构， 替代传统总线架构提升通信效率 |
| NPA | 网络物理地址 | 客户虚拟地址经本地 MMU 转换后的地址，在对端 MMU 中可进一步转换为本地系统物理地址 |
| NPM-Req | 非投递型组播操作 | 非投递型组播操作（Non-Posted Multicast Request），一种组播操作类型，发起方需要等待操作 完成的确认信号后才能继续后续操作 |
| NPM-Resp | 非投递型组播响应 | 非投递型组播响应（Non-Posted Multicast Response），是对非投递型组播操作的响应信号，用 于告知发起方操作已完成 |
| NPO | 近封装光学 | 近封装光学（Near packaged optics），一种将光模块 与芯片封装靠近放置的光互连技术，可减少信号损耗， 提升传输带宽和效率 |
| NPU | 神经网络处理器 | 神经网络处理器（Neural Processing Unit），专为神 经网络加速设计的 DSA 芯片，具备高并行度、高能效比， 适用于深度学习任务的快速运算 |
| NSP | 成员报文数量 | 成员报文数量（Number of Sub-packets），指一个聚 合数据包中实际包含的成员报文数量 |
| NTP | 网络时间协议服务器 | 网络时间协议服务器（Network Time Protocol Server），用于通过 NTP 协议为网络中的设备提供精 确的时间同步服务 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| NUMA | 非一致内存访问 | 非一致内存访问（Non-Uniform Memory Access）， 一种内存架构，处理器访问不同内存区域的延迟不同， 靠近处理器的内存访问速度更快 |
| NVLink | NVIDIA 高速互连总 线（英伟达私有AI互 联总线协议） | NVIDIA 开发的高速互连通信协议，采用点对点结构，用 于实现 CPU-GPU 及 GPU-GPU 间的高效互联，提供 超高带宽和缓存一致性，同时支持内存语义，是英伟达 私有AI互联总线协议 |
| NVLink Fusion | NVLink 融合技术 | 允许定制芯片（CPU/XPU）与 NVIDIA 的 NVLink scale-up 网络集成的技术，旨在实现半定制化的 AI 基 础设施部署，核心是“有控制的开放”。 |
| NVLink-C2C | NVLink 芯片到芯片 互连 | 基于 NVLink 协议的、用于芯片到芯片极近距离高速互 连的物理封装和连接技术。常用于构建“超级芯片”（如 Grace Hopper），提供统一缓存一致性内存空间。 |
| NVSwitch | NVLink 交换机 | 一种专用交换机技术，用于连接多个 NVLink GPU 服务 器，构建大型 Fabric 网络（NVLink 网络），解决多 GPU 间的高速通信带宽和效率问题。 |
| OAM | 开放加速器模块 | 开放加速器模块（Open Accelerator Module），一种 标准化的加速器模块规范，用于简化加速器与服务器的 集成和部署 |
| OCP | 开放计算项目 | 开放计算项目（Open Compute Project），致力于硬 件开源和标准化的组织，推动数据中心、服务器等硬件 的创新和普及 |
| OCS | 光电路交换机 | 光电路交换机（Optical Circuit Switch），Google TPU 集群使用的基于光路切换的交换设备，通过光信号直接 切换实现数据传输，具备低延迟、高带宽的特点 |
| ODCC | 开放数据中心委员会 | 开放数据中心委员会（Open Data Center Committee），推动数据中心标准化的组织，致力于制 定数据中心相关的技术标准和规范 |
| ODLS | 直接加载/存储 | 直接加载/存储（OISA Direct Load/Store），基于 OISA 架构的直接内存访问指令，可直接访问内存数据，简化 编程流程 |
| ODMA | OISA 直接内存访问 | OISA Direct Memory Access，OISA 架构中的直接内 存访问机制 |
| OISA | 全向智能感知高速互 联架构 | Omni-directional Intelligent Sensing Express Architecture（原Omnidirectional Intelligent Sensing Express Interconnect Architecture），中移动牵头的 互联标准，即全向智感互联相关架构 |
| OISA-SAI | OISA 交换芯片抽象 接口 | OISA Switch Abstract Interface，OISA 架构中交换 芯片的抽象接口规范 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| OM | OISA 管理器 | OISA Manager，负责管理 OISA 架构相关设备和协议 的管理模块 |
| OOB | 带外 | Out-of-Band，指不通过主数据通道进行的管理或通信 方式 |
| OPE | OISA 协议引擎 | OISA Protocol Engine，负责处理 OISA 协议的核心引 擎模块 |
| ORW | 开放机架(宽) | Open Rack Wide，一种机柜尺寸标准 |
| OS | 操作系统 | Operating System，管理计算机硬件与软件资源的计算 机程序 |
| OSFP | 八通道小型可插拔封 装 | Octal Small Form-factor Pluggable，一种高速光模块 封装标准 |
| P2P | 点对点 | Peer-to-Peer，指网络中节点之间直接进行通信，无 需通过中间节点转发的模式 |
| PAM4 | 四电平脉冲幅度调制 | 4 级脉冲幅度调制（Pulse Amplitude Modulation 4）， RoCE 物理层采用的编码方式，可在相同的带宽下传输 更多数据，支撑高速以太网传输；从 NVLink 4.0 开始使 用的信号编码方式，相比传统的 NRZ 编码，能在相同的 波特率下传输双倍的数据，实现带宽翻倍。 |
| PCB | 印制电路板 | Printed Circuit Board，电子元器件的支撑体，用于连 接各类电子元件 |
| PCH | 平台控制中枢 | Platform Controller Hub，负责连接 CPU 与外设，管 理 I/O 接口等功能的芯片 |
| PCIe | 外设组件互连标准 | Peripheral Component Interconnect Express，通用 的总线接口标准，计算机系统中核心的高速互联总线标 准，用于连接 CPU 与外设（GPU、固态硬盘、网卡等） 及各类加速器，实现数据高速传输。 |
| PCS | 物理编码子层 | Physical Coding Sublayer，负责数据编码和解码的物 理层子层 |
| PDB | 电源供电分配板 | Power Distribution Board, 一种将主电源高效率分配至 多个子系统组件的电路板 |
| PDU | 电源配电单元 | Power Distribution Unit, 一种专门为机柜内电子设备 （如服务器、交换机）供电的工业级插座，具备电流电 压监测、过载保护及模块化设计功能。 |
| PFC | 基于优先级的流控 | Priority-based Flow Control，IEEE 802.1Qbb 标准定 义的技术，为 RoCE 实现无损以太网的核心，当交换机 优先级队列缓冲区接近满载时，发送 PFC 帧通知上游暂 停发送对应流量，避免丢包 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| PL | 物理层 | Physical Layer，网络协议栈的最底层，负责处理物理 介质上的信号传输 |
| PLL | 锁相环 | Phase Locked Loop，一种用于同步信号频率和相位的 电路 |
| PMA | 物理介质连接层 | Physical Medium Attachment，负责物理介质连接的 物理层子层 |
| PMBus | 电源管理总线 | Power Management Bus，用于管理电源设备的串行 通信总线 |
| PMD | 物理介质相关层 | Physical Media Dependent，与具体物理介质相关的物 理层子层 |
| PN | 制造商部件号 | Part Number，制造商为每个产品分配的唯一部件标识 |
| POST | 加电自检 | Power-On Self-Test，计算机开机时自动进行的硬件 检测程序 |
| PP | 流水线并行 | Pipeline Parallelism，一种 AI 模型并行策略，将模型按 层拆分到不同设备，并行执行不同层的计算 |
| PRBS | 伪随机二进制序列 | Pseudorandom Binary Sequence，一种具有随机特 性的二进制序列，常用于通信系统测试 |
| PRI，Packet Rate Improvement | 报文速率提升 | 通过压缩以太网报文头部，增加帧传送效率的技术 |
| protocol data unit (PDU) | 协议数据单元 | SUE定义的协议封装单元名称 |
| PSU | 电源模块 | Power Supply Unit（原Power Distribution Unit表述有 误，修正为PSU标准定义），为电子设备提供稳定电源 的模块 |
| PUE | 电源使用效率 | Power Usage Effectiveness，衡量数据中心能效的指 标，计算方式为数据中心总耗电量与IT设备耗电量的比值 |
| PXI ，Peer-to-Peer AXI | 端到端的AXI总线 | 一种基于以太网的Scale up互联协议 |
| QoS | 服务质量 | Quality of Service，事务层的核心功能之一，为不同优 先级的事务分配带宽，保障高优先级事务的传输效率 |
| QP | 队列对 | InfiniBand 传输层的核心，由发送队列（SQ）和接收队 列（RQ）组成，是端到端消息隔离和可靠传输的基础， 需在通信两端初始化 |
| RAG | 检索增强生成 | Retrieval-Augmented Generation，大模型的一种应 用模式，通过检索外部知识来增强生成内容的准确性 |
| RAM | 随机存取存储器 | Random Access Memory，可随时读写数据的内存设 备，断电后数据丢失 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| RAS | 可靠性、可用性、可 维护性 | Reliability, Availability, Serviceability，衡量系统稳定性 和可维护性的三大核心指标 |
| RC | 根复合体 | Root Complex，PCIe 总线树的根节点，通常由 CPU 担 任，负责发起和管理 PCIe 总线上的事务 |
| R-CRC | 里德-所罗门循环冗 余校验 | 将RS编码和CRC编码融合的纠错技术，用于提升数据 传输的可靠性 |
| RDMA | 远程直接内存访问 | Remote Direct Memory Access，无需主机 CPU 参 与数据路径，应用程序可直接访问远程计算机虚拟内存 的技术，支持 Read/Write 单边操作和 Send/Recv 双 边操作，实现零拷贝通信 |
| Ring 算法 | 环形算法 | NCCL 中实现多 GPU 通信的基础算法，构建环形网络， 每个 GPU 仅与相邻两个邻居交换数据，适用于小规模 GPU 集群，设计简洁、对等性强 |
| RoCE | 基于融合以太网的 RDMA | RDMA over Converged Ethernet，基于以太网的 RDMA 技术，在以太网上承载 IB 协议，兼顾 InfiniBand 的性能与以太网的低成本，需无损以太网络支撑，分 RoCEv1 和 RoCEv2 |
| RQ | 接收队列 | 队列对（QP）的组成部分，用于存放待接收的工作请求 （WR），是 RDMA 接收数据的核心队列 |
| RR ARB ( Round-Robin Arbiter) | 轮询仲裁器 | 按固定顺序轮流服务每个请求源，每个源获得相同的服 务机会 |
| RTT | 往返时间 | Mirror Round Trip Time，数据从发送方发出到接收方 确认接收的总时间 |
| SA | 交换 Tray 管理代理 | Switch Management Agent，负责管理交换 Tray 设 备的代理模块 |
| SC | 子计算单元 | Sub Cores，处理器中的子计算模块，负责执行部分计 算任务 |
| SEL | 系统事件日志 | System Event Log，记录系统运行过程中各类事件的 日志文件 |
| SerDes | 串行器/解串行器 | Serializer/Deserializer，位于物理层的核心技术，将并 行数据转换为串行数据进行高速传输，支持多速率自适 应与极性/通道反转，用于减少电磁干扰（EMI）；高速 数据传输的接口电路技术 |
| SHARP | 可扩展分层聚合归约 协议 | CollNet 算法的基础协议，支持将数据聚合 / 归约操作卸 载到网络设备，减少 GPU 间直接通信需求 |
| SHM | 共享内存 | NCCL 节点内通信的传输方式之一，当直接 P2P 通信不 可用 / 性能不佳时，通过系统内存路由流量，利用 CPU 优化的 PCIe - 内存传输避免性能问题 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| Simple 协议 | 简单协议 | NCCL 的基础通信协议，实现简单，适用于无需特殊优 化的常规通信场景 |
| Snoop | 探听报文 | CXL 等协议中实现缓存一致性时的交互报文，用于确认 数据在各设备缓存中的状态，保证读取数据为最新 |
| SoC（System on Chip） | 片上系统 | 系统级芯片，将CPU、GPU、内存控制器等多种组件集 成在单一芯片上的集成电路 |
| SoIC | 系统整合芯片 | System on Integrated Chips，台积电的 3D 堆叠封装 技术 |
| SPA | 系统物理地址 | 对端设备的本地物理地址，由网络物理地址经对端 MMU 转换得到，用于访问对端本地内存 |
| SQ | 发送队列 | 队列对（QP）的组成部分，用于存放待发送的工作请求 （WR），是 RDMA 发送数据的核心队列 |
| SR-Req | Switch 归约读请求 | Switch Reduce Read Request，交换机发起的归约读 操作请求 |
| SR-Resp | Switch 归约读响应 | Switch Reduce Read Response，对 Switch 归约读 请求的响应报文 |
| SSH | 安全外壳协议 | Secure Shell，一种用于远程登录和数据传输的安全协 议 |
| SUE-T | Scale-Up 以太网传 输协议 | Scale-Up Ethernet Transport，博通主导的基于以太 网的互联协议 |
| sysfs | 系统文件系统 | Linux 系统中的虚拟文件系统，NCCL 通过该文件系统 获取 PCIe 设备层次结构、设备特性等拓扑信息 |
| TL | 事务层 | Transaction Layer，PCIe 协议栈中的一层，负责处理 事务请求和响应 |
| TLP | 事务层数据包 | Transaction Layer Packet，PCIe 事务层中，设备核 心的请求（存储器读写、I/O 操作等）被封装后的数据包， 用于在事务层与数据链路层间传输 |
| TOR | 架顶交换机 | Top of Rack，位于机柜顶部的交换机，用于连接机柜 内的服务器设备 |
| TP | 张量并行 | Tensor Parallelism，一种 AI 模型并行策略，将模型的 张量维度拆分到不同设备，并行执行计算 |
| TPU | 张量处理单元 | Tensor Processing Unit，Google 自研的 AI 专用芯 片，专为加速张量计算设计 |
| Tree 算法 | 树形算法 | NCCL 中的通信优化算法，常用双二叉树算法，利用二 叉树特性降低通信延迟（log2N < N），延迟性能优于 Ring 算法 |
| 术语 | 中文名称 | 解释/定义 |
|---|---|---|
| UALink | 一种AI高速互联协议 标准 | Ultra Accelerator Link，AMD、Intel 等发起的开放互 联标准 |
| UB | 统一总线 | Unified Bus，华为提出的互联架构概念 |
| UB-Mesh | 统一总线互联网络 | Unified Bus Mesh，华为发布的分层局部化网络拓扑架 构 |
| UEFI | 统一可扩展固件接口 | Unified Extensible Firmware Interface，用于替代 BIOS 的固件接口标准 |
| UMA | 统一内存寻址 | Uniform Memory Address，将不同内存区域映射到统 一地址空间的寻址方式 |
| UPS | 不间断电源 | Uninterruptible Power Supply，在电网断电时能为设 备提供临时供电的设备 |
| URMA | 异步内存访问 | 超节点上层应用的内存访问方式之一，可实现无阻塞的 远端内存访问操作 |
| UUID | 通用唯一识别码 | Universally Unique Identifier，用于唯一标识信息的 128位数字 |
| UVA | 统一虚拟地址 | 英伟达 NVLink 中实现的地址机制，将所有连接的 GPU 的本地内存、显存、CPU 内存映射到同一个虚拟地址空 间，支持直接的远端内存访问 |
| UVM | 统一虚拟内存 | 统一虚拟内存技术，允许 GPU 和 CPU 共享统一的内存 空间，使多个 GPU 可像访问本地内存一样访问远程 GPU 显存，减少数据拷贝开销。 |
| VC | 虚拟通道 | Virtual Channel，总线物理层 / 链路层的逻辑隔离机制， 在同一物理链路上划分的多个独立逻辑传输通道。 |
| VLAN | 虚拟局域网 | Virtual Local Area Network，将一个物理的局域网在 逻辑上划分成多个不同的广播域（子网）的技术 |
| VRM | 电压调节模块 | Voltage Regulator Module，为芯片供电的模块，负责 将输入电压转换为芯片所需的稳定电压 |
| WR | 工作请求 | RDMA 中提交到队列对（QP）的操作请求，网卡硬件 直接处理该请求，实现硬件卸载的零拷贝通信 |
| WRR ARB （Weight ARB） | 加权轮询仲裁器 | 在轮询基础上，为每个请求源分配权重Weight，权重越 高，获得的服务机会越多 |
本站所有资讯是用户利用其本地Agent获取并分享，均为公开信息，如需删除请联系我们。
