★ FEATURED ARTICLE 2026年10月2日我在常刷的论文摘要流里看到两篇大厂工作位置恰好挨在一起。一篇来自抖音的广告算法团队标题里写着“端到端生成广告召回”另一篇来自Meta的基础设施团队核心结论是把大规模训练的有效时间推到了90%以上。两篇文章一个在讲算法怎么做得更“整”一个在讲算力怎么用得更“狠”。把它们放在一起读我发现这才是工业界最近最真实的两种焦虑模型想越做越端到端系统想越跑越高效。这篇文章会把两篇论文的核心思路、关键设计和落地思考展开讲讲适合搜广推算法、大模型训练、MLOps的人参考也适合想理解“端到端”和“训练有效时间”这两个词到底在说什么的人。1. 端到端生成广告召回把“漏斗”压成“一条道”1.1 传统广告召回的痛点漏斗越长信息丢得越多在搜广推系统里广告召回通常是一个典型的级联漏斗从千万甚至上亿的广告候选里先用双塔、向量检索、树模型这些轻量手段捞出几百到几千个再交给精排模型打分最后经过重排、频控、竞价上屏。这套架构打磨了很多年工程上非常成熟但它有一个结构性的问题每一层都在按自己的目标优化召回的“相关性”和精排的“转化收益”并不是一回事。我给你打个比方这就像一个大公司招人HR先用关键词筛简历筛完再让业务面试官去面。HR筛掉的人面试官永远看不到。如果HR偏向“学历名校”而业务其实更看重“实操经验”那即使后面面试维度再合理前面已经把优秀候选漏掉了。广告系统也一样召回阶段往往用粗粒度的语义相关性或点击信号但广告真正要优化的是GMV、订单量、甚至广告主ROI中间信号错配导致的信息损失是上一级模型无法弥补的。更麻烦的是广告场景还有预算、频控、出价、多样性等约束。一个广告即使和用户很相关如果广告主预算已经快花完或者这个用户已经看过太多次它就不应该被召出。但这些约束在传统级联里通常是在召回之后才被考虑导致召回层“辛辛苦苦捞上来的候选在后续被大量过滤”。端到端生成广告召回就是想把这套漏斗尽量压成一个整体让“候选生成”直接面对最上层的业务目标而不是中间的人工取舍。说实话“端到端”这个词在推荐系统里喊了好几年但真正在广告这种规模落地并不容易。难点在于广告候选规模大、更新快本身还带实时出价信息强行端到端容易让模型变得又大又慢。今年这版工作能够出现我觉得核心条件已经有了一是生成式模型能处理超大词表二是工业级推理引擎总算力跟得上了。1.2 生成式召回的思路让模型直接“生成”候选端到端生成广告召回的具体思想可以这么理解把“召回候选”从“检索任务”重新定义成“生成任务”。模型输入是用户行为序列、上下文特征、广告主特征输出不是某一个相关性分数而是直接生成一组广告的标识序列比如广告ID的token list。这一组token对应的是模型认为在当前用户和场景下最值得展示的广告集合。我理解它的结构大致包括三块第一块是编码器负责把用户和上下文压缩成向量第二块是decoder以自回归或非自回归的方式逐步生成候选广告ID第三块是目标函数不再只用曝光或点击作为监督而是把下游精排、竞价、甚至最终转化纳入训练目标。为了让生成过程符合广告投放的约束常见做法是给生成动作加上预算消耗、频控限制等软性惩罚项或者通过采样weight来影响生成结果分布。与常规生成式推荐不同广告的场景里“候选”本身不是单纯的个人喜好问题而是多方博弈的结果。同一个用户在不同广告主的出价、创意质量、投放时段下最优曝光集合是不同的。所以生成式召回不能只“凭感觉”生成“像用户喜欢的广告”还要在生成过程中考虑广告主的实际投放条件。抖音这版工作我读下来的印象是在一个统一的模型结构里把用户侧、广告侧和投放约束一起做序列化建模再靠可控生成来同时满足相关性和商业目标。这里有一个很值得琢磨的细节生成式召回比传统双塔召回更能保留“条件依赖”。双塔模型通常把用户和广告各自编码成独立的向量最后做内积这种结构本质上假设了“用户偏好”和“广告属性”是各自独立的表示。而生成模型在解码每个广告token时会依赖前面已经生成的token也就是能建模“这些广告放在一起是否合适”的集合关系。这在广告多样性、上下文互补性上天然更有优势。代价是推理成本更高这也是它之前在工业界一直没大规模用的原因之一。1.3 为什么之前不火现在才成熟几年前就有人用seq2seq做过item召回效果并不算惊艳。当时主要问题有三个第一item ID是随机的模型很难学到ID背后的语义第二生成式模型的候选集是开放式的容易出现“凭空编造”一个不存在的广告ID第三线上推理要实时生成延迟预算根本不够。现在这三个阻碍都在被慢慢拆掉。ID问题靠语义token化解决把广告ID映射到多模态语义空间或者用内容特征聚类出离散码本让模型生成的是“可泛化的广告概念”。不存在ID的问题靠约束解码解决在beam search的时候只从当前可用的广告集合里选相当于给生成过程加了一层业务过滤。推理延迟问题靠蒸馏和异步预生成解决线上用一个小模型在召回阶段生成候选离线用大模型蒸馏指导。而且广告系统本身对召回通道的延迟要求通常是几十毫秒级只要把生成式召回作为其中一个通道与其他快通道并行整体命中率就会提升不至于让系统“等死”。还有一个背景是算力。生成式召回的训练需要很大的batch和较长的序列长度动辄需要成百上千卡跑很久。而这正好和Meta那篇讲“训练有效时间”的工作对应上——如果训练集群里GPU有一半时间在空转这种模型根本跑不起来。所以两篇论文放一起看其实是一条产业链上的链条。2. Meta把训练有效时间推到90%向“空转”要算力2.1 训练有效时间为什么被浪费先解释“训练有效时间”这个词。它指的是在整个训练任务挂机期间GPU真正用于前向和后向计算的时间占比。假如一块卡挂了100小时其中80小时在算10小时在等数据5小时在存checkpoint5小时在故障重启那有效时间就是80%。这里的“有效”是相对于“能用但没在算”的时间。为什么有效时间普遍到不了很高我这些年实际踩下来主要损耗来自四个地方。第一是同步等待分布式训练里每个step都要等所有卡把梯度算完才能allreduce只要有一张卡慢了整批都得等它。第二是数据加载训练集太大IO带宽不够或者预处理没跟上GPU经常是“等菜下锅”。第三是checkpoint保存大模型动不动几百GB如果同步落盘一个checkpoint可能卡住几十秒。第四是故障恢复任何一个节点挂了AllReduce的环就断了可能要等调度器重新拉起、重新加载权重运气差的话几小时就没了。这些损耗在小型实验里不明显但在万卡规模上会被放大得非常吓人。1000张卡等1秒就是1000卡秒白白烧掉。Meta这次能把有效时间推到90%以上意味着他们把“花在非计算上的时间”压缩到了一个很低的水平。别小看这百分之十几的提升在万卡集群上这相当于白捡了几千张卡的算力。2.2 把有效时间推上去的几个抓手我没有拿到论文的完整细节但按照我对大规模训练基础设施的理解能到90%以上一定不是靠某一招而是把下面几件事都做到了位。第一是弹性调度和故障自愈。训练任务被打断后以前是人肉建ticket找值班同学恢复现在常见做法是让训练框架定期上报心跳和step进度调度器一旦发现某个节点心跳超时或者progress卡住就自动把任务迁移到备用节点并从最近的checkpoint续跑。这个“自动续跑”非常关键它解决了分布式训练最伤的“坏点导致整体停摆”问题。第二是计算通信重叠的大幅优化。在千亿参数模型里每次allreduce的通信量是GB级别。如果把通信、梯度计算、数据加载安排在同一个时间流水线上让计算和通信互相掩盖而不是“先算完再通信”整体的step时间能缩短15%到30%。这个优化需要深入框架层比如在CPU侧prefetch并预处理下一个batch同时在GPU侧做通信重排。第三是checkpoint的异步化。现在很多训练框架支持在训练时直接提内存副本再由另一个线程或进程异步写入分布式文件系统训练主线程不用等磁盘写完成。再配合增量checkpoint只保存优化器状态的变化量可以大幅减少保存耗时。第四是慢节点的动态降级。训练集群里总会出现“比平均水平慢半拍”的卡可能是散热降频可能是网络拥塞。较新的调度器会动态识别这类慢节点把它们从主训练组中摘除用备用节点替换避免它们拖慢所有人。这一项看着不大但往往能把尾部延迟降一个量级。以上这些方向的光环都不在模型身上而在系统细节里。某种程度上比模型还难做因为它需要把调度、网络、存储、训练框架全部打通任何一层出问题都会拉低最终的有效时间。2.3 有了90%以后能带来什么最直接的价值是算力成本下降。可以用简单模型算一下假设你有1万张GPU单卡每小时成本按某些云的报价大概是1.5美元粗略估算每提高10%的有效时间每天多出的有效卡时是10000乘24乘10%也就是24000卡时相当于每天省3.6万美元一年就是上千万美元。即便不按云报价而是按自建折旧算这个量级的优化也足够说服管理层。Meta自己训练超大模型时往往一跑就是几个月有效时间每提升一点省下的都是一个天文数字。第二个价值是迭代效率。有效时间90%意味着所有研究员排队等实验的时间缩短了每天能跑完的实验数量变多。原来一周才能验证的想法现在可能四天就出结果。这在大模型快速迭代的窗口期里比钱更值钱。第三个价值是降低了超大集群训练的风险。训练跑得越快被故障打断导致前功尽弃的概率就越小自动续跑机制又进一步把“长时间稳定训练”变成一件可以预期的事。我记得几年前常有团队因为一次节点故障重启导致整个训练任务晚几天上线这种“纯运气”的环节被系统干掉后整个团队的排期都能更稳。3. 端到端与训练效率的化学反应算法系统一起看3.1 生成式召回训练“吃算力”系统优化正好补位两篇论文放在一起我觉得最值得玩味的是它们刚好互补。端到端生成广告召回训练阶段要灌入海量用户行为序列和广告特征序列长度和batch size都很大这种模型比传统双塔起码贵几倍。如果没有高有效时间的训练集群算法团队可能很难支撑起反复的实验调参。Meta这种基础设施优化本质上是在给所有“烧算力”的新算法松绑。反过来说端到端模型对训练稳定性更敏感。它不像双塔那样“容错度高”几步没收敛可能整个embedding空间都乱了。如果训练过程中频繁被慢节点、checkpoint阻塞打断模型观察到的数据分布可能出现偏差导致收敛异常。所以系统端越稳定算法端才越敢放开手脚尝试真正的端到端。这个互补关系让我想到软件工程里的一句话抽象只能建立在可靠的底层之上。算法研究总是默认底层算力是免费的、稳定的、永不失败的但工业界知道这从来不是事实。Meta这次把底层可靠性和有效时间做实其实是给上层的端到端应用打了个更牢的地基。3.2 从广告端到端到智驾端到端同一股技术思潮最近在技术社区也刷到很多“智驾端到端技术”的内容比如CSDN上那批讲自动驾驶大模型的长文。自动驾驶领域说的端到端是把感知、预测、规划、控制合到一张网络里输入传感器数据直接输出方向盘和油门刹车。表面上跟广告召回风马牛不相及但底层逻辑是一样的减少多阶段级联中的人工接口和信号丢失让目标函数跨过中间环节直接传导到最终决策。广告端到端是把召回、精排的边界模糊掉用生成模型直接输出候选让商业目标影响候选生成智驾端到端是把感知规则、规划逻辑熔进一个模型让“到达目的地”的最终目标约束每一个中间表示。两种场景下中间模块退化成可学习的隐变量而不是人工设计的固定接口。这可以说是AI系统设计的一种范式迁移从“分而治之”到“全局优化”。当然端到端不是银弹。广告里它面临可控性差的问题智驾里它面临可解释性差、安全验证难的问题。所以工业界通常不会一步到位而是先让端到端模块跟传统模块并行逐步增加它的决策权重。我觉得未来很长一段时间会是“端到端主路径加规则约束兜底”的混合形态而不是彻底推翻旧系统。3.3 未来可能的形态生成式全链路与效能折中往远了想广告系统是不是能走到“生成式全链路”不只在召回阶段生成候选而是在排序阶段生成广告创意在重排阶段生成广告序列甚至整条广告页面都由一个模型生成。这个趋势现在已经有了苗头比如AIGC已经可以生成广告素材那下一步完全有可能把素材生成和排序一起优化直接用转化目标引导素材的生成。但这里要泼一盆冷水全链路生成的训练成本和推理成本都很高而且不好调。做工程的人都知道越大的端到端模型越像一个黑盒你很难定位是哪个环节出了问题。在真实广告系统里客户会追着问“为什么一个广告投不出去”如果模型给不出理由就很难与客户建立信任。所以未来的生成式全链路一定要在关键节点上保持可插拔的诊断能力不能为了端到端而端到端。Meta那个90%有效时间的意义其实也在这里只有把系统效率抠得足够高才有多余的算力去支持这种更烧钱的探索。算法理想需要系统现实来买单这是我今年看各类大厂技术分享最强烈的一个感受。4. 工业落地视角避坑清单与量化参考4.1 想把生成式召回接到线上先解决四个问题读完论文是第一步落地是另一回事。如果你所在的团队也想尝试端到端生成广告召回我会建议先解决下面四个问题否则大概率上线翻车。第一离线评估metric要想清楚。生成式召回产出的是“一组广告”不是“一组分数”。只看召回率、AUC是不够的要定义“生成集合”的整体质量比如集合的多样性、覆盖的广告主数量、与线上精排结果的吻合度。更稳妥的做法是直接离线模拟“召回到精排再到重排”的全链路对比端到端召回和旧召回的最终业务指标。第二延迟预算和算力分配。生成式召回通常比双塔慢一个量级你需要决定把它做成“同步主召回”还是“异步候选通道”。我见过不少团队直接拿大模型上召回结果RT从10ms飙到80ms广告超时被系统丢弃。比较务实的是先跑一个蒸馏后的小模型线上只做一个很浅的beam search把候选控制在二三十个保证延迟预算不破。第三候选的有效性约束。生成模型可能输出不存在的广告ID哪怕是万分之一的概率在千万级QPS下也是严重事故。必须在解码时绑定一个“可投放广告集合”像在星空中只能用已知星星拼星座。同时还要做曝光频控和广告主预算的实时过滤否则模型生成的候选有一半根本不能投。第四与旧系统的闭环评估。不要一开始就让生成式召回取代传统召回最好作为一个独立召回通道和双塔、向量召回并行最后在融合层看收益。这样做的好处是风险可控、回滚方便。等AB实验确认收益长期为正再逐步提高它的召回占比。4.2 训练有效时间的度量与优化顺序对于训练侧如果老板让你去提升集群有效时间第一步不是盲目优化而是把它度量出来。你可以在训练代码里给每个step埋几个时间戳数据加载耗时、前向耗时、后向耗时、通信耗时、checkpoint耗时、空转耗时。用这些数据画一张“step时间瀑布图”一眼就能看出时间花在了哪里。我给一个参考的排查顺序。第一优先处理数据加载是不是没有开足够多的dataloader worker是不是文件分布不均衡把IO打满以后通常能拿回5%到10%的有效时间。第二是checkpoint落盘从同步保存改成异步保存或者减少保存频率这里通常又能挤出几个点。第三是故障恢复自动化即便有备用节点也要检查一下拉起一个新节点、重新建立分布式通信的端到端耗时把这部分做成自动操作。最后才是通信overlap、调度优先级这些更精细的活。我见过最有效的方案是在大规模集群里引入“进度心跳”机制训练框架每30秒上报当前step号和loss调度中心如果发现某个任务已经超过3分钟没有前进会自动触发排查、重启或迁移。这个机制不复杂但对“有效时间”的提升极其明显因为它是唯一能同时捕获数据卡死、网络故障、节点假死的统一手段。4.3 一张表算清“有效时间”的账为了让大家对收益有更直观的感受我列一个粗略的估算表。假设一个训练集群有1万张GPU单卡每小时综合成本按1.5美元计算连续跑30天看不同有效时间下的浪费情况有效时间30天浪费的GPU时数浪费成本美元70%2,160,0003,240,00080%1,440,0002,160,00090%720,0001,080,000这个表的计算其实很简单总GPU时数是10000乘24乘30即7,200,000。有效时间70%意味着有30%的时间在空转浪费2,160,000卡时乘1.5就是324万美元。从70%提升到90%相当于省下来2,160,000卡时、216万美元。这个数量级还没有算上故障后人工介入的时间如果把工程人员的工时也算进去收益会更高。至于单卡成本云厂商和自建机房差异很大但1.5美元这个量级在目前的主流加速卡里基本靠谱你可以按自己的成本模型替换。4.4 最后说点团队协作的私货我想说的是算法和基础设施团队很多时候是两条线算法怪算力不够系统怪算法不懂调度。我个人的经验是两拨人应该定期坐在一起把“有效时间”和“模型效果”放进同一个复盘报告。算法团队要知道自己提交的任务到底占用多少计算成本系统团队也要理解模型为什么需要那么大的batch、那么长的序列。只有这样“算法层更准”和“系统层更高效”才能真正形成一个正循环。我现在看一个训练平台第一反应就是问它的有效时间是多少面试候选人也会问他在一次长训里遇到过哪些导致GPU空转的事故。因为这个指标背后藏着一个团队对工程细节的敬畏程度。端到端生成广告召回也好训练有效时间90%也好想表达的其实是同一件事在工业界把一件事做得“整”和做得“稳”从来都是一枚硬币的两面。
阅读完成 · 觉得有帮助？
