端口模型与硬件成本
集合通信的理论下界（见 01-理论下界）依赖端口模型假设。本文从硬件实现角度分析实际系统中的端口模型、增加端口数的成本，以及何时端口数不再是瓶颈。
主流 AI 加速器的端口配置
| 硬件 | 端口数 $k$ | 互联技术 | 单端口单向带宽 | 总双向带宽 | 实现方式 |
|---|---|---|---|---|---|
| SG2260 | 2 | CDMA C2C | 64 GB/s | 256 GB/s | CDMA + VSDMA 双 DMA 引擎 |
| NVIDIA A100 | 6 | NVLink 3.0 | 25 GB/s | 600 GB/s | 12 条 NVLink（6 双向对），每条独立引擎 |
| NVIDIA H100 | 9 | NVLink 4.0 | 50 GB/s | 900 GB/s | 18 条 NVLink，需 NVSwitch 芯片 |
| NVIDIA B200 (NVL72) | 18 | NVLink 5.0 | 50 GB/s | 1800 GB/s | 18 条 NVLink + 9 颗 NVSwitch，72 GPU 全连接 |
| Google TPU v4 | 6 | ICI | 42 GB/s | 504 GB/s | 3D Torus，每维 2 条双向链路 |
| AMD MI300X | 7 | XGMI 3.0 | 64 GB/s | 896 GB/s | 7 条 XGMI links |
| InfiniBand NDR | ~all-port | RDMA | 50 GB/s | 取决于拓扑 | 多 QP 并发，硬件调度 |
关键观察：1-port 模型在实际硬件中不存在——所有主流互联都支持多链路同时传输。理论分析中使用 1-port 的价值在于给出最保守的下界，而非描述真实硬件行为。
增加端口数的硬件成本
增加端口数 $k$ 的成本来自三个层面：DMA 引擎、物理链路、交换网络。
DMA 引擎成本
每个独立端口需要一套完整的 DMA 子系统：
- 发送/接收 FIFO 缓冲区（通常 32-128 KB/端口）
- 地址转换单元（VA -> PA 映射）
- 流控逻辑（信用/反压机制）
- 中断/轮询状态机
以 SG2260 为例，从 1 端口（单 CDMA）到 2 端口（CDMA + VSDMA），互联子系统面积增加约 5-10%。但这部分成本相对较低——DMA 引擎在现代芯片中占比很小。
物理链路成本
更多端口意味着更多物理连线，成本随规模急剧增长：
| 互联规模 | 链路类型 | 单链路成本 | 主要成本构成 |
|---|---|---|---|
| 2-4 芯（板内） | PCB 走线 / C2C | ~$1/lane | PCB 层数、信号完整性 |
| 8 芯（单机） | NVLink bridge / 短铜缆 | ~$55/lane | 连接器、DAC 铜缆 |
| 16-32 芯（跨板） | 有源铜缆 AEC | ~$70-105/lane | 有源电缆、交换芯片 |
| 64+ 芯（跨机） | 光模块 AOC | ~$247/lane | 光收发器、光纤、交换机 |
NVIDIA NVL72 的互联成本结构：每 GPU 18 条 NVLink（每条 50 GB/s），需要 9 颗 NVSwitch 芯片（每颗 ~$500-1000）。仅交换芯片成本 $5000-9000，加上铜缆和连接器，互联成本占整机 BOM 的 15-25%。
交换网络成本
当 $k$ 超过直连邻居数量时，必须引入交换网络：
| 方案 | 支持的 $k$ | 额外硬件 | 成本级别 |
|---|---|---|---|
| 直连（Ring/Mesh） | $d$（拓扑度） | 无 | 零 |
| NVSwitch（单级） | 全连接 8 GPU | 1-2 颗 NVSwitch | $1000-2000 |
| NVSwitch（两级） | 全连接 72 GPU | 9 颗 NVSwitch | $5000-9000 |
| InfiniBand 交换 | all-port | 多级 Fat-tree 交换机 | $10k-100k/节点 |
收益递减分析
增加端口数的收益（通信时间缩短）与成本（硬件增加）之间存在明显的递减关系。
理论收益
以 Ring AllReduce 带宽项为例，$k$-port 下总时间为：
$$\begin{equation} T_{\beta}^{k\text{-port}} = \frac{2(N-1)}{N} \cdot \frac{M}{k \cdot \beta} \label{eq:port-kport-ring-time} \end{equation}$$从 $k$ 增加到 $k+1$ 的边际收益：
$$\begin{equation} \Delta T = T_{\beta}^{k} - T_{\beta}^{k+1} = \frac{2(N-1)M}{N\beta} \cdot \frac{1}{k(k+1)} \label{eq:port-kport-marginal-gain} \end{equation}$$边际收益以 $O(1/k^2)$ 速度递减：
| 从 $k$ 到 $k+1$ | 时间减少比例 | 边际硬件成本 | 性价比 |
|---|---|---|---|
| 1 -> 2 | 50% | 低（+1 DMA 引擎） | 极高 |
| 2 -> 4 | 25% | 中（链路翻倍） | 高 |
| 4 -> 8 | 12.5% | 高（需要交换芯片） | 中 |
| 8 -> 16 | 6.25% | 很高（多级交换） | 低 |
| 16 -> all-port | < 5% | 极高（全连接交换） | 仅大规模训练可接受 |
瓶颈转移
当 $k$ 足够大时，通信瓶颈从网络端口转移到其他子系统：
内存带宽瓶颈
DMA 引擎从 HBM 读取数据的速度有上限。以 H100 为例：
- NVLink 总带宽：900 GB/s（18 links x 50 GB/s）
- HBM3 带宽：3350 GB/s
NVLink 带宽占 HBM 带宽的 27%，尚有余量。但当多个 DMA 引擎同时访问 HBM 时，与计算单元争抢内存带宽，实际可用带宽下降。当 NVLink 利用率超过 ~60% 时，HBM 争抢开始成为瓶颈。
软件调度开销
多端口并行要求软件精确调度每个 DMA 引擎的传输顺序和同步点。端口数越多，调度复杂度越高：
- 2-port：两个方向独立，调度简单（如 SCCL 的左/右分工）
- 8-port：需要规划哪个 chunk 走哪条链路，避免目标端口冲突
- all-port：需要全局调度算法（如 NCCL 的 channel/ring 分配），软件开销本身成为延迟的一部分
PCIe / Host 接口
CPU 与加速器之间的数据通路通常是 PCIe（64 GB/s for Gen5 x16），远低于加速器间互联带宽。当集合通信需要跨 Host 时，PCIe 成为真正的瓶颈，此时增加加速器间的端口数毫无意义。
超越端口数：网内计算
当端口数增加的收益触及天花板，NVIDIA 选择了一条不同的路径——将计算下沉到交换网络中：
| 方案 | 每 GPU 传输量（AllReduce, $M$ 字节） | 需要端口数 |
|---|---|---|
| Ring（1-port） | $\frac{2(N-1)}{N}M \approx 2M$ | 1 |
| Ring（2-port） | $\frac{2(N-1)}{N}M \approx 2M$（时间减半，总量不变） | 2 |
| NVLS（网内规约） | $M$（发 $M$ + 收 $M$，交换机内部做规约） | 1（到 NVSwitch） |
NVLS 的思路是：与其让每个 GPU 搬运 $2M$ 数据（只是搬运速度更快），不如让 NVSwitch 芯片内部直接做规约运算，每个 GPU 只需发送 $M$（原始数据）和接收 $M$（规约结果）。这从根本上将传输量减半，突破了软件 AllReduce 的带宽下界。
详见 09-nvls。