1. 从推荐模型的基础特点看 袁镱 腾讯

2.

3. 个人简介 ! 袁镱 博士，专家工程师 ! 研究方向：机器学习系统，云计算，大数据系统 ! 负责腾讯平台与内容事业群（PCG）技术中台核 心引擎：无量系统。支持大规模稀疏模型训练， 上线与推理 ! 无量系统 ! 项目于17年启动，先后经过了6个主要版本的 迭代 ! 覆盖腾讯PCG全部业务的推荐场景，支持腾讯 IEG，CSIG，QQ音乐，阅文等业务的部分推 荐场景

4. 提纲 ! 推荐场景深度学习系统的基本问题与特点 ! 推荐类模型的深度学习系统设计 ! 系统维度 ! 算法维度 ! 总结

5. 基于深度学习模型的推荐流程，场景与目标 用户行为数据上报 数据 通道 特征 处理 特征 库 实时样本 生成服务 离线样本 生成任务 样本 存储 数据 通道 数据 落地 训练系统 无量 Serving系统 模型 登记 HDFS ! 推荐场景的重要性 模型 管理 上线 管理 模型 上线 业务服务 无量 预测 请求 RGW/Cos/ kafka 混排 排序 召回 内容 获取 请求 ! 千亿级推荐模型应用 ! PCG的图文，视频推荐（腾讯视频，腾讯新 闻，QQ看点，浏览器，微视， QQ小世界等） O1. 千亿级特征（TB级）的模型的在线/离 线训练，在线推理服务和持续上线 ! 腾讯系内容推荐：阅文集团，QQ音乐 O2. 针对推荐特点的深度优化，达到业界先 进水平 ! Facebook推荐场景推理成本占AI推理成本的 >72% [ISCA2020 RecNMP]

6. 推荐系统的核心特点 Item推荐 Item 推荐系统 User 1.1 User与推荐系统交互，7*24小时 流式学习 在线推理 模型上线 文章 新闻 模型训练 视频 用户反馈 Item特征 1.2 Item和User新增，离开/遗忘， Embedding空间动态变化。 百万级稠密 交叉参数 ! Feature 2（数据的时空特点） 2.1 短时间内只有部分item和user被 命中，只有部分参数被用到 访 问 百 分 比 单个样本命 中的key 千亿级 稀疏输入 层参数 本小时访问过的key 上小时访问过的key 时间（小 时） ! Feature 3（机器学习的特点） ! Feature 1（基本特点） ! 2.2 hotkey现象，且训练与推理的 hotkey高度重合 比如：性别，年龄等取值少的特征； 热⻔文章的特征，活跃用户的特征 Embedding参数 少量的高频key占据了主要访问需求 ID/tag/交叉特征 小特征 中型特征 (全量为：亿，千亿) （个） 一段时间样 本命中的 unique key Embedding以稀疏的方式表达信息 ID/tag/交叉特征 (千，千万) （百） 小特征 中型特征 （个） （十） 短期命中的高频key随时间缓慢变化

7. 大规模推荐模型深度学习系统基本解决维度 分布式 ! Feature 1（基本特点） ! Feature 2（数据的时空 特点） 系统 1. 高性能 2. 效果无 损的优化 大规模 优化 模型 算法 ! Feature3（机器学习 的特点）

8. 大规模推荐模型深度学习系统基本解决维度 分布式 ! Feature 1（基本特点） ! Feature 2（数据的时空 特点） 系统 1. 高性能 2. 效果无 损的优化 大规模 优化 模型 算法 ! Feature3（机器学习 的特点）

9. 训练框架—基于参数服务器架构的分布式训练框架 Feature 1: 动态空间 Feature 2.1:短时间内只有部分item和user 被命中，只有部分参数被用到 TB级模型 分片 存储/更新 参数按需 获取/更新 百TB数据 分片训练

10. 异步训练流水线和多级存储：提升性能，降低内存成本 ! 常规训练流水线 Worker Reader 样本读取 样本解析 样本读取 样本解析 需保持顺 序，以保证 训练效果 ! 问题： ! 异步参数处理流水线 Worker Parameter Server Learner Request Handler Storage 参数拉 取 样本解析 查询Sparse Table 查询Dense Tensor 返回参数 训练 参数更新 查询Sparse Table Learner Reader 样本读取 Batch入队列 Parameter Server Request Handler Storage Batch入队列 Unique keys 参数 预准备 Lookup+ pooling 算子融合 参数拉取 查询Dense Tensor 返回参数 训练 参数更新 查询Sparse Table 磁盘 近期训练 参数管理 更新参数 查询Dense Tensor 更新参数 ! Learner线程中参数拉取和参数更新对性能影响大 ! 内存成为主要资源瓶颈。由于需要等待全部参数 就绪，Parameter Server难以利用速度慢的存储 介质 ! 效果： ! 在不影响训练效果的情况下，降低参数准备与更新耗时，提 高训练速度。训练耗时下降超50% ! 异步storage线程，支持基于冷热数据的多级存储。内存消 耗下降30%-70%

11. 基于GPU的多级存储训练：更高的性价比 ! Feature 2.1: 短时间内只有部分item和user被命中， 只有部分参数被用到 ! 方案 ! 原有：内存能够存储的参数->对应的样本量Group 1. 减少节点数 分布式训练的慢机与同步问题 2. 提升节点同 构性 ! 新增：显存能够存储的参数->对应的样本量Pass ! 新增：GPU并行操作友好->CSR格式的显存数据访问 ! GPU训练的优势 ! 更少的机器节点，更少的分布式系统相关问题 ! 更高的性价比 ! 推荐模型GPU训练的挑战 ! 显存（A100最大80GB）放不下TB级的模型 ! GPU多线程并行计算能力对稀疏数据不友好 SSD磁盘 10TB 全部参数 内存 1TB 显存 32/40/80GB 即将用到的参数 正在训练的参数

12. 推理服务—分布式Serving架构 ! 业务需求 ! 模型大小超TB ! 单个请求需要15W个key ! 读写架构 ! 耗时要求10ms以下 ! 资讯业务请求量大 （>10000请求/秒） ! 模型有多个版本 ! 多线程无锁：基于模型版本的读写分离 >15亿key/秒 CPU型服务 ! 多机：多副本并行读取 近千台 ! CPU：固定64位key，基于L1缓存的查 询优化 并发查询优化 网络型服务 数十台 ! 原有在线分布式存储系统的 问题 ! 主备模式资源严重浪费 ! 数据读写需要加锁 ! 支持多模型和模型多版本 困难 只读版本 Feature 2.2 Hotkey缓存优化 内存型服务 <10台 写版本

13. TB级模型实时上线 ! 问题：TB模型实时多地传输和加载成本高 ! 更灵活的用法：模型多切片，按需上线 ! 方案：高低频分别上线 训练端生成高频参数集 独立通道上线 降低请求毛刺 Feature 2.2 Hotkey变化慢 ! Dssm ! wdl 业务服务 MB级别DNN部分 推理节点 1. 获取用户向量 SDK Sparse Hotkey 2. 向量召回 召回索引服务 异步 刷库 推理节点 推理节点 分布式 Serving集群 分布式 Serving集群 分布式Serving集群 Group 1 Group N ... 副本1 副本2 副本1 副本2 TB级别Embedding部分 全量模型，TB级，低峰期（Cos存储） 增量模型，GB级，20分钟（Cos存储） 实时模型，KB级，秒（Kafka） Feature 2.1: 短时间内只 有部分参数被用到

14. 大规模推荐模型深度学习系统基本解决维度 分布式 ! Feature 1（基本特点） ! Feature 2（数据的时空 特点） 系统 1. 高性能 2. 效果无 损的优化 大规模 优化 模型 算法 ! Feature3（机器学习 的特点）

15. 通讯量可以变小来提升训练速度么？---参数，梯度压缩 ! 问题： 特点 Dense参数，每次 都用，快速收敛 Sparse参数，随数 据变化，收敛度差 异大 混合压缩 方案 基于动态阈值 的稀疏化压缩 float16压缩 ! 参数w和梯度g占据主要的通讯量，拉⻓了请求时间 ! 常规的数值无损的压缩方法效果不明显 ! 业界主流做法： ! 量化 float32->float16->int8->int4->2bit 直接压缩->训练算法补偿 ! 稀疏化。累计发 送，需要做本地 梯度修正 效果 ～-90% -50% 训练速度提升 10%-30% [2020] Compressed Communication for Distributed Deep Learning: Survey and Quantitative Evaluation [ICLR2018]Deep Gradient Compression: Reducing the Communication Bandwidth for Distributed Training

16. 在线推理服务成本高，上线模型可以变小么？---模型压缩 痛点： 线上服务 成本 > 训练任务 成本 内存是主要瓶颈 1. 更少的values： 百度 优点：与优化器无关 变⻓Embedding 特征出现次数少，用1个float 结合show/click，有效果提升 2. 更少的key： 问题： CV/NLP低频上线，常用的模型 压缩算法不适应推荐场景 阿里 思考： 模型的大小由什么决定？ Key + embedding values 优点：1. 稀疏度高 缺点：特定优化器有 效，与adam有效果 差距 优点：与优化器无关 key级别的稀疏化 3. 更短的values 无量 2. 变⻓编码，不利于性能优化 2. 实现简单 group lasso a) 缺点：1. 只适合低频特征多的场景 混合精度： float16+int8+int4 b) 量化压缩，1bit或2bit 无量同时支持四种方法 缺点：方案b需要量化训练

17. Embedding table可以设计得更小么？Double Hashing 业界方案：Double Hashing 压缩手段除了量化和稀疏化，还有什么？因式分解 Facebook [KDD21] Compositional Embeddings Using Complementary Partitions for Memory-Efficient Recommendation Systems Embedding Table与第一层fc可以看作低秩矩阵分解 Twiiter [RecSys21] Model Size Reduction Using Frequency Based Double Hashing for Recommender Systems 矩阵分解 原始矩阵 9 512 腾讯，阿里，头条也都支持了Double Hashing 512 9 hash1(key) 9 亿 亿 下一步的 问题： 解空间 千 万 key 千 万 hash2(key) 场景 内存节省 1. Embedding Table的信息仍然非常稀疏 场景1 88% 2. 直接压缩key空间和缩小value⻓度都会导致模型效果下降 场景2 64%

18. 未来方向—现有推荐架构的问题，算法工程协同的解法 ! 推荐全链路自适应 ! 统一建模，根据请求量削峰填谷，资源利用最大化 问题1. 推荐链路的漏斗 是对资源的巨大浪费 ! 多场景建模 [CIKM2021] One Model to Serve All: Star Topology Adaptive Recommender for Multi-Domain CTR Prediction ! 预训练模型Bert GPT-3在CV/NLP大行其道， 相关技术正在进入推荐领域 [ijcai2021] UNBERT: User-News Matching BERT for News Recommendation [CIKM2021] Self-Supervised Learning on Users’ Spontaneous Behaviors for Multi-Scenario Ranking in E-commerce 问题2. 结果利用 不充分，响应不 够快 端上 重排 [KDD2020] DCAF: A Dynamic Computation Allocation Framework for Online Serving System ! 更基础的复杂模型，场景的快速适应 ! 端云一体的协同 推荐技术 问题3. 几十个场 景，独立链路 场景1 场景X [2021] MC2 -SF: Slow-Fast Learning for Mobile-Cloud Collaborative Recommendation

19. 总结 目标 ! 千亿级推荐模型应用 O1. 千亿级特征（TB级）的模型的在线/离线训练， 在线推理服务和持续上线 O2. 针对推荐特点的深度优化，达到业界先进水平 推荐场景特点 ! Feature1（基本特点） Item和user变化导致特征随时间新增，遗忘。 Embedding空间是动态的。 ! Feature 2（数据的时空特点） 2.1 短时间内只有部分item和user被命中，只有部分参 数被用到 2.2 hotkey现象，且训练与推理的hotkey高度重合 ! Feature 3（机器学习的特点） 信息以稀疏的方式表达 方案

20. Q&A

21.

22. Thanks