5 Lessons from Building a Multi-plane Network Fabric for Agentic AI

面向智能体AI的多平面网络：5个经验教训 | CoreWeave

发布日期

2026年8月24日

9

分钟阅读

构建智能体AI多平面网络架构的5个经验教训

作者

Min Jun

已复制

从东西向网络架构的角度来看，训练基础模型是一个行为良好的问题。数千块GPU会反复在同一时间运行相同的集体计算任务，持续数周。这对带宽来说是巨大的压力，但具有规律性。你可以围绕这种规律性进行设计。

智能体AI的流量模式则更加难以预测。智能体会将任务拆解为多个步骤，依次调用检索器、调用工具、调用其他模型，有时还会调用其他智能体，并在每个步骤完成后才知晓下一步操作。这种串行路径构成了智能体链，其延迟是每个步骤延迟的总和，而非最差延迟。当数千条智能体链与训练任务和标准推理任务同时在同一批次计算节点上运行时，流量模式就不再像批量作业那样规律，而是呈现出一种对延迟敏感、多跳对话在全网同时发生的特征。

智能体流量打破了训练从未验证的假设

与通过改造通用云平台来适配AI需求不同，CoreWeave从底层架构开始就为AI量身打造了网络。智能体本身并非全新概念，但要在集群规模上运行智能体，会带来早期AI工作负载从未出现过的网络需求。满足这些需求意味着需要从网络拓扑结构开始重新构建后端网络，使一个集群能够同时承载持续的训练集体计算、稳定的推理任务和突发的智能体流量，而不会让其中任何一种流量影响其他流量的性能。

我们基于NVIDIA Spectrum-X以太网平台、BlueField-3 DPU和ConnectX-9 SuperNIC构建了网络。随后，我们通过CoreWeave Kubernetes Service（CKS）、SUNK和CoreWeave Mission Control将这些硬件与我们自研的遥测、编排、调度、安全和可观测性栈进行集成。如今，该网络架构已连接超过50个数据中心的集群。

这就是我们在集群规模上构建该网络所学到的经验。

1. 非阻塞设计确保训练高峰时智能体仍能流畅运行

一个网络架构可能通过所有点对点带宽测试，但仍可能导致智能体链阻塞。通常原因在于过度订阅。当接入交换机的上行链路容量小于其下层节点生成的流量时，这种差距在两种流量类型同时争夺同一链路时才会显现。

单独的训练任务可以容忍一定程度的过度订阅。但混合了同步训练突发和数千个小型串行智能体请求的网络架构则无法容忍，因为它需要同时满足高聚合带宽和低、可预测的每流延迟。过度订阅的链路难以同时满足这两种需求。

我们应用的经验是：避免过度订阅。每个接入交换机的上行链路容量都足以在每个层级上以1:1的比例维持所有连接节点的满速率传输。这一原则贯穿我们构建的所有网络架构，这也是CoreWeave能够运营当今规模最大的NVIDIA Quantum InfiniBand和RDMA over Converged Ethernet（RoCE）网络的原因。

确保一个租户的突发流量不会影响其他租户的链路

NVIDIA Spectrum-X Ethernet 将交换机与 SuperNIC 协调为统一的网络架构，而非将拥塞视为交换机层面的问题。基于自适应路由和遥测的拥塞控制机制，可防止一个租户的同步训练突发流量影响另一个租户对延迟敏感的代理链。针对 NVIDIA 集体通信库（NCCL）流量优化的拥塞阈值，可减少集体操作易触发的数据包丢失，这对训练运行和代理编排步骤中常见的“扇出-同步”模式具有重要意义。

我们也在新型芯片上率先部署。CoreWeave 是首批部署 NVIDIA Spectrum-X SN6600-LD 的云服务提供商之一，这是业界首款全液冷 102.4 Tb/s 以太网交换机，目前正作为 NVIDIA Vera Rubin NVL72 的核心交换架构运行。这使客户在新型 AI 系统上线时即可访问更高容量的网络资源。

2. 多平面架构使您的集群规模翻倍而无需增加跳数

随着集群规模扩大保持非阻塞状态，比最初建立时更具挑战性。扁平化的两层叶脊拓扑最终会因端口数量（交换机实际可支持的端口数）达到极限而无法扩展。传统解决方案是增加第三层，通过增加跳数来提升容量。更多跳数意味着抖动累积的潜在位置增多，而这一点往往在智能工作负载最无法承受时发生。

多平面架构通过拆分每个 GPU 的 SuperNIC 连接至两个或多个独立网络平面，避免了增加层级的取舍。这种设计使扁平化两层架构可扩展至 128,000 个 GPU，达到单平面架构的 64 倍规模，且无需重新设计。

多平面架构在架构层面实现扩展，多轨设计则在节点层面延续这一原则。每个 GPU 通过多个 SuperNIC 连接网络，且在轨优化设计中，每个节点的第 N 个 SuperNIC 会连接至所有其他节点第 N 个 SuperNIC 所接入的相同叶交换机。特定轨上的流量无需跨越至其他叶交换机域即可直达目的地。

其结果是 GPU 之间的路径始终保持简短且可预测，而非随机散落在任意可达的叶交换机上。多平面架构使网络架构在扩展时不会出现容量瓶颈，多轨设计则确保每个 GPU 进入架构的路径始终简短且一致。

3. 硬件加速负载均衡让您充分利用已购买的带宽

非阻塞带宽和可扩展的拓扑结构仍无法保证流量能充分利用所有带宽。若依赖静态哈希算法，少量大流量会集中在同一条路径上，而其他路径则处于空闲状态。这种不平衡正是导致精心设计的网络架构在真实集体和智能流量下出现拥塞的原因。

传统负载均衡由软件实现，NCCL 决定如何将集体通信流量分配到可用链路上。虽然这种方法有效，但存在两个权衡：

• 与其它需要发送数据包的进程竞争主机 CPU 资源
• 在拥塞发生后才做出反应，而非根据网络状态变化提前规避拥塞

NVIDIA ConnectX-9 SuperNICs 作为 Spectrum-X 以太网平台的一部分，将这项任务转移到硬件层面，改变了逻辑运行的位置以及响应速度。专用的硬件路径能够以线速响应实时拥塞遥测数据，这是共享主机 CPU 的软件调度器无法实现的，而且它在执行此操作时不会占用网络所服务的工作负载的计算周期。硬件负载均衡能够更快地响应拥塞路径，并在不增加额外开销的情况下，将更多并发流分散到整个架构中，即使集群规模扩大也不会出现性能下降。

CoreWeave 将 ConnectX-9 SuperNICs 与 Spectrum-X 交换架构中的自适应路由相结合，在我们的 NVIDIA Vera Rubin NVL72 部署中，每块 GPU 可实现高达 1,600 Gb/s 的带宽。交换机与 SuperNIC 直接协同工作，利用实时拥塞遥测数据而非静态哈希算法，根据流量变化动态地将数据流分配到所有可用路径、平面和轨道中。

针对真实流量进行调优，而非教科书默认值

正确实现这种协同需要调优工作，而非简单的配置。优先级流量控制和显式拥塞通知必须根据实际流量进行设置，而不是依赖教科书中的默认值，因为网络在负载过高时过于激进地暂停传输，会导致数据包丢失与首包阻塞相互竞争，同时带来自身的尾部延迟成本。拥塞阈值需要针对 NCCL 模式单独调优，因为集合通信会产生同步的多对多突发流量，而这正是以太网拥塞设置最难以处理的流量形态。调优的回报不是更快的网络架构，而是一个在流量变得复杂时仍能保持无丢包的架构。

4. 代理链没有清晰的重启边界

一个训练任务如果停滞几分钟，虽然成本较高，但可以从检查点重新启动。而一个代理在 10 步链的中途停滞，当这种情形扩展到数千个并发链时，就没有等效的重启方式。没有单一的恢复点，这意味着弹性能力无法仅依赖堆栈中的某一层。每一层都必须独立承担恢复责任。

这意味着需要在五个层级上构建弹性：

• 拓扑层：多平面和多轨道架构能够在某个平面或轨道降级时，将流量转移到其他路径，而无需节点承受全部影响。

• 芯片层：NVIDIA BlueField-3 DPUs 在专用硬件上运行网络、隔离和策略执行，而非依赖主机 CPU，因此租户隔离独立于主机操作系统，资源分配、固件验证和策略执行不会占用工作负载的计算周期。

• 软件层：CKS 完全移除了虚拟机监控程序，从根本上防止虚拟化故障演变为租户问题。

• 运维层：CoreWeave Mission Control 由专门的 FleetOps 团队支持，一旦节点健康度低于阈值，系统会自动替换故障节点，团队全天候监控潜在问题的早期迹象。

• 地理层：CoreWeave 的网络骨干将数据中心连接为跨区域的单一架构，因此跨多个站点的工作负载不依赖于任何单一设施持续运行。

这一原则在两个层级同样适用：基础设施工作应部署在专用硬件上，而非你付费运行工作负载的资源上。没有虚拟机监控程序阻隔你与 GPU 之间的连接，也没有网络服务与你的任务争夺主机资源。

新一代 DPU 进一步拓展了这一方案。BlueField-4 将 64 核 CPU 与集成的 ConnectX-9 结合，实现 800 Gb/s 的吞吐量，且 DPU 上的计算能力达到 BlueField-3 的约六倍。基础设施层的更多功能完全从主机卸载：多租户网络、快速存储访问和运行时安全。对于智能体工作负载而言，当主机 CPU 已经需要处理编排和工具调用时，DPU 每吸收一个周期，工作负载就能保持一个周期的运行效率。

5. 无法看到的跳转无法修复

如果缓慢的跳转始终隐藏未被发现，以上所有优化都毫无意义。NVIDIA 网络可观测性工具可从 GPU 追踪到 SuperNIC 的流量级性能，跨交换机端口和 RoCE 队列映射每跳行为。这将"这个智能体链路感觉很慢"这类模糊症状转化为工程师可直接处理的具体链路或队列。

CoreWeave Mission Control 将这些原始信号转化为整个舰队运维团队可操作的信息，而非又一堆仪表板。它持续评估舰队内 GPU、网络和存储的健康状况，其 GPU Straggler Detection 功能可自动识别性能瓶颈，无需工程师翻查日志或客户重新提交任务即可隔离受影响节点或 GPU。

对于同步训练运行，该功能能及时发现拖慢整体进度的节点。对于智能体流量，它能捕捉到那些会悄无声息地为每条经过的链路逐步增加延迟的节点，且不会有任何错误信息提示原因。在舰队规模层面，能在几分钟内而非几天内定位到该节点，这决定了问题是否会被视为事故。

将相同信号发送给您的工具

Telemetry Relay 为您提供直接访问这些可见性的能力。这是一个完全托管的服务，通过 HTTPS、S3 兼容端点或 Prometheus Remote Write，以最小的配置将 CoreWeave 的日志、指标和审计事件转发到您自己的 SIEM 或可观测性系统。

对于智能体工作负载而言，这比单个训练任务更重要。无需为重建数千个并发链路的执行情况而构建定制集成，CoreWeave 运维团队使用的相同遥测数据会直接出现在您团队已运行的工具中。

安全可见性与性能遥测集成在相同的操作系统层，而非作为独立系统并行运行。身份和访问管理、基于角色的访问控制、持续审计日志等均部署于此，Telemetry Relay 会通过加密方式将这些审计和安全事件转发到您的 SIEM。治理和合规审查基于与所有其他功能相同的实时信号进行。

对于智能体工作负载而言，当代理代表用户跨系统操作时，了解"谁在何时以何种身份访问了什么"不是合规性的后续考虑，而是将这种全舰队范围的可见性应用于安全领域，而非仅限于性能监控。

为 AI 的下一步发展构建基础设施

这些经验来自于 CoreWeave 与 NVIDIA 的紧密联合工程，已在行业尚未达到的规模上得到验证。

CoreWeave 运营着目前全球规模最大的 InfiniBand 和 RoCE 网络架构之一。我们是首批部署 Spectrum-X SN6600-LD 的云服务提供商，也是首家成功部署并验证 NVIDIA Vera Rubin NVL72 的企业。据我们所知，我们在 AI 基础设施领域实现了 BlueField DPU 的最大规模部署。

这种实践经验体现在工作负载层面。基于舰队级规模的 InfiniBand 和 RoCE 网络，配合我们在实际部署中验证的最新 NVIDIA 交换机和网卡芯片（而非仅停留在数据手册上的理论参数），使单一网络架构能够同时满足两种极端需求：既满足大规模训练对带宽的持续高需求，也能应对自主代理 AI 对低延迟、多跳路径的不确定需求，无需在两者之间做出取舍。

训练需求推动了高速网络的行业建设。而自主代理 AI 将决定哪些网络架构真正具备长期价值。

准备好了解 AI 网络技术了吗？

查看 CoreWeave 如何实现每机架 AI 网络带宽翻倍

从构建能够同时处理训练、推理和自主代理工作负载的多平面网络中，我们学到的五个关键经验。

分享这篇文章： /