2019年6月25日，由浪潮与OCP开放计算社区联合主办的首届OCP China Day（开放计算中国日）在北京正式开启。本届 OCP China Day聚焦人工智能、边缘计算、OpenRack、OpenRMC、SONiC、OAM等前沿技术话题，来自Facebook、LinkedIn、Intel、微软、百度、腾讯、阿里、诺基亚、中国移动、浪潮等资深技术专家分享了最新技术进展。近千名工程师和数据中心从业者参加了此次大会。
OCP是全球最大的开放硬件社区，2011年由Facebook发起成立，其宗旨是以开源开放的方式，重构当前的数据中心硬件，发展面向下一代数据中心的服务器、存储、网络、基础设施等创新硬件。目前，OCP核心会员超过200家。
随着AI的发展，ASIC、GPU等AI加速器越来越多，技术更新也越来越快，AI硬件系统的技术挑战和设计复杂性也越来越大，将加速器集成到系统中通常需要大约6-12个月。这种延迟阻碍了新的竞争性AI加速器的快速采用。
不同异构方案的需求是相同的，包括供/制冷、弹性、可用性、可管理性、内部I/O交互和外部可扩展的I/O链路等。OCP社区在服务器项目组下设立了OAI（Open Accelerator Infrastructure）小组，负责开发OAM（OCP Accelerator Module）规范，将加速器模块标准化，简化AI基础架构的设计，缩短硬件设计周期。在本次OCP China Day上，来自项目成员Facebook、百度以及Intel的专家带来了OAM的最新进展。
以下为大会演讲实录：
主持人：今年3月份在OCP的全球峰会上由Facebook、百度、微软三家公司联合宣布了OAM的成立，社区的反应非常的强烈。今天我们非常有幸的请到了其中两位负责人，一个是在Facebook的Whitney Zhao，还有一位是百度的丁瑞全，他们会和Intel的song一起分享一下OAM的进展情况。
丁瑞全（左）、Whitney Zhao（中）、Song Kok Hang（右）
Whitney Zhao：大家下午好，我是Whitney Zhao，我来自Facebook，在Facebook主要服务AI系统规划和架构设计。
丁瑞全：我来自百度，是AI架构师。
Song Kok Hang：大家好，我是Song，来自Intel，主要服务系统架构的设计。
Whitney Zhao, Facebook Hardware Engineer：我们还有一位嘉宾是来自微软的，由于一些原因没有来到现场，今天由我和其他两位分享一下开放加速器的基础架构项目。
这是我们今天的大纲：
· 我们会讲一下为什么有这样一个开放加速器基础架构的项目？等一下会给大家分享一下。这个项目由Facebook发起，很快找到微软和百度，我们一起开发了其中一个小项目，我们继续在完成整个规范的讨论。
· 之后我们会再来讲一下什么是我们的OAI？我们OAI这个项目下面有哪些小的模组？我们怎么一步一步完成这个规范？以及这个规范下面OAM的最新进展情况？OAM本身是加速器模组的规范，目前已经形成行业内的标准。
· 在OAM以后，在这个基础架构下面，我们会接着开发我们的universal Baseboard，当我们有加速器模块的时候，我们怎么让这个行业更快的加速，去应用到硬件系统、数据中心里。然后由Song分享一下英特尔对这个规范的需求和他们的产品，我们也希望大家积极参与到这个项目中，给我们更多的反馈。
为什么要做OAM？
Whitney Zhao, Facebook Hardware Engineer
Whitney Zhao, Facebook Hardware Engineer：为什么要做OAM？可能大家对于OAM、OAI的概念不是特别熟悉，当我提到人工智能，当我提到硬件加速器，不得不把他们联系起来，最近几年人工智能高速发展，有非常多新的硬件加速器出现，很早的时候Facebook在考虑问题，面对这么多的加速器的出现，对于机器学习、深度学习以及HPC领域，这么多新的硬件加速器，我们怎么样可以应用它们？从传统的GPU到TPU、IPU非常多的PU，针对不同的应用有不同的解决方案，我们怎么选择更好的解决方案，或者对于不同的应用可能有不同的解决方案都要来选择，针对这些我们怎么样更快的导入到数据中心来。
这是一些图片，给大家分享一下，当新的加速器芯片出现的时候，通常芯片会以模块的方式出现在舞台上，除了标准物理形态的卡，也有非标准的特制化的卡，比如大家非常熟悉的英伟达。还有谷歌最近两年出现的TPU，都是比较基于特制化的形态。
不同的板卡出现的时候，我们要导入数据中心就需要设计这些不同的系统来应用他们，我右边的这些图片是过去几年微软、Facebook和百度在我们数据中心的系统，大家可以看到这引发了我们第二个思考，针对这些不同的解决方案出现在市场上的时候，我们这些公司都在做着相同的事情，我们把这些解决方案应用到数据中心，这也是为什么很快Facebook和微软和百度联合起来成立了这样一个OAI小组，大家一起商量怎么让我们更快速的把解决方案导入到数据中心，当然我们也非常开放的服务更多的人。
这是我们的目的，我们有不同的解决方案产生的时候，我们在达到相同的需求，所以接下来我们要怎么样做这件事，我有请百度的丁瑞全分解一下服务器系统。
百度AI系统架构师 丁瑞全
百度AI系统架构师丁瑞全：谢谢Whitney，我们为什么要做这个OAI的project？怎么去应对这些挑战？首先将我们典型的AI的硬件系统进行分解，看看这里面有哪些关键的组成部分，然后把它们的关系理清楚，我们可以看怎么更好地做这样的系统。第一，我们需要有AI的加速芯片，但是一个不够，我们需要更多，所以我们需要有一个Base Board承载多个OAI的module，整个系统需要一个CPU控制整个系统的执行流程，当然CPU没有那么多的PCIe资源，我们需要有一个PCIe开关把AI芯片和CPU连接起来，这三部分构成了我们的AI加速系统，但是大规模的AI的爆发需要很快的算力，一个节点不够用，我们需要更好的扩展能力，有两种典型方式，第一是通过传统的以太网的交换机实现互联，但是这个license比较高，互联的带宽也是有限的。第二是新兴的技术能实现AI加速芯片之间私有的互联技术，这是一种更高速的互联，有更低的延时，可以大幅提升大规模训练的性能。从一个单机扩展到多机，构建了典型的大规模的训练系统。除此之外我们还有基础的基础设施，包括供电、散热，AI这种场景功耗非常高，散热和供电都很有挑战的问题，我们这个系统有很多不同的模块，这些模块之间有很多种不同的组合形式实现这个目标，但是这里面有很多权衡，有很多选择，不同的方案有不同的优劣。
我们接下来看一下现在典型的产品是怎么解决的，这里面存在什么问题。第一是AI PCIe形态的加速器，PCIe是一个标准，所有的AI芯片几乎都会有这种形式，可以快速地用起来，但是它的问题在于PCIe供电能力是有限的，不能够很好地支持高速互联，所以这个图片大家可以看到有些方案在尝试将PCIe标准形态的卡连接起来，这种时候系统已经不是很标准了，会出现很多系统设计的因素的限制，所以有些新的方案，比如定制一种非标准的Mezzanine解决这些问题。现在图片显示的几个系统用的是同一款AI加速芯片，但是系统加速层面有很多差异。最右边是百度自己的产品，上面是2.0的产品，下面是3.0的产品，它也会因为各种各样的因素导致不同的卷轮中不能兼容。AI芯片相互之间和CPU之间是需要互联起来的，可能因为计算节点的限制包括对于存储的需求和IO互联的需求的要求不一样，所以在PCIe拓扑的地方大家在设计的时候有些差异，导致我们的硬件系统适应新的需求都比较困难。
这是供电的部分，典型的供电有两种，一种是常见的将电源模块放到服务器内部，这种方式比较简单，简单易实现，问题是不容易扩展。第二是集中式的供电方案，中间是OCP的Rack，8482在中间，右边是Scorpio的Rack，也是采用集中供电，但是8482在侧边。AI芯片的功耗非常高，一张GPU卡相当于一台服务器的功耗，一台AI的服务器几千瓦的功耗，对于散热非常关键，风冷和液冷两种方式。风冷比较常见的是将风扇集中在服务器内部，第二种是采用共享的风冷墙的方案，它相对比较灵活，但是随着AI芯片的功耗进一步增加，传统风冷的散热效率有一定的局限性，所以我们需要有更好的液冷的技术支持更大功耗的AI加速芯片，提升整个系统的性能。
管理，对于数据中心部署的产品，远程的可配置性、可监控性、可维护性都是非常重要的，这样我们才能大规模地部署这样的产品，对于AI的硬件系统这是必不可少的部分。IO Board，低速的IO比较简单。相对比较关键的是高速的IO，比如存储的IO以及多机互联的网络IO，这些因为不同的需求导致一个系统里IO的数量不一样。
我们刚才举了很多例子，现在我们在怎么构建AI的硬件系统和这里面存在的问题。这里面都在解决同样的需求，可以分为三类，第一类是灵活性、高可靠性、可运维性、远程配置的管理，这些基础的特性，对于大部分数据中心的服务器，这些都是有需求的。有两点不一样的地方是AI的场景里对于Module之间的互联带宽要求更高，我们需要卡间互联提升整个系统的纵向扩展的能力，也可以实现Scale Up的能力，我们需要Scale Out横向扩展的能力。
第三部分对于AI的硬件系统来说非常重要。针对这些挑战，针对这些需求，我们怎么去解决它？如果你想走得更快一点，你一个人单枪匹马往前冲很快能达到你的目标，但是问题在于当你攻克了第一个目标后，下一个目标又要重新设计你的方案，当新的AI加速芯片出来的时候怎么办？重新再做一套，一年的周期就过去了。从这个角度看，自己做自己的项目短期能取得一定效果，长期是比较困难的，所以需要协作，大家共同构建良性的生态，借助集体的力量做这个事情。我们跟Facebook、微软形成共识，在现在的时间点，在OCP的舞台里我们需要做这样的事情，这样才能实现长久的高效的发展。
所以我们需要开放的AI加速的基础架构，我们需要采用模块化的思路，增强不同的模块与系统之间的互操作性，加速相关技术的创新，推动新的AI芯片的快速落地。在这里我们承接了开放的AI加速的基础架构的规范，定义了相关的基础规范，我们把相关模块之间的边界定义得很清楚，只要满足相关的接口大家在这个系统里面共存，这样可以很好地将共性的需求抽离出来，将特定的需求通过模块化的形式满足，会更好地加速相关的创新。这里面分为八部分，第一部分是OCP的开放加速的模组，这是AI加速卡的本身，我们需要Base Board承载AI加速的模块，我们需要主机的接口将AI加速的模组和CPU部分连接起来，我们在整个系统中需要有供电的能力。第五部分是不同的主板之间多机拓展互联的能力，包括基本的控制、安全需求，怎么实现高效的运维，怎么兼顾不同的Rack尺寸的需求以及限制。
我们这个是模块化的，相关的设计和产品只需要满足部分就可以了，并不需要完全follow相关的规范，这是我们考虑AI project时候的很大的原则，我们需要最大限度的统一，同时也能将特定的需求在这个大的框架下面支持到。目前我们OAM的Project已经取得了很好的进展，当前已经实现了开放的AI的加速模组，接下来有请Whitney给大家分享一下这方面的进展。
基于OCP规范的加速器模块OAM及其进展
Whitney Zhao：接下来我给大家介绍一下什么是基于OCP规范的加速器模块OAM？OAM在不同的AI芯片出来的时候，它都可以跟随我们定义的形态来设计这个板块，这个目的是当你有一个系统设计的时候可以使用不同的模块，可以用A解决方案或者B解决方案，保证你的灵活性，不需要设计很多系统。
为什么我们要做这个OAM的模块，我列了很多问题，比如在训练芯片的场景下，训练芯片有很多的Interformance，PCIe只能定制，它有很多互联，所以我们希望这些输入输出的连接跟芯片之间距离要足够的短。
我们也要保证足够的空间，当我们制订这个标准的时候也跟不同的厂家谈，我们AI芯片有更多算力的时候，也许下下一代芯片做的更大，我们也考虑了这样子一个，不仅仅是从这个方面，也可能是下一代，下下一代，这个大小都可以融合，我们也希望散热器的灵活性，可以支持风冷也支持液冷。
我们也知道基于PCIe的规范最多是300瓦，保证最大应用性能的情况下，我们很多推出的芯片已经超过了300瓦，这样PCIe没有办法满足这个需求，这个情况下推出了这个标准。
在这个模块下，我们有考虑到有一些低功耗的训练场景的芯片，也许它们的电源设计还要基于12V，因为12V是目前的主流，在超过300-400瓦以上的时候，英伟达已经推出一些解决方案，基于48V或者54V的电源解决方案，我们这个标准是同时支持12V、48V或者54V，12V的情况下，根据我们的定义，我们最多可以支持到350瓦，48V或者54V的情况下最多支持到700瓦，700瓦并不代表现在已经有一个解决方案是700瓦，因为700瓦×8，大家知道这个系统电源多大，我们是基于电源管脚的定义。
在高密的connector（音）有八组X16型号，其中一到两组X16的型号可以延主机，另外6-7组X16是定义给模组和模组之间的通信，模组跟模组之间的通信，这个X16可以被分解成X4或者X8或者X1，这样的意思，我这个模组，大家可以看这个不代表这个模组只有一个芯片，如果你的芯片比较小颗，放两个或者四个都可以。
高速连接的速度最多是56G，每一个基于19寸机箱的大小，我们的主机板大概在16.7到16.9宽度的情况下，一排放四个，整个系统放八个，在这个规范里也有系统的管理和调试的标准接口。
在这个规范里也做了比较详细的跟散热有关的参考设计，它的机构上有哪些东西必须按照他的规范，如果我们有这样的主机，你有跟随这个规范做这个模块你用到我们的主机上，可能要跟随机构的设计，包括定位孔螺丝孔的大小，这个你要跟随，我们也提供了一个3U的散热器的设计，考虑到通常一个主板可以放四颗，但是因为这个模组本身比较大，在你运维的时候，SeverBility也是我们考虑的方面，你在装机的时候也比较容易去做。
这个概念由Facebook发起，由微软和百度共同开发，3月份，这个规范已经得到了非常多公司的欢迎，已经便成了行业内的标准，包含我们国内的腾讯、阿里巴巴，目前这些商标是我们三月份的一个截图我也很开心的宣布京东也加入到了我们这个组织里，非常多的公司在这上面，我分为三块给大家讲解一下我们这个生态系统的建立。
第一，我们的最终用户是谁，如果大家熟知七大数据中心，亚马逊、AWS、谷歌、微软、腾讯、百度、阿里巴巴，这里面已经有六家加入了OAM的能力里了，我们也通过一些渠道跟亚马逊取得联络，因为这真的是一个行业的趋势，我们也希望他们最终加入我们。
第二块是AI硬件芯片的提供商或者模块的提供商，这个提供商除了传统的最大的芯片提供商，大家非常熟知的英伟达以为，我们有AMD、英特尔，还有新兴的创业公司。
生态系统第三部分是系统提供商，我们有最终用户，有芯片提供商，我们要设计这些系统，我们也是跟很多公司合作设计这些系统。
目前OAM的情况，我们已经有Spec0.9版，在这个月底，这一周1.0的版本会出来，0.9到1.0的改动是比较细微的，我们也感谢非常多的公司给我们很好的意见来完善我们的规范。同时在过去的几个月，我们3月份在设计这个规范的过程中，我们已经开始很芯片厂商合作推出基于OAM规范的模块或者GPU，我给大家举两个例子，第一，3月份英特尔已经公开了，基于NNP的OAM的模块。第二个是HAbana，HAbana是比较大的创业公司，他们在上周做了他们的芯片，这是基于OAM的规范，他们也推出了基于OAM规范的系统。
这是我们OAM目前的工作进展，接下来几个月工作重点会放在基于OAM的主板设计，我们会很快的做出新的OAM的产品。下面请丁瑞全继续讲一下UBB的情况。
丁瑞全：谢谢，OAM已经取得了很好的进展，已经有落地的产品可以使用了，怎么快速地把它用起来，我们需要Base Board，大规模的训练场景里我们需要更高的性能，不同的神经网络软件层面的算法和策略都有比较大的差异，有模型并行、数据并行、参数同步的方式，软件层面的因素都会影响着我们的硬件系统上的差异，对不同互联拓扑的要求也都是不一样的，我们怎么用相对比较通用的方案解决这种差异化的需求，我们需要通用的主板的规范。基于现有的服务器的基本尺寸，我们认为在一个1U的空间长度宽度里8个OAM是比较合理的，对于UBB整体的尺寸我们会定义一个标准，确保相关的系统都能够很好的兼容它。OAM之间会有比较高的互联，这种互联只是硬件层面连起来，但是软件层面协议层面上没有关系，所以它是协议无关的硬件的互联。在UBB对外的相关接口我们会采用通用的部件和连接器，去兼容外部的生态。OAM之间有很多互联，但是这些互联不管是主板用线连接起来还是外面用Cable连接起来，这些线都是线，和上层不同OAM协议之间没有太大的关系，所以我们可以构建通用的Base Board。
这种互联的拓扑比较经典的是Hybrid Cube Mesh的形式，在这个示例中8个OAM之间连接起来，每个OAM会有连接host的相关主机接口，通用的主办可以通过相互之间的互联能够实现多机的扩展能力。这样一种拓扑是为更好的带宽优化设计的。还有一个很重要的特点是这种拓扑相对比较灵活，8个OAM模块一起使用的时候可以组建多个环，硬件层面可以把所有链路最合理的利用起来。尤其是在云计算这种场景里面，当你需要不同力度的资源的拆分的时候，比如你把8个拆成2个部分或者4个部分的时候，这样的拓扑仍然可以保证不同部分之间的互联相对来说更高一点，它不是最优的，但是相对更优的，后面我会讲相关的拓扑的不足。这种架构既可以做单机的高速互联也可以做一定的可扩展性，所以它能比较好的满足大规模训练的硬件系统设计的需求。
这是一个例子，4个通用的主板，它们之间通过高速的互联连接起来，可以实现更好的扩展能力，甚至可以扩展到16个、128个甚至更多的OAM，构建大规模的训练集群。典型的例子是谷歌的TPU。第二个比较常见的拓扑是全互联的。这种拓扑情况下对AI的OAM的module有些要求，这里面任意一个module之间有相互的连接，至少每个module需要有7个以上的连接的LINK，这样互联的拓扑的好处是所有的模块之间都会直接进行通信，不需要进行转化，所以它的License是最低的，因为是全互联对称的架构，所以软件层面上比较简单，你可以任意两个卡之间做通信。这个方案和前面Hybrid Cube Mesh有限制，当你和这样的拓扑拆分的时候，分成4个卡或2个卡，不管怎么拆之间的线只有一根，前面Hybrid Cube Mesh场景里拆完在某些CASE情况下OAM还有更好的互联，小的场景下Hybrid Cube Mesh互联会有优势，当把8个AI module放在一起是最好的架构。
基于全互联的基础上也会有变体，前面的拓扑每个都是点对点的互联，在软件层面挺好用的，但是整体相对比较困难，把不同的端口汇聚起来形成更高的带宽，这样的方案采用中心式的开关放在中间，所有OAM的module都连接在这个上面去，所有module之间是可以互联起来的，并且有个中心化的交换的单元，互联带宽也非常好，但是这种方案是非常难的，如果每个OAM的module都有好几个高速互联的LINK到一个中心的开关，那么这个中心的开关将是巨大的，实际上从技术的角度来说这样的开关是很难实现的，很理想但是很难实现。在这个基础上有些进一步的变体，我们可以用多个小的开关的芯片连接到每个OAM，逻辑上它仍然是相对比较大的开关，但是在物理上它是多个小的模块汇聚起来的，所以在实现层面上相对比较简单，软件层面可以达到同样的诉求，但是在物理层面上相对会更简单一点。
除了刚才讲的Hybrid Cube Mesh全互联之外还有其他的拓扑，我们这里简单说一下。如果OAM只有6个互联的端口，在全互联的硬件的架构情况下它是缺一个LINK的，这种时候变成了不是全互联，所以这种情况下软件层面有一定的不对称性，所以对软件层面的复杂度相对比较高，这种方案应用得比较少一点。2D Mesh的拓扑，它的前后左右都可以互联起来，也可以实现多机的可拓展能力，但是相对要求比较高，在部分OAM之间的互联带宽也不是最优的。刚才讲的这些拓扑可以满足大部分场景的需求，并且在这种拓扑里面所有的OAM module都是一样的，是同构的OAM module，但是在OAM设计的过程中并不局限于此，因为OAM是标准的，在一个系统中我可以放不同的OAM的module。不同的芯片更擅长做不同的事情，如果我们将不同类型的OAM放在不同的系统中大家分工合作做自己擅长的部分，可以取得更好的效果。
现在视频+5G非常火，在AI里面如果要对视频的东西进行处理的话，第一步得先进行解码，第二步才能对它进行处理，大部分的AI芯片并不擅长做视频的解码或编解码工作，如果我们能将不同的芯片放在一个系统里面，它们之间形成流水线去协同做一个事情，整体上是最高效的。
当前我们UBB的OAM已经发布了，我们的OAI 整个Project 8个部分，现阶段集中在UBB这块，OCP社区里我们形成了sub group，需要签署相关协议才能参与相关规范的讨论和制定，目前有一些系统的厂商在参与到组织里面帮助构建基于OAM和UBB规范的参考的系统，当前UBB已经有一半的初版规范，我们希望明后两天借OCP的机会有更好的讨论，希望这个规范能尽快定版。我们目标在今年9月阿姆斯特丹的OCP会议上希望能发布这样的规范。
这是我们当前初步的方案，UBB上面有8个OAM module，板子的尺寸16.7×21英寸，这个UBB可以放在普通的19英寸的机柜也能放在21英寸的机柜，UBB OAM之间的互联是8×8的LINK，我们会采用18-24层超低损耗的板材，既能满足信号指令要求的基础也能进一步降低系统的成本。在供电方面，12V的产品里可以做到300瓦的功耗，对于48V、50V可以做到四五百瓦的供电能力。这是我们两个参考的系统设计，有一些尺寸的限制。左边是平铺式的，UBB的板子和PCIe Board在同一个尺寸上面，有些Rack并没有这样的尺寸，我们有第二种堆叠式的形态，这个图后面缺乏一个Module Board，上面是UBB的办法下面是PCIe的板子，把它互联起来可以减少尺寸的要求。
刚才分析了不同的拓扑，不同的拓扑对于不同的深度学习的负载带来的影响都是不一样的，我们对于全互联的模式能够满足更多场景的需求，基于现有的AI芯片来看这两种拓扑适应性更广泛，所以这两个拓扑将是接下来UBB规范里面重点看的两个方向。我稍微补充解释一下，UBB并不是唯一的Base Board，而是尽量universal，我们能统一的情况下尽量统一，一定的特定场景里面我们还是允许它有不同的东西存在，所以我们是在大的架构的层面上做的一定的统一，当然也可以允许有不同的东西出现，所以两个拓扑在我们UBB里面都会支持，但是其他的拓扑我们短期不会支持。在这里我号召不管你是OAM的供应商还是最终的终端用户，还是相关系统的提供商，都能够参与到我们这样一个项目里面，提出你的建议、意见和需求，确保我们做出的大家比较认可的规范能够满足更多人的需求。
接下来有请英特尔的同事给我们分享他们采用OAM规范的相关产品。
Song Kok Hang, Intel System Architect
Song Kok Hang, Intel System Architect：我的普通话说的不是很好，我跟大家介绍一下英特尔的这个项目，它是OAM项目下的一个产品，英特尔产品是符合OAM最新的标准的，它的耗电功率可以达到425瓦，它其实也可以在较低功率下进行运转的。
这一页是我们现在的这个项目，大家今天在外面英特尔的展台上可以看到，这里面会考虑到热循环的处理，用户可以根据系统需求跑一些模拟测试等等。
英特尔Nervana NNP这个系统怎么部署，首先是电压和功率的要求，40v到60v，这是功率一直到高压的部分，3.3v是低压部分，它的功率总的来说需要3400瓦，可以驱动X8的425的英特尔Nervana NNP的OAM。它不仅仅可以用于HCM的拓扑结构，它可以支持多个模式深度学习的拓扑连接，也可以做全连的状态。
如果做单机箱HCM的拓扑，我们可以看到，左边的连接图，蓝色的是PCB，红色的是内部的连接，大家可以看到图上整个线缆的连接，它是怎么样进行内部连接和外面连接的。
HCM是可以优化我们的带宽的，也可以对于训练卡做一个更好的学习，他支持多机箱的扩展，在左边大家可以看到，这是机柜里面怎么样做一个扩展的配置，所以其实就是内部连接还是一样的，外部连接会互相连接起来，从上面和下面做一个互联。
那要问了，我们到底可以支持多少的扩展能力，其实这个扩展是没有限制的，扩展到32、64甚至更多都没有问题。
在多个机柜之间它怎么做扩展，因为刚才那张图是一个机柜里不同的机箱，这个是多个Rack中间多个机箱之间的互联和扩展，大家接着前面两张图可以看的非常清楚，他们的内部继续互联，这还是一样的，机箱之间在进行互联。
这是我要跟大家分享的，谢谢。
Whitney Zhao：这是他们的OAM模块，基于英特尔的NNP的解决方案，这个会放在外面的展台，大家有兴趣可以看一下。我们也非常开心，过去的三个月很快已经有了很多的OAM的合作伙伴跟我们共同开发这个模块，目前公开的消息已经有两个，我们不便透露更多，预计明年推出更多这样的模块，这也是方便我们建立这个生态系统。
讲了这么多，我不知道大家吸收了多少，如果你真的没有空，大概记住这个Page就够了，OAI是开放服务器的基础架构，它旨在加快加速器，怎么样加快应用的解决方案。OAM是我们推出的第一个行业规范，如果你是AI芯片的设计公司，可能这个模块需要考虑一下，因为这个生态系统可能已经建立好，或者正在建立，这样有利于你的解决方案更快的被各家公司采用。
UBB的话我也非常感谢浪潮来帮我们建立这个系统，预计今年9月份会推出来三款基于不同的Rack或者不同方案的参考系统，当我们有一方推出这样的解决方案，另一方在讲有没有这个系统可以帮助我来测试和应用，9月份就有这样的系统推出来，而且是完全Open的分享给大家的。
基于这个UBB Baseboard的规范还在讨论中，我明天还在这里，我们在这边有两天的会议，希望尽快把UBB的规范制订出来，相关的像其他的电源转接板一并讨论，预计9月份推出这样的参考系统供给大家使用。
今年9月会推出我们UBB的spec，如果你是OAM加速器模块的供应商，就有这样的系统使用帮助你，像Facebook本身，我们已经有项目在进行，基于OAM系统的项目，这个项目一旦完成我们会开放到平台上。
如果你想要知道更多的信息可以关注我们的网址，每个月我会在那边发布一些最新的进展，如果你有注册我们的邮箱的话可以收到我们的进展，我们也有相关的wiki，你可以从上面了解到最新的信息和每个月开会讨论的内容，我们也有一些回复，你可以返回去听。谢谢大家！
本文属于原创文章，如若转载，请注明来源：建立异构加速器规范 OAM优化AI开发部署//server.zol.com.cn/720/7202010.html
