AI Neocloud Playbook and Anatomy
AI Neocloud 使用手冊與剖析

H100 Rental Price Cuts, AI Neocloud Giants and Emerging Neoclouds, H100 Cluster Bill of Materials and Cluster Deployment, Day to Day Operations, Cost Optimizations, Cost of Ownership and Returns
H100 租賃價格削減，AI 新雲巨頭和新興新雲，H100 集群物料清單與集群部署，日常運營，成本優化，擁有成本與回報

Dylan Patel and Daniel Nishball
作者: Dylan Patel 和 Daniel Nishball

Oct 03, 2024
2024年10月3日

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

原標題:AI Neocloud 手冊和剖析

H100租金降價、AI Neocloud巨頭和新興Neocloud、H100集群物料清單和集群部署、日常營運、成本優化、擁有成本和回報

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 使用獵鷹/GRD 部署帶有 8x200G 以太網的 H100。即使 Google 確實可以節省資金，在某些情況下這也會影響性能。

現在，我們先跳過機架級別，轉到集羣級別 BoM，從網絡開始，它是計算節點之後最大的集羣成本驅動因素。

集羣級別 – 網絡物料清單

H100集羣中有三種不同的網絡：

1.前端網絡（以太網）

2.後端網絡（InfiniBand 或 RoCEv2 以太網）

3.帶外管理網絡

簡單回顧一下，前端網絡只是一個普通的以太網網絡，用於連接互聯網、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 米，我們可以使用稱爲直接連接銅纜 ( 數模轉換器 ) 的“廉價”無源銅纜將服務器連接到葉交換機。對於這種設計，我們建議將 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 或 DCGMXID 錯誤報告根本沒有錯誤，但輸出錯誤的矩陣乘法結果。這些錯誤稱爲靜默數據損壞 (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