MTFM统一基座大模型：破解外卖多场景推荐与多目标优化难题
1. 外卖多业务场景的痛点：为什么必须有一个统一基座大模型
做推荐系统这些年，我一直觉得外卖推荐和电商推荐是两码事。电商用户打开APP，搜索场景、首页信息流、购物车推荐，本质上都是“货找人”，用户状态偏静态，决策周期相对从容。但外卖不一样，用户打开美团的时候，往往是带着明确的饥饿感和时间压力的。他可能前一秒还在首页刷奶茶推荐，下一秒因为午休时间紧张，直接去搜索“附近快餐”，然后在结算页为了凑满减疯狂找小食。这里至少涉及三个业务场景：首页Feed流、搜索排序、购物车搭配购。老一代的做法是每个场景各搞一套模型，看起来互不干扰，实际上问题一堆。
先说场景割裂带来的冷启动困境。首页Feed流模型对用户兴趣的判断，依赖的是用户过去14天的点击、下单序列。但这些序列在搜索场景里根本不适用，因为搜索用户有明确的query意图，需求词和菜品词必须做强耦合匹配。如果各场景独立训练，搜索模型只能从有限的点击日志里自己摸索“烤鸭”和“卤煮”之间的关系，样本利用率极低，新用户冷启动更是难上加难。我在社区里看到很多同行吐槽，外卖场景的冷启动比电商痛得多，原因就是时空约束：午高峰和夜宵完全是两类人群，晴天和雨天用户对配送时效的忍耐度也完全不同，这种强动态特征如果不统一建模，小模型根本学不过来。
另一个痛点在于多目标优化的内耗。外卖推荐的核心目标绝不是只有点击率或下单率。用户看到了不点，不行；点了不付，不行；付了后商家出餐慢导致骑手等餐超时，不行；最终配送超时给了差评，更不行。传统的做法是，每次业务方提出一个新约束，就单独驯一遍模型。比如同时优化点击率和GPM，就在模型上叠一个加分项，结果两个模型在线上分流A/B，每次都要花两周时间做小流量验证，如果指标冲突，还得人工看数据调权重。这种“单打独斗”的模式，在业务场景增加到一定程度后，维护成本会指数级上升，训练任务互相抢资源，评估代码越来越难读，最后不得不推到重来。
这也是MTFM这类统一推荐基座大模型出现的原因。它的核心思路不是把几个模型的代码合并，也不是简单的多任务学习共享embedding，而是把外卖多个业务场景的数据、特征、目标都放回同一个模型底座里训练。基座通过大量预训练数据学到通用的用户兴趣表达、商家行为规律和时空偏置模式，然后上层通过场景适配模块输出不同业务需要的排序结果。统一基座模型的价值在于，不同场景见到的数据不再孤立，新场景上线时可以直接继承基座已经学到的“行业常识”，冷启动成本大幅下降，在线指标也更容易跨场景对齐。说白了，基座模型要解决的是外卖推荐“既要又要还要”的工程难题。
2. MTFM拆解：多模态、多目标、多场景如何共用一个底座
2.1 MTFM的任务边界：比传统多任务模型多做了什么
MTFM全称可以理解为“美团体量平台统一推荐基座大模型”，它是一个面向外卖多个业务线的超大规模深度模型。传统多任务模型大多是“一个网络、多个输出头”，例如共享底层特征输入，上层分出CTR和CVR两个塔。这种做法在目标之间冲突不严重时还能用，但外卖多个场景之间的特征分布差距非常大，硬共享会让模型学出一个“四不像”的表征。MTFM采用了类似“主干网络+场景专家”的架构：底层是全场景共享的Transformer encoder，负责建模用户时序行为、时空上下文和商家状态；中间层是一组专家网络，每个专家对特定场景的特征交互负责；最上层才是真正的多目标输出头，分别输出点击概率、下单概率、叠加购买概率和配送履约概率。
这样做的好处是，基座大模型可以先在预处理阶段用自己的训练任务，比如用户行为序列预测和商家流量预测，学到极其通用的表征。等到具体业务场景想用这些能力时，只需要在顶层做少量场景适配，而不需要从头去刷几亿条日志。这一点实际落地中非常关键，因为外卖业务是“天级”甚至“小时级”变化的，你不可能因为某个城市突然下雨，就花两天时间重新训练一个专用模型，但基座可以通过在线侧的特征调整，快速响应天气和骑手端的压力变化。
2.2 时空动态特征怎么嵌进基座模型
外卖推荐模型里最特殊的部分，是时空动态特征。用户当前是否在上班、附近商圈拥堵程度、商家当前出餐压力、手边骑手的空闲运力，这些特征对排序结果的影响非常大。线下场景里这三个特征的变化是高度共线的：中午十二点，写字楼附近的商家出餐压力大，骑手运力紧张，用户又着急用餐。如果模型没有能力同时感知这三个信号，肯定会做出错误的推荐。
MTFM在处理特征时，并不像老模型那样把“小时”维度one-hot化处理一下就完事。它把时间戳、经纬度、商圈ID、兴趣点数据做成了连续embedding，通过一个独立的时间编码器（Time2Vec变体）和前馈网络，嵌入到底座模型。也就是说，晚间八点和夜间十二点，虽然在一个周期内是连续的时间值，但模型可以自适应学会它们对应完全不同的饮食兴趣分布，因为每个人时间偏好不同，没必要强设边界。此外，骑手运力特征被编码成商家周围一公里活跃运力的置信度向量。这一下就和业务场景打透了：如果一家店CTR很高但出餐慢且运力不足，模型会倾向于在首页往下沉一截，但在拼好饭这类特殊场景，又可以通过调整运力权重把这家店提上来。
2.3 多目标损失治理：CTR、CVR、配送履约怎么一起学
多目标学习里最大的坑是Loss量纲不一致。CTR的LogLoss通常在0.3~0.4这个量级，CVR的LogLoss可能在0.1~0.2，而配送履约预测加入后，如果直接做加权求和，模型会被大量纲的损失牵走。MTFM没有直接用简单加权，而是用了“动态权重”。它根据每个业务目标的实时梯度大小和置信区间，自适应调节每项目标在回传时的影响。这样做的好处是，训练过程中那个目标当前更难学，权重会自动加大，而不是某个目标从头到尾占据主导。
另一层治理手段是分场景的专家路由。虽然顶层是共享的，但对不同目标的Loss，模型允许不同场景选择不同的专家组合。举例来说，首页Feed流更看重点击率，因为它的流量成本高，用户注意力很珍贵；而购物车场景更看重客单价的叠加购买。MTFM让每个目标都有一个场景专家路由权重，从底层Transformer抽出的特征，经过不同专家的组合激活后，再送入目标头。这样一来，模型虽然是一个底座，但不同业务输出的质量都有保障。
还有一个细节容易忽略，就是多目标之间的业务约束。比如“用户点了某家店但配送超时”，实际上损失函数里不光要惩罚“没下单”，还要惩罚“下单后履约失败”。只优化点击和下单，不考虑履约，模型会倾向推荐出餐快但口味差的店，长期看用户LTV是下降的。MTFM在损失函数里引入了履约目标作为约束项，并在排序结果后置阶段会过滤掉明显出餐时间超阈值的商品组合。这个机制在传统单模型里几乎不可能实现，因为只有统一基座才有能力把“用户意图-商家状态-骑手运力”放在同一个特征空间里去评估。
3. 多业务场景落地实战：搜索、首页和购物车如何统一治理
3.1 场景适配：统一基座不是“一刀切”
统一基座模型不意味着全场景最终输出必须彻底相同。MTFM的落地原则是“底层共享、上层差异”。在实际工程中，我们把首页Feed、搜索排序、购物车推荐三条业务线分开做了适配层。底层基座已经在海量全场景数据上完成预训练，这部分是完全一致的推理框架。但在进入具体场景后，模型会推入一个“场景特征适配器”，它由两到三层MLP构成，参数规模只占整个模型的百分之几，却能完成最关键的特征极性翻转工作。
什么叫特征极性翻转？举一个具体例子：在首页场景，用户点击一个商家后停留时间短，通常被解释为兴趣低、要降低该商家权重。但在搜索场景，用户点击进去看到菜单后迅速退出，可能是因为菜单商品不全，或者库存不足，与搜索意图无关。这种现象在传统多任务模型中很难处理，因为共享的embedding会把“停留时长低”学成负向信号，用到搜索场景就会把一些本来优质但菜单表现不佳的商家错误降权。MTFM让每个场景的适配器自己学习这种“极性偏移”，搜索结果会根据query匹配度和商家折扣力度来调节压缩率。这个功能非常实用，是单独训练场景模型无法比拟的。
3.2 蒸馏与基座微调：大模型怎么落地到线上
大模型再好，物理瓶颈还是在那里：在线推荐链路不能接受动辄几十毫秒以上的排序延迟。我们外卖场景的推荐链路是分层的：召回阶段花50ms内，精排阶段预算紧一点也就200~300ms。如果直接把一个几百亿参数的Transformer跑到精排阶段，就算用A100扣下来，单趟也要几十毫秒，根本扛不住高QPS。所以MTFM的线上落地必须走“蒸馏+微调”两条路。
蒸馏是指把基座大模型先蒸馏到一个“学生模型”。学生模型往往只有几亿参数，保留了基座绝大部分的表征能力但推理速度能快一个量级。蒸馏时不只是蒸馏输出logits，更关键的是蒸馏中间层embedding。因为推荐场景的最终目标是排序，logits经过非线性后信息损耗很大，只有中间embedding才能保留用户行为的深层语义。实际操作中我们会在蒸馏阶段冻结部分底层参数，重点蒸馏场景专家网络，这样可以保留各场景的独立性。
微调则是针对已经在线上跑的学生模型，定期用全量新增日志做增量训练。基座模型和线上模型之间会有一个“滞后差”，因为基座一周训练一次，而线上每天都要更新。为了不让线上模型偏离基座太远，MTFM在微调时加入了一项正则化约束：线上模型更新后，其embedding的NRL2范数不能与基座最新版本差异过大。这个约束有效防止了线上模型在少数极端数据上过拟合，保住大部分蒸馏出来的优秀泛化能力。这套框架跑下来，模型迭代效率明显提升，过去一个场景三个月才能做完的模型升级，现在一个月就能完成。
3.3 购物车和更多垂直场景的快速接入
外卖场景远不止首页和搜索。购物车里的“再来一单”“湊单神器”，以及美团超市里的关联推荐，甚至到店业务，本质上都是推荐问题。如果每个场景都重复收集数据、单独训练模型，人力成本和时间成本都极高。MTFM的快速接入能力在这里体现得很明显。因为基座已经把用户、商家、时空、骑手等基础信号都做得足够好，新业务场景只需要提供一份“场景配置”，比如目标函数定义、约束条件、特征映射表，就可以复用基座的embedding和专家网络。
购物车场景的接入我印象最深。购物车场景的特点是用户意图极其明确，用户已经把菜品加入购物车了，接下来推荐的目标是搭配更多的小食、饮品或主食。这里面临的约束是：不能推荐和当前购物车品类完全重叠的商品，否则会分散用户决策，也不能推荐价格过高的商品导致支付总额超出预期。这个需求的本质是“约束优化”，如果从零训练一个模型很难把突发折扣和跨品类搭配学好，MTFM通过场景专家和条件化特征，直接实现了对购物车约束的建模。上线后购物车连带率涨了约5个点，相比以前单独优化联动模型提升明显。
除了购物车，外卖拼好饭这类低价场景也接到了基座。低价场景的特征分布和主场差异非常大，全是几块钱一份的简餐，用户对价格极其敏感，市场价格因素的权重必须上调。有了基座后，新场景的第一版模型不再需要从零做特征收集整理、用户画像圈选，直接继承基座权重，再通过场景适配器微调。我们的感受是，基座模型不只是算法层面的进步，更是基础设施层面的降本增效。
4. 工程链路优化：把大模型塞进高并发的饭点高峰
4.1 推理性能拆解：GPU、CPU和缓存怎么协同
饭点高峰期的QPS压力是很大的，特别是周末中午12点整点，首页Feed流排序请求会瞬间冲高。在这样的大流量下，如果精排模型是几亿甚至几十亿参数的神经网络，再叠加数百个特征工程的读取和预处理，CPU肯定撑不住。我们的做法是采用“GPU+CPU混合推理”架构，重头戏在特征embedding和Attention层。对于模型的第一层和第二层特征向量化，放在CPU上做，因为它们逻辑分支太重，但参数少；而Transformer block的重计算放在GPU上，因为矩阵乘法的并行效率高。
这里还要提一个重要优化：把用户特征加上短期行为序列做缓存预测。MTFM基座模型里有大量基于Attention的序列建模，在线推理时如果把每个用户的全部行为序列都实时喂给GPU，往往要等两次跨机房特征拉取，这会显著增加延迟。我们用一个叫“预计算缓存”的机制，把用户过去5分钟内的embedding变化增量缓存，只有发生新点击时才重新计算增量编码，降低重复推理开销。实测下来，线上平均排序耗时能控制在50ms以内，高峰期99分位耗时可以接受。
4.2 特征一致性与在线离线一致性
基座大模型上线过程中，我踩过最大的坑就是特征一致性。离线训练的时候，我们对用户行为和商家特征做了大量的填充、截断、归一化。但在线上推理时，由于部分特征在访问时的时效性不同，比如实时运力数据可能比离线训练时延迟几十秒，导致模型见到的特征分布完全不一致。这种偏差会导致“离线AUC涨、线上指标降”的经典问题。
MTFM在处理这个问题上花了很大功夫。首先，线上推理封装了一套统一的特征服务接口，所有特征都必须同步写到实时数仓一份，用于训练数据回流，从源头保证训练集和线上请求的log是同一条链路产生的。其次，模型对实时特征会加一个“时间衰减标识”，比如运力特征取的是当前时刻前5分钟的平均值，如果取不到就用上一轮缓存补，并打出marker，让模型学习到这些marker条件的表征。最后，在模型刚性评估期，我们会用“回放测试”，把上一小时的线上特征重新灌进模型，对比预测分布和线上实际结果。这些工程措施虽然琐碎，但缺一环模型都很难稳定。
4.3 降本增效：特征压缩与动态Batch
大模型不是免费的。MTFM基座全参数训练一次的成本和人力投入都很大，所以部署成本也必须精打细算。我们在线上模型侧做了两层压缩。第一层是特征列压缩：同一个商家的画像、动态指标、折扣力度合并成结构化特征组，按照周期批量更新到本地SSD和CPU内存，而不是每次推理都去拉取全量特征。第二层是模型结构压缩：把场景专家网络和输出头的参数量限制在一定范围内，只保留底层Transformer的精简版本部署到线上，用4bit量化来降低显存占用。
另一个有意思的技巧是动态Batch。外卖推荐场景的流量并不是均匀分布的，每小时的流量曲线差异很大。我们不再使用固定Batch大小，而是根据当前排队长度和GPU利用率，动态决定将多少个请求拼成一个Batch。高峰期请求量大，Batch稍微大一点，提升GPU吞吐率；低谷期减小Batch降低单次延迟。这套调度做下来，峰值时GPU利用率从65%提升到85%，单次推理成本下探了不少，省下来的算力正好用于支持更多新场景的接入测试。
5. 复盘与经验：基座大模型解决不了什么
虽然基座大模型MTFM在多个外卖业务场景的落地效果明显，但我也想说点和社区里很多“大模型万能论”不太一样的话。基座模型不是银弹，它不能解决所有问题，而且在某些方面反而会带来新麻烦。
第一个新麻烦是“长尾场景的过拟合”。因为基座是在全场景大样本数据上预训练的，理论上长尾场景的样本量远少于头部场景，模型为了压低整体损失，会偏向于把概率分布向热门商家压缩。具体现象是：美食里中低客单价的品类模型更新很灵活，但细分品类如轻食、地方菜往往推荐多样性会下降。这个问题模型层面很难直接解决，必须依靠业务规则或重复强化学习外部信号来把多样性拉回来。基座模型的统一表达能力越强，这种“确定性坍缩”的风险反而越大，需要持续监控。
第二个麻烦是损失函数的“内耗效应”。多目标统一建模后，如果不同目标在不同场景中的业务优先级没有绝对排序，训练会出现严重的震荡。比如外卖场景里点击率目标和履约率目标经常冲突，遇到暴雨天用户的点击欲望和履约能力都下降，两个目标的梯度方向相反，模型一轮下来的embedding会被拉扯得不成样子。我们在遇到极端天气时，不得不临时将履约目标的权重调低，这在传统单场景模型里是可以直接配置的，但基座模型由于全局共享，这种权重调整会影响其他所有场景。你需要自己设计一套“场景分割+目标冻结”的机制，过程比预想复杂得多。
第三个麻烦是冷启动，特别是新商家冷启动。基座大模型记忆和泛化能力都很强，但对完全没出现过的新商家，它依然会倾向给一个全局平均值的初始分，不会像真人运营那样看一眼新店的菜单、价格、评价就给出直觉判断。我们尝试将商家上传的菜单文本和招牌菜视觉特征注入基座，所谓“图文冷启动”，但效果提升有限，因为外卖用户对“新商家”的信任度本身偏低，光靠模型联想还不够。这块还有很长的路可以走，比如把社区评价和商家历史经营数据加入多模态序列，或者用更细粒度的迁移学习补齐新商铺的偏好空间。
最后聊一下工程上的组织协作。基座大模型大多是中心化团队训练，场景团队负责调参和上线，这种组织模型在沟通成本上必然会带来损耗。场景团队会觉得“基座是黑盒，我们不知道怎么调”，中心团队又觉得“场景团队总是提些不符合底层逻辑的需求”。要解决这个问题，我们要求每个场景必须配备一个“基座模型接口人”，负责把场景需求转化成模型可实现的配置，并且定期共享场景评测数据给中心团队，形成闭环。这个看似是管理问题，其实直接决定了基座模型迭代的ROI，比任何一个算法模块都重要。
MTFM这套基座模型的实践还在持续推进。从最初的电商推荐底座，到覆盖外卖多业务场景的若干次模型迭代，过程中有很多环节都值得复盘和优化。如果你所在团队也正打算从多模型治理转向统一基座建模，我的建议是别急着冲参数规模，先把你们场景中最痛的三五个业务指标找出来，再用统一的Container表示层去整合特征，基座模型的能力，最后都取决于你能不能把业务经验真正写进它的骨子里。