Cost, Billing, and Ops2026年10月13日Flatkey Team

NVLink vs NVSwitch：面向 AI 集群的 GPU 互连解析

NVLink 是 GPU 之间的连接，NVSwitch 是互连交换结构，而 InfiniBand 或以太网则是横向扩展网络。以下介绍如何为 AI 集群做出选择。

NVLink vs NVSwitch：面向 AI 集群的 GPU 互连解析

如果你在比较 NVLink vs NVSwitch，简短答案是：

NVLink 是高带宽的 GPU 到 GPU 连接。
NVSwitch 是交换互连架构，它让许多通过 NVLink 连接的 GPU 彼此通信，而不必强迫每一对 GPU 都落在一条狭窄的点对点通道上。
InfiniBand 或 Ethernet 仍然是连接系统、机架、存储以及更大规模集群的横向扩展网络。

当你在租 GPU、购买 HGX 或 DGX 系统，或者决定某个工作负载是否真的需要直接访问集群而不是托管模型 API 时，这一区别就很重要。如果模型在等待 tensor-parallel 同步、all-reduce、all-gather、reduce-scatter 或 all-to-all 流量上耗费太多时间，那么再快的 GPU 也不够用。

本指南从实际集群角度解释 nvidia nvlink vs nvswitch 的差异：各组件分别做什么，InfiniBand 处于什么位置，拓扑何时会改变 LLM 性能，以及在投入昂贵的 GPU 集群架构之前应该问哪些问题。

NVLink vs NVSwitch：快速区别

层级	它是什么	典型范围	它改善什么	它不能替代什么
NVLink	直接的高带宽 GPU 互连	受支持的 NVIDIA 平台内部的 GPU 到 GPU 连接	张量并行、peer GPU 内存传输、scale-up 域内的集体通信	它本身不是集群网络
NVSwitch	用于 NVLink 端点的交换芯片和互连架构	取决于平台的多 GPU 服务器、基板或机架级 NVLink 域	全互连 GPU 通信、无阻塞或更高双向带宽的 GPU 互连、更大的 GPU 域	它不能消除集群横向扩展所需的 InfiniBand/Ethernet
InfiniBand / Ethernet	系统与机架之间的网络互连	节点到节点、存储、管理、多机架集群	跨多节点的分布式训练、存储访问、服务流量、调度域	它不能在节点内部为 GPU 创建本地 NVLink 带宽

nvlink vs nvswitch 的区别最容易记住的方式是 link vs fabric。NVLink 是 GPU 之间的道路。NVSwitch 是立交枢纽，让这些道路中的许多条能够汇聚，而不会把每一次传输都变成狭窄的点对点路径。

NVLink 做什么

NVLink 是 NVIDIA 用于 GPU 到 GPU 通信的高速互连。它专为那些在普通 PCIe 路径上代价很高的流量模式而设计：模型并行层、同步的张量分片、peer 内存访问，以及高频集体通信。

在当前公开的 NVIDIA 平台上，代际很重要：

平台代际	公开的 NVIDIA 参考点	每个 GPU 的 NVLink 带宽
Hopper	H100/H200 代	900 GB/s
Blackwell	B200/GB200 代	1,800 GB/s
Vera Rubin	已公布的下一代平台	3,000 GB/s 预估

对于基础设施买家来说，这些数字并不保证每个工作负载都能获得相应的加速。它们告诉你该拓扑可提供的通信上限。实际收益取决于模型大小、并行策略、batch 大小、sequence length、框架行为、部署位置，以及工作负载是否受通信限制。

当你的工作负载对一次请求、一个训练 step 或一个模型分片组使用多块 GPU 时，把 NVLink 作为购买信号。若每块 GPU 只处理彼此独立、几乎没有通信的作业，它的重要性就要小得多。

NVSwitch 做什么

NVSwitch 是把许多 NVLink 端点连接成更高带宽 GPU 互连架构的交换层。如果没有交换架构，多 GPU 系统可能会把每块 GPU 可用的链路预算分散到许多点对点连接上。有了 NVSwitch，受支持的系统可以让每块 GPU 到 NVLink 域中其他 GPU 的路径更均匀。

这就是为什么 nvswitch vs nvlink 不是两个替代品之间的选择。NVSwitch 使用 NVLink 连接来构建互连架构。交换机之所以有用，是因为八块、十六块或七十二块 GPU 的行为并不像两块用线缆直接连接的 GPU。

在 NVIDIA 的公开示例中：

DGX H100/H200 系统使用八块 H100 或 H200 GPU，并列出 900 GB/s 的 GPU 到 GPU 带宽，同时通过 ConnectX-7 InfiniBand/Ethernet 端口进行集群网络连接。
DGX B200 系统使用八块 B200 GPU，并列出两颗第五代 NVLink 交换芯片，总带宽为 14.4 TB/s；可在我们的 B200 vs H200 指南中比较购买取舍。
GB200 NVL72 在机架级设计中连接 36 颗 Grace CPU 和 72 块 Blackwell GPU；NVIDIA 将其描述为一个 72 GPU 的 NVLink 域，具备 130 TB/s 的低延迟 GPU 通信能力。关于平台选择，请参见 GB200 vs B200。

实际结论：随着一个 scale-up 域中的 GPU 数量增加，以及工作负载关键路径中 GPU 到 GPU 通信所占比例上升，NVSwitch 变得越来越重要。

NVLink vs NVSwitch vs InfiniBand

nvlink vs nvswitch vs infiniband 这个说法往往掩盖了三个不同的设计问题：

在单个 GPU 系统内：GPU 是否拥有足够的点对点带宽，以支持张量并行、流水线阶段或多 GPU 推理？
在单个机架级域内：许多 GPU 能否作为一个更大的加速器互连结构来运行，以支持大模型并行？
跨多个节点或机架：集群网络能否可预测地承载分布式训练、数据加载、存储、检查点保存和服务流量？

NVLink 和 NVSwitch 解决前两个问题。InfiniBand 或以太网解决第三个问题。

例如，配备 NVSwitch 的八 GPU HGX 或 DGX 节点，非常适合需要在节点内跨 GPU 进行紧密张量并行的模型副本。如果你需要数百或数千个 GPU，你仍然需要一个横向扩展网络。在 Blackwell 机架系统中，NVIDIA 将大型 NVLink 域与 InfiniBand 或 Spectrum-X 以太网结合起来，以扩展到机架之外。

不要问 NVLink 是否取代 InfiniBand。要问哪些流量应该留在 NVLink 域内，哪些流量必须跨越集群互连结构。

为什么 AI 工作负载关心拓扑

现代 LLM 工作负载不只是矩阵乘法。一旦模型被拆分到多个设备上，每一层都可能引入通信。

常见的通信模式包括：

All-reduce：每个 rank 贡献数值并接收归约结果。
Reduce-scatter 和 all-gather：张量并行和数据并行策略的常见构建模块。
All-to-all：每个 rank 向其他 rank 发送不同的数据块，这对某些专家并行和重路由密集型设计很重要。
KV 缓存和激活传输：实现方式相关，但通常对局部性和放置位置很敏感。

NCCL 将这些集合通信描述为跨 CUDA 设备的基于 rank 的操作。这很重要，因为软件看到的是 rank，而不是营销术语。只有当你的 rank 放置、框架、容器、NCCL 设置和调度器布局能让任务真正利用它时，一个好的互连结构才会带来帮助。

在 NVIDIA 关于 LLM 推理的讨论中，张量并行推理要求 GPU 在某一模型层完成工作后交换结果，之后下一层才能继续。当这种交换很慢时，Tensor Core 就会闲置。这正是 NVSwitch 对多 GPU 服务可能很重要的核心原因。

何时值得关注 NVSwitch

当以下情况之一成立时，应优先考虑基于 NVSwitch 的系统：

你提供的模型需要跨多个 GPU 进行张量并行才能达到延迟目标。
训练或微调任务在性能分析器中显示大量集合通信时间。
你计划运行大批量推理，而 GPU 间同步会随着并发增加而上升。
你需要在一个八 GPU 节点内实现每个 GPU 之间可预测的 all-to-all 通信。
你正在评估 GB200 NVL72 之类的机架级系统，其中 NVLink 域是主要产品特性。

在以下情况下，NVSwitch 的决定性会较弱：

任务是尴尬并行的，每个 GPU 执行独立工作。
工作负载受 CPU、存储或数据加载器限制。
模型能舒适地放入单个 GPU 并在其上提供服务。
应用调用托管模型 API，而不是直接管理硬件拓扑。
瓶颈在于节点间互连，而不是节点内 GPU 通信。

正确的问题不是“这块 GPU 有没有 NVLink？”而是“我的关键工作负载是否会让同一 NVLink/NVSwitch 域内的多个 GPU 忙碌到足以证明溢价合理？”

NVLink 与 NVSwitch 系统的采购清单

在租用或购买 GPU 集群之前，请使用这份清单，并在签订长期预留之前结合 GPU 集群 TCO 评估。

问题	为什么重要
提供的确切 GPU SKU 和外形规格是什么？	H100 PCIe、H100 SXM、H200、B200 和 GB200 系统可能暴露出非常不同的拓扑和带宽。
系统是仅 NVLink 点对点、基于 NVSwitch，还是机架级 NVLink 域？	“支持 NVLink”还不够。你需要了解互连结构的形态。
一个 NVLink 域里有多少块 GPU？	域大小会影响张量并行和模型并行的放置选项。
节点间网络是什么：InfiniBand、RoCE、Spectrum-X Ethernet，还是普通以太网？	NVSwitch 不能修复薄弱的横向扩展网络。
是否可以针对所租用的确切形态运行 NCCL 测试？	合成集合通信可以揭示拓扑、驱动、链路和容器是否配置正确。
是否可以独占整个节点或域？	共享租用可能破坏对局部性和可重复性的假设。
是否有网络通道和 NIC 放置文档？	大规模下，NCCL 可能需要正确选择接口和考虑通道感知的放置。
当某个 GPU、交换托盘或 NIC 性能下降时会发生什么？	弹性和更换策略会影响生产可用性。
长期预留前必须通过什么基准测试？	可接受输出的成本比单纯的每小时价格更有用。

基准测试计划：在预留之前验证互连结构

对于高成本的 GPU 预留，在承诺长期使用之前先运行一次拓扑验收测试。

盘点拓扑。 采集 nvidia-smi topo -m、GPU SKU、驱动、CUDA、NCCL 版本、NIC 和容器镜像。
运行 NCCL 集合通信。 针对与你工作负载相似的消息大小，测试 all-reduce、reduce-scatter、all-gather 和 all-to-all。
测量真实工作负载延迟。 使用你的实际模型、上下文长度、批处理策略和并行设置。
比较同域与跨节点部署。 检查调度器是否意外将 rank 移动到了更慢的路径上。
跟踪每个可接受输出的成本。 对于推理，衡量每美元可接受 token 数或成功响应数，而不只是每秒 token 数。对于训练，衡量每美元的 loss 进展或已完成样本数。
记录故障行为。 如果提供商允许，可杀死一个 worker、重启一个容器，或模拟一个降级的 NIC。

如果提供商无法告诉你拓扑，或无法运行基础 NCCL 基准测试，那就应把这视为风险信号。小时费率也需要结合 GPU 租赁价格、容量承诺、网络附加费用和失败运行成本来理解。

常见错误

错误 1：把 NVLink 当作 NVSwitch 的同义词。 一个平台可以提供 NVLink 连接，但并不一定像由 NVSwitch 支持的系统那样具备同样的 all-to-all 行为。

错误 2：以为 NVSwitch 消除了网络设计的必要。 NVSwitch 有助于 scale-up 的 GPU 域。多节点训练仍然需要严肃的 InfiniBand 或以太网设计。

错误 3：为彼此独立的任务购买带宽。 如果每块 GPU 运行一个独立的推理 worker，NVSwitch 可能无法显著提升利用率，从而不足以证明成本合理。

错误 4：不看拓扑就比较每小时 GPU 价格。 两个“8x H100”方案如果一个是带 NVSwitch 的 SXM，另一个是 PCIe 或网络更弱，实际表现可能完全不同。

错误 5：忽视软件部署。 NCCL rank 映射、容器版本、网络接口选择和调度器策略都可能抵消硬件优势。

决策矩阵

工作负载	NVLink 重要性	NVSwitch 重要性	scale-out 网络重要性	实用建议
单 GPU 推理	低	低	低到中	在为 NVSwitch 付费之前，先优化 GPU 内存、批处理和模型选择。
2-8 GPU 张量并行推理	高	在 8 GPU 系统上高	中	优先选择带 NVSwitch 的 H100/H200/B200 系统，并基准测试真实延迟。
多节点分布式训练	每个节点内高	每个节点内高	非常高	同时评估节点内部互连和 InfiniBand/以太网；不要只看 GPU SKU。
专家并行或 all-to-all 密集型模型	高	高	跨节点时高	直接测试 all-to-all 和部署位置；拓扑可能占主导。
批量离线生成	中	中	中	衡量每美元的可接受输出；在更高批量下，NVSwitch 可能有帮助。
API 优先型产品工作负载	通常被抽象掉	通常被抽象掉	提供商负责	在租用硬件之前，先将直接 GPU 控制与模型/API 基线进行对比。

Flatkey 的定位

Flatkey 是一个统一的 LLM API 网关：一个密钥、一张账单，并通过一个与 OpenAI 兼容的端点接入众多文本、图像和视频模型。当你需要自定义 kernel、私有权重、微调控制或与拓扑相关的性能工作时，它不能替代直接的 GPU 集群。

当业务目标是输出而不是基础设施所有权时，它可以作为一个基线。在为推理预留一个重拓扑的集群之前，先将集群方案与托管模型/API 路径进行比较：

托管模型能提供什么质量和延迟？
在重试和失败生成之后，每个可接受响应的成本是多少？
集群运维会消耗多少工程时间？
该工作负载是否需要直接控制 GPU 内存，还是只需要可靠的模型输出？

如果模型/API 基线已经满足产品需求，那么 NVLink vs NVSwitch 可能还不是你现在必须自己承担的优化项。如果工作负载需要私有部署、自定义服务，或在规模化下满足硬性延迟目标，那么先比较 GPU 云与模型 API 的取舍，再使用上面的清单购买正确的拓扑，而不是最容易被认出的 GPU 名称。

FAQ

NVSwitch 比 NVLink 更快吗？

NVSwitch 并不是简单的“更快的 NVLink”。NVLink 是 GPU 连接链路。NVSwitch 是把多个 NVLink 端点连接起来的交换结构，使多块 GPU 能高效通信。在受支持的系统中，NVSwitch 能在更多 GPU 配对之间维持较高的 GPU-to-GPU 带宽，而不只是简单的点对点布局。