UEC終於來了，能撼動InfiniBand嗎？ - asiasworldcity.hk

「香港飛龍」標誌

本文内容：

公衆號記得加星標??，第一時間看推送不會錯過。來源：內容編譯自semianalysis。今天，超級以太網聯盟 (UEC)宣佈發佈UEC 規範 1.0，這是一箇基於以太網的全面通信堆棧，旨在滿足現代人工智能 (AI) 和高性能計算 (HPC) 工作負載的嚴苛需求。此次發佈標誌着我們朝着重新定義下一代數據密集型基礎設施以太網邁出了關鍵一步。UEC 規範 1.0 爲網絡堆棧的所有層（包括 NIC、交換機、光纖和電纜）提供了高性能、可擴展且可互操作的解決方案，從而實現了無縫的多供應商集成並加速了整個生態系統的創新。UEC 規範正在推動整個行業的採用，通過推廣開放、可互操作的標準來避免供應商鎖定。隨着積極的實施和合規計劃的推進，UEC 正在爲整個行業建立一箇統一且易於訪問的生態系統鋪平道路。超級以太網聯盟技術諮詢委員會主席 Hugh Holbrook 補充道：“超級以太網 1.0 規範是人工智能、高性能計算 (HPC) 和網絡專家、系統和芯片供應商以及網絡運營商通力合作的成果。它融合了與應用、傳輸協議、擁塞控制、直接內存訪問、以太網鏈路和 PHY 技術以及網絡安全相關的豐富知識、經驗和理念。這對行業而言是一箇里程碑式的發展，我非常高興超級以太網的公開發布，這將進一步推動以太網在人工智能和高性能計算領域的成功。”隨着 AI 和 HPC 工作負載以前所未有的速度不斷髮展，UEC 的專用以太網創新實現了：用於以太網和 IP 的現代 RDMA – 支持高吞吐量環境的智能、低延遲傳輸。開放標準和互操作性——避免供應商鎖定，同時加速整個生態系統的創新。端到端可擴展性——從路由和配置到操作和測試，UEC 可擴展到數百萬個端點。專爲現實世界集成而設計UEC 1.0 基於全球採用的以太網標準，簡化了從硬件到應用程序的整個技術棧的部署。它易於理解，並配備強大的工具，對於尋求低摩擦採用路徑的雲基礎設施運營商、超大規模企業、DevOps 團隊和 AI 工程主管來說尤其有價值。“作爲超級以太網聯盟主席，我很榮幸地宣佈發佈 UEC 1.0 規範——這是我們在人工智能和高性能計算時代重新定義以太網使命中的一箇重要里程碑，”超級以太網聯盟指導委員會主席 J Metz 博士表示。“這項標準是整個行業前所未有的合作成果，它提供了當今和未來最苛刻的工作負載所需的低延遲、高帶寬和智能傳輸。UEC 1.0 的發佈僅僅是一箇開始——超級以太網已經到來，它旨在擴展未來。”在 GenAI 熱潮初期，標準以太網的市場份額一度被 Nvidia 的 InfiniBand 搶佔。此後，以太網開始重新奪回市場份額，這主要得益於成本、InfiniBand 的各種缺陷，以及在以太網基礎上添加更多功能和定製的能力。那這個新標準，會帶來新變化嗎？超級以太網聯盟候選版本 1：深入審查超級以太網聯盟 (UEC) 候選版本 1 是一份內容豐富的文檔，長達 565 頁，於今日公開發布。這與優先考慮簡潔性的 Ultra Accelerator Link v1 規範形成了鮮明對比。UEC 本質上並不簡單；直接通讀幾乎難以理解。然而，通過結構化的方法可以揭示其底層邏輯。UEC 項目旨在爲以太網網卡和交換機提供傳輸層和流量控制層，以改善其在大型快速數據中心網絡中的運行。傳輸層確保用戶內容從源頭傳輸到目的地，並承載現代人工智能或高性能計算 (HPC) 用戶所需的所有命令。流量控制層確保數據以最佳速度流動，防止流量擁堵，並繞過故障或慢速鏈路進行重新路由。網絡接口卡必須實現 UEC 才能正常工作。交換機是可選的，網絡部分可以使用現有的以太網交換機。UEC 規範經過精心設計，因此不同供應商的設備應該能夠互操作。UEC上下文和核心塊UEC 在 Linux 聯合開發基金會 (JDF) 下運營，並作爲標準開發組織 (SDO) 運作。UEC 以以太網爲基礎，同時借鑑了其他一些規範或行業經驗作爲構建模塊。UEC 被設計爲本地網絡，旨在實現跨集羣的 1 到 20 微秒的往返時間，尤其針對數據中心。其主要目標是優化橫向擴展網絡，以用於 AI 訓練、AI 推理和高性能計算 (HPC)。該規範要求使用以太網標準作爲網絡 PHY，並要求交換機具備現代以太網功能。一箇關鍵的構建模塊是開放架構接口 (Open Fabric Interfaces)，也稱爲LibFabric。瞭解 LibFabric 可以解開 UEC 規範的前 120 頁。LibFabric 是一箇已被廣泛採用的 API，它標準化了 NIC 的使用。現有的綁定或插件將 LibFabric 連接到高性能網絡庫，例如 NCCL（來自 Nvidia）、RCCL（來自 AMD）、MPI（原始超級計算並行通信）、SHMEM（共享內存）和 UD（不可靠數據報）——這些網絡類型是人工智能或 HPC 超級集羣所必需的。UEC 並非一項全新的發明。相反，它建立在既定的開放標準之上，爲其操作定義了一箇可互操作的框架。互操作性顯然是核心關注點，因爲 UEC 對 API 如何與 CPU 或 GPU 配合運行沒有任何限制。LibFabric 圍繞用於數據傳輸、接收和特殊值以及完成的命令隊列展開。這種基於隊列的 NIC 交互已成爲 40 多年的標準。UEC 並不規定這些隊列如何與 GPU 或 CPU 構建，但要求支持所有 LibFabric 命令：發送、接收、RDMA、原子操作和特殊命令。超過 100 頁的文檔詳細說明了如何將這些命令封裝在消息頭中，以確保在不同供應商的 NIC 之間兼容執行。這有效地將 LibFabric 從 CPU/GPU 上的軟件堆棧轉換爲 NIC 上的硬件加速命令集。“作業”（Job）是源自 LibFabric 並集成到 UEC 的一箇關鍵概念。作業代表一組分佈在多箇端點上的協作進程。雖然功能上與 VXLAN 類似，但它利用的是 UEC 網卡內的交換矩陣端點 (FEP)，而非以太網 VXLAN。單個網卡可以承載多箇 FEP，但每個 FEP 都分配給一箇作業，並且只能與共享相同作業 ID 的其他 FEP 交互。可信交換矩陣服務負責管理這些作業及其關聯 FEP 的創建和終止。作業還可以包含加密域，從而提供安全的流量隔離。此外，還提供了具有靈活成員資格的作業，以適應動態服務環境。這些 LibFabric 概念和命令是必需組件。接下來，UE 傳輸層負責將 LibFabric 命令和數據內容傳送到 FEP，可能通過以太網，但理想情況下最好有可選層的支持。數據包層：第 3.2 節該規範真正有趣的地方在於3.2節，該節詳細介紹了數據包層。雖然沒有明確提及，但該層似乎大量借鑑了供應商在模塊化交換機方面的豐富經驗。它涉及將LibFabric消息分塊成更小的數據包並靈活地路由，同時明確考慮了可靠性和流量控制。UEC的既定目標是將這些功能集成到傳輸層。數據中心的延遲非常低，因此需要硬件加速的錯誤恢復和流量控制才能獲得最佳、流暢的流量。數據包引入了額外的報頭，但有助於在網卡和交換機之間交換網絡操作信息，而這與消息流無關。在模塊化交換機中，交換機的第二層（內部層）通過數據包處理此操作；然而，UEC依賴於網卡生成具有增強流量控制的數據包，並由增強以太網承載。UEC 專爲“fat”網絡而設計，其特點是 FEP 之間具有多條等距且速度相同的路徑。一種常見的現代實現是“rail”配置。在 UEC 網絡中，這可能涉及一箇 NIC，例如，一箇 800GbE 接口，包含 8 個 100 Gbps 通道。在交換機機架上，這 8 個通道中的每一條都連接到不同的交換機，也許是 8 個交換機，每個交換機有 512 x 100G 端口。這允許最多 512 個 FEP 連接到這 8 個端口。UEC NIC 旨在通過分配一箇“entropy”數在所有 8 個通道上“spray”消息，該entropy數在路徑中每次選擇輸出通道時對通道分配進行哈希處理。發送方選擇一箇entropy值來平衡路徑的使用，以填滿完整的 800 Gbps 吞吐量。至關重要的是，CPU 或 GPU 應用程序仍然不知道這種複雜性；他們只是通過 LibFabric 對消息進行排隊，然後 NIC 處理“magic of rails”。Rail magic 支持 512 端口交換機（目前較爲流行的選擇）以相同的拓撲結構並行使用，從而獲得多倍吞吐量的優勢。最大的進步在於，端點由單個網卡內的 UEC 進行協調，這樣主機就能感知到巨大的吞吐量，而網卡則會將流量分配到所有路徑上。廣泛的交換機基數對於構建大型集羣至關重要，而一致的拓撲結構則簡化了網絡的構建和管理。UEC 網卡經過精心設計，甚至可以處理跨多箇交換機層的路由。此外，多路徑上的數據包使 UEC 網卡能夠提供極快的丟失數據包替換和超快的流量控制，即使在應用程序調度不理想或偶爾出現網絡鏈路抖動的情況下也能確保流量順暢。第 3 節至 3.4 節詳細介紹了數據包和報頭的構造，並與 LibFabric 語義有所關聯。報頭可能很長，最多可達 44 字節，但針對頻繁傳輸的較短數據包優化後的報頭可以小至 20 字節。在預期最低的 UEC 通道速度 100Gbps 下，20 字節（160 位）轉換爲大約 1.6 納秒。雖然 UEC 的最大吞吐量將低於裸以太網的理論最大值（模塊化交換機通常使用速度稍快的背板來吸收數據包開銷），但 UEC 的以太網充當背板，導致用戶數據速率略低。這種權衡是爲了實現近乎完美的流量，這通常應該會提高實際數據速率。3.5 節（第 219 頁！）深入探討了數據包操作的細節。與命令和隊列不同，這是 UEC 獨有的。它似乎規範詳盡，顯然借鑑了模塊化交換機的經驗，但沒有提供任何外部參考，這表明它是一種共識設計，而非源自任何單一市場解決方案。考慮到 UEC 依賴以太網作爲背板，而現代模塊化交換機使用專有背板，這也合情合理。由於消息被分片成數據包，連接可以即時建立，無需 ACK（確認接收的回覆）開銷。雖然同一條消息的所有數據包都遵循相同的選定通道（以便於修復和重組），但消息本身可以且將會被分散到不同的通道上。通道選擇由報頭中的“熵”值（與真實熵無關）決定，該值代表路由選擇並具有相關的流量控制。啓用加密後，建立數據包連接會產生一些開銷（強制往返 ACK）。實際性能測試需要使用加密進行基準測試。希望這項開銷不會太大。丟失的數據包是根據序列號推斷出來的，並通過特定的請求進行替換，這是一種在預計數據包丟失率極低的數據中心中合理的方法（否則，就會出現更大的系統性問題）。擁塞控制：UEC-CC（第 3.6 節）3.6 節介紹了擁塞管理系統 UEC-CC——可選，但卻是選擇 UEC 的核心原因。這裏的設計選擇非常明智。UEC-CC 採用基於時間的機制，傳輸時間精度低於 500 納秒。前向和後向路徑獨立測量，這意味着網卡在絕對時間上同步，儘管規範中並未明確說明。雙向測量可以準確地將擁塞歸因於發送方和接收方。如果啓用了 UEC-CC，交換機需要使用 ECN（顯式擁塞通知），並且預計將使用現代 ECN 變體，其中擁塞標誌按流量類別設置，並在數據包傳輸前立即進行測量。這提供了最新的擁塞信息，並針對每個流量類別進行差異化處理。在嚴重擁塞的情況下，可以修剪數據包，只留下墓碑頭，以明確地將壞消息告知接收網卡——簡單地丟棄一箇數據包會減慢糾正措施的速度。這種機制至關重要，因爲接收 FEP（每個 NIC 有一箇或多箇）負責爲發送方設定步長。由於數據中心的往返時間 (RTT) 僅爲幾微秒，發送方可以在非常短的時間內發送數據而不會收到 ACK。接收方決定允許多少個新數據包，從而允許發送方在幾微秒內暫停發送，通常可以避免丟失數據包。接收方從分佈在多箇通道和流量類別中的 ECN 標誌收集豐富的流量狀況信息，從而爲其提供單獨的信用計數和所有到達數據包的概覽。它通過 ACK 和特殊的 Credit CP 命令將其決定傳達給發送方。這些決策還可以通過調整特定的“entropy capacities”來重新平衡路由，從而改變用於消息噴灑的平衡。UEC 在一定程度上標準化了（前向）糾錯率和丟包率的報告，從而能夠檢測使用弱鏈路的特定熵（entropy），並重新路由流量以避免這種情況。熵會在每個交換機上計算哈希跳躍選擇，預計熵的數量級將比通道數量高出一箇數量級，從而能夠在最大程度上隔離弱鏈路，同時最大程度地降低對整體路由容量的影響。至關重要的是，UEC-CC 棄用了一些流量控制方法。廣泛使用的舊方法 RoCE 和 DCQCN 會降低 UEC-CC 的性能，因爲與 UEC-CC 不同，它們不會直接更新流量控制以匹配流量問題的實際位置。優先級流量控制 (PFC) 沒有必要，必須在交換機之間禁用，因爲它可能會阻塞有效的流量。當網卡連接到交換機時，它也已被棄用，因爲它缺乏 UEC-CC 的精度，並且可能會過度減少流量。基於信用的流量控制同樣由於與 UEC-CC 的干擾而被棄用。傳輸安全子層（第 3.7 節）第 3.7 節“傳輸安全子層”技術性很強，而且看起來非常完善。它大量借鑑了成熟的方法，並融入了實用的更新。推薦的加密算法是後量子 DES 密碼。防禦性操作尤爲重要，並制定了定期隨機數 (nonce) 更改的規則。加密按域分配，域是作業中 FEP 的子集，其中包括一箇用於自適應域的變體，支持客戶端加入和離開的動態服務。巧妙的密鑰派生方案允許在整個域中使用單個密鑰，每個流都使用不同的密鑰和隨機數，同時最大程度地減少表空間佔用（作業可以包含數萬個端點）。數據中心結構必須包含可信組件：用於設置域的安全域管理實體 (SDM)，以及包含可信硬件的網卡 (NIC)，用於將其端口連接到域。雖然驗證和證明這些組件的版本超出了 UEC 規範的範圍，但可以要求供應商支持現有的開放標準。第 3.8 節爲第 3.7 節提供了有用的參考列表。其他層第 4 節，UE 網絡層，主要討論數據包修剪，這是擁塞控制的可選功能。第 5 節，即 UE 鏈路層，旨在通過鏈路級數據包替換和交換機之間的流量控制來提升整體性能。我認爲這會增加不必要的複雜性，尤其是在 UEC-CC 部分棄用了 CBFC（該層實現的）。在往返時間達到微秒的數據中心中，接收方前端端點 (FEP) 會根據全局流量信息做出質量流量控制決策，數據包丟失很少，並且 UEC 已經能夠在按計劃進行修復的同時繞過這些數據包（第 6 節很有幫助！）。規範的這一部分似乎增加了複雜性，卻沒有相應的價值。幸運的是，它是可選的，我敢打賭它永遠不會被廣泛使用。它肯定會使測試和互操作性測試（多供應商互操作性會議）變得複雜。第6節，即UE物理層，主要推薦遵循802.3/db/ck/df規範的多通道100Gb以太網。簡短的致歉指出，由於200Gb並非官方標準，因此無法引用。UALink規範引用200Gb沒有任何問題，而且這正是當前的趨勢。UEC應該以此爲起點，而不是僅僅達到目標。6.3 小節探討了如何使用 FEC（前向糾錯）遙測技術來監控和評估鏈路級可靠性。雖然 FEC 對任何網絡愛好者來說都極具吸引力，但其要點很簡單：FEC 非常有效，能夠讓正確初始化的數據中心鏈路上出現丟包的情況變得極其罕見。很高興在規範中看到它。UEC：主要優勢綜上所述，採用UEC的令人信服的理由包括：硬件加速的 LibFabric。精心設計的工作結構與現代加密技術相結合。數據中心擁塞控制，正確實施。消除有問題的 RoCE 和 DCQCN。現有的 CCL、MPI、SHMEM 和 UD 開源插件。UEC：注意事項值得注意的是，使用 LibFabric 的 Amazon EFA 網絡插件支持並非易事。雖然提供了插件配置，但 Nvidia 的立場往往並不支持，儘管支持底層接口，但仍然傾向於使用其專有解決方案。據報道，該插件在 EFA 網卡上獲得了良好的性能，但在較新的 UEC 網卡上的性能仍有待觀察。必須檢查通用的互操作性，不僅要檢查“是否正常工作”，還要檢查當端點來自不同供應商時性能是否穩定。當中間網絡不是 UEC 時，檢查 UEC 網卡的工作情況也很有用——只要確保交換機支持 UEC 確實使用和要求的功能，例如最佳實踐的 ECN 生成。與 UALink 和 SUE 的比較儘管編寫過程同樣細緻，Ultra-Accelerator Link 的規格說明長度還不到 UEC 的一半。Broadcom Scale-Up 以太網的描述則細緻但不拘泥於形式，只有 20 頁，並且假定其描述內容簡單明瞭。UALink 和 SUE 都專注於 ScaleUp，類似於 Nvidia NVLink。它們僅支持單個交換層和最多 1024 個端口（即 GPU 或 xPU）。這比 UEC 的目標（即構建具有多箇交換層和數萬個端點的橫向擴展網絡）要有限得多。這三個規範都假設一箇 AI 或 HPC 集羣，其軌道網絡可以最大化交換基數。SUE 和 UALink 自信地在其規格中提到 200GbE 鏈路，這使得 UEC 顯得有些落後。UALink 與 UEC 類似，將流量分散到不同的軌道上。UALink 明確闡述了基於信用的流量控制。相反，SUE 則推遲了這一方案，建議在以太網中藉助客戶端軟件實現——這是一箇更簡單的規範，但實際效果大致相同。UALink 將 4 條通道綁定在一起（例如 4×200）以實現更快的消息傳輸，而 SUE 和 UEC 似乎都認爲 200G 通道已經足夠快了。這是 UALink 中一箇額外複雜的領域，但價值似乎微不足道。SUE 建議以太網通過 PFC 或基於信用的流量控制（最好是）來處理流量控制。考慮到 PFC 在單交換機級別最有效，而 CBFC 可以提供更順暢的運行，這種方法肯定有效。UALink 實現了連接加密。SUE 更簡單地指出，以太網應該提供可靠性、數據完整性和加密。SUE 將消息噴灑和跨軌道負載均衡委託給端點內的軟件層。這對於專門從事此類軟件的公司來說無疑是一大優勢。SUE 和 UALink 都提供內存映射接口。這兩個規範均未規定內存映射的具體實現，但它們都期望通過讀取或寫入大型虛擬系統中另一箇端點對應的內存地址來發送/接收消息。這些接口應該與 NVLink 一樣高效，但由於它們不復制 NVLink 的數據包格式，因此需要插件或新的底層代碼。內存映射和主機結構內存映射通常被稱爲“內存語義”。映射——使用一箇大型虛擬地址空間爲每個主機分配其自身可識別的範圍——允許主機處理器使用讀寫指令和內存操作。它們不包含諸如排序和一致性之類的內存語義。不會發生內存偵聽，也不會對集羣周圍的緩存進行智能更新。對於包括 UEC 在內的所有這些系統，數據中心的運行速度和低延遲正在促使端點遷移到主機芯片結構上的協處理器，而不是通過日益過時的“IO 總線”進行遠程控制。這更像是將端點（NIC）視爲多核系統中的一箇核心。這簡化了計算核心（流式 GPU 或經典 CPU）之間發送命令以及端點與主機內存交互的高效互操作。我們可以預期 SUE 和 UALink 將以集成到主機芯片中的 IP 塊形式出現，而不是將它們作爲單獨的芯片。NVlink 已經存在一段時間了，英特爾 Gaudi 3 或微軟 Maia 100 等芯片也通過以太網鏈路實現了這種功能。這簡化了 IP 塊，但也要求它們足夠簡單，以減少在主機芯片中的佔用空間。UEC 的複雜性可能會體現在單獨的 NIC 中，但很快就會集成到主機架構中。或許是以 chiplet 的形式？https://semianalysis.com/2025/06/11/the-new-ai-networks-ultra-ethernet-uec-ualink-vs-broadcom-scale-up-ethernet-sue/*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅爲了傳達一種不同的觀點，不代表半導體行業觀察對該觀點贊同或支持，如果有任何異議，歡迎聯繫半導體行業觀察。今天是《半導體行業觀察》爲您分享的第4063期內容，歡迎關注。加星標??第一時間看推送，小號防走丟求推薦

(本文内容不代表本站观点。)
---------------------------------