不出意外,AI是今年云栖大会的绝对主角,无论是主论坛的主旨演讲还是各分论坛的大咖论道,无不充斥着人工智能的青春荷尔蒙。作为资深网工,我们重点带大家探秘10.31日下午的《可预期网络:AI Infra》专场。可预期网络专场邀请了英伟达SVP Gilad,博通VP Mohan,以及阿里云基础网络负责人蔡德忠等行业顶级专家齐聚云栖小镇,颇有些华山论剑的味道。再加上IB和以太网在AI集群市场上的激烈厮杀,以及近期国际上成立UEC联盟来构建新一代高性能网络等最热门的话题,显而易见的结果就是两个字,“火爆“。几百人的会场,3个小时,从始至终座无虚席。
主旨演讲1:阿里云《端网融合的可预期网络》
言归正传,论坛的第一个主旨演讲是阿里云的蔡德忠,付斌章和席永青带来的《端网融合的可预期网络》。这个演讲对阿里云针对AI集群网络的设计理念以及当前的解决方案做了深入的阐述,干货满满,尤其是很多AI大模型实际的训练数据和流量模型是第一次向外披露,充分展示了阿里云基础设施团队的硬核创新能力,体现了阿里云作为业界头部云厂商推动业界进步的技术担当。整个演讲内容分为三部分:
Part 1: 为什么需要AI集群网络?
首先,传统数据中心网络内的东西向流量呈现“多、小、相对稳定“的特点,而AI集群内的东西向流量则呈现”少,大、突发/并发“的特点。根据演讲中的示例,某ECS大客户的链接规模达到了100K规模,而灵骏大客户训练任务的链接数只有60多个。正是因为有1000倍的数量上的差异,所以原本在通用计算场景下无法实现的per-flow的流量工程,在AI场景都变得顺理成章了。
另外,因为ECS集群内同时运行的任务种类和数量更多,很多个小流汇总在一起,反而在统计学意义上呈现出一种“相对稳定”的状态,但是总的带宽利用率也仍然只有20%左右。
灵骏集群内的流量则完全不同,因为训练任务是周期性迭代的,导致网络上的流量也是周期性的突发,并且每次突发都可以打满网络带宽。这就给网络设计带来了很大的挑战,因为网工们都知道“少量大象流”是ECMP的噩梦,非常容易导致Hash不均的问题出现。
阿里云的解决办法是多级的流量工程,从最上层的任务调度一直到最底层的Adaptive Routing,根据实际部署实践,这套“降龙十八掌”打下来,很好的解决上面这些问题,最后展示的大幅度性能提升也佐证了这种多级流量工程带来的效果。
Part2: 如何构建AI集群网络?
其次,并行训练需要的GPU数量越来越大,并且GPU服务器有NVLINK提供机内高速互联。
基于这两个前提,阿里云的HPN7.0架构基于博通 51.2T的TH5交换芯片搭建了一个单层1K GPU,2层16K GPU的极致性能网络架构,并且已经在上个月正式开服了,这也是全球第一个实现51.2T交换机大规模商用的云厂商,一方面说明阿里云有足够的前瞻性,准确预测了需求,同时也证明其强大的研发能力。
另外,演讲中比较有意思的一点是关于集群最大规模的讨论。因为业界也有可以支持更大规模的集群架构,但是阿里云的架构师强调这些更大规模的集群架构在当前IDC功耗限制下是没有意义的。这个观点与英伟达的首席科学家Bill Dally在今年的某次演讲中表达的观点不谋而合,即当前的AI集群是“power gating”的。
如果国内的IDC的总功率仍停在每栋楼10MW左右的能力,那么单集群搞10W卡或者更大其实意义也不大。毕竟因为时延的关系,我们一般不会跨楼构建集群。但是这里有个变量,在新的法规限制下,单芯片算力下降了,那么是否就需要更大规模的网络架构可能是一个需要重新讨论的问题。此外,在强大的需求推动下,相信未来也会有超高功率的IDC出现。
最后就是面向serverless场景的技术挑战。事实上,阿里云在容器网络领域也有很深的技术积累。Nimitz容器网络从2017年开始在阿里内部服务ODPS业务,21年开始和高网相结合,构成了一套完整的支持多租的高性能网络解决方案。在AI这个场景下,由于并行训练任务对高性能网络的性能有极致追求,而传统的SRIOV+VxLAN的标准解决方案会带来不可忽略的性能损失,所以阿里云提出了全新的vSolar+RDMAv6的解决方案。
vSolar是对Solar RDMA的扩展,也是Solar RDMA从存储走向计算的一个重要优化。通过基于virtio的混合虚拟化技术,既保证了租户隔离的安全需求,同时确保性能敏感的数据通路没有任何性能损失,再配合基于IPv6的地址编码技术RDMAv6实现了网络地址的隔离。最终在这套解决方案的加持下,阿里云自研的高性能网卡EIC虽然是基于FPGA实现的(underlay性能不如ASIC方案),其overlay网络性能完全可以媲美ASIC方案,这就是架构创新的优势吧。再叠加阿里云自研的HPCC拥塞控制和多路径传输技术,应用的端到端性能可以更上一层楼。
Part3:未来展望
由于时间的关系,未来展望部分讲的比较简短。核心的观点是坚定的基于开放的以太网生态打造新的高性能网络技术,特别提到了GPU的互联部分。当前以英伟达为主导的异构计算生态下,GPU的IO分为PCIe(以太)和NVLINK两个部分,其中 PCIe/以太部分用于实现scale out,NVLINK部分用于实现scale up。而当前国际上的UEC联盟也在探索GPU全出以太网接口,即无论scale out还是scale up都采用以太网。这种方法的好处是显而易见的,因为以太网是开放的,可以吸纳全球的力量来促进技术进步。
主旨演讲2:英伟达《Networking for AI》
第二个主旨演讲来自于英伟达的Gilad,他是Mellanox的联合创始人,英伟达全球高级副总裁,在HPC和高性能网络领域有着丰富的经验。同时Gilad来自以色列,这一次也是排除了万难(换了3班飞机)才来到了中国参加云栖大会,说明了他对中国市场以及云栖大会的高度重视。对于他的到来,现场观众也报以了雷鸣般掌声,来表达了欢迎和感谢。Gilad的演讲题目是《Networking for AI》。回想今年在中国台湾举行的ComputeX大会上,Jensen Huang就介绍了Spectrum以太网方案。当时业界就有疑惑,难道英伟达放弃IB了吗?这次Gilad演讲给出了还算比较清晰的定义,Spectrum面向AI Cloud,而IB面向AI Factory。
关于设计理念部分,Gilad的见解和阿里云基本相同,也强调了网络性能的重要性,特别是长尾时延的重要性。因为AI训练是典型的并行计算应用,一个慢节点就会导致整个任务的性能下降,所以只是峰值性能高是不能满足要求的。为了解决这个问题,英伟达在Spectrum+BF3的整体以太网方案率先支持了Adaptive Routing技术,从而可以实现稳定的、可预期的网络性能。Gilad也多次提到可预期(Predictable),这一点和阿里云的观点完全一致,正所谓英雄所见略同。
可以预料到的是,Gilad最后还是转向推荐他们的IB解决方案。与以太网相比,IB最大的优势在于对In-network Computing的支持,例如SHARP技术。根据Gilad展示的数据,使能SHARP之后集合通信性能是默认模式下的1.7倍,这个收益还是非常具有吸引力的。据说国内不少厂商都采购了IB,并且在积极推动SHARP的应用。不过按照UEC披露的信息来看,未来以太网交换芯片也会支持相关功能,咱们拭目以待吧。
主旨演讲3:博通《Unleashing Ethernet: The Ubiquitous choice of Networking for AI/ML Clusters》
第三个主旨演讲来自于博通的Mohan,他是博通全球副总裁、首席架构师。Mohan的演讲题目是《Unleashing Ethernet: The Ubiquitous choice of Networking for AI/ML Clusters》。博通作为以太网交换芯片的绝对领导者,其态度非常鲜明,即基于以太网打造AI/ML集群网络。背景部分不再重复,直入主题。Mohan演讲中重点强调了“调度”的重要性,包括switch scheduled和endpoint scheduled两种方案。
Switch scheduled方案是利用Jericho3-AI作为leaf交换机,利用Ramon3作为spine交换机。其核心思想包括几点:1)在leaf交换机之间建立credit流控,只有接收端的交换机有空闲的credit,发送端交换机才允许将报文注入网络,2)报文在注入网络时,会被切成固定大小的“cell”,并将不同的cell均匀的分发到不同的网络路径上,实现负载均衡,3)用VOQ技术避免HOL blocking。由于时间关系,Mohan在会上讲的细节不多,感兴趣的同学可以参考这个演讲(博通交换机调度方案)。
端侧调度的核心思想来自于NSDI‘22的论文(EQDS论文),基本思路还是receiver-based credit调度。最近几年,sender调速和receiver调速的争论很多,其实Bill Dally教授在《Principles and Practices of Interconnection Networks》一书中讲解input-arbiter和output-arbiter的时候分析的很清楚,两者本质上没有区别。另外,ACK和credit又有什么区别呢?ACK的目的不也是用于释放/增大窗口吗?那么稍微优化一下ACK的反馈机制就够了?总体上感觉,虽然博通和阿里云都在讲流量调度,但是阿里云的视角更宽一些,从集群任务调度到底层AR都有涉及,而博通的方案还是局限在网卡和交换机。当然这与两个公司在生态中的站位是有关的。个人感觉阿里云的方案更全面。
当然Mohan演讲中最吸引眼球还要是UEC话题。UEC最早是在今年OCP大会上公开的,博通、AMD、Intel、Meta、Microsoft是其中的主力成员,目标是在AI/ML这个市场上构建基于以太网的网络生态。目前AI集群中,GPU网络仍然分为scale out网络和scale up网络。Scale out网络的实际标准是RoCE和IB,scale up网络的事实标准是NVLINK。UEC的核心目标是把两个网络都统一到以太网。但这也并不是很容易,例如NVLINK需要支持缓存一致性协议,从而可以实现一个“Giant GPU”,以太网是否可以高效的支持缓存一致性协议是目前主要的问题。
圆桌论坛
前面的演讲精彩纷呈,圆桌会议也是热烈非凡,颇有华山论剑的感觉。
在AI大模型时代,数据中心网络架构该如何演进,高性能网络协议又该如何演进是目前行业内最热门的话题,针对这个问题,专家们的观点总体上是一致的,即网络的发展一定是要满足应用需求来发展的,那么当前最重要的需求还是支持更大规模的模型训练,那么协议的设计、AR和CC算法的设计都是围绕这个目标来展开的。
为此,UEC已经在尝试给出自己的答案,但是也有专家提出UEC并不是目前唯一的“努力”,谷歌也提出了Falcon方案并计划开源。由于UDP提供了一个最基础的datagram语义,所以Falcon也是采用了业界普遍的做法,和SRD、Solar 一样,采用在UDP之上进行扩展的方式来满足各自的业务需求,在高性能网络传输的核心功能方面,Falcon 和阿里的 Solar-RDMA,AWS 的SRD 没有太多本质区别,都是围绕多路径传输,更加先进的流控,以及支持更大规模连接方面在增强,但是Falcon在安全性,以及协议的多样性支持方面有所增强,从而可以支持多种应用,例如RoCE和NVMe,甚至 TCP,但是据一些渠道获取的信息,Falcon 在Google 内部并没有大规模部署。
关于NVLINK 和IB 的关系,Gilad也阐述了自己的观点,他认为NVLINK和IB是面向不同场景下设计的,所以两者之间不存在替换的关系,所有在未来不会看到IB完全取代NVLINK的情况,不过在需求的推动下,目前GH200已经支持了256个GPU通过NVLINK Switch互联,未来这个网络的规模可能会更大,当NVLINK大规模组网时也会遇到以前大规模IB或者以太网已经遇到的扩展性问题,所以NVLINK在某种程度上与IB进行协同甚至融合又是一个确定性的趋势。
在GPU集群如何 scale up 方面,Mohan坚持认为未来会统一到Ethernet,事实上,AMD和Intel最新的GPU已经在使用以太网来实现Scale up网络了,那么是不是可以说技术上全部基于以太网是可行的,那么剩下的就是商业选择了,不同厂家可能会有不同的选择。
如果从客户的角度来看(云厂商是芯片厂商的客户),客户肯定不希望有五花八门的网络方案,这一点阿里云的专家也表达的非常清晰。云厂商的这个诉求其实也是比较容易理解的,网络不只是一个个芯片,实际上是一个复杂的分布式系统,需要配套的监控和运营系统,以及相应的运营团队。如果每个GPU厂商都采用自己定义的私有协议,那么云厂商就需要为每种芯片定制监管控系统,并且配置单独的运营团队。当然这些复杂度和成本最终一定会转嫁到更下游的消费者。
参考白盒交换机市场,所有交换芯片厂商都支持SONiC,那么下游的云厂商只需要适配SONiC就好了,回顾SONiC的历史,早期也有其他竞对方案,通过多年的持续迭代最终逐渐归一到SONiC,相信GPU互联标准这块也会有类似的过程,通过市场的选择,最终一定会出现一个事实标准,可能是UEC,也可能是其他,但是一定是一个开放的、大家可以共同参与的生态。
阿里云早在2019 年就提出了端网融合的可预期网络这个网络发展方向,这是基于阿里云从2016年就开始研发部署 RDMA 高性能网络,并在大规模部署实践中不断创新而提出来的理念。
随着AI大模型的火热,行业内对“Predictable” 这个词使用的频率已经越来越高,对于可预期网络的理解也越来越具像化了,这次圆桌论道,行业内的多位专家也是多次提及 Predictable, Predictable 可预期网络目的是规避网络“抖动”,这对于高并发,高带宽,同步通信等大模型训练的网络流量特质而言,收益是巨大的,因为提升大算力集群线性扩展度不仅仅需要绝对网络性能的提升,而且需要降低网络长尾延时,规避木桶短板,提供稳定的高性能,而这就是可预期网络(Predictable Network)的真正精髓所在。
-
AI
+关注
关注
87文章
30106浏览量
268399 -
阿里云
+关注
关注
3文章
940浏览量
42963 -
大模型
+关注
关注
2文章
2322浏览量
2479 -
AI大模型
+关注
关注
0文章
307浏览量
289
原文标题:华山论剑:AI 大模型时代的高性能网络如何演进?
文章出处:【微信号:SDNLAB,微信公众号:SDNLAB】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论