carrie葡萄_个人页_阿里云开发者社区

发表了文章 2021-06-27

持续探索行业新趋势，PAI平台获得联邦学习评测证书

2021 年 6 月 24 日，阿里云机器学习平台PAI参加中国信通院 “2021大数据产业峰会成果发布会”，获得“大数据产品能力评测”联邦学习项目基础能力专项评测证书。PAI平台持续探索行业新趋势，不断在前沿的热门领域尝试AI应用落地。信通院“大数据产品能力评测”评审会，项目覆盖联邦学习、数据管理平台、分布式流处理等热门领域，已经成为大数据领域权威的第三方评测品牌，成为供给侧产品研发和需求侧采购选型的风向标。PAI平台基于联邦学习框架，开发了深度联邦算法，包含DeepFM、DIN等，这些算法已经在客户的数字营销、智能推荐、广告投放等场景广泛应用，引领行业智能创新新方向。2020年成为PAI平台云原生的元年，在PAI-Studio可视化建模平台基础上，PAI-DSW云原生交互式建模平台，PAI-EAS云原生弹性推理服务平台，PAI-DLC云原生AI基础平台，云原生三驾马车应运而生。PAI平台面向企业客户及开发者，提供轻量化、高性价比的云原生机器学习平台，提供从数据标注、数据预处理、特征工程、模型训练、自动调参数、模型优化到模型在线、离线推理服务的全流程支撑，支持千亿特征、万亿样本规模加速训练，预制多个行业典型场景算法组件，全面提升机器学习工程效率。同时，PAI平台通过场景化AI的能力助力客户业务增长、实现客户价值，成为电商、广告、互娱等行业众多企业的首选。基于PAI平台打造的黑白盒一体化智能推荐解决方案，结合业务场景，实现高性价比、可灵活配置的智能精准推荐，不仅10天左右快速搭建并且企业自主可控。PAI用户增长方案通过提供成熟的算法组件模式，帮助客户在一周左右，快速实现流失用户召回等能力，并实现客户自主掌握全部技术细节。PAI平台灵活的PasS+SaaS服务模式，成为众多互联网及传统企业智能转型的首选合作。未来，PAI平台会进一步发挥自己在算法方面的独特优势，为联邦建模的客户提供更多有益于业务的深度学习联邦算法，帮助客户更有效的使用联邦机器学习技术建模。

发表了文章 2021-04-02

机器学习PAI-DSW交互式建模个人版有奖评测活动

【任务描述】任务1：阿里云机器学习PAI-DSW交互式建模平台个人版，模型构建和管理，操作体验。难度：中等（需要有算法理论基础）任务简介：体验人员登录阿里云机器学习PAI-DSW交互式建模平台（https://www.aliyun.com/activity/bigdata/pai/dsw），从真实客户视角，对平台在多场景的应用可行性进行产品评测，主要包括：产品功能：互联网和传统企业业务场景下，模型构建管理的功能易用性、有效性等；平台性能：模型构建的流畅度、计算资源丰富度、技术支持能力等；文档内容：使用文档的完整性、准确性和易读性等；在规定时间完成产品评测后，按照提交评测报告。体验内容包含但不限于PAI-DSW个人版模型构建和管理，体验整个训练和调用流程，查看产品文档，了解建模服务、授权等。任务步骤：1、登录阿里云机器学习PAI-DSW交互式建模平台（https://www.aliyun.com/activity/bigdata/pai/dsw），点击进入控制台2、进入控制台，在左侧导航栏，选择模型开发和训练 > 交互式建模（DSW）3、在DSW控制台页面，左上角选择城市，并点击创建实例4、根据提示进行两个角色授权，具体说明如下：首次使用PAI-DSW，需要对相关资源进行访问授权，详情请参见为关联角色授权。如果RAM用户创建实例，则需要主账号为其授权，详情请参见RAM用户授权。5、授权后，在配置实例向导页面，选择个人版，配置参数，配置完成点击确认订单。具体配置详细说明：https://help.aliyun.com/document_detail/163684.html?spm=a2c4g.11186623.6.690.76bd606dj3WidN6、核对订单信息，选中《机器学习PAID SW服务条款》复选框，并单击创建实例。7、任选一种熟悉的方式，进行模型构建，也可以使用预置案例。详细请见：https://help.aliyun.com/document_detail/154119.html?spm=a2c4g.11186623.6.692.6f1e369eYaczIg8、读写OSS数据，详细说明：https://help.aliyun.com/document_detail/130266.html?spm=a2c4g.11186623.6.693.3b2e52f8PTIz7Y9、模型管理，可以在PAI-DSW控制台内，点击停止模型构建，或设定自动停止配置。评测报告（示意）：评测人：王XX联系方式：189XXXX1234职业/院校专业：（上班族或师生朋友，请根据实际情况填写）评测细项：1、平台登录环节如：登录入口明显，登录顺利，没有问题如：登录入口找不到，需要账号认证校验，耗时较长2、 PAI-DSW模型实例创建环节如：流程顺利，开通成功进入控制台，成功创建实例，提示清晰好理解如：创建实例失败或过程不顺畅，缺少包含OSS数据导入等环节的整体流程介绍、报错、卡顿、授权失败、配置不成功、创建时间超过5分钟、OSS读写困难或失败等描述问题，说明理由（截图）3、 PAI-DSW预置实例测试环节如：流程顺利，能够成功且顺畅的使用预置实例如：预置实例少、未能成功运行预置实例、第三方库安装失败等描述问题，说明理由（截图）4、 OSS数据读写环节如：流程顺利，能够成功完成OSS数据读写如：读写失败等描述问题，说明理由（截图）5、 PAI-DSW模型管理环节如：顺利关闭和开启模型实例，能够顺利找到管理功能，提示清晰如：关闭不成功，体验不流畅等，描述问题，说明理由（截图）6、产品文档查看和体验如：文档清晰无误好理解，能够帮助新手顺利完成模型构建和管理如：文档有错误，需要XX不满足。文档需要优化，补充XX说明，描述问题，说明理由（截图）7、整体感受：体验XX。（选项：非常不满意，不满意，中等优缺点感受差不多，满意，非常满意）8、感受描述：请描述满意以及不满意的感受。XX需求没有满足；体验顺畅，能满足需求。附件：点击下载数据集、测试代码（非常欢迎大家用日常业务数据参加评测）补充说明：本次项目，PAI-DSW个人版模型构建服务，会产生少量费用，以最小资源为例，每小时会产生0.42元（4毛2）的训练费用。（体验后请及时停止训练，以免产生不必要的费用，在DSW控制台，Notebook建模服务页面，单击停止即可。）任务2：AI模型构建对比评测难度：中等（建议有算法理论基础）任务简介：体验人员登录阿里云机器学习PAI-DSW交互式建模平台（https://www.aliyun.com/activity/bigdata/pai/dsw），以及其他任一AI模型构建平台（如华为ModelArts，百度BML，百度EasyDL专业版，AWS SageMaker等）。将同一批数据集在多个平台（至少2个）的同类算法服务下（Notebook操作环境），进行模型构建体验。输出每个平台的构建体验比对报告。任务步骤：1、登录阿里云机器学习PAI-DSW交互式建模平台（https://www.aliyun.com/activity/bigdata/pai/dsw）2、授权并创建实例。3、对比评测的其他AI模型构建平台，请自由选择，并按照平台流程进行体验。评测报告（示意）：评测人：王XX联系方式：189XXXX1234职业/院校专业：（上班族或师生朋友，请根据实际情况填写）评测完成时长：XX小时评测细项：1）体验平台1——阿里云机器学习PAI-DSW个人版2）体验平台2——XX平台3）比对的服务：包含但不限于模型构建和管理，也可以延展到模型部署4）测试数据集：数量≥505）模型构建：在线完成模型构建和管理6）测试结果：（同一批数据，同一指标的对比结果，可以用Excel对比展示，示意文件下载）附件：点击下载数据集、测试代码（也非常欢迎大家用日常业务数据参加评测，对比测试记得用同一份数据进行测试哦）补充说明：本次项目，PAI-DSW个人版模型构建服务，会产生少量费用，以最小资源为例，每小时会产生0.42元（4毛2）的训练费用。（体验后请及时停止训练，以免产生不必要的费用，在DSW控制台，Notebook建模服务页面，单击停止即可。）评测要求：1-活动时间：2021年4月2日--2021年4月18日。2-按照要求完成至少一项评测任务，并提交测试报告。经产品组评估确认后可获得机器学习PAI定制马克杯一个。3-对产品优化和体验提出高价值意见建议的开发者，还可额外获得机器学习PAI定制帽衫一件。4-请在4月18日24点之前，将评测报告发送到：putao.fy@alibaba-inc.com。5-2021年4月23日前在本帖评论更新获奖开发者名单。

发表了文章 2021-03-14

AICompiler动态shape编译框架

移动互联网的兴起，不仅产生了海量数据，也对人机交互有了新的定义。企业如何动态处理不同规格图片数据，如何更灵活处理不同长度的对话语料等等，提升企业运营效率，争取更多的商业机会和流量，成为众多企业探索的热门技术应用。近期，阿里云机器学习PAI团队全新上线一套Dynamic Shape Compiler框架，不仅作为AICompiler技术栈中原有的Static Shape Compiler框架的重要补充，更是增加了Compiler在企业级数据处理应用的无限可能，在提升数据处理效率的同时，大幅提升AI工程化效率。先来看看案例和效果数据。性能结果某TensorFlow语音识别业务示例以某业务方的语音识别模型为例。过往我们为这个业务提供的优化主要基于Static Shape Compiler，但因为shape变化范围较大，只能采用离线预编译的方式来完成部署，部署过程较为繁琐。下图展示了基于Dynamic Shape Compiler在不同batchsize下的实际性能结果，其中纵轴为latency的提升倍数。整体编译次数从之前的几千次降低到1次。从数字上来看，在只有一次编译的较小编译开销下，性能十分接近Static Shape Compiler的性能优化结果。某TensorFlow广告推荐业务示例下面这个例子是某广告推荐业务方的推理模型，在线上系统中，预估时的input shape变化非常频繁，比如：用户画像标签个数可能不同；用户的历史行为序列的长度会不同；召回广告的集合大小会不同；广告所属类目的数量也会不同。这些变量会最终导致请求预估服务的input shape也是时刻变化的。过往业务方的同学需要通过batching/手工干预圈图等方式才能将编译次数控制到可接受范围内，造成每次模型迭代后部署过程较为繁琐。从性能结果上看，对比基于XLA优化的性能，Dynamic Shape Compiler基本接近甚至超过Static Shape Compiler的性能优化结果。某TensorFlow语音合成业务示例我们以某业务方的TTS模型为例，具体看一下实际业务中对优化工具对动态shape支持的需求情况。在这个业务模型里，用户的输入sequence length输出sequence length都可能发生变化。此外，由于TTS类算法本身需要在推理过程中引入随机数的特点，即使输入同一条样本，内部子图的shape也会发生变化。我们测试了如果基于static shape compiler来优化这个模型的话，输入数据数量以及累积编译次数的变化曲线。在这个业务模型中每个shape的编译开销约为20s左右，可以看到在经过几百轮迭代之后，编译cache都还没有收敛趋势，根据理论shape变化范围测算总编译时间至少在10个小时以上，因此这类业务如果使用XLA等静态shape编译器的话，无法透明的实现可商用的部署。AICompiler里面的dynamic shape compiler组件很好的解决了这一问题，在一次编译的前提下帮助用户获得平均2X的性能收益，目前业界尚无其它AI编译器能够实现类似的效果。某PyTorch公式识别业务示例下图是一个PyTorch业务的例子，对比的Baseline是基于libTorch执行导出后的TorchScipt脚本，可以看到AICompiler对PyTorch业务提供了同样的编译优化能力。本文主要介绍这套动态shape编译框架，对更多技术细节兴趣的读者可以参考DISC: A Dynamic Shape Compiler for Machine Learning Workloads.从PAI团队三年前启动深度学习编译器方向的工作以来，“Dynamic Shape”问题一直是阻碍实际业务落地的严重问题之一。彼时，包括XLA在内的主流深度学习框架，都是基于Static Shape语义的编译器框架。即，just-in-time运行的编译器，会在运行时捕捉待编译子图的实际输入shape组合，并且为每一个输入shape组合生成一份编译结果。Static Shape Compiler的优势显而易见，编译期完全已知静态shape信息的情况下，Compiler可以作出更好的优化决策并得到更好的CodeGen性能，同时也能够得到更好的显存/内存优化plan和调度执行plan；然而，Static Shape Compiler的缺点也十分明显，具体包括：• 编译开销的增加。对于训练业务，编译开销导致训练迭代速度不稳定，训练初期显著负优化，甚至整个训练过程的时间开销负优化；对于Inference业务，很多业务实际部署和迭代时不允许出现性能抖动，而离线的预编译预热又会使得部署的过程变复杂。• 内存显存占用的增加。除编译开销的问题之外，当shape变化范围特别大的时候，编译缓存额外占用的内存显存，经常导致实际部署环境下的内存/显存OOM，直接阻碍业务的实际落地。• 对于一部分业务场景，shape变化范围可能非常大甚至是趋于无穷的，比较常见的包括广告推荐类业务中常见的稀疏化模型，还有例如分布式训练下的embedding切片等等。在这种情况下，编译缓存永远也无法收敛，用户也就不可能通过compiler获取到性能收益了。• 上述问题在部分情况下，可以通过人工干预Compiler的圈图过程来缓解，即，将shape变化剧烈的子图排除在编译范围之外。然而，这种解决办法对用户非常不友好，大大降低了Compiler应用的通用性和透明性，这要求做部署和优化的同学同时对模型结构和compiler非常了解，且每一次模型结构迭代时，都需要花费额外的工作量来调整圈图获得可以接受的性能效果。关于这一问题，曾经出现过若干类解决方案，包括，对Compiler在圈图过程中的自动化干预；在编译期内部自动对变化维度做bucketing补齐并将子图计算结果做自动的slicing。然而这些解决方案都存在各自的局限，例如前者只能适配于小部分子图shape变化剧烈的情况，后者在很多模型上都无法得到自动slicing的完备数学推导。为彻底解决这一问题，我们选择基于MLIR（Multi Layer Intermediate Representation），结合团队过往对AICompiler中积累的部分经验，打造一套完备支持Dynamic Shape语义的AI编译器，希望能够彻底解决深度学习编译器在这部分对灵活性要求较高的业务中无法落地应用的问题。整体架构Dynamic Shape Compiler的整体架构，及其在AICompiler中的上下文关系如下图所示。Compiler部分MLIR InfrastructionMLIR是由Google在2019年发起的项目，MLIR 的核心是一套灵活的多层IR基础设施和编译器实用工具库，深受 LLVM 的影响，并重用其许多优秀理念。这里我们选择基于MLIR的主要原因包括：• 比较丰富的基础设施支持，使得完成编译器的常规开发工作更为便捷，效率更好。TableGen，以及编写常规pattern matching的graph optimization pass的简化等。• Open for Extension的模块化设计架构，这里的核心是其Dialect抽象的设计。除Dialect的concept本身，在架构设计上，基于LLVM在传统编译期领域的成功经验，MLIR团队还是展现出了老练的架构设计能力，将整个MLIR架构的设计变得很具模块化。• MLIR的胶水能力，使得其可以比较灵活方便地与已经存在的优化手段进行集成，而非拒斥。具体实现MLIR框架的上述特性，使得我们可以比较方便的有选择性的leverage部分社区已有组件，避免完全的重新造轮子，也一定程度上避免从头彻底重构XLA代码带来的巨大工作量。这里我们根据过往对AI编译器的理解，选择了4层比较主要的中间层抽象，包括：• DHLO Dialect：能够完备表达动态shape语义的算子层计算图抽象，它的主要作用是能够用有限数量的算子类型来描述不同前端框架的大量算子定义，且表达足够灵活。• DLHLO Dialect：引入Buffer语义的计算图抽象，用于在编译器流程中进行内存/显存的管理和优化。• Loop Dialect：用于将算子层的计算描述基于Loop等展开为指令集的计算描述，我们在这一层上完成了算子fusion的CodeGen。• GPU Dialect：为GPU编程模型中的kernel launching及各种底层原语提供中间层抽象。下图展示了我们基于MLIR的Loop Dialect等基础设施，在CodeGen中实现最简单的Input fusion的基本原理。对比XLA中只有高层的HLO和底层的llvm两层中间表示，MLIR提供的Loop Dialect抽象可以直接在中间层完成fusion，很好的简化了开发的复杂度。篇幅原因，我们在次不在赘述Compiler部分其它各个模块的具体实现细节，请感兴趣的同学请移步MLIR社区中发起的相关细节讨论：RFC，以及会议讨论。此处想着重介绍下对比于XLA，Dynamic Shape Compiler需要额外考虑的一些问题，包括：• DHLO IR，我们在XLA的HLO IR基础上，扩展了一套具有完备动态shape表达能力的IR。静态场景下，HLO IR中的shape表达会被静态化，所有的shape计算会被固化为编译时常量保留在编译结果中；而在动态shape场景下，IR本身需要有足够的能力表达shape计算和动态shape信息的传递。• Placer模块，对于Dynamic Shape Compiler来说，计算可以分为shape计算和data计算两类，对于GPU backend而言，通常shape计算的计算量较小，launch和拷贝开销相比较大因此通常更适合在host侧完成计算。我们实现了一个简单的单卡分图策略，对host侧和device侧计算执行不同的lowering pipeline。• Buffer管理及Buffer优化模块，有别于静态Shape编译期能够比较容易通过liveness分析，实现Buffer的复用等优化，而在动态shape语境下，由于Buffer Size未知编译期则不容易做到完全一致的优化。我们目前使用的是动态的Buffer申请和释放，优化申请和释放的时间点，同时后台使用应用层包含Cache的Allocator，来达到性能和灵活性之间的平衡。后续可考虑在IR中充分表达Shape Constraint信息的情况下，来尝试在编译期做精细的Buffer复用优化。此外，我们注意到在动态shape语境会为编译期的性能performance带来一些有趣的新挑战：• 部分优化决策后置到运行期，以Implicit Broadcast为例，目前主流的前端AI框架都支持implicit broadcast语义，而在动态shape语义下，编译期无法充分知道LHS/RHS是否需要执行Broadcast操作。为保证完备性，如果所有情况下都稳妥的执行Broadcast计算的话，则会带来比较严重的冗余计算/Fusion颗粒度等问题。其它与之类似问题还包括GPU Kernel的Launch Dimension选择等，我们解决这一问题的做法是编译期做多版本编译，运行期根据实际shape来选择最优实现，保证灵活性的同时，缓解灵活性带来的性能损耗。• Shape约束信息的使用，我们发现在Dynamic Shape Compiler中，即使Tensor的Shape信息未知，但Shape之间的约束信息，例如两个Tensor之间的某两个维度的size是否相等等信息，仍然会对编译结果的性能产生比较重要的影响。主要原因包括：在图层面，这些信息带来了更大的图优化空间，而在CodeGen层面，这些信息能够更有效的指导低层Lowering做CSE等传统编译器优化，减少冗余的计算指令数。多前端框架支持随着近年来PyTorch用户数量的持续增加，对PyTorch作业的性能优化需求也正在变得越来越重要。AICompiler框架在设计时也包含了扩展支持不同前端框架的考虑。从IR lowering的角度，这里我们选择相比于HLO更具泛化表达能力的DHLO Dialect作为不同前端框架的统一接入IR，而在PyTorch侧选择用户部署时导出的TorchScript IR，通过实现一个轻量的Converter将TorchScript转换为DHLO IR实现了对PyTorch Inference作业的覆盖。MLIR相对完备的IR基础设施也为Converter的实现提供了便利。RAL (Runtime Abstraction Layer）除编译本身的问题之外，我们还面临其它一些问题，例如如何将编译的结果能够配合TensorFlow/LibTorch等宿主在各自的运行环境上下文中执行起来，如何管理运行时IR层不易表达的状态信息等等。我们希望为不同的运行时环境实现一套统一的Compiler架构，为此我们引入了运行时抽象层，即RAL层。RAL层主要负责解决如下问题：Compile Once and Run AnywhereRAL实现了多种运行环境的适配支持，用户可以根据需要进行选择。• 全图编译，独立运行。当整个计算图都支持编译时，RAL提供了一套简易的runtime以及在此之上RAL Driver的实现，使得compiler编译出来结果可以脱离框架直接运行，减少框架overhad，比如我们在支持某语音ASR模型（类transformer网络）推理优化时，使用全图编译将框架开销从TF的22ms减小到4ms；• TF中子图编译运行。RAL目前实现了TF Driver，可以支持在训练/推理场景中对圈出的子图进行编译执行；• Pytorch中子图编译运行。RAL目前实现了Libtorch Driver，可以支持在推理场景中对圈出子图进行编译执行；以上环境中在诸如资源（e.g. memory）管理，API语义等上存在差异，希望能够引入一层抽象对compiler侧屏蔽这些差异。RAL通过抽象出一套最小集合的API （RAL中称为Driver），并清晰的定义出它们的语义，这样compiler和runtime就可以在一定层度上隔离开来，简化compiler的开发，同时通过提供这套API在不同环境下的实现，来达到在不同的环境中都能够执行编译出来的结果的目的。Stateless编译dynamic shape compiler完成一个计算图的编译之后，编译的结果可能被多次执行，而有些op的执行是带状态的：• 在device（e.g. gpu）上执行时，对const op希望只在第一次执行时加载并常驻device，而不是每次都引入一次host-to-device的拷贝；• 对于需要根据具体shape信息进行tuning的op （e.g. gemm/conv），tuning cache需要一个地方存储；RAL将资源初始化等带状态的部分抽取出来，封装成context来管理生命周期。在代码生成的过程中，通过简单的注入context，将状态量隐藏在context之后，使得compiler侧看到的是一个纯计算的过程。无状态的设计一方面简化了代码生成的复杂度，另一方面也更容易支持多线程并发执行（比如推理）的场景，同时在错误处理，回滚方面也更加容易支持。对用户透明的编译模式切换我们对于Dynamic Shape Compiler在AICompiler中的定位是：与原Static Shape Compiler并列的一套框架，在允许适度牺牲性能的情况下，提供对于强Dynamic Shape类业务的通用透明支持。然而从用户的角度来说，通常并不容易判断一个Workload的更适合Dynamic Shape Compiler还是Static Shape Compiler，为此我们结合接耦和全量打开[link]中的工作，设计了一套编译模式自动切换的状态机。其基本思路是，在任务初期先选择较为安全的Dynamic Shape Compiler，结合后台编译让用户能够在运行时尽早得到有性能提升的编译执行，并在后续执行过程中结合资源的实际占用情况和实际运行时的shape变化范围来有选择性的切换到Static Shape Compiler的执行。两套compiler在运行时的切换关系如下图所示：阿里云机器学习PAI平台面向企业客户及开发者，提供轻量化、高性价比的云原生机器学习平台，涵盖交互式建模、拖拽式可视化建模、分布式训练到模型在线部署的全流程覆盖，百余种落地场景，全面提升机器学习工程效率。目前， PAI AICompiler已经集成在阿里云机器学习PAI的通用推理优化工具PAI-Blade敏捷版中，用户可以可以参考开发文档来快速体验。作者：朱凯，赵文益，杨军

发表了文章 2021-03-14

AICompiler编译器介绍及访存密集算子优化

阿里云机器学习PAI是阿里云上提供的人工智能平台服务，提供一站式的机器学习解决方案。在过去的三年多时间里，阿里云机器学习PAI团队在AI编译优化技术方向投入了比较专注的资源精力，对这个领域也建立起了一定的理解。目前在内部集群上AICompiler已经实现了默认的全量打开，在阿里外部已经开始为来自多个不同行业的业务方提供服务，涉及行业领域包括在线教育，安全，娱乐，电商，直播等；涉及的业务类型包括文本分类/识别，机器翻译，语音识别/生成，图像类业务等等；支持覆盖的硬件包括云端GPU/CPU以及端上CPU等。我们会在接下来的系列文章里介绍一下这方面的工作以及一些思考，一方面抛砖引玉，吸引更多同学来进行共同建设；另一方面也为阿里云上对训练和推理作业的性能优化有一定需求的用户同学提供一些技术方面的背景介绍。AI编译器简介在上图中将近年的深度学习框架粗略分为三代。几代框架之间有一个趋势，在上层的用户API层面，这些框架在变得越来越灵活，灵活性变强的同时也为底层性能问题提出了更大的挑战。另外一个技术趋势则是系统底层的深度学习的编译器近一段时间也开始活跃起来，这些编译器试图去解决框架的灵活性和性能之间的矛盾。传统编译器是以高层语言作为输入，避免用户直接去写机器码，而用相对灵活高效的语言来工作，而深度学习编译器的作用相仿，其输入是比较灵活的，具备较高抽象度的计算图，输出包括CPU或者GPU等硬件平台上的底层机器码及执行引擎。AI编译器的目标是针对AI计算任务，以通用编译器的方式完成性能优化。让用户可以专注于上层模型开发，降低用户手工优化性能的人力开发成本，进一步压榨硬件性能空间。涉及到性能优化，我们有必要先对一个AI作业执行过程中的性能开销的分布有一个感性的认识，所谓what you can't measure, you can't optimize it. 在《Characterizing Deep Learning Training Workloads on Alibaba-PAI》这篇paper里，我们针对阿里云机器学习PAI平台训练workload的性能开销占比有过一个比较细致的分析。考虑到目前我们在AI编译优化里还主要关注单计算设备的计算效率问题，所以我们可以宏观上将单设备上的性能开销拆解为计算密集算子（比如GEMM和Convolution）和访存密集算子（比如Elementwise Add，BN等操作）两部分，关于计算图过于灵活带来的框架开销，我们也统一归类到访存密集算子开销占比中。针对不同的性能热点，所需要的优化手段也存在区别。本文后续篇幅将首先介绍我们在访存密集型部分的工作，计算密集型算子的部分会在后续连载中进行介绍。Fusion Stitching——大颗粒度访存密集型子图CodeGen阿里云机器学习PAI团队在访存密集算子上以XLA为基点开展了大量的工作，工作内容涵盖前端、中端、后端以及执行引擎，我们将其称之为Tensor Accelerator and Optimizer(TAO) compiler。TAO Compiler先后经历了V1 (FusionStitching: Deep Fusion and Code Generation for TensorFlow Computations on GPUs)和V2(FusionStitching: Boosting Memory Intensive Computations for Deep Learning Workloads)两代演进。如前文所说，XLA在GPU backend上的主要收益来源是对访存密集型算子的自动Op Fusion CodeGen。催生我们做这些尝试的原因是，我们在实际业务中发现，社区XLA在最核心的CodeGen环节还有很大的问题和改进空间。例如下图为一个LayerNorm模块的前向计算子图，手工优化的话，它可以很容易被写成一个CUDA kernel，本应该是很适合编译器通过自动op fusion来获取性能收益。但我们发现XLA实际并没有做的非常好。经过细致的分析后我们认为这里的本质问题是社区的CodeGen模版过于简单，因为模版非常简单限制了中端Fusion pass的灵活度，被迫做了非常保守的op fusion策略，图中每一条红线都有一个细节的原因导致社区XLA无法把这些算子fuse到一起，也就无法拿到节省相应访存开销所能得到的优化收益。分析之后我们认为造成这些问题的根本原因为：• 单一Parallel Loop的比较简单的CodeGen模版；• 由于CodeGen模版比较简单，为保证性能而被迫保守的Op Fusion策略。这种简单的CodeGen策略在fuse线性的Elementwise算子时足够得到理想的结果，但当计算图的连接关系变复杂，同时计算图中出现Reduce／Broadcast等复杂计算节点时，在实际业务中效果并不好，特别是对于包含了后向处理部分的训练过程计算图更是如此。当然，我们可以直接采用复杂的CodeGen模版，通过牺牲通用性的方式换取更好的性能收益。但在Op节点类型以及计算图的拓扑结构千变万化的情况下，这种方式并不能够在编译器中通过编译的方式有效的节省人力成本。于是就引申出了TAO compiler的设计理念。TAO Compiler V1TAO Compiler V1的核心原理可以概括为：• 借助于GPU硬件中低访存开销的shared memory，缝合不同schedule的计算子图，实现多个parallel loop复合• 支持不同shape的多个tensor输出• 保证CodeGen性能的前提下，实现更加激进的Op fusion策略在GPU的体系结构中，SM内的shared memory的访存开销远远低于global memory的访存开销，可以帮助我们来把多个本来独立的kernel粘合在一起。这样的方案下，被粘和的每一个子图仍然可以基于自己的简单的CodeGen模版来运作，他们不必担心因为各自的pattern被fuse在一起而需要更复杂的CodeGen模版，也一定程度上不必担心因为fuse的颗粒度太大而产生过多的冗余的计算。V1的核心工作涉及中端和后端两个部分，解决了多种不同细节原因导致的细粒度算子无法fuse到一起的问题，主要是基于这个核心思路。下面的两张图分别为社区XLA Codegen的情况和TAO Compiler V1的情况。TAO Compiler的CodeGen将社区做法中难以fuse在一起的计算pattern，通过低访存开销的shared memory作为桥接，将多个kernel缝合在一起，同时又保留被缝合的每一个部分都依然采用简单的CodeGen模版。这种方案在通用性和性能之间取得一个更好的平衡点。TAO Compiler V1通过这样的方式，在一定程度上保证CodeGen性能的基础上，大幅提高了op fusion的颗粒度，以下面表格中的两个例子为例：TAO Compiler V2在做V1的推广落地的同时，我们抽取了一些业务进行了比较精细的分析，观察优化距离性能的极限还有多大的距离，结论是虽然凭借在op fusion颗粒度上的优势，在很多case上可以做到明显优于社区XLA，但离硬件性能的峰值还是有比较明显的gap的。所以我们抽取了一些有代表性的kernel，分析了这些gap的具体原因。我们发现每个case各自都有不同的原因导致没有能够接近访存的峰值性能。这些原因比较细节，在此不再展开，但宏观来说问题来自于目前的CodeGen基于Rule-Based的策略，而Rule-Based的策略本身存在其固有的局限性。具体到compiler的各个环节：• 在中端Op Fusion层面上，基于简单规则下局部合理的Op Fusion决策可能并非全局最优的决策；• 在后端CodeGen层面上，基于简单规则下，同一Kernel内的不同节点的模版选择和CodeGen行为决策也可能并非整体最优的决策。在TAO Compiler V2与V1以及社区XLA相比最大的区别可以概括为：• 更多的考虑全局最优，而非基于贪婪的局部最优；• Rule-Based到Cost-Based的演进。这两点区别同时反映在中端的Op Fusion策略以及后端的CodeGen策略上。我们引入了多个不同等级的Cost Model，其主要区别如下：中端在Graph范围内做Op Fusion决策，由于探索范围较大，选择接入开销较低的SOL cost model；后端在Kernel范围内做tuning，可以接入开销相对较高的Proj Cost Model。中端Op Fusion决策部分目前XLA和TAO V1中解决HLO instruction之间的Auto Fusion问题时采用的是完全基于规则的策略。这些规则都是基于人工经验确定的，往往难以覆盖到所有的情况，导致可能会出现各种corner case以及为了解决这些corner case而打上的一系列补丁。从长期来看这种方法并不能充分的挖缺潜在的性能优化空间，也会带来越来越沉重的维护成本。为了使用更加系统性的方法解决Auto Fusion的问题，我们提出了Cost Based Fusion Strategy。新的策略主要是对V1中以下两个大的方面进行改进：• 兼容性度量。兼容性度量是一种用来评估一个给定的Fusion动作是否有收益的方法。目前V1中使用的是一条简单的规则来进行兼容性度量，即只要融合之后的kernel的thread block level的并行度没有下降到1则认为融合具有收益。该策略在很多实际业务上发挥了很好的作用，但也遇到了不少Corner case。比如该规则对于大shape的pattern表现为过于激进，融合后可能因并行性大幅下降而导致性能变差，而对于小shape的pattern则表现的过于保守，丢掉了一部分融合的机会。在V2中我们基于cost model来更系统化的考虑访存量，kernel launch次数，并行度改变对于最终性能的影响等，可以更准确的评估一个融合动作的效果以指导Fusion Plan的探索。• Fusion的探索空间。一个计算图对应的Fusion Plan由多个Fusion Pattern组成。一个Fusion Pattern中如果只包含具有生产消费关系指令则是纵向fusion，反之如果包含有不含生产消费关系的指令否则为横向fusion。一个计算图可能存在着多种不同的Fusion Plan。目前V1中是基于一个启发式的贪心策略确定性的生成一个Fusion Plan，而再不进行其他可能的探索。这种策略好处是具有很高的效率，但缺点是会漏掉很多可能性。另一方面目前社区XLA及TAO Compiler V1中只会考虑纵向fusion而未考虑横向fusion。这里所说的横向fusion即不存在直接生产消费关系的节点之间的fusion，如下图所示。除其中近距离横向fusion可同样带来仿存节省的收益外，在更多的场景下可通过节省kernel launch开销带来收益，同时当使用空分并行的方式对横向fusion之后的kernel做CodeGen时还可能提升GPU的资源利用率。下图中展示了一些横向fusion的例子。V2的中端部分，对包含以上两种fusion的解空间进行了更多探索，以期找到更好的全局最优决策。具体来说fusion空间探索是一个迭代式的过程，每一次迭代由以下几个步骤构成：• 搜索高价值fusion pattern。这里的高价值指的是基于cost model评估会带来更大收益的pattern。直接暴力枚举进行搜索是一个指数级别的算法，我们使用的是一种启发式的算法，在稀疏图场景下（一般指令间的连接图满足这个前提）是一个接近线性的算法。具体而言我们首先构造计算图指令间的一个拓扑排序，依次遍历每条指令并按照递推的方式生成以该指令结尾的top k候选fusion pattern。递推的过程中我们会进行局部的充分枚举（扩张），对整个空间进行更多的探索，同时也会及时进行剪枝（收缩），确保可以不会组合爆炸。• 构造fusion plan。即寻找Fusion Pattern的一个有效组合以构成一个完整的Fusion Plan。这里的有效组合指的是各个Fusion Pattern之间不相交且相应的融合动作不会引入环。这里我们尝试了多种不同的策略，比如贪心策略，BFS+剪枝策略。目前使用的是每次选择兼容的且收益最大的fusion pattern的贪心策略。• apply fusion plan。也即根据Fusion Plan执行相应的融合动作。以上的过程可以对整个优化空间进行更大程度的探索，同时又有效的控制了搜索的复杂性，在一组评测应用集合（这也是进行编译器开发经常性需要的工具支撑了）上的实验表明，该策略工作良好，符合预期。后端CodeGen部分在介绍V2后端CodeGen的具体工作之前，我们先对XLA和TVM做一个简单的横向比较：• XLA是一种比较务实的方案，用基于规则的简单方式去做收益空间最大的访存密集型pattern的Automatic CodeGen，它的优势是自动化和比较小的编译开销，缺点是如果想进一步提升性能的话会非常局限；• TVM的目标是去胜任更复杂的CodeGen，基于规则的策略无法胜任情况下，它在Halide工作的基础上，提出了一个比较先进的Schedule抽象。这个Schedule的空间非常大，如何才能找到最好的Schedule，一方面需要基于用户的经验写出比较适合硬件体系结构的Schedule，一方面需要巨大的编译开销为代价在Schedule之间进行tuning。这里我们需要解决的问题是：需要找到一种方式，能够自动/对用户透明的，在有限的编译开销的基础上，提升性能并进一步接近硬件的性能峰值极限。V2的工作在XLA的基础上，一定程度上试图借鉴TVM的Schedule抽象的核心想法，但又有本质的不同。根据我们过往工作的经验，对于访存密集型pattern来说，为了达到或接近硬件的峰值性能极限，所需要的Schedule的枚举空间通常并不需要非常大。因此我们试图提炼一套比TVM的schedule抽象要简化很多的CodeGen Plan抽象，希望这套抽象能够代表手工写相应Pattern的Kernel时所需要考虑的全部问题空间。同时需要保证CodeGenPlan的枚举空间是足够小的，能够满足用户对编译开销的需求。此外，我们使用Proj Cost Model而非TVM中目前基于实际profiling结果来tuning的方式，其原因也是希望能在编译开销和性能之间取得更好的平衡点。在TAO Compiler V1的工作的基础上，V2在CodeGen部分的主要区别是：• CodeGen Plan抽象，尽量对全部的CodeGen可能性做抽象和枚举；• Index计算与主体计算分离，引入index_cache与value_cache，最小化冗余计算；• 与CodeGen Plan抽象相对应的Implementation抽象，方便对不同节点增加新的算子实现模版。篇幅原因我们不再详细介绍CodeGen Plan抽象的具体细节。下面仅试图以一个pattern为例，来说明TAO Compiler V2与V1及社区XLA之间，在CodeGen结果上的主要区别。下图左图为社区XLA的CodeGen结果，由于简单模版的限制会生成3个简单Schedule的kernel；右图是TAO Compiler V1的结果，借助Shared Memory的粘合，可以生成一个kernel。TAO Compiler V1距离硬件性能峰值之间可能存在差距的主要问题来自于：• A/B/C三个子部分的CodeGen Schedule是彼此独立的，在此例中，A/B/C三个部分的计算在同一个GPU thread内可能依赖于Elementwise 4节点处的不同Element，产生冗余计算。• A/B/C三个子部分的CodeGen过程相对独立，Elementwise 3等节点处的值和Index的计算结果无法被有效Cache，进一步增加了冗余计算指令。• A/B/C三个子部分可能各自有多种CodeGen模版，但可能只有一部分子模版的组合可以在全局上最好的利用GPU的并发度（即GPU Occupancy）。当冗余计算指令的数量（或者Occupancy带来的问题）达到一定临界值后，本应该是仿存Bound的计算pattern，性能热点便会迁移为计算或Occupancy，导致无法达到硬件仿存性能峰值的性能。TAO Compiler V2经过CodeGen Plan的枚举和基于Cost Model的tuning之后，会找到一个认为相对最优的CodeGen Plan。例如，在上图这个pattern中，选择Reduce节点做为整个Kernel的Dominant节点可能是更好的方案，其它节点处，在同一个thread内需要计算的Index会由Dominant节点的Index以辐射传播的方式推导计算得到，Index的传播过程和数值的计算过程在整个kernel范围内进行Cache，通过以上机制最大化的避免冗余的Index计算和数值计算。此外，CostModel还会对枚举的CodeGen Plan中的Launch Dimension等因素对Occupancy的影响进行建模，得到对于整体性能最优的CodeGen行为。TAO Cost Model中端不同的fusion策略以及不同后端CodeGen生成方式会影响最终模型实现的效率。所以很自然的想到利用cost model帮助中端、后端CodeGen探索最优的实现。这里主要的挑战是：• cost model需要高效的对成百上千种不同实现做实时的评估，需要减少其本身的overhead；• cost model需要准确的区分不同实现的性能差异；• 不同型号的gpu拥有不同的硬件架构（memory hierarchy，latency以及throughput指标），cost model需要对不同型号的gpu建模。所以我们会将workload输入映射成不同的资源需求，同时对device内部流水线stage的resource、latency以及throughput做了抽象和表示。最终通过建立latency模型以及throughput模型估计当前实现的计算耗时。Cost Model分为3个level： SOL Cost Model, Projected Cost Model以及Profiling Cost Model。• SOL Cost Model 只考虑硬件spec，不考虑具体实现、架构特点（例如假设100% cache hit ）和编译器效率。对于CodeGen，主要用memory cycles以及device throughput（例如：处理 1000T MACs, V100 125 Tflops vs 4x TPU 180 Tflops vs new ASIC）来区分。其特点是建模速度快，误差较大，所以可以用于粗粒度性能筛选以及不同硬件性能快速评估。因此,我们在中端OP fusion探索决策时引入SOL cost model评估不同Op fusion的cost并保留下cost 最小的Op fusion Plan。• Projected Cost Model需要考虑具体kernel实现、架构特点（如hit rate）和编译器特点。对于CodeGen，主要用kernel latency来区分。特点是建模速度慢，但误差较小，所以可以用于细粒度性能筛选。因此,我们在做后端CodeGen时，引入Proj cost model区分同一条fused instrcution在不同CodeGen Plan下因为指令数不同以及寄存器复用情况差异造成的性能差别。• Profiling Cost Model目的是作为cost model的ground-truth，从profiler上得到实际运行性能结果。其特点是执行耗时长，所以可以用于构造offline cost model以及修正SOL level与Proj Level cost model。Cost Model主要由三个模块组成： Workload Model, Device Model, 以及 Cost Evaluation。简单来说。可以举一个简单的例子，假设任务的workload由10条硬件指令组成，芯片的处理能力是每个cycle处理2 条硬件指令，那么该workload需要5个cycle才能被处理完。Workload model的准确性影响了整个cost model建模的准确性，因此80%以上的研发时间用于建模workload model。实践中，我们会估计某条fused instruction在当前CodeGen Plan下的寄存器消耗、各个硬件单元的硬件指令需求、memory 消耗以及shared memory消耗。Device Model建模了GPU各个硬件单元的throughput、bandwidth以及latency。可以从公开资料或者论文中得到.在device model中，我们主要建模了芯片内部各个unit的数量、SM内各个单元的throughput和latency、L2的throughput（用于建模atom指令）以及 Memory bandwidth。Cost Evaluation根据workload model以及device model 估计最终生成kernel的Memory cycle、Occupancy（并行度）、Wave number、Kernel Latency、Performance Limiter以及SM内部各个unit的cycles。Cost Model主要有两种建模方式：Throughput Model以及Latency Model。Throughput Model首先估计fused instruction所需各机器指令的数量（例如需要X条FFMA, Y条MOV, Z条IMAD等）。并对机器指令根据其对应的pipe做聚合（例如FFMA和IMAD都是发射到FMA Pipe的）。在获得当前GP各个pipe的throughput后，用pipe workload（硬件指令）的数量除以这个pipe的throughput就是其所需要的cycle数。最后在所有pipe中找cycyle最大的pipe，这个pipe就是这个fused instruction在当前gpu上的performance limiter，并且这个pipe所需要的时间就是kernel的时间。Latency Model首先估计fused instruction所需的register数量，并计算出它的occupancy，再计算出总共需要的wave数量（波数）。然后估计fused instruction所需各硬件指令的数量（同Throughput Model中的第一条）。根据device model获得当前gpu各个硬件指令的latency。根据硬件指令数以及指令的latency计算 warp latency，用warp latency乘以wave数量得到最后的kernel latency。对于TAO Compiler V1来说，由于大部分fused instruction已经达到或者接近GPU math或memory的理论上限，此类情况下，throughput model能很好地对fused instruction做建模。对于TAO Compiler V2，由于fuse了更大的尺度，目前大部分fused instruction距离硬件极限还有点距离，所以用throughput model做区分是不合理的。需要用latency model。性能数字下图为基于本文中所述工作，在一些典型业务模型上，TAO Compiler与社区XLA在Nvidia V100上的性能数字对比，其中社区XLA与TAO的性能收益数字，均为相同计算精度下的收益数字。下图为某业务方基于PAI的easyTransfer解决方案进行建模，在不同模型上的性能收益数字。AICompiler同样对不同应用场景给出了一致性的优化方案和相对比较明显的性能优化结果。提供的性能优化数字普遍超过了社区XLA的工作。阿里云机器学习PAI平台面向企业客户及开发者，提供轻量化、高性价比的云原生机器学习平台，涵盖交互式建模、拖拽式可视化建模、分布式训练到模型在线部署的全流程覆盖，百余种落地场景，全面提升机器学习工程效率。目前， PAI AICompiler已经集成在阿里云机器学习PAI的通用推理优化工具Blade敏捷版中，用户可以参考开发文档来快速体验。作者：朱凯，赵文益，杨军

发表了文章 2021-03-09

尼日利亚的学生开发者，用阿里云PAI打造了卡通头像神器

3D Animate Hub生成的卡通头像Hashim就读于尼日利亚的Afe Babalola大学计算机学院。作为一名软件开发者，他曾从事独立游戏开发工作，却遇到了不小的挑战：“艺术方面是我的弱项，绘制形象并将他们卡通化总是耗费我许多时间，我认为我可以找到一个基于AI来做这些工作的更简单的方式。”于是，Hashim决定进入AI领域。通过在Coursera等平台自学课程，他掌握了机器学习的基础知识。借助公开数据集与开源模型，他用阿里云PAI-DSW快速完成了3D Animate Hub的模型训练——自动识别图片中的人脸部分，并生成相应的开通形象。基于这个模型，他应用阿里云OSS和Web应用托管服务打造了3D Animate Hub 的Web端——只需将人脸照片上传至站点，就可以一键完成卡通化处理，生成卡通形象。Hashim表示阿里云PAI-DSW是一个易用性很强的模型训练平台，帮助他用很短的时间就完成模型训练；而阿里云OSS则是他所用过的最简便易用的存储服务，他也将其推荐给很多朋友使用。目前3D Animate Hub还处于demo阶段，接下来Hashim计划将其打造成商业产品并推向市场，还将加入针对视频中的头像进行卡通化的功能。首届阿里云全球AI创新挑战赛于2020年9月-12月举行，吸引全球35个国家和地区的536支团队参赛。通过两轮比赛角逐，16个基于阿里云机器学习PAI等产品于服务打造的AI创新项目脱颖而出，分享了价值11.6万美元的总奖金。阿里云机器学习PAI，灵活组合的产品体系，面向企业客户及开发者，提供轻量化、高性价比的云原生机器学习平台，涵盖交互式建模、拖拽式可视化建模、分布式训练到模型在线部署的全流程覆盖，百余种落地场景，全面提升机器学习工程效率。日前，AI体验馆全新上线，开发者们可以在线体验图像、语音、自然语言处理、视频等千亿参数预训练模型效果，支持一键部署，零基础也能轻松应用！点击免费体验更多机器学习功能体验，欢迎访问阿里云机器学习PAI官网点击图片查看Abdul-Hadi Hashim的分享视频

发表了文章 2021-02-24

AI体验馆上线！集成业界领先NLP场景深度迁移学习框架EasyTransfer

2020年10月，阿里云正式开源了深度迁移学习框架EasyTransfer，这是业界首个面向NLP场景的深度迁移学习框架。开源链接：https://github.com/alibaba/EasyTransfer目前集合该能力的AI体验馆已正式上线，免费体验：https://workbench.data.aliyun.com/experience.htm#/paiAbilityVenue/用户可以轻松点击，免费体验包括NLP（文章分类、内容审核）、图像分类、语音识别、视频分类、视频精彩集锦自动生成等能力！今天就带大家走进AI体验馆背后，揭开NLP领先技术的神秘面纱。EasyTransfer框架由阿里云机器学习PAI团队研发，让自然语言处理场景的模型预训练和迁移学习开发与部署更加简单和高效。面向自然语言处理场景的深度迁移学习在现实场景里有巨大的需求，因为大量新的领域不断涌现，传统的机器学习需要对每个领域都积累大量训练数据，这将会耗费大量标注的人力与物力。深度迁移学习技术可以将源领域学到的知识迁移到新的领域的任务，进而大大减少标注的资源。尽管面向自然语言场景的深度迁移学习有很多的需求，目前开源社区还没有一个完善的框架，而且构建一个简单易用且高性能的框架有巨大挑战。首先，预训练模型加知识迁移现在是主流的NLP应用模式，通常预训练模型尺寸越大学习到的知识表征越有效，然而超大的模型给框架的分布式架构带来了巨大挑战。如何提供一个高性能的分布式架构，从而有效支持超大规模的模型训练。其次，用户应用场景的多样性很高，单一的迁移学习算法无法适用，如何提供一个完备的迁移学习工具来提升下游场景的效果。第三，从算法开发到业务落地通常需要很长的链路，如何提供一个简单易用的从模型训练到部署的一站式服务。面对这三大挑战，PAI团队推出了EasyTransfer，一个简单易用且高性能的迁移学习框架。框架支持主流的迁移学习算法，支持自动混合精度、编译优化和高效的分布式数据/模型并行策略，适用于工业级的分布式应用场景。值得一提的是，配合混合精度、编译优化和分布式策略，EasyTransfer支持的ALBERT模型比社区版的ALBERT在分布式训练的运算速度上快4倍多。同时，经过了阿里内部10多个BU，20多个业务场景打磨，给NLP和迁移学习用户提供了多种便利，包括业界领先的高性能预训练工具链和预训练ModelZoo，丰富易用的AppZoo，高效的迁移学习算法，以及全面兼容阿里巴巴PAI生态产品，给用户提供一个从模型训练到部署的一站式服务。阿里云机器学习PAI团队负责人林伟表示：本次开源EasyTransfer代码，希望把阿里能力赋能给更多的用户，降低NLP的预训练和知识迁移的门槛，同时也和更多伙伴一起深入合作打造一个简单，易用，高性能的NLP和迁移学习工具。EasyTransfer工具的框架总览EasyTransfer的整体框架如下图所示，在设计上尽可能的简化了深度迁移学习的算法开发难度。框架抽象了常用的IO，layers，losses，optimizers, models，用户可以基于这些接口开发模型，也可以直接接入预训练模型库ModelZoo快速建模。框架支持五种迁移学习(TL)范式，model finetuning，feature-based TL, instance-based TL, model-based TL和meta learning。同时，框架集成了AppZoo，支持主流的NLP应用，方便用户搭建常用的NLP算法应用。最后，框架无缝兼容PAI生态的产品，给用户从训练到部署带来一站式的体验。业界领先的高性能预训练工具链和预训练ModelZooEasyTransfer框架支持工业级的分布式应用场景，改善了分布式优化器，配合自动混合精度，编译优化，和高效的分布式数据/模型并行策略，做到比社区版的多机多卡分布式训练在运算速度上快4倍多。基于这个高性能的分布式底座，框架推出完整的预训练工具链，方便用户预训练语言模型如BERT和ALBERT。值得一提的是，基于该预训练工具产出的模型在多个公开的榜单上取得好成绩，比方说多轮对话榜单QuAC第一名（2019年10月），中文CLUE榜单取得第一名（2019年12月），和英文SuperGLUE榜单第二名。同时EasyTransfer集成了预训练模型ModelZoo，支持BERT，ALBERT，XLNet等主流模型的Continual Pretrain和Finetune，也集成了在PAI平台上训练的高质量预训练模型和自研的电商场景多模态模型FashionBERT。丰富易用的AppZoo & 知识蒸馏EasyTransfer封装了高度易用、灵活且学习成本低的AppZoo，支持用户在仅用几行命令的条件下“大规模”运行“前沿”的开源与自研算法，即可迅速接入不同场景和业务数据下的NLP应用，包括文本向量化、匹配、分类、阅读理解和序列标注等。并且集成了丰富知识蒸馏算法，使得用户能从参数量大、推理速度慢的大模型中蒸馏出参数少、推理性能高的可上线的小模型。比方说，EasyTransfer集成了任务自适应蒸馏模型AdaBERT，从神经架构搜索（NAS）这个全新的角度出发，搜索出最适合目标任务的小模型架构，在6个NLP经典任务上，将BERT模型压缩到原来的1/17~1/10，推理加速达到原先的12 ~ 29倍。同时该模型相应论文已被AI顶级会议 IJCAI 2020 所接收。高效的迁移学习算法EasyTransfer框架支持所有主流的迁移学习范式，包括Model Fine-tuning, Feature-based TL, Instance-based TL, Model-based TL和Meta Learning。基于这些迁移学习范式开发了10多种算法，在阿里的业务实践中取得了良好效果的效果。后续所有的算法都会开源到EasyTransfer代码库里。在具体应用的时候，用户可以根据下图来选择一种迁移学习范式来测试效果。集成适应多任务的自研元学习算法EasyTransfer框架集成了基于元学习（Meta Learning）的多任务学习算法，支持用户在训练特定任务的模型时利用其他任务的数据集进行学习增强。EasyTransfer集成了自研的元调优（Meta Fine-tuning）算法，借鉴元学习的思想，旨在学习预训练语言模型跨领域的Meta-leaner，从而使得学习的Meta-leaner可以快速迁移到特定领域的任务上。该算法相应论文已被NLP顶级会议 EMNLP 2020 所接收。由于上述模型仍然具有参数量太大、推理速度慢的问题，EasyTransfer团队进一步自研了元知识蒸馏算法，在蒸馏阶段额外对Meta-leaner进行选择性蒸馏，使得蒸馏得到的小模型在相应的领域的效果显著提升，逼近原始模型的效果。相关的代码和论文会在近期发布。全面兼容阿里巴巴PAI生态产品EasyTransfer框架全面兼容PAI-Tensorflow，用户通过简单的代码或配置文件修改，就可以使用PAI自研高效的分布式训练，编译优化等特性；同时框架完美兼容PAI生态的产品，在PAI Web组件（PAI Studio），开发平台（PAI DSW），云原生训练平台（PAI DLC），和PAI Serving平台（PAI EAS）上均可直接使用。应用落地和创新的算法解决方案。EasyTransfer框架已在阿里集团内数十个NLP场景落地，包括智能客服、搜索推荐、安全风控、大文娱等，带来了显著业务效果的提升。目前EasyTransfer日常服务有上亿次调用，月均训练调用量超过5万次。EasyTransfer团队在落地业务的同时也沉淀了很多的创新的算法解决方案，包括元学习，多模态预训练，强化迁移学习，特征迁移学习等方向的工作，共合作发表了几十篇顶级会议文章，下面列举一些代表性工作。这些算法一部分已经开源，其他部分会在EasyTransfer框架里陆续开源供广大用户使用。[EMNLP 2020]. Meta Fine-Tuning Neural Language Models for Multi-Domain Text Mining. 2020.[SIGIR2020] FashionBERT: Text and Image Matching for Fashion Domain with Adaptive Loss. 2020.[IJCAI 2020] AdaBERT: Task-Adaptive BERT Compression with Differentiable Neural Architecture Search. 2020.[KDD 2019]. A Minimax Game for Instance based Selective Transfer Learning. 2019.[CIKM 2019]. Cross-domain Attention Network with Wasserstein Regularizers for E-commerce Search, 2019.[WWW 2019]. Multi-Domain Gated CNN for Review Helpfulness Prediction, 2019.[WSDM 2019]. Learning to Selectively Transfer: Reinforced Transfer Learning for Deep Text Matching. 2019.[WSDM 2018]. Modeling Domain Relationships for Transfer Learning on Retrieval-based Question Answering Systems in E-commerce. 2018.[ACL 2018]. Transfer Learning for Context-Aware Question Matching in Information-seeking Conversations in E-commerce. 2018.[ICDM 2017]. A Short-Term Rainfall Prediction Model using Multi-Task Convolutional Neural Networks. 2017.作者：岑鸣/葡萄

发表了文章 2021-02-24

知乎李大海对话阿里云贾扬清：透视AI应用难题与未来趋势

自AlphaGo接连战胜李世石与柯洁后，越来越多从业者将AI看做科技行业的未来。大大小小的AI公司兴起，国内外巨头公司纷纷加速向AI转型。但经历祛魅后的AI，在过去几年间却并未获得观察者们预想的火箭式爆发。“AI行业接下来可能有哪些发展？” “一线从业者如何看待其中的机会？”知乎合伙人、CTO李大海与阿里巴巴副总裁、阿里云智能高级研究员贾扬清亮相知乎直播，与网友分享了他们对AI时代下行业趋势、技术应用、个人成长等多个层面的洞察和思考。谈海内外异同，国内关注技术落地，海外试错造就新机会AI浪潮席卷全球，但国内外发展则各有所长。贾扬清在入职阿里巴巴前，曾在Facebook担任研究主任，领导研究团队为所有Facebook的应用程序构建大型通用AI平台。李大海则于2006~2010年在Google任职高级工程师。两位嘉宾均在国内外科技公司任职多年，这一经历也造就了两人宽阔的横向视野。正因如此，在面对主持人开场提出的“在AI研发和应用方面，国内科技企业和硅谷公司有哪些差别？”这一问题时，贾扬清、李大海观点一致：国内科技公司和硅谷同行们的相近之处在于从业者都很用功，对前沿技术突破都有追求。差异点在于，国内公司较关注把方法和业务结合起来，更为看重技术落地；而硅谷公司为员工纯粹的技术好奇心提供了更大试错空间，“不经意洒下的种子”往往创造出意想不到的产业机会。谈发展趋势，从AI感知到AI决策的螺旋前进AI相关话题持续火热，仅在知乎上，“人工智能”话题就有超过150万人关注。但对于“AI行业目前发展到哪一阶段，是否看好”，吃瓜群众们一直众说纷纭，甚至就连一线从业者也有不同观点。有人认为目前行业概念先行，充满泡沫。也有人认为AI已有长足进步，未来3-5年发展可期。对于这一话题，李大海表示，如果要判断AI的发展阶段，那么首先需要了解发展的全景是什么，而现在还很难预测人工智能最终能发展到什么程度。对人工智能是否能达到“强人工智能”（即完全通过图灵测试，有意识、能进行情感层面的表达）他本人也持悲观态度。但他更看好AI作为生产工具的应用空间，“大家所认为的泡沫其实是AI企业在探索商业模式过程中困境，但AI作为生产工具越来越强大，这是毋庸置疑的”。贾扬清认为，AI发展最开始试图绕过“感知”层面直接解决“决策”层面的问题，但事实上这条路走不通。随后，AI行业开始专攻“感知”领域，发展到现在已经较为成熟，比如，AI的图像识别能力已经远超人类；眼下，如何解决“决策”层面的问题，再次成为攻克的方向。“比如说，自动驾驶领域已经进化到可感知到周围的人与车，但难点则在于，怎么在不同条件下做出决策，规避感知到的障碍，这些问题更有挑战性”。谈个人成长，上手能力很重要，AI人才正在“业务化”AI作为最有前景的高科技行业，也创造了大量就业岗位，并且吸引了众多程序员“转型”。在直播中，AI行业的职业成长问题也成为网友关注焦点。对于网友“工程AI与算法AI哪个更有从业前景？”的提问，李大海表示，随着技术迭代，未来AI的从业能力门槛会越来越低，相比“选A或者选B”这样的算法积累，工程师的基础能力和学习能力更加重要。工程师需要具备 “T字形思维”，一横代表处于平均水平线之上的动手能力，一竖则代表快速学习能力，能根据业务需求进行针对性的技能提升，才是工程师的立身和进阶之本。贾扬清则借此提出一个大胆的观点。他认为行业不存在算法工程师的角色。换言之，未来行业只有两个角色，一个是算法研究人员，一个是应用工程师。而只会做简单适配的“调参侠”是没有市场的。针对“AI工程师如何进阶，如何能够脱颖而出”的问题，贾扬清表示，当下的算法已经像工具一样普惠化，AI在算法层面的创新正在变缓。因此实现AI的突破，需要算法、系统、应用并行。如何找到实际应用场景，往往最能体现个人价值。李大海则认为，在实际工作过程中AI是一个系统工程，“往往工程师90%的工作都跟算法无关”。当下，业界较为成功的人或者团队都在“业务化”，相比单纯钻研算法，更重要的是了解用户需求，并解决实际问题。两位大咖在知乎的这场直播对话吸引了众多科技圈及AI圈从业者的关注，也引发知乎用户在站内的二次讨论。事实上，在知乎直播平台，活跃着大量各领域专业人士与多元话题，从毕志飞与王瑞恩的直播辩论，到张亮与许先哲的文化对谈，他们在文字分享之外，通过直播形式讲述见解，分享真知，直播也成为了知乎专业内容生产与消费的重要场景。点击查看大咖对话视频来源 | IT168 作者 | 姜惠田

发表了文章 2021-02-19

阿里云PAI平台模型压缩技术落地淘宝直播双十一应用：一猜到底

随着移动端应用的兴起，应用安装包的压缩技术已经愈发成熟，在4G网络时代就可以轻松下载，我们手机上安装了各种各样的应用APP也依旧运行顺畅。模型压缩也是类似的效果，机器学习从理论研究逐渐尝试技术落地，AI工程化也成为趋势，模型压缩作为深度学习模型实现轻量化部署的有效手段，备受关注。简单来说，模型压缩就是在尽可能不改变模型效果的情况下，减少模型的体积，使得模型有更快的运行速度，帮助减少深度模型端侧部署的资源消耗。在2020年阿里双十一期间，淘宝直播APP上线的“一猜到底”语音交互游戏中，阿里云机器学习PAI平台的模型压缩技术体现了关键作用，在端智能应用场景实现了端侧智能的应用落地。“一猜到底”游戏背后的模型压缩技术淘宝直播APP上线的 “一猜到底”游戏：由当红主播现场推荐商品，粉丝以“语音猜价”形式参与互动。全新的互动形式搭配双十一，上线后带来一波疯狂上涨的流量，对模型性能和工程化能力要求极高。图1 淘宝直播“商品价格竞猜游戏”: 1) 在淘宝直播找到“一猜到底”; 2) 首席猜价官吴佳煜; 3) 游戏现场，薇娅直播;经过阿里多个技术团队打磨，“一猜到底”游戏已经成为端侧落地的成功案例，能够经受住淘宝直播高访问流量的严格考验。语音识别（ASR）技术，在准确率（Low Error Rate）和高实时率（High RTF）都有很好的表现。在此基础上，PAI团队提供了行之有效的模型压缩支持，在帮助压缩模型的同时、保证了语音识别的高准确率，并显著降低了模型在移动端部署时的ROM/RAM/RTF，即参数存储、运行时内存与实时率开销。PAI模型压缩：混合精度量化技术模型压缩是PAI云端一体解决方案的重要环节。如图2所示，在移动端智能语音的E2E优化部署链路中，PAI模型压缩技术（混合精度后量化、量化训练、稀疏训练等）起着模型瘦身、复杂度降解的关键作用。图2 PAI模型压缩在E2E链路中的关健作用图3 SAN-M模型结构: 由特征驱动的Self-Attention、与训练驱动的DFSMN记忆单元相结合，实现全局相关性与局部相关性特征的有效融合基于PAI团队研发的混合精度量化方法，有效实现了Transformer ASR（SAN-M）模型的离线后量化（PTQ：Post-training Quantization），主要创新点包括：• 支持端到端Transformer的离线后量化，相比于拆图量化、量化训练等方法，端到端后量化具备快捷、高效的优势，能够帮助用户一键部署量化方案；• 集成了丰富的后量化策略，为后量化的精度鲁棒性提供了坚实保证；• 无Label干预的混合精度量化流程，无需提供数据标注，且能准确反映逐层量化的敏感度；PAI模型压缩：支持端到端Transformer的离线后量化由于Transformer模型存在自回归循环解码操作，较难直接获取解码器中的张量数据，因此现有的模型压缩框架和推理优化工具，鲜少支持端到端Transformer的离线后量化。如图4所示，PAI团队的后量化方法，引入了循环张量探针（Tensor Probe）的使用，能够有效支持端到端Transformer的离线后量化。循环体内的张量（Tensor）通过若干个延迟单元的传输，构成了不同时刻的信号汇总。这些信号数据导出之后，便可有效支持离线量化参数的统计计算（KL、MSE或Cosine距离最小化等策略）。图4 循环张量探针（Tensor Probe）的使用PAI模型压缩：集成了丰富的后量化策略在执行Transformer模型的逐层量化（Layer-wise Quantization）时，每个网络层的输入/输出张量、以及网络权重的量化，都会引入量化噪声，主要包括Round误差、Clip误差。图5 逐层量化引入的量化噪声PAI团队的后量化方法，集成了多种可改善量化效果的PTQ策略，允许用户在Post-training阶段妥善解决量化误差问题，以避免进一步使用量化训练（QAT：Quantization-aware Training）等繁重方法。具体的PTQ策略，包括改进的KL算法、EasyQuant、Bias Correction、ADMM等：• KL算法的改进，能够有效减少输入/输出张量的量化噪声；并且可以根据Activation的数据分布，自动选择最佳KL策略；• EasyQuant（参考文献 [1]）的使用，可进一步减少输入/输出张量的量化误差，尤其能改善INT7等更低精度量化的效果；• Bias Correction（参考文献 [2]）通过网络权重量化偏差（均值与方差的偏差）的补偿，减少权重量化噪声；同时对Bias Correction的适当改进，增强了对达摩院Transformer ASR的补偿效果；• ADMM（参考文献 [3]）亦可优化权重量化参数，减少权重量化噪声；也适当改进了ADMM的使用，从而在交替方向迭代范围内，确保权重量化误差最小；• Weight Adjustment（参考文献 [4]）在Kernel weight按Per-tensor量化时，通过Per-channel形式的等价均衡变换，可以减少Weight量化误差。PAI模型压缩：无Label干预的混合精度量化流程如图6所示，基于多种后量化策略的有效集成，PAI团队提出了Label-free混合精度量化流程（Label-free AMP Pipeline, AMP：Automatic Mixed Precision）：• 该流程从模型输入到混合精度决策，无需数据标注（Label）的干预，简洁易用、快捷有效；• 量化误差按逐层统计，并能准确表示每个网络层的量化敏感度，为混合精度（INT8/FP32混合）决策提供了有效基础；• 通过把控回退的网络层数，可选择出精度与模型容量折中最佳的帕累托最优解，完成多目标优化；• 生成的混合精度量化表，能够对接移动端推理框架MNN，以生成低延迟、高推理精度的运行时推理引擎；从而构成了完整的工具链路，即从混合精度量化、到移动端的推理部署；• AMP Pipeline不仅适用于移动端，也适用于CPU/GPU优化部署，体现了PAI云端一体的优势所在。图6 Label-free混合精度量化流程（Label-free AMP Pipeline）基于AMP Pipeline，在移动端部署Transformer ASR模型时，通过回退Op数的把控，可以实现WER (SER)与ROM/RAM (RTF)之间的合理折中，妥善解决多目标优化问题。需要注意的原则主要有：• Model size、Latency与内存占用等，都会随着回退Op数的增加而增加，通常可以视作统一的目标函数，并以回退Op数作为自变量；• 在相同的Pareto front上，回退Op数越多，通常WER越低、Model size越高，因此需要折中选择；• 不同的Pareto front (取决于PTQ策略的改善效果)，回退相同的Op数，达到的折中状态有所不同；参考图7所示的Pareto fronts，都回退Op1，Pareto2的状态、优于Pareto1的状态；• AMP目标：采用更有优势的PTQ策略，得到更好的Pareto front，为混合精度择优提供有效基础；图7 两种Pareto front的对比下表展示出了双十一使用的Transformer ASR模型，在众包测试集上的精度表现，包括FP32、全INT8、AMP INT8的对比。相比于原浮点模型，经过AMP INT8量化之后（回退3个Op，分类层保留为FP32实现），ASR模型的WER绝对损失低于0.1%、SER绝对损失低于0.5%、理论压缩比约为3.19倍。并且，量化模型对Bad case也体现出了较强的鲁棒性，助力淘宝直播“价格竞猜游戏”经受住了直播场景的严格考验。表1 双十一模型在7K众包测试集上的表现PAI模型压缩简介离线量化相关的策略（包括PTQ/AMP等），已集成至Blade；并且支持随机稀疏压缩与PTQ叠加使用，例如60%稀疏度时，叠加INT8量化、压缩比可达6.6倍左右；除了离线后量化之外，在诸如量化训练、网络剪枝、权重稀疏化与模型结构搜索等模型压缩领域，PAI团队也长期坚持耕耘。其中量化训练、稀疏训练与网络剪枝的产品化体验，可参考PAI用户手册。以量化训练为例，PAI与阿里MNN团队合作提出了Winograd INT8量化与计算加速技术、并发表了合作论文 [5]。在下游迁移阶段，针对带有一维卷积（kernel size>=3）的ASR模型，经过Winograd INT8量化训练，能够有效确保ASR模型的量化精度鲁棒性，并进一步实现了一维卷积在移动端的INT8计算加速。从PAI量化训练、到MNN移动端优化部署，同样构成了完整的量化/优化工具链路。图8 从大规模预训练、到量化微调、再到优化部署的工具链路机器学习PAI平台面向企业客户及开发者，提供轻量化、高性价比的云原生机器学习平台，涵盖交互式建模、拖拽式可视化建模、分布式训练到模型在线部署的全流程覆盖。内置200+成熟算法、图像视觉、音视频、文本等AI领域高质量深度学习预训练模型50+，帮助开发者快速构建AI业务方案，全面提升机器学习工程效率。目前已在游戏、社区、媒体、广告平台的搜索推荐、多媒体内容处理、自动驾驶等多领域商用。全新官网：https://www.aliyun.com/product/bigdata/product/learn扫码加入PAI钉钉交流群，最新干货资料等你来参考文献：[1] Di Wu, Qi Tang, Yongle Zhao, Ming Zhang, Ying Fu, Debing Zhang, "EasyQuant: Post-training Quantization via Scale Optimization", arXiv preprint 2006.16669, 2020.[2] Ron Banner, Yury Nahshan, Elad Hoffer, Daniel Soudry, "Post-training 4-bit quantization of convolution networks for rapid-deployment", arXiv preprint 1810.05723, 2018.[3] Cong Leng, Hao Li, Shenghuo Zhu, Rong Jin, "Extremely Low Bit Neural Network: Squeeze the Last Bit Out with ADMM", arXiv preprint 1707.09870, 2017.[4] Markus Nagel, Mart van Baalen, Tijmen Blankevoort, Max Welling, "Data-Free Quantization Through Weight Equalization and Bias Correction", arXiv preprint 1906.04721, 2019.[5] Yiwu Yao, Yuchao Li, Chengyu Wang, Tianhang Yu, Houjiang Chen, Xiaotang Jiang, Jun Yang, Jun Huang, Wei Lin, Hui Shu, Chengfei Lv, "INT8 Winograd Acceleration for Conv1D Equipped ASR Models Deployed on Mobile Devices", arXiv preprint 2010.14841, 2020.作者：益武、小豌、莱茵、熊兮、嘀豆、执真、临在、穆琢

发表了文章 2021-01-14

基于Flink的机器学习算法平台 Alink（二）推荐算法介绍

一、Alink介绍（一）整体介绍什么是Alink？  Alink是基于Flink的机器学习算法平台 1）由阿里巴巴计算平台事业部PAI团队研发； 2）同时支持批式/流式算法，提供丰富的算法库； 3）帮助数据分析和应用开发人员能够从数据处理、特征工程、模型训练、预测，端到端地完成整个流程。  相关名称的公共部分 Alibaba，Algorithm，AI，Flink，Blink （二）和SparkML对比 SparkML是目前市面上使用较为广泛的机器学习的库，下面从性能和功能两个方面对Alink与SparkML进行比较。1、性能对比Alink与SparkML性能对比图上图为开源Alink与SparkML算法运行时间对比，纵坐标为各类算法，横坐标为运行同一算法时，SparkML相较开源Alink所花费的时间倍数。由上图可看出，在大多数情况下，开源Alink比SparkML效率更高。 2.功能对比Alink与SparkML功能对比图由上图可知，Alink拥有SparkML支持的大多数功能。在此基础上，Alink还支持流式算法、批流混跑、在线学习与中文分词等SparkML不具备的功能，Alink功能种类更丰富与齐全。（三）算法调用方式1.Link Link是批式/流式算法通用的串联方式。下方为三个Alink搭建的实验：批示实验，流式实验，批流混合实验。批式实验（Batch Experiment）流式实验（Stream Experiment）流批混合实验（Batch-Stream Mixed Experiment） 2. Python 脚本调用Alink算法除了用Web的方式，还可以用写脚本的方式调用Alink，用脚本完成机器学习的训练与预测，Demo如下：二、Alink 推荐 Demo （一）基于 Alink 推荐算法线上服务流程图在线上服务的时候，首先需要召回有用数据，例如真实用户关心的商品，或者相近的商品数据，然后针对商品做特征拼接，接着进行特征编码，最后通过排序算法得出结果，将排序比较靠前的推荐给用户。针对线上服务流程，Alink能提供什么帮助？如下图所示：针对线上服务，在离线模型中，Alink对召回、特征拼接、特征编码、排序等流程对应提供了多种算法。在线模型中，Alink支持在线学习，实时训练模型，不断将模型部署到线上，实现模型更高更快时效性。（二）影片推荐Demo 接下来，以影片推荐Demo为例介绍一下算法的使用。1.数据集介绍我们在Moivelens网站上采集了不同时间段的电影观众的评分，做出了以下数据集：如上图所示，这个数据集包括了User的ID，Movie的ID，还有观众的打分。下面针对这个数据集，我们来看Alink算法是如何实现对电影的推荐。 2.ALS训练模型（ALS model training）ALS训练模型脚本Demo 上图为ALS训练模型的脚本Demo。得到一个数据集后，它会Link ALS的训练算法，在算法里面设置User、Item还有Rating列名，然后设置一些参数，包括Lambda，Rank，NumIter。下面第二个Link是将它写到对应的目录中，这个目录可以是本地的环境目录，也可以是网络文件的目录，Alink都是支持的。然后加上执行代码后，脚本就可以直接执行。训练完数据集Train_set对应的模型后，最后写到对应的目录中，以上就是ALS训练模型的一个简单脚本。 3. 使用ALS模型求TOPK的电影（topK movie with ALS model）下面解析ALS模型如何实现对电影进行求TOPK。使用ALS模型求TOPK的电影通过上图脚本可以看到，首先通过创建一个Pipeline Model，然后ALS模型通过Source组件将它读取，设置到Pipeline对象中。接着设置User的列，设置Top的数量（如Top10），然后设置推荐的列名，最后通过Transform就可以得到推荐电影数据，推荐数据如下：例如对43号电影，这边推荐了与它最相近的10部电影与相应的打分。 4. 使用ALS模型对电影打分（Rating movie with ALS model）ALS实现电影打分Demo 如何得到每位观影的User对所看电影的打分数据。通过上图可以看到，这里使用的方法与之前类似，首先建一个Pipeline Model，然后设置打分组件，接着设置User、Item、Recomm的列，最后设置ALS模型，完成模型录入。第二个组件KeyToValue，它将电影的ID对应到电影的名字。通过上述两个组件，可以得到用户和用户对电影打分的结果。例如下图，是用户1对各个电影的打分情况Rating以及系统推荐的分数Recomm。打分之后希望看到打分效果，于是接了评估组件EvalRegressionBatchOp，如下图所示： EvalRegressionBatchOp组件相当于将打分结果跟真实结果做一个回归对比，下方是它的一个MSE和RNSE的结果，可以看到用ALS对数据进行打分的话，效果十分不错。 5.基于物品的协同过滤——模型训练接下来介绍基于物品的协同过滤算法训练模型，调用方式与ALS类似，Demo如下：首先在脚本中设置对应的模型与参数，然后linkFrom对应的打分数据，接着将它放到Pipeline Model，最终执行就完成了。这样数据对应的模型渲染出来，并将它存到对应的pipeline_model.ak中。 6. 基于物品的协同过滤——推荐预测如果有这个模型，如何用它来做推荐预测？如上图左边所示，首先用Pipeline_lodel可以Load函数，然后给出对应的文件路径。这样的话就将模型Load到内存中，然后Transform就可以将对应的数据集进行推理预测。右边为输出结果。 7.基于物品的协同过滤——Java/Python LocalPredictor预测训练模型最终要部署到线上，这边提供了LocalPredictor机制，它支持Java与Python接口。在Java或Python环境下，直接通过LocalPredictor就加载模型，然后模型可以通过Map函数完成推理的操作。有了Python和Java这两个接口，我们可以在相应的环境下部署想要的一些服务。（三）Click-Through Rate Prediction DEMO 在网络广告中，点击率（CTR）是衡量广告效果的一个非常重要的指标。因此，点击预测系统在赞助搜索和实时竞价中具有重要的应用价值。该Demo 使用 FTRL方法实时训练分类模型，并使用模型进行实时预测评估，展现了在线学习的能力。上图为一个经典的数据集，有一些是字符串，有些特征是对应的数值性。如何针对这个数据集去做在线学习呢？在线学习流程图该流程存在四个问题： 1）如何进行特征建模？ 2）如何训练初始模型？ 3）如何进行在线训练和预测？ 4）如何对结果进行评估？ 1.如何进行特征建模？上图为脚本Demo，首先对原始数据做标准化操作，然后对这数据链做了一标准化操作，之后通过FeatureHash将它映射到数组中，生成一个Pipeline，Fit将整个数据相进行特征工程训练，训练出模型。 2.如何训练初始模型？ FTRL本质上是Online的逻辑回归，初始模型调了逻辑回归组件，通过设置参数，以LinkFrom方式对数据训练，最终完成初始模型的训练。 3.如何进行在线训练和预测？在线训练和预测主要分为三步，第一是准备流数据，第二是FTRL算法实时更新模型，第三是对实时数据进行预测，对应Demo如下：准备流数据 FTRL算法实时更新模型对实时数据进行预测 4.如何对结果进行评估？如上图所示，得到模型之后，希望对模型进行评估。通过 EvalBinaryClassStreamOp组件，就可以完成对模型的评估操作。上图下方为得到的评估指标，可以根据相应的信息去考虑这个模型是否要部署到线上。（四）Web Demo 上方为脚本的方式，这边用Web的方式也可以实现这样的操作，操作流程图如下： Alink支持大屏显示，实时结果写一个数据库中，大屏会实时读取数据库的数据进行展示，如下图所示：图上方为评估结果，下方为AUC曲线和准确率曲线。我们也可以直接对模型进行评估，而不是预测，如下图所示：当FTRL训练完模型，会有一个实时的评估组件，组件对模型进行评估。这里要注意的是，两个特征工程调用的是同一个特征模型。FTRL模型过滤参数配置（分享人：赵伟波）第一期分享内容《基于Flink的机器学习平台Alink》云原生场景中的AI调度欢迎加入机器学习PAI钉钉群交流！

发表了文章 2020-12-28

基于Flink的机器学习平台Alink

一、Alink是什么 1.1 Alink介绍 -Alink是基于Flink的机器学习算法平台 1）由阿里巴巴计算平台事业部PAI团队研发； 2）同时支持批式/流式算法，提供丰富的算法库； 3）帮助数据分析和应用开发人员能够从数据处理、特征工程、模型训练、预测，端到端地完成整个流程。 -相关名称的公共部分 Alibaba，Algorithm，AI，Flink，Blink 1.2 Alink开源 Alink自2019年11月开源至今，共发布以下4大版本： -Alink v1.0 1) 2019年11月 Alink v1.0.0 Flink Forword Asia大会上宣布开源；支持Java接口和Python接口(PyAlink)。 2) 2019年12月 Alink v1.0.1 解决一些场景下PyAlink的安装问题；更新算法文档。 -Alink v1.1 1） 2020年2月 Alink v1.1.0；支持发布到Maven中央仓库和PyPI； PyAlink兼容PyFlink，改进UDF / UDTF功能；支持多版本的Kafka数据源。 2） 2020年4月 Alink v1.1.1 提升使用体验，在参数检查方面更加智能。 3） 2020年6月 Alink v1.1.2 新增30余个数据格式转化组件；支持多版本Hive数据源； Pipeline和LocalPredictor支持SQLSelect操作。 -Alink v1.2 2020年7月 Alink v1.2.0 支持多文件系统； CSV格式读取、导出组件支持各文件系统；推出AK格式读取、导出组件，简化文件数据的操作；支持模型信息摘要、输出；增加FM分类、回归算法。 -Alink v1.3 2020年12月 Alink v1.3.0 增加ItemCF、UserCF等推荐算法；增加向量和文本相似度算法；插件化catalog和文件系统；丰富model info功能；改进Pipeline存储和导入；增加测试工具模块，优化测试体验。丰富的数据库 1.3 开源Alink与SparkML对比上图为开源Alink与SparkML算法运行时间对比图。纵坐标为各类算法，横坐标为运行同一算法时，SparkML相较开源Alink所花费的时间倍数。由上图可看出，在大多数情况下，开源Alink比SparkML效率更高。二、Alink如何使用 2.1 Alink使用方式有两种使用方式：Link与Pipeline。下面通过一个例子展现两种使用方式的区别。 Link Link是批式/流式算法通用的串联方式。如上图所示，当得到训练数据后，训练数据进行了一次VectorAssembler，将多个列合成一列Vector. 数据处理完成后进行PCA的训练，训练结束后做PCA预测。预测数据做PCA预测时同时做Assembler，目的在于与训练数据保持一致，PCA预测结束后打印出结果。上述例子通过Link与Pipeline实现具体过程如下： Link Pipeline 2.2 Alink支持多种数据源 Alink还有一个优势是支持多种数据源。它支持文件系统数据源与Catalog数据源，文件系统数据源包含HDFS、OSS、Local等，Catalog数据源包含Hive、Mysql、Derby等。这里需重点注意Local。Lcal为本地数据文件系统，如果在本地运行时，就可以使用它去进行测试。 Alink支持多种数据源的优势在于，当用户在使用时，面对不同的数据源不需要将数据导来导去，直接在Alink中区别对应数据源，然后将相应数据写到对应的Sink中去。 2.3 Alink运行当算法与数据源准备完毕后，可以开始运行代码。运行代码可分为开发与部署，相当于本地运行与集群运行。在开发阶段，可以先用一个小数据集进行本地运行测试，快速验证过程与效果是否正确无误。当本地运行测试无误后，可以提交到集群，运行大规模数据。本地运行与集群运行的代码只有些许差异，具体代码如下。本地运行：useLocalEnv 集群运行：useRemoteEnv 2.4 LocalPredictor 集群运行之后，需要进行线上推理，流程图如下图所示。数据会在分布式集群系统中进行模型训练，然后将模型存储到文件存储系统或其他Sink里，接着将模型推到线上服务系统进行线上服务，该过程在Alink实现过程如下： Alink使用LocalPredictor有个显著的优势，当用户在开发过程中，它使训练过程、线上预测与线下预测等数据保持一致。三、Alink进阶上面介绍了Alink的算法、数据源、运行与部署，那如何进行开发？开发的过程中有哪些技巧可以使用呢？ 3.1 利用提示和报错信息 -利用提示查看算法相关Op, 可以查看Op和Pipeline。举个例子，Alink支持6种数据格式，包括Vector、Triple、Json、Columns、Kv以及Csv，这六种格式可以根据实际需求相互转换。如果要去做数据转换的时候，该如何找这个名字？例如要将Columns转换成Csv，就输入Columns，那么跟Columns相关的所有算法都会出现，直接选择想要转换的算法即可，如下图所示。这种方式提升了转换算法的效率，解决了用户在数百个算法中寻找的困扰。 -利用提示查看算法支持的参数。每个算法拥有不同的参数，该如何设置参数？ Alink里的参数均以Set开头，举例如下图所示：先将算法名字OneHotEncoder写上，然后写上set，那么相关的这种参数则会罗列出来供用户选择。 -枚举变量，使用JAVA，有枚举值的提示。如果 Python的话，也可以通过下图的报错信息来看这个值到底应该怎么填。以之前为例，ChiSqSelectorBatchOp里面有一个变量是SelectorType表示筛选类型，因为用户不清楚所以输入“aaa”，运行之后算法抛出来异常，表示“aaa”并不是SelectorType里的成员。它可能的值为NumTopFeatures、PERCENTILE、FPR、FDR、FWE，此时用户可以选择自己需要用的方法填入相应的值即可。 Alink对列名异常也做了一些优化。如果列名输错了，行为是怎么样的？如上所示，这个数据里面列是ID跟Test，当用户添了一个“text 1”，运行之后系统报错表示“text 1”无法找到，并提示“do you mean : text ?”，使得用户可以去查找相似列名。 3.2 查看训练信息接下来介绍如何查看训练信息、模型信息，评估信息等，有些算法有丰富的训练信息可以帮助进行正确性验证，可能会输出每一轮的Loss、学习率，特征重要性、权重等等。 -Loss、学习率，特征重要性、权重以上面为例，先定义逻辑回归算法Op，设置参数，使用lazyPrintTrainInfo可以将打出训练过程信息，lazyCollectTrainInfo可以在中间函数选择需要打印的信息。上图为运行结果，显示了Loss、GradNorm、learnRate相应信息。下方的train importance info包含模型的特征重要性，用户可以根据实际需求打印。 -通过训练流程得到的模型，不只是用于推理服务，也可以帮助诊断流程。以上面为例，与之前的TrainInfo非常相似，在后面PrintModelInfo之后系统会打印model信息，在这里可以查看选择列、label值、categorical变量、gaussian变量以及模型等相关信息。还有一些其他的这种信息。 -对于复杂的模型，还可以提供更形象化的模型展示。复杂的模型信息较多，例如树型结构。这种情况可以用lazyCollectModelInfo将图saveTreeAsImage，则会得到一个清晰的树状图，用户一目了然。 3.3 查看模型评估结果 -模型评估涉及到复杂的计算； -信息量大 -需要繁琐的处理 3.4 Op和DataFrame互转 PyAlink提供了与pandas DataFrame的互转操作，能够方便的使用python生态中已有的工具。 3.5与PyFlink一同使用 -PyAlink新增了getMLEnv的接口，直接获取PyFlink的执行环境； -Table和Op互转。（分享人：品一）欢迎加入机器学习PAI钉钉群交流！云原生场景中的 AI任务调度基于Flink的机器学习算法平台 Alink（二）推荐算法介绍

发表了文章 2020-12-23

云原生场景中的 AI任务调度

一、AI任务的需求与DLC1.1 AI产品应用云原生场景里面的AI任务到底是什么样的？现在的AI任务，已经广泛的应用到各种各样的产品，是生活中不可或缺的一部分，如语言翻译、淘宝上拍立淘识别商品、天猫精灵人工智能助手等。此外还有在产品背后呈现的AI技术，如淘宝上跟据用户兴趣精准推荐用到的推荐系统和广告系统，也是AI技术。可以说，AI已经渗透到了业务产品中的方方面面。 1.2 AI任务运行平台在阿里云平台上运用AI任务三大优势：云原生、弹性、线性加速。云原生完全基于云的基础设施，如Kubernets-native平台容器化，在各种各样的机型上都支持AI的任务，各种机器的用户均可使用。如果用户对于资源要求较高，可以用SLA有保证的机型，如果用户对价格比较敏感，可以用Spot Instance这种价格会波动的机型。借助云原生的力量，使得AI可以做到开箱即用。弹性支持半托管和全托管的计算资源，用户在使用计算资源上，比如需要做AI任务，用相应的机器和完整的全套技术栈，把AI任务做完；而当业务不需要计算资源的时候，也不用支付资源的费用，通过全托管去相应控制。半托管和全托管，给到用户不同的资源控制选择。线性加速结合阿里巴巴内部使用AI计算的平台上优化的经验，我们的系统可以为AI任务提供线性加速能力，这通过通过云上通信优化，以及包括AI模型的数据并行、模型并行等方面的工作来完成，属于深度学习引擎框架层的范畴。 1.3 AI任务的独特性关键词：异构计算资源、多种框架AI任务不同于在云上常见的服务计算或大数据计算任务，AI任务有自己的独特性。 1）AI用户会使用异构计算资源。现在较为通用的是GPU。GPU提供更强的算力，但价格较为昂贵，典型的GPU机型价格是 CPU机型的10倍。因为GPU的广泛应用，出现新的异构通信链路，如英伟达的GPU使用 NVLINK进行GPU之间的通信。机器间的通信方式是使用RDMA,可以bypass远程的 CPU进行通信。随着数据量越来越大，大规模的分布式计算才能满足很多用户的这种大数据计算诉求。这些是从计算资源与底层硬件的角度来看AI任务的独特性。 2）AI任务是多种框架，现在用的框架非常的多，AI是比较笼统的称谓，里面包括深度学习、相对传统意义点的决策、AI的算法，还有为特定应用开发的框架。如X-DeepLearning是阿里巴巴广告团队开发的深度学习框架,在广告领域使用效果优秀。 1.4 云原生深度学习平台DLC架构为了在云上支持AI任务，我们设计了DLC产品，DLC呈现的技术架构如下图所示：首先它是建立在云原生的ECS Clusters上面的，通过在原有的支持K8s的ACK的集群添加相应的DLC的组件，使得它可以变成DLC的集群，于是它可以直接拥有相应的AI能力，包括对AI任务的提交控制能力、享受对应的框架层和系统层的优化。整体架构图如下：最上层提供DLC Control Panel提供相应的管控、弹性支持，使得用户可以很容易在上面提交自己的任务，做到开箱即用。中间核心层则由PAI-Tensorflow与PAI-PyTorch两个框架进行支持。我们提供深度定制的深度学习框架，在兼容社区的基础上做了进一步的优化，结合阿里内部的场景进行锤炼，其能力通过云上的方式输出，让更多的用户直接用上优化的效果。因为GPU很贵，比如加速两倍，就相当于节省一半的 GPU的资源，这对用户来说非常重要。 KubeDL Pro的CRD底层会结合在ALIYUN Cloud Kubernets的调度、容器化、GPU共享、Quota相关的优化，使得用户可以用较为便宜的方式使用资源，比较高效使用上 AI硬件这种独特的通信，还有计算的能力等。底层是支持现有的云原生的所有机型、通信还有存储方式。二、KubeDLKubeDL三大特性： 云原生支持AI； 易扩展支持更多AI workload； 机器学习能力统一扩展。 2.1 云原生支持AI 为了能够在云原生的场景里面支持AI，我们跟阿里云团队一起合作开发了KubeDL任务提交组件，采用All-In-One的理念，使得可在一套通用开发operator上支持TensorFlow、PyTorch等典型的深度学习计算任务提交，也支持稀疏模型、树模型等典型框架，如下图所示：它有三大特点：第一,提供Unified Operator，兼容所有主流的框架，沉淀通用调度的能力。第二,是通过插件化的调度能力，使得其可以非常容易的适配各种底层不同的调度器，提供相应的功能，如对AI来说很重要的GANG Scheduling。第三,把代码和基础镜像做了一个解耦，使得做算法的同学只需专注代码问题，底层问题由我们解决。第四，提供相应的Dashboard和监控的Panel，可以提供全周期任务的监控，白屏化整个管理流程。以上内容已在GitHub上面开源，可扫图中的二维码查看。 2.1易扩展支持更多AI workloadKubeDL可以做一些针对性的扩展，支持更多的AI workload。经典案例·大规模的工业界的图神经网络分布式框架GraphLearn。 GraphLearn框架目前已经应用在淘宝的搜索推荐里面。使用淘宝的用户都有这种体验，淘宝会根据用户平时刷淘宝看到的相关物品，通过浏览记录和购买记录，推荐相似物品，其背后都是一套图神经网络。它会分析用户的浏览，还有商品之间的特性，从而把图信息嵌入到深度学习里面，从而推断用户兴趣爱好，而图神经网络是目前深度学习中的热门流派。上图是一个典型的TF任务，采用PS-worker架构，PS节点主要用于存储模型，对应的还有Work节点，它通过加载数据，从Ps节点上面获取相应模型，对数据在模型上做计算，最后把计算结果更新到模型之上来完成一个迭代训练流程。云原生场景里面对于TF-Worker的支持，最早是属于TF-Opreator开发，现在KubeDL上面也可跟社区一样兼容对于TF任务的提交方式。随着图神经网络在更多的领域得以广泛应用，我们也想把图神经网络的能力跟TF结合，这里引入GraphLearn-Server角色概念。不同于TF-Worker和TF-PS的计算节点，它通过把图数据进行预处理，还有图分割的相关操作，允许用户通过编程方式进行采样、聚合等操作，把最后结果同时反馈到TF-Worker，联合进行深度学习训练。 GraphLearn是一个图神经网络框架，如何在云原生场景里面加入这个角色，使得它可以跟已有的TF很容易工作起来。而GraphLearn也有自己的要求，它在启动顺序上有需求，即图神经网络要求GraphLearn必须比TF-Worker 先启动起来，当Worker处理的时候，能够得到 Server相应的响应。GraphLearn还基于一套不同于TF的地址发现机制，需要在KubDL里面能够一并进行支持。 KubDL的架构设计较为完善，把启动顺序进行了相应的抽象，添加GraphLearn的角色并达到上述功能可以很轻松的完成。我们总共仅需要10+行代码改动，就可以完美支持图神经网络。 2.3 KubeDL：机器学习能力统一扩展经典案例·GANG Schedule我们还是沿用图神经网络的场景来介绍GANG Schedule的问题，在引入图神经网络节点之后，有别于社区的TF。把新角色在同样的任务里做GANG Schedule，这在原生的TF-Operator里面并不支持。在KubeDL里很容易做到，对于库底层，上面无论定义多少角色及类型，只要满足角色定义的逻辑，都会把它当成资源的Role，然后统一做GANG Schedule。通过引入这一点，KubeDL可在底层做同时满足Cpu/Gpu的异构资源申请。例如， TF work会需要用到GPU来做加速计算，而PS和GraphLearn都只需要CPU，这里调度的时候，GANG Schedule考虑多种不同计算Role， GraphLearn与TF原生角色，一起进行了资源考量和任务拉起。所有资源检查完毕，在集群里面会放行与调度执行，如果这一点没做好，可能其中一部分的角色已启动，另外一部分角色没有足够的资源，整个任务就hang在那，其余用户也无法使用这些资源，严重的话会造成资源死锁。此外还需要统一的Quota检查，用户相应的Quota需要全部满足才可执行。这些可在底层统一做，它并不只是针对GraphLearn的角色，包含任务所需要的所有角色，也可以不需要任何改动的扩展到包括原生TF在内的其他框架。因为云上追求灵活性，不同的用户会选择不同方案及对应调度器，例如社区里，就有Kube-batch对大数据计算来设计的调度器，现在也可支持AI的任务。而KubeDL的GANG Schedule能力可以支持Kube-batch，当然也可以延伸扩展到支持任意调度器。 KubeDL还可以支持ASI调度器，这是阿里内部支持双11日常的任务调度的高性能调度器，ASI上的能力也可通过KubeDL调用和实现，而YuniCorn调度器也同样支持。三、KubeDLPro在KubeDL的工作中，我们完成了对于深度学习任务的基本支持，而KubeDLPro诞生，源自于我们对于AI任务运算的特性需求的深入的理解与新硬件的挑战。 3.1 深入理解 AI任务运算的特性做 AI任务调度，首先需要深入理解 AI任务运算的特性。上图左边是对阿里内部计算任务做的一个统计， 80%计算任务命令Mini-batch时间约为600个毫秒以内，这样的频繁数据同步是AI Flow一个典型的要求。从深度学习模型参数如今的发展上看，两三年前Bert的参数与如今最大模型PPT3相比之下已经非常小，说明用数据并行的方式在训练一个模型的时，如果80%的任务，可能每600毫秒需要通信整个模型参数的数据量，如今的模型通信的数据量非常大，对于整个的网络带宽都有个比较大的挑战。 3.2 新硬件的挑战从底层硬件角度看，发现随着AI任务的引进，底层硬件也丰富起来。比如GPU，现在用的非常多的V100、A100等。阿里也有一些相应的AI推理的芯片，如含光800芯片，可以加速整个任务推理，在云上还有RDMA-Nic、SmartNic这种相应的通信优化的这种硬件。如何把上下两层之间，去弥合计算任务特性，以及跟底层硬件相关的间隙，对于AI任务的性能就显得至关重要。而我们通过通信、计算、存储、资源调度以及整套的监控相应的优化，试图去解决这个问题，这就是KubeDLPro。 3.3 KubeDLPro：拓扑感知调度接下来介绍现在在KubeDLPro上面实现的一个能力，叫拓扑感知调度，通过下图展示一下它的功能。举个例子，用户提交一个PyTorch任务，假设PyTorch任务需要4个GPU,这个任务用户就会起4个Worker，每个圆圈代表一个Worker，每个Worker运行在1个GPU上。传统的调度方法会把这4个Pod放到一个资源池里面，调度器查看哪里的资源有一些空闲，就按照某一调度的策略做一个摆放。但是，实际上AI计算资源池并不是像之前那么简单。上述例子调度执行后可以发现，其实任务被放在了两个不同的机器上，这里面橘黄色的模块表示一个机器，然后机器上它又有不同的GPU，每个GPU之间呈现不同的拓扑连接，而且并不是一个完全对称的。上图展示的是一个典型v100的机型，每个绿色的方框代表一个GPU，黑色的线代表了GPU之间是通过NVLINK进行连接。其中NVLINK在GPU通信是里面较为重要的硬件。首先它的带宽比Pcie大很多，可能几倍于Pcie的带宽。其次它可以使GPU跟GPU之间的通信做到零拷贝，不需要通过CPU，从而减少了数据搬移的代价。在这个调度的场景里面，由于传统的方法并不关注和感知底层的数据网络通信拓扑，它有可能一个调度把整个PyTorch任务调到了两个机器、各使用两个GPU，并且同个机器内的GPU，甚至无法用NVLINK进行联系。拓扑感知调度就是感知底层的一些拓扑信息以及任务对通信的一个需求，它可以在空闲的资源里面选择最佳的、紧凑的、通信带宽大的机器/GPU来放置计算任务。这种NVLINK带来的P2P GPU Direct通信的好处，一是不用数据拷贝，二是不用CPU跟GPU之间进行数据通信，三是0内核调用。具体实现方法首先做一层统一的感知设备间的通信能力，感知的东西，包括现在的NVLINK，然后PcleSwitch。比如同一个PcleSwitch的通信，会比跨PcleSwitch要差了百分之几十。QPI是不同的CPU socket之间连接的通信，此外还包括RDMA NIC，因为RDMA可以用上GPU Direct。AI任务的性能，在TCP网络和RDMA网络上也会呈现不同的效果。以上优化内容均先在阿里巴巴内部GPU集群上面部署验证，我们针对于阿里内部典型的ALLReduce式的深度学习模型，可以带来1.12到10.54的性能提升。在云原生环境中，我们用PyTorch 10w分类任务做一个评估，与现有的社区的实现，两者相差就可以达到10倍的性能。而观察发现，在阿里巴巴内部整个集群的角度，通过拓扑感知调度，NVLINK通信资源的利用率得到4倍的提升，有更多的任务及计算可以通过NVLINK的大带宽、免拷贝形式能够更快速完成。 3.4 拓扑感知调度系统架构具体做法如上图所示，从下往上看，这里有4个GPU，NVLINK、PCleSw表示不同的网络拓扑连接，做一层Enhanced NVIDIA Device Plugin，从硬件的角度把拓普关联的关系抽取出来，把信息发给KubeDL的 Operator及集群调度器，使得可感知底层的硬件资源的拓扑。KubeDL会做拓扑感知Job的调度，通过调度器提供的资源预占的接口，使得它不只是做GANG的时候考虑任务之间使用GPU时相关联的特性，从而为它分配更大带宽、更好的通信位置，做到精准的GPU级别调度的分配。主要的改动在三个层面，第一层是在KubeDL，第二层是在Scheduler Framework里面改Scheduler，第三层是在Enhanced整个的NVIDIA Device Plugin。 3.5 拓扑感知调度系统实现上图是实现整个大体的逻辑，用户提交一个ALL-Reduce 任务，首先来到KubeDL，KubeDL会把相应的信息提交给GPU Coordinator，再生成资源预占的CRD,与此同时Device plugin上报的GPU拓扑保存在 CRD里。GPU Coordinator根据GPU拓扑的CRD以及任务资源需求的CRD分析做匹配，将整个任务所有需求考虑。进而调用调度器提供的预留资源接口，将这个任务预占，最终把相应的Pod的信息提交到调度器。调度器会做pod的调度消费，将刚才预留过的资源精准分配给相应的Pod，完成整个任务的调度，这就是对基础版的拓扑感知调度的实现方式。上面的实现始于阿里内部GPU集群的验证，而我们也发现当下的硬件能力在社区的调度方案无法充分发挥其效果，于是把这个方案输出到阿里云的云原生平台，我们希望能让更多的人能够享受这样的服务。 3.6 直观举例分析进一步的，举个直观的例子，当要提交一个8卡的深入学习任务，要用怎样的一个方式去提交？比如单机8卡，所有东西都放到一个进程，指定去做通信设定，进一步拓展可以2机4卡， 4机2卡，极端情况做完全分布式8机1卡。上述不同提交方法各有利弊。1机8卡可以控制相应的计算资源，能让任务去走相应的NVLINK进行通信，缺点是无法快速获取资源。分布式的8机1卡优点在于，即使当集群里面存在一些碎片时，也可以更快拿到相应资源，比起1机8卡，其资源粒度更细，更容易拿到所需的资源，因而等待时间更短。但现实情况是整个集群大多数情况，用户任务都在运行，不断的有任务完成，和到达，机器里剩余的可用卡数不同，并不是规整的2卡4卡8卡这种情况。这个问题应该如何解决？在一个忙碌的集群里面，确实很难找到这种规整GPU的计算资源，于是就会出现一个问题。如下图所示，用户买了4个机器，每个机器8块卡一共32，目前空闲16块卡，用户希望提交一个2机每机4卡的任务，但无法提交。其本质原因在于，集群里面找不到两个机器满足2机每机4卡的需求，因此这个任务被迫等待。可以发现， 2机4卡并不是唯一解决办法，如果以“3+5”的形式执行该任务，那么整个任务完成时间其实与提交2机4卡的任务一样。在实际场景中，用户不知道当前跑的集群剩余资源的情况，所以也无法提前作出3+5这种资源申请，因此需要系统运行结合调度的情况，给用户做资源申请形状的改变，让用户在等待时间和运行时间上达到平衡。而从用户侧，其实1机8卡和8机1卡所需要的代码完全不同，许多用户在这上面非常纠结。我们通过系统层能力来做到自动平衡，使用户编码上不用纠结。拓扑感知自动聚合进一步对拓扑感知做扩展，扩展到拓扑感知加自动聚合。建议用户在编码时完全按照分布式方式做编程，让用户写PyTorch的任务，以PyTorch DDP的方式，刚刚的例子写成一个8机的1卡。通过KubeDL加上PAI框架，PyTorch里面相应的一些改动来支持用户行为，它会自动的选择。第一是自动选择最佳的通讯拓扑。第二是实现了跨Pod NVLINK的通信，现在社区的方案跨了Pod，无法看到另外一个GPU，也无法进行相应的NVLINK通信，会变成走Share Memory或者网络的情况。第三是当这个Pod对其他Pod的 GPU可见时，通过框架自动分配 GPU的设备到相应的PyTorch Worker上，这需要改动相应框架知道在使用哪块卡。上面举例的8卡任务，在这个场景里面可以被自动捕捉，然后以“7+1”（如上图所示）的形式运行。它与用户最初设想的两个机器里面4张卡的情况相比，性能也完全一样。目前整体该功能囊括在PAI DOC的产品里，TensorFlow和PyTorch均支持这样的功能。四、总结综上所述，云原生场景中的AI任务调度工作主要如下：第一，是提供了完全开源的KubeDL组件，做到方便扩展，同时兼容社区所有的Tf-operator/PyTorch-operator等深度学习应用提交工具的接口。第二，基于这套组件可以简易地进行扩展，许多开发者需要通过KubeDL来实现一些 AI任务提交，我们都有教学文档帮助大家实现。通过All-In-One理念，只要实现很简单的Operator，该任务就拥有底层相应资源优化的能力，通过调度器与AI框架做一些协调设计，在阿里内部的一些AI实现这种优势特性和能力，通过兼容社区的Operator、调度器的形式进一步透出，让 AI框架跟调度进行联动，硬件资源可得到充分利用。第三，观察到大部分AI任务的用户都是算法工程师，他们在研究算法调参上花费大量时间，但对于系统底层并不是特别了解，需要我们对用户做到功能透明，使用户无需操心系统实现和硬件细节就可达到预期效果。GPU价格昂贵，我们希望能够不断优化做任务的训练速度，提升整个集群资源利用率和任务吞吐率。（分享人：肖文聪）了解PAI-DLC云原生深度学习训练平台，请访问官网：https://www.aliyun.com/activity/bigdata/pai-dlc欢迎加入PAI钉钉群交流：https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingd0cf799086f27cb135c2f4657eb6378f&inviterUid=F21988A2A1749D4394460A2FDF52346D&encodeDeptId=0746DEFF8740D17C91E7FE61FE0552A6

发表了文章 2020-11-30

伊对联手机器学习PAI 让云技术赋能恋爱社交行业升级

在9月17-18日的2020阿里云栖大会上，伊对相关业务专家分享了云技术在视频恋爱社交领域的应用和场景互动形态的探索。伊对是阿里云的合作伙伴，也是云技术成功的行业应用案例。伊对App是北京米连科技有限公司旗下产品，专注于移动端的线上交友和相亲，是恋爱社交领域杀出来的一匹黑马，被业界誉为社交+直播的成功典范。伊对将视频、直播和在线红娘创造性地融入该领域，成为独立赛道的领先者。凭借伊对App成功运营，米连科技跻身北京CBD评选出的高科技高增长的“朝阳20强”。截至目前，伊对注册用户超过4000万，活跃红娘4万多人，每月撮合线上相亲活动约1000万场，稳居行业头部。面对日益增长的庞大数据，如何完善基层技术数据存储、加工、推理，并快速为用户提供智能推荐，打造更加完美的恋爱社交场景，是伊对始终需要面对的技术课题。据阿里云相关人士介绍，阿里云与伊对的合作平台是阿里云机器学习平台PAI。这是一款高性能、低门槛的云端一站式AI服务平台，为传统机器学习和深度学习提供了从数据处理、模型训练、服务部署到预测的一站式服务。阿里云机器学习平台PAI为伊对技术赋能，包括弹性扩展服务、数据计算存储、算法模型三大架构。那么，作为普通用户，如何感知云技术带来的便利呢？据伊对相关负责人介绍，与阿里云合作的成果之一是推荐技术。恋爱社交有一个公式：恋爱转化率×机会=结果。伊对App通过大数据算法，在数千万用户中，精准地定位符合每一位用户基本要求的对象，并向用户推荐，帮助他们便捷地找到真爱。另外一个就是体验感。在伊对App上，连麦用户可以感受到清晰、流畅、低延时的视频对话体验，背后是强大的视频云做支撑。借助阿里云全球领先的云计算及人工智能技术，伊对实现了1秒以内的超低延时，保障了近乎完美的视频和直播体验。在春节期间和疫情以来，伊对下载量环比节前新增1.5倍，用户活跃度新增50%以上，数据处理和推荐压力倍增。但是，伊对不但顶住了流量冲击，而且在提升体验感、风控反作弊等方面都有持续的进步。视频和直播正成为风口，从线下到线上，云会议、云课堂、云卖货、云旅游，一切都基于视频的场景全面爆发，以云技术为基础，诞生了更多新内容、新交互、新体验。社交+直播平台的模式还在高速发展，对数据的利用和推荐效率也会成为企业不可或缺的硬核竞争力。伊对表示，未来会将阿里云机器学习PAI平台应用到更多推荐业务及风控反作弊等场景，为用户提供一个更阳光、更真实、体验感更好的恋爱社交平台。访问PAI平台官网了解详情欢迎加入PAI钉钉群交流，免费干货下载：https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingd0cf799086f27cb135c2f4657eb6378f&inviterUid=F21988A2A1749D4394460A2FDF52346D&encodeDeptId=0746DEFF8740D17C91E7FE61FE0552A6

发表了文章 2020-10-13

机器学习PAI有奖调研获奖名单

机器学习PAI平台主要面向企业开发者，提供从数据处理、模型训练到服务部署的一站式服务。支持Studio可视化/DSW交互式/EAS在线预测/DLC云原生深度学习训练/全自动化多种建模方式，内置200+成熟算法、深度学习预训练模型50+，快速构建AI业务方案，已在搜索推荐等领域商用，官网：https://www.aliyun.com/product/bigdata/product/learn