百度基于GPU的超大规模离散模型训练框架PaddleBox与

　　导读本文主题为基于GPU的超大规模离散模型训练框架PaddleBox和FeaBox。
　　文章包括以下几部分：
　　1。PaddleBox、FeaBox是什么
　　2。凤巢CTR模型算法及框架演进
　　3。PaddleBox：基于GPUBox的大规模离散模型训练框架
　　4。FeaBox：基于GPUBox的一体化特征抽取框架
　　5。PaddleBox、FeaBox在百度的应用情况
　　分享嘉宾焦学武百度主任架构师
　　编辑整理胡俊琪
　　出品社区DataFun
　　01hr首先介绍一下什么是PaddleBox和FeaBox
　　PaddleBox是百度打造的一个基于GPUBox的大规模离散模型训练框架。它是业界第一个能够使用全GPU去做大规模离散DNN训练的训练框架。事实上使用GPU去训练模型很常见，但是目前业界基本上都是采用GPU去做Dense模型的训练，Sparse模型因为它的规模特别大，规模通常有10个T级别，显存存不下。在百度之前还没有公司将Sparse参数放到GPU里去做GPU训练，所以目前百度是相对领先的。
　　目前PaddleBox使用一台机器GPU就可以实现千亿维特征、万维参数的模型训练。模型体积是10T级别的，目前在商业范围已经覆盖了排序和召回的所有场景。不仅单机能训练这么大的规模，而且可以通过多机去进行横向扩展，以支持更大的模型或者去处理更大的样本以及进行更快的训练，通过分布式的GPU去做加速。
　　整体来说，PaddleBox框架具有相比传统解决方案低成本、高性能、高稳定这些优势。其中低成本、高性能、高稳定主要是来源于GPU的优势，灵活易用主要是来源于PaddlePaddle开源生态。这套方案相比传统MPI的解决方案具备5～40倍性价比的提升。
　　PaddleBox框架主要是用来做大规模的DNN训练。与它配套的另一个是FeaBox框架，它也是基于GPUBox打造的一套框架，是用来做一体化的特征抽取。这套框架在业界也是属于比较领先的一个框架，它采用的是抽取和训练一体化的方式，跟PaddleBox组成一对组合，一边抽特征一边去训练模型。这样PaddleBox和FeaBox一起就可以实现用GPU既做模型训练，又做特征抽取，从而获得非常高的性价比提升。
　　02hr凤巢CTR模型算法及框架演进
　　在介绍框架之前，首先了解一下百度凤巢在CTR模型方面的一些算法以及框架的演进。
　　在国内，百度做大规模离散模型的历史是非常久远的。从百度凤巢诞生那一天起，就有非常强的离散模型特性。因为在凤巢系统之前百度是用竞价排名的系统，即所谓的价高者得，有谁出钱高就出谁的广告。但是这个对各方都是有损的。对用户来说因为相关性很低，所以用户体验会比较差。对于广告主，它可能会投放了一些广告，但展现的并不是他的目标用户。同时对于百度自身来说，也是影响营收的。因此百度凤巢从诞生的一天起，它最大的特点就是引入了广告的质量这一概念，我们希望把质量高的广告推荐出来，推荐给他所匹配的人群。
　　在2009年百度凤巢诞生最开始用的就是大规模的LR模型。LR模型是非常简单的，但是百度的LR规模特别大，能达到几百亿倍的超大规模。一直持续到2013年，都是这类的技术模式。它在算法层面上采用的是MPI并行的LBFGS算法。那之后大规模的模型带来的功能挑战给我们迭代带来比较大的困难，所以我们又开始尝试连续值DNN。在2013年开始做连续值DNN，它采用的框架是基于GPU的单机的SGD优化算法。在2014年我们又把前两阶段的工作进行了一些融合，就是大规模并离散的DNN。DNN有两方面的优势，一方面它有超大的离散能力，同时它又有DNN的深度预测能力。
　　这个时候传统的解决方案已经成为瓶颈，GPU训练不了规模太大的模型，因此当时采用的是分布式CPU的参数服务器的并行迭代算法。到目前它也是业界主流的离散DNN的训练方式。在之后，百度凤巢不断的在模型结构，还有各种算法的优化上蓬勃发展，出现了多塔DNN、序列化建模、路由网络，还有模型量化等各种各样的创新。在这个时代，我们逐渐走向了使用分布式GPU参数服务器的并行的迭代算法。分布式GPU使得我们可创新的事情越来越多，因为它的算力特别强。
　　当2014年离散DNN首次落地的时候，我们采用的是Abacus和Mio分布式的MPI的解决方案。它是我们所知道的国内非常早期的一个落地，且一落地就能够支持万亿维10TB级别的大规模离散DNN。模型的训练在架构上采用的也是分布式CPU集群的解决方案。它是分布式的，可以做模型并行把模型分散到多个CPU的节点，能支持更大的规模，同时多个节点也可以加速训练，使得我们能够并行地去处理更多样本。在参数更新上采用的是传统的TCP协议，采用低速的网络进行参数同步。如果是训练速度不够，或者说模型规模在加大，我们需要不断地进行集群的扩充。到2019年，我们开始尝试使用GPU去训练大规模离散DNN模型。我们实现了业界首次使用一台GPU服务器进行了大规模离散DNN模型的DNN的训练，当时成本也大幅降低，降低了80以上的成本。
　　在训练的组网方式上，我们当时还是采用百度凤巢一直以来的Abacus的组网方式，Abacus是我们商业部门自研的一套框架，采用C的方式去自己构建。同时百度因为在不断建设和推广Paddle生态，所以在2020年我们又开始做PaddleBox。在这个过程中，我们主要做两方面的工作：一方面是性能和规模方面的工作，我们不断对框架进行性能优化，对异构参数服务器不断优化，进一步大幅提升了性能。同时我们也可以支持更大的样本量以及更大规模的模型。另一方面我们又深度融合入Paddle开源生态，给开源生态去做各种贡献，协助Paddle团队优化框架，同时给业务部门也带来了非常实际的一些收益，使得我们的开发效率大幅的提升，可以不断引入Paddle里面各种各样的开源算法，并且通过Paddle里python实现op的主要方式，我们的算法创新更快。同时2020年我们也开始做FeaBox，并开始落地，目前在凤巢已经有很多的落地。这个时候我们就实现了FeaBox和PaddleBox在一台GPU服务器上去做一体化的特征以及训练，同时我们也支持通过多台机器去进行线性加速。
　　以上就是我们的演进路线。
　　03hrPaddleBox：基于GPUBox的大规模离散模型训练框架
　　接下来介绍PaddleBox框架。
　　先来介绍一下百度的大规模离散模型的业务背景。凤巢从模型诞生以来，特征的体积就特别大。目前我们了解到各个互联网广告的业务，总体上其Sparse模型一般也都是非常大的，通常都是T级别的。百度到了10TB级别，有千亿特征。经统计，我们特征占比量比较高，是因为广告场景有各种各样的ID类特征，包括广告ID、用户ID、物料ID，以及这些ID的组合，因此会特别大。比如用户ID可能就是10亿维的，广告ID可能也有类似量级，再结合queryterm的维度去做组合特征，很容易就会达到百亿维，加上各种各样的特征，就会到千亿维的规模。同时每一维特征又会有1维到64维的这样更高维度的表征，所以参数量会在万亿维规模之上。
　　大规模离散模型最大的特点就在于它的离散模型特别大。反而Dense是一个比较常见的普通类似全连接网络的网络，Dense数量级要比Sparse要小很多。我们之前一直采用的都是和业界相似的解决方案，都是基于大规模分布式MPI集群的解决方案。上图是目前业界常采用的一个经典的参数服务器的架构。我们之前在百度内部也有这套解决方案，比如Abacus，以及PaddlePaddle开源的PSlib也是这样一种架构。
　　这套架构的价值非常大，它是第一个训练大部分离散DNN的解决方案。通过把稀疏参数分散多个存储节点实现了模型的并行。同时把样本也分散到多个计算节点上，实现了数据的并行。但是这套架构也存在不足，体现在几个方面：
　　（1）首先训练性能上，因为使用的是CPU做训练，所以算力有限，无法支持现在各种各样的复杂模型算法，模型算法一复杂，速度就不够。所以多年来，在大规模离散模型的组网上，变式并不多，没有办法去设计复杂的网络。不仅单机算力不够，也很难通过规模的扩容而提升性能。因为它主流的使用方式上通常都是百台左右或者是200台左右这样的规模去做模型训练。一方面它集训规模的增长无法在性能上做到线性增长，边界效益获得的速度不一定快。另外会有更严重的一个问题，节点过多，有严重的梯度过期的问题。我们曾经测试过，当MPI节点规模大于200个以上，它的梯度过期就很严重了，开始影响效果。如果大于500个节点以上，那效果基本是不可接受的。
　　（2）稳定性方面，既然用MPI集群一定意味着它的集群要有一定的规模才能训得动，那这里就存在稳定性的问题。比如一台机器，它的稳定率要求是999，但是999是一个很高的数字了，我们并不能保证所有的场景都有这么高的数字，即使它能够满足这个要求，那如果我们使用200个节点，任务挂掉的概率是非常高的，有18的概率，任务还是会挂掉。
　　（3）另外一个问题是成本。有一定规模的公司，在模型训练方面的资源投入都在数万台以上。大家都在采用分布式CPU解决方案的时候，在其他的一些领域就不断地开始一些新的硬件。新的硬件迎来了非常快速的发展。首先在GPU的性能上，早期的K40到最新的A100，GPU的性能增长150倍；在显存容量上，从K40的十几个G增长到了A100的80G，增长了7倍。NVLink，GPU互联的带宽上也有10倍的增长。在GPU的硬件、性能、容量、带宽山都有大幅的提升。同时在其它一些存储介质上，有多种选择。比如最大的有硬盘，最小的有各种的GPU的Cache，看起来速度非常高，但是它的容量比较小，大的存储像SSD只有几个T。所以我们在存储阶段上也有越来越多选择，我们可以权衡性能，去选一个合适的介质。同时在多机方面，机器和机器之间的带宽也增长非常快。因此新硬件的发展使得GPU加速成为AI行业的趋势，包括语言、图像、NLP等各种各样的领域，已经全面落地。但是GPU在大规模离散场景还没有，没有人去用GPU去处理大规模稀疏模型这样的事情。所以我们就提出希望能够打造一个PaddleBox（它的前身叫AIbox）以及FeaBox这样的框架，用GPU去做大规模离散模型训练，并且保证高性能、高稳定、低成本。
　　但我们面临着一些挑战，其中最核心的就是大规模离散场景的巨大模型。
　　（1）第一个是存储挑战，万亿维参数体积，会有10TB级别的正量级。我们要使用GPU做训练的话，首先要把这个模型存进来。GPU我们最开始用的是V100，V100的单卡显存只有32G，两者相差了三个数量级，所以存储挑战特别大，这也是做整个事情大的前提。
　　（2）第二是性能挑战，一方面我们知道GPU是非常擅长矩阵训练的，它的计算能力主要是体现在矩阵计算的场景。但是稀疏模型，它主要的处理逻辑都是在做稀疏特征的处理。矩阵运算，比如最大的70以上操作，包括稀疏参数的查询更新，以及从稀疏到稠密模型的转换，还有各种各样的样本处理，这些操作并不是GPU所擅长的。如果用GPU能否获得我们所希望的收益，这是第二个挑战。
　　（3）第三个是通信挑战，如果使用GPU就不可能像CPU那样用上百台机器去做训练，成本太高了，而且也不一定会有很大的性能提升。因此给我们带来了通信方面的一些挑战，包括样本处理上骤降的网卡数。原来我们100台机器有100张网卡，但是现在如果用一台机器，就只有一张网卡，能否支持海量样本的读取需求是一个巨大的挑战。另外在模型训练上，单节点就要承担非常大的通信量，而且我们的通信数据都是一些稀疏特征，而不是稠密向量。所以很难去用GPU的AllReduce或者AllGather通信模式。所以在通信方面上我们一定是要做很多事情去适配我们的场景。
　　百度在这方面还是有一些优势的，我们是最早采用大规模离散模型去做业务的广告系统，因此我们在硬件方面有很多积累。
　　我们的基础架构部研发了XMan百度超级计算机，从2016年至今已经迭代了四个大的版本，它是PaddleBox和AIBox的硬件基础。在2016年就诞生了XMan1。0，它有很高的计算密度。在2017年，XMan2。0又支持了更高的散热效率，包括风冷夜冷等多种散热模式。2018年推出了XMan3。0，早期的PaddleBox、AIBox版本就是基于XMan3。0去做的。3。0是一种双层的设计，是CPU节点和GPU的服务器一种结构的设计，方便我们去做CPU和GPU的合理配比。在XMan4。0上这个架构实现了超融合的一些操作设计，实现了更加灵活的异构硬件配比。这里就不仅是CPU和GPU的灵活配比，包括一些绑卡的灵活配比还有SSSD的灵活配比。还有PCIE布线方面也可以做灵活的调整。
　　所以，我们要做一个极致的训练框架，一定是软硬结合的非常紧密的方式，既要去根据硬件结构去做软件的设计，同时从软件反过来又去建议硬件的改造，硬件基础是我们去做高性能的一个大的前提。
　　我们在做这套系统的过程中，主要经历了几方面的工作。
　　首先是实现了一个单机的方案，核心点是打造一个异构的层次化的参数服务器。这一套方案实现了一台GPU单机八卡就可以实现10TB级别模型的训练。整体方案如上图所示，是一个三层的参数服务器的架构，最底下的是SSD的参数服务器，中间层是内存的参数服务器，上层是分布式的GPU稀疏参数服器。这里面临的最大挑战就是存储，针对存储我们做了两个工作：
　　（1）一个是实现了业界第一个分布式的GPU稀疏参数服务器，以及业界第一个SSD的超大的稀疏参数服务器。另外，三层参数服务器之间可以实行自动化的协同，使得容量提升了两个数量级。我们这套架构，使得我们的参数服务器既获得了容量又获得了性能。我们用了各种方法优化SSD的性能，最后把SSD的性能提升到了理论瓶颈，即单卡3GB。
　　（2）第二个工作是，既然是一个分布式的GPU参数服务器，那它一定涉及到很高频的通信，所以我们对通信的效率要求就特别高。我们提出了两种解决方案，首先是在XMan2。0机型上，我们实现了软件创新。上图右边是XMan2。0硬件的布局示意图。这套架构存在的一个问题是GPU并不是一个全互联的组件架构，早期并不是所有的GPU之间都是有高速的NVLink链路的。比如我们再接8张卡来看，可以看0号的网卡，这张GPU卡跟123都是有直接的NVLink链路的，所以这个通信性能还是非常快的。但是它跟5号网卡之间因为没有直连，所以当它们两个之间发送数据包的时候，会通过CPU节点去发送，也就是说从0号节点走红色的PCIE的链路，然后发送到CPU1，然后CPU1再通过QPI链路走到了CPU0，再从PCIE才能走到GPU5。GPU的算力是非常强的，但是在这个通信的过程中，要走低速的PCIE以及QPI的通信，性能就非常差了。因为PCIE的带宽只有16G但NVlink的带宽有300G，所以整体性能就没有办法去发挥。所以我们做了两跳通信的方案，就是在GPU卡之间做P2P通信的时候，从来都不使用PCIE和QPI，我们实现了所有的GPU节点之间通过NVLink。这个方案使我们的交互的性能提升了七倍。
　　后期基于需求，硬件又引入了NVSwitch全互联的架构，从硬件层面就实现了GPU之间PC的高度空间，使性能得到进一步的提升。这个点是我们融入在XMAN3。0的机型上。在其他方面我们也做了这样的软硬一体的优化，我们会参考硬件的布局去做各种优化，比如在绑核方面，我们就做了跟传统的CPU解决方案完全不一样的策略。
　　尽管GPU已经足够快，但是我们还是希望它能够有更加好的扩展方式。所以我们也要实现一个多机方案，以支持更大的场景、更大的样本以及更快的训练。
　　事实上我们还没有碰到无法处理的规模，因为单机已经能够处理10TB，多机可以处理几十TB甚至上百TB的模型。在多机的方案上，我们主要考虑的是两个点，首先是要做模型并行，因为我们要支持几十T甚至上百T的这样的模型，所以要做模型分库，把稀疏参数分割到多台的PaddleBox上。包括两个层面，一个是SSD要支持多机，还有一个层面就是说GPU也要支持多机。同时我们还要求在不同的机器之间参数和参数要保证完全一致性，这也是模型的一个要求。当然在这方面，从策略角度，GPU还是比CPU要有更高的优势的。因为采用GPU我们可以用AllReduce这类的同步训练，分布式CPU只能做异步训练，同步训练可以获得更好的一个策略效果。所以我们还要做好参数同步。
　　这里还是有比较大挑战的，因为机器和机器之间以及GPU之间需要进行超高频的通信，我们要与其计算能力相匹配，计算能力非常强，所以要求通信的能力也非常强。有了基本的方案之后，我们要解决的最大的挑战就是通信的挑战。我们在机器之间的通信方面做了很多工作，比较核心的一个通信方面的创新是，既然要用GPU做高速通信，那我们从硬件上影响就要升级网卡拓扑不能采用传统的CPU通过CPU的TCP通信，显然不能满足我们GPU的高算力的需求。升级的网卡拓扑，在GPU上直接安装网卡在多机的GPU之间直接进行高速通信，使得我们的通讯性能提升了一个发展级，就是在工程上实现了一些通信方的工作。同时在算法上我们要降低通信数据量。我们在一台机器内多卡之间去进行梯度聚合，在多台机器之间又进行了量化通信，数据量又降低了原来的14。
　　另外我们还做了大量的软硬协同的性能优化，包括流水线架构。大的架构上我们要让样本读取、样本解析、参数拉取和模型训练组成一个大的流水线。在每一个大流水线的每一个阶段内部我们又做了系列的小的流水线。这样我们可以实现网卡、CPU、GPU还有SSD异构硬件的最大化的并行。在硬件层面我们协同基础架构去进行CPU、GPU、SSD网卡布局的最优化的设计，使得我们能够得到一个极致的性能。
　　上图是PaddleBox目前的整体架构，刚才我们介绍的主要是参数服务器部分。我们把三层异构的参数服务器抽象成了一个BoxPS组件，去深度融合到了PaddlePaddle，成为PaddlePaddle的核心组件。同时我们基于PaddlePaddle又实现了一系列广告相关的业务框架，并且目前已经全面落地。同时借助PaddlePaddle开源生态，也为广告业务做到了很好的赋能。
　　04hrFeaBox：基于GPUBox的一体化特征抽取框架
　　接下来介绍一下我们的特征处理框架FeaBox的工作。
　　特征调研是一个非常重要的工作。我们需要从海量的数据中提取优质的样本，去做模型训练来获取策略的收益。所以抽取特征也是测试创新的基础，它的需求也是非常频繁的。通常我们做一次模型迭代，要做几十次的调研才能最终实现一个全量。中间可能几次调研才能够实现一个小流量，几次的小流量最后才能实现一次置信的收益。
　　因此特征调研也是模型迭代的一个重要方向。目前在百度包括搜索广告和推荐广告，在特征的优化方面都有比较高的投入度。业内主要采用的是两阶段的调研模式。早期我们也是这样的一种调研模式：通常采用MR去做特征抽取，从原始日志经过几轮MR的处理，产生原始样本，把原始样本写入到用HDFS，再启动一个训练任务。训练任务从集群去读取训练样本，产出模型，模型又存到HDFS上。
　　这套方案有几个方面的不足：首先，任务是割裂的模式，一个是训练任务，一个是推动任务，其间是没有关系的，应用性上是有问题的。同时MR的性能也存在问题。另外还需要占用大量的样本存储。所以我们就提出一个思路，要做一个一体化的方案，也就是FeaBox与PaddleBox联合的模式。
　　上图上面是我们原来的解决方案，内部系统叫ADT，后来又演进到瓦利，瓦利是在ADT基础上避免了很多的重复计算，后来又实现流式的瓦利一直迭代到现在的FeaBox。我们早期的两阶段模式，跟业界是类似的。但我们有一些改进：在基线方面，有基线的复用，就是从全量做一基线，然后从原始样本去投增量。这里会有非常大的IO，即便不是最大的场景，一天中HDFS相关的中间数据，IO也有200T。也有15T以及4T上原始数据的读取。同时我们在特征任务和训练任务中间还需要清除十几T的样本，这是传统的解法。
　　我们最终实现了以下解决方案：
　　一个是在原始读上采用了增量调研，只是增量读列分。在这一块的读取上，我们从原始40TB原始数据的读取直接降低到了500G的增量数据的读取，所以降低了95以上的IO。在中间数据上我们将以前的MR又改成了流式计算的方式，所以中间的IO也都去掉了。因此基线的复用就是增量的读取以及流式的计算，使得我们的IO大幅的降低。同时流式计算也大幅的优化了性能。另外因为我们采用一体化的方式，所以存储也降到了0。因为我们在GPUBox去完成，所以我们打造了一套异构的特征抽取的框架，支持CPU和GPU混合的去做特征抽取，发挥算力优势。最终我们在调研时，从原来的天级才能看到效果，变成了分钟级就能看到效果，提交一个任务几分钟之后我们就能看到AUC的产出。同时相比以前的训练，性能也提升了5到10倍，存储资源直接降到零。
　　这里涉及的技术比较多，我们主要还是来讨论GPU方面的一些工作。我们要使用GPU去做特征抽取，首先要实现一套异构的调度方案。因为并不是所有的算子都是GPU的。一方面，我们可能有一些算子不是那么的重，用非GPU是OK的，所以我们不希望所有的算子都必须有一个GPU的实现；从迭代的角度并不是一个方面的事情，所以我们希望能够既支持CPU又支持GPU，要实现一套异构的调度方案。如图所示，我们异构的调度方式经历了几个发展阶段。我们首先将原始的函数调用的特征处理方式变成了节点依赖的方式。进一步我们又对节点进行分层，来加大我们的并行异构调度的过程。
　　首先我们要做数据的准备，把原始的日志数据从CPU拷贝到GPU，然后在GPU内部去做裁剪和列存储。我们希望尽量多的操作在GPU完成，因为GPU算力明显更强。同时我们要做一个高效的边界的调度。这里主要体现几个方面：一是我们要做一个好的、依据我们的DAG的拓扑实现分层调度。并且在同层之内，我们要尽量使得CPU和GPU去并行。在同一层内，我们首先去异步的调度GPU节点，让他去做GPU操作。再同步去调用CPU节点，使得我们在GPU和GPU这两硬件之间去并行。另外对于GPU这些节点，同层的GPU节点，我们还又会做KernelFusion来减小Launch的开销。最后在GPU透传之后，再把它的结果列转行，转到CPU的内部，最后弹出数据。
　　另外一个比较重要的工作是提高显存分配的效率。因为我们的特征是特别多的，每天有几亿到几十亿的样本，样本量特别大。而且还有一个特点是样本的长度变化非常大，所以我们并不能够直接使用GPU平时的显存分配方式，因为GPU能够处理的都是定长的数据，但如果用定长数据，显存消耗非常大。
　　加入两条数据，一条数据可能长度只有几十个字节，另一条数据可能是1k，如果都按最大长度去申请，那么显存需求显然是不可能满足要求的，而且流量也特别大。同时为了满足GPU高计算能力相匹配，显存分配的性能要求非常高。而且在显存分配的布局上，要能够支持扩大显存的高效访问。所以我们要满足仿真合并的需求。我们实现了动态的显存分配的方案。
　　整体思路是要构造一个显存池，并且在显存池上要进行分层。我们从扩大线程级别，将原来的线程级别降级到了block级别的线程，来减轻操作的频率。同时我们要借助cuda并行的计算能力来加速显存的分配。
　　05hrPaddleBox、FeaBox在百度的应用情况
　　最后介绍PaddleBox和FeaBox在百度内的应用情况，FeaBox和PaddleBox以及AIBox目前在百度广告已经全面的落地了，已经落地到百度的凤巢原生和百青藤所有的业务场景。这里面凤巢指的是我们的信息流广告，百青藤对应的是我们的联盟广告。同时我们支持了多种多类模型，包括点击率模型、转化率模型，还有召回模型能力，并且产生了很好的业务价值。从训练资源上，性价比相比传统的解决方案是提升了5到40倍的。因为不同的模型场景，我们的优势也是不一样的，模型越复杂，我们的优势会越大。同时我们也提供了更大的策略创新空间。
　　刚开始也提到分布式CPU并没有办法去支持我们复杂的模型。那么在GPU和Paddle的灵活性加持之下，策略可操作的空间越来越多。现在我们商业这边的策略已经不仅仅是早期的全连接模型，而是将各种各样的，比如Attention、Ernie、甚至CNN都已经引入到了点击率预估。所以GPU算子和PaddlePaddle的结合为我们的商业系统提供了一个更大的策略空间。另外我们的这一套框架目前也不仅仅在广告场景发挥作用，在其他一些场景也逐渐的去做了一些落地。
　　最后，欢迎有兴趣的同学加入我们，一起去探讨。
　　以上就是今天分享的内容，谢谢大家。
　　分享嘉宾