1
MTGR：美团外卖下一代生成式推荐模型落地实践
核心本地商业/业务研发平台/搜索和推荐平台部
韩瑞东
2025年7月
2
• 背景：为什么要做生成式推荐
• MTGR：美团生成式推荐落地实践
• MTGRBoost：训推引擎建设
• 总结与展望：未来工作
Outlin
e
3
背景：为什么要做生成式推荐
4
大模型Scaling
Law
• 2 0 2 0年OpenAI首次系统性提出Scaling Law的概念——模型性能随着模型规模、数据量和计算资源的增加而提升，
且遵循一定的数学规律。
• 从G P T开始，旗舰L L M计算复杂度以及参数量快速上升，先后出现了 4 0 5 B、DeepSeek-R1 6 7 1 B等大尺
寸模型。
Kaplan,Jared,etal."Scalinglawsforneurallanguagemodels."arXivpreprintarXiv:(2020).
5
美团外卖DLRM Scaling历
史
…… ……
Multi-Query Projection Key & Values Projection
……
Query Projection
……
Fusion Layer
MoE Layer MoE Layer
……
Multi-task prediction
User behavior sequenceContext User profile Target item
Multi-Head Attention
……
Multi-Head Attention
……
…… ……
Key & Values Projection Query Projection
Multi-Head Attention
……
Concat
……
Multi-task prediction
User behavior sequenceContext User profile Target item
MoE
Scaling module
a. Scaling cross module b. Scaling user module
优点：user x item建模充分
缺点：训练、推理开销难以优化
优点：推理可以进行成本分摊
缺点：user only，user x item建模不充分
2018～2022 2023
Scaling module
推荐系统中Scaling Law——历史发展与困
境
6
• 注意力机制与推荐系统：
• 引入注意力历史悠久：从2 0 1 7年开始，推荐系统领域就开始尝试引入注意力机制，包括 S A S R ec、D IN等，
至今采用 浅层注意力研究超长序列建模仍然是推荐系统重要的研究方向。
• 工业实际使用与L L M发展存在巨大gap：工业界至今仍然罕有业务使用超深注意力机制部署线上服务。
• 核心挑战：
• 推荐模型训练的token数以及词表空间都远大于L L M（亿级别用户 x 万级别用户序列 x 数百天训练样本= 10 1 4
vs 10 1 2 tokens）
• 线上推理延迟限制严格（~30ms）
低成本、高效率的训练和推理面临巨大的算法与工程挑战。
推荐系统中Scaling Law——历史发展与困
境
7
• 落后于LLM发展深层次原因：
• 基建历史包袱重：推荐系统从进入深度学习时代开始，已经使用了近1 0年的Tensorflow生态，大部分团队还是基于
TF1，对于Attention计算的支持远落后于开源Torch生态。
• 算法认知螺旋上升：不同于LLM 简洁的decoder-only架构，推荐模型往往包含多个模块，S caling哪一部分，怎么
Scaling等核心问题在很长一段时间没有共识。
• 算法与工程的co-design处于原始阶段：LLM 领域中，如何极致的压榨G P U性能是算法设计必须考虑的重要因素（如
DeepSeek M L A、NSA），而搜推领域基本没有起步。
推荐系统中Scaling Law——
HSTU
• HSTU(Hierarchical Sequential Transduction Units)：首次在业务上落地了生成式推荐系统
（Generative Recommenders, GR）大模型，对整个建模方式、任务定义进行了大幅度的修改，极
具颠覆性，是业界争相复现落地的重点。
• 数据组织：所有输入特征组织成序列的形式。
• 任务定义：所有任务（召回&排序）都嵌入到这个序列生成模型中。
• 模型结构：模型主体采用Transformer，将长序列输入Transformer中进行信息交互。
8
Zhai,Jiaqi,etal."Actionsspeaklouderthanwords:Trillion-parametersequentialtransducersforgenerativerecommendations."arXivpreprintarXiv:(2024).
推荐系统中Scaling Law——
HSTU
• HSTU：该方案在Meta已经落地到实际场景中，取得了比原来的推荐系统模式更优的效果。
• G R在离线指标和在线A B实验中，都优于DLRM模型。
• G R展现出良好的Scaling Law的性质，找到了一条模型效果优化的可持续发展路径。
9
Zhai,Jiaqi,etal."Actionsspeaklouderthanwords:Trillion-parametersequentialtransducersforgenerativerecommendations."arXivpreprintarXiv:(2024).
DLRM vs
GR
• 在有限的资源下，传统推荐模型（D LR M ）不能高效处理全量用户行为，需要通过序列检索、特征工程等
方式对重要信息进行提取加工，限制了模型效果的上限。
• 对比D L R M，G R可有效提升推荐模型的训练及推理效率，提升模型scaling的规模上限。
DLRM（Deep Learning Recommender Model） GR（Generative Recommendation）
数据
组织
模型
范式
• 模型结构重Cross module；
• 一次曝光对应一条样本，同一用户多次曝光的用户信息被重
复计算，浪费计算资源；
• 大流量业务需要负采样降低训练成本。
• 模型结构重User module；
• 一次曝光作为一个Token，同一用户多次曝光被压缩成一条单独的样本，用户信息只
计算一次；
• 无需负采样，全部数据训练的额外开销几乎可忽略。
推理
范式
• 由于不同服务、请求下要预估的目标不同，较大的Cross
module导致整个网络几乎要被重算，可复用性差。
• 每个候选独立计算Cross module，User module计算共享，支持更大规模的模型。
• 可利用K V Cache技术在跨请求情形下减少Attention的计算开销，进一步提升吞吐。
10
11
MTGR：美团生成式推荐落地实践
MTGR-核心问
题
• 通过Causal Mask建模完整的用户行为链？
• M e t a G R的落地场景为沉浸式视频流Reels，Causal M a s k建模符合业务展现形式，但不一定适合单列业务。
• 完整行为链在电商业务中噪声较多，往往需要更多的Token进行建模。
• 删除了全部交叉特征？
• M e t a G R认为交叉特征全部隐含在序列信息中，通过scale up可以弥补丢失交叉信息带来的信息损失。然而对于L B S业
务，删除交叉特征效果损失巨大，在我们的实验中需要Scaling百倍算力才可弥补。
• 落地核心挑战：
• 尽量保持D L R M 现有特征体系，在训推成本约束的前提下利用G R 获取Scaling Law收益。
MTGR
12
MTGR-数据组
织
User A
User B
Context &
User profile
User behavior sequence Target item
Context &
User profile
User behavior sequence Target item
包含时间戳作为sideinfo用于生成掩码避免穿越
User A
User B
包含时间戳作为sideinfo用于生成掩码避免穿越
Context &
User profile User behavior sequence Target item
DLRM
13
Han,Ruidong,etal."MTGR:Industrial-ScaleGenerativeRecommendationFrameworkinMeituan."arXivpreprintarXiv:(2025).
MTGR
• 按用户聚合，同时取消负采样 & 长序列检
索
MTGR-模型结
构
• 模型结构整体上参考H S T U的实现，在序列构成和多目标预估上做了改动：
• 序列构成：序列由多种不同类别的Token构成——user_profile, lifelong_seq, rt_seq, pv_items。每种Token类别包
含多个特征，同一类别具有相同的特征空间。
• HSTU计算：输入序列经过Embedding层后，进入到N个H S T U block进行Attention计算。为了避免实时序列和曝光
items出现特征穿越，需要根据时间戳自定义mask矩阵。
• 多目标预估：通过M M o E 进行多任务学习。
14
Han,Ruidong,etal."MTGR:Industrial-ScaleGenerativeRecommendationFrameworkinMeituan."arXivpreprintarXiv:(2025).
MTGR-模型结
构• Group LayerNorm：不同与L L M， M T G R包含了多种不同类型的Token，通过Group L N保证
不同空间Token可以高效对齐。
• Dynamic Mask：不同与Causal Mask，对于静态特征我们采用双向注意力编码提升编码效果，
同时对于实时侧，动态演码机制可以避免信息泄漏，具体规则包括：
• 静态特征对所有特征可见
• 动态特征满足因果性，每一个特征只能被他后面的特征看到，包括预估候选
• 预估候选只能看到自己
15
Han,Ruidong,etal."MTGR:Industrial-ScaleGenerativeRecommendationFrameworkinMeituan."arXivpreprintarXiv:(2025).
MTGR-离在线效
果
Embedding dim被设置为��표e�l /【푇표�ne 中特征数】附近的值
16
Han,Ruidong,etal."MTGR:Industrial-ScaleGenerativeRecommendationFrameworkinMeituan."arXivpreprintarXiv:(2025).
MTGR-离在线效
果
• 离线实验在宽度、深度、Token长度多方面观察到近似对数线性的Scaling Law。
• 在线A B设置small、m e d i u m、large三个不同尺寸模型，训练超过半年，离在线均取得收益。
• MTGR-large在首页推荐场景全量部署，取得近年来迭代最大收益，训练成本持平，推理成本下降4 4 %。
17
Han,Ruidong,etal."MTGR:Industrial-ScaleGenerativeRecommendationFrameworkinMeituan."arXivpreprintarXiv:(2025).
18
MTGRBoost：训推引擎建设
19
MTGRBoost总体介
绍
Wang,Yuxiang,etal."MTGRBoost:BoostingLarge-scaleGenerativeRecommendationModelsinMeituan."arXivpreprintarXiv:(2025).
• GR模型训练和推理面临严峻挑战：
• 训练数据和稠密网络参数规模scale导致离线训练计算量激增：按照Scaling Law的指导，模型效果的提升来自训练数
据量和模型参数量的增加，带来训练计算量的大幅增加。
• 稀疏Embedding规模scale导致离线训练存储规模激增：新模型范式引入更多的样本和特征，导致Em bedding数据
量大幅膨胀，给Embedding的分布式存储和通信带来严峻的性能挑战。
• 在线推理模型规模和计算量伴随模型scale激增：模型大小和计算量膨胀显著，需要更强算力、更大显存的G P U加速卡，
或者考虑CP U - G P U联合推理的异构计算模式。
• 解决思路：
• 建设了G R模型训推引擎——MTGRBoost，解决模型计算量和存储量激增带来的诸多性能挑战。包含两个核心组件：
• MTGR-Training：支持低成本、高效率大规模分布式训练
• MTGR-Inference：支持低延迟、高吞吐大规模线上推理部署
MTGR-
Training
• 基于TorchR ec，我们构建了简单易用、高性能、可扩展的G R模型训练引擎M TG R -Training，可支持千
亿参数、100GFLOP/example甚至更大计算量的模型的高效分布式训练。
MTGR-Training
H ashtable
TorchRec
梯度累积 通信优化
Sparse并行 Sparse压缩 Pipeline并行
数据读取 训练评估 断点续训
Sparse合表 负载均衡 Warm-start
模型并行
FSDP
Megatron
自建
开源
离在线
一致性校验
监控报警
算法模型1
20
算法模型2 算法模型3 算法模型N
MTGR-Training优化总
结
21
类别 优化项 方案概述 收益
功能
支持
动态Hashtable 给torchrec集成了一个高性能的Hashtable，实现了
forward、backward、optimizer全流程相关op
无需提前指定embedding表的容量，无
需提前对sparse ID做映射，使用更方便；
相比torchrec的dynamic_embedding
插件，端到端训练吞吐提升1 0 %
梯度累积
对于sparse部分，通过稀疏聚合的方式高效实现梯度
累积；对于dense部分，复用torch的方案
支持梯度累积功能，引入的额外开销很小
性能
优化
自动合表
设计实现了一套稀疏原语API，用户仅需定义特征的关
键属性，即可自动生成模型的sparse部分，并且对多
个稀疏表进行自动合并
开启自动合表，端到端训练吞吐提升8 %
混合精度训练 训练时将模型dense部分从FP32转为BF16进行计算 对G E M M 密集的结构收益显著
Kernel优化
对关键子结构（例如HSTU）进行定制的Kernel优化，
主要是通过fusion提升计算效率
使用优化的H S T U kernel，端到端训练吞
吐提升8 5 %
ID unique
输入的sparse ID先去重再进行All2All通信，降低通信
数据量
端到端训练吞吐提升4 5 %（ 3 2卡）
变长序列负载均衡
通过动态batch_size策略平衡每张卡的计算负载，避免
通信等待
端到端训练吞吐提升3 0 %
GAUC计算优化
将Group ID计算逻辑前置到数据读取进程中，降低训
练进程的C P U 负载
端到端训练吞吐提升1 0 %
MTGR-Training优化——HSTU kernel优
化
• 通过集成Nvidia提供的深度优化的Cutlass-based HSTU kernel，支持变长序列的输入无需padding，
大幅提升了Attention的计算效率，单算子性能相较于Triton版本提升2~3倍。
Fused Cutlass-based
H S T U kernel
Padding-free
batch input
1 2 3 4 5 6 7
1 2 3
1 2
1 2 3 4
22
23
MTGR-Training优化——变长序列负载均
衡
• 固定batch_size(BS)会带来负载不均的问题：
• 推荐系统中用户序列呈现明显的长尾分布：少数用户的序列很长，大部分用户的序列都比较短。
• 固定B S训练：每张卡拿到的用户数相同，但由于序列长度不同实际的计算量差别较大。
• 木桶效应：每个step都要等负载最重的卡计算完，所有卡才能进行梯度同步。
• 解决思路：
• 引入动态BS，每张卡的BS根据实际数据的序列长度动态调整，保证计算量（total_tokens）基本相同；
• 修改梯度聚合策略，按照B S对每张卡的梯度进行加权，保证计算逻辑的一致性。
1 2 3 4 5 6 7
1 2 3
1 2
1 2 3 4
total_token_num=16,
underload
1 2 3 4 5 6
1 2 3 4 5 6 7 8
total_token_num=26, full load
固定B S=4
动态BS
1 2 3 4 5 6 7
1 2 3 4 5
1 2 3 4
1 2 3 4 5 6
1 2 3 4
BS=5, total_token_num=26, full load
1 2 3 4 5 6 7 8
1 2 3 4 5 6
1 2 3 4 5 6 7 1 2 3 4 5
1 2 3 4 5 1 2 3 4 5 6 7
BS=4, total_token_num=26, full load
G PU -0
G PU -1
24
MTGR-
Inference
• 基于Nvidia软件生态，我们构建了高性能的G R模型推理引擎MTGR-Inference：
• 选择TensorRT作为模型推理框架：TensorR T是N vidia推出的推理优化框架，在业界广泛应用，具有较强的算子融
合、低精度量化能力。
• 选择Triton Inference Server作为模型部署框架：Triton Inference Server是Nvidia推出的高性能模型部署框架，
在业界广泛应用，是TensorRT官方推荐的模型部署方案。
Nvidia G P U
TensorR T
FP16计算 User Cache
特征H 2D
优化
C U D A
G raph优化
H S T U
算子融合
Hashtable
Triton Inference Server模型部署框架
推理优化手段
模型推理框架
加速硬件适配
已完成
建设中
25
总结与展望：未来工作
总结与展望
26
• 总结：
• 为了支持G R模型在美团实际业务中应用落地，我们提出了M T G R以及对应的模型训推引擎MTGRBoost，以较低的成
本支持了对于D L R M base达6 5倍甚至更大规模计算量的G R模型的训练、推理，实际业务的线上A B 实验也取得了一定
的效果收益，为下一代搜推广模型的迭代打开了算力天花板。
• 未来主要工作：
• 利用M T G R高效的推理性能，改变上下游漏斗迭代范式。
• 利用M T G R异构建模特点，建立跨业务Foundation model。
更多技术干货
欢迎关注“美团技术团队”
邮 箱 ：
hanruidong@
27
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
mailto:hanruidong@
28
Q&A
