近年来，中台一词炙手可热。经过实践后，各个互联网大厂都逐渐走出了自己的中台技术线。推荐 / 搜索因为在业务中展现出越来越重要的商业价值，而通过深度学习模型为用户提供千人千面的服务已经成为推荐 / 搜索的主流方案。推荐中台由此成为推荐 / 搜索场景重要的基础设置。本文详细介绍了腾讯 PCG 推荐中台的模型系统以及核心的超大规模深度学习框架：。 1. 特征处理模块管理 user 和 item 的实时和固有特征，并根据线上的反馈更新实时特征，比如：用户画像、浏览记录等。为了不同训练的实时性，实时样本生成服务和离线样本生成任务利用特征处理模块管理的信息生成样本，输出到离线或者在线. 这些样本被训练系统中的训练框架训练，生成训练模型。根据模型上线实时性不同的要求，模型被存储在持久化存储或者消息中间件中。 3. 在线 Serving 服务在收到模型管理服务的模型上线请求后，从持久化存储或者消息中间件中获取模型信息并更新线. 在模型持续训练和上线的过程中，业务服务持续的调用 Serving 系统的服务进行模型推理。 5. 业务服务将召回、排序、展示、点击等信息记录 A/B Test 系统，同时将其他信息回传至特征处理模块，以更新实时特征。 在特征中台中，其核心目标为加速整个流程，让研究人员的模型开发、实验和分析周期变得更短，提升业务实验的效率。腾讯 PCG 推荐中台目前已经接入了 PCG 所有业务以及其他 BG 的部分业务，为业务提供标准的基础设施，并取得了非常好的效果。 本文主要介绍腾讯 PCG 推荐中台的模型系统，包括从模型的训练、上线和在线推理部分，上图中灰色框中的内容。后续还会有文章介绍推荐中台的其他模块。 腾讯 PCG 推荐中台的模型系统是从 1.0 系统的基础上重构和发展而来（ 1.0 详细内容请参考《独家揭秘：腾讯千亿级参数分布式 ML 系统背后的秘密》）。 1.0 系统实现了 TB 级模型训练和上线 的突破，但要想成为支持所有推荐业务的中台系统，还存在以下的一些问题： 1. 模型描述能力不足。 1.0 支持的深度学习算子有限，导致很多最新的深度学习模型无法在 1.0 上描述。如果开发新算子，整个模型开发周期将以月为单位。 1.0 对模型的描述是基于配置文件的。导致算法人员需要学习一种私有的配置描述方式，带来了较高的学习成本。而整个深度学习领域使用 Python 作为模型描述语言，以算子化的方式灵活构造模型已经成为了主流。 2. 模型在线推理服务成本高。 1.0 的推理服务成本主要体现在两个部分：a. 实验成本。由于未能实现对任意深度学习模型的支持，每次上线 模型，都需要有后台开发人员与算法人员做模型对齐并开发相应的适配代码，且由于后台开发人员与算法人员技术能力的差异，整个过程耗时费力，非常容易出错。与推荐中台以天为单位的实验周期目标冲突。b. 运营成本。高性能的分布式 Serving 服务解决了 TB 级模型的在线存储问题，也引入了较大的额外资源开销。 3. 模型上线管理能力弱。为了在业务中快速实验，算法人员会快速上线 / 下线模型，并同时上线多个模型进行效果对比。绝大多数推荐模型都是采用在线训练方式，按照一定的时间间隔持续上线模型，或者采用实时方式训练和上线。在这个过程中，可能出现模型效果抖动、上线异常、资源占用导致推理耗时毛刺等各种问题。系统需要管理多个模型，持续稳定地上线，同时确保业务不会受到持续批量上线. 业界常用深度学习框架的支持能力有限。除了 1.0 框架，算法人员也会选择一些其他的深度学习框架，如：TensorFlow、Pytorch 来训练自己的模型，以便快速应用业界和学术界的研究，在业务中验证效果。使用这些深度学习框架进行的实验也需要训练、上线 系统不能支持这些框架，了算法人员的选择范围，影响实验速度。 为了解决以上问题，满足业务发展对深度学习模型快速开发、实验的需求，研究人员完成了以下几件事： 1. 开发一个易用性与业界对齐的分布式深度学习框架 -- 2.0。性能继续保持 1.0 在 TB 级模型训练上的性能优势，在进一步优化的同时支持 TensorFlow 的 Python 接口方式描述深度学习模型。 2. 开发标准化的深度学习模型推理服务。实现深度学习框架训练出的模型零开发 / 零配置上线。优化推理服务性能，降低服务资源消耗，超越定制化实现的水平。 3. 开发完善、易用的模型管理服务。支持模型的存储和管理；支持不同大小、不同格式的模型上线 / 下线，允许为模型定制不同的上线管理策略；支持模型高频率持续稳定上线到千级别的服务节点。 4. 支持了常用的深度学习框架的模型训练、上线和推理。除了支持框架生产的模型，还需要支持至少两种业界常用的深度学习框架（TensorFlow、Pytorch）生产的模型上线和提供在线推理服务。为了让算法人员在多种深度学习框架之间切换的开发过程更为顺畅，该研究提供了配套的模型转换工具集合。 训练框架通过桥接的方式引进 TensorFlow，基本架构见下图。这种桥接的方式保留了框架在分布式训练系统中的实现度，便于后期功能定制化和性能优化。同时通过复用 TensorFlow 算子，使得算法同学能够轻易的将 TensorFlow 上开发的模型迁移到框架，也可以用算法人员熟悉的 TensorFlow 编程接口来描述模型，提升模型开发效率。在模型导出时，将模型在线推理所需的信息以标准化的模型描述文件方式记录下来。在线推理服务通过解析模型描述文件和模型数据文件，自适应地构建在线推理逻辑，实现模型的零配置上线. 模型全流程系统 洪晃照片 模型全流程系统整合了训练平台、模型管理模块、在线推理平台，采用统一的方式管理模型的生产、上线和在线服务。模型上线 / 下线控制逻辑被抽象为的 Servable 框架，与具体的深度学习框架隔离，实现模型管理逻辑与深度学习框架推理逻辑之间的解偶。架构如下图：（1）模型管理与一键自动化上线。在推荐场景中，训练样本需要在线训练，生产出的推荐模型需要持续上线，以获得更好的业务效果。该研究构建了一套适应不同大小模型自动化上线系统。首先，系统支持了 TB 级模型的全量 / 增量上线模式，同时支持了流式更新的实时上线。其次，对于不需要复杂上线方式的中小模型，系统也能够很好地支持。在推荐场景中，还会出现一个模型被切分到多个服务中使用的情况。例如下图所示，一个 dssm 模型被用于召回场景时，需要提供给两个使用方：1）业务服务在线）异步近线刷库服务，要求高吞吐。在实际运营中，需要用两套的服务来实现。如果两套服务中都保存和更新整个的模型，资源消耗和模型更新速度都会受到影响。通过将模型参数按上线逻辑进行切片，可以实现最小集合的上线 小时持续上线，模型效果，上线质量保障。在持续上线的过程中，通过标准的模型描述文件，系统自动化地识别模型的效果，对于不符合要求的模型进行过滤，避免不合格的模型被上线到推理服务中，影响业务效果。 （1）统一的 Servable 架构。为了支持多种深度学习框架的推理服务，对深度学习框架的推理服务进行了模块化，分为与模型管理有关的逻辑和推理服务有关的逻辑。在推荐场景下，模型管理模块的逻辑与 ServingManager 服务、模型存储交互，便于统一控制逻辑。不同的深度学习框架实现方式差异巨大，但是基本推理结构符合深度学习的基本框架，所以与框架相关的实现被抽象为可替换的 Servable，灵活组合。与业务服务调用有关的部分，被实现为标准接口，便于业务服务的开发。为了便于不同深度学习框架的切换，系统还配套了模型转换工具，方便训练和推理的交叉实验工作。（2）优化性能。推理部分：通过模型描述自解析的方式，实现了在线推理服务对模型的通用适配，降低了模型上线的成本，但也引入了通用性服务面临的普遍性能问题。具体表现是在某些情况下，性能不如业务以前采用的定制化实现。由于 PCG 的业务体量都很大，推理服务性能的差异直接导致资源成本的上升。通过采用算子融合、代码优化等方式，框架推理服务成功将性能提升到了超越业务定制化实现的水平。参数存取部分：分布式 Serving 集群的存在，解决了 TB 级模型在线推理的问题，但是也引入了额外的服务调用，当单词请求的 Embedding 需求量变大时，网络也会成为瓶颈，危害整体推能。通过针对推荐场景的模型特点构造高速缓存，成功地去除掉超过 70% 的分布式 Serving 请求通讯量。 虽然推荐中台模型系统已经接入了PCG所有业务以及其他BG的部分业务，但是大量的用户以及业务的多样性也给中台带来了巨大的挑战。 系统与算法的联合创新。中台的模型系统是连接算法与系统的纽带。一边是机器学习/深度学习算法的不断创新，一边是高性能和稳定的系统。这也给予模型系特的创新空间，相比于单独算法创新或者性能优化，如何结合系统与算法进行联合优化，是一个挑战和发挥空间巨大的问题。最终让更多的算法成为可能，也让系统更加易用和高效。 性价比方面。TB级模型的训练和推理对资源需求很大，每个业务都有很多细分场景有多组实验并行进行，让模型系统成为资源大户。中台需要更高的性价比。这些工作需要架构与算法之间紧密配合，通过框架重构与升级，将最新的硬件技术，算法创新应用到系统中。 需求更新与稳定性方面。当中台成为业务统一基础设施后，意味着更多样的需求和更重的责任。系统本身也需要更加灵活和稳定。 曾存储过 GB 级业务数据的组织现在发现，所存储的数据量现已达 PB 级甚至 EB 级。要充分利用这 些海量数据的价值，就需要利用现代化云数据基础设施，从而将不同的信息竖井融合统一。 无论您处于数据现代化过程中的哪个阶段，本行动手册都能帮助您完善策略，在整个企业范围内高效扩展数据、分析和机器学习，从而加快创新并推动业务发展。
|