vivo 推荐中台升级路：机器成本节约 75%，迭代周期低至分钟级
作者｜王兆雄、严鹏、吴伟兴、陈炜基
编辑｜邓艳琴
背 景
vivo 推荐业务包括浏览器信息流、横版视频、广告、直播、小说等互联网业务，以及负一屏信息流、阅图锁屏、i 音乐、i 主题等 ROM 场景业务。推荐形式多样，内容类型繁多，堆积的推荐需求和紧凑的业务上线时间节点，导致人力紧、时间赶。因此，vivo 人工智能推荐团队从业务定制的烟囱模式走向框架抽象，以实现推荐算法全流程的标准化、自动化、规模化开发为目标，打造能力复用的玲珑·推荐中台。玲珑·推荐中台主要为数据及算法工程师提供从算法策略到 A/B 实验的工程架构解决方案、通用的特征服务和样本生产服务、模型的离线训练到上线部署全生命周期管理、高性能推理等能力。玲珑·推荐中台包含四大模块：推荐中心、特征中心、模型中心、端云协同推荐。
玲珑·推荐中台架构图
目前已经有多个业务接入玲珑·推荐中台，使用其提供的上述能力，快速实现业务个性化推荐的诉求，一站式的推荐解决方案赋能 vivo 软件和互联网推荐业务。然而，业务在使用玲珑·推荐中台的过程中，还存在以下问题：
- 业务系统需要针对不同模型开发特征查询，拼接和回传的逻辑代码，代码复用程度低；
- 特征拼接逻辑需要工程开发人员与算法同事沟通特征处理过程，开发效率较低；
- 模型离线训练和在线推理目前分别使用 2 类不同配置文件，线下线上查询有不一致风险，开发和调试困难；
- 特征上线效率低，增加一个特征需要编码、压测、验证数据结果、上线，整个流程 3~10 个工作日；
- 缺乏统一的缓存机制，需要业务代码自行实现，增加业务接入的难度；如果处理不合理，容易出现 GC 问题。
针对以上问题，推荐工程团队通过规划并打造配置化的推理服务，实现统一规范，减少推理流程的重复代码开发，提高迭代效率。
整体设计
具体而言，在设计配置化推理服务的时候，我们主要考虑实现以下关键目标：
- 统一模型特征规范，打通离线训练和在线推理特征配置；
- 降低特征 SDK 查询和处理复杂度，特征即服务 FaaS（Feature as a Service）提升特征上线效率；
- 落地模型即服务 MaaS（Model as a Service），打破烟囱式推理，实现新模型零代码上线及在线推理能力。
从下图可以看到，配置化推理服务在整个推荐中台的位置和作用。
配置化推理服务在整个推荐中台的位置
配置化推理服务包括以下内容：
- 模型特征统一配置规范 VMFC （vivo Model Feature Configuration)
- 特征仓库与特征服务 FaaS（Feature as a Service）
- 模型仓库与模型服务 MaaS（Model as a Service）
模型特征统一配置规范
“模型即服务”（MaaS）落地的基础是统一规范，为了打通离线训练与在线推理的特征解析，我们对多个业务进行抽象设计，制定了 vivo 模型特征统一配置规范，VMFC（vivo Model Feature Configration）。
算法工程师在样本生产时，先在特征仓库勾选形成样本需要的特征集，在创建离线模型训练任务的时候，选择该模型训练与该特征集匹配。最终模型训练完成之后，在模型中心对其一键部署为在线推理服务。
在线推理服务对外提供统一接口，业务方使用时只需要指定对应的业务与模型代码，配置化推理服务找到该模型的 VMFC，便可以自动查询需要的特征，拼接为模型入参，返回预测结果。模型特征统一规范的主要内容如下：
特征仓库与特征服务
特征获取和特征处理，在推荐系统中是一个高并发，灵活多变的关键环节，在 vivo 传统的推荐系统架构中，特征的获取、特征的处理、特征的拼接以及推理预测是耦合在推荐工程的代码中的，每次算法实验的迭代，每增加一个特征，甚至是增加一个用于回传的特征，都需要在离线训练和推荐工程端硬编码新增的特征名称，然后把特征处理函数“搬运”过来，显然存在以下难以解决的痛点：
- 架构耦合对单机压力愈来愈大 ：特征获取与模型预测耦合，推荐系统服务器单机运行压力大；
- 硬编码迭代效率慢成为工程落地的瓶颈 ：特征获取与特征处理的逻辑不够灵活，无法应对算法实验的快速迭代需求，成为推荐系统流水线的瓶颈环节；
- 特征数据不一致 ：频繁的多分支多版本算法实验，多人协作带来较大沟通成本；训练的特征集、特征处理函数可能与线上推理预测的不一致，进而导致特征数据不一致；
- 特征复用困难 ：各个业务场景的特征都依赖于数据流算法工程师的经验，对多个团队类似的业务场景，特征的数据和经验不共享，导致增加了特征重复处理、存储等问题。数据孤岛效应明显，成本也很难缩减。
基于上述痛点，vivo AI 推荐工程团队在提炼了信息流推荐、视频推荐、音乐推荐等多个推荐业务，为了从根源解决算法迭代效率的问题，创造性的提出了特征仓库，特征集和通用特征服务的三大概念。
特征仓库，是通过特征工程把 Raw 数据抽取转化为一个特征，在特征平台注册为一个新特征元数据信息（Metadata），描述了这个特征存储的方式，数据类型，长度，默认值等，并且可以对该特征设置多项目共享，达到特征复用的目的。
特征集，是一个虚拟灵活的特征集合概念，按照模型迭代的需求，可以自由从特征面板（特征仓库）上勾选需要的特征元数据，类似购物车的概念，按需动态勾选一个匹配当前模型训练的特征集。
由于所有业务都在玲珑推荐中台注册特征、勾选特征集，从而进一步推动了特征共享复用的可能性。如果一个特征已经在平台上注册过，其他业务和场景需要复用，相应的算法工程师只需要申请共享，通过合规审批之后，就可以通过勾选特征集，用于自己的模型训练和在线推理。在此之前，vivo 各个搜广推业务是通过特征 SDK 来独立获取特征，每个业务需要根据算法工程师提供的多个包含特征配置及 Redis 集群信息的 XML 文件，生成一个 FeatureBean 实体，通过特征 SDK 连接到 XML 中提供的 Redis 集群地址，根据自己的需求分步骤多次查询出需要的用户特征、天级物料特征、准实时物料特征、再通过特征 SDK 交叉特征，整个获取特征的流程较为复杂，尤为令人诟病的是每次增加特征，需要同步修改 XML、FeatureBean 实体类、特征处理代码块等多个位置的代码逻辑；虽难度不大，增加特征的流程却很繁琐。
为了解决这个耦合深的痛点，vivo AI 推荐工程深圳团队提出了一个灵活高效的方案，用平台统一管理在线预测的推理配置特征集替代原来工程中 XML、YAML 这些一致性较差的配置文件。
特征服务主要功能思维导图
特征服务，“特征即服务” FaaS (Feature as a Service) 摒弃烟囱式的特征抽取和特征获取的低效，把特征获取这个关键步骤直接服务化。通用特征服务，是 vivo AI 研究院深圳团队打造的与特征管理平台联动的一个可配置化特征服务。特征服务在推荐排序阶段查询哪些特征，抽象到平台统一管理，在平台灵活勾选需要的特征形成特征集，在线获取特征的时候，调用通用特征服务的接口，传入特征集的唯一 ID，特征服务根据特征集元数据动态灵活获取需要的特征，一次返回给在线推理工程，通过特征拼接进入 Tensorflow 模型进行 CTR 实时预测。给出推荐结果。
对比之前的特征 SDK 形式，通用特征服务的效果较为明显：
传统特征 SDK 与通用特征服务流程对比
- 新增一次特征的算法迭代的效率大幅提升：新增特征不需要修改代码，不需要重新部署后端服务，只需要在玲珑·推荐中台修改特征集即可，算法迭代流程从 2 人 / 天缩短到 5～30 分钟；
- 特征仓库提升了全域特征数据复用可能性：特征数据也只需要存储一份即可，避免了由于特征不共享造成的信息孤岛，以及由此带来的数据存储层的浪费。
模型仓库与模型服务
模型离线训练过程比较长，分为前期的高效调参与离线训练，算法同事在对参数等调整和验证之后，通过编写 YAML 文件设定模型训练参数，执行分布式调度任务，完成模型的训练及生成。在部署模型服务的时候，算法同事首先需要与工程开发人员沟通该模型使用到特征及使用方式，然后工程同事据此来编写特征查询 XML 与模型特征拼接的实现代码，通过离线验证后，需要手动在发布系统部署该模型成为在线服务。特殊情况下，可以由算法同事来编写模型特征拼接的实现逻辑，但是这对于算法同事的工程能力要求较高，另外，就算可以实现，编写与执行效率也难以得到保证。
从离线模型部署到在线推理服务的过程中，需要较多的手动进行模型相关的配置（模型训练 YAML 与在线推理的 XML），以及工程和算法人员大量的口头沟通，从而带来较高的协作成本与出错概率。
模型仓库 ，主要是对离线训练完成的模型进行统一管理，并且提供离线模型的一键部署能力。算法同事在完成模型训练之后，只需要确定该离线模型符合预期并加入模型仓库。
模型服务 ，“模型即服务”（Model as a Service）， 基于 VMFC 的离线训练得到模型，在模型仓库一键部署成为在线服务，即可对外提供标准的在线预测接口。
模型服务部署图
模型加载与预热
模型仓库中维护该模型的基础信息，包括模型 ID，模型路径等，在一键部署模型的时候，发布系统在启动服务时，根据该信息加载模型，成功后再通过组装请求，进行模型预热。
自动扩缩容
在部署模型时候，我们要求模型服务实例是至少 2 个，避免单点故障。而在实际的线上推理过程中，通过设置 vivo 容器平台的扩缩容能力，实现流量高低峰期，在线服务的弹性扩缩容。
GPU 推理能力
当前 vivo 推荐业务的在线推理主要是基于 Tensorflow 的 CPU 推理，同时我们发现 CPU 推理存在一些问题。
- 成本问题，CPU 利用率不能太高（40% 以上，服务超时），模型复杂后，需要增加成倍的机器；
- 性能问题，对于复杂模型，CPU 机器进行推理超时严重，需要使用 GPU 来解决推理加速的问题。
基于上面的问题，vivo 近年也在 TensorFlow GPU 推理领域做了一些探索，由于 GPU 芯片架构的独特性，不进行优化的原始 TensorFlow 模型，很难充分利用 GPU 的算力。一开始，我们把训练导出的 TensorFlow 模型经过 ONNX 转换成 TensorRT 模型，通过推理服务框架 Triton 加载 TensorRT 模型，这样确实能提升 GPU 的利用率，但是也存在一些问题，比如部分推荐模型从 TensorFlow 转换到 TensorRT 存在算子不支持的情况，需要手动开发 TensorTR 算子，而通常推荐业务的算法模型迭代更新频率比较高，在线推理工程化的开发周期无法满足算法模型快速迭代的需求。最终我们联合杭州模型架构团队通过多进程 + MPS + TensorFlow Runtime 的技术方案落地，既能充分利用 GPU 的算力，同时部分场景还不需要对模型进行 TensorRT 转换。
通用 GPU 推理架构
因此我们的在线推理服务就能支持部署到 CPU 和 GPU 服务器，在部署环节选择不同的镜像来支持部署到不同的机器资源。在调用线上推理服务的时候，通过代理层封装调用细节，实现高效接入。
通用的特征处理
在 CPU 与 GPU 的推理实现中，模型推理入参类型是不一致的，这导致了有两套的特征处理逻辑，在实际算法实验迭代过程中，会带来额外的开发工作量。所以我们针对这个问题，对特征处理进行封装，实现不同的计算资源下，采用同一套特征处理逻辑，减少重复开发工作。在业务层面不需要关注底层采用的是 CPU 还是 GPU 资源，只需要专注业务逻辑和提升推荐效果。
落地实践与成果
vivo AI 推荐工程深圳团队把配置化推理服务的整体设计在横版视频、手机主题、智慧桌面信息流、原子阅读等多个推荐业务上做了落地实践。
手机主题推荐业务接入推荐中台后，离线模型训练后通过模型仓库一键部署上线，无需修改代码和人工操作发布系统，普通模型实验上线周期从 4 小时减少到 30 分钟左右。同时，对业务逻辑抽象组件化设计，结合推荐中台的分层实验功能，实验迭代效率明显提升，同时间内可支持的实验也从 5 个提升到 20 个。
智慧桌面信息流业务在模型推理环节，针对复杂模型采用 GPU 推理，在压测下 P95、P99 延迟都有明显降低, 整体的 QPS 提升约 5.2 倍。
CPU/GPU 推理性能压测数据对比
在相同精排请求 600 QPS，3000 Batch size 下，经测算模型推理机器成本节省约 75% 左右。
GPU 推理在智慧桌面信息流落地成本对比
另外， 2022 年 Q1～Q2 季度在横版视频业务上全流程（召回、排序、特征回传等环节）率先落地了特征仓库和通用特征服务，摒弃了冗长的配置文件和 Hard Code 的传统特征 SDK 方式获取特征，接入特征服务之后，助力算法工程师和数据工程师提升特征和模型的迭代效率，从工程问题和一致性问题中解放出来，把精力重新回归到对特征的抽取和模型实验效果的提升上。对比接入特征服务之前，整体人均曝光 +3.8%、CTR 持平、RCTR +0.6%，时长完播率也均有所提高，推荐效果稳步提升。
原子阅读业务在特征回传环节，通过特征集的方式做回传，代替原有的特征 XML 方式，后续特征的迭代都只需要在特征平台上做简单的配置，实现零代码更新升级。特征数据的变更迭代无需数据、工程等多方沟通，迭代周期从天级降低到分钟级。
从上图对比可以看出，在特征上线的效率和特征获取的性能两方面有较明显的优势。同时由于接入通用特征服务，线上、近线、离线的特征获取和处理也都使用了通用特征服务一套计算和处理函数逻辑，数据流一致性得到保障，目前落地的业务数据流一致性均 >99.9%。
特征服务最近 24 小时平均耗时曲线图
通过多个业务的部分场景落地验证，通用特征服务在性能上有着不错的表现和特征可配置的灵活性，通过对特征获取路径的抽象和解耦架构设计，解决了性能和灵活度不可兼得的难题，特征服务在线上的特征获取，在获取物料特征 Batch Size 是 40 ，特征集中物料特征个数是 250，单次调用特征服务可获取 10,000 条特征数据。在目前单机 TPS 100 情况下，单机每秒可获取特征总数达 10,000,000 条，拥有很高的吞吐能力。通过配置化做到零代码部署上线，具备分布式、高并发，以及海量吞吐的能力，真正做到特征开箱即用，特征即服务。
总结展望
综上所述，通过模型特征统一规范与配置，实现离线训练与在线推理的样本、特征一致；通过特征仓库与特征服务，解决单机压力瓶颈，提升特征获取和处理的迭代效率；通过模型仓库与模型服务，实现模型的全生命周期管理，并且提供一键部署能力；通过 CPU 和 GPU 的异构推理配置，可以灵活支持不同业务的推理需求。
近期配置化推理服务已经在 vivo 横版视频、手机主题、智慧桌面信息流、原子阅读等推荐业务逐步落地，后续我们将对接更多的推荐业务，持续完善推荐中台的组件和能力建设，提高业务的迭代效率，助力业务提升推荐效果。
作者介绍
王兆雄、严鹏、吴伟兴、陈炜基，vivo AI 架构工程师，来自 vivo AI 研究院推荐工程组深圳团队。
团队介绍：vivo AI 推荐工程组深圳团队，长期招聘 AI 架构工程师 / 技术专家，负责推荐、搜索业务多个方向的系统研发工作，坐标深圳。欢迎感兴趣的同学加入我们。可投简历至：wuweixing@vivo.com（邮件主题请注明：vivo 推荐工程组深圳团队）
未能投入生产的模型无法为企业或组织创造价值，作为 AI 工程中极其重要的组成，MLOps 的出现正是为了减少这种无用功。其提出了众多解决方案、最佳实践和工具，来帮助算法模型切实落地到业务实践中。将于今年 7 月 31 日 -8 月 1 日举办的 QCon 全球软件开发大会（广州站）「AI 工程与 MLOps 」专题将挖掘知名团队的实践案例。
