再谈云计算范式的变革

上海的流控

刚接到一个通知,被隔离天数似乎成了一个滑动窗口了

再谈云计算范式的变革

渣居然此刻在想,是不是以后要改成AIMD一类的拥塞控制呢?例如2个阳封24小时,3个36小时…反正最大也就14天,然后每少一个隔离等待时间减半什么的?顺便此处又吐槽一个RoCE那种只会用PFC全部封城的策略….毕竟一个城市还是要一些基本的流动性的,按街道这种网格化管理真的蛮细致的,但愿疫情早些过去吧…想起以前做复杂网络的时候玩过一段时间SIR模型,当Omicron的R0接近8,换到当年绝对是一个难以想象的值。

回到正题,渣以前已经谈过很多次计算范式的变革了,最近看了Tenstorrent的一些软硬件架构和未来的计划,似乎找到知音了,想再说说这个话题

>“流动”基础设施及云计算新范式<

Ch0. 计算范式的变革

知乎上有一个问题为什么有些学数学的看不惯甚至鄙视 Deep Learning?[1] 其中有段话:

@黑暗里谁还不睡:现在AI领域的现状就是这样,数学上的high level intuition和ml theory的一堆assumption是割裂的,based on ml theory的formulation和跑出来的玄学实验结果又是割裂的,在苛刻条件下的实验结果和现实中的task上的performance还是割裂的,仅有的几个performance比较好的任务和工业界要求的变现能力强的落地场景仍旧是割裂的,但凡有人可以补上这几环中的任何一环足以拯救这个行业,但现在来看,真的很难乐观

这些割裂的现状也一直不停的在过去几年折磨我自己,当然这个话题不光是简单的狭义的讲DL,更多是谈ML本身,记得很多年前给某司的同学们讲ML的时候有这样一页ppt:

再谈云计算范式的变革

而如今可能只是在机器辅助决策和可视化的层面上,而过去很多年渣一直盯着Model Driven Operation和Predictive Operation上在看待很多问题,也就是当年做的Nimble Engine的项目,当然还有一些小伙伴坦诚地跟渣讲:“你涉猎太广了,而且没有focus,一会儿流计算、一会儿AI、一会儿云原生、一会儿RTC、一会儿又DPU搞硬件”,而过了几年后,你会渐渐的发现nimble+ruta+netDAM是凑齐这个局的三颗看似毫无关联的龙珠罢了,这几天刚好看到Linkedin上Tenstorrent的一个视频[2],似乎现在能看懂这些内容的大概H厂有几位大神,A厂应该有几个,T厂可能有一两个,其它没有接触不太清楚…

接下来把这个视频的一些内容和nimble+ruta+netDAM凑起来讲,大家估计就明白了,当然从nimble到ruta再到netDAM甚至到10年前做Lisp Layer2,关于创新的东西以后有空再单独谈。

正如我去年在下文中谈到的

>云网融合的探索<

冯诺依曼结构的本质在于当时的I/O决定了其数据处理的方式:

而在而在云时代,实际上大量的标量交互已经发生在了前端终端。我们可以很容易的用低代码的方式构建表格,让最终用户填写数据。云端的交互更多的变成了一种API结构体数据的处理, 大量的计算伴随着数据流动发生。这就是流式计算的处理方式:

而另一个就是计算本身以某一段程序存在,或者低代码的方式构建在Serverless的基础上。那么如何围绕着这样的架构构建指令集呢?当时写过一个图:

以数据计算为中心的指令集体系结构和冯诺依曼结构的最大区别就是输入输出设备本身由标量变为了结构体,但是相对于一些矢量处理架构,您可以注意到结构体本身的每个字段长度不等的。而这些操作的主要目的就是将运算中的跟数据解析封装批量写回等操作的。对应到现在的结构就是SideCar和Serverless计算本身在体系结构上的紧耦合。

当你看到下面这个图是否会觉得差不多就是一样的东西呢?

当然不全一样,因为在设计NetDAM的时候考虑的是一个更加泛化的处理方式,对于Tenstorrent而言矩阵乘法和加法本身就构成一个环,而正如渣前面讲的,通用计算可能更要考虑对普通结构体的代数约束,因此有两种选择,要么是对结构体的操作构成交换群,并采用Checkpoint的方式实现逆元,要么就是构成半格,采用幂等的方式处理。接下来以tenstorrent video的顺序一边写一边展开吧

Ch1. Software 2.0

这是tenstorrent一开始讲的场景:

但是Software2.0不会只存在神经网络和Tensor计算,渣更喜欢以下面的ppt讲述这个问题,因为本质上你还要在这里复用混合一些冯机的生态和代码

这一点在TT后续的ppt中也讲到了

本质上是如何把模型看成程序同时又和已有的程序融合,说到这里是不是想到Spark ML或者Flink+Alink了?所以渣在设计2018年Nimble的时候就考虑到这问题了,也就是说Nimble中是一个hashmap或者array构成的DataStream结构体

然后针对它提供了一些ML推理的算子,支持自定义map函数或者各种推理引擎(xgboost/LightGBM/scikit-learn/tensorflow)

当然也会像Flink那样实现window function以及其它一些路由、通信、数据库功能,乃至针对前端的GraphQL输出支持:

而对于TT提到的这种异构计算,事实上Nimble几年前就实现了,从边缘网关直连摄像头,然后推理转换为数据库

所以我前面提到在真正的Software2.0的计算范式中数据并不是tensor,而同时针对数据流随时间的变化,NOC需要大量的动态路由的支持。

当然现阶段呢,Tenstorrent还是考虑的是简单的tensor +torrent结构,因为创业公司嘛,主要需要快速落地。

而当前大多数AI相关的DSA而言都是只需要实现矩阵计算和一些特殊的函数就行了:

当然TT这些老手用RTC的RISC-V核肯定不简单,因为他们看到了更多可编程的需求

此处只是举了一个例子,而这些也是今天nvidia GPU比较头疼的问题,因为计算范式变了。

而另一个问题指向了云和边缘协同:

即一个神经网络模型在云端可能会按照模型拆分,但是也有可能端和云协同的做法,所以渣当时的做法是同一套框架兼容边缘和云:

所以logo用了一个章鱼,而思科自己又有大量的IOT边缘节点,乃至路由器、交换机、AP上都可以提供容器化的计算资源。但是谈到端网融合的问题,又涉及到SDWAN和一些隐私计算的处理,隐私计算例如FL或者FHC效率还有一些问题,所以渣先选择了在SDWAN上构架加密隧道的处理方式。按照某司一个很资深的产品经理的说法,这个时候SDWAN应该使用OBI-WAN(Out-of-band intelligence WAN)

因为思科自己先在拿Hub当控制器搞了IWAN,后来控制器是分离了,但是控制信令又在overlay的隧道里,于是经常产生先有鸡先有蛋的问题。最终为了解决这个问题出现了Ruta,并且采用云原生的全分布式方式组网,把边缘的计算节点连起来。

而这个问题和后面的tenstorrent NOC也有关系, 毕竟就是涉及到如何将多个PU连通并避免拥塞的问题,毕竟要scale到整个DC

未来的趋势

TT总结了Dynamic Sparsity、Conditional Execution、Dynamic Routing这三个趋势都是值得国内DPU和GPU厂商们好好思考的。

首先是稀疏执行的问题,如果在传输和计算的过程中能够有指令集删除零元,通信量和计算量都会小很多。

TT的做法是采用Mini-Tensor的处理方式,一方面可以利用多个小核隐藏延迟,另一方面可以智能bypass zero-tensor

另一个就是讲MoE(The Sparsely-Gated Mixture-of-Experts Layer)的问题

结论很有趣,也就是说需要更加智能的网络并和计算资源紧耦合(NetDAM+Ruta就在干这事)

另一方面暗示ML处理器需要更细颗粒度的分支执行并同时执行高速的数学计算和数据搬运(即I/O密集+计算密集业务,也就是NetDAM在干的事情),最后要求能同时处理训练和推理,并且要支持从边缘到云端或者数据中心全覆盖,所以这里看你就明白(Nimble+Ruta在干嘛了)

Ch.2 硬件架构

NOC

片上网络和数据中心网络的融合是这场变革的关键,渣很早也讲过:

回到TensTorrent的片上网络和片间网络来,很喜欢这样的架构。

而算子间的通信源语很简单,主要是如下几种,并且DataFlow是Compiler指定的,因为计算任务是一个明确的DAG.

然后你会注意到他们多次谈到采用Push的方式,而不是处理器Poll的方式,但事实上是这张图:

而实现这个魔法的是在以太网控制器上直连的SRAM和相应的包处理器,然后他们把每个PU分为了NOC层和Compute层,后面讲软件的时候会说,而同样渣在设计NetDAM的时候采用了相同的处理方式

不过渣要考虑的问题更多,一方面是多租户的问题,还有传统云数据中心IPU场景的拥塞动态调整等,数据不会像TT那样的可以拆成mini-tensor,而且数据还有峰谷和局部拥塞毛刺等,难度比TT高很多,而且还要考虑Internet用户直接接入VPC的场景,例如利用RTC datachanel直接通信,然后还要适配各种生态的XPU

再一次看明白了NetDAM+Ruta以及为啥NetDAM header要这么设计了吧?

但是基于Packet Proccessing和Packet metadata做conditional execution都是TT和NetDAM的NOC层需要考虑的问题,很显然某种意义上说TT的处理器是一个NP,如果定义PacketProcessor算NP:

然后金坷垃讲到现代ML处理器可能需要同时兼顾存储加速网络加速、有时还要准备数据、有时还要做Post Processing,于是在他们第三代处理器中直接买了SiFive最顶级的x280 RISC-V核心,然后Jim讲到作为一个创业公司呢,首先要做的就是正确的构建有价值的东西,然后说道他们已经有非常好的AI处理器、也有非常好的软件,现在野心自然出来了,要做一个同时兼顾ML和通用计算的处理器

当然也解释了为啥RISC-V,这个图值得好好研究一下,然后8个Core构成一个集群:

然后就谈到了和已有的AI处理器异构并实现基于Packet的Cache Coherence的处理, 大号的CXL+NetDAM看懂没?所以最后的架构图

Software

这里开始讲不搭(BUDA)了,给C–加个赞,但是你里面又用C艹…

首先对于传统的AI模型,简单的抽象成一个可微分算子

但是都用了RISC-V了,自然要玩点不一样的,也就有了GENERIC CODE的算子

而渣在Nimble的引擎里也是同样的处理方式,利用go channel实现的Map算子容器

这样有个好处就是,用RTC核可以同时将视频解码生成图片并转换成向量以及到后面数据库写入融为一体

然后每个Op可以实现自己的处理方法:

下图有个BUDA实例,这是一个标准的矩阵乘法器

很清楚的流程 wait_tile, compute,  pop_tile, pack_tile ,wait_free_tiles, push_tile,这里是tensor构成的tile好写,但是考虑到其它情况可能就难一点了,例如一个通用的结构体?

然后就是通信的Pipe,也没啥特别的,只是又一次强调了Push的重要性,注意到High overlap of compute/communication

接下便是编译器了,也就是TT自己说的NOC层(pipe)和Compute层分离的结构

有些细节就不多说了,接下来就是吹了下如何快的根本原因

特别是还这图吊打黄教主,特别喜欢

对于BUDA如何planning graph这次没讲多少,专利上谈到一些,首先根据算子的复杂程度将DAG划分并映射到不同的区域

然后有一些基于推测的算法图尝试planning graph,具体可以看他们的专利

看到这里是不是想到Flink?不过TT需要考虑的东西更多一些。然后片上通信采用跨核交换路由的方式,因此不需要严格约束某个算子一定要在邻近的核。

这一点让渣想到了大概十多年前做一个模型用到的元胞自动机的一些算法,加上最近读的一些关于meme,还有Temporal Network,似乎可以做一些AutoML的东西出来而不是人来写代码构建DAG

当然TT也有展望,但是感觉没想透,时域上的window function要做,分布式系统到边缘后SDWAN也要做,小的处理器也要做,和通用处理器异构和通用云存储和云数据库融合也要做…

最后,很高兴有这样的工业界的实践,高山流水觅知音的感觉。

终于渣再也不用在一些why not viptela SDWAN,why not SRv6,why not Flink的问题上和一些人纠缠了,有个学霸写了同样的作业,当然渣并不是抄作业的那个。

当然能做到这一切,你不得不花大量的心血去研究,而且在各个领域都要看的很深,Nimble涉及到整个AI训练推理和流计算平台,Ruta涉及到大量的网络和路由的知识体系,NetDAM则涉及到大量的体系结构的的东西,这几年一直维持着一个很小的团队甚至其中一些项目还独自solo,冷暖自知,因为那个年代的世界上别人因为没有看见所以不会相信。

哪有什么天才,哪有什么颠覆式创新,哪有什么弯道超车,哪有什么灵光一现。无非都是在一次次的推演和妥协后的结果。直道踩油门,要干就盯着业界第一打。要有这个勇气和自信,堂堂正正的去干。

Reference

[1]

为什么有些学数学的看不惯甚至鄙视 Deep Learning?: https://www.zhihu.com/question/58992444


[2]

Software and Silicon in Serbia: https://youtu.be/5bn54FSe_0A

再谈云计算范式的变革》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/233.html