基于开放标准的异构计算加速平台

Whitney，Facebook：大家好，我是Whitney，来自Facebook基础架构部门，今天我和天轶一起介绍下OAI这个开源项目的进展。我会分享OAI开放加速基础架构项目背景、历史，简单介绍项目相关的五个工作小组。

2019年3月，Facebook连同微软、百度一起开源OAM标准的时候，同步成立了OAI开源项目组，OAI主要Focus在定义和建立OAM相关的技术架构，包括电子、机构、散热、管理、安全各个方面。

这个是支持开源项目的公司列表，今年有一些新的公司陆续加入。简单回顾下OAI/OAM时间线，在2017年年底时，鉴于很多公司开始步入设计AI加速芯片和解决方案领域，我们没有足够的资源，也不想每一种硬件加速方案都设计一个不同的硬件系统，所以就萌生了这个想法——定义加速卡标准，也生成了0.1版本的标准，然后就开始Engage其他公司，很快就得到了微软、百度的响应，跟我们一起继续定义这个标准。

经过一段时间，在2019年3月，我们开源了OAM 0.85版的SPEC，并且随后在2019年，通过跟intel 、Habana、英伟达、AMD、赛灵思、Enflame等等公司的合作，19年总共推出6款和OAM标准兼容的加速卡模块，也在2019年下半年开源了OAM Base for UBB这样一个标准。

鉴于项目组各个分支逐步细化，大概在2个月前我们把项目组划分为5个具体的工作小组，下面我们来介绍下各个工作小组的概况：

1、 OAI系统，主要是针对OAM模块，UBB的载板，HIB主机接口板，系统firmware等等一系列系统相关的模块做标准化定义，也包含参考系统设计；

2、 电源工作小组，主要针对OAI系统的power delivery，电源设计相关的要求，还有推荐设计，包含定义DCDC转换等。

3、 第三个是cooling相关的工作小组，主要负责定义和推动OAI、OAM液冷解决方案的标准化相关工作；

4、 高速信号，核心工作是针对未来高速信号的研究，比如112G PAM4，PCIe Gen5\6等高速信号对于OAM模块和未来OAI系统设计相关的影响，这些工作直接关系到OAM2.0标准的定义。

5、 OAM tool，这也是唯一一个跟server的工作小组，这个小组主要工作focus在定义标准化OAM管理方面的接口，utility相关的工作。

谢谢大家！

Tianyi Gao：感谢Whitney。大家好我是来自百度的Tianyi Gao。百度是OAI项目的Founding member，我和Whitney一起合作负责做开源工作，很高兴OCP china day这个平台给大家介绍和分享OAI项目。刚刚Whitney给大家做了整体项目和背景介绍，接下来我分享技术部分重点更新，包括已经发布的定义标准和规范，以及行业合作进程。

在OAI项目中最核心的模块是OAM,就是AI加速卡模块，再具体一些就是基于Smartlink connect 的AI加速卡， 因此，OAM技术规范是项目最早发布的核心规范标准，今年该标准更新并发布了1.1版本。

在OAM定义规范中，包含了OAM卡的电气、机械、散热、结构、互联等详细封装和设计规范，比如加速卡封装的form factor，不同功率范围下的供电和散热设计，机械结构设计，还有通讯互联部分的设计。

规范中也包括了至多可配置8*16互联通道的不同拓扑结构，这个配置包括模块与模块间，和模块与host服务器间的互联部分。

在1.1版本中的重要更新是添加和引入了System management和Security的设计要求。OAM的第一版规范0.85版本发布于2019年，一直以来项目组内部跟很多加速卡厂商紧密合作，来开发和实现基于OAM规范的产品和解决方案，同时也不断验证、更新和完善相关的技术规范，这里展现的是目前已经实现的基于OAM规范的多家厂商的AI加速卡，同时目前也有一些AI硬件公司正在开发和研发基于和兼容OAM标准的解决方案和产品。

第二个重要进展跟大家分享的是UBB的规范标准，UBB是通用的基板，核心作用来部署和使能8颗加速卡，和其互联和管理等，项目组今年发布了UBB SPEC 1.0版本，SPEC 1.0包括了IO interface的设计，electric部分的设计，比如包括有整体PCP版的electric design,与host主机接口retimers设计，基于Qdd scale-out 64 retimers设计,还有机械结构的设计规范，比如兼容19寸和21寸不同规格的机柜，供电和散热规范，比如支持48V和12V供电，风冷和液冷散热方式，系统管理的拓扑方案等。

同时还有重要的一部分是包含对应支持OAM SPEC的不同互联拓扑方式的设计规范，在系统和UBB部分，在过去一年内项目组内有多个厂商共同合作来开发UBB和OAI系统，今年也有多个新的服务器系统厂商加入了项目组，后续深入的合作包括UBB和OAI其他模块部分的设计规范和样机开发。

对于互联拓扑部分，OAM和对应的UBB规范中，包括多种不同设计，包括基于8个link 的 hybrid cube mesh ，6个link的循环，全互联，还有全互联+HCM结合的等多种互联方案，这里思路是可以更灵活更广泛支持不同AI加速卡，及相应的技术需求。

对于UBB的部分，重点核心是设计不同拓扑方案，来支持不同的OAM,但是在其接口部分，和其他规格上保持高度的兼容设计。刚刚提到了一款兼容结合的互联方案，就是兼容全互联，和6-port HCM两种互联拓扑，这样的设计使得一种设计的物理port，可以用于支持部署更灵活实现不同拓扑方案的OAM。

这里图片也可以看到，在SPEC中也给出了基于互联方案的PCB 的XXX routing解决方案，这样不仅进一步提升了系统厂商的设计开发效率，同时增加了end user灵活部署的可能性，在上午进行的OAI workshop,和接下来的一个session分别安排了多个技术分享和panel discussion ,希望给大家介绍一些更详细的项目工作进展，还有下一步的项目规划，包括OAI内不同work stream的内容和计划， 在panel讨论中，也交流了AI硬件和系统在当前和未来的挑战，和OAI项目在解决这些挑战中的价值和作用。

最后，这里两个链接，包括项目的wiki page，有OAI项目发布的技术规范，和进展更新，另一个是项目信息发布的mailing list，我们也希望有更多的业界同行和伙伴加入项目，共同合作一起构造AI硬件标准和生态。

再次感谢大家的时间，谢谢再见！

基于开放标准的异构计算加速平台

OAI参考系统

王磊，浪潮信息首席系统架构师

王磊：首先感谢主持人的引荐，其次很高兴大家来参加OCP今天的盛会。我叫王磊，来自浪潮，是浪潮的首席架构师，负责整个我们浪潮OAM 21英寸系统的设计。今天很高兴能跟大家分享我们这个系统整个设计。

我今天的介绍内容分成了四个部分，第一个部分是一个OAI的介绍，第二个就是浪潮如何来协助OAI进行加速的实现，第三个给大家介绍浪潮21英寸的OAM系统，第四个介绍浪潮基于21英寸整机柜的解决方案。

OAI大家知道它是一个开放的组织架构，这个组织架构里由百度、Facebook来主导的，他的核心思路是来规范整个AI加速模块以及系统的设计，分成大概几个部分，底层对整个架构进行了规范，上层是加速模块OAM，以及承载OAM模块的OAI-UBB，以及基于OAM的安全、控制和管理模块OAI-SCM，上层是他分到这块不同的interface，他的整个供电的方案，以及OAI-Tray和OAI Chassis。

浪潮是作为AI国内领先的领头企业，同时我们也深刻认识到AI逐渐进入到大家的生活，像我们快速支付、瘦身美颜、人体测温等等，所以浪潮也是积极的参与到整个开源组织里来，我们有几个核心的目的，第一个我们通过参与这个组织，以及UBB的设计，我们希望能来降低整个业界伙伴进入OAI领域开发的难度，其次不同的客户可以基于UBB的设计可以快速根据自己不同的work load构建自己基于OAM的系统，从而缩短产品上市的周期。第三个，通过我们的UBB和我们的符合OCT标准系统的设计，可以让进一步开元的技术更广泛的推广到产业链，可以更快的使产业的配套更加简化。

这个是浪潮在整个OCP OAI组织里所做的贡献，主要有三个大的部分。第一个部分首先我们浪潮参与了OAM模块这个SPEC的制订，第二个是浪潮组织了SPEC的制订以及UBB的设计。第三个部分是我们浪潮首先发布了业界第一款符合OCP标准21英寸的基于OAM的系统。左边这个图大家可以看到，在2019年OCP欧洲峰会上，OCP也展示了浪潮第一款UBB的设计，同时今年我们浪潮也联合了各个OAM厂商，像英特尔，以及像国内燧原这些OAM厂商一起，在整个系统上进行了适配，来推动OAI以及OAM系统生态的建设。

这个是我们浪潮面向OCP标准首发的第一款21英寸支持八个OAM的系统，它是基于OCP的标准，采用的是前维护的形式，这个也非常符合未来业界像这种数据中心的可维护性，同时在前面我们也预留了非常多的一种灵活的扩展方式。大家可以看到，其实我们有很多的采用高速高密的连接方式，在两侧每个高密连接器上，我们可以承载两个板16速的高速信号，可以使客户非常灵活、快速的去连接他这种符合OCP标准的电脑，来根据不同的客户应用来构建基于OAM的解决方案。同时大家在看到系统上我们也是提供了标准的，我们叫view模组，这种模组提供了非常丰富的可扩展的方案，客户可以基于他的应用，可以适配增加一些比如说针对date的一些扩展，同时比如客户还可以基于他传统的像数据中心的网络来进一步利用OAM的优势，来线性的去扩展他自己的基于OAM的AI的加速网络和系统。

这个是我们整个系统大致的SPEC，我们设计标准，是符合OCP标准的，我们是采用了一种非常极致化的高密的设计，我们可以支持八个OAM模块，同时我们还支持了非常丰富的IO的扩展能力。这个大家看到是我们整个OAM系统的组成，它包含了UBB的标准模块，还有Front IO给客户提供可支持的模块，同时我们在两侧提供了PCIe的标准模块，同时我们可以支持非常极致的设计，这个对我们整个架构还有散热带来了非常大的挑战。在后面整个布局上他是有Switch和POB组成的，我们也参与了立交桥的设计思想，使他们的交换和供电集成在了一个平面，这样可以大大提高我们整个系统的散热以及布局的密度。

这个是我们整个OAM系统的拓扑图，我们采用串型的布局，这个可以提供更多外部的扩展给到我们系统，可以实现更多的像计算资源的迟化。再往下OAM本身来说，我们每个Switch对接了两个OAM，这也保证了IO到GPU或者到OAM的通讯他有高带宽比。同时我们也提供了灵活的IO扩展。

这个刚才我介绍了，由于我们提供的架构设计，所以在这种支持上，我们可以支持Muiti-Host的技术，左边的图右边的图大家可以看到，我们同时可以支持两个计算界面和四个计算界面，这样使得客户针对他不同的应用附载可以动态的去做计算资源，来动态的匹配他们这些AI的应用和不同的。

这个是刚才介绍的基于符合制度的，符合UBB标准的机板，这个机板其实我们当时设计的是符合了刚才介绍的，我们支持两种拓扑，一种是面向完全对OAM之间大的高速的带宽或者对大的AI的模型有特殊需求的，同时在这个基础上我们还支持6Port的HCM，这个相当于我们提供对AI场景有小应用分割的场景，也是能同时满足这种场景下，所以我们这种UBB的设计可以满足大程度上一种灵活的方式，满足不同的客户对AI模型应用算法的需求。

这个是我们整个OAM系统的设计，我们首先的宗旨是采用54V供电的直入设计，因为比传统的12V来说，54V可以更好的提升整个供电的效率，来减少供电的损失，然后因为是为了支持比如不同的OAM的解决方案，所以在我们供电设计这块，我们采用分割的设计，我们采用了54V注入以后，我们通过我们的UBB版，把它转化成54V和12V双向的输出，传递到UBB版，这样使得在UBB模块上同时支持54V以及12V的那些OAM，可以给厂家或者合作伙伴提供更灵活的选择。

这是整体的解决方案，包含了刚才说的OAM的系统，以及符合OCP标准的计算节点，我们现在这一套整个的系统已经完善了，也是希望能通过这个系统助力更多的合作伙伴能尽快的把他们这些基于OAM的应用能尽快的构建起来，希望我们通过浪潮的力量来加速整个OAM在整个业界的推广。

同时，我们浪潮也是基于OAM有整个整机柜的解决方案，这样我们面向未来的数据更新，一个我们整个是基于48V的机柜设计，所以能满足他未来可以协助客户更好的来提升他的数据中心的效率。这里面我们包含了像33千瓦Power Shelf，同时包含了OAM系统以及计算节点，同时我们还有标准的，我们希望一系列符合OAM整体的解决方案，能更进一步助力OAM整体的生态。

我的分享就到这里，谢谢大家。

百度AI全栈解决方案

黎世勇，百度系统架构师

黎世勇：非常感谢主持人，我是来自百度的黎世勇，主要负责的是服务器软硬协同方面的工作。

今天在这里也非常高兴有这么多朋友一起来做技术交流，今天想在这里跟大家对百度AI底层的基础设施做一个简单的介绍。我今天要讲的内容包含这几方面的内容，一方面首先简单的概要一下我们百度AI基础设施要解决哪些问题，怎么样去解决这个问题，构建了什么样的框架。

另外一块在整个基础设施里面最重要的几个环节，最重要的一个环节就是整个AI的计算系统，所以在这个地方我会跟大家同步一下百度AI服务器4.0的特性和想法。第三个内容涉及到重组还有通信上的一些事情，在这块我们做了很多软硬结合的优化，企图消除业务在使用过程中的各种各样的瓶颈，大化的发挥AI系统的性能。最后，前面东西都是软件和硬件上的设计，最后我们基于云原生去打造一个分布式的训练平台，这样上层就会有很多的应用可以共享底下的AI基础设施。

大家知道AI应用包括很多环节，包括数据的读取，涉及到IO系统，包括一些预处理可能涉及到CPO。所以我们设计了高性能AI的计算系统，这样去应对我们整个AI系统中的挑战。给大家案例一下百度基于对自己模型的理解，在自研究的芯片这块推出了昆仑，并且我们在未来也会有一些在训练上在互联上，甚至在跟OAI结合的一些相关的信息分享给大家。基于底下的芯片和中间层，要分别优化重组系统和通信系统，后面跟大家介绍。

最上面介绍了我们整个分布式的AI训练平台这一层，主要基于智能的调度或者一些弹性的调度，让我们把底下的资源用的更好，浪费的更少。当然结合上面我们的框架层，这样就可以给上层的业务提供非常好的一个底层基础设施的体验。

首先给大家介绍一下我们整个在计算服务器上，就在以前的一些交流过程中也分享了，在2016年的时候其实在很早的时候基于PCIe的连接年代，我们通过池化手段实现了高密度，在2017年我最早开始尝试液冷的技术，在这个时候我们实现高速节点之间内部的互联。现在百度更多用的是3.0的AI产品，采用模块化的设计，更多的去满足我们在扩展性，在灵活性上的一些需求，同时在这里我们也会尝试，我们已经开始用48V的电源去提高更高的性能和算力。然后我们在下一代产品中，也就是我们的X-MAN4.0更多的会考虑花在IO花在互联上，这样会带来更多的灵活性和可拓展性。同时大家都知道以前我们的AI服务器更多考虑的是AI的场景，在这种场景下，节点之间的互联，其实节点之间的数据传输不会这么大规模，不会这么大要求。所以我们在4.0的情形下，也会充分考虑HPC上面的需求。

这里就是我们在X-MAN4.0方面的设计，整个拓扑图还是模块化的设计，一个结构化的设计，机头的CPU和后面的GPU产生解耦的方式，无论是在内部通过link实现GPU之间的高速互联，在外部我们通过冗余的网卡，可以构建大规模的GPU的集群。另外一个，我们通过可扩展性实现更高的密度，在单机的系统中可以实现24卡GPU的密度。

除了我们基于OAI实现的X-MAN，百度在整个AI系统中也是处在领导者和推动者的姿态，希望结合OEM厂商，需要结合芯片的厂商，更好的推广OAI的生态。当然前面有介绍，浪潮已经推出了OAI的参考系统，越来越多的芯片厂商开始推出我们这种OAM模组的解决方案。比如AMD，当然包括国内其实也有一些很多企业，包括燧原这些公司都在考虑我们通过OAI的方式去实现我们整个的AI计算系统。

前面介绍了计算，就是说从一个AI系统来说，第二块，我们就要去处理数据，首先要去获得数据，获得数据对一个OAI系统来说，我们为了获得高精度的模型，我们需要训练大规模的数据，成千上万的数据，但是这些数据具有一些特点，它往往都是一些小数据，比如图片，比如一段文本，这些小数据来说对我整个重组系统性能上的挑战也非常的大，希望我们在很快的时间去获得这些数据，然后以为保后端的GPU，充分发挥GPU的性能。从这个角度来说，可能需要具备针对小数据集上的优化。在这里我们主要是通过两个方面，一个方面是通过硬件系统，我们采用一个池化的解耦的方式，将计算节点和重组节点完全解耦开，通过IBM的互联实现高带宽低延迟，当扩展计算和重组节点的时候，不需要绑定在一块。

另外一块，就解耦我刚才说的，AI系统中大多数都是小数据，小数据的性能在重组中往往实现挑战，所以在整个软件生态上我们设计了我们自己分布式的重组系统，BPFS，在这里通过底下的一些高速的互联，IDMA、SDK这些技术去实现我们对性能的考虑，当然在性能层还需要优化手段去优化小零件的性能，也就是说通过我们自己设计的这套BPFS，针对小零件能够满足很好的性能上的需求。另外在上层的时候我们提供完整的接口，这样方便业务可以很方便的接入和使用。也就是说通过解耦的硬件设计，再加上针对小文件的分布式存储系统，优化的存储系统，我们就去很好的为我们整个AI系统去提供了存储的能力。

这里挑选了一些典型的模型还有一些业务一些数据分享给大家。

在我们针对小文件式优化的场景下，我们几乎可以获得不亚于本地盘的一个相关的IO性能，同时在一些典型的业务上，我们跟传统的那种文件系统相比，也获得了极大的训练项目的提升。

第三块内容就是通讯，大家知道我们在分布式训练中，往往要在GPU中间传输大量的梯度数据，这些梯度数据非常小，延迟的敏感性非常高，所以我们怎么样设计一个很好的通信系统，除了前面我们说的，我们可能要用到高速的网络，我们在软件系统上也需要考虑各种各样的问题，我们在分布式训练中首先从一个层面来看，我们会用到各种框架，还有一些公司会用自己自研的框架，总之多种多样。

这些通讯框架从现在来看会遇到很多的问题，要么使用起来非常复杂。现在很多的一些训练框架更多考虑的是单机的训练，在分布式训练上的使用过程复杂。另外就是另外一类，效率非常低，通信效率非常差。比如大家经常诟病的会在这方面出现问题。另外从底层来看，其实通信的角度来说，我们现在用到通信的一些基本的技术库也是多种多音，比如MPI来实现通信，从这个层面来说我们要实现通用的通信框架，就要很好的去适应这种软件上的多样性。

另外一个刚才也提到，我们在芯片之间传输的大多数都是梯度的数据，这些梯度数据的优化，或者梯度数据的传输的效果也对我们整个通信有很大的影响，在这一层，也就在我们通信策略这一层，我们会去做大量的围绕梯度上面的一些工作，包括如何，包括量化这些事情去加速我们整个数据的传输。也就是说整体来看，从底下的算法库到中间的梯度压缩到上层我整个分布式框架的集成，这样去打造了一个通信加速的框架。当然我们也是拿着典型的模型去看整个的效果，就与现在比较流行的开源的halo work相比在调优的情况下可以获得更大性能的提升。

前面讲的是设计，整个系统瓶颈是怎么样的，另外一方面我们整个训练是什么样子的，这样可以很好的指导我们前面说的计算系统、通信系统上面的优化。

最后想跟大家分享的就是我们大型的AI分布式训练平台Kongming，为什么要去打造这个平台？是因为百度有大量的业务，大量业务在使用底层资源的过程中，我们怎么样充分使用底下的计算资源、重组资源，需要有个调度系统，我们上面训练的任务也很在乎性能，需要有任务的调度系统，所以结合资源的调度和任务的调度，我们最后推出了基于K8S打造了整个分布式的训练平台，主要是这几方面的工作，首先在最底层是结合的我们自研的CPU的整套方案，去实现GPU共享的机制和能力，这样多个任务可以在相同的GPU上去共享这些GPU。

第二层，我们要去调度好这些资源，所以我们去实现了我们比较智能的弹性的调度的策略，去更好的把底下的资源给充分的利用上来。在上层我们更好的管理业务，管理队列，希望给业务提供高效的训练效果，通过这几层为上面提供了整个分布式的训练平台。

在这里给大家分享一下中间这一层怎么样做智能的调度，或者保证资源高效的使用。

首先，我们最先打造的就是一个抢占性的调度，百度的任务还是多种多样的，面对我们整个训练效果要求也不一样，有的可能是训练到希望尽可能完成训练，要求非常高，有的可能是可以运行很长的时间，这样就导致我们任务可能具有不同的优先级，比如在这个图中，我们红色表现高优先级的任务，当一个高优先级任务到来的时候，我们整个集群中有没有一些服务器的资源在使用的情况下，就是会从整个当前正在运行的pass中去筛选他的优先级，在这整个图中黄色和绿色是中等优先级和低优先级，我们去判断这些优先级在资源释放的情况下能否满足高优先级的任务需求，以及他可能的释放方案。在把各种方案进行一个排列，排列完了之后去选择最优的抢占的方案，在抢占方案的情况下，就会把当前的这些中等优先级和低级优先级的任务给暂停，当高优先级任务运行完了之后，再通过框架的checkpoint恢复低优先级任务的运行，这样给用户非常好的训练上的体验。

第二块前面也说过，我们基于K8S的机制，实现了左边多任务共享的能力，当前的GPU我们在调度程序使用的过程中往往都是独占的，我分配给任务A了之后，B是很难再使用它了。我们通过升GPU这样一层隔离机制，去很好的把多个任务放在单GPU上可以同时的运行，这样针对一些小模型会带来很大的资源提升，因为有些小模型在现在芯片算力越来越大的情况下，可能跑不满一块芯片。另外我们在这里也去使用一些工具，比如IPS去做一些优化的能力，通过IPS把运行在一块GPU上多个任务进行融合，这样能给业务的训练效率带来极大的提升。第三块就是TOP感知，大家知道我们的一个AI系统设计出来之后，经过我们的CPU，CPU之间还有互联，经过我们的PCIE、网络、IO这种TOP结构是非常复杂的，在现有的调度系统中，一般情况下不会感知底下硬件上的差异，导致我们在分配资源的时候，有可能出现跨很远连接的GP无误的互联，提供给训练任务去使用，这样子会导致很多通信上的开销。感知TOP的调度，就是让需要多GPU的任务，尽可能分在一个TOP的节点下，这样就节省了跨各种中间层的数据传输的影响。

最后一块，在我们整个训练的过程中，其实往往还遇到我们在运行的过程中发现资源不足或者资源过剩，需要进行动态的资源调整，所以我们针对这种场景实现了弹性的调度，弹性的调度机制主要依赖于框架的checkpoint，弹性调度就依赖于框架checkpoint的机制，当他需要动态调整资源的时候，保护好现状，恢复好运行，重新分布数据重新分布计算，这样更大化的去使用我们底层的资源，也保证我们整个时间没有去浪费。

最后简单总结一下，就是百度是基于前面对AI系统从计算重组、通信上的一些挑战，去构建整个完整的AI的基础设施的生态，包括今天没有展开的昆仑的芯片到上层的框架，希望能给上层业务提供非常好的基础设施的体验和算力，同时硬件上百度积极推荐OAI项目，也跟国内国外芯片的厂商，去给大家提供更好的软硬件协同上的一些解决方案。谢谢大家。

针对AI训练的开放智能芯片

江斌，上海燧原科技有限公司系统架构及设计总监

江斌：我今天给大家会分享一下燧原科技，因为燧原科技是一个两年半的初创公司，有些朋友他不了解，所以我今天也跟大家简单分享一下燧原科技。另外，我就介绍一下我们云燧T11 OAM这个产品，另外我们结合一个OAM的工具，在支持OAM的 OAI系统里面也是非常关键的。最后会给大家分享一下我们的软件栈简单的介绍。

我先简单介绍一下燧原科技，我们燧原科技是一家什么样的公司呢？我们希望是说我们可以提供普惠的AI算力，算力意味着芯片，所以燧原科技第一步就是做了一个AI训练的加速芯片，同时基于这个芯片，我们做了两个产品形态，PCIe和此次跟浪潮一起展示的OAM。同时我们希望跟我们业界的硬件厂商和软件生态一起提供一个AI基础设施的解决方案，我想这是我们燧原科技目前正在努力的一个目标。

另外，在融资方面我也给各位简单分享一下，目前我们燧原科技融资总额13.4亿元人民币，经历了三轮融资，Pre-A轮、A轮以及B轮，很多投资人对燧原科技和整个团队也是非常的看好。

我们目前的产品是T10和T11，很多人问我们说，我们这么短时间内怎么做出这样的产品，我也给大家分享一下。我们的芯片设计是在2018年4月份开始，2019年5月底流片，在2019年9月份就在上海一次性点亮，随后在12月发布了T10和T11的两个产品。

我们在2020年的6月份正式量产PCIe版本的T10， 9月份我们在客户的云数据中心商务落地， 10月底在中国芯的评比中我们的“邃思”芯片获得了年度重大创新突破奖，“邃思”也是在这个奖项中第一个获得这个荣誉的AI芯片。

燧原科技怎么从短短的2018年到2020年这么短的时间内，2年多做到量产，我相信主要是因为我们燧原的人，以及我们的供应商对燧原团队的信任，是业界各大厂商，整个产业链对燧原提供了一个非常强大的支持，因此这个成就不仅仅是燧原科技的成就，我认为这样的成就应该属于我们半导体、人工智能的产业界，在此也非常感谢我们众多的从半导体产业一直到服务器整个全领域的众多的合作伙伴，谢谢大家。

这里谈一下我们燧原科技跟OCP结缘，我们在去年6月份的时候作为OCP china day观众来参加了，我们真的感受到OCP这个组织对技术创新以及对于一些新技术的包容性，我回去以后跟我们的CEO赵先生和张先生汇报了这个情况，我们在7月份就加入了OCP，同时这个项目就在当月通过了T11的设计。8月份就成为了OAM的成员，我们跟其他成员一起制订了OAM的发布。同时很荣幸今天能够受邀来参加OCP的主题演讲，以及后面还有一些论坛环节，我们在外面也有一个展台。

接下来我们的目标是希望能够量产我们的OAM的云燧T11的产品，以及前面百度的朋友以及浪潮的朋友讲的系统，我们希望可以跟系统厂商一起把整个OAM系统能够商业化、落地。

我在这里分享一下我对整个OCP之路的感觉，OCP它对技术的开放度，燧原科技作为一家初创公司，我们今天为什么能够站这个讲台上跟大家分享这个技术，这个是OCP这个组织它的一个包容性体现，不管你是大公司、初创公司，只要你有技术实力，只要你想让我们整个的数据中心、人工智能技术的一个发展做出贡献的企业，给我们带来的贡献非常巨大，可以让我们初创公司更好更快速的实现商业落地。

这里我给大家介绍一下我们云燧T11整个的SPEC，完全按照SPEC1.0设计的，我们整板功耗在300瓦，我们这个性能是基于单精度FP32，同时我们支持混合精度BF16以及FP16，这两个性能都是在86TFLOPS，之前谷歌在他的TPU上有支持，我们也可以说是业界比较领先支持的数据格式，在数据精度影响不大的情况，BF16是比较好的方案之一，同样我们采取3U标准的，3U标准的散热器的性能，我们的散热器性能在我们内部测试下来远远不止300瓦，甚至我们有做过一些对比测试，我们的性能上可能还要更好一些。

我们在接口上面也是支持PCIE Gen4 x16，我们叫燧原的智能互联，总共支持四个link，每个link有8个Lanes。这个在外面展台上也有展示，跟浪潮的展台上也有展示，我们单机八卡的整套系统也在外面展示，大家可以去了解一下。

整个AI里面光有OAM模组是不行的，所以刚才浪潮、百度秀的OAM的集群是非常重要的，对AI来讲一个芯片的性能是有限的，必须是集群。我们按照现有的拓扑支持4x8的，同时也支持QSFP-DD的4个接口。同时拓扑图上增加红色的，5和6增加进去以后，这个UBB变成6x16或者6x8的HCM，他依然可以支持QSFP-DD的接口，增加一个7的端口就可以支持全互联的7x16的HCM的模型。我们推荐的拓扑，是所有的拓扑一个UBB，所有的拓扑都可以支持QSFP-DD接口，你在两个机器之间就可以用这个东西互联了，跨服务器之间就可以实现两个芯片的点对点互联，我们是所有拓扑都可以支持。

这个是我们单机柜的HCM互联的拓扑，我们整个单机柜里面我们是用全部的GCU-LARE，不需要用RDMA交换机做任何的辅助，做两个机器的互联，它带来的好处就是低延时，我们基本上小于800个纳秒延时的速度，同时在两个机器之间大家可以看到绿色，绿色有四分线，每根线可以提供50GB/s的带宽，所以四根线总共可以提供200GB/s，在两个服务器之间，这样的好处就是没有RDMA的Switch，线的连接非常简洁，所以我们在公司里面布了个小型的集群，那个线看起来是非常美观的，所以对数据中心的布局理念也是提供了非常方便和便捷的解决方案。

到单机柜以后大家可以看的到我们的集群，我们按照自己的评估到1024卡规模的集群是没有问题，而且可以提供非常好的线性度，整个线性度为什么能保持比较好？因为我们支持2D Torus的拓扑，整个2D Torus是什么样的拓扑呢？红色和绿色就是我们GCU-LARE的拓扑，你可以实现一个垂直的环。

因为数据中心它的布局有时候比较远，用GCU-LARE会带来长度的局限性，我们采用的是一张RDMA的网卡，一个机器有两张RDMA的网卡做跨机柜之间的部署，机柜距离之间的限制不会那么大，所以我们采用了GCU-LARE加上一个网卡，一个垂直环一个水平环，在两个方向上做同时的Rings，这个就是拓扑的图，我们再做一些交换，这个是在我们分布式集群里面，我们这样集群大的优点是线性度非常好，成本非常低。

这个就是介绍一下我们燧原科技提供的系统管理工具，我们叫做Enflame-ML、Enflame-SMI，我们会提供系统的一些接口、命令，包括一些服务器的健康管理的一些命令，包括功耗、温度等，我们都会通过这个工具的接口跟上面一些分布式管理的接口做匹配，同时还有温度功耗之类的。

我的客户不想用SMI，他可以做自己相对应功能的一些SMI相关的工具。因为OCP现在也在做OAM Tool，希望通过OAM Tool来做所有模组的接口，这样我们对上层就会换成OAM Tool了，对OAM厂家来讲变得非常简单，我们只要跟OAM Tool的接口接上了，我上面这一层就不要关心了，各大厂家接入的时候，如果他支持整个OAM Tool的工作量就会减少很多，目前我们燧原也正在支持对OAM Tool的小组里面，我们会和大家一起努力，把OAM Tool做得更完善更好，这样会覆盖到所有的OAM厂家。

下面我简单介绍一下我们燧原的软件栈，我们最下层的就是我们的T11、T10和我们下一代产品这样一个硬件平台。目前我们的算子库支持500个的算子，支持一些算子的优化、算子融合，超越函数，包括众多的数据格式。当客户发现他自己要定制算子的时候，他可以自己去写算子。

特别强调，我们有分布式解决方案。上面就是我们整个TopsMatrix，下层会有通信库，以及同时会有K8S运行管理的，我们燧原是从芯片跟我们的硬件供应商一起做系统的集成，同时我们在软件栈上面我们也希望给予不同客户有不同的选择。有些互联网公司比较大的他自己有分布式集群的，我们可以利用他们集群的，刚刚百度的黎总也讲了，我们可以借路他们的分布式系统。对有一些行业客户，以及科教研的这些单位，如果他自己没有分布式的，我们燧原也希望通过我们驭算软件栈可以给这些客户提供一个开箱即用的方案，明年我们还将开始构建生态，通过开源的方式与第三方合作，希望通过开放共赢的思路，为客户打造适用的训推一体化解决方案。

所以我们燧原科技继续会以我们的AI芯片为核心，以板卡为产品形态，同时跟各家合作伙伴一起给AI的人工智能产品及人工智能技术以及数据中心做出我们燧原能够做出的一些贡献。

谢谢大家。

OCP CHINA DAY 2020直播回看：https://zhibo.ifeng.com/video.html?liveid=136938