关于人工智能:vivo-推荐业务-x-DeepRec全链路优化实践

2次阅读

共计 5502 个字符，预计需要花费 14 分钟才能阅读完成。

作者：

vivo – 人工智能举荐团队：何鑫、李恒、周健、黄金宝

vivo 人工智能举荐算法团队在深耕业务同时，也在积极探索实用于搜寻 / 广告 / 举荐大规模性稠密性算法训练框架。别离摸索了 tensornet/XDL/tfra 等框架及组件，这些框架组件在分布式、稠密性功能上做了扩大，可能补救 tensorflow 在搜寻 / 广告 / 举荐大规模性稠密性场景有余，然而在通用性、易用性以及性能特点上，这些框架存在各种有余。

DeepRec 是阿里巴巴团体提供的针对搜寻、举荐、广告场景模型的训练 / 预测引擎，在分布式、图优化、算子、Runtime 等方面对稠密模型进行了深度性能优化，提供了丰盛的高维稠密特色性能的反对。基于 DeepRec 进行模型迭代不仅能带来更好的业务成果，同时在 Training/Inference 性能有显著的性能晋升。

作为 DeepRec 最早的一批社区用户，vivo 在 DeepRec 还是外部我的项目时，就与 DeepRec 开发者放弃亲密的单干。通过一年积攒与打磨，DeepRec 赋能 vivo 各个业务增长，vivo 也作为 DeepRec 深度用户，将业务中的需要以及应用中的问题踊跃回馈到 DeepRec 开源社区。

vivo 人工智能举荐算法组的业务蕴含了信息流、视频、音乐、广告等搜寻 / 广告 / 举荐各类业务，根本涵盖了搜广推各类型的业务。

为了撑持上述场景的算法开发上线，vivo 自研了集特色数据、模型开发、模型推理等流程于一体的举荐服务平台。通过成熟、标准的举荐组件及服务，该平台为 vivo 内各举荐业务（广告、信息流等）提供一站式的举荐解决方案，便于业务疾速构建举荐服务及算法策略高效迭代。

3.1.1 痛点

在理论业务实际发现，TensorFlow 原生 Embedding Layer 存在以下问题：

1. 动态 Embedding OOV 问题

在构建 Embedding Layer 的时候，TensorFlow 须要首先构建一个动态 shape[Vocab_size, Embedding size] 的 Variable，而后利用 Lookup 的算子将特征值的 Embedding 向量查问出。在增量或者流式训练中，会呈现 OOV 的问题。

2. 动态 Embedding hash 特色抵触

为了躲避上述的 OOV 问题，通常做法是将特征值 hash 到肯定的范畴，然而又会引入 hash 抵触的问题，导致不同的特征值共用同一个 Embedding，会造成信息失落，对模型训练是有损的。

3. 动态 Embedding 内存节约

为了缓解 hash 抵触，通常会设置比实在的特征值个数 N 大一到两倍的 hash 范畴，而这又会强行地减少模型的体积。

低频特色冗余

在引入稠密特色时，呈现频次较低以及许久未呈现的特色 ID 对于模型而言是冗余的。此外，穿插特色占据了大量的存储，能够在不影响训练成果的前提下过滤掉这些特色 ID。因而，迫切需要特色淘汰以及准入机制。

总的来讲，TensorFlow 的 Embedding Layer 对实在的业务场景有几个不太敌对的点，第一是可拓展性差，第二是 hash 抵触导致模型训练有损，第三是无奈解决冗余的稠密特色。而 DeepRec 奇妙地解决了上述问题，次要提供了基于 Embedding Variable 的动静 Embeeding 性能和特色准入 / 淘汰性能。

3.1.2 Embedding Variable

DeepRec 中的 EmbeddingVariable 以 HashTable 作为外部存储的根本构造，动静的创立 / 开释 Embedding 向量，适配了 Embedding 前向查问，反向更新等 OP，从而解决了用户的痛点。

在构建 Embedding Layer 时应用 DeepRec 的 Embedding Variable。利用 Embedding Variable 具备动静维度的个性，模型训练对新增的特征值无感知。此外，因为摒弃了 hash 的操作，训练的模型也是无损的，同时模型的体积也会放大。

3.1.3 特色准入 / 淘汰

特色准入：

DeepRec 提供了基于 BloomFilter 和 Counter 两种策略的准入机制。特色准入能够防止模型稠密特色的快速增长，回绝低频特色进入模型，影响模型收敛成果。

特色淘汰：

DeepRec 反对两种淘汰策略，一种是依照 global step 进行淘汰，一种是依照 L2 weight 进行淘汰，它们将不合乎规定的特色从模型参数中剔除，保障特色的有效性。

3.1.4 收益

动态 Embedding 降级到动静 Embedding

应用 DeepRec 的动静 Eembedding 替换 TensorFlow 的动态 Embedding 后，保障所有特色 Embedding 无抵触，离线 auc 晋升 0.5%，线上点击率晋升 1.2%，同时模型体积放大 20%。

ID 特色的利用

在应用 TensorFlow 时，vivo 尝试过对 ID 特色进行 hash 解决输出模型，试验表明这种操作比照基线具备负收益。这是因为 ID 特色过于稠密，同时 ID 具备惟一批示性，hash 解决会带来大量的 Embedding 抵触。基于动静 Embedding，应用 ID 特色离线 auc 晋升 0.4%，线上点击率晋升 1%；同时配合 global step 特色淘汰，离线 auc 晋升 0.2%，线上点击率晋升 0.5%。

3.2.1 痛点

目前 vivo 外部应用的是 TFRecord 数据格式存储训练数据，这种存储格局存在以下缺点：

1. 占用存储空间大

因为 TFRecord 采纳 protocol buffer 结构化数据存储，存储不够紧凑，占用空间比拟大，在训练时 I/O 开销也十分大。vivo 尝试过利用 prebatch 的形式存储 TFRecord 以节俭存储空间，然而此计划解析绝对简单，I/O 开销进一步加剧。

2. 非明文存储

因为 TFRecord 以二进制格局存储，无奈间接查看数据内容，存在解析艰难、不便进行数据分析的问题。

3.2.2 Parquet Dataset

Parquet 是一种列式存储的数据格式，可能节俭存储资源，放慢数据读取速度。DeepRec 的 Parquet Dataset 反对读取 Parquet 文件，开箱即用，无需额定装置第三库，应用简略不便。同时，Parquet Dataset 可能放慢数据读取速度，进步模型训练的 I/O 性能。

3.2.3 收益

vivo 外部尝试应用 Parquet Dataset 来替换现有 TFRecord，进步训练速度 30%，缩小样本存储老本 38%，升高带宽老本。同时，vivo 外部反对 hive 查问 Parquet 文件，算法工程师可能高效快捷地剖析样本数据。

在业务逐步倒退过程中，广告召回量增长 3.5 倍，同时指标预估数减少两倍，推理计算复杂度减少，超时率超过 5%，重大影响线上服务可用性以及业务指标。因而，vivo 尝试摸索降级革新现有推理服务，保障业务可继续倒退。vivo 借助 DeepRec 开源的诸多推理优化性能，在 CPU 推理革新以及 GPU 推理降级方面进行摸索，并获得肯定收益。

vivo 间接应用 TensorFlow 提供的 C++ 接口调用 Session::Run，无奈实现多 Session 并发解决 Request，导致单 Session 无奈实现 CPU 的无效利用。如果通过多 Instance 形式（多过程），无奈共享底层的 Variable，导致大量应用内存，并且每个 Instance 各自加载一遍模型，重大影响资源的使用率和模型加载效率。为了进步 CPU 使用率，也尝试多组 Session Intra/Inter，均会导致 latency 升高，服务可用性升高。

基于 ShareNothing 架构的 SessionGroup

DeepRec 提供的 SessionGroup 可能无效地解决上述问题，其根本架构如下图所示：

SessionGroup 可配置一组 Session，并且通过 Round Robin (反对用户自定义策略) 形式将用户申请散发到某一个 Session。SessionGroup 对不同 Session 之间的资源进行隔离，每个 Session 领有公有的线程池，并且反对每个线程池绑定底层的 CPU Core(numa-aware)，能够最大水平地防止共享资源导致的锁抵触开销。SessionGroup 中惟一共享的资源是 Variable，所有 Session 共享底层的 Variable，并且模型加载只须要加载一次。

在应用 SessionGroup 性能后，CPU 使用率低的问题显著失去缓解，在保障 latency 的前提下极大进步 QPS，单机 QPS 晋升高达 80%，单机 CPU 利用率晋升 75%。

通过 SessionGroup 的优化，尽管 CPU 推理性能失去改善，然而超时率仍旧无奈失去缓解。因为以下几点起因，vivo 尝试摸索 GPU 推理来优化线上性能。

多指标模型指标塔数较多
模型中应用 Attention、LayerNorm、GateNet 等简单构造
特色多，存在大量稠密特色

4.2.1 Device Placement Optimization

通常，对于稠密特色的解决个别是将其 Embedding 化，因为模型中存在大量的稠密特色，因而 vivo 的广告模型应用大量的 Embedding 算子。从推理的 timeline 能够看出，Embedding 算子扩散在 timeline 的各个阶段，导致大量的 GPU kernel launch 以及数据拷贝，因而图计算十分耗时。

Device Placement Optimization 齐全将 Embedding Layer placed 到 CPU 上，解决 Embedding layer 外部存在的 CPU 和 GPU 之间大量数据拷贝问题。

Device Placement Optimization 性能优化显著，CPU 算子（次要是 Embedding Layer）的计算集中在 timeline 的最开始，之后 GPU 次要负责网络层的计算。相较于 CPU 推理，Device Placement Optimization P99 升高 35%。

4.2.2 CUDA Multi-Stream 性能

在推理过程中，vivo 发现 GPU 利用率低，GPU 算力节约。DeepRec 反对用户应用 multi-stream 性能，多 stream 并发计算，晋升 GPU 利用率。多线程并发 launch kernel 时，存在较大的锁开销，极大影响了 kernel launch 的效率，这里的锁与 CUDA Driver 中 Context 相干。因而能够通过应用 MPS/Multi-context 来防止 launch 过程中锁开销，从而进一步晋升 GPU 无效利用率。

此外，模型中存在大量的 H2D 以及 D2H 的数据拷贝，在原生代码中，计算 stream 和拷贝 stream 是独立的，这会导致 stream 之间存在大量同步开销，同时对于在 Recv 算子之后的计算算子，必须等到 MemCopy 实现之后能力被 launch 执行，MemCopy 和 launch 难以 overlap 执行。基于以上问题，NV 专家计算团队的同学在 multi-stream 性能根底上进一步优化，开发了 MergeStream 性能，容许 MemCopy 和计算应用雷同的 stream，从而缩小上述的同步开销以及容许 Recv 之后计算算子 launch 开销被 overlap。

vivo 在线上推理服务中应用了 multi-stream 性能，P99 升高 18%。更进一步地，在应用 merge stream 性能后，P99 升高 11%。

4.2.3 编译优化 -BladeDISC

BladeDISC 是阿里团体自主研发的、原生反对存在动静尺寸模型的深度学习编译器。DeepRec 中集成了 BladeDISC，通过应用 BladeDISC 内置的 aStitch 大尺度算子交融技术对于存在较多访存密集型算子的模型有显著的成果。利用 BladeDISC 对模型进行编译优化，推理性能失去大幅度晋升。

BladeDISC 将大量访存密集型算子编译成一个大的交融算子，能够大大减少框架调度和 kernel launch 的开销。区别于其余深度学习编译器的是，BladeDISC 还会通过优化 GPU 不同档次存储（特地是 SharedMemory）的应用来晋升了访存操作和 Op 间数据交换的性能。图中能够看到，绿色是 Blade DISC 优化合并的算子代替了原图中大量的算子。

另外，因为线上模型比较复杂，为了进一步缩小编译耗时、晋升部署效率，vivo 启用了 BladeDISC 的编译缓存性能。开启此性能时，BladeDISC 仅会在新旧版本模型的 Graph 构造产生扭转时触发编译，如果新旧模型仅有权重变更则复用之前的编译后果。通过验证，编译缓存在保障正确性的同时，简直覆盖了编译模型的开销，模型更新速度与之前简直雷同。在应用 BladeDISC 性能后，线上服务 P99 升高 21%。

4.2.4 总结

DeepRec 提供大量的解决方案能够帮忙用户疾速施行 GPU 推理。通过一系列优化，相较于 CPU 推理，GPU 推理 P99 升高 50%，GPU 利用率均匀在 60% 以上。此外，线上一张英伟达 T4 显卡的推理性能超过两台 CPU 机器，节俭了大量的机器资源，机器老本升高 60%。

基于 CPU 的分布式异步训练存在两个问题：一是异步训练会损失训练精度，模型难以收敛到最佳；二是随着模型构造逐步简单，训练性能会急剧下降。将来，vivo 打算尝试基于 GPU 的同步训练来减速简单模型训练。DeepRec 反对两种 GPU 同步框架——SparseOperationKit(SOK) 和 HybridBackend。后续 vivo 将尝试这两种 GPU 同步训练来减速模型训练。

DeepRec 开源地址：https://github.com/alibaba/Deep

正文完