手把手教你搭建GPU算力中心

如果您希望可以时常见面，欢迎标星收藏哦~

AI Neoclouds 的崛起吸引了整个计算行业的关注。从企业到初创公司，每个人都在利用它们来访问 GPU 计算。即使是微软，尽管拥有自己的数据中心建设和运营团队，每月也通过 AI Neoclouds 在 GPU 计算上花费约 2 亿美元。Nvidia 通过直接投资、大量分配 GPU 以及在各种演讲和活动中的赞誉，预示着多个 AI Neoclouds 的快速增长。

AI Neocloud 被定义为一种新型云计算提供商，专注于提供 GPU 计算租赁服务。这些纯粹的 GPU 云为其客户提供尖端的性能和灵活性，但为其提供动力的经济性仍在不断发展，因为市场正在了解其商业模式的运作方式。

在文中，我们将揭秘 Neocloud 的运行层面，从制定集群物料清单 ，到处理部署、资金和日常运营的复杂性。我们将在 BoM 和集群架构方面提供几项关键建议。

巨人与新兴企业

AI Neocloud 市场由四类主要提供商提供服务:传统超大规模提供商、Neocloud 巨头、新兴 Neocloud 以及经纪商/平台/聚合商。

AI Neocloud 市场规模巨大，是 GPU 需求最有意义的增量驱动因素。总体而言，我们认为 Neocloud 的增长将超过总需求的三分之一。

提供 AI 云服务的传统超大规模提供商包括 Google Cloud 、Microsoft Azure、Amazon Web Services (AWS)、Oracle、腾讯、百度、阿里巴巴。相比之下，Meta、xAI、字节跳动和特斯拉尽管也拥有强大的 GPU 集群和可观的产能扩张计划，但目前并不提供 AI 服务，因此不属于这一类别。

传统超大规模企业采用多元化业务模式，因此资本成本最低，但其集成生态系统和数据湖以及现有企业客户群意味着其定价比其他企业高出很多。超大规模企业也倾向于从其云业务中获得高额利润，因此其定价远高于 AI 云的合理价格。

与传统的超大规模企业不同，AI Neocloud Giants 几乎只专注于 GPU 云服务。最大的企业目前或计划在未来几年内，其所有站点的总容量将远远超过 10 万个 H100 当量，其中一些企业计划为 OpenAI 提供数十万个 Blackwell GPU 。主要的三大 Neocloud Giants 是 Crusoe、Lambda Labs 和 Coreweave，后者是迄今为止最大的。与超大规模企业相比，它们的资本成本更高，但与新兴 AI Neoclouds 相比，它们通常能够以合理的速度更好地获得资本，这意味着 Neocloud Giants 的相对拥有成本较低。

新兴 AI Neoclouds 包括我们跟踪的数十家云服务，这些云服务仍然拥有少量容量，并且在运行数据中心基础设施方面相对缺乏经验。这些新贵通常具有较高的资本成本，也是我们今天将重点关注的类别。新兴 Neoclouds 中还包括许多属于 Sovereign AI 范畴的区域参与者，Sovereign AI 是指任何专注于向美国或中国以外的次要地区提供 AI 云服务的 AI Neocloud。

这些地区目前在 AI 技术方面远远落后，包括欧洲、印度、中东、马来西亚等。特别是他们的客户通常希望出于监管、隐私、数据安全或其他商业原因将他们的 GPU 计算排除在美国或中国之外。虽然大多数新兴 Neoclouds 要么拥有不到 10,000 个 GPU，要么尚未部署 GPU，但其中许多都有非常雄心勃勃的计划，可能很快就会让其中一些进入与 Neocloud 巨头相同的联盟。

最后，是经纪人、平台和聚合商，他们通常聚合需求和供应，但往往资本较少，不愿直接承担 GPU 租赁价格风险，因此自己不拥有任何 GPU。此类别中有两种主要的商业模式:平台模式提供类似 Shopify 的平台，帮助 GPU 所有者和数据中心代表他们营销和匹配计算资源；聚合商使用类似亚马逊的市场模式，让 GPU 所有者能够向不同的买家提供计算。

平台可以为想要拥有 GPU 计算能力但又不具备部署或营销集群专业知识的主机提供 IaaS 基础设施以及设置和采购支持。与亚马逊之类的市场聚合器相比，经纪人和平台通常需要更多的人工接触点，类似于房地产经纪人，可以帮助您以交易价值的分成找到房屋。与任何经纪或市场服务一样，经纪人的收入分成对最终客户来说可能是不透明的。

另一种有趣的新兴商业模式是 VC 集群，即风险投资 或类似 VC 的实体为投资组合或其他附属公司建立集群。著名的例子包括 Andromeda、AI2、Computefund.ai和Andreesen Horowitz 计划的 GPU 集群。借助内部集群，这些 VC 可以提供非常灵活的计算租赁选项——在短时间内提供大型 512 或 1k GPU 集群，远低于其他 Neoclouds 为换取股权而收取的费用。他们还可以提供慷慨的租赁条款，以进一步向投资组合或附属公司倾斜。

如何构建 AI Neocloud

一、了解集群物料清单

让我们从一个简单的框架开始。那么，您想启动 AI Neocloud 吗？您会怎么做？这是我们的分步指南，从 BoM 开始，最后设置 Neocloud。

理解和定制 AI 集群报价和物料清单 是 Neocloud 部署中最重要的因素之一，正确处理可能会决定利润率高低或财务困境。我们建议从 CEO 到工程师和销售人员的每个人都了解其 BoM 中的每一项产品。

目前部署的大多数 Neocloud 集群都拥有 2048 个或更少的 GPU。最常见的物理集群大小为 2048、1024、512 和 256 个 GPU，2048 个及以下 GPU 集群的部署成本随 GPU 数量线性增长。在本次分析中，我们将重点分析 1024 个 GPU 部署，这是新兴 Neocloud 的共同点。

OEM 和 Nvidia 在报出 BoM 时自然会寻求加价销售。BoM 通常细分为四类:计算机箱级、机架级、集群级和软件级。

二、计算机底盘物料清单

我们将从最低的抽象层开始，即计算机箱物料清单 ，这是集群中最昂贵的部分。默认的计算机箱 BoM 报价往往使用顶级组件 - Supermicro、戴尔等 OEM 最初会报价接近顶级的 Intel Emerald Rapids CPU，以及配备 2TB RAM 和 30 TB 本地 NVMe SSD 闪存的系统构建。

微调此引文是 AI Neocloud 最简单的优化方法。此优化的步骤是选择中端英特尔 CPU，因为许多客户的工作负载无论如何都不会使用太多 CPU。LLM 训练是一项非常 GPU 密集型的工作负载，但对于 CPU 而言，工作负载强度非常低。CPU 主要运行简单任务，例如 PyTorch 和控制 GPU 的其他进程、初始化网络和存储调用，并可能运行虚拟机管理程序。

总的来说，虽然 AMD CPU 在大多数 CPU 任务上表现优异，但我们建议使用英特尔 CPU，因为英特尔 CPU 更容易获得正确的 NCCL 性能、更容易进行虚拟化，而且整体体验错误更少。

例如，在 AMD CPU 上，您需要使用 NCCL_IB_PCI_RELAXED_ORDERING 并尝试不同的 NUMA NPS 设置以实现可接受的性能。如果您计划进行虚拟化，则需要将虚拟核心正确固定到正确的 NUMA 区域，否则您的设备到主机和主机到设备的带宽和延迟将不理想。明确地说，如果您熟练的话，这是可行的。

许多标准产品都具有 2TB 的 CPU DDR5 RAM，但您的大多数客户不会使用那么多。RAM 是计算机底盘 BoM 中第四昂贵的部分。我们建议将标准的 2 TB RAM 降级为仅 1 TB RAM。您的 Neocloud 的大多数客户不太可能询问 RAM 容量，因为他们的工作负载根本不受 CPU RAM 限制。

除了核心计算组件之外，另一个潜在的成本节约方法是删除标准报价中的两个 NVIDIA Bluefield-3 DPU。这些 DPU 最初是为传统 CPU 云开发的，并被宣传为一种成本节约技术，可让它们出租更多 CPU 核心，而不是让这些 CPU 核心运行网络虚拟化。

但是您的 Neocloud 客户无论如何都不会使用太多 CPU 计算，因此如果您使用部分主机 CPU 核心进行网络虚拟化，这并不重要。在许多情况下，您无论如何都会将裸机服务器交给您的客户，从而消除任何网络虚拟化的需要。此外，Bluefield-3 DPU 相当昂贵，以至于购买另一个 54 核 CPU 比购买 Bluefield-3 更便宜。完全跳过 Bluefield-3，使用标准 ConnectX 作为前端。

综合考虑前几项成本优化，我们估计可节省 13600 美元，使一个计算节点的成本从 270000 美元降至 256400 美元，节省约 5%。在拥有 128 个计算节点的 1024 H100 集群中，可节省 174 万美元。随着数量不断增加，此价格会越来越低。

在典型的 BoM 中，每台 H100 计算服务器将配备八个 400Gbit/s ConnectX-7 NIC，从而使每台服务器的总带宽达到 3,200Gbit/s。一些 Neocloud 只选择了四个 NIC，这将使后端网络带宽减少 50%。

虽然我们认为这可能会为某些工作负载带来更好的总拥有成本性能，但大多数 Neoclouds 的目标客户并不希望每台计算服务器的 InfiniBand 带宽低于 8x400Gbit/s。因为这确实会影响工作负载性能。这是许多公司对 Google Cloud 反感的主要原因之一。Google Cloud 使用 Falcon/GRD 部署带有 8x200G 以太网的 H100。即使 Google 确实可以节省资金，在某些情况下这也会影响性能。

现在，我们先跳过机架级别，转到集群级别 BoM，从网络开始，它是计算节点之后最大的集群成本驱动因素。

集群级别 - 网络物料清单

H100集群中有三种不同的网络:

• 前端网络

• 后端网络

• 带外管理网络

简单回顾一下，前端网络只是一个普通的以太网网络，用于连接互联网、SLURM/Kubernetes 和网络存储，以加载训练数据和模型检查点。该网络通常以每 GPU 25-50Gb/s 的速度运行，因此在 HGX H100 服务器上，每台服务器的速度将达到 200-400Gbit/s。

相比之下，后端计算结构用于将 GPU-GPU 通信从数十个机架扩展到数千个机架。该网络可以使用 Nvidia 的 InfiniBand 或 Nvidia 的 Spectrum-X 以太网，也可以使用来自 Broadcom 等交换机供应商的以太网，这些供应商包括 Artista、Cisco 和各种 OEM/ODM。与 Broadcom 以太网解决方案相比，Nvidia 提供的选项更昂贵。尽管以太网的每 TCO 性能，但我们仍建议 Neoclouds 使用 InfiniBand 或 Spectrum X，因为它具有最佳性能，并且最容易销售，因为客户将 InfiniBand 与最佳性能联系在一起。客户通常认为以太网“性能低得多”，尽管这并不反映现实。这主要源于 Neocloud 和客户必须进行工程优化才能优化 NCCL。我们以前做过这些，除非您拥有优秀的工程人才和时间，否则这并不容易。此外，许多人认为 Nvidia 会为购买其网络解决方案的人提供优先分配。

最后，还有带外管理网络。它用于重新映像操作系统、监控节点健康状况。服务器、PDU、交换机、CDU 上的基板管理控制器 (BMC) 通常连接到此网络，以监控和控制服务器和各种其他 IT 设备。

对于前端网络，Nvidia 和 OEM/系统集成商通常会在服务器上拥有 2x200GbE 前端网络连接，并使用 Nvidia Spectrum Ethernet SN4600 交换机部署网络。但是，我们建议不要这样做，因为每台 HGX 服务器拥有 400Gbit/s 的网络带宽远远超过您的客户可能使用的网络带宽。客户将仅使用前端网络进行存储和互联网网络调用以及 SLURM 和 Kubernetes 的带内管理。由于前端网络不会用于延迟敏感和带宽密集型梯度，所有这些都会减少集体通信，因此每台服务器 400Gbit/s 会过度使用。因此，对于整体前端网络部署，我们建议使用来自 Arista、Cisco 或各种 OEM/ODM 等供应商的通用以太网交换机，并且每台 HGX 服务器仅拥有 2x100GbE。

下一个唾手可得的成果是带外管理网络。默认 BoM 包括 SN2201 Nvidia Spectrum 1GbE 交换机，但这些交换机的价格相当高，对于像带外网络这样简单的东西来说，很难证明其合理性。这相当于购买品牌 Advil 而不是通用布洛芬。使用任何通用带外交换机都会降低带外网络成本，因此，我们建议使用通用 1GbE 交换机。

优化后端网络

后端网络的选择变得更加复杂，需要对高性能网络有更深入的了解，而新兴的 Neoclouds 公司有时可能缺乏这种了解。该网络将运行 All Reduce、All Gather、Reduce Scatter 的大规模突发，即您的集体通信。由于这些集体的突发性，后端网络与传统云网络相比具有完全不同的流量模式。

首先，我们来谈谈 Nvidia 参考网络拓扑。参考拓扑是一个具有无阻塞连接的两层 8 轨优化胖树。在无阻塞胖树网络中，如果您任意将节点分成对，那么所有对都应该能够同时以全带宽相互通信。尽管在实践中，由于拥塞、不完善的自适应路由和额外交换机跳数的额外延迟，情况往往并非如此。

当网络进行 8 轨优化时，来自 4 台服务器的所有 32 个 GPU 不是连接到架顶 交换机，而是来自 32 台服务器的 8 个 GPU 索引中的每个 GPU 索引都有自己的交换机。例如，来自所有 32 台服务器的所有 GPU #0 都连接到叶交换机 #0，来自所有 32 台服务器的所有 GPU #1 都连接到叶交换机 #1，依此类推。

轨道优化网络的主要优势是减少拥堵。如果来自同一服务器的所有 GPU 都连接到同一个 ToR 交换机，当它们同时尝试将流量发送到网络中时，它们尝试使用相同链路遍历胖树网络的可能性会非常高，从而导致拥堵。用于 AI 训练的 GPU 应该会定期一次性发送数据，因为需要集体操作来交换梯度并更新新参数。

下图第一张图展示了一个 8 轨优化网络，其中有 8 个来自集体通信的并行流用于连接 8 个不同的叶交换机，而第二张图展示了一个非轨优化设计，其中服务器连接到 ToR 交换机。

Nvidia 参考架构还将集群划分为 4 个 pod，每个 pod 包含 32 个 HGX 服务器(256 个 H100)和 8 个轨道。每个 GPU 索引始终与 pod 内另一台服务器中的相同 GPU 索引相距一跳。这很重要，因为它可以减少主干交换机上的网络流量，而主干交换机很容易成为拥塞热点(即使在非阻塞网络上也是如此)。

与普遍看法相反，在多租户环境中，优化轨道并减少顶层流量/拥塞尤其重要，因为在这种环境中，您通常会有多个租户/客户。在 8 轨道优化网络中，每个工作负载的所有 8 个流都是物理分离的，因此不会发生路由/交换冲突。在我们即将推出的 Nvidia NCCL 和 AMD RCCL 集体深入探讨中，我们将讨论轨道优化配置的好处以及为什么拥塞可能是一个严重的问题，尤其是对于 AI Neoclouds 等多租户环境。

不幸的是，拥塞问题无法通过 nccl-tests 轻松测量，而是需要现实世界的并发工作负载才能了解嘈杂邻居/拥塞问题如何影响端到端工作负载吞吐量。如果租户之间没有物理隔离，嘈杂邻居将永远存在。鉴于我们在拥塞问题上所看到的情况，我们强烈建议采用某种形式的 8 轨优化拓扑。

轨道优化拓扑的另一个好处是，由于大多数流量将在叶交换机本地进行，因此可以超额订阅网络的主干层，这是一种架构优化，我们将在本文后面讨论。

优化光纤与电气网络

使用光纤进行联网的优点是传输距离更长，但缺点是增加了功率要求，并且光纤收发器的成本非常高，尤其是直接通过 Nvidia 购买时，而这对于 InfiniBand 网络来说基本上是必须的。优化物理网络拓扑和机架布局可以减少光纤收发器的使用，只在实际需要更长传输距离时才使用。

在 Nvidia 参考设计中，叶交换机位于单独的网络机架上，而主干交换机位于专用的网络机架上，这意味着需要使用 100% 的光学器件。

为此，可以考虑使用一种网络拓扑结构，即无阻塞机架顶部 设计。大多数具有传统网络背景的人都会立即认出这种设计，因为它是传统网络中最常见的设计，其中在机架中间或顶部有一个交换机，用于连接机架中的所有服务器。由于 ToR 交换机与服务器之间的距离小于 3 米，我们可以使用称为直接连接铜缆 (DAC) 的“廉价”无源铜缆将服务器连接到叶交换机。对于这种设计，我们建议将 InfiniBand 交换机放在中间，以缩短 DAC 电缆需要传输的距离。

从叶交换机到顶层主干交换机，我们都必须使用光纤。这很昂贵，但至少 50% 的连接现在将被更便宜的 DAC 铜缆取代。

不幸的是，对于这种设计，您将无法实现 8 轨优化网络，因此，即使您的主干层是无阻塞的，您也通常会遇到拥塞热点，因为现在有 8 个流跨越多个交换机级别，这意味着每个流都需要动态使用不同的路径来避免拥塞。在拥有完美自适应路由的理想世界中，ToR 将作为拓扑很好地工作，因为路由将始终避免拥塞路线。但在现实中，由于完美的自适应路由并不存在，因此实现这种拓扑将严重损害网络性能。

下图是我们对这种无阻塞机架顶部结构的模拟热图，其中浅蓝色表示由于拥塞导致带宽减少，深蓝色表示接近满线速率。如您所见，使用 ToR 拓扑可以达到线速率，但由于所有 8 个流都进入一个交换机，因此仍然存在相当大的拥塞，由于拥塞，吞吐量变得更加不稳定，并且这些流的带宽更少。

尽管这种设计的性能对于 Neoclouds 这样的多租户环境来说并不是特别好，但成本节省却是巨大的，节省了 34.8% 的后端 InfiniBand 结构成本。

虚拟模块化交换机

现在，如果我们可以兼顾两全其美的优势，既能优化 8 轨的性能优势，又能节省 ToR 的成本，那会怎样？

这就是虚拟模块化交换机的作用所在。它具有与 Nvidia 参考设计相同的逻辑拓扑，但由于巧妙的平面规划和交换机位置规划，可以使用从叶交换机到主干交换机的铜线。

这里的基本思想是将交换机机架直接放置在彼此之间，这样主干交换机位于中间机架，而叶交换机位于左机架和右机架，如下图所示。这样，叶交换机和主干交换机之间的连接可以全部采用铜缆，而服务器和叶交换机之间的连接仍将使用光纤。

由于拓扑仍针对 8 轨进行优化，因此 8 个流中的每一流都将物理分离，从而显著减少拥塞。

这种设计应该能让我们两全其美，但是这种拓扑结构有什么缺点呢？

不幸的是，这些交换机到交换机的 DAC 铜缆往往弯曲半径较小，而且非常粗，导致气流受阻。我们之前在生产中看到过类似的设计，如果你能很好地管理电缆，这些问题就可以克服。这个问题也可以使用有源铜缆 来解决，这种铜缆几乎和多模光纤一样细，混合半径也很好。不幸的是，我们听说的一个潜在问题是 Nvidia 的 LinkX NDR ACC 电缆的错误率不是很好。

使用这种无阻塞虚拟模块化交换机设计，与参考架构相比，我们可以在后端网络上节省 24.9% 的成本，同时保持相同的性能。另一个巨大的好处是无源铜缆通常比光收发器更可靠。收发器故障率很高，激光器是故障的主要部件。这种高故障率带来了更换收发器零件、集群停机时间和维修所需人工方面的成本。

超额订阅后端网络优化

我们可以通过突破无阻塞网络的限制，进一步优化成本。由于大多数流量在 8 轨优化设计中位于 32 台服务器的 pod 本地，并且由于 InfiniBand 具有足够好的自适应路由，因此您可以设计从叶交换机到主干的超额订阅。即使集群将由仅运行一个工作负载的单个租户使用，这也有好处。当使用 1024 个 GPU 时，您的单个模型副本永远不会大于 256 个 GPU。这意味着张量、专家和管道并行性将在 32 台服务器的 pod 内运行。

该流量将停留在第一级交换机本地，而带宽要求较低的数据并行、梯度和所有缩减将发生在主干交换机上。由于主干层的带宽要求处于较低水平，并且 InfiniBand 具有足够好的自适应路由，因此您可以仅通过设计进行订阅。

在 Meta 的 24k H100 集群上，他们在 pod 之间实现了 7:1 的超额订阅，但我们认为以更保守的超额订阅进行设计更有意义，我们建议对小型集群仅使用 2:1 的超额订阅。

这种设计的好处是，1024 个 H100 不需要 16 个主干交换机，而只需要 8 个主干交换机。当将 2:1 超额认购与虚拟模块化交换机设计相结合时，我们可以在中间机架中安装更少的交换机。这意味着电缆管理要容易得多。另一个好处是您的叶交换机上有空端口，因此将来，当您的 pod 间流量较大时，您可以轻松添加更多主干交换机并降低超额认购程度。

我们估计，与参考架构相比，使用虚拟模块化交换机实现 2:1 超额订阅可节省 31.6% 的成本，这比仅使用非阻塞虚拟模块化交换机设计时节省的 24.9% 有所改善。非阻塞设计的唯一缺点是您需要将客户合理地分配到物理服务器，并避免 pod 边界之间的碎片化。我们相信，只要有一支有能力的团队，就可以轻松实现这一点。

Nvidia 还通过 CS9500 系列为 NDR InfiniBand 提供了自己的物理模块化交换机。您可以使用此交换机创建相同的 8 轨优化胖树拓扑，并且如果愿意，还可以进行超额订阅。此模块化交换机最多可支持 2048 个 400Gbit/s 外部端口，因此可扩展到连接最多 2048 个 H100。主干交换机 ASIC 位于机架的背面，而叶交换机 ASIC 和 OSFP 笼位于机架的正面。主干交换机 ASIC 通过类似于 NVL72 背板的铜背板连接到叶交换机 ASIC。不幸的是，只提供液体冷却解决方案。

CS9500 的液体冷却要求是我们建议为大多数 Neoclouds 部署虚拟模块化交换机而不是物理模块化交换机的原因。当前 GB200 驱动的液体冷却就绪主机托管需求以及主机托管供应总体紧缩意味着新兴 Neoclouds 不会有太多价格合理的容量。由于 Nvidia 的定价基于对最终用户的价值，并且由于这种物理模块化交换机可能对大型集群部署非常有价值 到 O(100k))，我们认为这比仅仅制造您自己的虚拟模块化交换机要花费更多。

不幸的是，使用 InfiniBand 的缺点之一是，要拥有一个不错的 REST 接口，您需要购买 UFM 管理许可证。统一结构管理器 是 Nvidia 提供的软件包，用于处理网络管理、性能优化和监控。建议在 2048 个 GPU 以下的集群中使用 UFM，对于更大规模的集群来说，这是一项硬性要求。UFM 许可证按每个 NIC 端点收费，这意味着对于 1024 个 GPU 集群，您需要购买 1024 个许可证。

购买 UFM 的另一种方法是使用开放子网管理器，该管理器仅通过终端命令行界面提供，但幸运的是，您可以创建一个简单的 REST 服务器，该服务器包装命令行并使用子进程 Python 库为您执行命令。对于您的第一个集群，我们建议只购买 UFM 许可证，但对于未来的集群，我们建议 Neoclouds 考虑这一点以节省成本。

AI Neocloud 存储

我们将讨论 H100 集群中下一个最昂贵的部分，即联网 NVMe 存储。这是所有客户都想要的东西，并且实际上是运行 SLURM 的必要条件。存储部署基本上只有两个项目，即您的物理存储服务器和您的存储软件供应商许可证，例如 Weka 或 Vast Data 等。由于与 OEM 的渠道合作关系，这些是最受欢迎的供应商。

为了实现高可用性，大多数存储软件供应商建议您部署至少 8 台存储服务器。事实上，大多数 Neocloud 仅部署最低限度的 8 台存储服务器。使用 8 台存储服务器，您将在所有存储服务器上以大块大小获得 250GByte/s 到 400GByte/s 的聚合存储带宽。这足以满足在 1024 台 H100 上运行的大多数合理或不合理的 AI 工作负载。

由于存储的交付周期非常短，我们建议您从 1024 H100 集群的总存储容量 2 PB 开始，因为如果您发现客户正在使用您部署的容量，您可以轻松扩展存储。我们建议在您的存储部署中留出足够的端口、NVMe 驱动器托架、电源和机架空间，以便轻松扩展。大部分存储成本都在存储软件许可证中，而不是物理存储服务器本身。

尽管您的存储服务器可以在 InfiniBand 后端计算结构上运行，但尝试过的人已经损失了很多头发！此部署通常会将您的 IB NIC 绑定到 GPU 0，以充当您的存储 NIC。在英雄存储基准测试中，这将提供很大的延迟和高带宽，但在现实世界的工作负载中，这将导致您的 GPU 0 落后，因为使用 IB NIC 进行存储会产生冲突。当存储集群中的磁盘发生故障时，将触发重建，这将在您的计算结构上造成大量的网络流量，从而造成更大的拥塞。您可以购买单独的专用存储结构，但这是过度的，因为您可以在前端网络上拥有存储流量。

我们建议将存储服务器和流量放在前端网络上。前端网络通常未得到充分利用，因为它主要用于互联网流量、SLURM/Kubernetes 管理和提取容器映像。

更多网络管理和软件包

在带内管理方面，为了运行高可用性 UFM 和 CPU 管理节点，我们建议部署至少三个 CPU 节点。在这三个节点中，两个节点需要 ConnectX NIC 来管理 InfiniBand 结构。第三个 CPU 节点将仅用于其他非 InfiniBand 管理任务。此外，还需要其他杂项 IT 设备，例如物理防火墙、42U 机架、受监控的 PDU 等，但这些设备的价格不会显著增加集群总资本支出成本。

集群 BoM 资本支出摘要:

参考架构与半分析优化架构

如下所示，使用 Nvidia Superpod 参考架构 ，集群的总成本达到每台计算服务器约 31.8 万美元(不包括存储)，但使用 SemiAnalysis 优化架构和 2:1 超额认购，总总成本仅为每台计算服务器 28.3 万美元(也不包括存储)。我们通过谈判帮助 Neoclouds 进一步优化，尤其是在大型集群上进一步削减成本。

驱动程序、用户体验和软件

如果您来自大型科技公司或国家 HPC 实验室，那么用户需求就很简单。用户需要正常运行的 GPU、网络、正确安装的驱动程序、正常运行的共享存储和调度程序。然而，现实情况是，绝大多数 Neocloud 都无法满足这些用户需求，从而导致用户体验不佳。

从运行 GPU 所需的 GPU 驱动程序开始 - 我们需要 cuda-drivers-5xx 和 fabricmanager-5xx 以及 cuda-toolkit-12-x。

Cuda-drivers-5xx 是 ubuntu/Linux 与 GPU 交互所需的内核空间 Nvidia 驱动程序。接下来是 fabricmanager-5xx，这是一个负责配置节点内 NV 链路结构的软件包。如果没有 fabricmanager-5xx 包，节点内的 8 个 GPU 将无法通过 NV 链路相互通信。Cuda-toolkit-12-x 是包含所有用户空间工具和 API 的工具包，例如 NVCC，它是将 CUDA C++ 代码编译为 PTX 汇编和 Nvidia 机器代码的编译器。

对于网络，需要在每个 GPU 服务器上安装 Mellanox OpenFabrics Enterprise Distribution 驱动程序。此软件包是 ConnectX-7 InfiniBand NIC 的驱动程序，用于执行 RDMA(远程直接内存访问)和 OS 内核旁路。为了让 GPU 直接与 NIC 通信，您还需要GPUDirect RDMA，这是一个附加内核驱动程序，包含在 cuda-drivers-5xx 中，但默认情况下未启用。如果没有此驱动程序，GPU 将需要在 CPU RAM 中缓冲消息，然后这些消息才能发送到 NIC。启用 GPUDirect RDMA 的命令是“sudo modprobe nvidia-peermem”。为了进一步优化 GPU 与 NIC 的通信，您需要下载一个名为 Nvidia HPC-X 的软件包。

如果没有上述 GPUDirect RDMA 和 HPC-X 软件包，您的 GPU 只能以 80Gbit/s 的速度发送和接收流量，而每 GPU 的线路速率为 400Gbit/s。启用这些软件包后，您的点对点发送和接收速率应达到 391Gbit/s，而线路速率为 400Gbit/s。

接下来，用户需要一个调度和启动软件包。在 Neocloud 市场中，70% 的用户希望 SLURM 可以开箱即用，另外 20% 的用户希望 Kubernetes 可以开箱即用，最后 10% 的用户大多希望安装自己的调度程序。

对于 Neoclouds 来说，让 SLURM 或 Kubernetes 开箱即用非常重要，因为最终用户通常没有安装这些类型的调度程序的经验。这是因为来自大型科技公司或国家/大学实验室背景的用户通常有专门的人员负责安装和操作这些 SLURM 软件。最终用户必须花 1-2 天时间自己安装 SLURM，这笔费用是相当可观的，因为他们实际上是在为安装期间闲置的 GPU 集群付费。

最后，100% 的客户还必须能够在需要时手动将交互式终端接入其 GPU 节点 - 托管 SLURM 可提供此功能。使用 SLURM，您可以运行“srun –gres=gpu=8 -w NODE_NAME –pty bash”以将交互式终端接入任何节点。

Crusoe 和 TogetherAI 等 Neocloud 是黄金标准。由于它们开箱即用，安装了所有必需的 InfiniBand 驱动程序、GPU 驱动程序和调度软件，因此它们可以收取比竞争对手更高的费用，并且客户流失率更低。

获得最低价值体验的下一个用户要求是拥有一个简洁的共享主目录和共享数据存储目录。所有 GPU 节点和登录节点都将在 /home/$USER/ 和 /data 处安装共享存储。这实际上意味着，当最终用户可以在任何 GPU 节点中启动交互式终端时，该节点将具有相同的主目录和文件。这非常棒，因为这意味着分配给用户的每个 GPU 节点都是可互换的，用户无需关心他们正在使用哪个 GPU 服务器。此外，在启动多节点训练作业时，用户的所有代码都会自动出现在每个 GPU 节点上，因此用户无需通过 ssh 手动将代码复制到每个节点。

使用 Neocloud 存储时，用户对存储感到沮丧的主要原因是文件卷随机卸载以及用户遇到大量小文件 问题。解决随机卸载问题的方法是使用名为“ autofs ”的程序，该程序会自动保持共享文件系统处于挂载状态。

其次，LOSF 问题可以轻松避免，因为只有当您决定推出自己的存储解决方案而不是为 Weka 或 Vast 等存储软件供应商付费时，它才会成为问题。如果集群上存在 LOSF 问题，那么最终用户很快就会注意到集群上的 LOSF 问题，因为即使将 PyTorch 导入 Python 的时间也会导致完全滞后。

下图是我们在 Crusoe 集群上进行测试时生成的，展示了经过优化且不存在 LOSF 问题的集群存储解决方案应如何运行。如您所见，即使增加 GPU 数量，将 PyTorch 导入 Python 进程所需的时间也保持相对平稳。

这与在未优化的共享存储上运行的集群有着天壤之别，在 Python 多节点训练运行中导入 PyTorch 所需的时间激增，经常导致集群完全无法使用。请注意 Crusoe与另一个存在 LOSF 问题的集群之间的差异。

多租户

除非整个客户长期租用整个物理集群，否则每个物理集群可能都会有多个并发客户。这意味着您需要隔离前端以太网和后端 InfiniBand 网络，并在客户之间实现存储隔离。每个客户通常会将每个 GPU 服务器作为一个整体来租用，这意味着在计算服务器上虚拟化并不是严格需要的，因为每个物理服务器只有一个客户。花时间细分节点是不值得的。使用标准 vLAN 可以轻松为前端以太网设置隔离。在 vLAN 中，虽然物理以太网结构是共享的，但每个客户的节点只能与分配给同一客户的其他节点通信。

与以太网 vLAN 相比，InfiniBand 多租户的设置和自动化并不那么容易，但学习曲线非常快。在 InfiniBand 世界中，网络隔离是使用分区密钥 实现的 - 本质上与 vLAN 的概念相同。每个客户都通过 pKeys 获得自己独立的 InfiniBand 网络，并且只有具有相同 pKeys 的节点才能相互通信。

可以通过 UFM UI 仪表板或使用UFM REST API轻松创建和附加 pKey 。对于许多工程师来说，这实际上可能比自动化以太网 vLAN 更容易，因为有一个易于使用的 InfiniBand pKeys POST/GET/DELETE API。

不幸的是，我们从自己的测试经验中发现，一些 Neocloud 的 pkey 设置不正确，导致一个客户的用户能够看到 InfiniBand 网络上其他租户的节点。我们强烈建议客户亲自验证他们的 InfiniBand 网络是否与其他客户正确隔离。

对于存储而言，多租户尤为重要。幸运的是，存储管理也相当简单，因为 AI 领域的主要存储提供商 Weka 和 Vast 都支持多租户作为首要原则。

在 Weka 和 Vast 的数据软件中，您可以轻松创建租户并为每个存储卷设置访问控制策略，以便仅分配给一个租户。该软件提供了强有力的保证，如果策略设置正确，则每个客户的用户只能访问他们自己的存储卷。

裸机或虚拟化

对于 H100 SXM，最小计算单位是一台服务器，这意味着每台服务器每次只能有一个客户。这意味着可以在保持安全性的同时进行裸机部署。裸机是可能的，而且确实很常见，但我们确实看到使用虚拟机具有额外的好处，例如更长的平均恢复时间和更强的可靠性。

使用虚拟机时，如果客户正在使用的物理 GPU 服务器出现故障，那么 Neocloud 能够轻松地在热备用服务器上为客户迁移或启动新的虚拟机。

可以使用开源虚拟机管理程序在 GPU VM 上创建虚拟机，它将启动您的 VM，在其中将 vCPU 固定到物理 CPU，并留下几个未固定的核心来运行虚拟机管理程序。

您还需要将 vLAN 以太网接口绑定到 GPU VM。使用通用虚拟机管理程序创建 CPU VM 是一项简单的任务，如今大多数计算机科学毕业生都可以做到。要将 VM 变成 GPU VM，您还需要对 GPU 和 InfiniBand NIC 进行 PCIe 直通。对于 Neoclouds 来说幸运的是，NVIDIA 尚未找到一种方法来对其 GPU 和 NIC 上的 PCIe 直通收费。我们还看到 Neoclouds 使用SR-IOV创建虚拟 InfiniBand NIC 并将其传递到虚拟机中，而不仅仅是物理 InfiniBand NIC，尽管使用 SR-IOV 并不是严格必要的。

您需要记住执行的另一个步骤是通过 NCCL_TOPO_FILE 变量手动传递 /etc/nccl.conf 中的 NUMA 区域和 PCIe 拓扑文件，因为 NCCL 和 Nvidia 驱动程序现在在该 GPU VM 内运行，因此无法自动检测 NUMA 区域和 PCIe 拓扑。如果没有此步骤，NCCL 性能将以应有带宽的 50% 运行。

与裸机相比，使用虚拟机的缺点之一是，由于启用了IOMMU， CPU 到 GPU 的传输带宽和延迟会略慢。但我们认为使用虚拟机是值得的，因为它对最终用户来说平均恢复时间更快，而且主机到设备 的传输通常与计算重叠，因此对最终用户来说甚至可能不会有明显的影响。

由于 CPU RAM 为 1-2TB，开箱即用的 kvm-qemu 虚拟机管理程序需要很长时间才能启动 VM。相比之下，使用 cloud-hypervisor 进行了优化，系统使用多个 pthreads 并行对内存进行预故障，从而将 1TB 的内存预故障时间从 80 秒缩短到仅 6 秒。此优化由 Crusoe Cloud 创建，幸运的是已上传。根据我们的测试，Crusoe 的 VM 能够在不到 90 秒的时间内启动。

快速启动的重要好处是，当客户的 GPU 服务器不可避免地出现故障时，Neocloud 操作员可以非常快速地将 VM 部署到其热备用节点并将其添加到客户的 SLURM 集群中，从而使客户能够非常快速地恢复训练。

监控和常见错误

在监控仪表板方面，我们至少建议通过 Grafana 和 Prothemeus 使用 Nvidia Datacenter Manager 仪表板，以便用户跟踪 GPU 温度、电源使用情况和活动XID 错误。

此外，我们还建议 Neoclouds 安装 ipmi-exporter 来监控整体风扇速度、温度和其他 BMC 指标。在运行 CPU 部署时，使用某种集中式仪表板来显示所有这些指标是标准做法。

监控的软件架构包括在每个 GPU 节点上安装一个 IPMI 导出器和 DCGM 导出器，然后在 CPU 管理节点上部署 Prometheus 抓取器以与 GPU 导出器通信并将数据存储在 InfluxDB 数据库中。接下来，Grafana Web 服务器可以连接到 Prometheus 以可视化收集的数据。

高级 NeoCloud 操作员还将拥有一个 promtail 记录器，用于汇总每个服务器的诊断消息 日志。应及时标记的两个常见 dmesg 消息是电缆被拔出以及 NIC 和/或收发器温度过热。这些消息中的任何一个都可能表明您有一个不稳定的 InfiniBand 链路，需要在客户开始流失之前及时解决。

遇到的另一个常见错误是 GPU 通过 dmesg 或 DCGM XID 错误报告根本没有错误，但输出错误的矩阵乘法结果。这些错误称为静默数据损坏 。确定 GPU 上是否有 SDC 的最简单方法是使用 Nvidia DCGMI 诊断级别 4 工具 (sudo dcgmi diag -r 4)。该工具将捕获 95% 的最常见 SDC，但不幸的是会错过剩余 5% 的 SDC，导致非常漫长的调试过程和非常愤怒的客户。

NCCL 死锁和停滞都是非常常见的问题，可能会导致训练作业停滞 30-35 分钟，然后 PyTorch 的 NCCL 看门狗会终止整个训练作业。我们认为，如果 Neoclouds 添加自己的后台 NCCL 检查器来检查活动的 SLURM 作业并查看作业在过去 4 分钟内是否使用了超过 150W 的电量，那么 Neoclouds 可以在此领域为客户增加价值。如果用电量低于 150W，这可能意味着 NCCL 挂起并且存在某种死锁，机器人可能会自动向客户发送电子邮件，提醒他们重新启动 SLURM 作业。

一些最常见的 InfiniBand UFM 错误代码包括 110、112(链接中断)、329(链接中断)、702(端口被视为不健康)和 918(符号位错误警告)。我们通常建议用户在跟踪 UFM 错误时，如果遇到上述任何错误代码，应立即联系工程师进行进一步调查。但实际上，这些问题可能已经给 Neocloud 的许多客户造成了严重问题，他们已经向 Neocloud 运营商发送了垃圾 ping 消息。

我们强烈建议 Neocloud 运营商使用 Jira 等支持票务系统来跟踪所有硬件故障和客户问题。如果没有票务和客户管理系统，问题就会被忽视，导致客户流失率增加。

更多提示和测试

我们没有看到很多 Neocloud 操作员使用的另一个功能是 SLURM topology.conf。SLURM 拓扑配置功能将启动用户的 SLURM 训练作业并为每个等级分配一个 SLURM_ID，以减少主干级流量。对于某些重要消息，最佳地分配 SLURM_ID 将导致 20-30% 的速度下降。我们将在即将举行的 Nvidia NCCL 和 AMD RCCL 集体沟通深入探讨中进一步讨论这一点。

一般来说，我们建议您使用nccl-tests来分析您的集群，并与 Nvidia 和您的 OEM 的参考编号进行比较，看看是否存在任何性能不足或下降。

为了使 NCCL 测试变得简单，我们正在开发一个名为 ClusterMAX-NCCL 的单行函数来运行并将您的集群与一组参考结果进行比较。

在 ClusterMAX-NCCL 中，我们针对所有不同类型的集合体测试了从 16MiB 到 256MiB 的所有重要消息大小。我们最近推出了此工具的测试版，支持单节点 NCCL 测试。以下是加载和运行 ClusterMAX-NCCL 的一行代码:

docker run --gpus all --ipc=host --shm-size 192G -v $/results:/workspace/results semianalysiswork/clustermax-nccl

如果您的节点配置正确，您应该会看到类似以下的结果:

提供具有竞争力的价格、强大的可靠性和正确设置的集群是大多数 Neocloud 的主要价值差异。我们在这个集合之外看到的唯一差异化价值来自 Neocloud TogetherAI，Flash Attention 的发明者 Tri Dao 就在那里工作。TogetherAI 为其 GPU 客户提供一组独家的超优化 CUDA 内核，这些内核可以轻松集成到客户现有的训练代码中，从而为客户带来 10-15% 的训练吞吐量性能快速提升。

基本上，通过能够将训练速度提高 10-15%，客户可以节省 10-15% 的 GPU 支出，或者使用相同的 GPU 美元预算，在 10-15% 以上的代币上训练他们的模型，从而提高模型性能。我们认为，如果不克隆 Tri Dao，Together 创造的价值就无法在其他地方复制。

集群部署和验收测试

集群部署通常利用 OEM 的机架规模集成和部署团队。这些团队将在单个服务器级别和集群范围级别进行集成和测试，在此期间，网络测试将在 OEM 的集成工厂进行。我们建议集群范围的高温老化应持续至少 3-4 周，以捕获节点组件中所有与早期失效相关的故障。集成团队使用 LINPACK 作为老化和验收流程非常常见，但我们认为这不是一个很好的测试，因为 LINPACK 不会大量使用网络，也不会占用太多 GPU 的 HBM 内存，而是仅使用和测试 GPU 的 FP64 核心。相比之下，ML 训练非常依赖网络、HBM 和 BF16/FP16/FP8 张量核心，因此，我们认为需要进行实际老化相关组件的老化和验收测试。

在集成工厂完成集成和老化后，OEM 将打包所有机架和电缆，运送到 Neocloud 的数据中心，之后还需要两周时间才能将集群部署到这个主机托管数据中心。我们建议 Neoclouds 在现场设置集群后再进行 2-3 天的老化/验收测试，即使集成工厂老化已经完成。这是为了确保在运输或现场部署过程中没有硬件损坏。一个非常常见的问题是，由于在运输和设置过程中光纤连接端点上积累的灰尘导致 InfiniBand 链路抖动。解决此问题的方法是清洁抖动端点的光纤末端。但有时还有更深层次的问题需要发现和解决。

日常运营

Neoclouds 的日常运营主要包括一次又一次的“打地鼠”。拥有良好的内部管理和调试工具将使这个过程顺利进行，甚至令人非常满意/愉快，但很多时候 Neoclouds 没有足够的工程师来构建这些工具，因为具有讽刺意味的是，大多数工程师的时间将花在“打地鼠”上，而不是构建更好的“打地鼠”工具。

集群中最常见的问题包括 IB 收发器抖动、GPU“从总线上掉下来”、GPU HBM 错误和 SDC。大多数情况下，只需对物理服务器进行硬重启，或者在许多情况下构建 UI 按钮或教客户自己对服务器进行硬电源循环，即可解决这些问题。在其他情况下，解决问题的方法是拔下并重新插入 InfiniBand 收发器或清除光纤电缆上的灰尘。其他情况下，需要致电 OEM 或系统集成商，获得保修 RMA 以完全更换整个服务器。

如上所述，Neocloud 集群早期阶段的故障非常常见，因为大多数 Neocloud 在交付给客户之前不会在集群中进行烧机测试。正如 Yi Tay 所注意到的，在可靠性方面，未进行烧机测试的集群比进行烧机测试的集群差几个数量级。

这是 TogetherAI 和 Crusoe 得分很高的另一个方面，因为它们是为数不多的在将集群移交给客户之前进行数周磨合的 Neocloud 之一。此外，雇用和留住拥有多年 Nvidia GPU 和 InfiniBand 网络操作经验的人员的公司往往会遇到更低的故障率，因为关于如何正确调试和防止 AI 集群发生错误的未成文部落知识库中包含了大量关于如何设置可靠集群的知识。

我们发现，对于拥有 512 个 H100 的集群，顶级 H100 运营商通常平均故障间隔时间为 7 天。对于这些顶级运营商来说，大多数情况下，只需重启节点即可轻松修复故障。

半导体精品公众号推荐

专注半导体领域更多原创内容

关注全球半导体产业动向与趋势

今天是《半导体行业观察》为您分享的第3906内容，欢迎关注。

『半导体第一垂直媒体』

实时 专业 原创 深度

公众号ID:icbank

喜欢我们的内容就点“在看”分享给小伙伴哦