美团搜索:推荐:⼴告场景训练引擎实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 美团搜索/推荐/广告场景训练引擎实践⻩军美团机器学习平台 2023年11月

2. 美团深度学习推荐系统模型训练挑战 • 大规模稀疏参数 • 个数从几百—>几千，增⻓了近10倍 • 总参数量从几亿—>百亿，增⻓了10~20倍 • 如何更加灵活、高效的存储大规模稀疏参数？ • 海量的样本 • 训练样本从到百亿—>千亿，增⻓了近10倍 • 如何保障业务能在1天内完成训练？ • 模型复杂度 • 越来越复杂，模型单步计算时间增⻓10倍以上 • 如何在复杂度持续提升的情况下，仍然能保障系统的性能？ • 大规模集群部署 • 大规模集群运行时，会遇到慢机和宕机 • 如何自动处理异常，保障系统的稳定运行？ 2

3. 目录 • CPU训练框架实践 • GPU训练框架实践 • 大规模集群部署 • 未来展望 3

4. TensorFlow PS分布式训练架构分布式训练流程开源TensorFlow扩展能力[1] 对于大流量业务，一次训练实验，从几个小时增⻓到了几天 [1] TensorFlow 1.x版本 4

5. Profling工具链 • 自动化实验框架 • 问题分析工具链 • TF原生是单步采样，不支持全局监控 • 抽象实验过程（数据、模型、参数） • TF原生指标太粗，未展示通信算子全链路耗时 • 自动采集各类监控指标 • 全链路细粒度埋点，与公司原CAT打通 • 自动化、多轮次实验并生成报告工欲善其事，必先利其器 5

6. 系统分析1 总参数增⻓10~20X 稀疏特征个数增加10X 单次请求压力变大 PS需要更多内存需要扩更多PS 通讯压力 PS并发压力训练样本扩大10X 通过扩展Worker加速模型计算增加10X 总访问请求压力单位算力吞吐降低通讯压力 PS并发压力不优化要扩更多Worker 核心负载： 1.通信压力 2.PS并发压力横向扩展PS堆资源，看来起可以解决问题？ 6

7. 系统分析2 2.5 2.375 2.25 2.125 训练流程关键点： 1.worker单步训练需要和所有PS通讯同步完成 2 10 20 30 40 50 PS数量扩展PS到一定数量单步训练时间增加 2.worker每一步训练顺序执行 3.整个训练过程要执行上百万、上千万步核心原因：链路延迟超过加PS算力并发收益核心挑战：有限PS实例下的分布式计算优化 7

8. 高性能弹性稀疏参数大规模稀疏参数使用tf variable弊端： 1.参数大小需要提前设定，带来巨大的空间浪费 2.不支持动态伸缩，无法支持Online Learning 我们的方案： 1.基于HashTable实现了自动弹性伸缩参数，避免开辟冗余空间 2.支持自动分片，分布式存储，解决参数存储扩展性问题 3.API设计上保持与社区版本兼容，用户接入成本低解决大规模稀疏参数高效存储问题大规模稀疏参数的HashTable方案 8

9. PS架构的训练吞吐优化1 • PS负载均衡优化 • 所有稀疏参数和大的稠密参数自动、均匀的切分到每个PS上 • 解决了原生Adam优化器，β参数全局热点的问题（复制+冗余计算） • 单实例PS并发优化 • 核心数据结构HashTable选用了高并发的tbb::concurrent_hash_map • 基于内存池化的方式优化HashTable的内存管理 Adam优化算法 HashTable内存优化 9

10. PS架构的训练吞吐优化2 • 通信优化 • 通信协议：使用更高效的通信协议rdma • 聚合通信：合并稀疏参数+对应的动量+对应低频过滤计数器的通信 • 计算和通信的重叠 • 在整个训练过程，通信和计算会相互等待，延迟时间占比48%（如下图） • 参数查询、参数训练、参数更新串行逻辑流水线化，但会影响算法精度 • 只处理影响小&通讯占大头的稀疏参数（95%+通讯），且控制并行步数、让算法精度控制在接受范围内计算等待通讯时间通讯等待计算时间 10

11. 整体优化效果分布式扩展性从1百 worker->上千 worker 大规模训练同资源吞吐提升2倍以上支持公司1年样本1天内完成训练多层次、多⻆度深度定制的TensorFlow 11

12. 目录 • CPU训练框架实践 • GPU训练框架实践 • 大规模集群部署 • 未来展望 12

13. 为什么要做GPU训练？ • 领域SOTA模型越来越复杂[1]，业务模型单MatMal计算，3年耗时占比增⻓26% • 优化的TensorFlow CPU训练架构，CPU使用率已经90%以上，很难有压榨空间 • 大规模分布式异步训练，并发太大，可能会有损算法效果（和模型强相关），在学术界也属于难题 [1] In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA) 13

14. 为什么要做GPU训练-续？ GPU核心数多90倍，访存带宽快10倍经过三代产品迭代，多卡带宽增⻓9倍多级存储体系（性能、容量、成本的权衡）经过8年的迭代，网络带宽提升16倍新硬件迭代带来的红利：1台GPU服务器可以支撑大多数业务日常算力需求 14

15. 系统演进策略目标：原生TF接口上，支持TB级模型的分布式GPU训练架构，相比CPU性价比提升到2倍以上系统演进策略：按照需求覆盖面，逐步交付，每代架构可演进 1.0架构：单机多卡100G模型 2.0架构：单机多卡TB模型 3.0架构：分布式TB模型 15

16. 系统分析 CPU分布式负载系统关键负载分布式CPU方案算力读取样本耗费大量的CPU 模型计算已经把当CPU打满存储大模型参数通常需要几TB存储内存：几十TB 网络 ~1000Gbps CPU：几千核 ~1000Gbps GPU单节点负载单机GPU方案 CPU：96核 GPU核：8 x 6192 CUDA Core GPU显存：8 x 80GB 内存：TB级 SSD：几十TB级 8 x 100Gbps 迁移新方案硬件面临问题核心计算需要尽量都切换到GPU 上，否则GPU服务器的CPU会成为瓶颈单机GPU显存和内存无法承载大模型参数需要用好多网卡核心挑战：基于硬件特性，打造软硬一体的架构 16

17. 1.0 整体架构保持开源组件设计范式核心模块相互解耦数据模块：自研数据分发模块，支持NUMA亲和性，多网卡数据下载计算模块：每张GPU卡启动一个TensorFlow训练进程执行训练通信模块：每个节点启动一个Horovod进程来进行卡间通信 17

18. 1.0 系统流程 • 参数存储 • 大规模稀疏参数切分到多卡上 • 小的稀疏参数+稠密参数每张卡都存一份 • 不同特征流程 • 大规模稀疏参数：通过all2all同步ids，embedding values和梯度 • 小的稀疏参数：通过allgather同步梯度 • 稠密参数：通过allgather同步梯度第一版：GPU的SM利用率只有10%~20% 相比CPU没有太大优势 18

19. 1.0 系统优化1 • 数据IO Pipeline • 样本拉取：NUMA亲和性 + 多网卡加速，数据分发进程和TF进程zerocopy传输数据 • 特征解析：通过SIMD指令集提升TFRecord解析速度（后升级到列存orc，大大减少这部分耗时） • MemcpyH2D流水线：基于tf prefetch实现了PipelineDataset，提前把Host数据（Pinned Memory）拷⻉到GPU显存 • 硬件调优：在网络传输优化方面，开启LRO（large-receive-offload）、TC Flower的硬件卸载、tx-nocache-copy等特性，提升网络带宽17%。内存延迟和带宽优化方面，尝试了3种NPS配置，综合业务场景和NUMA特性，选择了NPS2，此外，结合其他BIOS配置（例如APBDIS，P-state等），可以将内存延迟降低8%，内存带宽提升6%。端到端训练吞吐提升40% 19

20. 1.0 系统优化2 • CPU的计算迁移到GPU • 耗时较⻓（计算密集型），传输数据量较大（访存密集型）的CPU算子，需要实现GPU版本算子 • 实现了最关键的稀疏参数的GPU计算（HashTable表操作相关，耗时占比40%以上），GPUHashTable的计算量并不大，核心收益是GPU的访存带宽是内存的10倍 • GPU上的计算跑得更快 • 高频算子手工优化，获得更高性能（如：Unique、DynamicPartition、Gather等） • 普通算子编译优化(自动重写算子，提升计算和访存效率)，获得较优性能 • 利用Tensor core硬件特性，使用半精度甚至INT8加速不同特性tensor core的性能利用好GPU高算力、高访存带宽优势 20

21. 1.0 系统优化3 进一步合并通信数据，减少通信次数，同时减少Kernel Launch次数、提升访存带宽更亲和GPU的通信模式，训练吞吐提升85% 21

22. 2.0 整体架构继续保持开源组件设计范式复用了1.0架构的核心工作用户接口与1.0架构保持一致自研高性能异构参数服务器组件 1.基于外置独立进程，MQ做控制面、共享内存做数据交换的设计 2.支持内存、内存+SSD的混合存储模式 22

23. 2.0 关键演进增加异构参数服务器执行链路后，增加了CPU和SSD的操作 4级流水线->7级流水线 23

24. 3.0 整体架构支持多种存储模式的多机多卡全显存模式：直接通过Horovod完成多卡之间的数据交换异构存储模式：稀疏参数通过BoosterPS完成数据交换，稠密参数通过Horovod 24

25. 3.0 关键演进 direct all-to-all Hierarchical all-to-all 利用Horovod的分组通信，优化通信传输 25

26. 业务落地 • 系统完备性 • 支持了GPU训练的各种类型任务（包括：train/eval/predict） • 支持CPU和GPU训练出来的模型相互导入 • 支持了1~N卡的训练，同时针对1，2，4卡的任务还进行了专项优化 • 封装了代码模板，可以支持CPU和GPU任务，一行代码进行切换 • 训练效果 • CPU是异步训练，GPU是同步训练，且GPU训练batch size要大很多，模型需要重新调参 • 为了方便调参，把所有参数的聚合方式都修改成了统一（求平均） • 用Linear Scaling Rule的原则指导调整学习率 • 业务上线效果 • 目前已经在美团大规模上线，相比业务CPU训练，性价比提升到：2~6倍 • 2.0架构相比1.0架构，上线业务性能损耗在5%以内 • 3.0架构多机扩展性，上线业务近线性扩展到128卡 26

27. 目录 • CPU训练框架实践 • GPU训练框架实践 • 大规模集群部署 • 未来展望 27

28. 自动故障恢复1 • 任务自动异常诊断 • 自动采集各类子任务各阶段执行速度 • 根据内置策略判断那些任务异常 • 针对慢机策略 • 容忍范围内：动态分配数据处理任务 • 超过容忍范围：杀掉慢机上的任务，重新调度任务动态数据分配流程 28

29. 自动故障恢复2 • 完备的恢复机制 • 自动重新组网，如果是PS异步训练支持worker实例级恢复 • 自动数据进度的checkpoint，数据和模型的checkpoint恢复一致性保障细粒度任务恢复完备的任务恢复（数据+模型） 29

30. 目录 • CPU训练框架实践 • GPU训练框架实践 • 大规模集群部署 • 未来展望 30

31. 未来展望算法框架芯片 Machine Learning Systems Pathways? 31

32. Q&A

33. 招聘：机器学习基础架构工程师/专家邮箱：huangjun03@meituan.com 更多技术干货欢迎关注“美团技术团队”