（原标题：手把手教你搭建GPU算力中心）九游会体育-九游会欧洲杯-九玩游戏中心官网

若是您但愿可以时常碰头，宽宥标星保藏哦~

来源：内容编译自semianalysis，谢谢。

AI Neoclouds 的崛起眩惑了通盘狡计行业的关注。从企业到初创公司，每个东谈主齐在欺诈它们来造访 GPU 狡计。即使是微软，尽管领有我方的数据中心建设和运营团队，每月也通过 AI Neoclouds 在 GPU 狡计上破耗约 2 亿好意思元。Nvidia 通过径直投资、无数分派 GPU 以及在多样演打仗行为中的嘉赞，预示着多个 AI Neoclouds 的快速增长。

AI Neocloud 被界说为一种新式云狡计提供商，专注于提供 GPU 狡计租出作事。这些隧谈的 GPU 云为其客户提供顶端的性能和活泼性，但为其提供能源的经济性仍在不竭发展，因为商场正在了解其生意模式的运作方法。

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

巨东谈主与新兴企业

AI Neocloud 商场由四类主要提供商提供作事：传统超大规模提供商、Neocloud 巨头、新兴 Neocloud 以及经纪商/平台/团员商。

AI Neocloud 商场规模无边，是 GPU 需求最特真理真理的增量驱动要素。总体而言，咱们以为 Neocloud 的增长将越过总需求的三分之一。

提供 AI 云作事的传统超大规模提供商包括 Google Cloud (GCP)、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) 或类似 VC 的实体为投资组合或其他附庸公司建立集群。闻明的例子包括 Andromeda、AI2、Computefund.ai和Andreesen Horowitz 蓄意的 GPU 集群。借助里面集群，这些 VC 可以提供绝顶活泼的狡计租出选项——在短时辰内提供大型 512 或 1k GPU 集群，远低于其他 Neoclouds 为换取股权而收取的用度。他们还可以提供股东的租出条件，以进一步向投资组合或附庸公司歪斜。

如何构建 AI Neocloud

一、了解集群物料清单

让咱们从一个浅薄的框架脱手。那么，您想启动 AI Neocloud 吗？您会何如作念？这是咱们的分步指南，从 BoM 脱手，终末成立 Neocloud。

鸠合和定制 AI 集群报价和物料清单 (BoM) 是 Neocloud 部署中最蹙迫的要素之一，正确处理可能会决定利润率高下或财务窘境。咱们提议从 CEO 到工程师和销售东谈主员的每个东谈主齐了解其 BoM 中的每一项家具。

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

OEM 和 Nvidia 在报出 BoM 时天然会寻求涨价销售。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集群中有三种不同的蚁集：

前端蚁集（以太网）

后端蚁集（InfiniBand 或 RoCEv2 以太网）

带外不停蚁集

浅薄追念一下，前端蚁集只是一个普通的以太网蚁集，用于勾通互联网、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 不是勾通到架顶 (ToR) 交换机，而是来自 32 台作事器的 8 个 GPU 索引中的每个 GPU 索引齐有我方的交换机。举例，来自扫数 32 台作事器的扫数 GPU #0 齐勾通到叶交换机 #0，来自扫数 32 台作事器的扫数 GPU #1 齐勾通到叶交换机 #1，以此类推。

轨谈优化蚁集的主要上风是减少拥挤。若是来自团结作事器的扫数 GPU 齐勾通到团结个 ToR 交换机，当它们同期尝试将流量发送到蚁集中时，它们尝试使用不异链路遍历胖树蚁集的可能性会绝顶高，从而导致拥挤。用于 AI 覆按的 GPU 应该会按期一次性发送数据，因为需要集体操作来交换梯度并更新新参数。

下图第一张图展示了一个 8 轨优化蚁集，其中有 8 个来自集体通讯的并行流用于勾通 8 个不同的叶交换机，而第二张图展示了一个非轨优化假想，其中作事器勾通到 ToR 交换机。

Nvidia 参考架构还将集群辞别为 4 个 pod（也称为可扩展单元或 SU），每个 pod 包含 32 个 HGX 作事器（256 个 H100）和 8 个轨谈。每个 GPU 索引历久与 pod 内另一台作事器中的不异 GPU 索引相距一跳。这很蹙迫，因为它可以减少骨干交换机上的蚁集流量，而骨干交换机很容易成为拥塞热门（即使在非落魄蚁集上亦然如斯）。

与广阔看法相背，在多田户环境（举例 GPU Neoclouds）中，优化轨谈并减少顶层流量/拥塞尤其蹙迫，因为在这种环境中，您闲居会有多个田户/客户。在 8 轨谈优化蚁集中，每个使命负载的扫数 8 个流齐是物理分离的，因此不会发生路由/交换冲突。在咱们行将推出的 Nvidia NCCL 和 AMD RCCL 集体真切探讨中，咱们将磋议轨谈优化设立的刚正以及为什么拥塞可能是一个严重的问题，尤其是对于 AI Neoclouds 等多田户环境。

灾祸的是，拥塞问题无法通过 nccl-tests 闲居测量，而是需要现实寰宇的并发使命负载才略了解嘈杂邻居/拥塞问题如何影响端到端使命负载隐晦量。若是田户之间莫得物理羁系，嘈杂邻居将永久存在。鉴于咱们在拥塞问题上所看到的情况，咱们蛮横提议给与某种神志的 8 轨优化拓扑。

轨谈优化拓扑的另一个刚正是，由于大多数流量将在叶交换机腹地进行，因此可以逾额订阅蚁集的骨干层，这是一种架构优化，咱们将在本文背面磋议。

优化光纤与电气蚁集

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

在 Nvidia 参考假想中，叶交换机位于单独的蚁集机架上，而骨干交换机位于专用的蚁集机架上，这意味着需要使用 100% 的光学器件。

为此，可以辩论使用一种蚁集拓扑结构，即无落魄机架顶部 (ToR) 假想。大多数具有传统蚁集配景的东谈主齐会立即认出这种假想，因为它是传统蚁集中最常见的假想，其中在机架中间或顶部有一个交换机，用于勾通机架中的扫数作事器。由于 ToR 交换机与作事器之间的距离小于 3 米，咱们可以使用称为径直勾通铜缆 (DAC) 的“廉价”无源铜缆将作事器勾通到叶交换机。对于这种假想，咱们提议将 InfiniBand 交换机放在中间，以指责 DAC 电缆需要传输的距离。

从叶交换机到顶层骨干交换机，咱们齐必须使用光纤。这很上流，但至少 50% 的勾通目下将被更低廉的 DAC 铜缆取代。

灾祸的是，对于这种假想，您将无法完毕 8 轨优化蚁集，因此，即使您的骨干层是无落魄的，您也闲居会遭遇拥塞热门，因为目下有 8 个流跨越多个交换机级别，这意味着每个流齐需要动态使用不同的旅途来幸免拥塞。在领有完整自顺应路由的盼望寰宇中，ToR 将手脚拓扑很好地使命，因为路由将历久幸免拥塞阶梯。但在现实中，由于完整的自顺应路由并不存在，因此完毕这种拓扑将严重挫伤蚁集性能。

下图是咱们对这种无落魄机架顶部结构的模拟热图，其中浅蓝色暗意由于拥塞导致带宽减少，深蓝色暗意接近满线速率。如您所见，使用 ToR 拓扑可以达到线速率，但由于扫数 8 个流齐干涉一个交换机，因此仍然存在相当大的拥塞，由于拥塞，隐晦量变得愈加不踏实，而且这些流的带宽更少。

尽管这种假想的性能对于 Neoclouds 这么的多田户环境来说并不是稀薄好，但成本量入为用掉是无边的，量入为用了 34.8% 的后端 InfiniBand 结组成本。

臆造模块化交换机

目下，若是咱们可以兼顾两全其好意思的上风，既能优化 8 轨的性能上风，又能量入为用 ToR 的成本，那会若何？

这即是臆造模块化交换机的作用所在。它具有与 Nvidia 参考假想不异的逻辑拓扑，但由于好意思妙的平面有蓄意和交换机位置有蓄意，可以使用从叶交换机到骨干交换机的铜线。

这里的基本念念想是将交换机机架径直放弃在相互之间，这么骨干交换机位于中间机架，而叶交换机位于左机架和右机架，如下图所示。这么，叶交换机和骨干交换机之间的勾通可以全部给与铜缆，而作事器和叶交换机之间的勾通仍将使用光纤。

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

这种假想应该能让咱们两全其好意思，然则这种拓扑结构有什么短处呢？

灾祸的是，这些交换机到交换机的 DAC 铜缆时时盘曲半径较小，而且绝顶粗，导致气流受阻。咱们之前在坐褥中看到过类似的假想，若是你能很好地不停电缆，这些问题就可以克服。这个问题也可以使用有源铜缆 (ACC) 来处置，这种铜缆险些和多模光纤一样细，羼杂半径也很好。灾祸的是，咱们据说的一个潜在问题是 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(10k) 到 O(100k)），咱们以为这比只是制造您我方的臆造模块化交换诡秘破耗更多。

灾祸的是，使用 InfiniBand 的短处之一是，要领有一个可以的 REST 接口，您需要购买 UFM 不停许可证。协调结构不停器 (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 等，但这些开发的价钱不会权臣增多集群总老本支拨成本。

在默许的 Superpod 参考架构中，Nvidia 偏激 OEM 配合资伴会试图向您出售一种名为“Nvidia AI Enterprise”或“Base Command Manager (BCM)”的家具，其提议零卖价为每 GPU 每年 4,500 好意思元。BCM 是一个提供 AI 使命流和集群不停的软件包，但由于大多数客户会知足我方的使命流需求，因此对于 Neocloud 企业来说，这不是一款有价值的软件，但销售代表仍会将其手脚运转采购订单的一部分进行营销。这是咱们 SemiAnalysis Optimized Cluster BoM 的另一个无边成本量入为用来源。

集群 BoM 老本支拨摘录：

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

如下所示，使用 Nvidia Superpod 参考架构 (RA)，集群的总成本达到每台狡计作事器约 31.8 万好意思元（不包括存储），但使用 SemiAnalysis 优化架构和 2:1 逾额认购，总总成本仅为每台狡计作事器 28.3 万好意思元（也不包括存储）。咱们通过谈判匡助 Neoclouds 进一步优化，尤其是在大型集群上进一步削减成本。

驱动法度、用户体验和软件

若是您来荒诞型科技公司或国度 HPC 实验室，那么用户需求就很浅薄。用户需要正常运行的 GPU、蚁集、正确装置的驱动法度、正常运行的分享存储和调整法度（举例 SLURM 或 Kubernetes）。关联词，现实情况是，绝大多数 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 (MLNX_OFED) 驱动法度。此软件包是 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% 的客户还必须草率在需要时手动将交互式末端（即 ssh）接入其 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 (scp) 手动将代码复制到每个节点。

使用 Neocloud 存储时，用户对存储感到仇怨的主要原因是文献卷立时卸载以及用户遭遇无数小文献 (LOSF) 问题。处置立时卸载问题的方法是使用名为“ autofs ”的法度，该法度会自动保持分享文献系统处于挂载状态。

其次，LOSF 问题可以闲居幸免，因为唯独当您决定推出我方的存储处置决策（如 NFS 作事器）而不是为 Weka 或 Vast 等存储软件供应商付费时，它才会成为问题。若是集群上存在 LOSF 问题，那么最终用户很快就会瞩目到集群上的 LOSF 问题，因为即使将 PyTorch 导入 Python 的时辰也会导致全齐滞后。

下图是咱们在 Crusoe 集群上进行测试时生成的，展示了经过优化且不存在 LOSF 问题的集群存储处置决接应如何运行。如您所见，即使增多 GPU 数目，将 PyTorch 导入 Python 进度所需的时辰也保持相对牢固。

这与在未优化的分享存储上运行的集群有着一丈差九尺，在 Python 多节点覆按运行中导入 PyTorch 所需的时辰激增，时常导致集群全齐无法使用。请瞩目 Crusoe（黄金尺度）与另一个存在 LOSF 问题的集群之间的各异。

多田户

除非通盘客户（田户）历久租用通盘物理集群，不然每个物理集群可能齐会有多个并发客户。这意味着您需要羁系前端以太网和后端 InfiniBand 蚁集，并在客户之间完毕有储羁系。每个客户闲居会将每个 GPU 作事器手脚一个举座来租用，这意味着在狡计作事器上臆造化并不是严格需要的，因为每个物理作事器唯惟一个客户。花时辰细分节点是不值得的。使用尺度 vLAN 可以闲居为前端以太网成立羁系。在 vLAN 中，天然物理以太网结构是分享的，但每个客户的节点只可与分派给团结客户的其他节点通讯。

与以太网 vLAN 比较，InfiniBand 多田户的成立和自动化并不那么容易，但学习弧线绝顶快。在 InfiniBand 寰宇中，蚁集羁系是使用分区密钥 (pKeys) 完毕的 - 实质上与 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 的数据软件中，您可以闲居创建田户（在 Weka 中称为组织）并为每个存储卷成立造访限度战术，以便仅分派给一个田户。该软件提供了强有劲的保证，若是战术成立正确，则每个客户的用户只可造访他们我方的存储卷。

裸机或臆造化

对于 H100 SXM，最小狡计单元是一台作事器，这意味着每台作事器每次只可有一个客户。这意味着可以在保持安全性的同期进行裸机部署。裸机是可能的，而且如实很常见，但咱们如实看到使用臆造机具有极度的刚正，举例更长的平均复原时辰和更强的可靠性。

使用臆造机时，若是客户正在使用的物理 GPU 作事器出现故障，那么 Neocloud 草率闲居地在热备用作事器上为客户迁徙或启动新的臆造机。

可以使用开源臆造机不停法度（举例 qemu-kvm）在 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 的传输带宽和蔓延会略慢。但咱们以为使用臆造机是值得的，因为它对最终用户来说平均复原时辰更快，而且主机到开发 (HtoH) 的传输闲居与狡计访佛，因此对最终用户来说以至可能不会有显明的影响。

由于 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) 日记。应实时标记的两个常见 dmesg 音尘是电缆被拔出以及 NIC 和/或收发器温渡过热。这些音尘中的任何一个齐可能标明您有一个不踏实的 InfiniBand 链路，需要在客户脱手流失之前实时处置。

遭遇的另一个常见诞妄是 GPU 通过 dmesg 或 DCGM XID 诞妄论说根柢莫得诞妄，但输出诞妄的矩阵乘法完毕。这些诞妄称为静默数据损坏 (SDC)。笃定 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 $(pwd)/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 天。对于这些顶级运营商来说，大多数情况下，只需重启节点即可闲居建造故障。

https://www.semianalysis.com/p/ai-neocloud-playbook-and-anatomy

半导体极品公众号保举

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

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

*免责声明：本文由作家原创。著述内容系作家个东谈主不雅点，半导体行业不雅察转载仅为了传达一种不同的不雅点，不代表半导体行业不雅察对该不雅点赞同或支撑，若是有任何异议，欢管待洽半导体行业不雅察。

今天是《半导体行业不雅察》为您分享的第3906内容，宽宥关注。

『半导体第一垂直媒体』

实时 专科 原创 深度

公众号ID：icbank

心爱咱们的内容就点“在看”分享给小伙伴哦

九游会体育-九游会欧洲杯-九玩游戏中心官网