目录

快手技术 VP 王仲远对于 AI、大模型、深度学习的预测 2021-09-02

CV、Speech、NLP，背后主流的模型基本上都是基于 Transformer。在未来可能各方面的技术边界越来越模糊，事实上现在已经逐渐出现越来越多的多模态技术研究。技术融合变得门槛很低，但大家做的事越来越相像。

重要的研究方向

  • 大模型
  • 怎么让黑盒的深度学习跟知识能够进行融合变成可解释，然后增加常识。

近两年模型都已经到万亿级别了

  • Google Switch Transformer
  • OpenAI GPT-3
  • 阿里 M6

搜索系统是先以内容分析为主，再结合了用户行为；而推荐系统则是以用户行为为主，再尝试结合内容理解。 内容理解可以帮助推荐系统为用户做更加个性化的内容分发和匹配，探索如何更好地利用内容理解为推荐系统进一步提升个性化推荐能力。

怎么去考虑 AI 技术布局？（任何新技术都是类似的） 如果我们都只关注于未来三个月或半年就能落地的技术，那么很显然它是不具备可持续发展的。反之，如果只关注中长期才能见效的研究方向和研究项目的话，那么不确定性又会非常大，毕竟业务对于 AI 技术的渴求是非常强烈的。所以技术布局本质上是一个短期项目与长期项目配比的问题。 公司首要面临的是行业里激烈的市场竞争，我们的基本原则首先是希望能够去做对公司业务有意义的研究，在这个基础上再做选择，哪些技术业界已经进入到相对成熟的阶段，这类技术我们就想办法进行业务落地；哪些技术可能是行业未来发展的趋势，我们需要持续投入资源去做研发；哪些项目是要短期 3-5 个月就能够看到效果，哪些是中期或者长达 5-10 年才有效果。这个比例是要做充分考量的，比例不合适的时候公司业务发展就可能出问题。同时，在做中长期投入的时候，需要把它做 milestone 拆解，确保这个项目有阶段性产出。

一站式机器学习平台 Deepthought 的建设与初探 2020-06-24

  • v1.0 版，面向具体业务的机器学习平台（一个业务应用）
  • v2.0 版，面向通用业务的机器学习平台（组件化、调度、算法管理、可视化交互）
  • v3.0 版，面向具体业务的机器学习平台（推理、自动调参、超大模型的训练－参数服务器）

美团配送一站式机器学习平台建设实践 2020-02-11

为什么建设一站式机器学习平台

需要有一个功能强大且易用的机器学习平台来辅助算法研发人员，帮助大家脱离繁琐的工程化开发，把有限的精力聚焦于算法策略的迭代上面。

可视化训练平台

屏蔽多个训练框架的差异，降低算法 RD 的接入门槛。为了降低算法 RD 进入机器学习领域的门槛，我们开发了带有可视化界面的离线训练平台，通过各种组件的拖拉拽组合成 DAG 图，从而生成一个完整的机器学习训练任务。

我们的离线训练平台在产出模型时，除了产出模型文件之外，还产出了一个 MLDL（Machine Learning Definition Language）文件，将各模型的所有预处理模块信息写入 MLDL 文件中，与模型保存在同一目录中。当模型发布时，模型文件连带 MLDL 文件作为一个整体共同发布到线上。在线计算时，先自动执行 MLDL 中的预处理逻辑，然后再执行模型计算逻辑。通过 MLDL 打通了离线训练和在线预测，贯穿整个机器学习平台，使得线下和线上使用同一套特征预处理框架代码，保证了线下和线上处理的一致性。 在发布模型时，我们还提供了模型绑定特征功能，支持用户把特征和模型的入参关联起来，方便在线预测时模型自动获取特征，极大地简化了算法 RD 构造模型输入时获取特征的工作量。

模型管理平台

我们的图灵平台集成了 Spark ML、XGBoost、TensorFlow 三种底层训练框架，基于此，我们的训练平台产出的机器学习模型种类也非常多，简单的有 LR、SVM，树模型有 GBDT、RF、XGB 等，深度学习模型有 RNN、DNN、LSTM、DeepFM 等等。而我们的模型管理平台的目标就是提供统一的模型注册、发现、部署、切换、降级等解决方案，并为机器学习和深度学习模型提供高可用的线上预测服务。 对于超大规模模型，单机无法装载，需要对模型进行 Sharding。鉴于美团配送的业务特性，可以按照配送城市/区域进行分区训练，每个城市或区域产出一个小模型，多个分区模型分散部署到多个节点上，解决单节点无法装载大模型的问题。分区模型要求我们必须提供模型的路由功能，以便业务方精准地找到部署相应分区模型的节点。 同时，模型管理平台还收集各个服务节点的心跳上报信息，维护模型的状态和版本切换，确保所有节点上模型版本一致。

离线特征平台

配送线上业务每天会记录许多骑手、商家、用户等维度的数据，这些数据经过 ETL 处理得到所谓的离线特征，算法同学利用这些离线特征训练模型，并在线上利用这些特征进行模型在线预测。离线特征平台就是将存放在 Hive 表中的离线特征数据生产到线上，对外提供在线获取离线特征的服务能力，支撑配送各个业务高并发及算法快速迭代。 我们需要对离线特征从存储和获取进行优化。我们提出了特征组的概念，同一维度的特征，按照特征组的结构进行聚合成一个 KV，大大减少了 Key 的数目；并且提供了相对完善的管理功能，支持对特征组的动态调整（组装、拆分等）。

实时特征平台

相比于传统配送，即时配送无论是在位置信息、骑手负载，还是在当前路网情况，以及商家出餐情况等方面都是瞬息变化的，实时性要求非常高。为了让机器学习算法能够即时的在线上生效，我们需要实时地收集线上各种业务数据，进行计算，提炼成算法所需要的特征，并实时更新。

AB 实验平台

自 2000 年谷歌工程师将这一方法应用在互联网产品以来，AB 实验在国内外越来越普及，已成为互联网产品运营精细度的重要体现。简单来说，AB 实验在产品优化中的应用方法是：在产品正式迭代发版之前，为同一个目标制定两个（或以上）方案，将用户流量对应分成几组，在保证每组用户特征相同的前提下，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，科学的帮助产品进行决策。 互联网领域常见的 AB 实验，大多是面向 C 端用户进行流量选择，比如基于注册用户的 UID 或者用户的设备标识（移动用户 IMEI 号/PC 用户 Cookie）进行随机或者哈希计算后分流。此类方案广泛应用于搜索、推荐、广告等领域，体现出千人千面个性化的特点。此类方案的特点是实现简单，假设请求独立同分布，流量之间独立决策，互不干扰。此类 AB 实验之所以能够这样做是因为：C 端流量比较大，样本足够多，而且不同用户之间没有相互干扰，只要分流时足够随机，即基本可以保证请求独立同分布。

即时配送领域的 AB 实验是围绕用户、商户、骑手三者进行，用户/商户/骑手之间不再是相互独立的，而是相互影响相互制约的。针对此类场景，现有的分流方案会造成不同策略的互相干扰，无法有效地评估各个流量各个策略的优劣。 由于即时配送的场景较为特殊，比如按照配送区域或城市进行 AB 实验时，由于样本空间有限，很难找到没有差异的对照组和实验组，因此我们设计了一种分时间片 AB 对照的分流方法：支持按天、小时、分钟进行分片，多个时间片进行轮转切换，在不同区域、不同时间片之间，对不同的策略进行交替切换进行 AB 分流，最大限度减少线下因素的影响，确保实验科学公正。

vivo 手机背后的一站式机器学习平台架构实践 2020-01-21

对于 AI 研究院的各业务场景的工程师来讲，平台提供了开发调试、高效调参、模型部署、效果监控等能力，降低上线门槛，提高迭代效率。在平台内部，由四个部分组成。

  1. 特征工程系统：在规范特征格式、标准化数据流、统一存储与管理的前提下，以特征处理引擎为基础，构建更灵活增删特征、共享特征的系统；
  2. 模型训练：在深度定制的框架与计算组件的基础上，如 Tensorflow、Horovod 等，通过大规模分布式训练引擎提供了使用简单、功能强大的训练能力；
  3. 模型推理：在深度定制的推理框架与计算组件基础上，如 TensorRT、OpenVINO、TF Serving 等，提供 CPU 和 GPU 极致的高性能推理能力；
  4. 资源调度： 通过 K8s 来管理与调度 CPU 集群和 GPU 集群，规模 2000+CPU 机器，1000+GPU 卡，来支撑大规模的模型训练任务与推理服务。

特征工程系统

特征工程系统是由统一特征服务和样本生产服务组成，提供机器学习算法落地所需要的数据服务。它解决了特征生产效率，特征样本监控，特征处理一致性和数据一致性等问题；降低数据开发的入门难度，减少新业务上线成本，提高算法迭代上线效率。

大规模分布式训练引擎

用户只需配置特征格式和模型超参，即可使用。各种训练技巧即刻获得，包括极致的训练性能、分布式训练、分布式验证、增量训练、实时训练等。同时，也支持各种形式的定制，以满足各业务方的需求。主要优化了训练速度和模型对样本响应速度。 在训练速度提升方面，vivo 主要做了单机训练性能提升、同步更新的分布式训练和分布式验证三方面工作。在单机训练性能提升方面，通过增大了 batch size，即增大密集计算的 workload，将 CPU 和 GPU 的利用率从 30%提升至 90% ；同时适当调整学习率策略，参考 linear scaling rule，收敛速度提升了 10 倍之多。 在同步更新的分布式训练方面，vivo 基于 horovod 实现分布式训练，采用 ring allreduce 的方式进行通信；深度定制 Horovod 优化了高维稀疏特征梯度的交换效率。 在原生 Horovod 实现中，Rank0 验证时，其他 worker 都在等待，造成计算资源浪费。优化后，验证计算量由所有 worker 一起承担，每个 worker 计算完后，将指标汇总归并。 这样大大提高了计算资源的利用率，同时也提升了训练速度。 在提升响应速度层面，vivo 尝试了增量训练和实时训练。全量样本训练耗费太多计算资源与时间，增量训练可以提高训练的响应速度，效果更佳，同时也减少了资源的使用。要想实现实时训练，使得最新样本的分布尽快反应到模型中，就要去掉验证集；但训练任务的停止条件是通过验证集上 early stop 方式控制的，所以去掉验证集的话，就要寻找新的、稳定的、有效的停止条件；vivo 的方案是利用有验证集的训练任务得到训练集上的指标来指导无验证集的训练任务何时停止。

高性能推理引擎

在引擎内部，基于 CPU 和 GPU 的开源高性能计算库和推理服务器，根据具体业务的特点，一般会采取：

  • 在计算库与推理服务器基础上，调优参数配置，优化热点算子，来满足线上推理的需求；
  • 对性能要求比较高、机器预算比较大的场景，会针对这类业务定制化实现一套轻量级的推理引擎。

在性能优化方面，vivo 优化工作主要集中在图优化和算子优化上。图优化方面主要是：

  • 算子融合： 经典的矩阵乘加融合、卷积层和激活层融合，减少函数调用次数，提供执行效率；
  • 非功能性算子消除：如 Identity、Const、Reshape、ExpandDim；
  • 异构计算：I/O 密集型和逻辑处理放在 CPU 上执行，如 embedding、并查集； 密集计算放在 GPU 上执行。

算子优化方面，vivo 也针对 CPU 和 GPU 的硬件特性做了一些软件层面的定制优化工作。CPU 的算子优化：

  • CPU 有更大的内存和 cache，所以内存对齐、增加 cache 命中率，可以提高运行效率；
  • CPU 有更少的执行单元，那么利用 OpenMP 做代码矢量化、让代码并行执行，提高运行效率；
  • 对 intel 最新型号 Cascade Lake 的 VNNI 指令进行了 INT8 探索优化。

GPU 的算子优化：

  • GPU 芯片有大量的计算单元，所以合理设计线程布局会大大优化执行效率，同时也要减少线程束分支，避免低效执行；
  • 对 T4 的 HMMA 指令和 IMMA 指令进行了 FP16 和 INT8 量化的探索优化。

经过一年多的探索与实践， 在稀疏 DCN 模型、通用 OCR 模型、BERT 模型等相关技术的应用场景中，都得到了 10 倍左右的推理加速，为 vivo 节省了数千万机器成本。

揭秘腾讯千亿级参数分布式机器学习系统无量 2018-06-30

推荐场景面临的挑战

  • 样本数量大。在推荐场景下，每天的样本量可以达到百亿量级。如果需要按一个月的样本进行训练，样本量会在千亿级别。如果每个样本平均 500 特征值，单个样本的大小就是 5KB 左右，一千亿样本的大小就是 500TB。即便只使用一周内的样本，样本数据的大小也在 100TB 这个级别。
  • 特征维度多。巨大的样本量使高维度模型的训练成为可能。为了给用户提供更合理的推荐结果，需要对用户和被推荐的文章 / 图片 / 视频进行详细的描述。各个业务都会建立起丰富的用户模型，也会对文章 / 图片 / 视频进行多维度的标注。在系统进行推荐时，还会使用到用户现在的上下文信息，比如：时间，位置，之前浏览的页面等。当这些特征被引入到模型中时，会导致特征规模的迅速增加。如果再考虑交叉等特征转换操作，模型的特征维度会轻松地膨胀到千亿甚至万亿级别。
  • 训练性能要求高。我们面对的是百 TB 的样本和百亿 / 千亿参数的模型。而业务需要在短时间内训练出一个性能指标好的模型，以便快速上线验证。这对机器学习平台训练能力有很高的要求。 前面 1～3 点，提出的是超大规模模型的训练框架面临的挑战，然而训练出模型只是重要的第一步。最终模型需要上线为用户提供服务才能体现其业务价值。对于以往的机器学习中的中小模型，模型上线服务并不是一个特别被关注的事情。但是，当最终模型文件很大，甚至超过单机的内存大小时，模型上线服务就变成了棘手的问题。
  • 模型大但用户需要毫秒级响应。以最简单的 LR 模型为例，一个 10 亿特征的模型的大小也会达到 12GB（每个参数需要一个 8Byte 的 key 和 4Byte 的 float value）。如果是 DNN 模型，模型大小到达 TB 也是可能的。当训练好一个模型后，模型就被上线，为用户提供预测服务。为了达到良好的用户体验，预测服务的响应时间需要在 10ms 这个量级。以手机用户的推荐场景为例，从用户在手机上刷新页面到看到推荐结果，时间不能超过 1s，扣除掉网络通讯的开销，IDC 内在线服务的响应时间需要控制在 200ms 以内。但是，整个推荐的流程至少有召回，排序和展示控制三个阶段。在排序阶段，需要对 200 个以上的文章进行特征拼接和点击率预估，所以模型对这 200 个文章进行点击率预估的总时间要在 30ms 以内。如何使用这么大规模的模型进行高性能，高并发的预测也对平台能力的重大考验。
  • 模型实时上线。对于资讯推荐类场景，用户的关注点变化很快。系统需要根据最新的用户行为数据调整模型，然后以最快的速度将如此大规模的模型更新到多个地区的在线预测服务。

系统架构

在一个机器学习系统中，机器学习算法的代码只是训练或预测过程中非常小的一部分。为了让机器学习任务运行起来，需要大量的配套服务设施的支持，包括数据管理与存储，训练框架，在线预测框架和资源管理等多个模块。

无量计算框架

推荐模型与算法

预测用户点击率（Click Through Rate，简称 CTR）

  • LR 模型 LR 是一个简单而有用的线性模型。优点：它实现简单而且非常容易支持大规模特征的样本输入。在实际应用中，往往能取得不错的效果，常常被用作 baseline。缺点：由于是线性模型，需要大量的特征工程的工作来让它得到好的效果。而特征交叉等操作也直接导致了模型的特征空间急剧膨胀。

  • FM 模型 FM 在 LR 线性模型的基础上，引入了二次项，使得 FM 模型能够自动学习特征之间的二阶交叉关系。优点：自动学习二阶交叉关系，减少了部分特征工程的工作。缺点：要学习二阶以上的交叉关系，仍然需要进行交叉特征选择的工作来生成相应的样本。

  • DNN 模型 随着深度神经网络（DNN）在图像、语音等领域的突破性发展，DNN 被引入到 CTR 模型中来，希望学习到特征之间的复杂关系，得到更好的模型。在 CTR 预估中，输入特征是高维稀疏的，不能直接使用全连接网络直接进行学习，所以用于 CTR 预估的网络一般采用 embedding 层 + 全连接层的结构。通过 embedding 层将稀疏特征转换为低维稠密特征，再输入后面的全连接层。优点：可以直接输入原始特征，减少了交叉特征的选择工作。缺点：训练调参相比 LR 和 FM 等更难。由于 DNN 稠密参数的引入，训练性能也比 LR 和 FM 更低。

从上面的模型基本结构，我们可以总结出 CTR 模型的参数特点： 1）超大规模稀疏的输入特征参数。LR，FM 和 DNN 的 embedding 层的输入都是稀疏的，参数值可能是一个单独的值（LR 的 w），也有可能是一个向量（FM 中的 w+v 和 embedding 层的 w）。 2）稠密的交叉关系参数。DNN 中全连接层参数都是稠密的。

高性能大规模并行机器学习框架

在我们的系统设计目标中有三个关键维度：1）千亿级模型参数；2）千亿级样本数据；3）高性能。 参数服务器架构由此产生。

模型管理

管理超大规模的模型时，存在两个主要的挑战：

  1. 模型超大导致的模型上线性能的问题。模型在训练过程中的变化是渐进的，而当模型上线时，是一个相对稳定的状态，在线训练更多的是对模型的微调。因此，对于超大规模的模型，一般采用全量 + 增量的方式进行管理。首先使用全量模型加载到线上服务，然后定期将模型的差异部分以增量的方式叠加到线上服务的模型中。
  2. 模型分片导致的管理问题。不同于单机可存储的模型，在参数服务器框架下，模型被分片存储在不同的机器上。为了提高模型导出效率，多个 server 节点会并行导出多个模型分片文件。假设存在 100 个 server，那么就会有 100 个模型分片文件。

模型服务

  1. 模型加载的内存问题。当被加载到内存中时，需要构建相关的数据结构，所消耗的内存大小会比模型文件大很多。以最简单的 LR 模型为例，每个特征只会有一个 float 类型的模型参数，一个 10 亿有值特征的模型的文件大小大概是 12GB（每个特征 8 字节 key+4 字节值 value）。使用 stl 标准库中 unordered_map 加载这个模型需要超过 25GB 的内存。也就是说会有超过模型大小 1 倍的内存开销，这使得单机能够存储的模型大小受到极大的制约。我们自己实现了一个 hash_map：tl_hash_map，专门针对模型稀疏参数特点进行了内存优化。内存消耗只比模型数据大 20% 左右。这意味着 tl_hash_map 有效地提高了能够被单机存储的模型的大小极限。以 128GB 内存的机器为例，使用 tl_hash_map，最大能支持的 lr 模型文件大小是 100GB 左右，而标准 unordered_map 最大能支持 50GB 左右。
  2. 模型服务的性能问题。为了达到良好的用户体验，预测服务的响应时间需要在 10ms 这个量级。以手机用户的推荐场景为例，从用户在手机上刷新页面到看到推荐结果，时间不能超过 1s，扣除掉网络通讯的开销，IDC 内在线服务的响应时间需要控制在 200ms 以内，而整个推荐的流程至少有召回，排序和展示控制三个阶段。在排序阶段，需要对 200 个以上的文章进行特征拼接和点击率预估，所以模型对这 200 个文章进行点击率预估的总时间要在 30ms 以内。

参考资料