【ASPLOS2024】RECom:通过编译器技术加速推荐模型推理,论文中选并获得荣誉奖项!

2024年5月,关于推荐模型自动编译优化的论文 《RECom: A Compiler Approach to Accelerate Recommendation Model Inference with Massive Embedding Columns》 在系统领域顶会ASPLOS 2024上中选并进行了展示,并被授予了Distinguished Artifact Award 荣誉,以表彰RECom的易用性与结果的可复现性。

image.png

RECom是一个旨在加速GPU上深度推荐模型推理的机器学习编译器,解决了已有机器学习编译器无法有效优化推荐模型中重要的嵌入层计算的问题。RECom提出了一种新颖的面向子图间并行的融合方法,以在单个GPU内核中生成处理大量嵌入列的高效代码,大幅减少了内核启动的开销并显著提升了GPU的利用率。通过一个形状计算简化模块来解决动态形状下形状计算带来挑战,并通过一个嵌入列子图优化模块来消除冗余计算。在阿里巴巴的四个真实的内部生产推荐模型和两个生成模型上评估了RECom,实验表明,RECom在端到端推理延迟和吞吐量方面分别优于TensorFlow基线6.61倍和1.91倍。

背景

基于深度学习的推荐模型在各大企业的业务中变得越来越重要。通过为用户推荐合适的商品,能够帮助提升客户体验,增加销售额,以及提高客户保留率。典型的推荐模型包括两部分,即嵌入层和深度神经网络层(DNN)。 在生产环境中,嵌入层通常由对应不同特征字段的大量嵌入列(即通过查表将输入特征转换为嵌入向量的子图,如下图中虚线方框所示)组成,它能将输入的特征(比如用户ID,商品ID等)映射到低维的连续向量。


image.png

为了获得更高的模型精度,开发人员通常会生成数千个统计特征,并使用不同的嵌入列来处理它们。 然而,处理如此大量的嵌入列是昂贵的。 例如,我们在阿里巴巴的模型上进行的实验表明,嵌入列可以占据GPU上99%以上的端到端推理延迟。 因此,业务中迫切需要对推荐模型中的海量嵌入列进行优化。

挑战

虽然目前已有一些加速嵌入层计算的手写算子库[1],但它们很难在真实业务中被广泛应用,因为它们不可能在库中遍历嵌入层中所有可能的算子组合。此外,出于隐私考虑,实际业务中经常要求根据模型的计算图IR(比如TensorFlow GraphDef)而非源代码来进行优化。然而,一个公司的业务中通常会包含大量具有不同嵌入列结构的模型,并且一个模型可以包含上百万行的IR。因此,基于这些IR再手工地使用这些算子库来重新搭建所有的业务模型是不现实的。

另一方面,机器学习编译器,如XLA[2]等被广泛地应用于自动加速机器学习模型的计算。然而,目前的机器学习编译器主要关注于DNN的计算,而无法为嵌入层中包含的大量嵌入列提供有效的优化。它们主要存在以下三个问题:

首先,在 GPU 上为数千个嵌入列中的大量算子生成有效的代码是一项挑战。现有编译器的算子融合策略既无法有效消除模型中大量的非计算开销(包括内核启动与算子调度),也无法充分利用模型中子图间的并行性。我们在一个特定模型的实验上发现,XLA 可以为该模型生成超过10,000个GPU内核,这会引入大量的非计算开销,进而导致GPU的活跃时间仅占33%。并且,线上推理时输入的batch size通常不会太大,导致大多数生成的GPU内核的Waves per SM都非常小(小于 0.06),意味着大部分的GPU SM在执行中都没有被利用。


image.png
image.png

image.png

其次,推荐模型通常具有动态形状(dynamic shapes)。传统的机器学习编译器通常依赖张量的形状来进行各种优化,而推荐模型的计算图中的张量形状一般无法在编译期获取。一方面,动态形状造成的张量间形状关系信息缺失阻碍一些编译优化的pass。另一方面,动态形状场景下,部分算子(如SparseReshape)需要形状的输入,继而引入了大量形状计算。形状计算与张量计算的耦合使得计算图变得复杂,阻碍了后续的图优化。

下图(a)展示了一个级联SparseReshape的子图,其中蓝色的算子表示形状计算。由于SR1输出的sparse tensor的消费者只有SR2,因此第一次reshape是冗余的。理想情况下,编译器检测到这样的情况后可以直接把SR1的输入张量(即张量1)连接到SR2,越过冗余的SR1,如(b)中所示。然而,由于形状计算与张量计算的耦合,导致实际转化后的图会如(c)中所示,SR1并不能被正确的优化掉。


image.png

第三,现有的机器学习编译器忽视了推荐模型中存在的大量冗余计算。通过对业务模型的分析,我们观察到现有模型普遍存在大量的冗余计算。例如,使用TensorFlow框架进行嵌入表查找时会引入一些边界检查的计算,而这些检查在整个嵌入列子图的上下文里可能是冗余的,因为在经过哈希/分桶等操作后,用于嵌入表查找的索引已经满足了要求。在极端情况下,一个嵌入列中80%的GPU计算时间可能都是冗余的。

破局

我们提出了第一个端到端的推荐模型优化编译器RECom来解决以上的问题。

针对大量嵌入列的GPU代码生成,RECom 提出了一种子图间并行性导向的算子融合方法,将嵌入层中数千个嵌入列包含的大量算子全部融合(fuse)到一个GPU kernel中。一方面,这种方法使得RECom 能够消除频繁的内核启动与框架调度,显著减少嵌入层执行时的非计算开销。另一方面,为了生成具有高并行性的代码,RECom 将独立的嵌入列映射到不同组的GPU 线程中。每个线程组中的线程协作处理一个嵌入列,并利用GPU 的层次存储来进行中间数据缓冲和线程间通信。通过这种方式,RECom 可以有效地利用GPU 来挖掘推荐模型嵌入层中算子内部和嵌入列间的并行性。


image.png

为了解决动态形状与形状计算带来的问题,RECom提出了一种基于符号表达式的方法。类似于BladeDISC[3],RECom 通过下图中的四种pattern构建了嵌入列的全局符号形状表达式,并利用这些表达式来确定不同张量的形状间关系。


image.png

得到形状的符号表达式后,RECom进一步将所有形状计算子图用统一的算子进行重构。重构后的ShapeConstruct算子仅依赖于生成所需符号的算子,而非依赖于原计算子图的输入。
这样,RECom得以解耦张量计算与形状计算来简化计算图。回到之前冗余SparseReshap的例子,再经过形状计算重构后,SR2输入形状对SR1的依赖被消除,因此在经过原来的编译优化pass后,我们能得到下图的结果,成功去除了冗余的SR1。

image.png

对于嵌入层中存在的大量冗余计算,我们在RECom中开发了一个嵌入列子图优化模块,针对性地为常见的冗余计算设计了优化。具体细节可以参考我们的论文。

RECom的整个编译优化流程如下图所示。


image.png

与此同时,阿里云PAI团队与悉尼大学合作的论文《MonoNN: Enabling a New Monolithic Optimization Space for Neural Network Inference Tasks on Modern GPU-Centric Architectures》在OSDI2024中选,论文创新性地提出了MonoNN,这是第一个能够为单个GPU上的常见静态神经网络(NN)推理任务提供新的整体设计和优化空间的机器学习优化编译器。MonoNN可以将整个神经网络容纳到单个GPU核心中,大大减少了非计算开销,并从新形成的整体优化空间提供进一步细粒度的优化机会。最重要的是,MonoNN确定了各种NN运算符之间的资源不兼容性问题,这是创建这样一个整体优化空间的关键设计瓶颈。MonoNN通过系统地探索和利用跨不同类型的NN计算的并行补偿策略和资源权衡,并提出了一种新的独立于调度的群体调谐技术来显著缩小极其庞大的调谐空间。评估表明,MonoNN的平均加速比比最先进的框架和编译器提高了2.01倍。具体而言,就端到端推理性能而言,MonoNN在TVM、TensorRT、XLA和AStitch方面的表现分别高达7.3倍、5.9倍、1.7倍和2.9倍。
目前,MonoNN已开源,如需获取MonoNN源代码请前往https://github.com/AlibabaResearch/mononn;

论文地址:https://dl.acm.org/doi/10.1145/3623278.3624761

论文信息

论文标题:《RECom: A Compiler Approach to Accelerating Recommendation Model Inference with Massive Embedding Columns》

论文地址: https://dl.acm.org/doi/10.1145/3623278.3624761

参考文献

[1] NVIDIA. NVIDIA-Merlin/HugeCTR. https://github.com/NVIDIA-Merlin/
HugeCTR, 2023.

[2] Google. XLA: Optimizing Compiler for Machine Learning. https://www.tensorflow.org/xla, 2023.

[3] Zhen Zheng, Zaifeng Pan, Dalin Wang, Kai Zhu, Wenyi Zhao, Tianyou Guo, Xiafei Qiu, Minmin Sun, Junjie Bai, Feng Zhang, Xiaoyong Du, Jidong Zhai, and Wei Lin. BladeDISC: Optimizing Dynamic Shape Machine Learning Workloads via Compiler Approach. Proc. ACM Manag. Data, 1(3), nov 2023.

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,539评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,594评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,871评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,963评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,984评论 6 393
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,763评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,468评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,357评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,850评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,002评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,144评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,823评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,483评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,026评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,150评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,415评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,092评论 2 355

推荐阅读更多精彩内容