AI 超节点关键技术深度解析：从高速互连、内存访问到大模型并行执行

在上一篇《AI 超节点：为什么 AI 的竞争单位正从芯片变成机柜？》中，我们讨论了一个变化：大模型需要的计算能力越来越难由单颗芯片独立提供，竞争因而向机柜和系统延伸。

接下来的问题更加具体：数十颗、数百颗 GPU 或 NPU 究竟怎样协同工作？一条数据从计算核心出发，经过哪些模块，才能被另一颗芯片使用？为什么有的系统卡数增加了，模型却没有相应加速？

回答这些问题，需要把"高速互连""统一内存""集合通信""软硬协同"等术语拆开，落到真实的地址、数据、缓冲区、操作顺序和资源约束上。本文沿着一条连续的技术链展开：先看数据为什么需要跨卡，再看互连如何运输、远端内存如何访问、通信如何服务于矩阵计算，最后看运行时怎样调度、监控和恢复整个系统。

本文面向了解计算机体系结构或 AI 基础设施、但未必深入研究过互连协议和分布式模型执行的读者。涉及数学时，会先说明符号，再用小算例推演。供电和液冷放在系统约束中讨论，主要篇幅用于互连、内存、通信算法及软件。

资料核对截止日期：2026 年 10 月 16 日。本文以公开技术资料较完整的具体版本解释机制，例如 GB200 NVL72、2025 年 CloudMatrix384 论文，以及 UALink 200G 1.0 白皮书；这些案例用于讲原理，不代表截至该日期各厂商最新产品的完整清单。产品披露、论文测试和本文教学计算分别标明。文中 GB、TB 默认采用十进制，GiB、MiB 采用二进制；带宽标明单向或双向聚合。所有自绘图都是功能或教学示意，不冒充厂商未公开的物理实现。

文章目录

- 一、从一个模型算子出发，建立超节点的技术框架
- - [1.1 模型被切开之后，通信就成为计算的一部分](#1.1 模型被切开之后，通信就成为计算的一部分)
  - [1.2 超节点是一组能力的组合，不能用一个名词包办](#1.2 超节点是一组能力的组合，不能用一个名词包办)
  - [1.3 带宽之外，还要看启动时延、依赖深度和尾部](#1.3 带宽之外，还要看启动时延、依赖深度和尾部)
  - [1.4 用一组明确设定贯穿后文](#1.4 用一组明确设定贯穿后文)
- 二、高速互连的关键：协议、交换拓扑、流控与物理链路
- - [2.1 从一次跨卡读取看协议到底规定什么](#2.1 从一次跨卡读取看协议到底规定什么)
  - [2.2 PCIe、RDMA 与专用 scale-up 互连的分工](#2.2 PCIe、RDMA 与专用 scale-up 互连的分工)
  - [2.3 端口峰值、聚合带宽、对分带宽是三个不同指标](#2.3 端口峰值、聚合带宽、对分带宽是三个不同指标)
  - [2.4 全互连交换与全网直连具有不同的端口代价](#2.4 全互连交换与全网直连具有不同的端口代价)
  - [2.5 Clos、环面和高维直连：把成本放在不同地方](#2.5 Clos、环面和高维直连：把成本放在不同地方)
  - [2.6 信用流控保护缓冲区，但拥塞和死锁还要分别处理](#2.6 信用流控保护缓冲区，但拥塞和死锁还要分别处理)
  - [2.7 多路径需要在链路利用率与乱序成本之间取舍](#2.7 多路径需要在链路利用率与乱序成本之间取舍)
  - [2.8 SerDes、PAM4 与纠错：链路速率怎样变成可靠数据](#2.8 SerDes、PAM4 与纠错：链路速率怎样变成可靠数据)
  - [2.9 铜、光和光交换改变的不是同一件事](#2.9 铜、光和光交换改变的不是同一件事)
  - [2.10 UALink 用于理解开放互连的分层边界](#2.10 UALink 用于理解开放互连的分层边界)
- 三、从"内存可以连起来"到"数据能被正确使用"
- - [3.1 HBM 的高带宽首先来自封装内的宽接口](#3.1 HBM 的高带宽首先来自封装内的宽接口)
  - [3.2 统一地址、统一内存、共享内存与池化各指什么](#3.2 统一地址、统一内存、共享内存与池化各指什么)
  - [3.3 远端内存访问必须经过地址翻译和权限边界](#3.3 远端内存访问必须经过地址翻译和权限边界)
  - [3.4 load/store、DMA 与 put/get 是不同的操作组织方式](#3.4 load/store、DMA 与 put/get 是不同的操作组织方式)
  - [3.5 远端读取需要足够的并发窗口](#3.5 远端读取需要足够的并发窗口)
  - [3.6 缓存一致性与内存顺序分别解决什么](#3.6 缓存一致性与内存顺序分别解决什么)
  - [3.7 内存池化的真正收益来自放置、复用和容量管理](#3.7 内存池化的真正收益来自放置、复用和容量管理)
  - [3.8 KV 缓存容量怎样计算，超节点改变了哪一部分](#3.8 KV 缓存容量怎样计算，超节点改变了哪一部分)
  - [3.9 CXL 扩展内存能力，与加速器高速域怎样配合](#3.9 CXL 扩展内存能力，与加速器高速域怎样配合)
- 四、集合通信与模型并行：数据交换怎样完成真正的计算
- - [4.1 先区分五种经常混用的通信操作](#4.1 先区分五种经常混用的通信操作)
  - [4.2 用四个数组完整理解 AllReduce](#4.2 用四个数组完整理解 AllReduce)
  - [4.3 树、分层算法和网络内归约各减少什么](#4.3 树、分层算法和网络内归约各减少什么)
  - [4.4 读懂 algbw 和 busbw，避免带宽比较失真](#4.4 读懂 algbw 和 busbw，避免带宽比较失真)
  - [4.5 数据并行与 ZeRO：复制减少后，通信会发生变化](#4.5 数据并行与 ZeRO：复制减少后，通信会发生变化)
  - [4.6 张量并行：用两层 MLP 看清切分与归约](#4.6 张量并行：用两层 MLP 看清切分与归约)
  - [4.7 张量并行度为什么存在收益拐点](#4.7 张量并行度为什么存在收益拐点)
  - [4.8 MoE 专家并行：token 怎样找到专家并返回](#4.8 MoE 专家并行：token 怎样找到专家并返回)
  - [4.9 把 MoE 的通信量逐项算清楚](#4.9 把 MoE 的通信量逐项算清楚)
  - [4.10 专家负载不均衡为什么能拖慢所有卡](#4.10 专家负载不均衡为什么能拖慢所有卡)
  - [4.11 流水线并行：阶段交接与空泡来自不同原因](#4.11 流水线并行：阶段交接与空泡来自不同原因)
  - [4.12 长上下文并行：为什么 K、V 要跨分片交换](#4.12 长上下文并行：为什么 K、V 要跨分片交换)
  - [4.13 用可复算例子解释分块 softmax 合并](#4.13 用可复算例子解释分块 softmax 合并)
  - [4.14 通信与计算重叠：从时间线判断收益](#4.14 通信与计算重叠：从时间线判断收益)
  - [4.15 通信压缩：少传一半数据，还要核对缩放与转换成本](#4.15 通信压缩：少传一半数据，还要核对缩放与转换成本)
- 五、软件与运行时：把互连能力变成训练效率和推理服务
- - [5.1 软件栈的工作是把模型依赖落实到资源](#5.1 软件栈的工作是把模型依赖落实到资源)
  - [5.2 拓扑感知首先是正确的 rank 放置](#5.2 拓扑感知首先是正确的 rank 放置)
  - [5.3 通信库选择的不只是 ring 或 tree](#5.3 通信库选择的不只是 ring 或 tree)
  - [5.4 GPU 主动通信减少了哪些往返](#5.4 GPU 主动通信减少了哪些往返)
  - [5.5 算子融合与通信融合需要满足数据依赖](#5.5 算子融合与通信融合需要满足数据依赖)
  - [5.6 Prefill 与 Decode 的资源特征为什么不同](#5.6 Prefill 与 Decode 的资源特征为什么不同)
  - [5.7 PD 分离把执行干扰换成显式 KV 交接](#5.7 PD 分离把执行干扰换成显式 KV 交接)
  - [5.8 连续批处理与缓存调度是同一个容量问题的两面](#5.8 连续批处理与缓存调度是同一个容量问题的两面)
  - [5.9 隔离既包括地址，也包括共享带宽与故障](#5.9 隔离既包括地址，也包括共享带宽与故障)
  - [5.10 容错不能停留在链路重传](#5.10 容错不能停留在链路重传)
  - [5.11 检查点频率是一个可计算的取舍](#5.11 检查点频率是一个可计算的取舍)
  - [5.12 从现象到原因的一条排查路径](#5.12 从现象到原因的一条排查路径)
- 六、把关键技术放回完整系统：案例、工程边界与性能判断
- - [6.1 NVL72 展示的是柜级互连与软件管理的组合](#6.1 NVL72 展示的是柜级互连与软件管理的组合)
  - [6.2 CloudMatrix384 的七子平面结构可以直接做带宽守恒检查](#6.2 CloudMatrix384 的七子平面结构可以直接做带宽守恒检查)
  - [6.3 UB 规范、UB-Mesh 与具体产品应保持边界](#6.3 UB 规范、UB-Mesh 与具体产品应保持边界)
  - [6.4 开放互连真正需要互操作的层次](#6.4 开放互连真正需要互操作的层次)
  - [6.5 供电为什么是持续性能的一部分](#6.5 供电为什么是持续性能的一部分)
  - [6.6 冷板、CDU 与设施回路怎样传走热量](#6.6 冷板、CDU 与设施回路怎样传走热量)
  - [6.7 电、热、网络会通过同步把局部问题放大](#6.7 电、热、网络会通过同步把局部问题放大)
  - [6.8 用三条带宽屋顶判断程序可能受限在哪里](#6.8 用三条带宽屋顶判断程序可能受限在哪里)
  - [6.9 为什么提高十倍互连带宽，模型可能只快一小部分](#6.9 为什么提高十倍互连带宽，模型可能只快一小部分)
  - [6.10 一套能复现的性能验证应分层进行](#6.10 一套能复现的性能验证应分层进行)
  - [6.11 把一个 MoE 层从路由到完成重新连起来](#6.11 把一个 MoE 层从路由到完成重新连起来)
  - [6.12 技术结论：超节点扩大的是高效协作的可选空间](#6.12 技术结论：超节点扩大的是高效协作的可选空间)

一、从一个模型算子出发，建立超节点的技术框架

1.1 模型被切开之后，通信就成为计算的一部分

先看最常见的矩阵乘：

Y = X W Y=XW Y=XW

设输入 X X X 的形状为 m × h m\times h m×h，权重 W W W 的形状为 h × n h\times n h×n，结果 Y Y Y 的形状为 m × n m\times n m×n。 m m m 可以理解为这一次算子一起处理的 token 数， h h h、 n n n 是输入和输出的特征维度。采用通常的计数方法，一次乘法和一次加法各算一个浮点运算，计算量约为 2 m h n 2mhn 2mhn FLOPs。

当 W W W 放不进一颗芯片的显存，或者希望多颗芯片一起完成计算时，需要切分这个矩阵。

如果沿输出维度切开，令 W = $W 0 W 1$ W= $W_0\\;W_1$ W= $W0W1$ ，两颗芯片可以分别计算 Y 0 = X W 0 Y_0=XW_0 Y0=XW0 和 Y 1 = X W 1 Y_1=XW_1 Y1=XW1。它们都需要同一份 X X X，各自产生一半输出。如果后续算子能继续使用分片结果，就暂时无需收集；如果后续算子需要完整 Y Y Y，就要把两份输出拼起来。

如果沿输入维度切开，则把 X = $X 0 X 1$ X= $X_0\\;X_1$ X= $X0X1$ ，同时将 W W W 按行分成 W 0 W_0 W0、 W 1 W_1 W1。两颗芯片计算的结果具有相同形状，但都是部分和：

Y = X 0 W 0 + X 1 W 1 Y=X_0W_0+X_1W_1 Y=X0W0+X1W1

这一次，完成矩阵乘的最后一步是跨卡求和。即使每颗芯片内部的乘加都算完了，未收到另一颗芯片的部分和，后续算子仍可能无法开始。

这就是超节点需要解决的核心依赖：分布式计算产生的通信往往位于算子的完成路径上。如果通信依赖没有改善，缩短本地计算可能让等待在总时间中更加突出。

通信的性质还取决于切分方式。拼接输出、求和部分结果、把不同 token 发给不同专家，分别对应不同的通信操作。不能只用"每卡带宽很大"解释所有模型性能，也不能把一种集合通信的优化收益直接推广给另一种。

1.2 超节点是一组能力的组合，不能用一个名词包办

本文把超节点理解为：通过高带宽、低时延互连，将多颗加速器组织成适合紧耦合协作的计算域。它可以跨计算板、服务器、机柜，具体边界由产品和部署决定。SuperNode、SuperPod、SuperPOD、NVLink domain 等名称在不同厂商材料中并不完全同义，判断能力应回到实际配置。

图1：从模型需求到物理互连的技术关系。作者绘制。图中层次表示依赖关系，不表示某一产品的完整软件分层。

从图1顶部向下读，可以把系统拆成四个相互连接的问题。

第一层是模型与服务：训练要更新哪些参数，推理要生成多少 token，需要怎样的响应时间。这里决定了任务的目标。

第二层是并行与通信：权重怎样切分，哪些芯片属于同一个通信组，何时需要求和、拼接、交换或同步。这里决定数据交换的对象、数量和时机。

第三层是访存与执行：数据放在哪块内存，远端地址怎样表达，通信使用哪些缓冲区，完成通知怎样让计算核安全读取结果。这里把数学依赖转成可以执行的操作。

第四层是互连与物理：数据经过哪些链路和交换芯片，出口是否拥塞，信号是否可靠，发送端是否有足够的并发事务。这里决定一次操作实际需要多久。

图右侧的供电、液冷和恢复系统贯穿所有层次。通信加速后，计算核可能更少等待、平均功率随之上升；温度导致某颗芯片降频，又会拖慢整个通信组。把这些因素放在同一框架中，才能理解"系统协同"究竟协同了什么。

有几个经常混在一起的能力，需要分别确认：

能力	实际回答的问题	不能由此直接推出什么
高速链路	一个端点能以多大速率发送或接收	所有端点同时发送都能达到同样速率
交换互连	哪些端点可达，经过什么路径	一定只有一个跳数，或一定没有收敛
统一虚拟地址	软件怎样表示和识别地址	数据自动搬到最近的位置
远端访存	某个执行者能否读写另一设备内存	远端访问与本地 HBM 同速
缓存一致性	多个缓存副本如何保持约定的一致视图	程序没有数据竞争，或不再需要同步
集合通信加速	某类多参与者操作怎样被高效执行	任意通信都可由交换芯片完成
资源池化	内存、计算或网络资源能否被组合分配	物理位置与故障边界消失

"像一块大 GPU"适合表达协同目标。研究实现时，还要追问：像到哪一层？是一个逻辑任务、一个通信域、一个地址空间，还是一个缓存一致性域？这些问题的答案可以不同。

1.3 带宽之外，还要看启动时延、依赖深度和尾部

最简单的一次通信模型是：

T ≈ α + M B T\approx\alpha+\frac{M}{B} T≈α+BM

M M M 为消息有效字节数， B B B 为该路径的有效单向带宽， α \alpha α 汇总软件发起、协议处理、交换与传播等固定开销。这个模型忽略拥塞、重传和其他资源竞争，但能解释两种很不一样的情况。

教学设定 α = 2 μ s \alpha=2\ \mu s α=2 μs、 B = 400 G B / s B=400\ GB/s B=400 GB/s。发送 4 kB（4000 字节）数据时， M / B = 0.01 μ s M/B=0.01\ \mu s M/B=0.01 μs，总时间约 2.01 μ s 2.01\ \mu s 2.01 μs。即使带宽翻倍，总时间也只减少 0.005 μ s 0.005\ \mu s 0.005 μs。瓶颈主要在启动和依赖。

发送 400 MB 时， M / B = 1 m s M/B=1\ ms M/B=1 ms，启动时延只占很小一部分。此时翻倍有效带宽，才可能接近减半传输时间。两个例子使用同一条链路，却分别处在时延主导区和带宽主导区。

图2：依据本文教学模型绘制。横轴为消息大小，单位字节；纵轴为微秒。曲线不是产品测试。

图2蓝线在左侧近似水平，表示消息再小，也要支付固定开销。右侧逐渐与绿色虚线接近，表示有效负载传输开始主导。橙色竖线位于 M = α B = 800 k B M=\alpha B=800\ kB M=αB=800 kB，此时固定开销与序列化时间相等。这个转折量级随协议、软件与设备变化。

对于多个依次发生的通信，不能只把总字节数除以带宽。例如 80 层模型中，每层都要等待一次 5 微秒的同步，即使每次数据极小，仅这一条不可重叠的依赖链也有约 400 微秒。大批量训练可能容易摊薄这部分时间，小批量、低时延解码则可能很敏感。

集合通信还有尾部效应。如果一个阶段必须等待所有 rank 完成，其时间近似由最慢者决定：

T p h a s e ≈ max ⁡ i T i T_{\mathrm{phase}}\approx\max_i T_i Tphase≈imaxTi

rank 是参与分布式任务的逻辑进程或执行成员编号，不必等于物理卡编号。某个 rank 遇到热点专家、链路重试或降频，都会把整个阶段的完成时间向后推。平均端口利用率很好，不代表尾部没有问题。

1.4 用一组明确设定贯穿后文

为了避免不同章节不断改变口径，本文采用以下教学系统。它不对应一款具体产品，也不承担产品性能预测。

设定项	数值或约定
紧耦合计算域	64 个逻辑 rank，每个 rank 暂按一颗加速器理解
模型隐藏维度	h = 8192 h=8192 h=8192
激活数据格式	BF16，每元素 2 字节
某 MoE 层的本地输入	每 rank 4096 个 token
路由	每 token 选择 2 个专家，教学计算假设都需跨 rank
比较的有效单向带宽	路径 A 为 400 GB/s，路径 B 为 50 GB/s
需要单独说明的因素	专家分布、TP/EP 组合、反向传播、量化、拥塞和重叠

一个 token 的隐藏向量为 8192 × 2 = 16384 8192\times2=16384 8192×2=16384 字节，即 16 KiB。4096 个 token 合计 64 MiB。若每个 token 分别送给两个远端专家，Dispatch 的源端发送量就是 128 MiB。

注意这只是一次 MoE 层前向 Dispatch 的发送量。回传、反向、元数据和路由偏斜还没有计入，后文会逐项增加。这样得到的数字比一句"每步通信若干 GB"更有用，因为读者知道哪些事件被计算过，哪些还没有。

二、高速互连的关键：协议、交换拓扑、流控与物理链路

2.1 从一次跨卡读取看协议到底规定什么

假设 GPU A 要读取 GPU B 显存中的一段数据。把操作写成 value = *remote_pointer 很简短，但硬件需要完成一条完整路径。

首先，A 侧要知道这个虚拟地址对应 B 的哪一段受授权内存。地址翻译或通信窗口映射把软件标识转换成端点与目标地址。其次，A 的互连接口构造请求，其中至少需要表达操作类型、目标位置、访问大小，以及将响应与请求对应起来的标识。

请求经过路由和交换，到达 B 侧控制器。B 检查访问权限与资源状态，向内存系统发起读取，取得数据后返回响应。A 再根据事务标识把返回数据交给原先等待它的执行者，完成相关依赖。

这里的"协议"回答的远不止信号速率：读写怎样编码；是否支持原子操作；哪些操作保证顺序；发生错误时在哪一层重试；响应如何返回；发送端允许多少未完成请求；接收端如何防止缓冲区溢出；不同进程如何隔离。

远端写入又有不同的路径。写数据通常随请求向目标发送，有的协议还需要完成响应。发送调用返回、源缓冲区可复用、目标内存写入完成、目标计算核能够观察到更新，是不同的事件。实现可以让部分事件重合，但软件不能未经确认就把它们当成一回事。

理解这些事件，才能继续讨论 DMA、put/get、load/store 和 GPU 主动通信。否则"直访""零拷贝"很容易只剩宣传层面的直觉。

2.2 PCIe、RDMA 与专用 scale-up 互连的分工

PCIe 采用内存映射 I/O 和事务层数据包，并不是只能做消息传递。在硬件、交换结构、地址映射、驱动与安全配置支持时，GPU 可以通过 PCIe 进行 P2P 访问；同一 PCIe 交换芯片下的设备间流量，也不必一律经过 CPU 核心或主机 DRAM。CUDA 的 P2P 与 GPUDirect RDMA 文档明确讨论了平台拓扑和映射条件。参见 CUDA 编程指南与 GPUDirect RDMA 文档。

PCIe 在超节点语境下的约束，主要是每颗加速器可用的 I/O 带宽、共享上行和跨根路径、平台实现及 P2P 支持范围，而不能简化成"无法直接寻址"。PCIe 5.0 x16 的编码后单向理论上限约为：

32 × 10 9 × 16 × 128 130 ÷ 8 ≈ 63.0 G B / s 32\times10^9\times16\times\frac{128}{130}\div8 \approx63.0\ GB/s 32×109×16×130128÷8≈63.0 GB/s

这还没有扣除事务头、流控和访问模式造成的损耗。这个推算说明接口量级，也说明为什么需要分清编码速率与应用有效数据率。

RDMA 则是一组远程直接内存访问机制，常由网卡把已注册内存之间的数据传输卸载到硬件。软件事先准备通信对象、地址或 key、队列和缓冲区，数据面可以绕过传统 CPU 逐字节搬运。GPUDirect RDMA 进一步让受支持的网卡直接访问 GPU 内存，避免必须在主机 DRAM 暂存一份。GPUDirect RDMA 设计与约束。

因此，RDMA 的"远程内存访问"与处理器执行远端 load/store 不是同一层概念。RDMA 经常通过队列描述符表达批量传输，完成关系由通信接口规定；load/store 则更贴近执行核的访存指令和依赖模型。两者都需要地址、权限、完成和错误处理，区别在于由谁发起、传输粒度怎样组织、怎样与计算执行衔接。

专用 scale-up 互连把更多芯片引脚、链路、交换资源和协议设计集中于加速器协作。NVLink、UB、UALink 的能力和实现并不相同，但共同关注低时延、高带宽及适合紧耦合任务的数据操作。它们与域外 RDMA 网络可以同时存在；域内承担频繁通信，域外继续连接更大集群。

2.3 端口峰值、聚合带宽、对分带宽是三个不同指标

假设一颗芯片有 p p p 个互连端口，每个端口单向带宽为 b b b，则它的单向注入带宽上限为：

B i n j = p b B_{\mathrm{inj}}=pb Binj=pb

如果发送和接收方向可同时工作、各自速率相同，双向聚合可以写成 2 p b 2pb 2pb。这不是一份数据沿一个方向传输时能使用的速率。

NVIDIA 对 Blackwell/Blackwell Ultra 的公开说明给出，每 GPU 第五代 NVLink 双向带宽为 1.8 TB/s，来自 18 条各 100 GB/s 双向链路；换成方向对称的发送上限，是约 900 GB/s。这个数字是芯片接口能力，实际业务还要扣除协议、访问模式、交换和同步开销。NVIDIA Blackwell Ultra 技术说明。

将 72 颗 GPU 的 1.8 TB/s 相加，会得到 129.6 TB/s，常以约 130 TB/s 表述。它是整域端点带宽的聚合口径。若 A 向 B 发送一份数据，同时把 A 的发送与 B 的接收相加，就对同一份数据进行了两端计数。它不能被解释为"一次单向跨柜传输可用 130 TB/s"。GB200 NVL72 产品页。

对分带宽则回答另一个问题：将整个网络切成两组规模相同或尽量接近的端点，取允许的这类切分中最小的跨区带宽。统计时还必须说明单向还是双向；具体一条切面的容量，不一定就是全网络的对分带宽。它更接近检查大规模集体流量时会遇到的切面约束。

图3：8 端点两层交换教学拓扑。作者绘制，所有带宽均为单向有效能力的设定值。

图3中，左侧四颗 GPU 各有 100 GB/s 接入，合计 400 GB/s；它们的叶交换机向上只有 200 GB/s。右侧同样如此。如果 GPU 0 只向 GPU 4 发送，单对端测试可能达到 100 GB/s。若左侧四颗同时向右侧四颗发送，每颗仍想要 100 GB/s，跨区总需求就达到 400 GB/s，超过上行能力。

假设公平分配且没有其他损耗，每颗大致只能得到 50 GB/s。网络是连通的，单对端测试也是快的，但跨区有 2∶1 收敛。

因此，判断"无阻塞"要说明流量模型与端口配置。足额上行、内部交换容量、路由与调度都需要满足条件；全体端点都向同一个目标发送时，目标端口仍然只有自己的接收能力。任何拓扑都不能突破这一条。

2.4 全互连交换与全网直连具有不同的端口代价

如果 N N N 个端点两两直接连线，需要 N ( N − 1 ) / 2 N(N-1)/2 N(N−1)/2 条点对点连接，每个端点要为其余 N − 1 N-1 N−1 个端点安排端口。规模增大后，引脚、连接器、线缆与走线空间都会承受压力。

交换网络让端点先接到交换芯片，由交换结构转发到目标。端点不必为每个对端配一根专属直连线。所谓"全互联"有时指通过交换网络实现全对全可达，而不是每对 GPU 之间都有一束独占物理线。

NVL72 就应从交换互联理解。NVIDIA 的系统资料列出 18 个计算托盘，每托盘 4 颗 GPU，以及 9 个 NVLink 交换托盘。计算托盘、交换托盘、交换 ASIC、NVLink 逻辑链路、铜缆差分通道，是不同层级的对象，不能把它们的数量直接互换。NVL72 系统结构。

交换芯片内部也不是一个无限大的"转盘"。输入端收到分组后，需要识别目标出口，在内部互连上分配资源，并安排输出。当多个输入争用同一出口时，必须排队或仲裁。端口总速率、内部交换能力和缓冲结构共同决定拥塞下的行为。

一种经典问题是队头阻塞：某输入队列的第一个分组要去拥塞出口，后面本可发往空闲出口的分组也被挡住。按目标出口设置独立队列、使用虚拟输出队列等方法，可以减少这类阻塞，但还需要仲裁保证公平和前进性。这里描述的是通用交换设计原理，不表示所有厂商采用同一种内部队列实现。

多平面设计则把总带宽分散到多套并行资源。端点可把流量条带化到若干平面，既增加容量，也提供部分冗余。它要求软件或协议分配流量并处理可能出现的乱序；某个平面故障后，剩余带宽和路径也必须重新计算。

2.5 Clos、环面和高维直连：把成本放在不同地方

多级 Clos 网络通过叶交换与汇聚交换提供多条路径。其优势是扩展方式清楚，足额配置时能够支持广泛的流量模式；代价是交换端口、跨层链路和物理布线数量较多。

环面网络则让每个节点只连接若干邻居。例如二维环面每个节点沿两个维度分别连接正反方向邻居。端口数量较少、结构规则，但远端通信可能经过多跳。规模增加后，某些切面的链路数未必跟得上端点数，适合规则近邻流量的拓扑不一定适合任意 All-to-All。

高维 FullMesh 的思路，是在每个维度内让节点形成更密集的直连关系，再通过多个维度到达全网。一个教学性的二维 4 × 4 4\times4 4×4 结构中，坐标为 ( x , y ) (x,y) (x,y) 的节点连接所有同一行与同一列节点，每节点需要 3 + 3 = 6 3+3=6 3+3=6 个邻接方向，任意两节点可以先改一个坐标再改另一个坐标，至多两跳。它并不是 16 节点的全网两两直连，后者每节点需要 15 个邻接方向。

这种设计把"全互连"局限在各维度内，降低了全局直连的端口需求。若不同维度分配不同带宽，就可以给板内、柜内的频繁通信更多资源，给远距离低频通信较少资源。收益以任务具有适合的局部性为前提；任意流量强行跨越较弱维度，仍会遇到瓶颈。

华为 UB-Mesh 论文采用分层局部化的 nD-FullMesh，并讨论拓扑感知的并行映射和通信。需要注意，UB 是互连协议体系，UB-Mesh 是一种网络架构；CloudMatrix384 论文披露的具体交换结构，也不能直接等同于 UB-Mesh 论文中的所有拓扑设计。 UB-Mesh 论文 §3---5。

算法与拓扑应一起看。环形归约可以利用规则邻接，高维全对全交换需要合适的维度调度，TP 组适合放在带宽高且路径短的局部域。拓扑没有脱离工作负载的绝对优劣，关键是模型产生的通信矩阵与网络能力是否匹配。

2.6 信用流控保护缓冲区，但拥塞和死锁还要分别处理

如果发送端持续把数据推向接收端，而后者来不及处理，接收缓冲区最终会满。信用流控用一种明确的配额告诉上游：你还可以发送多少数据。

图4：4 槽位信用流控教学模型。作者绘制，实际协议的计量单位和返还粒度依规范而定。

假设图4的接收端有 4 个槽位，每个槽位能存放 64 字节。建立链路时，发送端获得 4 个 credit。每发送一个 64 字节单元，credit 减 1。接收端把一个单元消费掉或转发走，释放槽位，再向发送端返还一个 credit。

若发送端连续发出四个单元而没有收到返还，它就必须停下来。这样能够保证接收端不会因为上游毫无限制地发送而被冲垮。

链路往返越长，要持续满速运行所需的在途数据就越多。粗略地说，发送窗口或可用信用所覆盖的数据量，至少需要接近带宽时延积：

W ≳ B × R T T W\gtrsim B\times RTT W≳B×RTT

对逐跳信用流控，这里的 R T T RTT RTT 是消耗信用到相应信用返还的控制周期，不是任意端到端访存的往返时延。设 B = 100 G B / s B=100\ GB/s B=100 GB/s、信用返还周期为 1 μ s 1\ \mu s 1 μs，仅维持流水就需要约 100 kB 在途能力。若每个信用只覆盖 64 B，数量级约为 1563 个信用。这不是具体协议的缓冲要求，而是说明：即使链路标称很快，窗口太小仍会因等待信用而跑不满。

信用流控并没有消除热点。若很多源持续向一个目标写入，目标出口处理不过来，反压会逐级向上游传播。源端限速、调度、公平性和负载均衡仍然需要解决。

还有更难的问题：循环等待。A 占着 B 需要的缓冲区，B 占着 C 需要的缓冲区，C 又占着 A 需要的资源，所有人都在等下一跳返还信用。即使没有任何分组丢失，也可能无法前进。

虚通道可以把不同资源类别分开。例如请求和响应分开排队，避免大量请求占满全部缓冲，导致完成这些请求所需的响应无处可走。但"有虚通道"不自动保证无死锁，还要给出无环的通道依赖、维度顺序或可保证前进的逃逸路径。UB-Mesh 论文的流控讨论就把路由和通道依赖放在一起。UB-Mesh 论文 §4.1.3。

2.7 多路径需要在链路利用率与乱序成本之间取舍

当两端之间有多条等价路径，始终让一个大流走同一路径，可能造成某条链路很忙、其他链路空闲。按流分配路径能够维持流内顺序，但流数量少、大小悬殊时，哈希并不一定均衡。

按包或细粒度分片分散到多条路径，更容易利用全部链路，却会引入到达乱序。若第三个分片先到、第二个仍在另一条拥塞路径上，接收端必须知道哪些数据已经到达，哪些还缺失，以及何时能对上层宣布整个操作完成。

这需要重排缓冲、序号、完成位图或类似机制；具体形式因协议而异。重排资源不足会再次触发反压。若一味追求严格全序，快路径又可能被慢路径拖住。协议常会选择只对真正需要顺序的对象提供约束，例如同一地址上的操作，或同一通信通道内的特定事务。

因此，"负载均衡"不是一个独立开关，而是源端分配、交换路由、接收重排和完成判定的组合。Ultra Ethernet 的演进也把拥塞管理和面向 AI 的传输行为作为重要内容；它与 UALink 在目标层次上有重叠与分工，不能因为名字里都有 Ethernet 就视为同一种协议。UEC 官方技术说明。

2.8 SerDes、PAM4 与纠错：链路速率怎样变成可靠数据

上层协议生成的是数据单元，物理线上传播的是电信号或光信号。SerDes 即串行器与解串器，把芯片内部较宽、较低频的并行数据转换为高速串行信号，并在另一端恢复。

图5：高速链路的功能路径。作者绘制。CRC、重传与 FEC 的实际分层位置以具体协议为准。

图5从左到右依次出现分组、校验与重传管理、FEC 编码、发送、物理信道、接收均衡与时钟恢复、解码和校验。虽然实际芯片会合并或细分这些模块，但每一步都承担明确功能。

NRZ 用两个电平表示一位；PAM4 用四个电平，每个符号携带两位信息。在相近符号速率下，PAM4 可以提供更高比特率。然而同一摆幅中分出四个电平，相邻电平间隔更小，接收端区分信号的噪声裕量也更小。

铜线和 PCB 不是理想导体。高频损耗使快速变化的成分衰减，前一个符号的影响可能延伸到后一个符号，形成码间干扰；连接器、过孔和阻抗不连续又会产生反射；相邻线路之间还会串扰。

发送端预加重或前馈均衡，可以预先补偿部分频率响应；接收端均衡和时钟恢复，尝试从受损波形中恢复符号。速率继续提升时，均衡复杂度、模拟前端、DSP 功耗和封装走线要求都会增加。Synopsys 的高速接口资料讨论了 PAM4、均衡和 FEC 等设计关系。224G SerDes 技术资料。

CRC 主要用于发现数据错误；FEC 增加冗余编码，使接收端能够纠正一定范围内的错误；链路重传则在检测到不能接受的错误后，重新发送相应单元。三者解决的问题不同。

FEC 降低误码对上层的影响，但需要额外比特、编码解码电路和处理时间。轻量 FEC 可以减少部分开销，却要求信道本身提供更好的误码条件。不能脱离信道质量宣称"去掉 FEC 就能同时更快、更省电、更可靠"。

如果一条链路以 10 12 10^{12} 1012 bit/s 传输，原始误码率为 10 − 12 10^{-12} 10−12，按简单独立模型估算，平均每秒仍可能出现一个原始错误比特。随着系统链路数增加，系统级错误事件会累积。这个教学计算说明为什么误码、纠错、重传和监控必须成为设计的一部分，而不是意味着产品每秒都会出现应用可见错误。

2.9 铜、光和光交换改变的不是同一件事

无源铜缆在较短距离上可以省掉光电转换器件，结构相对直接。但能走多远，取决于速率、线规、信道损耗、连接器、均衡与误码预算，不能给所有代际规定一个固定米数。

AEC 在铜缆端部加入有源重定时或相关处理，帮助恢复信号、延长可用距离。它需要供电，也引入额外器件、热量和时延。有源铜缆不是把距离约束彻底消除，而是在成本、功耗与布线之间换取空间。

光模块把电信号变成光，光纤更适合较远距离传输，物理布线也可能更轻。但模块端的驱动、激光器、光电接收与可能存在的 DSP 都要占用功耗和空间。距离短、端口数量巨大时，光电转换的系统代价尤其需要计算。

这里要区分两条技术轴。LPO（Linear Pluggable Optics，线性可插拔光模块）主要改变模块的信号处理架构：保留可插拔形态，去掉模块内传统 DSP/重定时环节，依赖主机侧均衡与端到端线性通道设计。NPO、CPO 主要讨论光引擎靠近芯片或与芯片共封装的集成位置，以缩短高速电气路径；具体封装边界依实现而定。线性驱动与集成位置可以组合，不能把三者当作同一条位置演进阶梯。LPO MSA 官方问答、OIF 共封装框架。

这些光互连路线不能直接替代上层的地址语义、路由和通信算法。即使光引擎紧靠芯片，MoE token 仍需要被路由到正确专家，完成通知仍需要正确同步。

光电路交换 OCS 又是另一层：它可以配置端点之间的光路连接，使某些物理邻接关系可重构。光路建立后，数据沿该路径传播；是否逐包检查和处理数据，则与分组交换不同。重构所需时间、端口粒度和可实现的连接模式，决定它更适合在任务或较粗粒度阶段调整，还是能够服务更细粒度的变化。

传输介质回答"信号怎样走"，交换方式回答"路径怎样连"，协议回答"操作怎样解释"。这三层可以组合，不能互相代替。

2.10 UALink 用于理解开放互连的分层边界

UALink 200G 1.0 的官方白皮书给出了清楚的分层：加速器协议接口、事务层、数据链路层与物理层。接口面向加速器的操作，事务层把它们组织成传输单元，链路层负责相邻节点之间的数据组织与可靠传送，物理层负责信号。UALink 200G 1.0 白皮书。

图6：UALink Consortium，Introducing UALink 200G 1.0 Specification，第4页 Figure 4。截取原图区域，保留原始标签；图片权利属于原发布者。

原图左侧是加速器，右侧是交换或加速器接口。先沿左侧向下读：功能层的操作通过 UPLI 进入事务层，变成 TL FLIT，再由链路层组织成 DL FLIT，经过物理层发送。右侧向上则是接收与解包路径。两端都能发送和接收，因此每侧各有向上、向下箭头。

中间的虚线标记层间接口，不是额外的三条外部数据线；真正串行连接画在底部。64B、640B、680B 是不同层传输单元的字节数，212.5G 是线路速率标记，两类数字不能相加或直接比较。图中"Ethernet PHY"只位于底层，也正好说明复用物理层不等于复用整套网络协议。

其中一个容易误读的点是：采用以太网物理层技术，不等于整个协议栈就是普通以太网 IP 网络。可复用的 SerDes、FEC 和信道技术，位于上层事务语义之下。

白皮书说明，一个 station 由四条 lane 构成，每个发送和接收方向的带宽可达 800 Gb/s，即每方向 100 GB/s；更高的线路信号速率用于覆盖 FEC 等开销。把 800 Gb/s 直接写成 800 GB/s，会放大八倍。把一个 station 的能力当成整颗加速器的能力，则遗漏了设备配置多少 station 这个前提。

再做一次量级检查：假设 1024 个端点，每端点只配置一个发送、接收各为 800 Gb/s 的 station，以下先统计发送方向，端点单向带宽求和是 1024 × 100 = 102400 G B / s 1024\times100=102400\ GB/s 1024×100=102400 GB/s，即 102.4 TB/s。双向端点求和为 204.8 TB/s。这个算例只检查单位，不代表某个真实 1024 卡系统的配置，更不等于实际应用有效吞吐。

版本也要明确。截至本文核对时，UALink 官网除 200G 1.0 外，还列出 Common 2.0、不同物理层规范和管理规范；官网说明 Common 2.0 引入网络内计算。解释 1.0 的事务机制时，不应把后续版本能力写成 1.0 原本就有，也不能把规范允许的最大规模当作已交付系统规模。UALink 官方规范目录。

到这里，互连已经具备传输操作的能力。接下来的关键是：远端地址究竟指向什么，数据能否被安全、有效地使用。

三、从"内存可以连起来"到"数据能被正确使用"

3.1 HBM 的高带宽首先来自封装内的宽接口

GPU 的本地 HBM 与其他 GPU 的 HBM，虽然都叫高带宽内存，访问路径却很不一样。

HBM 把多层 DRAM 芯片堆叠，通过堆叠内连接和封装互连接到计算芯片附近。相对于在较少引脚上不断提高频率，它采用很宽的接口提供高总带宽。多个堆栈、多个通道并行工作，内存控制器再把请求分散到这些资源上。

"HBM 带宽"通常是整颗芯片连接各堆栈、各通道的汇总能力。要接近它，程序必须提供足够并发、较好的访问合并与通道分布。大量线程只访问少量地址，或者访问跨步导致请求集中到同一资源，仍可能远低于规格值。

本地访问通常经过计算核心的缓存层次、片上互连和内存控制器。跨卡访问还要经过源端互连接口、外部链路、交换结构、目标端接口，再进入目标内存系统。后者多了一整条共享数据路径。

因此，把多颗芯片的 HBM 容量相加，可以描述总容量；把 HBM 带宽相加，只有当计算也分布在各自内存附近、所有局部访问能够同时进行时，才有相应的物理含义。一颗 GPU 不会因为能访问其他 63 颗 GPU，就自动获得 64 倍本地 HBM 带宽。

这决定了超节点的一项基本策略：让大部分计算靠近它反复使用的数据，把必须跨卡的内容组织成可并行、可批量、可预测的交换。

3.2 统一地址、统一内存、共享内存与池化各指什么

在普通单机程序中，指针通常足以表达某个对象的位置；跨设备后，问题变复杂了。同一个数值地址可能属于不同进程，不同设备也可能拥有各自的页表。

统一虚拟地址主要帮助软件在一个规定的地址体系中识别不同内存区域。它减少显式区分"这段数值属于主机还是设备"的麻烦，但不保证该地址对每个执行者都已映射，也不保证访问权限与物理可达性。

CUDA Unified Memory 是更具体的运行时和内存管理能力。它可以围绕受管理分配、页映射与迁移，让 CPU 和 GPU 在所支持的平台上访问数据。硬件一致性系统、软件管理系统、不同分配方式的行为并不相同。跨多个主机访问时，还要遵守相应通信库与内存交换机制的约束。CUDA Unified Memory 文档。

共享内存强调多个执行者可以访问某些共同的存储对象。但共享到哪一层，需要继续确认：是否共享虚拟地址？是否共享物理页？缓存如何处理？允许哪些原子操作？对象能否跨进程、跨操作系统导出？

资源池化则更多是资源组织和分配方式。例如把多个 CPU 节点的 DRAM 作为缓存服务的容量池，允许不同推理实例按需申请。这可以通过远端访问、显式搬运、服务接口或组合机制实现，不一定表现为所有 GPU 直接对同一大数组做普通 load/store。

用一个例子区分：系统把 1 TB 缓存空间分配给任务 A，A 通过缓存 API 申请若干 KV 块，这是池化；API 返回能被通信引擎使用的远端句柄，这是远端访问接口；句柄被映射成 GPU 虚拟地址，这是地址映射；GPU 读取到最新内容，还需要满足写入完成和同步约定。每一步解决不同问题。

3.3 远端内存访问必须经过地址翻译和权限边界

图7：本地 HBM、远端 HBM 与 CPU DRAM 的三条访问路径。作者绘制。图中假定所需映射与授权已经完成。

图7的第一条路径从 GPU 0 向下到本地 HBM。第二条路径先经过 GPU 0 的 MMU 与互连接口，再经 Fabric 到 GPU 1 的 HBM。第三条路径同样使用 Fabric，但目标变为 CPU 连接的 DRAM。

这三条路径可以向上提供相似的地址使用方式，但延迟、带宽、可缓存性和竞争关系不同。画在同一个地址图里，不意味着物理存储被搬到一起。

一次受控映射至少要回答四件事：

对象是谁的：哪一个进程或租户拥有这段内存，谁有权导出。
对象在哪里：对应哪个设备、哪一段物理内存或通信窗口。
允许什么操作：只读、读写、原子更新，以及访问范围。
有效到什么时候：对象释放、进程退出、设备故障时，映射怎样失效。

在基于 RDMA 的实现中，这些信息常与内存注册、key 和队列关联。在支持跨主机内存导入导出的系统中，还会有相应的句柄交换与域管理。NVIDIA 的 IMEX 服务就是多节点 NVLink 系统中需要理解的组件：NVLink 域可跨多个独立操作系统，不能把跨主机共享等同于单进程里拿到一个普通指针。NVLink IMEX 概述。

TLB 缓存地址翻译结果，能够避免每次访问都重新走页表。大量零散页面访问、映射频繁变化或工作集超出翻译缓存，会增加翻译成本。大页可以减少页表和 TLB 项的数量，但可能增加内部浪费、迁移粒度和分配约束。

地址也有生命周期。假设程序释放地址 0xA000 后，分配器又把同一地址交给新对象。如果通信系统仅缓存地址、不核对对象身份和有效期，就可能把旧注册错误地用于新对象。高性能通信库需要处理这种"地址数值相同、存储对象已改变"的情形。

这说明控制面虽然不逐字节搬运，却承担着数据面的安全与正确性基础。少了它，"直接访问"就没有可信的对象边界。

3.4 load/store、DMA 与 put/get 是不同的操作组织方式

直接 load/store 的优点，是能够和设备端计算紧密结合。线程算出一个索引后，可以发起远端读取，再使用返回值。若访问零散且每次结果决定下一次地址，这种细粒度能力很有价值。

它的困难是依赖时延。设线程读取 A，取得 A 中的指针后才能读取 B，取得 B 才能读取 C。即使链路带宽很大，这三个读取也未必能并行。更多链路无法消除程序本身的串行地址依赖。

DMA 以一段描述符表达批量搬运：源地址、目标地址、长度、步幅或其他参数。执行核或 CPU 提交任务后，搬运引擎按描述符工作。大块连续数据、可预知的访问和重复使用的块，通常更容易通过 DMA 摊薄开销。

put/get 一侧发起的编程接口，则允许调用者把数据写到远端、或从远端取回，而不要求对方为每一条数据都执行匹配的 receive。它可能使用 DMA、设备端访存或网络硬件，具体路径由实现和互连决定。NVSHMEM 就提供基于对称内存与 PE 编号的单边操作；PE 是处理单元的逻辑编号。NVSHMEM 使用说明。

"单边"并不意味着接收方可以不管缓冲区与生命周期。双方仍要事先约定目标空间，保证它不被提前释放，并通过完成与通知机制确认何时可读。

选择方式可以从数据的复用看。若 GPU A 将反复使用 GPU B 上同一块权重，一次取回再在本地多次计算，可能比每次远端读取更合适。若 A 只随机读取少量元素，搬运整个大块反而浪费带宽。超节点扩展了可选路径，但数据访问模式仍然决定应选哪条。

3.5 远端读取需要足够的并发窗口

带宽是单位时间能够交付多少字节，时延是一次操作要等待多久。为了同时获得高带宽，系统需要让足够多的操作处在进行中。

假设远端读取的往返时延为 2 μ s 2\ \mu s 2 μs，希望达到 400 GB/s 的有效读带宽。按带宽时延积，需要约：

400 × 10 9 × 2 × 10 − 6 = 800000 B 400\times10^9\times2\times10^{-6}=800000\ \mathrm{B} 400×109×2×10−6=800000 B

即约 800 kB 的数据同时在途。

如果每次读 64 B，至少需要约 12500 个在途读取，才能在这个简化模型中覆盖等待。若硬件或软件总共只允许 1000 个这样的未完成事务，即使其他资源无限充足，吞吐上限也只有：

1000 × 64 2 × 10 − 6 = 32 G B / s \frac{1000\times64}{2\times10^{-6}}=32\ GB/s 2×10−61000×64=32 GB/s

这解释了一个常见现象：大块传输测试很快，细粒度远端访问却慢很多。限制它的可能是请求窗口、事务表项、地址翻译、执行线程数量或目标端处理能力，而不是光纤、铜缆的线路速率。

向量化读取、请求合并、预取、批量 put/get、更多独立线程，都是增加有效在途量的办法。代价是更多缓冲、状态与资源占用。预取太早会浪费容量，预取错误会传输无用数据；并发太多也可能加剧目标端拥塞。

因此，讨论远端访存性能时，至少要给出访问大小、读写类型、并发深度、地址分布和读写比例。一个"远端时延"数值不足以解释所有吞吐。

3.6 缓存一致性与内存顺序分别解决什么

缓存一致性主要关注同一位置存在多个缓存副本时，各执行者怎样观察这个位置的更新。内存顺序关注多个位置上的操作，在哪些条件下能够按约定的先后被观察。

即使对一个标志位的访问是原子的，也不自动保证标志位对应的数据块已经对接收者可见。最小例子是生产者写 data=42，再写 ready=1；消费者看到 ready==1 后读取 data。

从程序文本看，写数据在前，写标志在后。但编译器、缓存、写缓冲、互连和执行引擎可能具有不同的排序规则。要让消费者读到 42，需要在适当作用域和接口下建立发布---获取关系，或者使用通信库提供的等价保证。

图8：抽象的生产者---消费者同步路径。作者绘制。它表达所需语义，不是一段可直接替代任意 API 的代码。

图8先画数据传输，再画数据与通知之间的顺序约束，最后画通知。需要保证的是：消费者按接口要求观察到通知时，相关数据已经满足可见性要求。这不等于发送方必须先阻塞等待远端完成，再单独发送通知；有序的 put 后接 signal、或者带信号的传输接口，可以建立相应关系。具体调用仍须遵守所用 API 的约束。

这里有三个常见误解。第一，发送方"把数据发出去了"，不代表接收端已写入；第二，网卡报告完成，不代表任意已经运行的 GPU kernel 都能立即观察到新值；第三，普通 volatile 不能替代跨设备的完成和内存序协议。

实际编程应使用对应 API 的规则。例如 NVSHMEM 的 fence 对规定操作建立同一目标 PE 的交付顺序，不保证完成，也不覆盖非阻塞 get 或非阻塞原子操作取回值的顺序。quiet 完成调用 PE 已发起且处于其覆盖范围内的操作，本身不是所有 PE 的集合屏障，也不通知接收者。CPU 与 GPU 发起的通信分别受对应侧调用约束；多线程还需先确保待处理操作已发起，接收者则按 wait/test 等接口规则观察数据。NVSHMEM 排序与完成规则。CUDA 原子操作也有线程块、设备、系统等作用域；作用域必须覆盖真实参与者，不能把设备内同步直接推广到任意远端设备。NVSHMEM 内存模型、CUDA 内存模型。

GPUDirect RDMA 文档还单独讨论 GPU 的宽松内存模型与外部设备写入的交互。这些约束要与当前库、驱动和平台版本一起核对，不能用一条通用屏障伪代码覆盖全部环境。

CPU 与 GPU 通过特定一致性互连连接，也是一个明确的硬件范围。Grace 与 Blackwell 之间的 NVLink-C2C 一致性能力，不能直接推成整个 NVLink 交换域拥有与单台 CPU SMP 完全相同的缓存一致性语义。应分别检查 CPU---GPU、GPU---GPU、跨进程和跨主机的保证。

3.7 内存池化的真正收益来自放置、复用和容量管理

设 8 个推理实例各自预留 100 GB 缓存，固定分配合计 800 GB。某个时刻，四个实例各需要 150 GB，另外四个各需要 20 GB，总需求为 680 GB。固定配额下，前四个实例可能因为超过各自 100 GB 而受限，尽管其他实例还有大量空闲。

如果可以把容量作为池按需分配，680 GB 总需求就可能容纳在 800 GB 中。这是池化改善容量利用率的直接例子。但它没有说明远端访问足够快，也没有说明映射与调度开销为零。

要把容量收益转成性能，池管理器需要知道哪些数据热、谁会使用、何时再用。模型权重通常读取多、更新少或按步更新；KV 缓存随请求增长，部分前缀可共享；检查点需要一致快照；训练激活通常需要保存到相应反向计算完成，或通过重计算减少保存量，之后才能释放。这些对象的生命周期不同，不适合用完全相同的缓存策略。

例如，活跃解码请求的 KV 可能每生成一个 token 都要被读取，远端放置会持续消耗互连；冷前缀暂存在 CPU DRAM，命中后一次预取到本地 HBM，则用较低成本容量换取复用机会。相同的"缓存池"，两种用法对网络压力完全不同。

页面迁移也要计算收益。设迁移一个数据块需要 T m T_m Tm，迁移后每次使用节省 Δ t \Delta t Δt，预计还会使用 r r r 次。最简单的盈亏条件是：

r Δ t > T m r\Delta t>T_m rΔt>Tm

还需考虑迁移占用的带宽和目标空间。如果数据只用一次，迁移的时间可能收不回来；如果之后反复使用，预取或迁移就更值得。容量池化的调度因此必须与访问频度联系起来。

3.8 KV 缓存容量怎样计算，超节点改变了哪一部分

对于保存常规 K、V 的注意力层，忽略对齐和元数据时，KV 缓存容量可以估算为：

C K V = 2 L B S n k v d b C_{KV}=2LBSn_{kv}db CKV=2LBSnkvdb

L L L 为层数， B B B 为并发序列数， S S S 为每序列已保存 token 数， n k v n_{kv} nkv 为 KV 头数， d d d 为每个头的维度， b b b 为每元素字节数。前面的 2 对应 K 与 V。不同长度请求应对各自 S i S_i Si 求和，不能始终用一个平均长度代替峰值规划。

教学设定 L = 80 L=80 L=80、 n k v = 8 n_{kv}=8 nkv=8、 d = 128 d=128 d=128、 b = 2 b=2 b=2。每个序列每个 token 的 KV 大小为：

2 × 80 × 8 × 128 × 2 = 327680 B = 320 K i B 2\times80\times8\times128\times2=327680\ \mathrm{B}=320\ KiB 2×80×8×128×2=327680 B=320 KiB

一条 32768 token 序列需要 10 GiB；32 条同长度序列需要 320 GiB。这是跨全部 80 层的逻辑 KV 总量，不是每个 rank 都各占这么多。实际每卡占用取决于层与 KV 头怎样切分、是否复制、缓存布局和填充；尤其 KV 头复制时，不能直接把总量除以 TP 度。它们还没有包含模型权重、临时张量、通信缓冲与框架预留。

如果常规 MHA 使用 64 个 KV 头而其他条件不变，容量变为八倍。这说明 GQA、MQA 等减少 KV 头数量的模型结构选择，会直接改变存储和通信压力。MLA 的缓存表示与上述常规 K/V 公式不同，不能直接套用同样的 n k v d n_{kv}d nkvd 计量；需要按实际保存的低秩潜变量和额外分量计算。

超节点能提供更多可组合容量、更快的数据交换和更多放置选择，但不会改变模型本身每个 token 要保存多少信息。模型结构、量化、分页管理、前缀复用和物理互连分别作用于不同环节。

PagedAttention 把请求的逻辑 KV 块映射到物理块，减少为最大长度连续预留造成的浪费，并支持一定条件下的共享。它首先是缓存管理和执行机制；跨主机、跨设备使用这些块，还需要额外的数据路径和一致的块元数据。PagedAttention 原始论文。

一个实际例子是前缀共享。两个请求具有相同的长系统提示词，可以引用同一批只读前缀块；当后续 token 分叉时，各自增加新块。调度器必须确保共享部分确实对应相同模型版本、位置编码和前缀内容，并在写入分支时正确管理所有权或写时复制。共享的依据是语义相同，不是两个请求长度相同。

3.9 CXL 扩展内存能力，与加速器高速域怎样配合

讨论内存池时还经常遇到 CXL。理解它，应先分开三个协议用途：CXL.io 承担发现、配置和 I/O 等基础行为；CXL.cache 使设备能够在规定的一致性机制下缓存主机内存；CXL.mem 让主机以内存访问方式使用设备连接的内存。设备类型和版本决定具体采用哪些能力。CXL 联盟关于一致性与协议的说明。

这与"GPU 之间的高带宽通信"存在交集，但并不相同。一个 CXL 内存扩展设备可以帮助主机增加容量，不代表 GPU 到它的完整访问路径就具有本地 HBM 级带宽；一个系统支持 CXL，也不表示其中每个加速器都能直接访问所有内存设备。

池化与共享也需分开。假设一个设备有 1 TB 容量，管理器在不同时间分别把其中一些区域分给主机 A、主机 B，这是容量池化的一种形式；让 A、B 同时访问同一批字节，则进一步涉及共享、权限和一致性。CXL 不同版本扩展了交换与 Fabric 能力，不能用某一早期版本的访问关系覆盖所有版本，也不能把较新规范的能力当成所有现有设备都已实现。

从超节点角度，较大容量、成本较低的内存层适合放置哪些对象，需要按第三章前面的访问账本判断。冷缓存、模型暂存或检查点缓冲，与每一步都被反复读取的热权重、热 KV，具有不同带宽需求。体系结构允许连接只是第一步，数据放置和计算调度决定它能否真正改善性能。

到这一层，内存已经不只是容量数字，而是一组有位置、有权限、有状态、有生命周期的对象。下一章将把这些对象接回真实的模型通信。

四、集合通信与模型并行：数据交换怎样完成真正的计算

4.1 先区分五种经常混用的通信操作

下表前四类是集合通信操作；Send/Recv 是点对点原语，放在一起是为了比较数据关系。

集合通信描述一个通信组内所有参与者共同完成的操作。它规定输入输出关系，不规定只能使用环、树或某一种物理网络。相同的 AllReduce 可以有多种算法，算法也可以根据消息大小、拓扑和硬件能力变化。NCCL 集合通信定义。

操作	每个 rank 开始时有什么	完成后有什么	典型用途
AllReduce	同形状的局部数组	每个 rank 都有逐元素归约结果	梯度求和、TP 部分和合并
ReduceScatter	同形状、可分块的局部数组	每个 rank 保留归约结果的一块	分片梯度、序列分片输出
AllGather	各自的一块数据	每个 rank 都有拼接后的完整数据	参数或激活收集
All-to-All	按不同目标划分的数据	每个 rank 收到所有源给自己的分块	MoE 专家分发与回收
Send/Recv	一个源与一个目标之间的数据	目标得到相应数据	流水线阶段交接、定制交换

Broadcast 也很常见，由一个根 rank 向其余参与者分发相同数据。Reduce 则只让某个根 rank 得到归约结果。

最关键的区别在"归约"与"重排"：AllReduce 对相同逻辑位置做加法等操作；All-to-All 通常把不同内容送往不同目的地，不必发生求和。MoE 专家计算前后的数据不是天然可以合成一个和的同类数据。

即使某 API 名称相同，也要检查数据量口径。AllGather 的发送大小是本地分片，最终输出大小则是组内全部分片；ReduceScatter 输入是完整逻辑数组，输出是其中一块。把输入、输出字节数混用，会得到看起来很高却不可比较的带宽数字。

4.2 用四个数组完整理解 AllReduce

设 4 个 rank 各有 4 个数，归约操作为逐元素求和：

text 复制代码

R0: [   1,    2,    3,    4]
R1: [  10,   20,   30,   40]
R2: [ 100,  200,  300,  400]
R3: [1000, 2000, 3000, 4000]

每个 rank 最后都应得到：

text 复制代码

[1111, 2222, 3333, 4444]

最容易想到的实现是让 R0 收齐所有输入、求和，再把结果发回。但 R0 的接收、内存处理和发送都会成为集中点。其他 rank 即使还有带宽，也不能直接分担 R0 的负担。

环形 AllReduce 把数组切成 4 块，通过两个阶段分摊工作。

图9：四 rank 的 ReduceScatter 与 AllGather。作者绘制。为方便展示，每个数代表一个等大小的数据块。

第一阶段是 ReduceScatter。每个分块的部分和沿环逐步累加，3 轮后，每个 rank 拿到一个已完成的分块，而不是完整结果。

以块 0 为例，选择让它从 R1 的本地值 10 开始，沿 R1→R2→R3→R0 行进。第一轮，R2 收到 10，与本地 100 相加得到 110；第二轮，R3 收到 110，与本地 1000 相加得到 1110；第三轮，R0 收到 1110，与本地 1 相加得到 1111。

其余块按相应错位方式同时处理，最终可以得到如下分布：

text 复制代码

R0 持有块0的最终和：1111
R1 持有块1的最终和：2222
R2 持有块2的最终和：3333
R3 持有块3的最终和：4444

实际库可能采用不同的块编号和起点，语义相同。这里特意写出一块的中间结果，是为了看清"数据到达后做局部加法，再继续发送"的过程。

第二阶段是 AllGather。每个 rank 把自己已经完成的块沿环传播。再经过 3 轮，所有 rank 都收齐四块，得到完整数组。

若原数组大小为 S S S 字节，每轮每 rank 发送 S / 4 S/4 S/4，两个阶段各 3 轮，所以每 rank 总发送量为 6 S / 4 = 1.5 S 6S/4=1.5S 6S/4=1.5S，接收量相同。对于 N N N 个 rank，理想环形算法的每 rank 发送量为：

V r i n g = 2 N − 1 N S V_{\mathrm{ring}}=2\frac{N-1}{N}S Vring=2NN−1S

采用每轮固定开销 α \alpha α、单向有效带宽 B B B 的教学模型：

T r i n g ≈ 2 ( N − 1 ) α + 2 N − 1 N S B T_{\mathrm{ring}}\approx2(N-1)\alpha+ 2\frac{N-1}{N}\frac{S}{B} Tring≈2(N−1)α+2NN−1BS

这个公式既说明环形算法在大数据量下的带宽效率，也说明它的轮数随参与者数量增加。实际实现通常会流水分块、建立多条通道，并根据拓扑分配路径；公式不是对任意 NCCL 配置的精确预测。

4.3 树、分层算法和网络内归约各减少什么

树形算法让多个分支并行向上求和，再向下分发。理想二叉树在归约或广播单个阶段的逻辑深度约为 log ⁡ 2 N \log_2N log2N，相对于环单个阶段的 N − 1 N-1 N−1 轮，更适合某些小消息或时延敏感场景。

但轮数少不意味着必然更快。树根或中间节点会承担多分支流量；如果消息大、端口利用不均衡，带宽项会变得重要。双树、分块、多通道等设计用于平衡资源。算法选择必须同时看固定开销、消息量和网络映射。

当系统具有强域内、弱域外两层网络时，可以进行分层归约。例如每柜先把局部结果分片归约，让不同本地 rank 分别负责不同分片；随后相应 rank 跨柜归约各自分片；最后在柜内收集完整结果。

这样既利用快速域内链路，又避免让一颗代表 GPU 承担全部跨柜字节。跨柜通信实际经过多少网卡、是否共享上行、分片与网卡怎样对应，决定它是否有效。

网络内归约则把部分逐元素求和放到支持该操作的交换硬件中。若交换节点收到多个源对同一逻辑元素的贡献，可以在网络中合并，再向后传递部分和或最终结果。它减少某些归约算法中的转发与端点处理，必要时结合多播把结果分发给多个接收者。NVIDIA 关于 NVSwitch 与归约能力的技术说明。

这里必须守住操作边界。交换芯片支持某种数据类型和归约操作，不代表可以执行完整神经网络层；源数据仍要进入网络，最终结果仍要到达消费者；数据类型、对齐、组大小、资源配额和软件版本也都可能限制使用。

网络内求和也不能自动加速任意 All-to-All。MoE 中送往 E1 和 E3 的输入（也可能是同一 token 的两份副本），必须分别经过对应专家的非线性计算，不能在交换机里先加在一起。可以优化的是分发、复制、路径和回收过程，不能随意改变模型的运算关系。

浮点加法还不满足严格结合律。不同的归约树、分块与顺序，可能产生微小数值差异。分布式训练通常需要在性能、精度和确定性要求之间作出明确选择，不能用整数示例的完全一致性掩盖浮点现实。

4.4 读懂 algbw 和 busbw，避免带宽比较失真

NCCL tests 使用 algbw 表示算法带宽，即逻辑数据大小 S S S 除以完成时间 T T T。AllReduce 还给出 busbw，按 2 ( N − 1 ) / N 2(N-1)/N 2(N−1)/N 因子归一化：

a l g b w = S / T \mathrm{algbw}=S/T algbw=S/T

b u s b w = a l g b w × 2 ( N − 1 ) / N \mathrm{busbw}=\mathrm{algbw}\times2(N-1)/N busbw=algbw×2(N−1)/N

这有助于理解集合通信相对于链路能力的利用程度。NCCL tests 官方口径说明。

例如 8 rank、每 rank 1 GB 的 AllReduce，耗时 5 ms，algbw 为 200 GB/s，按该公式得到 busbw 为 350 GB/s。不能把 200 与另一测试的 350 当作同一种指标比较，也不能把 350 解释成 PCIe 或 NVLink 每条物理线实测的字节计数。

如果硬件使用网络内计算、特殊多播或不同的数据运动方式，归一化指标更要结合实际算法解释。最终判断仍应落回：多大的逻辑操作，在多大的通信组和什么配置下，用了多长时间。

4.5 数据并行与 ZeRO：复制减少后，通信会发生变化

最简单的数据并行中，每个 rank 保存完整模型，处理不同样本，计算局部梯度。为了让每份模型继续执行相同更新，需要在更新前归约梯度，通常再按所需规则取平均。

其计算容易并行，但模型参数、梯度和优化器状态在每张卡上重复保存。以一种常见的混合精度 Adam 配置为教学例子：低精度参数 2 字节、低精度梯度 2 字节、FP32 主参数 4 字节、一阶矩和二阶矩各 4 字节，合计约 16 字节/参数。实际训练实现可采用不同梯度、主参数或优化器状态格式，这个数不能通用化。

若模型有 1000 亿参数，仅这组状态就约 1.6 TB，还没有激活和通信空间。多做数据并行副本并不降低每副本的这部分容量。

ZeRO 按阶段将优化器状态、梯度和参数分片，让各 rank 分担存储。Stage 1 分片优化器状态，Stage 2 进一步分片梯度，Stage 3 再分片参数；执行某层时按需要收集参数，使用后重新释放或分片。DeepSpeed ZeRO 官方教程。

这里的收益和代价来自同一个动作：少存副本，就可能需要在使用时获取远端分片。因此，ZeRO-3 的参数 AllGather、梯度 ReduceScatter、预取与缓存策略，都可能进入模型执行路径。不能把数据并行一概描述为"每步只有一次低频通信"。

可以用一个更小例子理解。4 个 rank 各存参数的四分之一，某层需要完整参数才能计算。前向前先收集本层分片；算完后，如果释放完整副本，反向需要时可能再次收集。保留参数能减少重新获取，却增加显存占用。预取下一层能隐藏传输，却占用额外缓冲并与当前通信竞争。

所以，高速域也可能用于加速分片数据并行，而不仅仅用于 TP 和 EP。合理的映射依据是实际通信时间线，而不是并行名称的固定标签。

4.6 张量并行：用两层 MLP 看清切分与归约

对于简化的两层前馈网络：

Z = ϕ ( X W 1 ) , Y = Z W 2 Z=\phi(XW_1),\qquad Y=ZW_2 Z=ϕ(XW1),Y=ZW2

若 W 1 W_1 W1 沿输出维度切成两部分，各 GPU 得到 Z 0 Z_0 Z0、 Z 1 Z_1 Z1；再把 W 2 W_2 W2 沿对应输入维度切成两部分，分别计算 P 0 = Z 0 W 2 , 0 P_0=Z_0W_{2,0} P0=Z0W2,0、 P 1 = Z 1 W 2 , 1 P_1=Z_1W_{2,1} P1=Z1W2,1，最后求和 Y = P 0 + P 1 Y=P_0+P_1 Y=P0+P1。

图10：列并行接行并行的两层 MLP。作者依据矩阵分块关系绘制；省略偏置和门控分支。

图10左侧的 X X X 对两颗 GPU 都可用。第一层矩阵乘各自产生一部分中间特征；中间激活留在本卡，直接送入第二层的对应权重分片。右侧 AllReduce 将同形状部分和相加，恢复完整输出。

用具体数字算一次。令：

X = $1 2$ , W 1 = $1 0 1 2 0 1 1 0$ , W 2 = $1 0 0 1 1 1 2 0$ X=\begin{bmatrix}1&2\end{bmatrix},\quad W_1=\begin{bmatrix}1&0&1&2\\0&1&1&0\end{bmatrix},\quad W_2=\begin{bmatrix}1&0\\0&1\\1&1\\2&0\end{bmatrix} X= $12$ ,W1= $10011120$ ,W2= 10120110

取 ϕ \phi ϕ 为 ReLU，本例的中间值均非负，不改变数值。先在单卡验证：

X W 1 = $1 , 2 , 3 , 2$ , $1 , 2 , 3 , 2$ W 2 = $8 , 5$ XW_1= $1,2,3,2$ ,\qquad $1,2,3,2$ W_2= $8,5$ XW1= $1,2,3,2$ , $1,2,3,2$ W2= $8,5$

切到两卡后，GPU 0 保存 W 1 W_1 W1 前两列，得到 Z 0 = $1 , 2$ Z_0= $1,2$ Z0= $1,2$ ；GPU 1 保存后两列，得到 Z 1 = $3 , 2$ Z_1= $3,2$ Z1= $3,2$ 。

GPU 0 再乘 W 2 W_2 W2 前两行，得到 P 0 = $1 , 2$ P_0= $1,2$ P0= $1,2$ 。GPU 1 乘后两行，得到 P 1 = $7 , 3$ P_1= $7,3$ P1= $7,3$ 。二者求和，正好是 $8 , 5$ $8,5$ $8,5$ 。

这个算例说明：中间的四个特征不必先在每卡拼成完整数组，就能继续计算下一层。正确的矩阵切分减少了不必要的数据交换，最终所需归约来自第二层的求和关系。

但并非任何操作都允许这样切。若某个非线性或归一化操作依赖整个被切维度，就可能需要额外统计或收集。例如沿隐藏维度切开 LayerNorm，均值和方差就要跨分片协调；门控 MLP 也需要让对应门控分片保持匹配。真实框架处理的是完整算子图，而非孤立的两个 GEMM。

Megatron-LM 系列工作系统研究了 TP、PP、DP 的组合；其框架资料还讨论序列并行、上下文并行和专家并行。Megatron-LM 论文、Megatron Core 并行策略指南。

4.7 张量并行度为什么存在收益拐点

提高 TP 度通常能降低每卡权重容量，分摊部分矩阵计算。但每卡矩阵变小，GPU 未必继续保持原有 GEMM 效率；同时输出合并和同步仍然存在。

可以写成简化模型：

T T P ( p ) ≈ T G E M M ( p ) + T c o l l e c t i v e ( p ) + T o t h e r ( p ) T_{TP}(p)\approx T_{\mathrm{GEMM}}(p)+T_{\mathrm{collective}}(p)+T_{\mathrm{other}}(p) TTP(p)≈TGEMM(p)+Tcollective(p)+Tother(p)

其中 p p p 为 TP 度。理想情况下，第一项近似随 1 / p 1/p 1/p 减少；实际还受矩阵形状、算子实现与内存访问限制。第二项不一定减少，固定时延、通信组规模和总激活大小都可能保留。

设未切分矩阵计算为 1.6 ms，教学假设 4 路后为 0.4 ms，通信 0.1 ms，总计 0.5 ms；8 路后计算为 0.2 ms，通信升到 0.15 ms，总计 0.35 ms。继续到 16 路，如果小矩阵效率下降使计算只能降到 0.16 ms，而通信升到 0.25 ms，总计变成 0.41 ms。

这个例子不是产品预测，而是说明总时延要同时计算两条曲线。显存允许时，较低 TP 度可能获得更好的每请求时延或资源效率；显存不足时，又可能必须扩大 TP 才能运行。

序列并行可以让某些原先在 TP rank 上重复的激活按 token 维分片，并把部分 AllReduce 拆成 ReduceScatter 与 AllGather，使相邻算子保持更合适的数据布局。这里的"序列并行"要与上下文并行区别：前者常服务于 TP 组内的激活和非矩阵操作分片，后者处理长上下文注意力的跨设备依赖。不同项目命名可能有差异，应看实际张量如何划分。

4.8 MoE 专家并行：token 怎样找到专家并返回

MoE 层由路由器选择部分专家执行。假设隐藏向量为 x x x，选中 E1 与 E3，路由权重为 0.6 和 0.4，简化输出为：

y = 0.6 E 1 ( x ) + 0.4 E 3 ( x ) y=0.6E_1(x)+0.4E_3(x) y=0.6E1(x)+0.4E3(x)

如果 E1、E3 在其他 rank，源端必须把 x x x 发过去，再拿回两份输出，按原 token 顺序和路由权重合并。

图11：一个 token 的 Dispatch、专家计算和 Combine。作者绘制，路由权重为教学设定。

图11左侧不仅有向量，还隐含 token ID、源 rank 与顺序。路由与打包阶段按目的专家整理数据，形成适合传输和专家 GEMM 的布局。两条 Dispatch 箭头把同一向量送往不同专家；专家完成计算后，返回路径携带结果及恢复位置所需的元数据。

源端收到的顺序未必等于原 token 顺序。比如 t0、t1、t2 原本相邻，却分别由不同专家处理，完成时间也不同。Combine 必须按照记录的映射，把结果散回正确位置，再执行加权求和。若为了提升计算效率进行了排序或填充，还需要跳过填充项并恢复对应关系。

真实通信算子通常要完成更多步骤：统计各目的地接收量、为每个专家计算 offset、申请或复用接收空间、打包 token、传输、产生计数与完成信号、重排为 grouped GEMM 输入，再执行反向路径。这些步骤有些可以融合，但没有因为"用了 All-to-All"而消失。

动态 token 数量还会影响通信接口。一些通用 All-to-All 接口假定等大小分块，MoE 则常是不同目的地收到不同数量，需要变长交换、填充或专门算子。DeepEP 等项目就针对专家分发和回收组织通信，具体后端与接口随版本演进；阅读当前代码时，应记录实际版本。DeepEP 官方项目。

4.9 把 MoE 的通信量逐项算清楚

回到第一章的教学设定：每 rank 4096 token，隐藏维 8192，BF16，top-2，假设选中的两路专家都在远端。

每 rank 原始激活为 64 MiB，Dispatch 发送量为 128 MiB。在全局路由均衡、输入和输出隐藏维相同的设定下，平均每 rank 接收 128 MiB 待处理输入。

专家处理后，平均每 rank 需要向原始源端发送 128 MiB 输出；原始源端再接收对应的 128 MiB。于是单个 MoE 层的前向，平均每 rank 的账是：

阶段	发送	接收
Dispatch	128 MiB	128 MiB
Combine	128 MiB	128 MiB
前向合计	256 MiB	256 MiB

"发送+接收合计"是 512 MiB。但若接口全双工，且同一阶段的发送接收确实并行，估算阶段传输时间时，通常应分别计算发送和接收并取较大者，而不是把两者相加后除以单向速率。

用 400 GB/s 有效单向带宽，128 MiB 一次阶段的理想数据时间约为：

128 × 2 20 400 × 10 9 ≈ 0.336 m s \frac{128\times2^{20}}{400\times10^9}\approx0.336\ ms 400×109128×220≈0.336 ms

Dispatch 与 Combine 中间隔着专家计算，不能把同一个 token 的两者任意重叠。因此只看这两个阶段的数据时间，前向合计约 0.671 ms。换成 50 GB/s，则约为 5.369 ms。

如果有 24 个这样的 MoE 层，平均每 rank 前向发送量为 6 GiB，接收同样为 6 GiB。若反向在相同数据精度与路由模式下产生相应的梯度分发和回收，可以再增加约一倍交换量；具体训练实现仍需按激活梯度、路由权重梯度和通信格式逐项统计。

这里的 0.671 ms 是只包含给定有效带宽下数据传输的教学基线。启动、元数据、打包、重排、同步、局部专家比例和拥塞会改变实际时间；量化或合并重复目的地也会改变字节数。它不是实际通信时间的上界，实际系统完全可能更慢。

还有一个容易混淆的问题：源端按 top-2 复制向量，不代表物理网络总在每条链路上都复制两份。如果两个专家位于同一个目标节点，系统可以先把一份 token 送到该节点，再在局部域分发。层次化转发会改变域外与域内各自的流量，必须按切面统计。

4.10 专家负载不均衡为什么能拖慢所有卡

设总共有 8 个专家，一批 1000 个 token，每个 token 只选一个专家。均衡时每个专家处理 125 个。如果其中一个专家收到 400 个，其余专家分享剩余 600 个，那么即使网络传输足够快，最忙专家仍需完成 400 个 token。

若各专家单位 token 处理时间相近、没有额外并发优势，最慢专家的工作量是均值的 3.2 倍。其他专家提前结束后，需要等待它，整个 MoE 层的尾部被拉长。

缓解方法有不同作用点：训练时使用负载平衡策略改善路由分布；为专家设置容量或处理溢出；推理时复制热门专家并分配请求；根据观测重新放置专家；通过微批组织和 grouped GEMM 改善小批次执行效率。

每个方法都有代价。复制专家增加权重容量；训练中副本更新还要同步；重新放置会搬运权重；容量限制或 token 丢弃可能影响模型行为；过度约束路由也可能损害模型质量。系统优化需要明确哪些属于等价调度，哪些会改变模型计算或精度。

因此，EP 度越大并不必然越好。更多 rank 可以让专家分布更细、汇总更多显存和内存带宽，并改变通信参与者和路由跨度。但在 EP 组总 token 数、专家总数、top-k 与路由不变时，仅增加 EP 度不会让每个专家收到的 token 数减少。例如 1000 个 token、8 个专家、top-1 均匀路由时，每专家期望 125 个 token；EP 从 2 变成 4，改变的是每 rank 从放 4 个专家变成放 2 个专家。专家实际批量是否变化，还要看 EP 组输入量与路由是否随配置改变。Megatron Bridge 并行说明。最佳配置取决于总 batch、专家数量、top-k、互连和服务时延目标。

4.11 流水线并行：阶段交接与空泡来自不同原因

流水线并行把模型层分配给不同 stage。一个微批先在 stage 0 计算，再把激活交给 stage 1，依次向后。训练反向则沿相反方向传递激活梯度。

如果一次只处理一个微批，后面的 stage 开始前会等待，前面的 stage 完成后又空闲。把一个大批次分成多个微批，可以让不同 stage 同时处理不同微批，提高整体利用率。

在理想的同耗时、单向前向流水教学模型中， p p p 个 stage、 m m m 个微批，完成需要约 m + p − 1 m+p-1 m+p−1 个时隙，利用率为 m / ( m + p − 1 ) m/(m+p-1) m/(m+p−1)。训练中的前向、反向、激活保存和不同调度会改变公式，不能直接把它当成所有训练流水线的精确空泡率。

例如 4 个 stage、8 个微批，单向前向模型需要 11 个时隙；理想计算工作相当于 8 个满流水时隙，其余来自填充和排空。增加微批数可以摊薄它们，但可能改变有效 batch、调度开销和激活存储。

更快的阶段间传输减少交接等待，却不能消除计算不均衡。如果一个 stage 的计算是其他 stage 的两倍，它仍会限制节拍。划分模型时需要综合层计算量、通信量、激活容量与网络位置，而不是简单平均层数。

DeepSeek-V3 技术报告中的 DualPipe 将流水线调度、MoE 通信和计算重叠结合起来，说明算法组织会改变网络需求出现的时机。它的经验适用于对应的硬件、并行和工作负载设定，应理解其机制后再迁移。DeepSeek-V3 技术报告 §3。

4.12 长上下文并行：为什么 K、V 要跨分片交换

注意力的基本形式是：

O = softmax ⁡ ( Q K T d ) V O=\operatorname{softmax}\left(\frac{QK^T}{\sqrt d}\right)V O=softmax(d QKT)V

一个查询向量 q q q 要与允许关注的全部 key 比较，得到归一化权重，再对对应 value 加权。训练使用因果注意力时，只能关注当前位置及之前由掩码允许的位置。

如果把序列按 token 位置分到多个 rank，每个 rank 有自己的 Q Q Q，但所需 K、V 可能分布在其他 rank。只计算本地 K、V 会漏掉远端上下文，结果不完整。

一种思路是把 K、V 收集到本地；另一种思路是按块传递 K、V，收到一块就计算一块。后一种能控制峰值工作集，并有机会把下一块传输与当前块计算重叠，但必须正确合并不同块的 softmax。

不能把每块各自归一化后的注意力输出简单平均。因为某块的分数整体很高，另一块整体很低，两块在全局 softmax 中本来就不应具有相同总权重。

4.13 用可复算例子解释分块 softmax 合并

对一个查询，令第 j j j 个位置的分数为 s j s_j sj，value 为 v j v_j vj。为避免指数溢出，对某一块保存三个量：

m = max ⁡ j s j , ℓ = ∑ j e s j − m , u = ∑ j e s j − m v j m=\max_j s_j,\quad \ell=\sum_j e^{s_j-m},\quad u=\sum_j e^{s_j-m}v_j m=jmaxsj,ℓ=j∑esj−m,u=j∑esj−mvj

这里 u u u 是未归一化加权和，通常是一个向量；最终输出为 u / ℓ u/\ell u/ℓ。

图12：两个分块的归一化统计量合并。作者绘制。

设块 A 有 ( m A , ℓ A , u A ) (m_A,\ell_A,u_A) (mA,ℓA,uA)，块 B 有 ( m B , ℓ B , u B ) (m_B,\ell_B,u_B) (mB,ℓB,uB)。先取共同最大值 m = max ⁡ ( m A , m B ) m=\max(m_A,m_B) m=max(mA,mB)，再把两个块重标定到同一指数基准：

ℓ = e m A − m ℓ A + e m B − m ℓ B \ell=e^{m_A-m}\ell_A+e^{m_B-m}\ell_B ℓ=emA−mℓA+emB−mℓB

u = e m A − m u A + e m B − m u B u=e^{m_A-m}u_A+e^{m_B-m}u_B u=emA−muA+emB−muB

图12中的箭头表示合并这些统计量，而不是先把每块结果当作同等重要。上述表达式假定参与块至少含一个未被掩码排除的有限分数。因果掩码可能产生完全被屏蔽的块，实现应将其作为零贡献跳过或作等价处理，避免直接计算负无穷减负无穷；也不能对归一化分母为零的整行直接相除。

数值例子取标量 value。块 A 的两个分数为 0 0 0、 ln ⁡ 2 \ln2 ln2，对应 value 为 2、4；块 B 只有一个分数 ln ⁡ 3 \ln3 ln3，对应 value 为 10。全局直接计算时，未归一化权重为 1、2、3，所以结果为：

O = 1 × 2 + 2 × 4 + 3 × 10 1 + 2 + 3 = 40 6 ≈ 6.667 O=\frac{1\times2+2\times4+3\times10}{1+2+3} =\frac{40}{6}\approx6.667 O=1+2+31×2+2×4+3×10=640≈6.667

分块计算：块 A 的 m A = ln ⁡ 2 m_A=\ln2 mA=ln2， ℓ A = 1 / 2 + 1 = 1.5 \ell_A=1/2+1=1.5 ℓA=1/2+1=1.5， u A = ( 1 / 2 ) × 2 + 1 × 4 = 5 u_A=(1/2)\times2+1\times4=5 uA=(1/2)×2+1×4=5。块 B 的 m B = ln ⁡ 3 m_B=\ln3 mB=ln3， ℓ B = 1 \ell_B=1 ℓB=1， u B = 10 u_B=10 uB=10。

合并时 m = ln ⁡ 3 m=\ln3 m=ln3，A 的缩放因子为 2 / 3 2/3 2/3，B 为 1。于是 ℓ = ( 2 / 3 ) × 1.5 + 1 = 2 \ell=(2/3)\times1.5+1=2 ℓ=(2/3)×1.5+1=2， u = ( 2 / 3 ) × 5 + 10 = 40 / 3 u=(2/3)\times5+10=40/3 u=(2/3)×5+10=40/3。最终 ( 40 / 3 ) / 2 = 20 / 3 (40/3)/2=20/3 (40/3)/2=20/3，与直接计算一致。

如果错误地把 A 的局部输出 5 / 1.5 ≈ 3.333 5/1.5\approx3.333 5/1.5≈3.333 和 B 的局部输出 10 直接平均，本例恰好得到 6.667，因为两块的总未归一化权重都为 3；这个巧合会掩盖错误。把块 B 的分数改成 ln ⁡ 6 \ln6 ln6，其局部输出仍为 10，简单平均仍为 6.667；正确全局结果却是 ( 2 + 8 + 60 ) / ( 1 + 2 + 6 ) = 70 / 9 ≈ 7.778 (2+8+60)/(1+2+6)=70/9\approx7.778 (2+8+60)/(1+2+6)=70/9≈7.778。

第二个条件变化正好检验了理解：局部输出没有保留该块相对于其他块有多重要，因此仅有局部输出不够，必须连同归一化统计量合并。

分块与在线归一化也是理解 FlashAttention 的重要基础。FlashAttention 重点减少单设备内 HBM 与片上存储之间的 I/O；跨设备上下文并行则还要处理 K、V 的分布与网络交换。两者能够组合，但解决的物理层次不同。FlashAttention 原始论文、Megatron 上下文并行文档。

4.14 通信与计算重叠：从时间线判断收益

异步调用仅表示发起后不一定立即等待，并不证明通信已经与计算有效重叠。若同一块结果尚未算出来，不能发送；若后续算子依赖收到的结果，也不能提前读取。

图13：计算与通信的理想分块时间线。作者绘制，所有时间为教学设定。

设有 4 块数据，每块计算 2 ms、通信 1 ms。串行执行先计算完全部 4 块，再发送全部 4 块，需要 4 × 2 + 4 × 1 = 12 4\times2+4\times1=12 4×2+4×1=12 ms。

图13下面让第一块在第 2 ms 算好后立即发送，同时开始第二块计算。第二块第 4 ms 算好后发送，依次推进。最后一块在第 8 ms 算好，通信到第 9 ms 完成，总计 9 ms。

对于资源独立、各块耗时相同的模型，可以写成：

T p i p e ≈ t c + t m + ( k − 1 ) max ⁡ ( t c , t m ) T_{\mathrm{pipe}}\approx t_c+t_m+(k-1)\max(t_c,t_m) Tpipe≈tc+tm+(k−1)max(tc,tm)

k k k 是块数， t c t_c tc、 t m t_m tm 是单块计算和通信时间。第一块要经历计算与通信，后续节拍由较慢阶段决定。

现实中还要扣除四类损失。其一，小块增加 kernel 启动、描述符和同步次数；其二，通信 kernel 可能占用 SM 或向量核心，与计算抢执行资源；其三，通信读写本地 HBM，与 GEMM 共享内存带宽；其四，最后一个尾块无法继续隐藏。

因此，增加通信线程或通道可能提高网络速率，却让计算变慢。衡量是否成功，要看端到端时间，而不是只看通信操作自身缩短了多少。

分块尺寸也是取舍。块太大，首块要等很久才产生，重叠启动晚；块太小，固定开销和资源管理成本高。最合适的粒度通常与算子、网络、batch 和实现相关，需要通过时间线与计数器验证。

4.15 通信压缩：少传一半数据，还要核对缩放与转换成本

提高链路速率之外，还可以减少要传的字节。例如把适合的激活从 BF16 转成某种 8 位格式，主数据由每元素 2 字节降为 1 字节。若网络是主瓶颈，且转换成本可被摊薄，这可能明显减少通信时间。

低精度不是简单丢掉一个字节。量化需要把原数值映射到有限表示范围，并保存重建所需的 scale。用通用形式表示：

q = Q ( x / s ) , x ^ = s q q=Q(x/s),\qquad \hat x=sq q=Q(x/s),x^=sq

Q Q Q 包含转换、舍入和可能的截断； s s s 为缩放因子； x ^ \hat x x^ 是恢复后的近似值。实际库也可能存储逆 scale，符号约定需要核对。

用整数均匀量化作教学例子，取 s = 0.1 s=0.1 s=0.1，输入 x = 0.26 x=0.26 x=0.26，最近舍入得到 q = 3 q=3 q=3，恢复为 x ^ = 0.3 \hat x=0.3 x^=0.3，误差为 0.04。若值超出表示范围，还会发生饱和。这个例子说明量化误差来自映射，不能据此把 FP8 当成等间隔整数编码；FP8 有指数与尾数，数值间距随量级变化。

按整个张量使用一个 scale，元数据少，但离群大值可能压缩其他数值的有效表示空间。按块使用不同 scale，能适应局部范围，却增加元数据、转换与布局管理。NVIDIA Transformer Engine 文档和技术说明区分张量级、块级、当前与延迟缩放策略。FP8 缩放技术说明。

假设 128 个 BF16 元素原占 256 B，改为 128 B 的 8 位值，再附一个 4 B scale，传输为 132 B，理想缩减约 48.4%，略小于 50%。如果每 16 个元素附一个 4 B scale，则为 160 B，缩减 37.5%。这里采用通用元数据设定，不对应某个固定 FP8 标准。

压缩是否划算，可以比较：

T q u a n t + T m e t a + T d e q u a n t < M − M ′ B T_{\mathrm{quant}}+T_{\mathrm{meta}}+T_{\mathrm{dequant}} <\frac{M-M'}{B} Tquant+Tmeta+Tdequant<BM−M′

右侧是少传字节带来的理想节省，左侧是暴露的量化、元数据和反量化开销。如果转换融合进本来就要执行的 kernel，或者消费者能直接使用低精度输入，新增开销可能降低；如果要额外扫描张量、写回和再次读取，就可能抵消收益。

归约还有额外约束。不同 rank 采用不同 scale 时，不能不加处理就把编码值相加；累加格式、重标定和输出 scale 都需要有定义。训练梯度、MoE 激活、KV 缓存对误差的敏感性也不同，应分别验证精度。少传数据是一个性能机制，保持可接受的模型行为是它成立的前提。

至此，TP 的部分和、EP 的 token、CP 的 K/V、DP 的梯度、PP 的阶段激活，都有了明确的数据对象和操作路径。软件栈接下来的任务，是把这些关系映射成可靠运行的资源安排。

五、软件与运行时：把互连能力变成训练效率和推理服务

5.1 软件栈的工作是把模型依赖落实到资源

图14：模型、运行时、通信库、控制面和监控之间的关系。作者绘制。

从图14顶部看，模型图描述算子和依赖，训练或推理系统选择并行方案，算子库和通信库执行计算与交换。图中间分开控制面与数据面：前者建立环境，后者在环境中运行。

控制面通常需要发现 GPU/NPU、交换芯片、链路和内存，核对可用状态，建立路由与分区，分配访问权限，注册通信窗口，交换进程信息并创建通信组。数据面则持续执行矩阵乘、拷贝、归约、通知和等待。

这种区分有助于理解 CPU 的作用。GPU 可以在计算过程中直接发起通信，仍然需要 CPU、操作系统或管理服务完成初始化、资源分配与故障处理。"数据面减少 CPU 往返"不表示 CPU 从系统中消失。

图14底部的监控闭环也很重要。同一个"通信慢"，可能是链路降速、地址翻译问题、打包 kernel、专家偏斜或消费者迟迟不读取缓冲区。只有把物理计数器、通信事件和模型执行时间线对应起来，才能判断应该改哪一层。

5.2 拓扑感知首先是正确的 rank 放置

假设 64 rank 训练任务采用 TP=8、PP=2、DP=4，总数为 8 × 2 × 4 = 64 8\times2\times4=64 8×2×4=64。用三元组 ( d , p , t ) (d,p,t) (d,p,t) 表示一个 rank，其中 d d d 是数据并行副本， p p p 是流水线阶段， t t t 是张量分片。

固定 d , p d,p d,p，改变 t t t，得到一组 TP 成员；它们在层内频繁交换。固定 p , t p,t p,t，改变 d d d，得到相应的数据并行成员；它们同步同一参数分片的梯度。固定 d , t d,t d,t，改变 p p p，对应相邻流水线阶段之间的关系。

一种清晰的教学放置是把每个 8 rank TP 组安排在最紧密的局部域中，两个 stage 再通过合适路径连接，四个副本分布到更大范围。但如果局部显存不足、域外网络较弱或 ZeRO 参数收集很频繁，也需要重新选择。

EP 加入后，并行组可能在某些维度上复用或重新组织现有 rank。不能总写成 TP×PP×DP×EP，而不检查框架定义；某些并行维度不是独立相乘的物理扩容因子。

放置还包括 GPU 与网卡、CPU NUMA 域和内存的关系。如果 GPU 发送数据必须跨越较窄的 CPU 互连去找网卡，网卡标称 400 或 800 Gb/s 也未必能被 GPU 用满。拓扑感知因此包含设备亲和性、物理路径与共享资源，而不仅是把连续编号的卡分成一组。

可以把模型通信表示成加权图：顶点为 rank 或算子，边的权重为字节数、频次及关键路径敏感度。再把它映射到带容量和时延约束的物理图。频次高、依赖强的边应优先占用短而快的路径；可批量、可重叠的边可以容忍更远路径，但仍要满足总流量约束。

5.3 通信库选择的不只是 ring 或 tree

一个集合通信请求到达库后，库需要知道参与者、数据类型、操作、输入输出地址和大小。随后结合拓扑选择算法、传输方式、通道数、chunk 大小和执行资源。

某些小消息可以使用更偏低时延的协议或 kernel；大消息更关注连续吞吐；支持网络内归约时可尝试相应路径；跨多个网卡时还要决定如何切片与分配。

同一算法也可能建立多个通道，分别搬运不同分块。这有利于增加并发、覆盖链路等待、利用多个端口；同时会占用更多队列、缓冲和设备执行资源。通道数不是越大越好。

库通常还会检查 P2P 是否可用、注册是否成功、网络插件支持什么能力。如果快速路径不可用，系统可能报错，也可能选择其他传输路径，具体取决于实现。性能排查必须确认真正执行了什么，而不是只看机柜里安装了什么。

通信参与者的顺序也属于正确性要求。若两个 rank 对同一通信组发起集合操作的逻辑顺序不同，一个在等 AllGather，另一个在等 AllReduce，就可能挂起或产生错误。动态分支、异常退出和部分重试尤其需要保持通信契约一致。

这类挂起与第二章讲的硬件流控死锁不同：链路和路由可能完全正常，应用层协议却没有形成匹配的执行顺序。排查时应分别看硬件前进性与软件调用关系。

5.4 GPU 主动通信减少了哪些往返

传统执行中，GPU 完成某阶段后，CPU 观察事件、准备通信，再提交下一轮工作。这些步骤在大任务中可被摊薄，但细粒度、动态依赖多时，频繁 CPU---GPU 往返会成为开销。

GPU 主动通信让设备 kernel 在数据就绪时直接表达远端 put/get、通知或网络请求，使"产生数据---发送---等待---消费"更紧密地组合。一些实现让 GPU 直接操作网卡提交机制；另一些使用 CPU proxy 接收设备端请求并提交到网络。它们提供的上层功能可能相似，数据路径和性能却不同。

NCCL 的 Device API 与 GIN 文档把设备端窗口、远端操作、signal 和 counter 等对象明确列出。GIN 的 put 可关联远端动作与本地动作，用于表达目标数据稳定以及源输入已消费等不同事件。NCCL GIN API。

这里仍有资源成本：设备线程要构造请求、轮询或等待；网卡和网络的窗口有限；细小操作可能提高包率压力；通信 kernel 可能占用原本用于矩阵计算的 SM。GPU 主动发起并不必然意味着完全不使用 CPU，也不保证通信零占用。

适合它的场景往往具有明确的设备侧动态依赖。例如一个 tile 算好就发送给下一阶段，无需每个 tile 回到主机；MoE 在设备上完成路由，直接按目的专家发起交换；不规则计算中，GPU 根据结果决定下一次取数。

能否获益，仍然取决于缩短的主机往返是否大于新增的设备调度和资源竞争。应把 CPU proxy、直接网卡提交、设备端 NVLink 访存分别测试，避免把不同机制统一叫成"GPU 直连"后失去解释能力。

5.5 算子融合与通信融合需要满足数据依赖

算子融合可以减少中间张量写回 HBM、重复启动 kernel 和额外同步。例如局部矩阵结果出来后，直接执行缩放、打包或规约，比先写回、再启动另一个 kernel 读取，可能节省内存流量。

通信融合还可以把多个小操作组成一个较大块，摊薄启动开销。训练中将梯度按 bucket 归约，就是典型思路。但 bucket 太大，会等很久才凑齐，通信开始得晚；bucket 太小，启动和调度次数增加。

融合也可能破坏重叠。原来某一小块梯度早已就绪，可以立即发送；把它与晚就绪的大张量绑在一起后，整组都要等待后者。一次通信更高效，整个反向过程却可能更慢。

编译器和运行时因此要共同考虑张量布局、生命周期、执行资源和跨设备边界。静态图有利于预先规划内存和通信；动态长度、MoE 路由和连续批处理则要求运行时根据实际数据调整。

图捕获与重放可以降低主机重复提交开销，但重放所用地址、形状与依赖必须保持在机制允许范围内。缓存块重新分配、请求长度变化、通信组重建，都可能要求重新准备或使用更灵活的执行方案。超节点软件的复杂性，很大一部分来自在保持高效的同时处理这些变化。

5.6 Prefill 与 Decode 的资源特征为什么不同

Prefill 一次处理整段输入，通常有较多 token 可一起形成矩阵乘。Decode 则每条活跃序列逐次生成新 token，单请求在一个生成步里通常只增加少量 token，同时读取历史 KV。

这使两阶段的计算形状、批处理机会与带宽需求不同。较大矩阵的 Prefill 更容易利用计算吞吐；小 batch Decode 往往对权重读取、KV 访问和串行依赖敏感。大 batch、不同模型结构和缓存组织会改变主导因素，不能把"Prefill 计算受限、Decode 带宽受限"当作永远不变的分类。

服务指标也不同。TTFT 是请求到首个输出 token 的时间，包含排队、Prefill 和相关交接；TPOT 描述逐 token 输出节奏。用户可能同时要求首 token 快、后续输出稳定，这比只追求总 tokens/s 更严格。

如果一批很长的 Prefill 与 Decode 混排，可能占用计算和内存资源，使已在生成的请求等待。把 Prefill 切成较小块、调整调度优先级，或把两阶段分到不同资源池，都是缓解方法，适用条件不同。

5.7 PD 分离把执行干扰换成显式 KV 交接

图15：Prefill、Decode 和缓存资源池的关系。作者绘制。箭头表示可选的数据交接路径，不表示所有部署都同时采用全部路径。

图15左上是请求入口，它决定请求去哪组 Prefill 资源。Prefill 计算输入并形成 KV，随后 Decode 池接收相应状态继续生成。下方缓存池保存可复用前缀、历史请求或其他受管理块，减少重复计算，并帮助独立扩展容量。

PD 分离的直接收益，是两阶段可以分别选择 batch、并行度和资源规模，减少彼此干扰。DistServe 将资源配置、放置和服务时延目标联合优化，强调的是满足 SLO 的有效吞吐，而非只看裸吞吐。DistServe 原始论文。

代价是 KV 交接。沿第三章的教学模型，一条 32768 token 序列有 10 GiB 常规 KV。若完整状态需要经过一条 50 GB/s 的有效路径，理想数据时间约为 215 ms；400 GB/s 则约为 26.8 ms。它们只是 M / B M/B M/B，尚未计入布局转换和控制开销。

如果 KV 已按 rank 分片，并经多条独立路径并行交付，单路径负担可以降低；如果跨阶段的 TP 度不同，分片布局就可能需要重新分发。比如 Prefill 使用 TP=8、Decode 使用 TP=4，对应 KV 头或序列块的归属可能变化，不能简单把同编号 rank 一对一发送完就认为交接完成。

实际系统还可以在 Prefill 过程中分层或分块传输部分 KV，尽量与计算重叠；利用共享前缀减少新传数据；或者让缓存层成为中间交换位置。是否改善 TTFT，要看额外传输暴露了多少时间，而不是只看总字节数。

模型也会改变账本。MLA 保存的缓存表示不同，量化降低每元素字节数，前缀命中减少需要重算和搬运的部分。比较 PD 分离系统时，必须对齐模型、缓存格式、输入长度、并发和服务要求。

5.8 连续批处理与缓存调度是同一个容量问题的两面

连续批处理允许不同请求在生成步之间进入和退出执行批次，提高资源利用率。请求长度不同、结束时间不同，调度器持续调整活跃集合。

这会把缓存管理变成实时调度问题。新请求加入前，要有足够 KV 容量；已有请求增长时，要及时追加块；请求结束后，要释放私有块并更新共享前缀引用。如果容量不足，系统可能暂停请求、交换缓存、减少并发或拒绝新请求，每种选择都会影响时延。

在相同硬件与到达负载下，方案 A 可以等待更多请求组成大 batch，提高权重复用与吞吐，却可能增加排队时间；方案 B 更及时地执行较小批次，可能牺牲部分吞吐，以满足更严格的时延目标。实际 TTFT、TPOT 与吞吐的变化必须联合测量，不能只由 batch 大小直接断定。选择哪一种，应由服务目标决定。

缓存命中率也要和实际收益对应。命中一段很短前缀，与命中一段需要大量 Prefill 计算的长前缀，价值不同；命中后还要长距离搬运，则收益取决于传输时间和原计算时间。可以用：

Δ T ≈ T r e c o m p u t e a v o i d e d − T l o o k u p − T f e t c h − T l a y o u t \Delta T\approx T_{\mathrm{recompute\ avoided}}- T_{\mathrm{lookup}}-T_{\mathrm{fetch}}-T_{\mathrm{layout}} ΔT≈Trecompute avoided−Tlookup−Tfetch−Tlayout

判断某次命中是否值得。容量池化、地址索引和高速互连只有共同降低右侧这些开销，才会把命中变成端到端收益。

5.9 隔离既包括地址，也包括共享带宽与故障

同一超节点可能运行多个任务或租户。地址隔离确保任务 A 不能访问任务 B 的内存；交换分区限制哪些端点可以通信；资源配额和调度则减少带宽与计算争用。

这些隔离不完全等价。两个任务即使不能互访，也可能共享某些交换芯片、链路、电源和冷却资源。一方持续 All-to-All，另一方的小消息尾时延可能上升。硬件分区边界也未必与机柜边界、操作系统边界相同。

NVIDIA 的 Fabric Manager 与 NVLink 分区资料明确涉及拓扑发现、路由、分区和故障监控。管理服务是否正常、配置是否一致，会影响高速互连是否真正可用。Fabric Manager 文档、NVLink 分区管理。

对于内存池，命名空间隔离还要配合实际访问授权。仅在 SDK 中给 key 加前缀，不能替代硬件访问范围和租户身份校验；反过来，有硬件权限也不能代替正确的对象生命周期和上层索引。

5.10 容错不能停留在链路重传

物理层可通过 FEC 纠错，链路层可通过校验与重传处理传输错误，路由机制可以绕过故障链路，设备可以隔离损坏页，作业可以从检查点恢复。它们对应不同层级的故障，恢复能力不能相互替代。

链路暂时出错后，若重传成功且语义保持完整，上层可能只感受到时延增加。若 GPU 故障导致其持有的激活、梯度或优化器状态丢失，单纯绕路并不能重建这些数据。

应用层重试也要考虑幂等性。重新发送一个"把目标缓冲写为确定内容"的操作，与重新执行一次"对远端计数器加一"，效果不同。后者重复执行可能把值多加一次。协议必须识别重复、规定完成边界，或让上层采用可安全重试的设计。

训练检查点应保存足以恢复的模型状态、优化器状态、步数及必要随机或数据进度。分布式各分片还必须属于相互一致的逻辑时刻，不能随意拼接不同步的参数。

推理则更多涉及请求重试、KV 恢复、前缀重新计算和流式输出状态。已经向用户输出的 token 不能简单"撤回重算"；恢复路径要维护会话语义，避免重复输出或跳过内容。

5.11 检查点频率是一个可计算的取舍

教学设定中，写一次检查点耗时 C C C，相邻检查点间隔为 T T T，作业级平均故障间隔为 M M M。忽略恢复和其他开销，检查点造成的时间占比约为 C / T C/T C/T；故障平均丢失半个间隔的工作，损失约为 T / ( 2 M ) T/(2M) T/(2M)。

f ( T ) ≈ C T + T 2 M f(T)\approx\frac CT+\frac{T}{2M} f(T)≈TC+2MT

求导得到近似最佳间隔：

T ∗ ≈ 2 C M T^*\approx\sqrt{2CM} T∗≈2CM

假设 C = 60 C=60 C=60 秒、 M = 6 M=6 M=6 小时即 21600 秒，则 T ∗ ≈ 1610 T^*\approx1610 T∗≈1610 秒，约 26.8 分钟。若在同一简化模型下把有效检查点成本 C C C 改设为 15 秒，其他条件不变，则间隔约为 13.4 分钟。实际异步检查点还存在后台持久化延迟、带宽干扰和故障时可用快照的滞后；不能仅把前台阻塞时间代入，就认定已得到真实系统的最优间隔。

这个模型的意义是连接恢复机制与存储成本。它不是生产参数推荐；真实故障并不一定独立、稳定或服从相同分布，异步检查点也有后台带宽和一致性约束。节点扩容、共享电源和冷却故障还会引入相关失败。

更大域增加可用资源，也增加参与组件数量。若简单假设 N N N 个组件失效过程独立且具有恒定故障率，每组件故障率为 λ \lambda λ，且任意一个故障都会中断任务，则作业故障率近似 N λ N\lambda Nλ。真实系统可以通过冗余和局部恢复放宽"任意故障都中断"的假设，但必须有对应实现。

因此，衡量系统能力应计算长期有效训练时间或满足 SLO 的服务量。短时间内跑得很快、却频繁重启和恢复，未必比峰值稍低但稳定的系统产出更多。

5.12 从现象到原因的一条排查路径

假设模型扩展到更多 GPU 后，单步时间没有下降。首先分解时间线：计算、通信、等待、数据加载和检查点各占多少。接着确认通信组与实际拓扑，检查高频通信是否意外跨过较弱边界。

如果通信等待长，继续区分是在等待数据产生、发送启动、网络传输、目标处理还是完成同步。链路吞吐低，可能是源端未及时产生数据，不必然是链路故障；链路吞吐高，也可能主要在传填充、重复数据或重试。

如果计算时间变长，检查矩阵形状是否因并行切分过细而变差，通信 kernel 是否抢占资源，显存带宽是否被额外读写消耗，设备是否降频。

如果只有尾部 rank 很慢，检查专家偏斜、请求长度、共享网卡、重传计数、温度及相邻任务干扰。通过最大值、分位数和逐 rank 时间定位，通常比只看全局平均值有效。

这一排查过程把文章前半部分的机制重新接起来：协议、内存、算法和调度都可能限制同一个模型。最后再用公开系统案例和工程约束，检验这套分析方法。

六、把关键技术放回完整系统：案例、工程边界与性能判断

6.1 NVL72 展示的是柜级互连与软件管理的组合

GB200 NVL72 的典型公开配置包括 36 颗 Grace CPU、72 颗 Blackwell GPU，计算托盘通过 NVLink 交换系统形成紧耦合域。这套系统的意义，是把原先更局限于单个服务器的高速 GPU 互连扩展到柜级。NVIDIA GB200 NVL72 产品与系统说明。

从前文的框架看，它同时涉及三条路径：GPU 内部连接 HBM 的本地路径；GPU 之间通过 NVLink/NVSwitch 的路径；CPU 与 GPU 之间通过 NVLink-C2C 等机制连接的路径。产品还保留用于域外扩展与管理的网络，这些路径不能在参数表中简单合成一个"总带宽"。

较大的高速域允许更大的 TP 或 EP 通信组留在域内，也让软件有更多放置选择。但如果一个模型在 8 GPU 已经达到较好的计算通信平衡，直接把 TP 增大到 72，并不自动最优，甚至可能因头数、张量维度和实现的整除约束而不可用。它可能更适合运行多组副本、若干中等规模 TP 组，或采用其他并行组合。

跨托盘直接访问仍依赖内存导入导出、通信组与管理服务。NVLink 域可以包含多个独立操作系统实例，单域并不等同于单一 OS。IMEX 和 Fabric 管理组件正是理解这一点的重要入口。

物理实现同样值得注意。NVIDIA 向 OCP 贡献的设计包括机柜、计算与交换托盘、液冷环境及线缆组件相关设计。它说明高速域扩大不是仅仅更换通信库，还要重新组织机柜空间、连接器、供电、冷却和维护路径。NVIDIA 的 OCP 设计说明。

6.2 CloudMatrix384 的七子平面结构可以直接做带宽守恒检查

CloudMatrix384 论文披露了 384 个 Ascend 910C NPU、192 个 CPU 的系统，以及 UB、RDMA、VPC 三类网络平面。论文中的 NPU package 与 die 不是同一个计数单位：一个 910C package 包含两个 die，表格中有些访问测试按 die 报告。因此，比较前应先确认单位。CloudMatrix384 论文 §3。

图16：依据 CloudMatrix384 论文 §3.3.3 对交换关系重新绘制。仅展开一个子平面，其余结构用相同方式重复。所有带宽为论文披露的单向标称口径。

图16左侧代表一个计算节点，内含 8 个 NPU、4 个 CPU 和 7 个板上 L1 UB 交换芯片。中间七个框对应七个 UB 交换子平面，每个 L1 分别接入一个子平面。右侧展开其中一个：该平面有 16 个 L2 交换芯片，每个 L2 连接所有 48 个计算节点。

论文给出的每条相关上行链路为 28 GB/s，一个节点在每个子平面连接 16 条，上行合计 16 × 28 = 448 G B / s 16\times28=448\ GB/s 16×28=448 GB/s。七个平面合计 7 × 448 = 3136 G B / s 7\times448=3136\ GB/s 7×448=3136 GB/s，与节点中 8 个 NPU 各 392 GB/s 的单向接入之和一致。这是按披露配置进行的守恒核算，不是应用实测值。

这个图说明"多平面"具体增加了什么：同一节点拥有多组并行上行，而每组又连接多个 L2。流量能够分摊，但软件和协议必须实际利用这些资源；CPU、内存访问和并发任务也可能竞争其中的能力。

此外，论文中的内存池是由软件管理的 DRAM 资源：MP SDK 提供访问接口，控制器维护元数据，服务器管理本地容量。它说明池化除了硬件直访，还需要索引、注册、分配和生命周期管理；不能画成一个无人管理的全局数组。同论文 §4.4。

这里仅用披露配置解释结构，不据此宣称它在任意任务上优于另一系统。跨系统比较还需对齐模型、精度、batch、时延约束、统计范围和功耗。

6.3 UB 规范、UB-Mesh 与具体产品应保持边界

互连规范给出系统与设备之间需要遵守的行为；网络架构给出如何组织节点与路径；产品则选择某一组芯片、端口、线缆和软件实现。三者存在联系，却没有一一等价关系。

UB-Mesh 的高维局部化思路，适合用来解释如何根据流量局部性分配不同维度的带宽。CloudMatrix384 的具体交换结构，则适合用来解释多平面和带宽守恒。把二者合并成"华为所有产品都是同一张网"，会丢失版本与实现差异。

灵衢社区截至本文核对时列出基础规范 2.1，以及固件、兼容性测试、操作系统和系统管理等参考设计。这个文档集合反映了互连生态需要覆盖硬件行为、操作系统、接口和运维。本文没有把目录说明当作对规范全文实现细节的验证，也不把某一公开参考设计自动视为全部已部署产品的实现。灵衢官方文档入口。

这种区分对所有厂商都适用。规范支持最大端点数，不等于交换芯片已经以相同规模部署；某种路由算法在论文中有效，不等于所有固件默认采用；硬件提供原子操作，不等于上层框架已经使用。

6.4 开放互连真正需要互操作的层次

UALink 等开放路线的价值，不只在于公布链路速率，而是让加速器、交换芯片、线缆、固件和软件围绕共同接口协作。一个端点能够发出符合规范的事务，另一端才有机会正确理解并完成。

互操作至少需要四层一致：物理信道能训练和稳定传输；链路能够正确处理流控、错误和重试；事务能够表达相同操作与顺序；软件能够发现资源、建立映射并执行隔离。

还要验证压力下的边界：小报文包率、大块吞吐、信用耗尽、乱序到达、目标拒绝、链路异常、进程退出、分区变化。只有"正常情况下两端能互发一个包"，距离可用于训练的互操作仍有很大差距。

开放规范也不意味着现有软件自动兼容。通信库仍要适配硬件能力，编译器与框架仍要理解数据布局，运维工具仍要认识计数器和故障类型。成熟度应由实际可用设备、驱动、通信栈、测试与应用验证共同判断。

6.5 供电为什么是持续性能的一部分

高密度机柜把计算、交换和内存集中到较小空间。供电系统要把设施电源转换为机柜和板级可用电压，再由稳压模块提供芯片所需电源。每一级都有转换效率、导体损耗和动态响应限制。

先看基本关系：

P = V I , P l o s s = I 2 R P=VI,\qquad P_{\mathrm{loss}}=I^2R P=VI,Ploss=I2R

教学设定机柜需要 120 kW，如果在某一级用 48 V 传输，电流量级为 2500 A。这里是等效总电流，实际会由多路模块和导体分担。如果在更高电压的级别传输相同功率，电流相应降低，导体上的 I 2 R I^2R I2R 损耗也有机会减小。

但电压提高后，需要适当的电气间隙、绝缘、保护、连接和变换设计；不能仅凭一个平方关系就断言整体效率一定提升多少。该级导线损耗、转换器损耗和保护系统成本要一起计算。

计算负载还具有动态性。多个 GPU 同步进入大矩阵乘，功率可能一起上升；进入通信等待时又下降。电源要处理负载阶跃，控制电压下陷和瞬态响应。平均功率符合预算，不保证瞬态都满足要求。

如果功率上限触发降频，某 rank 的计算或通信服务速度下降，其他 rank 可能随之等待。供电调度、频率策略和模型时间线因此会相互影响。峰值算力规格只描述某些条件下的能力，持续性能还要看整柜能否稳定供给。

6.6 冷板、CDU 与设施回路怎样传走热量

图17：供电路径与典型双回路冷却框架。作者依据基本电气原理与 OCP 冷板/CDU 定义绘制。

图17上半部表示电能流向芯片，下半部表示热量离开设备。芯片通过热界面材料和冷板，把热传给设备侧冷却液；分水器把流量分到不同支路；热液返回 CDU，在换热器中向设施侧传热。两侧液体通常通过换热器隔离，便于分别管理压力、水质和材料兼容性。OCP 冷板开发与验证白皮书。

最基本的热量平衡为：

Q ˙ = m ˙ c p Δ T \dot Q=\dot m c_p\Delta T Q˙=m˙cpΔT

Q ˙ \dot Q Q˙ 是单位时间带走的热量， m ˙ \dot m m˙ 是质量流量， c p c_p cp 是比热容， Δ T \Delta T ΔT 是供回液温差。

教学设定需要带走 100 kW 热量，流体近似为水，取 c p = 4180 J / ( k g ⋅ K ) c_p=4180\ J/(kg\cdot K) cp=4180 J/(kg⋅K)，温升为 10 K，得到：

m ˙ = 100000 4180 × 10 ≈ 2.39 k g / s \dot m=\frac{100000}{4180\times10}\approx2.39\ kg/s m˙=4180×10100000≈2.39 kg/s

按密度约 1 kg/L 换算，约为 144 L/min。这个数只是能量守恒所需流量的量级，不是具体机柜的液冷设计值。实际冷却液成分、温度、压力、支路分布、冷板热阻和泵效率都会改变设计。

流量充足还不代表每颗芯片都足够冷。某个支路阻力偏大，可能分不到足够流量；冷板接触不良或内部流道设计不合适，局部热点仍然存在。泵需要克服压降，泵功率近似与压差乘体积流量相关，并要考虑效率。

把微通道做得更细，有机会提高局部换热，但也可能提高压降、颗粒堵塞风险和制造要求。冷却液水质、过滤、腐蚀、接头密封和材料兼容性，都影响长期稳定性。OCP 的冷板工作也把冷板、软管、分水器、快接和 CDU 作为整体系统的一部分。OCP Cold Plate 项目。

液冷也不表示所有部件都无需空气流动。电源、部分存储、光模块和其他器件可能仍需要风冷或其他热设计。判断方案时应确认液冷覆盖范围、剩余风量和整机热路径。

6.7 电、热、网络会通过同步把局部问题放大

设 8 个 rank 每轮共同完成一次计算和归约。7 个 rank 的计算各 4 ms，另一个因热限制需要 5 ms，归约与其他开销为 1 ms。若大家必须等最慢者，轮时间约为 6 ms，而不是按平均计算时间得到的 5.125 ms。

局部降频造成的 1 ms 差距，传播成整组共同等待。类似现象也会由网卡拥塞、内存热点和通信重试引起。

这解释了为什么系统监控应包含温度、功率、频率、纠错与重传、端口利用率、kernel 时间和逐 rank 等待。只看 GPU 利用率百分比，可能无法区分在执行有用矩阵计算、忙于通信打包，还是持续轮询等待。

维护动作也要考虑共同故障域。更换一个计算托盘可能影响关联的供电、液冷接头和通信分区；某个 CDU、母排或交换平面故障可能同时影响多颗卡。冗余设计应该对应这些实际共享组件，而不只是准备一张备用 GPU。

6.8 用三条带宽屋顶判断程序可能受限在哪里

经典 Roofline 将性能与计算强度联系：若跨指定内存边界每传输一字节完成 I I I 次浮点运算，带宽上限为 B H B_H BH，则该路径给出的性能屋顶为 B H I B_HI BHI。字节数应包含该边界上的实际读取与写入，并按缓存过滤后的流量统计。Williams 等的原始 Roofline 论文。

超节点还需要增加网络维度。先以单个 rank 为对象，设其计算量为 F F F，本地 HBM 实际流量为 M H M_H MH，选定网络瓶颈方向的流量为 M N M_N MN，可用算力上限为 P P P，对应可用带宽上限为 B H B_H BH、 B N B_N BN，可以建立一个理想资源下界：

T ≳ max ⁡ ( F P , M H B H , M N B N ) T\gtrsim\max\left(\frac FP,\frac{M_H}{B_H},\frac{M_N}{B_N}\right) T≳max(PF,BHMH,BNMN)

这是资源约束下的下界，并不要求实际执行已经重叠；只有相关工作能够充分重叠且没有其他瓶颈，执行时间才可能接近它。全双工链路应分别核算发送、接收方向的流量与带宽，再取约束更紧者，不能将两方向流量相加后除以单向带宽。全作业还要取最慢 rank，并检查共享链路和网络割集的总负载。若某段通信必须等计算完成后才开始，就应按真实依赖把对应时间相加；启动、同步和不均衡也会让实际时间更长。

将 I H = F / M H I_H=F/M_H IH=F/MH、 I N = F / M N I_N=F/M_N IN=F/MN 分别定义为相对于 HBM 与网络的数据强度，就得到三类上限：计算峰值、本地内存供数能力、跨卡供数能力。哪个最先触顶，取决于模型与实现。

小 batch Decode 可能需要从 HBM 读取大量权重，却只完成较少 token 的运算；增加 batch 可以复用权重、提高算术强度，但又增加 KV 占用、每步工作和排队时延。TP、EP 则可能降低每卡存储和计算，却增加网络依赖。所有优化都能在这个账本中找到对应变化。

需要特别区分"模型参数大小"和"实际 HBM 流量"。缓存复用、算子融合、激活重算、通信打包、量化解码都会改变实际读取写入次数。用参数字节数直接代替所有内存流量，只能作为特定条件下的近似。

6.9 为什么提高十倍互连带宽，模型可能只快一小部分

假设原执行时间 100 ms，其中 30 ms 是暴露在关键路径上、不能被计算隐藏的通信，70 ms 为其他工作。仅这部分通信加速 10 倍，总时间变为：

70 + 30 / 10 = 73 m s 70+30/10=73\ ms 70+30/10=73 ms

整体加速比约为 100 / 73 = 1.37 100/73=1.37 100/73=1.37。即使把这 30 ms 通信完全消除，极限也只有 100 / 70 ≈ 1.43 100/70\approx1.43 100/70≈1.43。

如果通信原先大部分已被隐藏，换更快链路的可见收益会更小。反过来，更大高速域可能允许改变并行策略、减少权重复制、扩大有效 batch 或减少跨域交换，这些结构变化可以带来超出"原通信时间简单缩短"的收益。

所以，评价新互连时要分清两种问题：固定模型配置下，仅替换通信路径有多少收益；允许重新选择并行与调度后，整个系统能达到什么服务目标。两种测量都合理，但回答的问题不同。

这也解释了为什么厂商发布的倍数需要完整条件。不同精度、输入输出长度、batch、延迟目标、系统规模和软件版本，都可能改变比较结果。把一个特定推理配置的加速倍数直接推广成"所有 AI 工作负载快同样倍数"，缺少因果依据。

6.10 一套能复现的性能验证应分层进行

第一层验证链路和路径。测试不同 GPU 对、GPU---网卡路径、本地与远端内存，区分单向与双向、读与写、小消息与大消息、单对端与多对端并发，记录实际链路状态和错误计数。

第二层验证集合通信。对 AllReduce、AllGather、ReduceScatter、All-to-All 分别扫描消息大小与通信组规模，记录完成时间、输入输出口径、算法与通道配置。MoE 还要测试均衡和偏斜路由，不能只测等大小均匀交换。

第三层验证算子链。将通信接到 GEMM、注意力、打包与重排中，检查设备资源争用和真实重叠。通信独立测试快，不保证与计算共存时仍然快。

第四层验证模型与服务。训练看稳定单步时间、有效吞吐、精度与恢复；推理看 TTFT、TPOT、吞吐、请求长度、并发与 SLO 达标比例。这里需要长期运行和尾部分布，而不仅是一轮最好成绩。

第五层验证生产约束。观察功率、温度、降频、共享任务干扰与故障恢复；把恢复时间和丢失工作计入有效产出。该层决定实验室峰值是否能在真实系统里持续获得。

观测现象	优先检查的机制	有帮助的证据
单对端快，全体同时慢	收敛、出口热点、多路径分配	并发流量矩阵、切面带宽、队列与端口计数
大块快，小读很慢	启动、事务并发、地址依赖	消息扫描、outstanding 数量、访问分布
通信单测快，与 GEMM 并行后慢	SM、HBM 与缓存竞争	时间线、执行资源与内存活动
EP 扩展后尾部变长	专家偏斜、实际专家批量与本地 GEMM 形状、路由跨度	每专家 token 数、GEMM 形状、逐 rank 延迟
TP 扩大后时延反升	小矩阵效率、同步轮数、跨域路径	TP 扫描、算子耗时、通信组映射
缓存命中增加却未提速	取数与转换成本超过重算收益	命中字节、避免计算量、实际 fetch 时间
平均性能好，长期产出低	故障、热限制、恢复与排队	长时间日志、故障时间线、SLO 达标量

这些验证不要求每个读者亲自拥有一套超节点，也可以用于阅读公开测试：检查对方给出的数据究竟覆盖哪一层，是否足以支撑其结论。

6.11 把一个 MoE 层从路由到完成重新连起来

现在沿一次完整执行重走技术链。

模型产生一批 token 隐藏向量，路由器给出专家编号与权重。运行时根据专家放置表把编号转换成目标 rank，计算每个目标的 token 数和缓冲区偏移。打包算子把数据组织成可传输、可供专家读取的布局。

源端通过已建立的通信窗口发起传输。事务接口表达相应数据操作，路由与交换逻辑选择路径，链路层检查信用和可靠性，SerDes 把数据送过铜缆或光链路。若某出口拥塞，流控把等待传播给上游；如果发送窗口不足，链路会在等待响应时空闲。

目标端校验地址和权限，把数据写入正确缓冲区。完成与通知机制保证专家计算启动时，输入已经按接口要求可见。专家 kernel 执行矩阵运算，读取本地权重和输入，结果按照原映射送回源端。

源端等待所需专家结果，恢复 token 顺序并加权合并，再交给后续层。若分块调度得当，可以让已就绪 token 的计算、其他块的传输和回收形成流水；但同一个结果的必要依赖依然存在。

管理与监控在旁维护整个过程：哪条路径可用，哪些映射仍有效，链路是否重试，哪个专家负载过重，哪个 GPU 降频，缓冲区能否复用。故障发生时，它还要明确是链路重发即可恢复，还是必须重建通信组和任务状态。

这一条链中，任何一处都可能改变最终时延。超节点的关键技术，正是让这些接口既能高效前进，又保持相同的计算含义。

6.12 技术结论：超节点扩大的是高效协作的可选空间

超节点将更多计算与内存资源纳入高速可达范围，使模型切分不再那么容易被传统服务器边界限制。但硬件扩大的是可选空间，软件还要在其中找到合适的配置。

互连带宽决定单位时间能搬多少数据，时延与并发窗口决定细粒度操作能否跟上；交换拓扑决定大规模流量能否同时通过；地址与内存序决定取到的数据是否有效；集合通信与并行算法决定必须交换什么、哪些交换可以消除；调度与运行时决定这些操作何时发生；电力、冷却和恢复决定性能能够持续多久。

由此判断一套系统，不宜只问它有多少卡、多少 TB/s。更有解释力的问题是：对这个模型、这组并行配置和这个服务目标，哪些数据必须跨设备，路径在哪里，完成依赖是什么，系统用多少时间和资源把它们交给消费者？

当这些问题能够被逐项回答，机柜里的芯片、交换、内存和软件才真正组成一个可理解、可验证、可优化的计算系统。

术语与阅读索引

术语	本文采用的含义	首次重点讲解
Scale-up 域	适合紧耦合协作的高速互连计算范围	第一章
Scale-out	将多个计算域或节点连接成更大集群	第二章
Fabric	包括链路、交换、路由与相关控制的互连结构	第二章
Lane / Link / Port	物理通道、逻辑链路与端口，依规范定义区分	第二章
Credit / VC	缓冲信用与虚通道	第二章
SerDes / FEC / CRC	串行收发、前向纠错、循环冗余校验	第二章
HBM / DRAM	高带宽内存、动态随机存取存储器	第三章
MMU / TLB	地址翻译单元、翻译缓存	第三章
P2P / RDMA / DMA	对等访问、远程直接内存访问、直接内存访问	第二、三章
PGAS / 单边操作	分区全局地址空间及一侧发起的访问模型	第三章
Rank / PE	分布式逻辑成员编号、处理单元编号	第一、三章
TP / EP / PP / DP / CP	张量、专家、流水线、数据、上下文并行	第四章
KV Cache	注意力推理所需历史状态；具体表示依模型而定	第三章
Prefill / Decode	输入处理阶段、逐步生成阶段	第五章
TTFT / TPOT / SLO	首 token 时间、每输出 token 时间、服务目标	第五章
CDU / TCS / FWS	冷却液分配单元、技术侧冷却回路、设施水系统	第六章

参考资料与图文说明

本文机制分析优先使用原始论文、官方文档与项目代码。以下按主题汇总阅读入口；具体事实的直接出处在正文相邻位置给出。论文中的性能数字适用于其测试条件，本文没有将其整理成跨厂商性能排名。

NVIDIA：GB200 NVL72 产品、多节点调优指南、系统结构。用于核对柜级配置与互连口径。
NVIDIA：Blackwell Ultra 技术说明、NVLink 与 NVSwitch 技术说明。用于核对 NVLink、C2C 和交换相关能力。
NVIDIA：CUDA C++ Programming Guide 13.0、Unified Memory 专题、GPUDirect RDMA。对应 P2P、地址、同步与内存行为。
NVIDIA：NVSHMEM 使用文档、NCCL 集合通信、NCCL GIN API、NCCL tests 带宽口径。对应单边操作、设备发起、集合语义与测试指标。
NVIDIA：Fabric Manager、IMEX 概述、NVLink 分区。对应跨主机映射与互连管理。
Narayanan 等：Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM；NVIDIA：Megatron Core 并行策略、上下文并行。对应并行切分与跨层映射。
DeepSpeed：ZeRO 官方教程、ZeRO 配置文档。对应参数、梯度与优化器状态分片。
DeepSeek-AI：DeepSeek-V3 Technical Report，v2；DeepEP 官方项目。对应 MoE 通信、路由、流水线和工程实现。项目主分支持续变化，本文不将历史后端当作当前固定依赖。
Dao 等：FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness。对应分块计算和减少存储 I/O 的研究背景；正文 softmax 例子由作者设置并推导。
Kwon 等：Efficient Memory Management for Large Language Model Serving with PagedAttention。对应 KV 分页与共享。
Zhong 等：DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving。对应 PD 分离与服务目标优化。
Zuo 等，Huawei 与 SiliconFlow：Serving Large Language Models on Huawei CloudMatrix384，v1。重点参考 §3.2---3.3、§4.4，分别核对交换结构、计数单位和内存池。
Liao 等，Huawei：UB-Mesh: a Hierarchically Localized nD-FullMesh Datacenter Network Architecture，v1。重点参考 §3---5，区分协议、拓扑、路由和模型放置。
UnifiedBus 社区：官方文档入口。用于核对当前文档体系和版本目录；本文未声称逐条验证基础规范全文。
UALink Consortium：Introducing UALink 200G 1.0 Specification、规范版本目录。重点参考白皮书的 station、分层和链路说明，区分 1.0 与后续版本。
Ultra Ethernet Consortium：官方技术说明。用于理解传输与拥塞管理的相关演进。
NVIDIA：GB200 NVL72 向 OCP 贡献的设计；OCP：冷板项目、冷板开发与验证白皮书。对应机柜工程、冷板、CDU 和冷却回路。
参考阅读：《AI超节点基础知识全解（第二版）》，架构师技术联盟出品，本地参考文件，共 211 页。本文将其用于建立覆盖线索，并独立核对关键产品与机制；其中缺少原始出处的定量断言未直接作为本文事实依据。
CXL Consortium：一致性与协议问答。用于解释 CXL.io、CXL.cache、CXL.mem 的基础分工；该资料对应其发布时期，本文没有用它描述所有后续版本。
NVIDIA：Per-Tensor and Per-Block Scaling Strategies for Effective FP8 Training。对应缩放机制；正文容量和量化误差例子为作者教学设定。

文中含 16 幅作者绘图及 1 幅 UALink 官方原图节选。图16依据指定论文披露关系重新组织，其余作者绘图为原理框架、数学关系或明确标注的教学设定。所有教学时延、带宽和容量算例用于解释机制，不是对真实部署的性能承诺。