阅读收获
- ScaleUp Fabric核心价值与演进:剖析ScaleUp Fabric(如NVLink)如何通过“内存语义”实现GPU间高效通信,及其向NVSwitch的演进,以满足大规模AI训练需求。
- NVIDIA架构局限性:认识到当前NVLink/NVSwitch架构中内存与计算紧密耦合的缺陷,导致AI推理资源配置低效和成本高昂。
- CXL与UALink的互补:理解CXL和UALink作为开放标准,在AI基础设施中如何分别解决CPU层和加速器层的内存互联问题,推动内存与计算解耦。
- 内存池化变革:了解Fabric附加内存(FAM)和内存池化技术如何通过CXL和UALink实现内存独立扩展,构建更灵活、经济的AI计算平台。
全文概览
随着AI大模型参数规模的爆炸式增长,对计算和内存资源的需求已达到前所未有的高度。传统的服务器架构,尤其是GPU与CPU之间、以及GPU与GPU之间的数据传输瓶颈,是否已成为制约AI性能提升的关键?高速互联技术“ScaleUp Fabric”应运而生,旨在突破这些限制,但其演进路径和技术挑战也日益凸显。NVIDIA的NVLink/NVSwitch架构在ScaleUp领域独步天下,然而,其内存与计算紧密耦合的模式,尤其在对成本敏感的AI推理场景下,正面临资源配置效率的严峻考验。CXL和UALink等开放标准能否通过创新的“内存池化”技术,实现内存与计算的解耦,从而开启AI基础设施的新篇章?本文将深入探讨ScaleUp Fabric的演进、内存语义的价值,以及开放生态如何重塑AI算力格局。
GPU到GPU的内存事务通过Scaleup Fabrics传输
GPU到GPU的内存事务通过Scaleup Fabrics传输
PPT的核心观点是区分并强调了“ScaleUp Fabrics”(向上扩展结构)的概念。
- 区分两个扩展维度: 它明确区分了两种类型的网络/互联:
- ScaleOut (横向扩展): 指的是节点与节点之间的通信,使用以太网(Ethernet)或InfiniBand等标准网络技术。
- ScaleUp (纵向扩展): 指的是单个节点内部,特别是GPU之间的高速、专用互联。
- 定义ScaleUp Fabric: PPT以NVIDIA DGX-1为例,将其内部用于GPU间直接通信的NVLink互联结构定义为一种“ScaleUp Fabric”。
- 核心功能: 这种“ScaleUp Fabric”是实现GPU到GPU内存事务高效传输的关键通道。这意味着GPU可以直接、高速地交换数据,而无需(或减少)绕道CPU和PCIe总线,这对于大规模AI训练至关重要。
更大的Scaleup Fabric拓扑需要交换机
当构建更大规模的节点内“ScaleUp Fabric”时(例如从DGX-1的8 GPU扩展到DGX-2的16 GPU),直连的网状拓扑(Mesh)不再适用,必须引入专用的交换机。
- 可扩展性的挑战: 上一张的DGX-1(8 GPU)使用的是无交换机(switch-less)的NVLink直连方式。而当GPU数量翻倍到16个时(如DGX-2),全互联(all-to-all)所需的端口和布线复杂度会急剧增加。
- 解决方案:NVSwitch: 为了解决这个扩展性问题,NVIDIA引入了“NVSwitch”。DGX-2的架构利用12个NVSwitch构建了一个交换式NVLink结构。这使得所有16个GPU都能以全NVLink带宽(full NVLink bandwidth)进行“all-to-all”通信,就如同它们在一个巨大的交叉开关(Crossbar)上一样,极大地提升了GPU间的通信效率和带宽。
- 拓展ScaleUp Fabric的定义: 这张图不仅展示了NVSwitch作为NVLink Fabric的实现方式,还通过图例引入了“UALink”和“SUE”两个新概念,暗示“ScaleUp Fabric”是一个更广泛的术语,可以包含多种不同类型的节点内高速互联交换技术(NVSwitch只是其中一种)。
PPT的核心观点是定义“ScaleUp AI Fabric (SAIF)”是一个全新的、高价值的市场细分,它在技术上与传统的数据中心网络(即使是用于AI的Scale-Out网络)有着本质区别。
- SAIF的技术本质: SAIF的核心是“内存语义”(Memory Semantics)。它不仅仅是“快”(高带宽、低延迟),更是让节点内(或机架内)的多个GPU能够像一个单一的大GPU一样工作,实现内存的直接、透明访问。
- SAIF的市场定位: SAIF(深蓝色区域)被Gartner视为一个全新的增量市场,而不是对现有AI网络(浅蓝色区域)的简单替代。它正在快速增长,并将在未来几年占据数据中心网络市场(72B)的巨大份额。
- 行业格局:
- NVIDIA (NVLink) 目前主导这一领域。
- 新的行业标准和联盟(如 UALink)以及其他技术的出现,表明业界正在激烈竞争,试图打破NVIDIA的垄断,抢占这个价值270亿美元的新兴市场。
Scaleup的核心是内存语义,它意味着更高的性能
Scaleup的核心是内存语义,它意味着更高的性能
Scaleup Fabric的优越性不仅在于高带宽,更在于其根本的“内存语义”特性,这带来了巨大的性能收益和简化的编程模型。
- 定义了关键技术差异: 明确区分了两种架构的编程模型。“Scaleup”使用“内存语义”,允许GPU像访问本地内存一样访问其他GPU的内存(原生编程,透明访问),而“Scaleout”使用“动词/套接字语义”,需要复杂的软件重构(如MPI)来管理数据传输。
- 提供了量化性能证据: 通过对比NVIDIA自家的顶级产品(GH200 vs H100集群),PPT证明了“Scaleup Fabric”(NVLink)相对“Scaleout Network”(InfiniBand)在各种大规模AI和数据任务上实现了2倍到6.5倍的性能飞跃。
连接性的“三位一体”:UALink, CXL, Ethernet
连接性的“三位一体”:UALink, CXL, Ethernet
现代AI基础设施需要一个“三位一体”的连接模型,其中CXL和UALink(一种ScaleUp Fabric)是互补的,而非竞争关系,它们分别在不同的层级解决关键问题。
- 定义“连接三位一体”:
- Ethernet (Scale-Out): 负责节点间(Inter-node / POD-to-POD)的通信。
- CXL (Host-level Fabric): 负责主机/CPU层的互联,实现CPU间的内存一致性和对共享“CXL内存池”的访问。
- UALink (Accelerator-level Fabric): 负责加速器/GPU层的互联(Scale-Up),通过专用交换机将多个加速器构建成一个“大GPU”模型,实现“内存语义”(Memory Semantics)通信。
- CXL与UALink的互补性: 这张图清晰地表明,CXL和UALink服务于系统的不同部分。CXL解决了CPU的内存扩展和共享问题;UALink解决了GPU集群的高速内存通信问题。一个完整的AI服务器需要同时具备这两种技术,才能分别满足CPU和GPU的互联需求。
一个开放、可与NVIDIA匹敌的AI生态系统,需要两个关键的开放标准——CXL和UALink——来分别对标NVIDIA的两个核心专有技术。
- 功能解构: 它将NVIDIA的成功(如GH Superchip)解构为两个层面的互联:
- CPU-GPU(缓存一致性): NVIDIA使用 NVLink-C2C。开放生态需要 CXL。
- GPU-GPU(I/O一致性/内存语义): NVIDIA使用 NVLink。开放生态需要 UALink。
- “开放生态”的蓝图: 这张PPT清晰地描绘了“Open Ecosystem”(开放生态)的技术蓝图,即通过CXL + UALink的组合,来复现NVIDIA通过(NVLink-C2C + NVLink)实现的“CPU+GPU”紧密耦合以及“GPU集群”高速ScaleUp的能力。
PPT的核心观点是:通过量化数据(带宽和延迟)来展示“ScaleUp Fabric”(如NVLink)所启用的“内存语义”访问的性能特征和层级。
- 内存访问的层级性: 图表清晰地显示了内存访问的性能层级。对于GPU而言:
- 最快: 本地HBM(~350ns, ~3900 GB/s)
- 其次: 本地CPU的DDR(通过NVLink-C2C)(~850ns, ~500 GB/s)
- 再次: 远程GPU的HBM(通过NVLink "ScaleUp Fabric")(~1050ns, ~500 GB/s)
- 最慢: 远程CPU的DDR(~1250ns, ~500 GB/s)
- ScaleUp Fabric (NVLink) 的性能特征:
- “HBM-p”数据点(远程GPU内存访问)就是“ScaleUp Fabric”的性能体现。
- 高带宽: 它提供了约500-600 GB/s的带宽,这远高于传统PCIe,使得大规模数据在GPU之间移动成为可能。
- 高延迟: 但它的 延迟(~1050 ns) 显著高于访问本地HBM(~350 ns)。
- “大GPU”模型的代价: 结合前几张PPT,这张图说明了“ScaleUp Fabric”虽然能将多个GPU的内存(如HBM-p)聚合起来,形成一个“Large GPU”模型,但这种聚合不是没有代价的。它是一种 NUMA(非一致性内存访问) 架构:访问本地内存极快,访问远程内存(即使是通过NVLink)则会慢得多(高延迟)。因此,软件和算法必须意识到这种层级性,以优化数据局部性,才能真正发挥ScaleUp Fabric的威力。
面对更大型的LLM,Scaleup Fabrics能否实现内存和计算的独立扩展?
面对更大型的LLM,Scaleup Fabrics能否实现内存和计算的独立扩展?
当前主流的ScaleUp Fabric实现(特指NVIDIA的NVLink/NVSwitch架构)存在一个重大缺陷:它无法实现内存和计算的独立扩展(即解耦)。
- 回答了标题的问题: 标题问“能否独立扩展?”,而正文通过分析给出了否定的答案。
- 指出了问题的根源: 问题的根源在于“内存与计算的紧密耦合”。在这种架构下,内存(HBM/DDR)被“困在”了GPU和CPU芯片上。
- 揭示了“耦合”的后果: 这种耦合导致了“扩展困难”和“资源配置僵化”。用户无法按需独立增加内存池(例如为超大LLM模型),而必须被迫购买其并不完全需要的、昂贵的GPU计算资源。
- 点明了推理(Inference)的痛点: 这种低效的资源配比在“推理”场景下尤为突出,因为推理工作负载(与训练相比)通常需要更高的内存/计算比。
Note
超节点可能并不适合做大规模推理,内存被捆绑在大量计算资源上导致投资成本过高。
Scaleup Fabrics:内存池化
通过CXL和Fabric附加内存(Fabric-Attached Memory, FAM)技术,未来的ScaleUp Fabrics将实现“内存池化”,彻底解决内存与计算的耦合问题。
- 解答了上一张PPT的挑战: 上一张PPT指出NVIDIA架构的缺陷(内存必须随GPU购买)。这张PPT展示的架构(以UALink/SUE/CXL/Unifabrix为代表的开放生态)则通过“内存池化”解决了这个问题。
- 内存成为“一级公民”: 在这个新架构中,内存不再是CPU或GPU的附属品(不再只存在于"Fabric的边缘")。相反,内存(通过"Memory Switch")可以直接挂载到ScaleUp Fabric (UALink/SUE) 或 CPU Fabric (CXL) 上,成为一个可独立扩展、可被所有计算单元(GPU/CPU)按需访问的共享资源。
- 实现了真正的独立扩展: 这张图展示的架构允许用户独立扩展计算或内存。如果一个大型LLM推理任务需要海量内存但计算量不大,用户可以只向Fabric中添加“Memory Switch”模块(即内存),而无需购买昂贵的、计算力过剩的GPU。这使得资源配置(尤其是针对推理)变得高效且经济。
UnifabriX 产品视图/功能
测试数据
Fabric附加内存:最佳链路利用率:基于CXL over PCIe Gen5
Fabric附加内存:最佳链路利用率:基于CXL over PCIe Gen5
Unifabrix的Fabric附加内存(FAM)解决方案能够以极高的效率运行,几乎完全利用了底层CXL/PCIe Gen5物理链路的全部带宽。
- 提供量化证据: 它不是空谈理论,而是通过标准测试工具(Intel MLC)跑出了实际的性能数据。
- 对比理论极限: 它将实测数据与学术论文中的理论可实现带宽(已扣除协议开销)进行对比。
- 证明高效性: 95.7% 和 99.4% 这两个极高的利用率数字是强有力的证据,表明该FAM解决方案的实现非常高效,其自身的协议或实现开销(overhead)极低,成功地将硬件的潜力(PCIe Gen5)几乎无损地转化为了实际的内存带宽。
CXL 协议模式 68/256B Flit
三个术语代表了不同CXL版本中数据传输的“信封”大小和格式。
可以把它理解为在高速总线上传输数据的“标准快递盒”。无论要寄送什么(数据、命令),都必须先装进这种固定大小的盒子里。
延伸思考
这次分享的内容就到这里了,或许以下几个问题,能够启发你更多的思考,欢迎留言,说说你的想法~
- 在实际AI解决方案设计中,如何平衡ScaleUp Fabric带来的性能提升与其潜在的NUMA架构(非一致性内存访问)挑战,以优化数据局部性和整体系统效率?
- CXL和UALink等开放标准能否真正打破NVIDIA在ScaleUp Fabric领域的垄断,其生态建设、互操作性以及性能优化面临的最大挑战是什么?
- 对于不同规模和类型的AI工作负载(如训练、推理、边缘AI),ScaleUp Fabric、CXL和Ethernet的“三位一体”连接模型应如何进行最佳实践和资源配比,以实现性能与成本的最佳平衡?
原文标题:UnifabriX:Memory over FabricsTM for AI[1]
Notice:Human's prompt, Datasets by Gemini-2.5-Pro
#FMS25 #CXL内存扩展
---【本文完】---
👇阅读原文,独立站提前更新🚀(测试中)🧪
- https://files.futurememorystorage.com/proceedings/2025/20250806_AIML-202-1_HYATT_v3.pdf ↩