来源 InfoQ网站 技术访谈，本文系转发
2020 年 1 月 21 日 10:56
机器学习项目痛点
起初，vivo 也是采用类似“作坊式”的团队模式，每个团队针对各自要解决的问题进行规划，由此产生了一种小作坊式的生产局面。随着应用规模逐渐增大，这种模式的局限就暴露出来了。鲁文龙表示，这种模式下的机器学习项目会出现如下问题：
1、特征与样本层面，添加新特征流程较长，且不同业务间特征无法共用；特征与样本的处理和存储系统性能与稳定性不佳。
2、训练与调参层面，在大业务量场景下，深度学习模型分布式训练有一定门槛；线上效果不佳时，缺乏一套分析定位问题的方法论。
3、CPU 与 GPU 线上推理层面，驾驭 CPU 尤其是 GPU 的深度学习模型的高性能推理门槛较高；离线调参与线上工程开发速度不匹配，影响整体迭代效率。
4、缺乏端到端的系统支撑，每个业务都重复做一套烟囱系统，可维护性差；缺乏技术沉淀，团队间协作效率低，整体产出会受影响。
举例来说，鲁文龙所在团队起初主要负责广告系统的机器学习项目研发，当时经常遇到的一个问题就是离线训·练和在线推理结果不一致。为了保证性能，线上通常会用 Java/C++ 来写一套程序，离线通常会基于 Spark、Flink 这样的大数据工具套件来开发，离线和在线的工程师团队也是不同的，如此种种造成了出现问题很难定位与修复。为了解决上述这些痛点，团队决定研发一套统一的机器学习平台来支撑各项目快速迭代。
经过讨论，vivo 将机器学习平台定位在解决公共的工程性难点和痛点，比如特征工程、模型训练、模型推理和资源调度方面的问题，不需要每个团队都重新学习部署一套 K8s 等基础设施平台，降低算法工程师的使用门槛，从而提高业务迭代效率。
对于 AI 研究院的各业务场景的工程师来讲，平台提供了开发调试、高效调参、模型部署、效果监控等能力，降低上线门槛，提高迭代效率。在平台内部，由四个部分组成。
1. 特征工程系统：在规范特征格式、标准化数据流、统一存储与管理的前提下，以特征处理引擎为基础，构建更灵活增删特征、共享特征的系统；
2. 模型训练：在深度定制的框架与计算组件的基础上，如 Tensorflow、Horovod 等，通过大规模分布式训练引擎提供了使用简单、功能强大的训练能力；
3. 模型推理：在深度定制的推理框架与计算组件基础上，如 TensorRT、OpenVINO、TF Serving 等，提供 CPU 和 GPU 极致的高性能推理能力；
4. 资源调度： 通过 K8s 来管理与调度 CPU 集群和 GPU 集群，规模 2000+CPU 机器，1000+GPU 卡，来支撑大规模的模型训练任务与推理服务。
鲁文龙表示，第一阶段主要以 SDK 的形式将在特征、训练和推理上构建的能力嵌入到业务中，推动业务方使用。经过大半年的努力，机器学习平台已经在众多业务中落地。接下来，团队的更多精力将聚焦在打通端到端的能力，通过平台门户提供更优的产品体验给工程师。
在构建机器学习平台的过程中，vivo 也探索出一些亮点性工作。鉴于资源调度部分，几个月前已经通过文章介绍过了 (《Kube-batch 在 vivo AI 计算平台的应用》)，接下来就介绍下其他三部分的亮点工作。
特征工程系统
特征工程系统是由统一特征服务和样本生产服务组成，提供机器学习算法落地所需要的数据服务。它解决了特征生产效率，特征样本监控，特征处理一致性和数据一致性等问题；降低数据开发的入门难度，减少新业务上线成本，提高算法迭代上线效率。
前文提到的离线训练与线上推理结果不一致的问题，主要是两方面原因造成的：其一是离线和线上两套流程逻辑可能存在不一致；其二是时间上的延时，离线训练通常是在曝光时生成的样本，而线上推理则是在请求时。对于前者，vivo 团队基于一套基础的特征处理标准，通过配置化将两套流程统一起来使得问题完美解决。对于后者，平台根据特征变化程度进行分级，分别在请求、请求回传 (排序胜出后)、曝光回传 三个环节拼接不同的特征，这样在保证一致性的同时，大大减少了存储和宽带成本。除了这些方法外，鲁文龙团队还构建了验证一致性的系统方法。如此，这个问题就彻底解决了。
大规模分布式训练引擎
训练引擎以 SDK 的形式供业务方使用，用户只需配置特征格式和模型超参，即可使用。各种训练技巧即刻获得，包括极致的训练性能、分布式训练、分布式验证、增量训练、实时训练等。同时，也支持各种形式的定制，以满足各业务方的需求。
鲁文龙表示希望通过机器学习平台解决大规模分布式训练推理方面的工程性难题，其他团队只需要复用这些经验即可，精力更多地聚焦在业务效果指标的提升上，这样可以提升整个大团队的产出效率。
具体来说，vivo 机器学习平台团队在训练方面，主要优化了训练速度和模型对样本响应速度。
在训练速度提升方面，鲁文龙表示，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 的方案是利用有验证集的训练任务得到训练集上的指标来指导无验证集的训练任务何时停止（如下图）。
高性能推理引擎
通过构建高性能推理引擎来支撑 AI 研究院所有推理加速的需求，鲁文龙表示，对于业务使用方来讲，接入方式有两种：
- 服务调用，适合于传输参数量级少的业务，方便服务升级管理。
- SDK 调用，适合于传输参数量级大，极致推理性能优先的业务。
在引擎内部，基于 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 节省了数千万机器成本。
经验总结
对于同样希望建设机器学习平台的企业而言，鲁文龙也提出了自己的建议。他表示，机器学习平台研发团队内部最好有做过业务的人，要懂用户（也就是业务方）的需求，不然很难抓住用户痛点，向业务推广时也不好落地。
未来发展
从技术发展来看，鲁文龙表示，目前业界都在尝试深度学习，并且模型的复杂度越来越高，vivo 也继续在这方面探索高效的分布式训练和极致性能的推理能力，争取在众多业务上都获得不错的收益。扩展到人工智能领域，他补充道，比较值得期待的是大规模落地的业务场景上的突破，搜索推荐这些互联网常见的场景自不必谈，但目前语音或视觉等技术落地的大规模业务场景还不是特别多，跟移动互联网比起来。他认为，当众多业务场景大规模落地后，技术的商业价值凸显出来，随之而来的算法、算力等各个方面的突破才能形成持续的价值闭环。