导读 本文主题为基于 GPU 的超大规模离散模型训练框架 PaddleBox 和 FeaBox。
文章包括以下几部分：
1. PaddleBox、FeaBox是什么
2. 凤巢 CTR 模型算法及框架演进
3. PaddleBox：基于 GPUBox 的大规模离散模型训练框架
4. FeaBox：基于 GPUBox 的一体化特征抽取框架
5. PaddleBox、FeaBox 在百度的应用情况
分享嘉宾｜焦学武 百度 主任架构师
编辑整理｜胡俊琪
出品社区｜DataFun
01
首先介绍一下什么是 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 既做模型训练，又做特征抽取，从而获得非常高的性价比提升。
--
02
凤巢 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 的解决方案。它是我们所知道的国内非常早期的一个落地，且一落地就能够支持万亿维 10 TB 级别的大规模离散 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 服务器上去做一体化的特征以及训练，同时我们也支持通过多台机器去进行线性加速。
以上就是我们的演进路线。
--
03
PaddleBox：基于 GPUBox 的大规模离散模型训练框架
接下来介绍 PaddleBox 框架。
先来介绍一下百度的大规模离散模型的业务背景。凤巢从模型诞生以来，特征的体积就特别大。目前我们了解到各个互联网广告的业务，总体上其 Sparse 模型一般也都是非常大的，通常都是 T 级别的。百度到了 10 TB 级别，有千亿特征。经统计，我们特征占比量比较高，是因为广告场景有各种各样的 ID 类特征，包括广告 ID 、用户 ID 、物料 ID ，以及这些 ID 的组合，因此会特别大。比如用户 ID 可能就是 10 亿维的，广告 ID 可能也有类似量级，再结合 query term 的维度去做组合特征，很容易就会达到百亿维，加上各种各样的特征，就会到千亿维的规模。同时每一维特征又会有 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 （它的前身叫 AI box ）以及 FeaBox 这样的框架，用 GPU 去做大规模离散模型训练，并且保证高性能、高稳定、低成本。
但我们面临着一些挑战，其中最核心的就是大规模离散场景的巨大模型。
（1）第一个是存储挑战，万亿维参数体积，会有 10 TB 级别的正量级。我们要使用 GPU 做训练的话，首先要把这个模型存进来。GPU 我们最开始用的是 V100，V100 的单卡显存只有 32G，两者相差了三个数量级，所以存储挑战特别大，这也是做整个事情大的前提。
（2）第二是性能挑战，一方面我们知道 GPU 是非常擅长矩阵训练的，它的计算能力主要是体现在矩阵计算的场景。但是稀疏模型，它主要的处理逻辑都是在做稀疏特征的处理。矩阵运算，比如最大的 70% 以上操作，包括稀疏参数的查询更新，以及从稀疏到稠密模型的转换，还有各种各样的样本处理，这些操作并不是 GPU 所擅长的。如果用 GPU 能否获得我们所希望的收益，这是第二个挑战。
（3）第三个是通信挑战，如果使用 GPU 就不可能像 CPU 那样用上百台机器去做训练，成本太高了，而且也不一定会有很大的性能提升。因此给我们带来了通信方面的一些挑战，包括样本处理上骤降的网卡数。原来我们 100 台机器有 100 张网卡，但是现在如果用一台机器，就只有一张网卡，能否支持海量样本的读取需求是一个巨大的挑战。另外在模型训练上，单节点就要承担非常大的通信量，而且我们的通信数据都是一些稀疏特征，而不是稠密向量。所以很难去用 GPU 的 AllReduce 或者 AllGather 通信模式。所以在通信方面上我们一定是要做很多事情去适配我们的场景。
百度在这方面还是有一些优势的，我们是最早采用大规模离散模型去做业务的广告系统，因此我们在硬件方面有很多积累。
我们的基础架构部研发了 XMan 百度超级计算机，从 2016 年至今已经迭代了四个大的版本，它是 PaddleBox 和 AIBox 的硬件基础。在 2016 年就诞生了 XMan 1.0，它有很高的计算密度。在 2017 年，XMan 2.0 又支持了更高的散热效率，包括风冷夜冷等多种散热模式。2018 年推出了 XMan 3.0，早期的 PaddleBox、 AIBox 版本就是基于 XMan 3.0 去做的。3.0 是一种双层的设计，是 CPU 节点和 GPU 的服务器一种结构的设计，方便我们去做 CPU 和 GPU 的合理配比。在XMan 4.0 上这个架构实现了超融合的一些操作设计，实现了更加灵活的异构硬件配比。这里就不仅是 CPU 和 GPU 的灵活配比，包括一些绑卡的灵活配比还有 SSSD 的灵活配比。还有 PCIE 布线方面也可以做灵活的调整。
所以，我们要做一个极致的训练框架，一定是软硬结合的非常紧密的方式，既要去根据硬件结构去做软件的设计，同时从软件反过来又去建议硬件的改造，硬件基础是我们去做高性能的一个大的前提。
我们在做这套系统的过程中，主要经历了几方面的工作。
首先是实现了一个单机的方案，核心点是打造一个异构的层次化的参数服务器。这一套方案实现了一台 GPU 单机八卡就可以实现 10 TB 级别模型的训练。整体方案如上图所示，是一个三层的参数服务器的架构，最底下的是 SSD 的参数服务器，中间层是内存的参数服务器，上层是分布式的 GPU 稀疏参数服器。这里面临的最大挑战就是存储，针对存储我们做了两个工作：
（1）一个是实现了业界第一个分布式的 GPU 稀疏参数服务器，以及业界第一个 SSD 的超大的稀疏参数服务器。另外，三层参数服务器之间可以实行自动化的协同，使得容量提升了两个数量级。我们这套架构，使得我们的参数服务器既获得了容量又获得了性能。我们用了各种方法优化 SSD 的性能，最后把 SSD 的性能提升到了理论瓶颈，即单卡 3GB。
（2）第二个工作是，既然是一个分布式的 GPU 参数服务器，那它一定涉及到很高频的通信，所以我们对通信的效率要求就特别高。我们提出了两种解决方案，首先是在 XMan2.0 机型上，我们实现了软件创新。上图右边是 XMan 2.0 硬件的布局示意图。这套架构存在的一个问题是 GPU 并不是一个全互联的组件架构，早期并不是所有的 GPU 之间都是有高速的 NVLink 链路的。比如我们再接 8 张卡来看，可以看 0 号的网卡，这张 GPU 卡跟 123 都是有直接的 NVLink 链路的，所以这个通信性能还是非常快的。但是它跟 5 号网卡之间因为没有直连，所以当它们两个之间发送数据包的时候，会通过 CPU 节点去发送，也就是说从 0 号节点走红色的 PCIE 的链路，然后发送到 CPU 1，然后 CPU 1 再通过 QPI 链路走到了 CPU 0，再从 PCIE 才能走到 GPU 5。GPU 的算力是非常强的，但是在这个通信的过程中，要走低速的 PCIE 以及 QPI 的通信，性能就非常差了。因为 PCIE 的带宽只有 16G 但 NVlink 的带宽有 300G，所以整体性能就没有办法去发挥。所以我们做了两跳通信的方案，就是在 GPU 卡之间做 P2P 通信的时候，从来都不使用 PCIE 和 QPI ，我们实现了所有的 GPU 节点之间通过 NVLink。这个方案使我们的交互的性能提升了七倍。
后期基于需求，硬件又引入了 NVSwitch 全互联的架构，从硬件层面就实现了 GPU 之间 PC 的高度空间，使性能得到进一步的提升。这个点是我们融入在 XMAN 3.0 的机型上。在其他方面我们也做了这样的软硬一体的优化，我们会参考硬件的布局去做各种优化，比如在绑核方面，我们就做了跟传统的 CPU 解决方案完全不一样的策略。
尽管 GPU 已经足够快，但是我们还是希望它能够有更加好的扩展方式。所以我们也要实现一个多机方案，以支持更大的场景、更大的样本以及更快的训练。
事实上我们还没有碰到无法处理的规模，因为单机已经能够处理 10 TB ，多机可以处理几十 TB 甚至上百 TB 的模型。在多机的方案上，我们主要考虑的是两个点，首先是要做模型并行，因为我们要支持几十 T 甚至上百 T 的这样的模型，所以要做模型分库，把稀疏参数分割到多台的 PaddleBox 上。包括两个层面，一个是 SSD 要支持多机，还有一个层面就是说 GPU 也要支持多机。同时我们还要求在不同的机器之间参数和参数要保证完全一致性，这也是模型的一个要求。当然在这方面，从策略角度，GPU 还是比 CPU 要有更高的优势的。因为采用 GPU 我们可以用 AllReduce 这类的同步训练，分布式 CPU 只能做异步训练，同步训练可以获得更好的一个策略效果。所以我们还要做好参数同步。
这里还是有比较大挑战的，因为机器和机器之间以及 GPU 之间需要进行超高频的通信，我们要与其计算能力相匹配，计算能力非常强，所以要求通信的能力也非常强。有了基本的方案之后，我们要解决的最大的挑战就是通信的挑战。我们在机器之间的通信方面做了很多工作，比较核心的一个通信方面的创新是，既然要用 GPU 做高速通信，那我们从硬件上影响就要升级网卡拓扑不能采用传统的 CPU 通过 CPU 的 TCP 通信，显然不能满足我们 GPU 的高算力的需求。升级的网卡拓扑，在 GPU 上直接安装网卡在多机的 GPU 之间直接进行高速通信，使得我们的通讯性能提升了一个发展级，就是在工程上实现了一些通信方的工作。同时在算法上我们要降低通信数据量。我们在一台机器内多卡之间去进行梯度聚合，在多台机器之间又进行了量化通信，数据量又降低了原来的1/4。
另外我们还做了大量的软硬协同的性能优化，包括流水线架构。大的架构上我们要让样本读取、样本解析、参数拉取和模型训练组成一个大的流水线。在每一个大流水线的每一个阶段内部我们又做了系列的小的流水线。这样我们可以实现网卡、CPU、GPU 还有 SSD 异构硬件的最大化的并行。在硬件层面我们协同基础架构去进行 CPU、GPU、SSD 网卡布局的最优化的设计，使得我们能够得到一个极致的性能。
上图是 PaddleBox 目前的整体架构，刚才我们介绍的主要是参数服务器部分。我们把三层异构的参数服务器抽象成了一个 BoxPS 组件，去深度融合到了 PaddlePaddle，成为 PaddlePaddle 的核心组件。同时我们基于 PaddlePaddle 又实现了一系列广告相关的业务框架，并且目前已经全面落地。同时借助 PaddlePaddle 开源生态，也为广告业务做到了很好的赋能。
--
04
FeaBox：基于 GPUBox 的一体化特征抽取框架
接下来介绍一下我们的特征处理框架 FeaBox 的工作。
特征调研是一个非常重要的工作。我们需要从海量的数据中提取优质的样本，去做模型训练来获取策略的收益。所以抽取特征也是测试创新的基础，它的需求也是非常频繁的。通常我们做一次模型迭代，要做几十次的调研才能最终实现一个全量。中间可能几次调研才能够实现一个小流量，几次的小流量最后才能实现一次置信的收益。
因此特征调研也是模型迭代的一个重要方向。目前在百度包括搜索广告和推荐广告，在特征的优化方面都有比较高的投入度。业内主要采用的是两阶段的调研模式。早期我们也是这样的一种调研模式：通常采用 MR 去做特征抽取，从原始日志经过几轮 MR 的处理，产生原始样本，把原始样本写入到用 HDFS，再启动一个训练任务。训练任务从集群去读取训练样本，产出模型，模型又存到 HDFS 上。
这套方案有几个方面的不足：首先，任务是割裂的模式，一个是训练任务，一个是推动任务，其间是没有关系的，应用性上是有问题的。同时 MR 的性能也存在问题。另外还需要占用大量的样本存储。所以我们就提出一个思路，要做一个一体化的方案，也就是 FeaBox 与 PaddleBox 联合的模式。
上图上面是我们原来的解决方案，内部系统叫 ADT，后来又演进到瓦利，瓦利是在 ADT 基础上避免了很多的重复计算，后来又实现流式的瓦利一直迭代到现在的 FeaBox。我们早期的两阶段模式，跟业界是类似的。但我们有一些改进：在基线方面，有基线的复用，就是从全量做一基线，然后从原始样本去投增量。这里会有非常大的 IO，即便不是最大的场景，一天中 HDFS 相关的中间数据，IO 也有 200T。也有 15T 以及 4T 上原始数据的读取。同时我们在特征任务和训练任务中间还需要清除十几 T 的样本，这是传统的解法。
我们最终实现了以下解决方案：
一个是在原始读上采用了增量调研，只是增量读列分。在这一块的读取上，我们从原始 40 TB 原始数据的读取直接降低到了 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 并行的计算能力来加速显存的分配。
--
05
PaddleBox、FeaBox 在百度的应用情况
最后介绍 PaddleBox 和 FeaBox 在百度内的应用情况，FeaBox 和 PaddleBox 以及 AI Box 目前在百度广告已经全面的落地了，已经落地到百度的凤巢原生和百青藤所有的业务场景。这里面凤巢指的是我们的信息流广告，百青藤对应的是我们的联盟广告。同时我们支持了多种多类模型，包括点击率模型、转化率模型，还有召回模型能力，并且产生了很好的业务价值。从训练资源上，性价比相比传统的解决方案是提升了 5 到 40 倍的。因为不同的模型场景，我们的优势也是不一样的，模型越复杂，我们的优势会越大。同时我们也提供了更大的策略创新空间。
刚开始也提到分布式 CPU 并没有办法去支持我们复杂的模型。那么在 GPU 和 Paddle 的灵活性加持之下，策略可操作的空间越来越多。现在我们商业这边的策略已经不仅仅是早期的全连接模型，而是将各种各样的，比如 Attention 、Ernie、甚至 CNN 都已经引入到了点击率预估。所以 GPU 算子和 PaddlePaddle 的结合为我们的商业系统提供了一个更大的策略空间。另外我们的这一套框架目前也不仅仅在广告场景发挥作用，在其他一些场景也逐渐的去做了一些落地。
最后，欢迎有兴趣的同学加入我们，一起去探讨。
以上就是今天分享的内容，谢谢大家。
｜分享嘉宾｜
版权声明：本文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不做权威认证，不拥有所有权，不承担相关法律责任，转载请注明出处。本文地址：https://www.sip-server.cn/103266.html
