拆解 Meta Prometheus 网络：20,736 张 GPU 如何互联？4 个设计取舍值得关注

Meta 的 Prometheus AI 超级集群把数万张 GPU 连接在一起，网络设计需要同时应对高带宽、低时延、长距离传输和故障恢复等挑战。

Meta 在 2026 年 10 月发布的工程文章披露，其建筑级网络 Fabric 可连接多达 20,736 张 GPU；另一层 Backend Aggregation（BAG，后端聚合网络）则负责连接相距约 2 公里至 100 公里以上的建筑级网络。两层网络面对的流量特征和距离约束不同，因此采用了不同的交换架构与设备方案。

这套设计最值得关注的，不只是交换机的端口数量，而是四个工程问题：短距离与长距离网络如何分工、浅缓冲与深缓冲如何取舍、网络调度如何演进，以及 GPU 故障如何控制影响范围。

阅读说明：下文将 Meta 已公开的信息、通用网络原理和本文的理论估算分开讨论。BDP 计算属于模型估算，不代表 Meta 的实测数据或内部配置。

一、先看整体架构：建筑内高速互联，建筑间分层聚合

大规模 AI 训练对网络的要求与常规 Web 服务不同。训练任务会让大量 GPU 在计算阶段与通信阶段之间反复切换，通信过程中的带宽、时延和拥塞都可能影响整体训练效率。

Meta 为此建设了独立的后端网络（Back-End Network），承载 GPU 之间的直接通信。Prometheus 的网络可以概括为两个主要层次：

建筑级 Fabric： 在单栋建筑或数据中心区域内连接 GPU 计算网络，优先考虑高带宽和低时延。
BAG 聚合网络： 将不同建筑、园区乃至区域的网络连接起来，处理更长距离的流量与更复杂的路径条件。

Meta 在 2026 年 2 月的 BAG 技术文章中进一步介绍了其分层连接方式、路由策略和不同连接拓扑的取舍。

参考配图 1：Prometheus 网络分层架构示意图

配图应表达的重点

建筑内部 GPU 集群通过 Building Fabric 互联，多个建筑的网络再通过 BAG 聚合层连接。建筑内与建筑间链路承担不同的距离和流量条件，因此网络设计也有所区别。

二、取舍一：为什么建筑内与建筑间采用不同的网络设备？

网络距离会影响传播时延，也会改变拥塞控制和缓冲管理的要求。把所有链路都当成同一种场景设计，可能导致成本、时延或性能上的妥协。

Meta 公布的方案中，建筑级网络采用 51.2 Tbps 交换平台，包括基于 Broadcom Tomahawk 5 的 Minipack3，以及采用 NVIDIA Spectrum-4 的 Minipack3N。BAG 则使用搭载 Broadcom Jericho3 芯片的 Arista 7800 系列深缓冲交换机。

这并不意味着浅缓冲交换机只能用于短距离网络，而是说设备设计需要匹配链路距离、流量模式、拥塞控制机制和目标时延。

1. 浅缓冲方案：减少排队时延

浅缓冲交换机的优势之一，是在合理的拥塞控制和负载均衡条件下减少排队等待。对建筑内部高带宽、低时延的 GPU 通信来说，这一点尤其重要。

但浅缓冲并不等于性能必然更高。如果流量突发集中到同一出口，或多个发送端同时向同一接收端发送数据，队列仍可能快速耗尽。是否丢包还取决于流量突发程度、队列管理、拥塞控制与端点行为，不能只根据缓冲区大小下结论。

2. 深缓冲方案：为长距离链路留出余量

长距离链路会增加往返时延。当网络采用 PFC 等以太网流控机制时，设备还需要足够的缓冲余量来应对流控生效前已经在途的数据。

Meta 在 BAG 文章中明确指出，较长的 BAG-to-BAG 连接促使其在 BAG 层使用深缓冲交换机，以为 PFC 等无损拥塞控制机制提供缓冲余量。

这里需要区分两个概念：

传播时延由链路距离和信号传播速度决定，无法通过增加交换机缓冲区消除。
排队时延由排队的数据量、链路速率和调度行为等因素决定，缓冲策略会影响其表现。

因此，深缓冲的意义不是让远距离链路"更快"，而是在特定流控与拥塞场景下为数据传输和流量管理提供更多余量。

用 BDP 理解链路距离与缓冲需求

带宽时延积（Bandwidth-Delay Product，BDP）可以估算一个链路在给定往返时延下，能够容纳多少仍在传输途中的数据。

BDP (Byte) = Bandwidth (bit/s) × RTT (s) / 8

这里带宽单位为 bit/s，RTT 单位为秒，计算结果为 Byte。BDP 描述的是在途数据量，不等于交换机必须配置的缓冲区大小；实际缓冲需求还取决于流控机制、拥塞窗口、流量突发和网络拓扑。

假设光纤中的信号传播速度近似为每秒 200,000 公里，链路距离按单程计算，忽略交换机转发、排队和端点处理时延：

单程光纤距离	理论往返传播时延	400 Gbit/s 对应的 BDP
2 km	约 20 μs	约 1 MB
10 km	约 100 μs	约 5 MB
100 km	约 1 ms	约 50 MB

表中数据为理论估算，采用十进制 MB；实际 RTT 会受到光路长度、设备转发、排队和端点处理等因素影响。这里的 400 Gbit/s 只是用于说明计算方法的假设值，并非 Meta 公布的 BAG 链路实测参数。

可复制的 Python 计算代码

python 复制代码

def estimate_bdp(distance_km, bandwidth_gbps,
                 propagation_km_s=200_000):
    """
    理论估算：
    - distance_km：光纤单程距离，单位 km
    - bandwidth_gbps：链路带宽，单位 Gbit/s
    - propagation_km_s：假设的光纤传播速度，单位 km/s

    忽略设备转发、排队和端点处理时延。
    """
    rtt_s = 2 * distance_km / propagation_km_s
    bdp_bytes = bandwidth_gbps * 1e9 * rtt_s / 8

    return rtt_s * 1e6, bdp_bytes / 1e6


for distance in (2, 10, 100):
    rtt_us, bdp_mb = estimate_bdp(distance, 400)
    print(
        f"{distance:>3} km: "
        f"theoretical RTT={rtt_us:.0f} us, "
        f"BDP={bdp_mb:.1f} MB"
    )

这段计算能帮助工程师建立量级判断，但不能直接用于决定交换机缓冲区规格。实际设计还需要结合链路速率、流控行为、队列结构、拥塞场景和测得的 RTT。

三、取舍二：从 DSF 到 NSF，网络调度如何演进？

Meta 公开介绍了两种建筑级 Fabric：Disaggregated Scheduled Fabric（DSF）和 Non-Scheduled Fabric（NSF）。

两者的关键差异在于网络如何组织数据包传输、处理乱序，以及交换机和网卡各自承担什么职责。

DSF：通过网络侧机制管理传输

Meta 对 DSF 的介绍涉及子包级多路径、网络内重排序、虚拟输出队列（VOQ）以及基于信用的端到端流控等机制。这类设计的目标，是更精细地控制流量在网络中的传输和拥塞行为。

它的代价是网络机制更复杂，需要在交换机、调度和端到端流控之间协调工作。对于大规模训练网络而言，复杂机制的收益需要与部署、运维和故障诊断成本一起衡量。

NSF：利用端侧能力简化网络路径

随着以太网网卡具备更成熟的数据包重排序能力，Meta 得以采用 NSF 架构。Meta 公开的 NSF 方案使用浅缓冲交换机，并结合动态负载均衡或自适应路由等机制，在网络侧分配流量、在端点处理相关的乱序问题。

这里不能简单理解为"NSF 不需要调度"或"所有重排序都移到网卡"。更准确的说法是：NSF 改变了网络与端点之间的职责分配，让端侧重排序能力成为架构演进的重要前提。 具体行为仍取决于网卡、交换机和协议实现。

Meta 在 2025 年的技术文章中介绍了 NSF 的浅缓冲交换机、自适应路由和负载均衡设计；2026 年的 Prometheus 文章则说明了端点重排序能力成熟后，网络架构可以从 DSF 演进至 NSF。

参考配图 2：DSF 与 NSF 设计对比图

配图应表达的重点

DSF：突出网络侧调度、VOQ、网络内重排序和端到端信用流控。
NSF：突出浅缓冲交换机、动态负载均衡或自适应路由，以及端点具备的重排序能力。
图中重点是职责分配变化，而不是暗示 NSF 完全没有调度、拥塞控制或重排序。

四、取舍三：光模块与长距离互联，为什么不能只看带宽？

在大规模集群中，光模块不只是采购清单上的规格项。传输距离、链路速率、功耗、成本和可维护性都会影响整体网络方案。

Meta 在 Prometheus 文章中提到，建筑内部使用 2×400G FR4 LITE 等短距离光模块，而约 10 公里以上的链路使用 800G-ZR 相干光学方案。

这反映的是链路条件不同，适合的光传输技术也不同。选型时至少要核对以下几个维度：

评估维度	需要确认的问题
传输距离	单程距离、光路预算及链路损耗是否满足要求？
速率与端口	两端端口速率、分拆方式和兼容性是否一致？
光学方案	短距、园区互联和长距链路是否选用了适配的光模块？
功耗与散热	模块及端口密度是否符合机柜功耗和散热预算？
运维与冗余	链路监测、备件、路由冗余和故障切换是否具备可操作性？

工程判断： 不要仅凭"800G 比 400G 快"就决定升级。应先明确目标链路的距离、流量模型、端口条件和可接受的时延，再比较不同方案的容量与成本。

五、取舍四：GPU 数量越多，故障影响就越大吗？

大规模 AI 集群的可靠性不只是网络链路是否冗余，还涉及 GPU 计算域、训练任务切分、故障检测和恢复机制。

Meta 的公开文章指出，从 NVL8 过渡到 NVL72 后，紧密耦合的 GPU 互联域规模发生变化，故障影响范围也随之增加。Meta 描述的 NVL72 运行方式中，一个训练切片使用 64 张 GPU，另外 8 张作为机内备用资源。文章还给出了一个 32,768 张活动 GPU 的配置示例：需要 523 个 NVL72 机柜，共 37,656 张 GPU。这里的总量与活动 GPU 数量并不相等，部分差异来自 64/72 的机柜配置方式。

这些数字需要准确解释：GPU 互联域的故障影响范围扩大，不等于整个数据中心网络故障域扩大了相同比例。 机内备用 GPU、备用机柜和训练任务恢复是不同层次的容错措施，不能混为一谈。

从运维角度看，故障处理通常需要区分几个层面：

链路层： 光纤、端口或交换机链路异常，是否能够通过冗余路径绕行？
设备层： 故障设备是否需要隔离，恢复后是否必须经过健康检查？
计算层： 故障是否影响一个 GPU 切片、一个训练副本，还是多个副本？
任务层： 是否可以让剩余训练副本继续运行，还是必须从检查点恢复？

Meta 还介绍了自动隔离故障组件、重新平衡剩余流量等运行机制。它们说明，超大规模训练网络的可靠性依赖网络设计与运维系统共同工作，而不仅是增加备用硬件。

六、如果网络性能异常，工程师可以先检查什么？

前面讨论的是架构设计。落到实际排障时，不能仅凭"单流速度低"或"多流速度高"就认定是缓冲区、TCP 窗口或网络架构的问题。需要逐步区分链路质量、端点资源、拥塞、丢包和应用处理能力。

以下命令适合在有权限的测试环境或故障主机上使用。执行前应确认测试不会影响生产业务。

1. 检查路径质量与丢包

r 复制代码

mtr -rw -c 100 <目标IP>

观察端到端时延、丢包和路径变化。中间节点显示丢包不一定代表转发流量真的丢失，因为部分设备会限制对探测报文的响应；应结合终点丢包和业务指标判断。

2. 使用 iperf3 对比单流与多流吞吐

服务端：

复制代码

iperf3 -s

客户端单流测试：

r 复制代码

iperf3 -c <目标IP> -t 30

客户端多流测试：

css 复制代码

iperf3 -c <目标IP> -t 30 -P 4

如果多流吞吐明显高于单流，说明单流表现可能受到并行度相关因素限制，但这不能单独证明 TCP 窗口或交换机缓冲不足。还应检查 RTT、丢包、拥塞控制、CPU、网卡队列、链路速率以及对端处理能力。

3. 检查 TCP 连接状态与重传

复制代码

ss -ti

重点查看连接的 RTT、重传和拥塞控制相关信息。不同内核版本和连接状态下，输出字段可能有所不同。建议结合具体连接、应用日志和接口统计分析，不要仅凭单个字段直接下结论。

4. 检查网卡与接口错误计数

bash 复制代码

ip -s link

如系统安装了 ethtool，还可以查看网卡统计信息：

xml 复制代码

ethtool -S <网卡名>

关注丢包、错误、队列丢弃及驱动暴露的相关计数。具体字段由网卡型号和驱动决定。

5. 检查 TCP 缓冲区配置

复制代码

sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max

这些参数能帮助确认系统的 TCP 缓冲区配置范围，但不应在缺少证据时直接调大。Linux 的自动调优、应用 socket 设置、拥塞控制算法和实际 RTT 都会影响最终吞吐表现。修改前应记录原值，并在可控测试环境中验证效果。

排障顺序建议

建议先确认接口错误、端到端丢包和 RTT，再用 iperf3 区分单流与多流表现；随后检查 TCP 状态、网卡计数、CPU 与应用端处理能力。只有在证据指向相关配置时，才进一步调整缓冲区或其他内核参数。

结语：架构设计的核心是让每一层匹配自己的约束

Prometheus 的网络方案体现了一个重要思路：网络规模扩大后，不能只靠堆叠更高速的交换机，而要根据距离、流量模式、端点能力和故障边界划分职责。

建筑级 Fabric 追求低时延与高带宽，BAG 负责长距离聚合；浅缓冲与深缓冲分别适应不同的网络条件；DSF 到 NSF 的演进反映了网络与端点职责的重新分配；而 GPU 备用资源、链路冗余和训练恢复机制，则共同决定了故障对任务的实际影响。

对于负责 AI 基础设施、数据中心网络和训练平台运维的工程师，这些设计取舍比单独记住某款交换机或光模块的参数更有参考价值。

拆解 Meta Prometheus 网络：20,736 张 GPU 如何互联？4 个设计取舍值得关注

一、先看整体架构：建筑内高速互联，建筑间分层聚合

配图应表达的重点

二、取舍一：为什么建筑内与建筑间采用不同的网络设备？

1. 浅缓冲方案：减少排队时延

2. 深缓冲方案：为长距离链路留出余量

用 BDP 理解链路距离与缓冲需求

可复制的 Python 计算代码

三、取舍二：从 DSF 到 NSF，网络调度如何演进？

DSF：通过网络侧机制管理传输

NSF：利用端侧能力简化网络路径

配图应表达的重点

四、取舍三：光模块与长距离互联，为什么不能只看带宽？

五、取舍四：GPU 数量越多，故障影响就越大吗？

六、如果网络性能异常，工程师可以先检查什么？

1. 检查路径质量与丢包

2. 使用 iperf3 对比单流与多流吞吐

3. 检查 TCP 连接状态与重传

4. 检查网卡与接口错误计数

5. 检查 TCP 缓冲区配置

排障顺序建议

结语：架构设计的核心是让每一层匹配自己的约束

参考资料