/tags/dlrm/ Recent content in DLRM on The Site of laekov Hugo -- gohugo.io en © laekov Wed, 20 Aug 2025 00:00:00 +0000 /technical/hypereca/ Wed, 20 Aug 2025 00:00:00 +0000 /technical/hypereca/ 闲话 - 前 这是一篇 ATC'25 论文 的中文简要版本. 然而这篇文章在学术创新上实在乏善可陈，正好多说一点闲话了。这也是为什么没有在文章发表前就把博客写出来，不然万一被撤稿了可就搞笑了。 写这篇博客是 laekov 一直以来坚持要把自己发表的每篇文章都翻译成中文，因为曾经的 laekov 觉得凭什么论文都要用英文写呀，而且八股文读起来好麻烦呀，用中文简洁明了地把文章讲清楚不是更好吗。 然后天真的 laekov 读博五年一共也就中了两篇文章。这是第二篇，中稿时间是毕业前三个月。 HypeReca 这个名字是 Hybridly Partitioned Embeddings for Recommendation Model Training Acceleration 的各种胡乱拼凑里找了个听起来好听一点的。 背景 基于深度学习的推荐模型是现在主流的推荐算法，它分为学习元素特征的稀疏部分和学习元素间关系的稠密部分。 稀疏部分主要是非常稀疏的嵌入表 embedding tables，它们可能会有 TB 级别甚至更大，所以得要很好地分布式地存下来，并且支持高吞吐地读取和更新。 稠密部分通常由传统的 DNN 构成，属于计算密集型任务（比如 CNN / MLP），所以得用 GPU 来加速。 在做分布式训练的时候，这两部分由于特性不同所以采用了不同的并行方式：稀疏部分用模型并行（切分存储），稠密部分用数据并行（小模型，大 batch size）。 这两部分之间通过 all-to-all 集合通信来传输所需的数据和用于更新的梯度。 然后就会发现在 scale up 的时候两部分之间的通信是瓶颈，可能会占到迭代时间的 90% 以上。 解决方案 这篇文章的核心想法其实很直白：embedding data 有冷有热。 把频繁访问的热数据找出来，也用数据并行的方法来存，重复地放到所有 GPU 上。 接下来要解决两个问题： 首先，挑多少热数据比较合适？ 热数据越多，可以省掉的 all-to-all 通信就越多，但同步热数据所需的 all-reduce 量就越大。 这里正好是一个在单峰函数上找最优的 trade-off。结合实际数据建模观察一下即可。