面向AI的服务器计算互连的创新探索

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
简介: 面向AI的服务器计算互连创新探索主要涵盖三个方向:Scale UP互连、AI高性能网卡及CIPU技术。Scale UP互连通过ALink系统实现极致性能,支持大规模模型训练,满足智算集群需求。AI高性能网卡针对大规模GPU通信和存储挑战,自研EIC网卡提供400G带宽和RDMA卸载加速,优化网络传输。CIPU作为云基础设施核心,支持虚拟化、存储与网络资源池化,提升资源利用率和稳定性,未来将扩展至2*800G带宽,全面覆盖阿里云业务需求。这些技术共同推动了AI计算的高效互联与性能突破。

一、面向AI的服务器计算互连的创新探索——Scale UP互连: ALink System

对于智算集群,互联是个非常大的命题。这部分主要是聚焦Scale Up,首先回顾一下云,因为云的基础设施演进,对于阿里云一直是需求驱动,所以看到过去在应用上的发展,以及芯片的技术趋势所带来的变化。


首先看模型发展,大模型已经不陌生,对于在过去的十多年间,甚至几十年间,人工智能领域一直是在波浪式的发展,在过去的十来年间,认为以神经网络驱动的模型发展非常迅速,由一开始的图像类引用的爆发,再到语言类的,最后到现在尤其是以大模型为代表的多模态的模型的发展。


大概在十年前,第一个爆火的模型是Alex net,当时把推理的精度相对于以往达到了非常高的水平,参数量是6000万参数,在哪个时代,互联已经是有价值的运题了,Alex net模型是分为两部分,两部分的原因是当时虽然没有各种复杂的互联架构,但是单芯片训练的水平不够,所以模型的作者拿了两个GPU来做,但又没有很好的分布式模型的训练,或分布式的框架来支持,把模型拆成横竖两半,可以看到算法模型的设计和硬件的结构是一起演进。


后来到图像类,到Alex net之后再到net,到了一定的水平之后,像GPT之类,GRN之后,扛起了语言类和多模态的大旗,可以看到在今年GPT 4里边,参数量已经达到了1点多个T,相对于原来6000万的参数量,已经增加了几千倍。但从参数量上某种程度也可以把它认为是算力的需求,这两个是绑定的,从芯片的性现状看,又面临着其他挑战,摩尔定律在过去时间是逐步的在失效,因为到了3nm以下工艺的时候,不无论是迭代的速度还是能拿到的收益都不明显。GPU的卡从过去的5年到10年之间,算力每一代还能保持不错的增长,即使用HBM容量,相对于从原来的GDR引进过来之后,单卡上面的显存发展的速度并不是特别快。


在这两种需求驱动对算力和显存的大规模的蓬勃发展的驱动,以及芯片遇到瓶颈下,必须用各种互联技术解决问题,在过去一段时间,像芯片内部的有ucie多带的互联,芯片外部主要是scale up互联也变得非常的重要。数据中心里计算集群的架构和算力的拓普,对于计算集群,有三张比较重要的网络,一是前端网络,前端网络里承载的流量是输入和输出,查询的输入输出结果的流量,另外还有checkpoint,以及存在云盘上存储相关的和外部通信的流量,它对于互联的需求除了高带宽之外,还需要和云网络有很深的绑定,因为它对接的是各种不同形态云的区域以及云盘的介质。


另外,在训练集群里面很有价值的scale out网络,scale out网络它所承载的目标是把整个训练集群横向扩展到数千甚至是数万,业界已经在往数十万规模去扩展,所扩展的是这样的目标。它上面跑的比较典型的流量像数据并行流水线并行相关的数据流量,比较典型的技术是RDMA技术了,上面会用采用外置板卡PCIe插卡的形式。


第三是变得越来越重要的互联,是scale up的互联,scale up互联它所承载的是因为现模型参数并行的维度越来越高之后,模型的切分方向上面也发生了变化,原来只有流水线等,现在可能张量并行,甚至专家并行都会变得越来越重要,这些并行对于流量、对于带宽的需求、延迟的需求以及它在设计上面特点是它相对于流水线并行更难去做隐藏,互联上对于性能的要求会变得非常高。


这是整个计算机群的大概系统架构。聚焦到scale up的互联上,为什么它的要求是极致的性能和极致的资源,首先不管是存储还是网络,最终发展的大集群都是分层的,存储大家感触非常深,随着云的发展,像云盘技术、本地盘技术和各种技术交织形成了完整的解决方案,但是扩展到数十万卡的集群时,如果只有一种互联拓扑来解决问题时,会把所有的挑战都放在拓扑上面,对于整个系统,它并不是成本和性能最优的解,第二个特点是场景的视角,AI的变成它整个的使用方式跟scale out有比较显著的区别,GPU它的体系结构跟通用计算也有着比较显著的区别,它是超多核的方案,对于通用计算,核数相对比较少,通常可以采用很多IO的形式来进行节点间互联,它的好处是当IO消耗时间比较长的时候,核可以通过操作系统的调度释放出来,干很多其他的事情。但对于GPU超重核的架构,这点是很难做到的,因为对于GPU靠编译器去预先编译过程,它和CPU上比较大的区别是CPU的调度是根据实时发生了什么让它操作系统去决定,但是GUP操纵核里边很难让GPU的自己来决定它swap出去之后在干什么事情。


另外,GPU里边因为算力相对于通用计算会高非常多倍,所以它整个的执行过程也非常快,中断式的切换是一种对性能非常脱力的行为。所以对于GPU,在scale up互联里面,业界采用的都是内存语义的芯片之间直接访问的形式,再回到芯片的视角,对性能的极致的要求,所以对于芯片需要用最极简的资源来实现它,把宝贵的IO资源都让给芯片上的算力,才能把它算力最大化。scale up它是直出的架构,它并不是用外界的插卡,因为可以看到后面介绍到整机柜方案里面带宽吞吐非常高,如果还用外接的卡去转,像PCIe转网络,无论是在公号还是各个维度都是不可实现的。


刚才讲到了它的重要性,对于scale up有哪些特别重要的关键技术,是从需求引导出来的。第一是原生内存语义的支持,第二是极致的带宽,极致的时延,最后是高可靠的链路。左下角列出了不同网络上承载的流量和它的特点。总的来说,在互联上,因为要达到推导出来的需求,所需要的是一套极简的协议,因为它的互联的场景,它的范围和scale out有比较显著的区别,它的节点数一个柜在几十个,通常不超过100个,顶多在几个柜之间做互联,它的规模基本上在几百量级,当前RDMA网络,面对这样一套技术是面临很多挑战,包括现在RDMA和之间的交互过程,如果用中断的模式,无论是在中断效率上,还是在实现效率上都不是很优,另外协议的面积还有整个协议站分层之后的开销都相对比较大,基于此,RDMA可能并不是对互联最合适和最典型的形态。


在业界看到有相关的协议标准推出,有UEC专注于scale out这样的协议,也有新的UIlink相关的联盟,所以逐步也在形成共识,因为解决的问题不同,需要不同的协议来面对。在过去几年,整个协议它是比较快的,scale up的生态是比较快速发展的,最开始有单机单卡的拓扑形式,之后发展到直连的形态,直连的形态通常是mash或者是像润环的拓扑,在一开始比较早期的时候,解决尤其是 or reduces算法效果是不错的,但在新的尤其是me很多方案里,对于其他的通信,它的通信效率并不是特别高,所以在18年左右整个协议整个生态,转向了Switch的架构的形态,但Switch在单机8卡的时代也停留了非常多的时间。


直到今年,NV在今年上半年也推出了整机柜方案GB200的方案,也是非常具有竞争力,整个协议发展下来,认为在24年已经全面面向了迈向了未来的整机柜的时代,所以现在为什么要Alink开放的生态标准,也是意识到互联尤其是在单位内有几千根线的互联,对于质量和极致的性能要求非常高,如果最后每一家都是封闭的标准,能达到的性能的极致程度,以及生产、设计、研发所均摊的成本都是非常高的,对于这种场景,非常适合用开放生态去推进。同时,也注意到今年有UI link这样相关的联盟,它是由MD一开始去贡献推动,现在除了MD,像英特尔博通很多公司都在里边,所以现在是基于UI link协议推进叫LS即是Alink system的开放标准。它分为几个层面,包括底层的协议层,中间的芯片层,再到设备层,以及上面的管控层几个维度,通过这四个维度打造全面的scale up开放生态。


上个月Alink在ODC上已经进行了相关的发布,可以看到有非常多的从GPU Switch的设备厂商,到部件的厂商再到IP厂商,都已经加入到开放生态当中。从底层的协议来看,ALS协议主要分为两大部分,是杠地的数据面这部分,数据面这一部分将原生的采用支持UI link协议方案。UI link是底下的互联协议,认为用了它之后,可以原生的支持所在场景里面需要的内存余的基础,因为原生的支持意味着它在使用协议从底层到上层的设计上面都能够满足场景的需求,通过这样一套互联标准,可以在整机柜里拿到达到数十TB的显存,最大规模的互联,同时在组网拓扑上也可以支持单层和多层的组网拓扑。


除了数据面之外,还有非常重要的点是管控,管控对于云也是非常重要的一环,因为在互联上面,当有统一的管控标准时,会对上面资源的配置、资源的申请释放、资源的诊断、故障的处理,都有一套标准的流程,这是除了数据面之外的部分,Alink system理念它是现在阿里云在推动的开放的生态标准。刚才介绍了协议之外,整个iOS系统是可以通过三个维度全方面的来支持ALS的场景,一是特性的维度,特性的维度是内存与组的支持。


除此之外,在协议的设计上也有相关的优化,在整个协议上面会采用点对点的同传的机制,而不是采用传统网络里面的端走端的同传方案,除此之外,还有流控,可能是credit base的流控,这些技术都是为了能够在各个层面达到极简的设计,并且能够用尽量少的资源实现最高的性能,最后是组网的维度,组网的维度对于整个AI的场景,会支持到可能在几百到1000最大规模的组网,但可能在实际的工程上,因为组网scale up的要求很高,连接的失效率是非常重要的因素,所以基本上在组网里面,大家会优先采用基于同线的组网方案,如果采用光的互联可能会有几个问题。


第一是光的能效成本非常高,对于光的连接,一对Switch可能需要几瓦的驱动能力,但对于同线的互联可能只在零点几瓦,功耗对于等级柜差非常多。


第二是光的失效率也非常高,对于并行计算,一个节点坏了,要么是回退checkpoint,要么是采用中断恢复的机制,成本都是非常高的,所以在拓扑下面,会支持基于同线的各种组网的模式。


图是概念样机的介绍,样机在今年云区的会场展馆里面也会有,对于集中式的系统,除了把互联设计好之外,供电、散热和运维上都要有一套标准化的处理流程,基本上相对于原来的方案,对于整机柜的方案是需要独立的交换节点的板卡插在外面,计算板卡会有AI的计算节点,因为cable的长度通常在场景下可能在1米到2米左右,所以会把交换节点放在整个机柜的中间,上下会配上供电和散热的单元,对于整机柜单元,相对于原来传统的机柜,它在供电上也需要独特的设计,因为原来的通用计算整机柜一台机器可能1000瓦,一柜可能一两万瓦,但是对于这种方案,基本上一柜要达到10万瓦的功耗的标准,中间也展示了样卡的概念图。这里面计算节点上的设计相对于原来也会有区别,原来可能是单机8卡的场景里,对于CPU带GPU数目会比较多,但是对于整机柜的方案里面,可能一张卡上面不会再去做8卡,会把它的节点做的更少,可能是2卡或者4卡处理的范围。总结一下,在scale up里面,推导的ALS会成为在scale up行列里非常重要的一股力量,因为它在原生的协议的设计上,有如下几个比较重要的特点,因此在生态上面也需要有全方位的生态位的支持,这点在联盟里参加的公司也可以看得出来,大家在每个生态位上都有很强的设计,通过生态的行业的发展以及协议的设计,会成为健康有序互相促进的作用,共同支持阿里云后面scale up技术的发展。

 

二、面向AI的服务器计算互连的创新探索——AI高性能网卡创新与实践

分享在面向AI的高性能网卡场景,在阿里云整个AI的产品,包括创新和实践,会结合实际的业务场景,实际的需求。接下来主要从三个方面来介绍,第一部分介绍在AI高性能场景下,AI业务对网卡带来的挑战。第二方面,阿里云在AI场景做了创新和实践的技术上的如创新、需求,包括落地,最后从我们角度来看,接下来可能面临的在云场景在AI场景,它会带来的新的问题和挑战。


1.AI对高性能网卡的挑战

基于阿里云的磐久服务器,整个网卡在里面的架构,包括它的定位,阿里云的磐久服务器,在展馆二号厅边也有展示,AI的场景,它的网卡的应用和传统的通用计算差别是非常大的。在AI场景,有非常强烈的scale out的需求,同时又有云的基础的通算的存管需求,在H800或者是其他GPU服务器上,可能采用机头机尾分离,CPU通用计算的节点和GPU的扩展节点是分离的服务器架构。


在的网卡上,负责DPC存储以及的管控的这一部分的网络网卡,它是部署在CPU的节点上面,其他像scale out智能网卡,它不部署在机尾,它是跟GPU有一定的亲合性的关系,它通过pcs Switch做映射,或者GDR的高速传输之类,从上面来看,在整个AI场景,因为网卡本身是网络的端测的承载,网卡现在它的角色在整个服务器里面已经分了两个角色。


第二个是不同的智能网卡,它跟GPU并不是随机组合的关系,它是有拓扑的感知和绑定的亲和关系。在AI场景,智能网卡首先带来的挑战是从线上的实际网络统计、观测发现,在AI整个集群里,最明显的是scale out的GPU通信网络,它的整个网卡吞吐是非常高的,它的分值接近到了的网卡的上限,是接近400Gb的吞吐,在通用计算场景是很难接到,通用计算大部分的DPC的网络,可能是几十Gb吞吐足以满足的客户的需求。另外在AI场景,它存在着大量的周期性高并发和吞吐,随着整个GPU通信并行计算的通信,包括整个TP的同步,它整个吞吐量可能会非常高,短时间它的持续的时间并不长。


另外包括RDMA协议的强依赖,包括包的特征,都是当前AI跟通用计算很大的差别,这些可能接下来会影响到的整个产品在智能网卡软硬件结合的方向,包括可能接下来要解决的问题。第二个问题是整个GPU通信,网卡在整个AI的集群,它的数量包括它的规模比原来通用计算大大增加,像1000卡的GPU训练,网卡只会比GPU多,不会比GPU少,单个任务的同步训练,对于智能网卡,它也存在着很多的挑战,第一是稳定性,是在像Meta之前的论文里也有统计,网卡在目前是AI自算场景,它的故障率可能是百位百的个位数的级别,交换机可能更高,像它拉玛405B模型,它可能有几十次的故障发生,不管是网络还是网卡端测的设计的时候,现在面临最大的是稳定性是要让业务尽可能少中断训练,可以提升的GPU包括提升整个生产效率。


对于网卡来讲,通过方式如何解决交换机,包括设置网络上面的RDM UI的问题。最后AI也是云的基础资源,在整个管理的时候,也有DPU的依赖,因为DPU本身目前也是整个云上,不管是AI还是通用计算,像裸金属实例,甚至硬件卸载加速的基本承载,在AI领域,相比通用计算在DPU上面有新的需求,首先DPU在整个AI里面走的是南北网络,它承载的是整个VPC存储和管控的网络接入,在这里,像AI的高性能存储,阿里的CPFS,用的是DPU的技术来做它的硬件加速或者卸载,同时整个客户在数据拉取的时候,可能从的数据仓库OSS拉取的时候,也要走DPU通路。因为AI的整个数据量会比较大,原始数据的拉取,包括频繁的存储需求,整个面临的很多挑战,通用计算也不一样,通用计算可能很多时候对于延时更敏感,对于小的包快存储可能会更敏感,因为在线的业务,像数据库。虽然训练是个离线任务,但是在这里整个前端的网络DPU这一块,它的需求比通用计算要更多。看到典型的AI对整个智能网卡或者DPU带来的挑战和领域。


2.AI高性能网卡的创新实践

接下来大概介绍一下阿里在这方面创新和实践。第一是自研的高性能网卡EIC,从大概是五六年以前开始在自研网卡一直在做投入,最早是因为RDMA它的特性的问题,为了解决存储网络,甚至是长尾的问题,所以通过自研RDMA来做高性能的网卡。当然是在这种情况下,做数据的压缩,随着整个迭代,FEIC2.0这一代,发展到200G,在这里面做了非常多QS,在整个云上QS相对比较敏感的东西,因为不同的租户不同的网络,在这里面带来的对于整个服务质量的关注是非常严格的。


接下来EIC1.0,现在已经在阿里云规模化上线的这样的高性能网卡,网卡现在的带宽是400G,自研了RDMA,通过硬件卸载加速的方式,实现整个RDMA的高端图演示,另外在这里面结合servilessK8S也做了如队列虚拟化来加速容器,启动,包括可能其他的拉起、性能方面的问题。EIC高性能自研网卡在整个架构上面,核心是对RDMA卸载加速,这里面包括控制算法,结合网络团队在这里面的像阿里自研自定义的HPCC,还有多路径的特性,还有全链路Qos,这些是从目前各大厂都有在做自研,拿RDMA相关的突破,阿里在这一块也是做了非常多年,目前也随着不管是存储集群还是AI,都已经实现了规模化的上线,配合整个网络,在端到端实现了网络的优化。


这是简单的测试对比,对比了业内的比较领先的商卡在做128g的情况下做场景测试。从AI目前来看,对于大包的整个带宽会更敏感,对延时相对没有敏感。在结合通信的承载情况下,带宽包括的整个长尾,包括拥塞,从实际的落地来看,这些方面都是对整个产品比较重要的点。智能网卡在scale out这一块,主要的需求包括的自研的落地,在DPU这一块,AI相比于通用计算,有很大的特征尤其在存储这一块,对于文件系统的依赖,在原来通用计算场景可能对快存储的需求会更强,对于文件分布式或并行的文件系统的需求,原来可能更多集合在数据的批处理,如连线的阿里的ODPS,在AI场景高性能的文件系统,不管是checkpoint的速度,还是对数据的持久化以及高性能并行都非常重要。


目前通过软硬件的结合,通过DPU的硬件的能力,结合软件的优化,目前CPFS高性能的文件存储系统,在AI场景吞吐已经达到40GB,化验成b,应该是300Gb以上,在这么重的吞吐情况下,如何考虑到其他的流量,业务的稳定性会有非常多的调整。另外也在做探索,如果做弧仓一体的可能会比较了解,像Snowflake或者datebreak,一直在做弧仓一体,包括亚马逊非常热衷于做S3存储一切,AI大部分的原始数据,以OSS它的海量低成本的数据,包括它的存储为主,在DPU上直接把对象存储,通过的DPU加速,与GPU做快速的数据直传,在这种技术情况下,目前业内也是最早来做这块相位创新和落地,在整个GPU和整个GPU之间做快速的数据直传,包括通信。


网络优化,在VPC或虚拟网络,相对来讲技术是比较成熟的,大家可以看到很多商业的产品,或者是大厂的发布上对于虚拟网络的转发的性能指标,甚至可能其他的筛选,或者是其他的flow的特性描述,整个网卡在AI上面带宽是会更高,在局部的客户,对于整个虚拟网络的需求非常大,因为他会构建自己的整个虚拟网络之上的存储cash服务,在这种情况下,基本上所有的智能网卡可能都支持像硬件转发,硬件转发情况下,一旦命中到不能解决的虚拟的流,包括转发,它会有比较大的GAP,因为网卡目前的整个性能,包括整个吞吐的迭代发展是远超CPU的,DPU上面的CPU能力,不管每一代CPU怎么叠加,整个增长很难跟得上,整个网络带宽每两年翻一倍这样的节奏,所以怎么样解决硬件卸载情况下,在不可知或存在的未定义的流上面,它的软转被客户带来衰减问题上面,还有很多的优化,像AI这块,目前通过剧增jumbo frame优化也能够在单核上,整个转发比原来达到一倍以上的收益,相对来讲,在AI场景中,jumbo frame它带来小包的延时相关的问题,在AI很多场景,从收益上面是可以有一定的妥协。


3.AI高性能网卡的未来思考

以上是实践的相关方向或点,从整个智能网卡未来的思考上。不管是DPU还是智能网卡,随着AI整个迭代的兴起,或巨大的需求推动,它接下来可能会有非常多的发展,尤其是DPU, 甚至是智能网卡的发展,所以接下来从看到的点来进行阐述,但并不代表一定适合每一个AI的场景。第一是因为接下来智能网卡很快会进入1.6T时代,市面上已经有800G网卡。


可能过3年1.6T网卡会在市面上出现,在这么高的吞吐下面,怎么去解决现在在DPU里面或者在智能网卡里面做转发能力的极限性能提升,或者极限的性能优化,存在比较大挑战的问题,从目前400G网卡DPU或者DPU上看,整个要把所有的网卡吞吐甚至性能打出来,已经是有非常多的挑战。可能硬件卸载相对来讲速度很快,但是它是相对比较固定的,它怎么解决未来多变,不管是上面的产品需求,还是业务的特征来解决问题,接下来会在可编程转发去做探索,像在文件系统整个加速上讲,像做到40GB,在更高的吞吐翻四倍的情况下,要把吞吐跑上去,还要做非常多的加速需求。


从目前来看,甚至文件相关的加速和转发,并没有看到特别好的应急加速的方案,因为它相对更复杂,所以它很多时候它依赖于通用CPU的处理,它的协议或者是新一代的设计,也是比较关注的点。另外随着整个其他的特殊需求,安全或者数据加密甚至压缩这些需求的推进,怎么去协调好这么多的业务流或者数据的模块,在整个智能网卡里运转是需要重点考虑的问题,从跑banchmark角度,单独把网络或存储跑道分值并不难,困难在于多种业务流的结合下,相互之间达到各个产品的预期,这里面的QS或者SLV,甚至相互之间的隔离,这些可能是遇到最棘手的问题。训练和推理,训练可能是相对关注比较多的场景,随着整个模型到AI往后的发展,它的整个需求会越来越重。


在这种情况下,为了提升资源的利用率,能够实现资源的有效调度,或者快速降低TCU快速的复用,所以在训练和推理需求可能会在接下来在的资源上做整合,在这种情况下,现在训练的整个服务器架构,它的网卡,包括他的前后端网络的分离,在推理场景会遇到非常多的问题,目前训练的网卡的设计和架构,并不适特别适合推理,接下来随着网卡的迭代,包括整个服务器的迭代,在训推一体的情况下,要重新构建自己的整个网卡相关的架构,另外在这种情况下怎么去做好,如不管是训练还是推理,在同服务器架构或者网卡下,怎么解决相对应的多租户的隔离的问题,或者RD MA的极致,因为它的延时、不同的业务感知不一样,或者其他的稳定性,或者是互联的问题,这些问题是接下来重点要关注的问题。

 

三、面向AI的服务器计算互连的创新探索

从芯片工程师的角度跟大家分享CIPU技术和自己的感悟。可能很多朋友已经知道CIPU的概念和对阿里云的价值,再简单互述一下,对于产品,实际上是在经营资源,把资源分为成物理资源,逻辑资源和客户能用到的可见资源。物理资源会有以X86RAM架构的CPU和当前为主流的CPU,以及作为辅助sick构成的物理的计算资源,背后的存储机群、本地存储构成物理的存储资源,以及物理网络构成的网络资源。物理资源通过CIPU以及运行在其上面的飞天系统,把它虚拟化成逻辑的池化资源,虚拟的计算池,虚拟的网络资源池和存储资源池,这些逻辑上的资源,再通过的管控调度系统,构建出弹性的各种计算机群、计算资源和客户使用。所以CIPU是处于物理资源和逻辑资源的桥梁,是产品非常关键的基础架构的一部分。


简单回顾CIPU的发展历程,从2017年云栖大会发布,首发基于硬件虚拟化技术MOC1.0的产品,今天发布CIPU2.0产品,经历了五代的演进。这五代演进驱动力有两点,第一点是性能,性能的标志性是带宽,每一代产品做到带宽翻倍同时处理性能一般会做到1.5倍的提升,随着处理性能的提升和带宽提升,也带来整个芯片架构的引进,性能提升,会做到软硬件切割呈新分工,把以前软化处理的逐渐的硬化。另外驱动力是云计算技术高度发展,以及整个的技术趋势的发展,驱动在做配线的增强,在2017年做首发硬件虚拟化技术时,实际上推出了业界第一个弹性路机手产品,弹性路机手支持了整个阿里集团的上云,后来看到了技术趋势是CPU服务器的高密化容器化,这些东西会推动去做更大规格更多资源的初始化和拉起销毁的能力。


AI它的底座技术或者是基础技术,看到的是RDMA为核心的基础技术,这是针对CIPU2.0所能支撑的东西,未来下一代继续按照逻辑去做,把CIPU 3.0规划也在日程之上,未来带宽会提到2*200,2*400和2*800G力度,同时特性驱动策会全场景的覆盖阿里云的业务需求。CIPU2.0的内部的东西,站在芯片的角度去讲,一是虚拟化,虚拟化技术是最早开始做起的,今年以高密为目的,支持500以上VM,或者几千个容器,同时快速的资源拉起消费能力,做的业务的处理引擎上有两大块,是存储和网络。存储有多种多样的形式,有传统的基于whatblock MME的快存储,也有基于文件系统的DFS,自研的磐古的技入FS之类,底下采用了统一的技术架构,即自研的存储访问的技术架构,它能够支撑到600万的IOPS基地的访问延迟仪器的延迟抖动,同时比较有特色的问题,本地存储也是在CIPU架构加速实现,它的本地存储实现了更高的性能以及更低的延迟,更廉价的成本,网络方面是RDMA基于物理网络,基于网络实现统一的架构,在上面还有安全性加强,性能和全面的数据的加密等等。


做CIPU也有8年了,为什么要在阿里云的云厂上做芯片或者系统,一直是秉承安全、稳定、性能、成本八个字去定义芯片,八个字每个人的理解是不一样的,性能有宏观上的benchmark性能,一定会从端端端的角度看性能,而不是benchmark,会看到有一半以上的客户会部署像是MYSQL这样的应用,这些应用如PPS宏光的指标达到一定高度以后,影响现在的是微观的指标如突发,设备和OS之间的配合,包括稳网络的稳定性,这些会真正的影响性能,所以会把大量的资源和精力做到改善微观的行为上,让性能有本质的提升,而不会为了调标,如1亿的PPS是不会把精力放在这上面。有人认为性能和成本是矛盾的,把性能提上去一定要加成本,实际上不是这样,是会站在整个平台的角度看待成本和性能的平衡。


举个例子,实际上展示的性能是客户能够拿到的性能,而不是去巡讲的性能,所以会看到个人场景,网络增强的场景,存储增加场景,或者高性能的场景,它实际上对内部资源的使用是不太一样,所以要做到芯片里面的各种资源,如队列等做到人口的可分配可调度,同时外挂的CPU,也不是和越多越好,内存越大越好,要通过芯片辅助让它能够做到弹性使用,内存和弹性使用,从整个的角度去做到性能和成本的统一,而不是矛盾的东西。


在云厂商做芯片,云厂商最大的资产是因为有很多既等软件又等客户应用,还等硬件的一批工程师,所以芯片的架构团队,很多同学是来自于几个大的云产品的资身软件架构师,在一起去定义软硬件的接口,定义软硬件分工,去定义的时候不是满足今天的需求,要看未来会变成什么样子。如RDMA的设计,RDNA做的比较早,最早做分析的时候,在一起讨论,设备,可靠传输,或者包括网络转发,这些东西是需要硬化的,但是像流控,多逻件算法,包括异常处理,要把它留给软件,通过这些东西,最早开始定义RDMA的时候,AI还没有这么火,也没碰到这么多问题,当做成以后,会发现架构很容易解决问题,把带宽拿到节点100% 。


安全和稳定是云的基础。因为今天的发展趋势高密化。CIPU作为单顶,一定会有故障爆障率的问题,所以通过芯片设计,只要是硬件,它一定会有故障,通过检测的故障,发现能够安全快速的迁移,是有能力让让VM快速迁走,减少损失。这是CIPU芯片的架构图,芯片架构图都很像,但是差异在细节上,在每个模块里面都会有体现,软硬件的定义,或者体现的性能,data path的设计。有几个部分,外部接口、的设备层、data path层、协议处理层,以及网络转化成外部的网络表象成熟这些类型。


作为ais产品,或站在CIPU的角度,一直以来追求用统一的底层架构支持各种各样的云产品,探索很早开始,在2017年的时候,有HPC高性能处理的场景,它的典型特征是需要构成小集群,集群之间要通过RDMA连接,当时统一价格的做法是把CIPU引进去,通过CIPU让集群接入到云管理体系,通过高性能的存储和网络的云发能力访问云服务,整个很快把所有的云体系站技术利用起来,达到了高效部署集群的能力,今天刚好切合到的AI计算,它的网络架构跟以前部署的非常像,所以今天在CIPU访问云的能力做到,未来CIPU要把整个的技术架构再实现统一,前后端前后的网络基础,前端是通讯计算RDMA能力要与后端RDMA在技术架构,技术内核上实现统一的RDMA架构,前后端的网络物理形态可能会有不同,但是技术架构一定要做到完全的统一。


RDMA做的比较早,通过软件定义芯片,通过业务的演进理解,发现很容易解决今天在AI上碰到的大象流,in cast,业务干扰问题。在当初定义的时候,从辅射的理念认为一定要做到数控分离,一定要做到软件能够定义芯片,要解决掉数控分离是认为数据移动它的代价挺大,灵活性交给软件。在设计上很快做到带宽去打码,但实际上是做到在ECS通用网络架构下,把带宽打到接近100%的能力。在接受方向把所谓的数控分离,让协议或者报文或消息能够自带控制信息,报文进来以后,首先把它存到内部的缓存,缓存不大,大了代价太大。放到里面只是要短暂的缓存,处理协议RDMA协议,处理完以后,快速的把数据提交到GPU大缓存里面,不会把数据存在芯片里面。


可以看到像in cast,它必然会带来数据的乱序,通过可编程的软件部分对提交的顺序进行排序,使得最终的结果正确,叫做DDM。在发生方向,先构造协议,计算它的流控窗口,做好这些事情以后,再从大的内存里面如显存把数据挖出来,数据只是在芯品里面做短暂的停留后再发出去,发送环境比较复杂,再有软件的窗口计算软件的流控,再加上硬件的两次的cos计算,cos计算平滑流量,让发生流量比较平滑,减少接收端的压力,做到带宽打上去。在AI时代,对存储的性能要求或者访问能力要大幅提升,通讯计算对存储的访问带宽要求不高,现在CIPU只对存储可以做到限速访问,二层200G,400G带宽可以做到双向400G的能力,同时,站在芯片设计的角度或者价格的角度,可以给客户另外技术选择,甚至可以自己去构造它的存储集群,购买ECS产品,构成存储技术群,通过OA类的RDM能力访问他的存储能力,这是技术选择,希望是从底层上层创新做更多的选择。最后,集群的高可用,在做CIPU的第一天,把云的能力,可迁移,可升级,这是最基本的能力设计,基于CIPU的集群架构,它是完全具备很好的迁移能力,因为它的状态是存在的云盘里,计算集群也是自己不带状态。


另外IP地址可迁移,可以迁到任何地方,CIPU的软件系统是很容易升级,像配型、修bug都是很容易的,芯片上也要有所支持是,芯片上所有的硬件资源,队列,缓存,状态都是可以动态分配的,到任何地方都能够这些东西暴露给广告系统后,可以分配到任何地方,状态可以迁移,把内部的状态迁过去,还能正常工作,更上层的基于筛选能力也是可迁移的。

相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
相关文章
|
22天前
|
存储 人工智能 自然语言处理
ChatMCP:基于 MCP 协议开发的 AI 聊天客户端,支持多语言和自动化安装 MCP 服务器
ChatMCP 是一款基于模型上下文协议(MCP)的 AI 聊天客户端,支持多语言和自动化安装。它能够与多种大型语言模型(LLM)如 OpenAI、Claude 和 OLLama 等进行交互,具备自动化安装 MCP 服务器、SSE 传输支持、自动选择服务器、聊天记录管理等功能。
133 15
ChatMCP:基于 MCP 协议开发的 AI 聊天客户端,支持多语言和自动化安装 MCP 服务器
|
23天前
|
人工智能 缓存 并行计算
转载:【AI系统】CPU 计算本质
本文深入探讨了CPU计算性能,分析了算力敏感度及技术趋势对CPU性能的影响。文章通过具体数据和实例,讲解了CPU算力的计算方法、算力与数据加载之间的平衡,以及如何通过算力敏感度分析优化计算系统性能。同时,文章还考察了服务器、GPU和超级计算机等平台的性能发展,揭示了这些变化如何塑造我们对CPU性能的理解和期待。
转载:【AI系统】CPU 计算本质
|
23天前
|
机器学习/深度学习 存储 人工智能
转载:【AI系统】计算之比特位宽
本文详细介绍了深度学习中模型量化操作及其重要性,重点探讨了比特位宽的概念,包括整数和浮点数的表示方法。文章还分析了不同数据类型(如FP32、FP16、BF16、FP8等)在AI模型中的应用,特别是FP8数据类型在提升计算性能和降低内存占用方面的优势。最后,文章讨论了降低比特位宽对AI芯片性能的影响,强调了在不同应用场景中选择合适数据类型的重要性。
转载:【AI系统】计算之比特位宽
|
2天前
|
存储 人工智能 运维
面向AI的服务器计算软硬件架构实践和创新
阿里云在新一代通用计算服务器设计中,针对处理器核心数迅速增长(2024年超100核)、超多核心带来的业务和硬件挑战、网络IO与CPU性能增速不匹配、服务器物理机型复杂等问题,推出了磐久F系列通用计算服务器。该系列服务器采用单路设计减少爆炸半径,优化散热支持600瓦TDP,并实现CIPU节点比例灵活配比及部件模块化可插拔设计,提升运维效率和客户响应速度。此外,还介绍了面向AI的服务器架构挑战与软硬件结合创新,包括内存墙问题、板级工程能力挑战以及AI Infra 2.0服务器的开放架构特点。最后,探讨了大模型高效推理中的显存优化和量化压缩技术,旨在降低部署成本并提高系统效率。
|
2天前
|
人工智能 弹性计算 运维
ECS控制台,AI助手与极简管控体验
本文介绍了ECS控制台的演进及最新AI工具功能。控制台作为运维平台,需兼顾用户体验、可靠性和安全性。针对不同用户(个人开发者、企业级用户、资源管理员和架构师),控制台提供了定制化AI助手,涵盖售前选型、售中购买、售后运维等全链路支持。AI助手可智能分析用户需求,推荐合适规格,并提供实例诊断、命令解释等功能,简化操作流程。此外,还推出了简洁版控制台,优化了小资源量用户的使用体验,减少复杂度,提升效率。未来,控制台将朝着更智能、个性化的chat ops方向发展。
|
26天前
|
机器学习/深度学习 人工智能 PyTorch
【AI系统】计算图原理
本文介绍了AI框架中使用计算图来抽象神经网络计算的必要性和优势,探讨了计算图的基本构成,包括标量、向量、矩阵、张量等数据结构及其操作,并详细解释了计算图如何帮助解决AI工程化中的挑战。此外,文章还通过PyTorch实例展示了动态计算图的特点和实现方法,包括节点(张量或函数)和边(依赖关系)的定义,以及如何通过自定义Function实现正向和反向传播逻辑。
69 7
【AI系统】计算图原理
|
26天前
|
机器学习/深度学习 人工智能 前端开发
【AI系统】计算图的控制流实现
计算图作为有向无环图(DAG),能够抽象神经网络模型,但在编程中遇到控制流语句(如if、else、while、for)时,如何表示成为难题。引入控制流后,开发者可构建更复杂的模型结构,但部署含控制流的模型至不支持Python的设备上较为困难。目前,PyTorch仅支持Python控制流,而TensorFlow通过引入控制流原语来解决此问题。计算图的动态与静态实现各有优劣,动态图易于调试,静态图利于优化。
44 5
【AI系统】计算图的控制流实现
|
26天前
|
机器学习/深度学习 存储 人工智能
【AI系统】计算图与自动微分
自动求导利用链式法则计算雅可比矩阵,从结果节点逆向追溯计算路径,适用于神经网络训练中损失值对网络参数的梯度计算。AI框架中,自动微分与反向传播紧密相连,通过构建计算图实现高效梯度计算,支持动态和静态计算图两种模式。动态图如PyTorch,适合灵活调试;静态图如TensorFlow,利于性能优化。
60 6
【AI系统】计算图与自动微分
|
26天前
|
机器学习/深度学习 人工智能 算法
【AI系统】计算图挑战与未来
当前主流AI框架采用计算图抽象神经网络计算,以张量和算子为核心元素,有效表达模型计算逻辑。计算图不仅简化数据流动,支持内存优化和算子调度,还促进了自动微分功能的实现,区分静态图和动态图两种形式。未来,计算图将在图神经网络、大数据融合、推理部署及科学计算等领域持续演进,适应更复杂的计算需求。
56 5
【AI系统】计算图挑战与未来
|
26天前
|
人工智能 调度 算法框架/工具
【AI系统】计算图的调度与执行
深度学习训练过程涉及前向计算、计算损失及更新权重参数。AI框架通过计算图统一表示训练过程,算子作为计算图的节点,由后端硬件高效执行。计算图调度包括算子间的调度、并发调度和异构调度,确保计算资源的有效利用。图执行模式分为单算子执行、整图下沉执行和图切分多设备执行,适应不同场景需求。以PyTorch为例,其算子执行通过两次调度选择合适的Kernel进行张量操作,并支持自动求导。
51 5