网站管理建设的总结,wordpress主题 google,重庆网站建设培训机构,佛山企业自从BERT诞生以来#xff0c;各大互联网巨头之间就展开了预训练语言模型军备竞赛#xff0c;XLNet、ERNIE、RoBERTa、T5、GPT-3....但当事情进展到号称自己是zero-shot learner的GPT-3时#xff0c;批判的声音变得明显多了。这么大#xff0c;能用吗#xff1f;真的能做到… 自从BERT诞生以来各大互联网巨头之间就展开了预训练语言模型军备竞赛XLNet、ERNIE、RoBERTa、T5、GPT-3....但当事情进展到号称自己是zero-shot learner的GPT-3时批判的声音变得明显多了。这么大能用吗真的能做到zero-shot吗领域外泛化不行啊...小学数学题都解不好GPT-3生成的内容侵犯了我的隐私我魔改下BERT就能小样本学习上吊打它啊...生成的内容不合逻辑...给出的医疗建议不靠谱很多人开始质疑一味的让模型变大、让参数量爆炸式增长真的能带来真正的语言智能吗但不可否认的是GPT-3做到了许多早期预训练模型做不到、做不好的事情如故事生成、文本-结构生成、Closed-book QA等相比GPT-2这个千亿参数规模的语言模型不仅生成的文本更流畅了甚至内容的事实性也有了显著的改善。但归根结底GPT-3的零样本和小样本学习能力主要还是来源于预训练阶段对海量语料的大量记忆其次是语义编码能力、远距离依赖关系建模能力和文本生成能力的强化以及自然语言进行任务描述等设计。而在训练目标/损失函数方面GPT-3并没有显式的引导模型去学习零样本/小样本泛化能力因此在一些互联网上公开较少的语料如一些toB场景上GPT-3经常出现翻车也是可以理解的。那么问题来了如果我们将语言模型的规模从千亿提升至万亿能不能复现GPT-3创造的奇迹呢我觉得这个问题要从目标来看。举个例子。假如你的目标是要解决网友吐槽的“GPT-3小学数学题都解不好”的问题那训万亿参数模型绝对是个不能更错误的路线这类不可枚举的数值计算问题需要专用的设计靠增加数据量和模型容量只能解决更多数值计算的特定输入而永远无法真正像计算机那样建立起稳定的函数关系。但是如果你确信你的目标场景数据分布是在互联网上存在且公开的或者你能通过某种渠道得到海量同分布或近分布数据那么你去训一个万亿参数的模型是确实可能产生进一步肉眼可见的飞跃。再或者你仅仅想要模型会解更多fancy的任务以及对同一个任务能在开放域解更多的case那去提升规模确实有意义的。而在一些影响因素更加繁杂的任务如推荐、广告点击率预估、搜索等特征维度高达千亿、万亿更是非常合理的事情毕竟这些工业界产品端不仅坐拥海量用户交互数据且无论用户侧还是物料侧均是一个足够大、足够复杂的开放域问题怎么拟合都不为过。那问题来了比拼语言模型规模这件事情难道没个上限吗数据瓶颈算力瓶颈分布式训练技术瓶颈数据数据怎么成瓶颈啦这不是个信息爆炸的时代吗没错信息是爆炸的但互联网上大量数据是dirty、重复、无意义的而在移动互联网时代互联网也变得越来越封闭要连接起一座座信息孤岛极其困难。对模型训练来说需要的不仅是数据绝对规模数据来源的丰富度和干净程度同样是模型能力的天花板。因此在数据层面没有相比上一代模型取得质的飞跃的情况下近期那些去训千亿、万亿参数语言模型的工作基本就是在烧钱赚吆喝。贴一下三代GPT模型的数据变化GPT-1仅用了包含1w本书的BookCorpus25亿词GPT-2的数据来自互联网用了800w在Reddit被link过的网页并做了清洗大概40GB名曰WebTextGPT-3则将语料规模扩大到570GB的CC数据集4千亿词WebText2190亿词BookCorpus670亿词维基百科30亿词。可以看到数据层面每一代均相比前一代有了数量级的飞跃无论是语料的覆盖范围丰富度还是绝对规模。因此下一代万亿模型使用的数据相比GPT-3若在质量、来源和规模上没有量级的改变至少我是不相信有多大提升的。ps: 近期一顿操作猛如虎一看提升一点点的工作真心太多了手动狗头算力不讲了money的问题。分布式训练技术好了终于到讨论技术的环节了。千亿、万亿参数的模型大概有三种设计方案/场景挑战万亿维度特征模型非常宽但是比较浅训练稀疏特征维度不高但是模型非常深万亿稠密参数又宽又深百亿、千亿的稀疏特征维度且存在数十层、上百层网络编码得到的稠密特征第一种方案适用于一些影响因素非常多的场景如推荐、搜索例如商品推荐中的点击率预估用户的性别年龄学历等画像、浏览历史、购买记录、商品的类型、标签、价格、标题、封面图乃至当下的时间节点和地理位置等均可能影响用户当下对一个商品的点击因此这类场景就更适合宽模型。第二种方案则适用于影响因素不多但抽象程度很高的任务如NLP、CV等。第三种方案则是一种更加复杂的场景例如搜索、计算广告中计算query与网页/广告的相关性进而排序我们不仅要考虑文本语义层面的相关性还需要考虑网页/广告的banner对用户的吸引力等进而需要点击率预估CTR这时网络不仅具备大型NLP模型的深度又兼具大型CTR模型的宽度。下面以百度飞桨PaddlePaddle为例分别谈谈这三类场景的关键技术方案。等等为啥是百度飞桨贴几个可能鲜为人知的milestone可能只有比较关注大规模机器学习/分布式训练相关工作的小伙伴才比较了解。2016年百度提出Ring-Allreduce[1]极大的缓解了多机多卡训练时的通信带宽压力使之不随网络中计算节点的数量增加而增加而在Tensorflow生态中流行的分布式训练框架Horovod的核心就是Ring-Allduce...2017年百度提出大名鼎鼎的混合精度训练[2]如今已成为训练/微调预训练模型的标配加速技术早在 2018 年飞桨的纯 CPU 参数服务器模式就可以支持万亿规模稀疏参数的模型训练...2020年百度打破GPU显存限制提出分布式层级化 GPU 参数服务器PaddleBox2021年提出 4D 混合并行策略可训千亿规模超大语言模型换句话说Paddle的全称是Parallel Distributed Deep Learning直译为“并行分布式深度学习”。当Tensorflow忙着做生态、Pytorch忙着做易用性的时候只有Paddle自始至终做着以分布式计算为代表的硬核底层优化以支撑百度搜索、推荐、广告业务的十亿乃至千亿的流量和恐怖的模型复杂度。因此毫不夸张的讲从百度飞桨就能窥见如今工业界训练万亿模型的前沿解决方案。万亿稀疏参数模型训练第一代架构如前所述搜索推荐场景经常面临数据量大、特征维度高且稀疏化的问题。对于这种宽模型最合适的分布式训练架构便是—— Parameter ServerPS 。如图所示PS架构将计算节点分为 server 与 worker其中worker用于执行模型的前向与反向计算而server则对各个worker发回的梯度进行合并并更新模型参数这种模型参数中心化管理的方式非常易于存储超大规模模型参数。百度搜索作为全球最大的中文搜索引擎对模型的规模、性能等要求非常高。为了应对严苛的实际业务挑战早在 2018 年飞桨的纯 CPU 参数服务器模式就可以支持万亿规模稀疏参数的模型训练。但是随着模型网络越来越复杂对算力要求越来越高在数据量不变的情况下CPU 计算性能差的弱势就会显现虽然可以通过增加 CPU 机器数量来解决甚至可以增加上百台但是这种方法不仅成本大幅提高而且集群的稳定性和扩展性也存在较大的问题。因此百度飞桨引入了纯 GPU 参数服务器来提升计算性能之前 100 台 CPU 机器才能训练的模型仅需 1 台多卡 GPU 机器即可完成训练。当然同时也要解决因为硬件更替所带来的问题。第二代架构纯GPU参数服务器GPU 强大的算力毋庸置疑可以提升集群的计算性能但随之而来的是不仅模型规模会受到机器显存和内存的制约而且通信带宽也会由于集群网卡数量降低而成为瓶颈。为了解决这两个问题百度飞桨引入了两大技术 SSD-MEM-HBM 三级存储 和 RPCNCCL 混合通信 到纯 GPU 参数服务器[3]。具体来讲SSD-MEM-HBM 三级存储策略允许全量参数使用 SSD 硬盘存储高频参数存储于内存当前 Batch 训练所用参数使用显存并且同时支持 SSD 的参数在硬盘、内存、显存之间快速拷贝。这样通过异步流水线执行机制隐蔽了 IO 带来的额外性能开销在保证训练速度的同时使训练的模型大小不再受制于显存和内存极大提升模型的规模。而 RPCNCCL 混合通信策略可以将部分稀疏参数采用 RPC 协议跨节点通信其余参数采用卡间 NCCL 方式完成通信充分利用带宽资源。▲GPU参数服务器百度飞桨纯 GPU 参数服务器虽然解决了之前纯 CPU 模式所面临的问题但新的问题又出现了——如何提高训练资源的利用率?第三代架构异构参数服务器兼顾网络宽度与深度在纯 GPU 的参数服务器下所有的训练都在 GPU 中当模型中部分网络层比较复杂并行难而串行链条长的时候GPU 利用率很难被打满而 GPU 机器中 CPU 与 GPU 的硬件配比是固定的无法灵活调整。针对这种情况有两种解决方案定制化 GPU 机型调整机器内 CPU 与 GPU 的硬件配比。混布 CPU 和 GPU 机器节点来调整机器间的硬件配比。基于这两种解决方案百度飞桨在 2.0 版本发布了通用异构参数服务器使训练任务对硬件类型和型号不敏感即可以同时使用不同的硬件混合异构训练如 CPU、AI专用芯片以及不同型号的 GPU 如 v100、P40、A100 等。同时还可以解决大规模稀疏特征模型训练场景下 IO 占比过高导致的芯片资源利用率过低的问题。通过异构参数服务器训练模式用户可以在硬件异构集群中部署分布式训练任务例如云服务器集群高效利用不同算力芯片为用户提供更高吞吐、更低资源消耗的训练能力。▲异构参数服务器异构参数服务器的最大亮点是硬件感知的任务切分因此甚至可以支持文首提到的最复杂结构的万亿模型——网络又宽又深。如上图所示针对类似 ERNIECTR 这样计算密集型与 IO 密集型兼有的训练任务可以被切分成多个子任务。其中的 IO 密集型任务如数据读取、Embedding 查询切分给 CPU 机器计算密集型任务切分给 GPU 机器用户可以根据子任务的计算复杂度来灵活决定机器配比并且还可以兼容传统纯 CPU 参数服务器和纯 GPU 参数服务器所支持的训练任务。4D混合并行超大规模稠密模型训练前面的三代架构解决了第一类和第三类万亿参数模型的训练问题网络极宽网络宽且深那么对于第二类万亿参数模型网络极深的大规模稠密模型有没有好的解决方案呢百度最新提出的 4D 混合并行策略 就是为该场景量身定制的目前已经支持了高达 2300 亿参数规模的100多层的 ERNIE 预训练模型的分布式训练。不同于前述的三代参数服务器的模式4D混合并行策略采用的是 集合通信模式 。这种模式没有管理模型参数的中心节点每个节点都是 Worker每个 Worker 负责模型训练的同时还需要掌握当前最新的全局梯度信息。而百度于2016年提出的Ring-Allreduce就是一种可以大大减少点对点通信次数的先进的集合通信方式目前已成为飞桨、Tensorflow、Pytorch等深度框架的分布式训练标配方案。首先来看一个公式总训练速度 ∝ 单卡速度 * 卡数 * 多卡加速比其中单卡速度由数据读取和计算速度决定多卡加速比由计算/通信效率决定。除了单卡可以使用的算子融合、混合精度之类的基础性能优化策略之外分布式训练还引入一系列并行策略。并行策略的核心思想是将数据和计算有关的图 / 算子切分到不同设备上同时尽可能降低设备间通信所需的代价合理使用多台设备资源实现高效的并发调度训练最大化提升训练速度。常见并行策略有数据并行Data ParallelDPLayer 间并行/流水线并行Pipeline ParallelPP)Layer 内并行/模型并行Model ParallelMP)我们从设备资源和计算/通信效率来分析三种策略的优缺点数据并行训练加速比最高但要求每个设备上都备份一份模型显存占用比较高。模型并行通信占比高适合在机器内做模型并行且支持的模型类型有限。流水线并行训练设备容易出现空闲状态加速效率没有数据并行高但能减少通信边界支持更多的层数适合在机器间使用。而4D混合并行策略的思想就是集三种策略的优势于一身实现取长补短。具体来说先在单机内使用模型并行和分组参数切片组合的 2D 策略这么选择的原因是这两个策略通信量较大适合使用机器内的卡间通信而后为了承载千亿规模模型再叠加流水线并行策略使用多台机器共同分担最后为了做到高效在外层又叠加了数据并行来增加并发数量提升整体训练速度。这样业内首个 4D 混合并行策略就诞生了。▲4D混合并行4D 混合并行策略的性能如何呢百度飞桨从理论性能角度对比分析了几组混合并行策略即 DP2 PP32 Sharding2 MP4、PP64 Sharding2 MP4 和 DP2 PP32 MP8。如下表所示与两种 3D 方式相比4D 混合并行策略在通信量和 Bubble 时间上并未明显增长但是大幅提升了数据并行路数!此外百度飞桨使用64台8卡v100机器在 2300 亿参数规模的100层的ERNIE模型上进行了性能实测。如图可以看到 4D 混合并行策略训练速度高于其它两种 3D 混合并行策略达到了8698 tokens/s至少可以提速 23.7%。至此千亿规模的超大稠密模型的问题在百度飞桨先进的4D混合并行策略下仅仅通过64台8卡V100机器就解决了万亿规模的超大稀疏模型和稀疏稠密混合的复杂模型在百度飞桨的异构参数服务器下也得到了很好解决。那么万亿规模的稠密模型呢以及万亿稠密十万亿稀疏的模型会怎样呢让我们拭目以待作下个时代的见证者吧寻求报道、约稿、文案投放添加微信xixiaoyao-1备注“商务合作”后台回复关键词【入群】加入卖萌屋NLP/IR/Rec与求职讨论群后台回复关键词【顶会】获取ACL、CIKM等各大顶会论文集 [1] Andrew Gibiansky. Bringing HPC techniques to deep learning, 2017. Ring Allreduce[2] Micikevicius, Paulius, et al. Mixed precision training. arXiv preprint arXiv:1710.03740 (2017). mix precision training[3] Zhao W, Xie D, Jia R, et al. Distributed hierarchical gpu parameter server for massive scale deep learning ads systems[J]. arXiv preprint arXiv:2003.05622, 2020 PaddleBox
