Meituan Tech | 美团技术团队修改

算法工程师的一天是“改代码—提交训练—等待—看日志—决定下一步”，过程中还经常被打断。我们团队从 Karpathy 的 AutoResearch 出发，经过三次架构重构，搭建出一套可在企业云端训练平台使用的算法研究自进化系统：系统从单线程 LOOP 探索升级为 CyclicGraph Engine 图探索架构，用状态机保证长周期运行的稳定性，并通过“业务知识库 + 真实大闭环 + 经验自动沉淀”实现系统自进化、越用越好用。

在结构、目标与场景均不相同的两个业务建模项目中，单任务完成耗时较人工基线分别减少约 85% 与 83%，其中一个算法模型已将系统自主推导的方案推全上线，并取得线上收益；另一个多目标项目中，系统产出的方案在全部 12 个预估目标上同时超过人工基线。两个项目唯一的共同点是同一套系统架构，说明增益来自架构本身。本文分享这套系统的设计理念、架构演进与可信度设计，希望对大家有所帮助或启发。

1 背景：算法工程师的时间都去哪了？

一个算法工程师的典型工作流是：修改代码、推送代码、提交训练、等待、查看日志提取指标、与上一轮对比、决定下一步。等待的间隙，工程师会切换到其他任务，但切换有成本，时间利用不充分；如果训练在凌晨完成，还要等到第二天继续。一天下来，大约完成 2~3 次实质性迭代。真正需要判断力的环节，反而被切换和等待挤压得所剩无几。

2025 年底，Andrej Karpathy 开源了 AutoResearch：一个在单张 H100 上训练 5000 万参数教学级 GPT 的实验原型。仓库只有三个文件：program.md 用自然语言描述研究规则，train.py 是 Agent 唯一可自主修改的训练代码，prepare.py 负责评估。正是这个极简组合，让 LLM 驱动的研究在夜间和周末自动运行。约两天内，系统运行约 700 次实验，产出约 20 个针对 val_bpb 的正向提交。这套循环背后有一个刻意的信任设计：负责评估的 prepare.py 被冻结为不可修改文件，Agent 只能改训练代码而不能改评估函数，从机制上杜绝了“篡改裁判”的可能；而 keep/reset 的 Git 棘轮机制让每一步改进都可审计、可回滚。

这让我们看到了“让 Agent 自主迭代”的可能性。但把它搬进企业场景后，三个问题很快暴露：

• 可信度问题：规则全部以自然语言 Prompt 声明，模型幻觉会导致执行不完全可信；
• 运行环境差异：本地单机与企业云端训练平台差异巨大，Agent 需要异步执行，评价指标要体现业务差异性；
• LOOP 架构的根本局限：keep/reset 本质是可回滚的单线程串行 LOOP，效果改善就 commit、退化就 reset，同一时刻只能维护一条时间线。多数 AutoResearch 实践者（包括最初的我们）都沿用了这套单线程思路。

本文要讲的，是我们如何在三个月内经历三次架构重构，最终跳出 LOOP 架构，从“跑起来”走到“能自动化、自进化”：V1 回答“能不能跑”，V2 回答“能不能稳定地跑”，V3 回答“能不能跑得又快又准”。

2 设计理念：我们想造一个什么样的系统？

在展开架构细节之前，先说清楚我们的五条设计理念，后面所有取舍都由此推导：

1. 高效、高性价比。Agent 的夜间与周末算力是“闲置产能”，系统要能把人的注意力从执行中解放出来，只保留在高价值判断上。
2. 与底层 Agent 基座解耦。Agent 基座能力在快速进步，模型每几个月就有性价比更优的选择。系统不应该绑死在任何一家基座上，而是通过良好的 Harness 设计“搭便车”——基座升级，系统免费受益。
3. 系统自进化，越用越好用。经验、工具、Skill 不应该每次从零开始，而应在使用中自动总结、经人工校验后沉淀回系统。
4. 用真实的大闭环获取优质数据。离线指标提升只是中间站，方案上线后的真实反馈回流知识库，才是垂直场景里最稀缺的数据。系统在使用中不断积累业务知识，形成自进化的飞轮。
5. 可信优先。无人值守的长周期循环里，一次错误会成为下一轮决策的输入，逐轮放大。凡是能用代码表达的约束，一律不放在 prompt 里。

3 三次架构演进：从 LOOP 到 CyclicGraph Engine

三个版本不是提前规划的路线图，而是被真实问题驱动的演进。

3.1 V1 把 LOOP 搬上企业云端

定时任务 + Shell 脚本周期性触发，单个 Agent 串行完成检查、提取、分析、改代码的全链路，报告归档到云端协作文档。V1 实现了企业云端的 AutoResearch，但上下文爆炸、状态同步不及时等问题造成了低效。

3.2 V2 异步循环与显式状态机

每次触发创建全新会话，状态持久化在 JSON 状态文件中，解决了长会话带来的上下文爆炸问题。架构拆分为 Monitor 与 Iterator 两个角色，依靠状态文件的 phase 字段互斥路由，同一时刻只有一个角色工作。状态文件只保留决策所需的最小信息，目标是把探索结果压缩为可复用的决策依据；这是针对 ML 迭代场景的定制设计，与通用图编排框架的“全量状态”思路不同。另一个关键决策是“无状态触发 + 有状态文件”：Agent 不同步等待训练（训练动辄数小时，长会话等待既浪费上下文也不可靠），而是靠定时触发的新会话在下一次唤起时从状态文件恢复现场，这为 V3 的异步并行打下了地基。

3.3 V3 CyclicGraph Engine 图探索架构

V3 打破了 V1、V2 沿用的单线程 LOOP 限制，核心机制是 Spawn-Converge：

• Spawn：决策层的主 Agent 把一个大问题拆成 3~4 个互斥的差异化假设（例如“特征不足”与“结构不足”），派发给执行层；
• 执行：子 Agent 通过上下文隔离并行地各自修改代码、提交训练，互不知情，因而不会被彼此的中间结论带偏；
• Converge：训练完成后，主 Agent 汇总对比几份独立结果、提炼洞察，并决策下一轮方向组合。

需要强调的是，这与“多开几个实验同时跑”有本质区别。并行只是手段，配套的是三步闭环：主 Agent 先拆互斥假设，子 Agent 各自独立验证，主 Agent 最后收拢对比做决策。如果只并行、不收拢，就退化成了多开实验。

调度层面，系统自 V2 起逐步演进为状态机驱动：异步触发 + 状态恢复，Agent 不同步等待训练，而是依靠状态机在下次触发时查询结果。这是对“训练需要数小时”这一物理约束的合理架构回应，也显著提升了系统稳定性与流程灵活度。

3.4 图架构带来的探索效率跃升

图架构的效率收益可以直接量化。在同一个建模项目上：LOOP 架构下 10 次迭代耗时 3 天（0.14 次/小时）且未取得突破；切换为图架构后，12 次迭代仅耗时 4.7 小时（2.55 次/小时）并达成目标，迭代速度相差 18 倍（完整效果见第 8 节）。

差异并非来自单次训练变快，而是来自四点：正交并行把每轮的信息获取量提升约 3 倍；“汇总—分发”的组织形式提高了单位时间内的有效决策数；边界探针快速确定参数的上下界；单变量控制避免了因变量混淆产生的无效迭代。

4 垂直耦合：把 AutoResearch 长在业务场景里

通用 Agent 不懂你的业务。让系统真正可用的关键，是把它垂直耦合到具体业务场景，而这靠的是业务知识库 + 真实大闭环。

4.1 业务知识库 系统的“入职培训”

初始化一个新项目时，系统会要求提供基础业务知识库（建模目标、样本口径、历史结论、约束边界），并结合自动化的初始调研构建方向池，保证知识库的起点是干净的。

4.2 渐进式调研机制

系统的调研方式分三层：

• 初始化调研：项目启动时建立方向池，对调研来源做筛选；
• 渐进式调研：研究过程中按需补充，而不是一次性塞满上下文；
• 强制调研：当指标边际提升缓慢、连续多轮在同一方案内打转时，触发逃逸机制，强制切换维度并重新调研——避免系统在局部最优里空转烧资源。

4.3 真实大闭环 自进化飞轮的燃料

离线指标提升只是中间站。方案上线后的真实反馈（线上实验结论、业务口径的指标变化）会回流进知识库，成为系统在垂直场景内最稀缺的优质数据。离线指标升降是明确的、可机器判读的；线上闭环数据则校准“离线好”与“线上好”之间的偏差。在系统使用过程中，通过知识、经验与工具的持续积累与回流，实现系统在垂直场景的自进化。

5 可信度设计：无人值守时，凭什么相信系统？

长周期自动循环中，Agent 的不可靠行为分为两类，成因和治理手段完全不同：

• 认知层幻觉：输出在语言上自洽、在事实上错误，例如把训练波动归因为某个并不存在的因素，或把参数填成不存在的取值。它不会报错，只会悄悄把后续决策引向错误方向。
• 执行层偏差：工具调用失败、返回结果与预期不符，例如平台接口超时、任务 ID 过期、日志字段缺失导致指标解析为空。

治理原则是一句话：凡是能用代码表达的约束，一律不放在 Prompt 里。Prompt 里写“不要重复已证伪方向”并不足够，Agent 仍可能认为“这次情况不同”；但已证伪方向一旦写入状态文件的硬约束列表，下一轮就会在代码逻辑层面被直接跳过。针对执行层偏差，系统在三个环节设防：关键状态以状态文件为唯一事实源，易过期字段（如任务 ID）每轮强制重新读取，禁止复用上下文旧值；所有平台调用封装为幂等化工具，返回值做结构化校验，字段缺失或格式异常即判定失败，而非带着空值继续执行；区分代码故障与基础设施故障，前者计入证伪记录并触发方案调整，后者自动重试且不占用轮次预算。

5.1 原始证据优先：指标与 diff 都要“原件”

系统保留每一轮探索的原始指标提升和原始代码 diff。Agent 的分析可能有幻觉，但指标数据和代码修改本身是确定真实的。任何一轮的结论都可以回溯到证据链，而不是回溯到某段叙述。这一点来自我们对幻觉复合效应的观察：循环里错误结论一旦被喂入下一轮上下文，就会在错误前提上叠加错误推理，步步错但步步“看起来合理”；唯一的反制，是让训练结果这样的物理事实成为不可绕过的校验锚点——模型可以幻觉“学习率太小”，但训练跑完后的指标曲线不会配合它幻觉。

5.2 上下文隔离与交叉验证

子 Agent 探索时上下文相互隔离，或改用不同模型，从两条路径验证同一个假设，检测分歧。汇总时主 Agent 对照几份独立结果再做决策，天然带一层交叉验证。交叉验证并非每轮都做（成本太高），而是在主 Agent 置信度偏低、连续多轮指标同向恶化、或归因涉及方向性决策时触发；分歧结论同时保留并转入人工审查，而非简单投票取多数。

5.3 二级人机校验 Skill 草稿机制

系统在执行过程中会自动总结工具使用经验与踩坑处理方法，沉淀出可复用的 Skill 草稿，经过“系统初筛 + 人工审核”的两级校验后，正式写入系统工具集。一个真实例子：早期批次中训练平台参数服务器连接异常的处理经验被系统自动整理为 Skill 草稿，人工审核后反哺至工具集，此后系统自主应对数百次同类基础设施故障，全程无需人工介入。已入库的 Skill 也会在后续使用中通过审核机制持续自完善。这背后是一条反幻觉的晋升链：经验先作为带证据的低层级记录存在，满足复用规则并通过人工审核后才晋升为正式 Skill，未经外部验证的结论永远不进入知识库，只暂存在临时区。

5.4 归因：自进化系统的“慢变量”

Agent 的归因（“为什么这个方向有效”）仍是开放难题。我们的答案不是某个单点技术，而是三方面积累：知识库的积累让归因有业务依据，调研的积累让归因有论文依据，真实实验数据的积累让归因有证据依据。归因能力是慢变量——Harness 建设得好，它会随使用时长持续变好；这本身就是自进化系统设计的一部分。

5.5 Harness 决定系统上限

我们把套在通用 Agent 外、让它在生产流程中稳定行动的一组运行规则（状态文件、工具返回校验、失败恢复、经验库、硬约束、提示词）称为 Harness。外部也有同方向的实证：LangChain 的编码 Agent 全程使用同一个模型，仅调整 System Prompt、Tools、Middleware 三个 Harness 维度，在 Terminal Bench 2.0 的 89 个跨领域任务上得分从 52.8% 提升至 66.5%。同一个模型，换一套工作机制，差异达到 14 个百分点。我们的三次重构，本质上就是在与底层通用 Agent 解耦的前提下，打磨这套领域特定的 Harness，它决定系统是加速发现真理，还是加速传播错误。基座模型的能力红利人人可得，而 Harness 是差异化竞争力的所在。

6 与 Agent 基座解耦，享受 Agent 红利

系统与底层 Agent 基座彻底解耦，核心设计是“无状态触发 + 有状态文件”：状态全部落在 JSON 文件里，每次触发都是全新会话。这个设计带来三重收益：随时可触发——不受会话生命周期限制，定时、手动、事件驱动任意唤起；零空转——Agent 不同步等待动辄数小时的训练，触发即工作、完成即退出，长周期任务中也能充分利用计算资源；基座自由——不依赖任何基座的会话记忆或专有能力，Agent 基座升级后，系统可无缝切换。

在前端交互层，我们尝试过 IM 机器人、内部 Agent 平台、自建沙箱等多种形态，框架设计与交互形态完全解耦——换个入口，系统照常运转。

7 真实使用体验：从一句需求到自主迭代

对使用者来说，开启一个新项目非常轻：

用户：我要开始一个新项目，需要给你提供什么？

系统：需要提供基础业务知识库（若有缺失，会询问补充）、需要优化的业务指标、报告归档的云端文档目录、迭代上限和阈值指标（主要用来防止无限制消耗资源），并给出一份可直接填写的需求模板。

用户：填写模板文档，把链接发给系统。

系统：启动自动迭代。中途用户可随时询问进度、打断；如果不打断，系统会在达成目标或达到上限时自行停止。

项目启动后的典型体验是：周五启动，周一回来发现系统已自主完成十余轮迭代，核心指标显著改善，期间零人工介入。这直接修正了我们对人机分工的初始设定（“AI 执行、人监督每一轮方向”）；实践后收敛出的分工边界是：人的价值集中在少数几个高杠杆节点上，而非分散在每一轮的执行监督中。

8 效果、验证与边界

8.1 效果：效率增益来自架构本身

在两个模型结构、优化目标、场景均不相同的建模项目上，系统给出了高度一致的答案：单任务完成耗时较人工基线分别减少约 85% 与 83%。两个项目唯一的共同点是同一套系统架构，这说明增益来自架构，而不是某个项目的特殊性。其中一个项目中，系统自主推导出的优化方案（不在任何参考论文中）已通过全部验证并推全上线，取得线上收益；另一个多目标项目中，全部 12 个预估目标均超过人工基线。

8.2 与传统 AutoML 的差异

最关键的一点：工程界主流的 AutoML 默认“正确答案在预定义搜索空间内”。而在我们的实际案例中，正确答案恰恰不在初始空间内——系统需要先证伪并退出一个错误的问题框架，再从论文的数学结构中推导出新的候选方案。这是能力层级的差异（从“执行给定方向”到“自主生成假设”），而非搜索效率的差异。

8.3 三层验证：自主方案上线和反哺经验

验证覆盖三件事：离线指标、线上实验、可解释性检验。前两件决定上线和推全——离线指标达标后，用线上 A/B 实验结果的置信区间判断是否推全；第三件决定能不能进硬约束库——若 Agent 给不出合理的推导，即使指标好也不入库，避免错误经验污染知识库，无法判断是否可入库时转人工审核。

8.4 适用边界与诚实的局限

这套架构适用于同时满足三个条件的场景：有明确的可量化指标；单次实验成本可接受；实验结果可逆。它不适用于评价高度主观、搜索空间完全开放、或单次实验成本极高且不可逆的场景。

• 基础设施依赖：训练资源是最大的外部瓶颈，系统只能降低资源消耗，无法从根源消除资源紧张；
• 经验迁移的幻觉风险：涉及垂直业务领域的经验库跨项目复用，可能把局部经验错误泛化，当前靠人工审核卡点拦截；
• 归因可解释性有限：系统能推导出有效方案，但“为什么有效”的归因解释仍不够严谨，需人工交叉验证后才能进入硬约束库。

下一步的方向：一是提升自进化稳定性 —— 自进化技术架构方向已确定，后续持续打磨状态机与流程稳定性；二是知识迁移中的幻觉问题 —— 如何稳定复用跨业务的经验，保证经验库干净稳定；三是探索更友好的交互与使用体验。

9 结语：从 Karpathy 出发，走到更远的地方

Karpathy 的 AutoResearch 是一个在单张 H100 上跑教学级 GPT 的实验原型。我们所做的，是把这套理念搬进企业云端的真实业务场景：在工程化过程中发现单线程 LOOP 的根本局限，用 CyclicGraph Engine 的图探索架构打破它；用状态机保障长周期运行的稳定性；用业务知识库和真实大闭环，让系统在垂直场景里越用越好用。

我们相信，Agent 自主研究的真正价值不在于“比人更快地搜索已有空间”，而在于“能够证伪错误的前提，并主动扩展搜索空间”。当系统能够从论文的数学结构中推导出人类未给定的方案，并在真实业务中验证有效时，它已经从“执行工具”走向了“研究伙伴”。这条路才刚刚开始。

最后回到方法论本身。三个月三次重构给我们的最大启发是：自主研究系统的核心工程量不在模型侧，而在 Harness 侧——状态机、硬约束、证据链、晋升门槛这些“不性感”的基础设施，才是决定系统可信度的分水岭。评估这套系统的正确方式也不是看它跑得多快，而是看它犯错之后能否被证据纠正、被约束拦住、被经验库记住。可复现、可审计、可回滚，是自主研究系统比效率更重要的底座。

10 参考文献及补充说明

• [1] Andrej Karpathy. AutoResearch. GitHub, 2025
• [2] Ryan Lopopolo. Harness engineering: leveraging Codex in an agent-first world. OpenAI, 2026
• [3] LangChain. The Anatomy of an Agent Harness. LangChain Blog
• [4] 统计口径说明：本文统一以“一个训练任务”作为一次迭代的计数单位（并行方向分别计入），含因指标崩溃被证伪的探索性失败；人工基线按实际投入迭代的工作日折算；系统侧仅统计正常执行批次，基础设施故障导致的批次不计入分母。18 倍为图架构相对本系统自身 LOOP 架构的提升；85% 与 83% 为相对人工基线的单任务耗时减少，两者分母不同。

搜索和推荐场景中想要使用语言模型提高在线效果，往往面临着在线极低延迟的约束，现有通用大模型推理引擎并非在这一延迟约束下设计，因此本文从「具有确定 decode 次数上界的请求」这一工作负载出发，重新设计在线执行路径：以静态 DAG 组织完整业务请求，结合 AOTInductor 编译、Packed Prefill、请求内 K/V 共享及选择性 FP8，系统性压缩调度与计算开销。在平均端到端时延低于 20ms 的约束下，Prefill-only 有效 MFU 达到 67%，吞吐较 SGLang 提升 10 倍，为 SLM 在搜推场景的大规模落地提供了一套高性能、可复用的工程实践。

摘要

搜推场景下业界逐渐使用 SLM（Small Language Model， 小参数量语言模型0.5~1B），用于意图理解，相关性判断，生成式推荐等任务，这些模型保留 Decoder-only Transformer 和 Next-Token Prediction 的基本结构，但在线执行形态与开放式文本生成存在明显差异：

• Prefill-Only 模式：仅执行一次 prefill，根据每条序列最后一个有效 Token 位置的 logits 得到类别或分值，或基于 prefill 产出的 Embedding 接入 MLP 模块做分类任务；
• Beam Search 模式：执行一次 prefill 和固定次数 decode，在固定 beam 宽度下返回少量候选序列。两类请求的输入规模、运行状态和最大迭代次数均具有可预先确定的上界。

本文将这类控制流结构、状态容量和执行资源能够在部署前界定，输出 decode 的次数具有固定上界的请求，统称为有界生成负载；其中Prefill-Only 可以看作为 decode 次数为 0 的特殊情况；

在项目早期，我们通过 Triton Inference Server 的 Python Backend 适配业务协议，并使用 SGLang 完成模型执行。该方案能够快速复用 tokenizer、生成调度和状态管理能力，支持业务快速实验拿到效果。但随着 SLM 在搜索场景的持续应用，越来越多的场景取得显著收益，推全成本也在显著增加，业界现有方案已经不足以支持更大规模的落地 SLM，我们随即基于模型负载的独特性，提出专为有界生成负载设计的推理系统。

我们构建了一套以静态有向无环图（Directed Acyclic Graph， DAG）为在线执行抽象的推理框架，将完整业务请求作为 DAG 执行、端到端测量和容量规划的共同边界，并以节点作为模型编译边界。模型计算节点使用 PyTorch AOTInductor 生成的 AOTI 产物，文本处理和数据转换由框架自定义节点完成，Runtime 负责节点调度、资源管理和并发执行。针对有界生成负载，系统进一步将 Packed Prefill、请求内 shared-prefix K/V 布局、固定 Beam Search 编译和选择性 FP8 矩阵计算等自定义实现嵌入 AOTInductor 编译流程。

性能结论表明，约 0.6B 的 Prefill-Only 模型在每个请求包含 15 条样本时达到约 100 request QPS，即约 1，500 sample/s；约 0.5B 的短 prompt 和长 prompt Beam Search 模型在 beam width 约为 100、decode 4 次时，分别达到约 300 和 120 request QPS。三类负载的平均端到端时延均低于 20 ms，P99 约为 70 ms，Prefill-Only 负载下混合精度有效 MFU 为 67%，约为 SGLang 10 倍，短 prompt beam search 有效MFU 41%，约为 SGLang 6 倍。

目前，该框架已经在美团搜索意图分流、搜索相关性判断、生成式召回等应用 SLM 的场景取得实验显著性，能支撑业务在推理成本可控的情况下全量推送。

01 有界生成负载的特征与设计约束

本文关注搜索推荐场景下一类在线执行过程受到业务约束的 SLM 负载：模型仍采用 Decoder-only Transformer，但一次请求涉及的模型阶段和最大迭代次数固定，搜索宽度和状态容量也具有可在部署前确定的上界。实际输入长度、batch 大小和搜索候选仍能随请求变化，但这些动态性均发生在预先配置的容量范围内。

“执行结构固定、动态 shape 可控”是后续系统设计的基础。这些约束来自具体业务的在线执行方式，与模型参数量或模型结构没有必然关系；同一个语言模型用于开放式文本生成时，也可能不满足这里的有界条件。

1.1 两类在线执行形式

Prefill-Only 模型只执行一次 Transformer prefill，不进入自回归 decode。模型在每条序列最后一个有效 Token 位置计算 Next-Token Logits，再根据目标标签对应 Token 的 logits，通过 softmax、Top-K 或固定映射得到业务输出。该路径仍使用语言模型的 Next-Token Prediction Head，但在线执行只包含一次批量前向过程。Prefill 结束后即可返回结果，不需要跨阶段维护该请求的 K/V 状态。

Beam Search 模型在 prompt prefill 后继续执行固定次数 decode。首步 logits 用于初始化候选，后续每一步从各 beam 的 Token 分布中选择局部候选，与历史累计分数合并，再保留固定数量的候选序列。对于一个具体部署配置，beam 宽度和最大生成 Token 数均为固定值。Beam Search 中的候选、累计分数和 parent index 仍由模型输出决定，但状态容量、更新次数和算子组合可以提前确定。

1.2 输入与状态边界

本文覆盖的请求平均输入长度均在 500 Token 以内，输出则是分类分值或少量生成 Token。部分 Prefill-Only 请求包含多条输入样本；有界 Beam Search 的 beam 宽度和最大生成步数由部署配置确定，本文覆盖的配置不超过 400 beam 和 5 个生成 Token。两类请求的实际输入和候选内容会变化，但处理规模和状态容量都具有明确上界。

对于同一 batch 内的变长输入，统一 padding 会使短序列承担与最长序列相同的线性层、MLP 和 attention 计算。系统因此保留每条序列的有效长度，并在后续 Prefill 计算中只处理有效 Token。

Prefill-Only 请求在一次前向后结束，不需要跨阶段保存 K/V。有界 Beam Search 只在少量 decode step 之间维护状态，同一请求内的 beam 共用一份 prompt K/V，并分别保存较短的 suffix K/V。输入长度、beam 宽度和生成步数均有上界，因此所需状态可以在加载阶段完成容量规划和内存预分配。

跨请求 prefix cache 的收益取决于公共 Token 前缀的长度和命中率。当前模板较早进入业务 Query、候选文本等请求特有内容，不同请求间可复用的公共前缀很短，实际命中率也很低；同时，平均输入长度不足 500 Token，缓存管理能够摊薄的计算有限。因此，系统不维护跨请求 Prefix Cache，只利用同一 Beam Search 请求内部确定存在的 prompt K/V 共享。

1.3 在线工作负载分析

由于 GPU 推理本质上是基于 Cuda Stream 的串行计算，因此推理服务的耗时可以抽象为排队论中的 G/G/1 模型。排队等待时间的经典工具是 Kingman 近似公式(G/G/1 排队）： $\mathbb{E}[W_q] \approx \frac{\rho}{1 - \rho} \cdot \frac{c_a^2 + c_s^2}{2} \cdot \tau$， 线上统计 QPS 是每秒处理的请求数，因此衡量推理性能的时间窗口就是 1000ms， 则可以对公式进行如下解释:

• $\rho$ 可以表征 GPU 的拥挤程度，表示在 1000ms 内执行计算的时间占比。
• $c_a$ 请求到达间隔的变异系数，可以表征的是在 1000ms 内请求到达 GPU的概率分布，通常自然流量遵循泊松分布，但由于序列过长而需要分批处理时则会偏离泊松分布，请求在 1000ms 内的分布出现聚集现象但 GPU 处理能力有限，造成排队。
• $c_s$ 服务时间变异系数， 表征的是对于推理服务处理的耗时分布情况， 如果序列长度，batch size 等分布不均，则会使得单次请求处理时间分布也呈现出方差过大的现象。
• $\tau$ 表征单次 forward 的平均耗时，表示单次请求占用 GPU 卡的平均时间，可以表示为请求处理的周转速度。

推理耗时可以分为四部分，CPU 入口等待时间、CPU 处理时间、GPU 入口等待时间、GPU 处理时间。 CPU 通常并发处理能力远强于 GPU，因此 GPU 成为资源瓶颈。 越大， GPU 入口等待时间就会延长，当超过上游超时后，排队中的请求被 GPU 顺序执行则是一种浪费，大量请求的丢弃又会导致 GPU 在 1000ms 内的处理时间不足，也就是 $\rho$ 偏低。于是呈现出一种 GPU 利用率很低但耗时却很高的现象。

在搜推场景下，由于序列分批导致请求到达间隔严重偏离泊松分布，服务时间通常是稳定的（序列长度和 batchsize 基本固定），单次推理的平均耗时一般在 20ms 以下。 传统的 SGLang/vLLM框架并不是在这样的假设下设计，调度策略难以处理严重偏离泊松分布的请求到达负载，而其为了prefill 长度任意变化，decode 次数无上界等场景设计的各种优化策略，在搜推的 SLM 场景均是负向优化。

我们利用 $c_s$ 在搜推场景下较小的优势，移除 SGLang 为无界生成负载定制的各种优化手段，重新为有界生成负载（Prefill-Only & Beam Search）设计 GPU 计算路径，以达到减少 $\tau$ 的目的，通过移除 Python 对 request 和 Token 的调度开销压缩 CPU 等待与处理时间，从而达到减少 GPU 空泡的目的，进一步通过 cpp 精细化的 Multi-Stream 调度能力，增加 GPU 跨请求并行计算的能力，以缓解无法调和的 $c_a$。

1.4 负载特征与系统设计

上述业务约束将系统问题收束为：如何高效处理边界已知的一批输入。编译、执行和容量控制均围绕这一目标组织。

02 基于静态 DAG 的分层编译执行架构

整体上，本文实现的是一套以静态 DAG 组织完整请求流程、以独立节点封装具体计算的分层编译执行架构。离线构建链使用 Python 表达模型语义、选择算子实现，并将完整 GPU 计算编译为可直接加载的 AOTI 节点产物；在线执行链使用 C++ 完成协议处理、DAG 调度、资源管理和数据转换，不再解释或即时构建模型计算。

在线执行链进一步分为服务、DAG Runtime 和节点三个层次。服务层负责 RPC 协议、请求准入和生命周期；DAG Runtime 根据静态拓扑调度节点，并管理跨节点 Tensor、设备同步、请求上下文和并发；节点负责具体计算，其中 CPU 节点承载文本处理和结果编码，GPU 节点加载 AOTI 编译产物。Runtime 只依赖节点的输入输出、设备和执行接口，attention、Beam Search 和精度策略都封装在节点内部。

离线构建：Torch 模型与算子语义
            -> lowering 与 AOTInductor
            -> AOTI 模型节点产物

          C++ 节点实现与配置
            -> CPU 自定义节点与资源

在线执行：RPC 服务
            -> DAG Runtime
                 -> CPU 预处理节点
                 -> AOTI 模型节点
                 -> CPU 结果节点
            -> RPC 返回

两类模型在这套架构中对应两张不同的 DAG：

这种分层首先使系统可以按完整业务请求执行：Prefill-Only 的多条样本一次进入模型节点，Beam Search 的各个 decode step 在生成节点内部完成。其次，静态拓扑和有界 shape 使 buffer、stream 和执行实例能够在加载阶段规划，请求热路径只处理有效数据。最后，模型计算被封装在节点内部，算子、精度和硬件实现可以独立替换，而服务协议和 DAG 调度机制保持稳定。

2.1 完整业务请求的执行边界

项目早期通过 Triton Inference Server 的 Python Backend 适配业务协议，并使用 SGLang 完成模型执行。这套方案能够快速复用 tokenizer、生成调度和状态管理能力，适合模型验证和早期上线。但在当时的接入方式中，批量输入会被拆分为多条独立生成请求，分别完成文本处理、状态创建和模型调度，返回后再恢复原有顺序和业务结构；Beam Search 模型的各个 decode step 也继续经过通用生成控制路径。

通用生成系统通常按照独立请求组织调度，并在运行时处理请求的加入、退出和解码长度变化。这种粒度适合开放式生成；对于当前只执行一次 prefill 或少量 decode 的负载，请求拆分、对象创建、进程通信、逐步控制和结果重组却都要在约 20 ms 的端到端时延预算内完成，较长生成任务中能够被模型计算摊薄的固定开销在这里更加显著。

因此我们重新选择执行单位：完整业务请求成为 DAG 调度、端到端测量和线上容量规划的共同边界。Prefill-Only 请求内部可以包含多条样本，但这些样本作为一个 batch 进入模型节点，不再拆成独立生成任务；Beam Search 请求则从 prompt prefill 到最终候选返回只经历一次 DAG 调度。模型编译仍以节点为边界，不与请求调度耦合。

项目早期的执行路径可以概括为：

批量业务输入
  -> 拆分为逐样本生成请求
  -> tokenizer / 请求状态创建
  -> 通用生成 Runtime
  -> 逐 decode step 控制
  -> 结果重组

当前执行路径则为：

业务请求
  -> 协议适配与请求准入
  -> DAG Runtime
       -> 文本处理与 packed tokenizer
       -> prefill / 生成 AOTI 节点
       -> 结果编码
  -> RPC 输出

Prefill-Only 中的多条序列由模型节点一次处理，Beam Search 的逐步控制则收进生成节点。在线请求不再反复跨越 Python Backend、服务进程和通用生成 Runtime，协议处理、DAG 调度、buffer 管理及 CPU 数据转换均在进程内完成。这一执行路径减少了请求拆分、对象创建、进程通信、逐步调度和结果重组产生的固定开销。

2.2 静态 DAG 的节点执行模型

静态 DAG 描述协议适配后的节点拓扑、跨节点 Tensor、执行设备和同步关系，而不要求每次请求具有完全相同的数据规模。Runtime 按照以下层次组织执行：

DAG Runtime
  -> Node
       -> CPU Engine  -> 节点配置与本地资源
       -> AOTI Engine -> 编译模型产物

DAG 声明节点之间的依赖和 Tensor 接口，节点类型决定使用哪类执行引擎，执行引擎负责调用具体实现。AOTI Engine 加载模型编译产物，CPU Engine 则调用 tokenizer、数据转换和结果编码等自定义节点，并加载各自的配置与资源。

公开协议中的字符串不会直接作为模型节点输入。在线服务首先将 String 输入转换为连续 UTF-8 payload 和 lengths，DAG 内部再通过 CPU 节点完成规范化、tokenizer 和 packed 数据组织；DAG 输出到 RPC response 的最终映射同样由服务接口完成。由此，DAG 的输入输出保持明确的 Tensor 表示，同时不将具体 RPC 协议耦合到节点实现中。

静态 DAG 固定的是执行结构和物理资源边界，并不要求 Tensor shape 完全固定。系统在加载阶段确定：

• 节点拓扑和依赖关系；
• 跨节点 Tensor 的类型与接口；
• Tensor 的最大物理容量；
• 最大迭代结构；
• 执行设备和同步边界。

请求阶段仍然动态确定：

• 请求内实际 batch 大小；
• 每条文本的有效 Token 数；
• 本次 Tensor 的逻辑 shape；
• Beam Search 中由模型输出决定的状态内容。

这一执行模型以固定结构承载有界的动态数据。加载阶段根据动态 shape 上界和执行并发预分配物理资源；请求到达后，CPU 节点只写入本次有效数据并更新逻辑 shape，下游节点仍按实际数据范围执行。输入长度和 Beam 状态等业务动态性得以保留，同时不会改变节点拓扑和物理资源容量。

节点边界主要由跨节点数据表示、执行设备和同步关系决定。字符串规范化、tokenizer 和结果编码由 CPU 节点执行。Prefill-Only 的 AOTI 节点包含 Transformer prefill 和分值计算；Beam Search 的 AOTI 节点则包含 Transformer、候选选择和固定 Beam 状态更新。一个 AOTI 节点可以包含多个算子及其固定组合，DAG Runtime 只负责调用节点，不需要理解内部的模型拓扑、搜索状态或精度策略。

同一请求上下文中的 GPU 操作优先通过 CUDA stream 的提交顺序建立依赖，只有 GPU 结果需要交给 CPU 节点或服务返回响应时才进行必要同步。跨节点 Tensor 的数据搬运也由 Runtime 统一规划，避免每个算子独立管理跨设备传输。

2.3 固定 Beam Search 的单节点编译

固定 Beam Search 可以把有限次数的状态转移表达为结构确定的 Tensor 程序，同时保留由模型输出决定的候选内容。开放式生成系统通常需要在 decode step 边界重新组织请求状态并决定下一轮执行对象；当前负载的搜索深度固定，这部分控制因而可以从在线 Runtime 移入模型程序。

设最大生成 Token 数为 N_gen。模型首先执行 prompt prefill，并根据首步 logits 初始化候选；随后固定执行 N_gen - 1 次状态更新。每一步维护的主要状态包括：

• 当前 logits；
• 候选 token 和候选分数；
• 累计 Beam 分数；
• parent index；
• 已生成 token sequence；
• suffix K/V。

这些状态的内容由当前模型输出决定，但状态 Tensor 的容量、更新流程和算子组合在部署阶段已经确定。因此，Beam Search 不由 C++ Runtime 手写逐 Token 控制，而是在 Torch 模型中表示为固定结构的张量程序，并与 Transformer 一同导出和编译。

prompt prefill
  -> 首步候选初始化
  -> [
       decode
       -> 局部候选选择
       -> 累计分数合并
       -> parent index 更新
       -> token 与 suffix K/V 重排
     ] × (N_gen - 1)
  -> 最终候选及分数

整个过程最终封装为一个生成 AOTI 节点。DAG Runtime 对该节点只执行一次节点调度，不感知内部包含多少次 decode，也不理解 Beam Search 的候选选择和状态更新语义。

固定的是控制流，不是模型输出。parent index 仍会动态决定 suffix K/V、token sequence 和累计分数的重排，候选内容也仍取决于每一步 logits；这些数据依赖不会改变 Runtime 所看到的节点拓扑、Tensor 接口和资源规模。

将逐 step 控制收进编译节点后，请求不再在每个 token 后返回通用生成 Runtime。Transformer 计算、候选选择和状态更新可以在同一导出图中统一优化，在线服务只看到 generation 节点的输入和最终输出。

2.4 节点实现的离线编译

离线编译链的核心作用是将模型语义与硬件实现选择解耦。Python 侧负责表达模型和算子语义、选择 lowering 并构建产物；在线服务和 DAG Runtime 只加载已经生成的节点产物，不导入 Python 模型代码，也不进行即时编译。

对于具有独立数学语义、值得针对目标 GPU 选择实现的计算单元，框架定义稳定的可替换算子接口。Torch 参考实现明确规定输入输出、shape、dtype 和数学语义，构建配置再根据目标 shape 和硬件选择 Torch、Triton 或原生 C++/CUDA 实现。lowering 只替换节点内部的具体计算路径，不改变 DAG 可见的 Tensor 接口。

整体构建链如下：

Torch 模型
  -> 算子 lowering
  -> torch.export
  -> AOTInductor
  -> AOTI 共享库
  -> 节点配置与 manifest
  -> 可部署节点产物

Triton lowering 可以通过 torch.library.triton_op 和 wrap_triton 进入导出图；需要原生 C++/CUDA 扩展时，则在目标构建过程中将对应接口和静态库链接进节点产物。权重转换、packing、量化参数准备以及目标 GPU 相关的 kernel 配置也都在离线阶段完成。

模型定义还将运行时配置、编译配置和验收标准固化为可检查的部署描述：

• 运行时配置：DAG 拓扑、节点 I/O、执行引擎、动态 shape 上界和并发资源；
• 编译配置：模型参数映射、可替换算子的实现、目标 GPU 和精度策略；
• 验证标准：参考实现、代表输入、边界 shape、数值门限、业务指标和端到端性能门禁。

模型结构和节点接口不变的新 checkpoint 可以复用大部分构建描述，但仍需重新检查参数映射、数值一致性和性能。接口复用并不意味着性能配置可以直接继承。

这种分层还使局部实现能够在接口不变的情况下替换。候选 kernel 先通过算子基准和数值对照筛选，再进入节点和完整 DAG 的 A/B 测试；只有在完整在线链路中仍能形成可辨认收益的实现，才会进入最终部署配置。由此避免仅根据 microbenchmark 决定线上实现。

明确的语义参考、可替换 lowering 和分层验收也为 AI 辅助优化提供了边界：AI 可以参与模型重表达和候选实现生成，最终选择仍由确定性的数值、业务指标和端到端性能验证决定。

2.5 执行资源与在线准入

状态和控制流有界，使执行资源能够在模型加载阶段按并发配置预先建立。在线链路中存在三个不同层次的并发参数，三者约束的资源不同，不能合并为一个统一的 concurrency 配置。

DAG 请求上下文持有一次请求执行所需的预分配 host/device buffer、逻辑 shape 状态和 CUDA stream。AOTI 执行实例负责调用已经加载的模型产物，并由执行引擎管理 runner、workspace 和权重资源。

加载阶段根据目标 GPU、动态 shape 上界和配置并发建立 DAG 请求上下文、Tensor 物理 buffer 和 AOTI runner。请求热路径只获取可用上下文、写入有效输入、更新逻辑 shape 并提交节点任务。

系统采用单个请求不跨卡、每张 GPU 部署完整模型副本的方式，不涉及 Tensor Parallel 或 Pipeline Parallel。不同卡型的算力、显存带宽、功耗限制和软件环境可能不同，因此节点内 kernel、精度配置和执行并发均按 GPU 独立选择；DAG、节点接口和资源管理机制保持不变。

容量配置按照完整链路逐层确定：先固定节点实现，再扫描 AOTI 执行实例数和 DAG 请求上下文数，最后设置服务入口的在途请求上限。每一步均通过端到端 QPS 和时延复核，避免将节点内部最优并发直接视为服务最优并发。

服务入口在已经验证的执行容量之外承担过载保护。后端暂时满载时，请求可以在入口有限等待；超过业务允许等待时间的请求不再进入后端计算。若持续到达速率高于单卡处理能力，服务按照配置拒绝或超时退出多余请求，避免已经失去业务时效的请求继续占用执行资源。

通过上述划分，在线系统只负责按照 DAG 执行完整请求，模型语义、固定生成过程和硬件实现均在节点构建阶段确定。第 3 章进一步介绍节点内部针对变长 prefill、Beam 状态、矩阵计算和 CPU 数据路径的专项优化。

03 有界生成节点的计算与数据路径优化

完成执行边界的调整后，系统吞吐主要取决于模型计算节点和相邻 CPU 节点的处理能力。两类负载中仍存在五类主要开销：变长样本的 padding 计算、Beam 间重复的 prompt K/V、候选选择与状态更新、密集矩阵计算，以及文本处理和结果编码的固定开销。

这些优化均以节点接口和数学语义不变为前提。Torch 实现提供数值和语义参考，构建阶段再根据目标 shape 和 GPU 选择具体 lowering 策略；候选实现依次通过算子、AOTI 节点和完整 DAG 验证后进入部署配置。

3.1 变长样本的 Packed Prefill

Prefill-Only 请求内包含多条长度不同的样本，统一 padding 会使所有样本按照最长序列执行线性层、MLP 和 attention。系统从 tokenizer 开始保留序列边界，将有效 Token 连续写入 packed buffer，并在一个模型节点中完成整个请求的 prefill。

请求内的多条字符串
  -> 连续 UTF-8 payload + lengths
  -> 批量 normalize / tokenize
  -> packed token buffer + sequence boundary
  -> packed Transformer prefill
  -> 各序列末位置 hidden state
  -> 每条样本的类别或分值

设第 i 条序列的长度为 L_i，query head 数为 N_q，K/V head 数为 N_kv，head dimension 为 D。packed attention 使用以下输入输出布局：

Q:   [ΣL_i, N_q,  D]
K/V: [ΣL_i, N_kv, D]
O:   [ΣL_i, N_q,  D]

sequence boundary 隐式定义 block-diagonal causal mask：不同序列之间不存在 attention 连接，每个 Query 只能访问同一序列内不晚于自身的位置。与统一 padding 相比，线性层和 MLP 的序列维计算规模由 B × L_max 降至更接近 ΣL_i，attention 则由 B × L_max² 降至更接近 ΣL_i²。batch 内长度差异越大，减少的无效计算越多。

FlashAttention-2 已提供成熟的变长 attention 实现。但在项目部署环境中，其变长接口无法同时满足 AOTI 集成与目标 GPU 兼容要求。系统因此采用针对目标 shape 优化的 Triton Packed GQA。

Triton kernel 不展开 GQA 的 K/V head，也不物化完整 attention score。kernel 根据 sequence boundary 确定当前 query block 对应的有效 K/V 范围，对 K/V 分块扫描，并使用 FP32 累积 online softmax 的最大值、归一化因子和输出状态。模型图随后使用同一套 sequence boundary 提取各序列末位置的 hidden state，再计算标签 logits、业务分值或生成所需状态。

sequence boundary 从 tokenizer 贯穿 attention 和结果提取，并与模型一起编译进 AOTI 节点。模型节点由此可以一次处理请求内的完整 batch，并按样本边界恢复输出。

Triton Packed GQA 使用显式 Torch 实现作为数值参考。代表 shape、边界 shape 和多序列用例共同验证数值误差与序列隔离。相对显式 Torch Packed Attention，该实现使中等和长 prompt 负载的完整 DAG 吞吐分别提升约 12% 和 39%。

3.2 请求内共享前缀的 K/V 布局

有界 Beam Search 中，所有 beam 共享同一个 prompt，仅生成 suffix 随搜索路径发生变化。这种固定的共享关系允许系统只保存一份 prompt K/V，并为每条 beam 保存较短的 suffix K/V：

prefix K/V: [L_p,    N_kv, D]
suffix K/V: [W, L_s, N_kv, D]

query:      [W,      N_q,  D]
output:     [W,      N_q,  D]

若每条 beam 分别保存完整 K/V，状态规模与 W(L_p + L_s) 成正比；使用 shared-prefix 布局后，则与 L_p + W L_s 成正比。对于本文固定 beam 宽度、同步推进且生成深度较小的负载，prompt 状态只需建立一次，请求结束时再与各 beam 的 suffix 一并释放。

对第 b 条 beam，attention 的数学语义仍为：

$$O_b = \operatorname{Attention} \left( Q_b, [\mathrm{prefix}_K;\mathrm{suffix}_K[b]], [\mathrm{prefix}_V;\mathrm{suffix}_V[b]] \right)$$

其中分号表示序列维拼接。实际执行不会生成对应的 concat Tensor。Triton kernel 直接读取公共 prefix 和当前 beam 的 suffix，并在同一组 FP32 online softmax 状态中合并两段 K/V 的贡献。

kernel 按 (beam， K/V head) 划分 program，每个 program 处理该 K/V head 对应的多个 Query Head。该路径不需要展开 K/V head，也不需要 page table 查询或 prefix/suffix 中间拼接。parent index 更新时，只重排较短的 suffix K/V、历史 Token 和累计分数，公共 prompt K/V 始终保持不变。

Shared-prefix 布局保留每条 beam 对完整 prompt 的 attention 计算，只改变 K/V 的物理组织和访问路径。收益来自减少 prompt K/V 副本、拼接 Tensor、分页索引和相关数据搬运。

项目曾评估 FlashInfer 的共享 page table Paged Decode 路径，该候选在当时的对照中使完整 DAG 吞吐提升约 3%，但它与 FlashAttention 路径在集成至 AOTI 编译流程后均存在稳定性问题，因此未被采用。

3.3 Beam 候选计算与状态更新

固定 Beam Search 沿用原有的两级候选选择规则：每一步先处理 W × V 个词表分数，再从各 beam 的局部候选中选出全局候选。系统保持候选集合和累计分数语义不变，将候选选择、精度转换和状态重排改写为固定 Shape 的 Tensor 数据流，并且只搬运下一步真正保留的状态。

设词表大小为 V，beam 宽度为 W。完成首步候选初始化后，每个 decode step 会生成 [W， V] 的 logits。系统先在每条 beam 内选出 2W 个局部候选，再将这些候选与历史累计分数相加，最后从 W × 2W 个扩展中选出全局候选：

BF16 logits [W, V]
  -> 每条 beam 选出 2W 个 token ID
  -> 从 FP32 log-probability 中读取对应分数 [W, 2W]
  -> 加上各 beam 的历史累计分数
  -> 展平为 W × 2W 个候选
  -> 选出全局候选及其 parent index
  -> 仅为下一轮 active beam 重排 token、分数和 suffix K/V

中间步骤保留 2W 个全局候选，是为了同时接收已经生成 stop token 的完成序列，并从其余候选中继续选出 W 条 active beam。局部裁剪不会改变这组全局候选：任意一条 beam 排名在本 beam 第 2W 名之后的 Token，都不可能进入全局前 2W。因此，全局候选合并处理的数据量从 W × V 降为 W × 2W；当词表远大于 beam 宽度时，这一差异十分明显。裁剪边界存在同分候选时，具体 Token 和顺序由冻结的 Top-K 实现决定；业务语义只要求分数等价及相同实现重复执行结果一致，不依赖同分候选的固定顺序。

候选 ID 和候选分数采用不同的数据路径。log-softmax 对同一行 logits 保持严格单调，因此 Token ID 可以直接在 BF16 logits 上通过 Top-K 确定；候选分数则由完整词表上的 FP32 log-softmax 计算，再按照入选 ID 读取。这样既保留累计概率所需的 FP32 精度，也避免 Top-K 再扫描一份 FP32 词表 Tensor。

全局候选展平后，一个索引即可同时确定来源 beam 和该 beam 内的候选位置。来源 beam 被记录为 parent index，下一步直接用它选择对应的历史 Token、累计分数和 suffix K/V。已经淘汰的候选不再复制搜索状态，公共 prompt K/V 也不参与重排。

上述候选裁剪、分数合并、parent index 计算和状态重排均位于固定 Beam Search 的 AOTI 节点内部。每个 decode step 只执行定长 Tensor 操作，不返回在线 Runtime 创建候选对象或重新组织请求。项目也评估过专用 GPU Top-K 实现，但完整 DAG 没有获得稳定的额外收益，最终保留 Torch Top-K，并将优化集中在候选数据流和整体编译上。

3.4 密集矩阵计算的选择性 FP8

代表模型的大部分矩阵 FLOPs 集中在 MLP、其他线性层和 LM head。系统优先将这些计算密集且能够形成端到端收益的路径转换为 FP8，同时在 softmax、候选排序、累计分数和最终业务分值等敏感位置保留 FP32 中间计算。

以 MLP 为例，内部数据路径为：

BF16 activation
  -> per-token dynamic E4M3 quantization
  -> FP8 Gate/Up GEMM
  -> FP32 SiLU(Gate) × Up
  -> per-token dynamic E4M3 quantization
  -> FP8 Down GEMM
  -> BF16 output

activation 使用 per-token 动态 scale，权重在离线阶段转换为 E4M3，并保存 per-output-channel 的 FP32 scale。节点之间仍传递 BF16 Tensor，使低精度计算只局限在已经通过验证的矩阵路径内。

Gate/Up projection 通过一次 FP8 scaled matmul 产生中间结果。随后的 Triton kernel 以每个 token 对应的一行为处理单位，在一次遍历中完成 FP32 SiLU、逐元素乘法、amax reduction、scale 计算和 E4M3 重新量化，避免生成完整的 BF16 SwiGLU 中间 Tensor。Down projection 直接读取量化后的 activation 和 per-token scale，再通过第二次 FP8 scaled matmul 返回 BF16 输出。

动态量化、scale 计算和格式转换本身也会占用时间，较小或计算占比较低的 linear 无法稳定获得收益。长 prompt 模型最终只对 MLP 使用 FP8；短 prompt 模型的 LM head 计算占比更高，在通过数值和业务验收后也纳入 FP8。以 Prefill-Only 模型为例，MLP selective FP8 相对全 BF16 路径使完整 DAG 吞吐提升约 24%。

attention 点积累积和 online softmax 状态、log-softmax reduction、动态量化 scale、Beam 累积分数以及最终业务敏感分值继续保留 FP32 中间计算。这些精度保护策略并非完全通用。不同模型需要分别确定 FP8 覆盖范围，kernel 和分块配置也需要针对目标 GPU 固化；直接沿用其他模型或卡型的配置，可能同时损害业务效果和性能。

3.5 CPU 文本处理与结果编码

在小模型和短输出负载中，tokenizer、字符串处理和结果编码难以被 GPU 计算摊薄，优化前已经成为完整请求时延中不可忽略的组成部分。这些固定执行且数据规模有界的处理统一由 C++ CPU 节点完成。

业务 tokenizer 在基础词表之外增加了一批需要优先识别的 added token。原有实现会对这些 Token 逐项执行字符串查找；当前实现把 Token 的 UTF-8 字节组织成 byte trie，即按公共字节前缀建立的树形索引，使输入可以在一次扫描中完成匹配。匹配仍遵循“优先选择最靠左的起点，同一起点选择最长 token”的既有语义。

服务首先把一个请求中的多条字符串转换为一段连续 UTF-8 字节和每条字符串的长度，CPU 节点据此确定各条文本的边界。文本规范化和 tokenizer 随后直接写入请求上下文中预分配的 token buffer，并同时生成 packed attention 所需的 sequence boundary，避免为每条文本反复创建字符串对象和临时数组。

string input
  -> contiguous UTF-8 payload + lengths
  -> normalize / tokenizer
  -> packed token buffer + sequence boundary
  -> GPU model

结果侧同样使用预分配的连续 buffer。CPU 节点一次解码同一请求中的全部 Beam 候选，并把 Token、Score 和 length 直接写入预分配的 UTF-8 JSON buffer。buffer 的物理容量按最大输出预先建立，实际 length 标记本次请求写入的有效字节数；在线服务据此构造最终 RPC response。

Beam token / score Tensor
  -> 同一请求内批量 decode
  -> UTF-8 JSON payload + lengths
  -> RPC response

这条路径减少了请求热路径中的对象创建、动态内存分配和格式转换。byte trie 与预分配 tokenizer 将代表 prompt 集合上的文本处理由毫秒级压缩到十微秒级。

04 完整链路的验证与性能结果

系统验证沿算子、AOTI 节点、完整 DAG 和在线服务逐层展开。正确性测试确认各层实现保持相同的模型与业务语义，性能测试则以完整 RPC 的 QPS、平均时延和 P99 时延选择单卡容量点，再用分层 A/B 和有效 MFU 解释主要收益与剩余瓶颈。

4.1 测试环境与容量口径

性能评估在业务常用的相近算力档位单卡上完成，后续结果统一按这一档位的单卡容量呈现。每个模型均针对实际部署环境独立构建节点产物，并选择对应的 kernel、精度策略和执行并发。混合精度 MFU 按部署 GPU 的 dense 理论峰值计算，BF16 和 FP8 峰值分别取约 150 TFLOPS 和 300 TFLOPS。

容量测试采用固定在途请求数的 closed-loop 方式。每个并发档位始终保持相同数量的完整请求正在等待或执行，一个请求完成后立即发送下一个，中间不加入客户端等待时间。QPS 统计每秒完成的完整 RPC 数量，端到端时延从请求发出持续到结果返回，P99 表示 99% 的请求不超过该时延。逐档增加并发可以得到单卡持续处理能力和时延开始快速增长的拐点。

单卡容量取同时满足平均端到端时延低于 20 ms、P99 低于 80 ms 的最高完成 QPS。服务入口再通过 deadline、超时退出和拒绝策略阻止过量请求继续占用后端资源。

4.2 分层正确性验证

执行链路一致性。在相同机器、相同输入和相同部署产物下，Python Artifact Runtime 与 C++ DAG Runtime 的输出 Tensor 保持逐字节一致。Server 使用同一 DAG Runtime 执行请求，协议层继续核对输出名称、类型、有效长度和最终业务结果。这一层验证用于确认节点调度、buffer 管理、数据搬运和协议转换没有改变部署产物的语义。

专用计算的数值验证。Packed GQA、shared-prefix attention、FP8 linear 和其他自定义 lowering 分别与 Torch 参考实现进行算子级和模型级数值对照。Beam Search 进一步逐 step 比较候选 Token、候选分数、parent index、累计分数、suffix K/V 重排和最终序列。

业务指标验收。低精度版本与原始离线模型使用相同的数据集、样本处理、评估代码和指标定义。优化实现不要求与原始 BF16 模型逐元素一致，但业务指标变化需要处于预先确定的验收范围内。最终部署产物通过了上述各层验证。

备注：【分层正确性验证】专用计算先与 Torch 参考实现进行数值对照；同一部署产物从 Python Artifact Runtime 到 C++ DAG Runtime 保持逐字节一致；低精度版本最终使用相同的离线评估流程完成业务指标验收。

4.3 时延约束下的单卡容量

下表给出三类代表负载在完整 RPC 链路上的单卡容量。三类模型的参数规模约为 0.5B 至 0.6B。每个 Prefill-Only 请求包含十余条样本，因此同时报告请求吞吐和样本吞吐；Beam Search 按一次完整搜索统计请求吞吐。

容量扫描表明，无约束峰值吞吐并不等于满足业务时延目标的容量。以短 prompt Beam Search 为例，在选定容量点上继续增加执行并发后，QPS 仅增加几个百分点，平均端到端时延却上升 30% 以上，并超过 20 ms 目标。

从并发曲线看，较低并发下增加请求上下文可以提高 CPU 处理、kernel launch、数据传输和 GPU 计算之间的执行重叠；进入饱和区间后，继续增加并发主要转化为排队、资源争用和单请求执行时间增长。线上配置因此选择满足时延约束的容量点，而不是无约束条件下的最高 QPS。

4.4 关键优化的分层 A/B

不同优化需要在对应层级进行 A/B，并最终回到完整请求确认收益。下表汇总 CPU 节点、AOTI 节点和完整 DAG 层级的主要结果。

分层 A/B 用于判断局部优化能否转化为完整请求收益，并确认优化后瓶颈所在的位置：

• Packed GQA 相对显式 Torch Packed Attention 的收益随 prompt 变长而扩大，说明变长 attention 实现是长文本路径的重要瓶颈；
• shared-prefix attention 通过减少 K/V 副本、拼接 Tensor、分页索引和数据搬运，使长 prompt Beam Search 的完整 DAG 吞吐提升约 20%；
• 选择性 FP8 在保留敏感计算精度的同时，使 Prefill-Only 的完整 DAG 吞吐提升约 24%；
• tokenizer 的文本处理由毫秒级压缩到十微秒级，CPU 热路径不再占用主要时延；
• 在固定 1,024-token 且不包含 RPC 的诊断负载下，完整 DAG 与 AOTI-only 的吞吐差异约为 1%，说明这一测试范围内的框架附加开销较小。

随着模型主体计算被压缩，profile 显示瓶颈逐步转移到 attention 状态布局、低精度转换、CPU 数据路径、同步和结果编码等环节，因此每次局部优化都需要回到完整请求时间线中复验。

4.5 混合精度有效 MFU

为估算逻辑矩阵计算相对于硬件理论能力的占用程度，本文定义“混合精度有效 MFU”。该指标将每个请求中不同精度的逻辑矩阵 FLOPs 分别除以对应的 dense 理论峰值，再按照相同请求口径下的完成 QPS 汇总。

设每个请求中的 BF16 和 FP8 逻辑矩阵计算量分别为 F_BF16 和 F_FP8，对应硬件理论峰值分别为 P_BF16 和 P_FP8，则：

$$\operatorname{Effective\ MFU} = QPS \left( \frac{F_{\text{BF16}}}{P_{\text{BF16}}} + \frac{F_{\text{FP8}}}{P_{\text{FP8}}} \right)$$

公式先估算每个请求中 BF16 与 FP8 逻辑矩阵计算在理论峰值下所需的等效时间，再乘以相同请求口径下的完成 QPS。Prefill-Only 的一个请求包含完整 batch，Beam Search 的一个请求包含一次完整搜索。结果表示单位 wall-clock 时间内完成的逻辑矩阵工作量相当于理论峰值算力的比例。

MFU 统计 linear、LM head 和 attention 的逻辑矩阵 FLOPs，FMA 按 2 FLOPs 计数。以下工作不进入分子：

• 物理 shape 对齐或分块产生的冗余计算；
• 动态量化和 scale 计算；
• 逐元素计算与非线性；
• softmax 和 log-softmax；
• Top-K 与 Beam 状态更新；
• tokenizer、结果编码和 DAG 调度；
• 数据传输和同步。

代表结果如下：

计算使用对应部署 GPU 的 BF16/FP8 dense 理论峰值，取约 150/300 TFLOPS。

该指标用于判断后续优化方向。Prefill-Only 模型的有效 MFU 已较高，继续只优化 GEMM 的端到端边际收益将受到限制；短 prompt Beam Search 则需要继续关注 Top-K、搜索状态和短 shape 计算。

05 适用范围与结论

5.1 框架与节点的复用边界

只要完整请求处理流程能够拆分为一组接口明确的节点，并由 DAG 表示节点之间的数据依赖，就可以接入本文所实现的这套推理框架。框架统一提供节点调度、Tensor 搬运、设备同步、资源预分配、请求上下文和并发管理，使新模型的开发与性能分析首先聚焦节点内部计算。

框架能力和专项优化具有不同的复用范围：

• 框架级能力：DAG Runtime、执行引擎、资源生命周期、并发管理和链路一致性检查，可由不同模型直接复用；
• 节点级语义：Packed Prefill、固定 Beam Search 和 shared-prefix attention，可由数据布局与状态结构相同的模型复用；
• 节点级实现：具体 Triton/CUDA kernel、FP8 覆盖范围、分块配置和执行并发，需要按照目标 shape、GPU 和软件环境重新选择。

模型结构和节点接口不变的新 checkpoint 还可以复用大部分构建描述，再完成参数映射、数值、业务指标和端到端性能验证。静态 DAG 本身不限于有界生成负载，本文的专项节点与性能结论则面向 Prefill-Only 和固定深度 Beam Search。

5.2 专项优化的适用边界

本文的专项优化主要面向控制流和状态容量稳定、单次生成较短的 SLM 负载。对于以下场景，通用 LLM serving 系统所提供的动态能力与需求更直接匹配：

• 开放式长文本生成；
• decode 长度高度动态；
• sequence 持续进入和退出；
• 强依赖 continuous batching；
• 跨请求公共前缀较长且命中率较高；
• KV 状态规模较大，需要动态分页、淘汰或复杂内存复用。

在这些场景中，vLLM、SGLang 等系统提供的 continuous batching、paged KV cache、prefix cache 和动态请求管理更匹配负载需求。当前部署采用单个请求不跨卡、每张 GPU 部署完整模型副本的方式。

5.3 结论

搜索推荐中的部分 SLM 保留 Decoder-only Transformer 和 next-token prediction 结构，但在线执行只包含一次 prefill 或固定次数 decode。请求规模、Beam 宽度、生成深度和状态容量的上界均能在部署前确定，因此模型构建、资源规划和在线执行可以围绕完整业务请求重新组织。

系统使用静态 DAG 表示完整请求流程，以 CPU 自定义节点处理文本和结果，以 AOTI 节点封装模型计算与固定搜索过程。DAG Runtime 负责节点调度、Tensor 搬运和请求资源，节点内部则分别应用 Packed Prefill、shared-prefix K/V、选择性 FP8 以及候选与状态更新优化。这种分层将通用在线执行能力与模型专项优化解耦，也使正确性和性能能够逐层验证。

在本文覆盖的模型、输入分布和单卡环境中，Prefill-Only 达到约 100 request QPS，即约 1，500 sample/s；短 prompt 和长 prompt Beam Search 分别达到约 300 和 120 request QPS。三类负载的平均端到端时延均低于 20 ms，P99 约为 70 ms，满足 80 ms 的线上要求。相同部署产物从 Python Artifact Runtime 到 C++ DAG Runtime 保持逐字节一致，低精度路径与专用算子的业务指标变化也处于预设验收范围内。Prefill-Only 与短 prompt Beam Search 代表负载的混合精度有效 MFU 分别约为 67% 和 41%。

这组结果表明，推理系统的设计应由实际执行边界决定。对于有界生成负载，将固定结构前移到构建阶段、按完整请求组织在线执行，并把专项优化限制在接口明确的节点内部，可以提高计算效率和时延约束下的单卡容量。

美团在 MTGR 基础上提出统一推荐基座大模型 MTFM，首次实现外卖多个主要业务的统一精排模型。围绕规模可扩展性、场景可延展性与架构高效性三大挑战，MTFM以异构 Tokenizer 与动态掩码实现多场景特征免对齐，通过混合注意力与 Target Scale-Up 提升模型 Scaling 能力，借鉴 LLM 优化实践提升深层网络训练效果，并以 User-Level 训练范式与定制算子保证系统开销可控。美团外卖多个业务订单量提升 2.06%~6.68% 不等，推理成本降低 24%，相关工作已被 KDD 2026 收录。

1. 引言

我们去年提出了 MTGR^[1] —— 一种新的生成式精排框架，在美团外卖推荐场景验证了 Scaling Law 的有效性，并取得显著业务收益。然而，推荐领域的 Scaling Law 探索往往局限于单场景内部，模型被限制在单场景孤岛中，跨场景的数据、算力和架构无法充分复用。在美团这一问题尤为突出，推荐覆盖外卖首页、拼好饭等多个业务场景，各场景长期独立建模。与此同时，大语言模型（LLM）已验证一条清晰路径：基座模型（Foundation Model）足以统一处理编程、数学、写作等多领域任务，也可以将文本、图像、语音等异构信息表示为 Token 序列并进行端到端学习，展现出了强泛化性与可扩展性。因此，我们认为美团推荐的下一个阶段关键在于打通跨场景的异构性，充分利用多场景数据提升 Scaling Law 的上限，即建设统一推荐基座大模型。

推荐基座大模型主要面临三个核心挑战：规模可扩展性（Scalability）、场景可延展性（Extensibility）和架构高效性（Efficiency）。规模可扩展性要求模型在参数规模、数据量扩大时，效果能够稳定、可预期地提升；场景可延展性要求模型能够低成本适配已有场景或接入新场景；架构高效性要求模型在处理多场景的海量数据时，训推仍保持可接受成本开销。

为解决上述挑战，我们在 MTGR 的基础上，提出美团统一推荐基座大模型 MTFM（Meituan Foundation Model for Recommendation）。MTFM 使用类 Transformer 骨干进行端到端建模，提出 Target Token Scale-Up 提升模型能力，借鉴 LLM 实践优化深层网络训练策略；通过异构 Tokenizer 替代固定特征模板，支持多场景异构特征免显式对齐；提出 Self-Attention 和 Target Attention 堆叠的混合架构，结合 User-Level 样本和 GPU 算子优化提升训推效率。

MTFM 首次实现外卖多个主要业务的统一精排模型并在各核心场景完成全量，相关工作于 2026 年 5 月被 KDD 2026 接收^[2]。

• 场景收益：全面超越 MTGR 或 DLRM 基线模型，各业务离线指标大幅度提升，在线效果最显著的业务线订单增长超过6%；
• Scaling：在模型参数量、序列长度上展现了稳健的 Scaling 能力，为后续落地更大规模基座打下基础；
• 资源效率：单样本计算量达到 192 GFLOPs，对比传统 DLRM 提升数百倍，在线推理成本降低 24.0%。

2. 工业界探索

多场景建模

核心目标是在共享跨业务用户兴趣表达的同时，兼顾不同业务间的分布差异与个性化需求。多场景建模主要沿着两条方向演进。第一类方法遵循“先同构、再解耦”的范式，通过将模型参数拆分为域共享与域特定部分。例如，STAR^[3] 采用星型拓扑结构，将领域参数锚定在共享中心参数周围；M3OE^[4] 进一步引入多个 MoE 模块，在通用、领域和任务层面学习层次化用户偏好；MLoRA^[5] 则通过轻量化 LoRA 适配不同领域，提高参数效率。第二类方法开始探索多场景基座模型方向，通常采用“基座模型 + 专家模型”的架构，例如 ExFM^[6] 将超大规模模型知识蒸馏到场景专家模型，LFM4Ads^[7] 通过多粒度机制在特征与任务间迁移表示，这类方法非端到端建模、可能限制模型能力上限。

具备 Scaling 能力的排序模型

推荐模型 Scaling 范式主要沿着三条方向演进。第一类方法聚焦 DLRM 骨干扩容，通过扩展特定可堆叠模块实现扩展，例如 RankMixer^[8]、TokenMixer-Large^[9]，通过 Token Mixing、Per-Token FFN 与 Sparse-MoE 增强特征交互能力。第二类方法将输入特征切分成独立 Token，采用 Transformer Backbone 进行端到端统一建模。具体而言， HSTU^[10] 将推荐重新定义为序列转导任务，采用高性能架构捕获用户行为模式；MTGR 在此基础上引入交叉特征与双向注意力机制，以进一步丰富特征交互；OneTrans^[11] 通过金字塔式的截断策略提升训推效率。第三类方法探索生成式自回归推荐，例如 OneRec^[12]，通过 NTP 将推荐改写为序列生成任务，尝试以统一生成框架替代传统“召回-排序”架构。

3. MTFM 模型

MTFM 的模型架构如图 1 所示，支持多场景统一建模，面向基座模型的三个核心属性进行创新改造：

• 规模可扩展性：整体采用 Transformer 类 Block 堆叠作为骨干网络，并针对性进行 Target Token Scale-Up 设计，以支持用户序列与 Target 信息的 Scalability。
• 场景可延展性：将多域输入抽象为统一的异构 Token 序列，让模型无需人工对齐特征模板、无损地提取各场景的异构信号，并通过动态 Mask 机制对跨场景信息与时间因果关系进行可见性控制，避免信息泄漏。
• 架构高效性：受 LLM 混合架构启发，MTFM 引入混合注意力机制（Hybrid Target Attention），避免了 Self-Attention 平方复杂度的性能瓶颈，在少数关键层使用 Self-Attention 以维持全局依赖捕捉，主要堆叠 Target Attention 将算力分配给更加重要的 Target-Aware 计算。

3.1 异构 Tokenizer

MTFM 将多业务输入统一组织为三类 Token：H-Token、R-Token 与 T-Token。其中，H-Token 表示用户跨业务历史行为序列，包括商家统一序列与商品统一序列，用于建模用户长期兴趣；R-Token 表示用户近实时行为序列，包括点击、加购等行为，按行为时间戳统一排序；T-Token 表示待预估目标（商家、商品或券包），包含上下文特征、候选侧特征及交叉特征。其中，H-Token、R-Token 全业务共享，T-Token 各业务独立维护。

模型采用统一 Token 化范式：针对 H-Token、R-Token，不同序列使用序列独立 Tokenizer 完成编码；针对 T-Token，将上下文特征与候选侧特征进行拼接，再通过业务独立 Tokenizer 编码。最终，所有 H-Token、R-Token 与 T-Token 按顺序堆叠，形成统一的 Token 序列输入共享 Attention Backbone，在无需显式对齐跨业务特征体系的情况下，实现多场景统一建模。

3.2 动态掩码机制

为防止跨场景、时间的信息泄露，MTFM 进一步扩展 MTGR 的掩码策略。在下图 Mask 矩阵中，每一行代表当前 Token 在注意力计算时能看到序列中的哪些 Token，每一列代表当前 Token 能被哪些 Token 看到。对 H-Token、R-Token、T-Token 三类 Token，可见性如下：

• H（History）-Token：可被所有 Token 看到，历史行为是全场景共享的用户上下文。
• R（Realtime）-Token：按时间因果可见，实时序列内部为标准 Causal Mask，且每个 Target Token 只能看到发生在该次曝光之前的实时行为。
• T（Target）-Token：只能被自身看到，同一请求内的不同候选之间互不感知。

3.3 高效注意力架构

3.3.1 注意力架构 V1：混合注意力架构

MTGR 采用多层 Full Attention 进行全序列建模，其计算复杂度随序列长度呈平方增长。统一模型包含多条千级长度序列，直接堆叠 Full Attention 会导致训练与推理成本难以接受。另一方面，推荐任务的预估结果高度依赖 Target 侧特征，已有工作（如 STCA^[13]、OneRec V2 ^[14]LazyDecoder）表明，Target Attention 能够以更低成本完成有效的信息提取。

基于此，MTFM V1 借鉴 LLM 中的混合 Attention 架构（Qwen3-Next^[15]、MiMo-V2-Flash^[16]），交错堆叠 Full Attention 与 Target Attention 层，以降低长序列建模复杂度。具体而言，Full Attention 层负责全序列信息聚合；Target Attention 层中，T-Token 仅以全序列 Token 为 Key/Value 执行注意力提取，不再参与全序列自注意力计算，从而显著降低计算量。在此基础上，进一步引入 GQA（Grouped-Query Attention），降低 Attention 的开销。

最终模型采用 Target:Full=3:1 的混合结构，共 16 层（4 个 Block，每个 Block 包含 1 层 Full Attention 与 3 层 Target Attention）。消融实验表明，该配置在各任务 GAUC 上均取得最优效果；同时由于显存占用下降，batch size 可扩大 1.7 倍，样本吞吐达到全 Full Attention 架构的 2.9 倍。

3.3.2 注意力架构 V2：Target Scale-Up

混合架构以更低成本取得了与全 Full Attention 相当的效果，说明将更多计算集中在 Target 侧是一条值得进一步扩展的方向。而在 MTFM 多场景长序列中，单个 Target Token 包含的特征数量，远多于单个 User Token 的特征数量，但是在 Token 化阶段 Target 和 User 侧都被视为同一维度的单个 Token，这会造成 Target 信息的过度压缩，在信息密度分配上是不合理的。因此在 MTFM V1 的混合架构基础上，MTFM V2（模型结构图见图 1）进一步对 Target Attention Layer 采用 Target Scale-Up 的方式来增大模型规模，以进一步实现 Scaling-Up。

具体方案：

1、Target Token Embedding 构造：采用 AutoSplit^[17]，每个 Target 的 User & Context & Item 特征经过一层 Linear 映射到 4 个 Token Embeddings。

2、Per-token Q Projection & FFN：在 Target Attention 层，每个 Target 的 4 个 Token 经过不同的 Q Projection Matrix 和 SwiGLU FFN。

3、Self-Attention & Target Attention 参数分离：位于同一层的 Self-Attention 和 Target Attention 有独立的 QKV Projection Matrix、 SwiGLU FFN 参数。

4、Target Token Mixing：拆分后的 Target Token 各自独立与用户序列进行 Cross Attention，经过独立的 FFN，如果不进行交叉，4 个 Target Token 在 Mean Pooling 前完全没有交互，会导致各 Token 在相同 KV 下趋向学到冗余相似的表征（表征坍缩）。因此采用 RankMixer^[18] 中的 Mixing 模块，以零参数低计算量对 Target Token 进行交叉，促使各 Token 学习不同的表征。

3.4 多场景统一训练

为了实现多业务间的知识共享与差异建模，采用“共享基座 + 业务解耦”的多任务架构。具体而言，经过混合 Attention 聚合后的各业务 T-Token 表征，被送入 MMoE 层进行跨业务信息提取，再接入业务独立的任务塔，完成 CTR、CTCVR 等目标预估。其中，长序列兴趣建模能力主要沉淀在共享 Attention Backbone 中，而不同业务的分布差异则由 MMoE 门控与任务塔参数承担。

在训练与部署层面，MTFM 采用“一图多业务”的设计范式。训练阶段，以用户为粒度聚合同一用户当日全场景曝光 Target，并共享序列侧 Attention 计算，使多个业务能够复用同一份用户兴趣表征，大幅降低长序列训练成本。线上部署阶段，各业务导出图保留共享序列基座与独享 Task Tower，使在线计算限定在当前业务相关组件上，减少无效 FLOPs 消耗，在统一建模的同时控制推理成本，实现“统一训练、多业务部署”。

实验表明，跨场景的信息迁移可有效缓解数据稀疏问题。具体体现在小流量业务显著提升 0.60~0.93pp不等，中流量业务提升 0.25pp，大流量业务持平微正。

4. 统一样本与行为序列

传统 DLRM 模型以曝光（PV）为粒度构建样本，多场景样本通过固定模板强制对齐，存在序列重复存储、计算的问题，资源利用率低。MTGR 将样本组织成单用户（UV）粒度，MTFM 进一步升级为外卖全业务的统一用户粒度样本，同一用户的外卖多业务曝光聚合成 1 条样本，共享模型中最耗费算力的长序列 Attention 部分计算。

4.1 统一 User-Level 样本

MTFM 训练时按 User-Level 聚合样本、推理时按各业务 Request-Level 聚合候选，训练阶段算力复用经济性收益进一步放大。特征组织上，由于各业务的供给类型、展现形态不同，特征 Schema 无法直接对齐。相应地，各业务首先在内部按 User-Level 聚合业务独立特征，再与共享的用户序列以及其他业务的样本进行合并。模型训、推时多 Target 共享长序列计算，实现了算力资源的高效复用。

4.2 统一行为序列

过往各业务独立维护场域内的行为序列，存在数据链路和 SideInfo 体系重复建设、跨场景行为信息缺失等问题，这一问题在数据稀疏的小流量业务中尤为严重。为此，MTFM 将全场景行为统一为商家、商品长序列，聚合外卖多场景的点击、加购、完单行为，构建覆盖质、价、品、情景化信息的通用 SideInfo。受益于 4.1 节的 User-Level 训练范式升级，整体资源消耗在可控范围内。各业务均使用全场景行为信号建模，提升了用户兴趣刻画的全面性，消融实验同步显示外卖多个业务均取得显著提升。

5. 训练策略

多业务联合训练叠加网络层数加深，使模型优化难度显著提升。项目初期发现多组随机重复实验的离线指标波动超过 0.4pp，严重影响迭代基准的置信度。通过监控中间层激活值、参数值、梯度值等指标，完善训练动态追踪，发现离线效果与部分层的梯度大小具有强相关性（图4，Run A、B、C为模型随机重复实验），基于此判断存在局部梯度衰减、参数退化的问题。为此从初始化、优化器两个方向系统性解决。另外针对多业务联合训练范式下样本稀疏引发的梯度噪声增大、无效梯度等问题，我们改进损失函数，完善优化器逻辑、并引入梯度累积。

5.1 深层网络训练稳定性提升

深度感知的初始化策略：MTFM 的骨干网络是带有残差连接的多层 HSTU，残差结构使得网络输出的 std 随深度累积不断变大，训练初期存在激活值过大导致非线性激活层饱和的风险。借鉴 GPT-2 针对多层 Transformer 的初始化策略，在初始化 HSTU 每个 Block 的输出投影层时按深度缩放标准差：

$$W_{o_{proj}} \sim \mathcal{N}(0,\frac{0.02}{\sqrt{L}})$$

其中 L = 16 为本次推全模型 HSTU 总层数，其他线性层的 std 仍设置为常数 0.02——使残差分支累积后的总方差保持在相对稳定的量级，改善深层模型训练初期的梯度稳定性。

优化器升级：将部分 Dense 参数由 AdamW 切换为 Muon — 一种主要面向二维矩阵参数、近年来在 LLM 领域得到广泛应用的优化器。Muon 使用 Newton-Schulz 迭代正交化更新梯度矩阵，以改善更新方向和训练效率。实践中借鉴了月之暗面的最新实践：增加 Weight Decay、Update RMS Scale，以提升训练的稳定性。我们针对 Muon 的覆盖范围进行探索，发现仅将 Muon 作用于 HSTU 的 UQKV 投影与 Output Projection，可以在速度与效果之间取得最佳平衡。

整体叠加两个优化策略，5~10 组随机实验的 train AUC 波动幅度从 0.4pp 降至 0.1pp，离线实验的稳定性和可复现性得到明显改善。

5.2 多业务联合训练优化

动态归一化：初期的联合损失采用各业务损失分别归一化后相加的形式：

$$L = \sum_{s} \frac{1}{|B_s|} \sum_{i \in B_s} \mathrm{loss}_i$$

其中 $B_s$ 为 batch 内业务的样本集合。由于小流量业务的有效 batch size 小，基于其归一化损失得到的梯度存在较大噪声，既影响自身个性化参数（如 MMoE、任务塔）的收敛，也通过共享参数间接影响其他业务。为此将损失改为按 batch 内各业务 PV 占比动态加权，该形式可化简为等价的全局归一化——不区分业务、对 batch 内全部样本统一归一，修改后的 loss 形式如下：

$$L=\frac{\sum_{s}\sum_{0\leq i \leq |B_s|-1} loss_{s,i}}{\sum_{s'}|B_{s'}|}$$

稀疏更新改进：多业务联合建模的范式下，稀疏样本带来了一个新的问题：部分 batch 内不含小流量业务的 Target，其 Tokenizer、MMoE 专家与任务塔在该步没有梯度，但这些参数仍在被持续衰减。为此在优化器的计算逻辑中跳过零梯度 Weight Decay，并将零梯度检测合并为单次批量同步、非零参数更新批量向量化以减少 kernel launch 次数提升训练吞吐。此外，为提升小业务的训练稳定性，引入步长为2的梯度累积，降低优化器 step 频率提升训练速度。

6. 训推性能

MTFM 的单样本计算量较 DLRM 模型增长数百倍，系统性的性能优化是基座大模型成功落地的前提。为此，从训练、推理两部分，解决模型计算量和存储量激增带来的诸多性能挑战。

6.1 训练性能

• FA 镜像与 Mask Kernel 优化：HSTU 动态 Attention 在 2k 长序列下，逐样本构造动态 Mask 因不连续访存与频繁 kernel launch 耗时高达 22ms。MTFM 基于 Flash-Attention V2 重构：将多维 Mask 预处理好一维 jagged mask 存入 Share Memory 供轻量读取；Mask 构造从 for-loop 改写为 Triton Kernel，降至 1ms；扩展 FA2 接口支持 Full/Target Attention、动态 Mask 读取与 SiLU 融合。相比 NVIDIA^[19] 实现，优化后前向加速 128%、反向加速 152%。
• GLN Kernel 融合：MTFM 序列由终身行为、实时行为、候选 Target 等多种异构 Token 拼接构成，各类型使用独立的 LayerNorm 参数。传统实现按 group 循环执行，多次 kernel launch 和冗余 global memory 读写，成为长序列训练中的瓶颈。
• 优化方案：前向基于 Triton 重构 Group LayerNorm（GLN）算子。将多组参数统一组织为 [G, D] 大矩阵，通过 seq_group_id_mask 为每个 Token 动态索引对应 group，单次 kernel 完成全部 Token 归一化；同时实现 GLN-ADD 与 GLN-MUL 融合算子，避免高频的中间结果回写。反向梯度改为分块归约：各处理单元独立累积局部梯度后统一汇总，避免多 Token 并发累加同一份共享参数带来的串行排队。在 2k 长序列下，GLN 的内存带宽利用率从 30% 提升至 60% 以上，整体相对原生实现提速超过 30%。
• Muon 性能优化：针对原生 Muon 优化器中 Newton-Schulz（NS）正交化逐 2D 参数串行执行、GPU 利用率低的问题，首先借鉴了 flash-muon^[20] （利用 X@Xᵀ 对称性仅计算上三角，FLOP 减半）。该做法在大矩阵场景下收益明显，但 MTFM 中矩阵普遍偏小，反而因额外 Triton 启动开销拖慢性能。因此采用针对小矩阵的批处理策略：将同一优化步骤中形状相同的权重梯度堆叠为 (B, M, N) 的批量张量，整组 NS 批量并行执行。批量化后，整个 NS 阶段 kernel launch 收敛至数十次，阶段加速 241%，端到端训练吞吐提升 19%。
• 消除阻塞点：随着特征规模和序列长度增长，训练瓶颈正从 Attention 计算转向 Host/Device 协同效率。典型阻塞点包括 torch.unique、TorchRec wait() 同步、HashTable 优化器 step，以及业务代码如 .item() 引发的 D2H 同步。
• 优化方案：核心思路是将“串行等待”转化为“并行重叠”。① 重构 TorchRec 数据分发和 HashTable 优化器链路，通过异步数据传输与计算重叠，削减通信、回传和更新中的闲置间隙，结合去重与截断优化降低冗余计算；② 将原先按 embedding 维度拆分的多个 HashtableCollection 融合为单个统一集合，所有特征一次性查表，消除多实例间的调度与同步开销；③ 基于 AI Agent Infra，将 repeat_interleave 等存在 D2H 阻塞的原生算子改写为纯 GPU 实现，频繁访问的 CPU 常量迁移为 GPU Tensor 预计算。最终，MTFM 训练流水线整体训练速度提升约 15%。
• 特征精简：多业务统一后特征规模达 1.3K+，利用 Agent Auto Research 分析与分组搜索验证，删减近 500 个特征且 GAUC 无损，释放显存以增大 batch size，训练吞吐 +6%，线上特征处理耗时同步降低。

6.2 推理性能

• 查表合并：多个 Hashtable 查询存在同表重复加载问题，导致显存碎片严重、多表查询串行化。将多个查询共享同一张表后，显存占用由 22GB 降至 5.9GB。
• Attention Maskfunc 规则跳算：在 MTFM 的 HSTU 结构中，进入 Attention 的序列可抽象为 User 和 Item 两部分，两者的 Mask 逻辑不同，对此分别做了针对性优化：
  • User 侧使用自定义 Mask（区别于 LLM 的 Causal Mask），在早期实现中，Mask 在 Attention 中以 element-wise 乘作用在 Q * K^T 的矩阵结果，在多场景长序列中 Mask 含大量零值，计算效率极低。对此优化方案是预扫描 Mask 生成有效计算索引，在 Attention 计算过程中仅对存在有效 Key 的 Block 执行计算，跳过全零块，在长序列下单算子延迟降低约 50%。
  • Item 侧的 Mask 逻辑为 Item 可见 User，User 不可见 Item，即 User→Item 方向的 Attention 计算完全无效。利用这一可见性先验规则直接跳过该方向计算，在 2000 User + 200 Item 配置下延迟降低 13%。
• GLN 自定义算子：原生 GLN 按 index 取数→归一化→写回，因 index 不连续产生大量乱序访问和显存拷贝。改为基于 Mask 的 GLN，直接通过掩码定位有效位置，避免重排开销；结合 block/warp 规约与向量化读取加速。吞吐提升 38%。
• 推理图精简：识别并融合冗余算子，合并连续的 Cast 转换，减少数值格式转换引发的额外内存搬运开销、降低访存压力，并重排计算顺序提升数据局部性，吞吐提升 20%。

7. 模型效果

7.1 Scaling Law 验证

MTFM 在网络层数、Token Dim、序列长度三个维度上表现出了稳健的 Scaling 能力（图5~7）：

• 网络层数（图5）：随着模型层数增加，各业务离线效果稳步增长，离线指标与网络层数高度相关；
• Token Dim（图6）：随着 Token 维度增大，序列 SideInfo 中的丰富语义得以充分表达，同时能建模 Q、K 之间更丰富的交互关系，在 192~768 范围内观察到效果显著提升；
• 序列长度（图7）：在 400~2000 范围内序列长度 Scaling 现象明显，随着入图序列长度增长，模型能够建模更长期的用户偏好，模型离线 GAUC 稳定提升。

7.2 各业务离线效果

MTFM 统一模型离线 GAUC 全面超越各场景基线，并且在 Target Token Scale-Up 上展现了更好的扩展效果。

7.3 各业务线上效果

目前，MTFM V1 在美团外卖多个业务完成全量，核心订单指标提升显著，在线效果最显著的业务线订单增长超过6%，同时这也是最近两年多个核心业务推荐场景单次优化的最大收益。

8. 总结与展望

MTFM 是一个真正意义上实现多场景特征免对齐的推荐基座大模型架构，具备规模可扩展性（Scalability）、场景可延展性（Extensibility）和架构高效性（Efficiency）这三个关键特质。具体以类 Transformer 骨干网络为基础，通过 Target Token Scale-Up 提升模型能力，借鉴 LLM 优化实践提升训练效果；设计异构 Tokenizer 和动态掩码机制支持多场景端到端统一建模；通过混合注意力、多场景 User-Level 训练、高效 GPU 定制算子等提升训推效率。首次实现外卖多场景统一精排模型，取得显著的离线 GAUC 与在线 A/B 效果提升，展现了良好的规模效应与算力经济性。在未来，我们将和各团队紧密合作，充分吸纳 LLM 与推荐领域业界最新进展，不断提升模型能力和 Infra 能力，继续拓展基座模型在推荐场景的能力边界。主要方向如下：

• Scaling 与 Infra 协同：算法&工程 Co-Design，实现更高效的 Infra，设计高 Scaling ROI 的模型结构平衡计算量与参数量，实现模型参数量 1-2 个数量级的提升，进一步验证模型参数、序列长度的 Scaling Law。
• 基座模型场景延伸：将 MTFM 推广到更多业务场景，通过 Co-Train、蒸馏等方式实现 MTFM-Lite，更低成本为各场景带来基座模型红利。

参考文献

• [1] MTGR：Han R, Yin B, Chen S, et al. Mtgr: Industrial-scale generative recommendation framework in meituan[C]//Proceedings of the 34th ACM International Conference on Information and Knowledge Management. 2025: 5731-5738
• [2] KDD 2026：MTFM: A Scalable and Alignment-free Foundation Model for Industrial Recommendation in Meituan（https://dl.acm.org/doi/abs/10.1145/3770855.3818452）
• [3] STAR：Xiang-Rong Sheng, Liqin Zhao, Guorui Zhou, Xinyao Ding, Binding Dai, Qiang Luo, Siran Yang, Jingshan Lv, Chi Zhang, Hongbo Deng, et al. 2021. One model to serve all: Star topology adaptive recommender for multi-domain ctr prediction. In Proceedings of the 30th ACM International Conference on Information & Knowledge Management. 4104–4113.
• [4] M3OE：Zijian Zhang, Shuchang Liu, Jiaao Yu, Qingpeng Cai, Xiangyu Zhao, Chunxu Zhang, Ziru Liu, Qidong Liu, Hongwei Zhao, Lantao Hu, et al. 2024. M3oe: Multi-domain multi-task mixture-of experts recommendation framework. In Proceedings of the 47th International ACM SIGIR Conference on Research and Development in Information Retrieval. 893–902.
• [5] MLoRA：Zhiming Yang, Haining Gao, Dehong Gao, Luwei Yang, Libin Yang, Xiaoyan Cai, Wei Ning, and Guannan Zhang. 2024. Mlora: Multi-domain low-rank adaptive network for ctr prediction. In Proceedings of the 18th ACM Conference on Recommender Systems. 287–297.
• [6] ExFM：Ads Recommendation. 2025. External Large Foundation Model: How to Efficiently Serve Trillions of Parameters for Online Ads Recommendation. arXiv preprint arXiv:2502.17494 (2025).
• [7] LFM4Ads：Shangyu Zhang, Shijie Quan, Zhongren Wang, Junwei Pan, Tianqu Zhuang, Bo Fu, Yilong Sun, Jieying Lin, Jushuo Chen, Xiaotian Li, et al. 2025. Large Foundation Model for Ads Recommendation. arXiv preprint arXiv:2508.14948 (2025).
• [8] RankMixer：Zhu J, Fan Z, Zhu X, et al. Rankmixer: Scaling up ranking models in industrial recommenders[C]//Proceedings of the 34th ACM International Conference on Information and Knowledge Management. 2025: 6309-6316.
• [9] TokenMixer-Large：Jiang Y, Zhu J, Han X, et al. Tokenmixer-large: Scaling up large ranking models in industrial recommenders[C]//Proceedings of the 32nd ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2. 2026: 7489-7500.
• [10] HSTU：Zhai J, Liao L, Liu X, et al. Actions speak louder than words: Trillion-parameter sequential transducers for generative recommendations[J]. arXiv preprint arXiv:2402.17152, 2024.
• [11] OneTrans：https://arxiv.org/abs/2510.26104
• [12] OneRec：Zhou G, Deng J, Zhang J, et al. Onerec technical report[J]. arXiv preprint arXiv:2506.13695, 2025.
• [13] STCA：Guan, Lin, et al. "Make it long, keep it fast: End-to-end 10k-sequence modeling at billion scale on Douyin." Proceedings of the ACM Web Conference 2026. 2026.
• [14] OneRec V2：Zhou, Guorui, et al. "Onerec-v2 technical report, 2025." https://arxiv.org/abs/2508.20900 (2025).
• [15] Qwen3-Next：Team Qwen. "Qwen3-Next: Towards Ultimate Training & Inference Efficiency." https://qwen.ai/blog?id=qwen3-next (2025).
• [16] MiMo-V2-Flash：Xiao, Bangjun, et al. "Mimo-v2-flash technical report." arXiv:2601.02780 (2026).
• [17] AutoSplit：参考 OneTranshttps://arxiv.org/abs/2510.26104
• [18] RankMixer：https://arxiv.org/abs/2507.15551
• [19] NVIDIA 开源自定义 Mask：https://github.com/NVIDIA/recsys-examples/blob/main/corelib/hstu/README.md
• [20] Flash-Muon：https://github.com/nil0x9/flash-muon/blob/main/README.md

综述

搭一个 Agent 正在变得越来越容易

过去三年，有两条趋势在同时发生。

一是基座模型的能力持续进化，它带来的结果是对使用者的要求在往下降。早期要让模型稳定地按格式输出、正确地选中一个工具，需要反复打磨 Prompt、设计各种兜底。现在这些能力越来越多地由模型本身承担，长上下文、原生工具调用、更强的指令遵循和多步推理，把大量原本需要工程去补的地方补上了。

二是 Agent 框架的功能持续丰富。从早期需要自己实现规划、记忆、工具注册和状态管理，到现在框架和协议层把这些抽象成标准组件，接一个工具、加一个 Skill，工作量都在显著下降。

两条曲线叠加，结论很直接：搭建 Agent 门槛正在逐年降低。这带来的直接变化是 Agent 落地场景越来越多，越来越发散。

评测认知的稀缺

自 2022 年底 ChatGPT（基于 GPT-3.5）发布以来，市场上出现了一波又一波 Agent 项目。但是那些真正走过冷启动、完成灰度扩量、推到全量的项目数量屈指可数。这导致掌握 Agent 评测方法的人非常稀缺。

过去三年绝大部分 Agent 项目都死掉了。它们消失的原因有一些共性：

• 停在 Demo：演示效果很好，一接真实流量就发现覆盖不住，用户的问法、数据的脏乱、场景的边界远超预期，团队疲于打补丁，最后不了了之。
• 卡在扩量：小范围试用还行，一放量各种问题集中暴露。团队既说不清问题出在哪一层，也不敢大改，因为改完不知道会不会把原来对的地方弄坏，项目在原地反复摇摆。
• 说不清业务价值：模型换了几轮，Prompt 迭代了几十版，团队自己觉得变好了，但拿不出证据。到了要资源、要继续投入的时候，回答不了“项目到底带来了什么”，最终停止投入。

这三种死法看起来不同，追下去会发现共同点：团队缺少一套可靠的判断机制。不知道当前版本行不行，不知道问题出在哪一层，不知道改完是真的变好还是换了个地方出错，也不知道怎么向外证明这件事的价值。做决策靠的是感觉和个别案例，而感觉在复杂系统面前不可靠。

把两件事放在一起看，会得到一个略显割裂的图景：搭 Agent 的门槛在快速降低，把 Agent 做好的认知却仍十分稀缺。并且，有限的评测认知面对发散的场景，同样力不从心。做好一个 ChatBot 的经验，并不能无缝泛化到做一个长程 Agent 身上。为此，我们希望将团队两年来在众多业务方中打磨出的评测的认知，以体系化的形式分享给大家，希望能帮大家少走一些弯路。

这个系列博客想做什么

前不久，我们发布了一篇博客《Agent 评测漫谈》，介绍了评测的核心方法论，回答的是“评测是什么、为什么这么做”。文章发出后，我们收到不少的反馈，其中出现频率最高的一类是：方法论看了，但具体到自己的项目，还是不知道从哪下手。

为此，我们计划撰写《Agent 评测白皮书》系列博客，体系化地为大家讲解评测的落地指南 —— 先做什么后做什么，每一步的产出物长什么样，做到什么程度算达标，遇到常见的坑怎么处理。计划分四篇：

本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。如果你正在从零开始搭一个 Agent，或者手里的项目卡在某个阶段推不动，希望这几篇能提供一些可以直接用上的东西。

这里也需要强调一下：评测是一门实践科学，本系列给出的做法来自我们评测团队在美团多个业务的实践，它们在各自的场景里被验证有效，但迁移到新场景时仍然需要结合业务特点做调整。比起照搬步骤，更值得关注的是每个做法背后要解决的问题。理解了问题，做法自然可以因地制宜。

前言

第一篇《评测全览》目的在于让大家系统地了解评测的构成，我们用一套统一的语言对齐行业内尚在发散和纠缠的概念，用一套叙事逻辑打通冷启动、扩量和自进化。有了全览之后，大家可以以终为始，判断自己现在处在哪里、下一步补哪一块。完备的评测体系可以概括为四个模块、三种能力、两条 Loop、一套资产。

一、完备的评测体系是什么样子

1.1 回到原点：评测是 Agent 效果的“精密量具”

评测的核心目的是回答两个问题：Agent 好不好？到底哪里好、哪里不好？前者给出判断，后者指明方向。一套完备的评测体系必须同时回答这两个问题。

在《Agent 评测漫谈》一文中，我们认为评测是一套“精密量具”，这个类比其实包含两个隐喻：

• 量具要准（方差小才置信）：同一个样本，不同的人、不同的时间、人和机器，量出来的结果要一致。这对应博客方法论中的“人人一致、人机一致”。
• 量具需要能定期校准：业务扩量后用户画像变了、Agent 能力边界扩了、业务目标有变化了，原有的评测集和 Rubric 就会逐渐失去代表性。这对应评测体系自身的迭代能力。

第二点是评测贴近真实业务场景、消除独裁者偏差的关键手段，但却是最容易被忽略的。

1.2 两条相互咬合的 Loop

理想的评测体系是一套持续运转的系统。它由两条 Loop 构成，二者共享同一批线上真实样本，通过 Case 挖掘与归因这个枢纽相互咬合。

第一条：评测体系迭代 Loop（评测演进）

Agent 上线后，在线评测和在线监控开始持续产出异常信号。这些信号背后的线上真实样本，经过 Case 挖掘进入 Case 池，再经过归因判断问题性质。如果归因结论是“评测集没有覆盖这类问题”，那么这个样本就应该补充进评测集；如果归因结论是“评测标准判错了”，那么迭代评测是 Metrics 和 Rubric 本身。这条 Loop 让评测集从冷启动人工搭建逐步逼近真实用户的反馈，逐步消除前文博客中提到的独裁者偏差。

第二条：Agent 迭代 Loop（Agent 演进）

同样是这批线上真实样本，经过 Case 挖掘和归因之后，定位到 Agent 本身的问题点——可能是 Prompt 写得不够明确、某个 Skill 的描述导致路由错误、上下文管理丢了关键信息，或者模型能力确实不够。研发据此做出变更，变更后用评测集回测，确认没有引入退化，再上线 AB 观察真实效果。这条 Loop 让 Agent 的能力持续提升，同时保证每次提升不以牺牲已有能力为代价。

除了 Case 挖掘和归因这个显而易见的咬合点，其实还有第二个咬合点——评测资产（评测集）。评测体系迭代 Loop 的产出是更完善的评测集，回测的门禁价值就越高；回测门禁越严格，Agent 上线后暴露的新问题就越少。从而形成正反馈。

1.3 评测体系的三种能力

把两条 Loop 放在一起看，完备的评测体系要同时具备三种能力，并沉淀评测资产（评测集）。

评测资产（评测集）：

这三种能力运转起来后，会沉淀下可复用的资产，它们才是评测体系真正的长期价值。

• 评测标准（Metrics & Rubric）：团队对“好”的共识的显式化、可量化，消除评测的模糊度。
• 评测样本：真实问题的结构化沉淀。黄金集定义了“好的下限”，错题集记录了“踩过的坑”，挑战集标定了“能力的边界”。它的价值在于可回归——每一个曾经犯过的错，都不应该再犯第二次。

但“什么叫好”的共识和“踩过哪些坑”的记录会随着 Agent 扩量而持续扩充。从这个意义上说，评测体系建设的本质，是把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产。

1.4 评测体系的构成

从评测体系的视角，可以拆解出四个模块。前三个模块分别回答不同的问题，第四个模块是前三者的地基。

关于模块划分的说明

业界和开源领域对离线评测的定义非常清晰，而在线评测、在线监控、观测以及 Case 挖掘与归因这几个模块彼此之间存在模糊地带，例如 Arize AI、LangFuse、Braintrust 对这几个概念的划分就不尽相同。例如有的产品把“Online Evaluation”和“Monitoring”合并成一个概念，有的把 Trace 采集归入 Observability 而把 Trace 分析归入 Evaluation。

由于行业内没有形成统一的概念划分，为了方便后续讨论中的概念对齐，以及用一套框架贯穿冷启动、扩量和自进化，我们拆解出上面这四个大模块。读者在实践过程中可以按自己团队的组织方式重新切分，不漏掉任何一项职责即可。

一个贯穿全文的例子

为了让后面的讨论有实感，我们先约定一个贯穿全文的场景——商家经营分析 Agent（对应内部的商家 Claw 类场景）。

这个场景的特点是典型的长程 Agent：多步骤、多 Skill 调用、有中间产物、与环境频繁交互、没有唯一正确答案。后面每讲一个模块，我们都会回到这个例子上看它具体长什么样。

二、离线评测：变更的门控

离线评测的核心作用在于 Agent 版本变更后的回测，可以作为上线前的门控。它依赖：固定评测集（固定样本和固定评测标准）、尽可能贴近生产的固定执行环境。

当 Agent Harness 的任何一个环节发生变化——模型升级、Prompt 调整、知识库更新、Skill 新增或下线——都可以通过离线评测验证效果，避免不成熟的变更导致 Agent 能力劣化。

为什么强调“固定”

回测的本质是控制变量对比：只让 Agent 版本变化，其他一切保持不变，这样分数的差异才能归因到版本变更上。

实践中最容易被破坏的是执行环境。比如评测时调用的是测试环境的下游接口，而测试环境的数据和生产不一致；或者沙箱里没有预置用户的历史文件，导致 Agent 拿不到必要的上下文。这类环境差异会让离线分数和线上表现系统性偏离，最终让团队不再信任离线评测。

一个实用的检验方法：拿同一批样本，分别在离线环境和线上影子流量里跑一遍，看两边的结论是否一致。差异过大，说明环境保真度不够。

2.1 评测集：评测体系的核心资产

2.1.1 评测集的构成

广义的评测集由（问题、参考答案、评价标准）三元组构成，其中问题-参考答案合起来称作评测样本。这个概念最早出自大模型评测领域，如今被借用到 Agent 评测领域。

但随着 Agent 形态从 ChatBot 演进到长程 Agent，这三元组的具体含义也在发生迁移：

这个迁移背后是一个根本性变化：Agent 评测从“答案评测”走向“行为评测”。短程场景下，参考答案是一个可以逐字比对的字符串；长程场景下，参考答案变成了一段对执行过程的描述，评测要看的是 Agent 走过的路径是否符合预期，以及最终环境状态是否达成目标。

借用 Anthropic《Demystifying evals for AI agents》文中对长程 Agent 评测 Task 定义：为“具有明确输入和成功标准的单个测试”，这个概念同样可以泛化到短程 Agent 领域。

借用这个概念，评测集的每一行三元组都可以看做一个 Task。

具体而言 Task 里要有固定输入，比如 Query / answer，或者 prompt / expected behavior；评价部分由 Metrics 和 Rubric 构成，其中 Rubric 是最小粒度的评测标准。

一个完整的 Task 大致长这样：

《Agent 评测漫谈》中强调的二元化 Rubric思路就是用在这里的：把“这个 PPT 做得好不好”这种模糊判断，下钻成一组可以回答是/否的具体检查项，从而将模糊的问题尽可能量化，消除分歧。人人一致率和人机一致率的提升，本质上都来自这种下钻。

2.1.2 评测集的分类：端到端与过程

评测集总体上可以分成两类：端到端评测集和过程评测集。每一个评测集都由上文的三元组构成。

对于端到端评测和过程评测，都可以建立我们常说的黄金集、必过集，这两套概念彼此独立不冲突。

为什么两类都需要？端到端评测集看的是最终结果，重点回答“事有没有办成”；过程评测集看执行过程，回答的是“中间哪一步出了问题”。回到商家经营分析的例子。端到端评测集告诉你“100 个任务里有 68 个交付了可用的 PPT”，端到端交付率是业务方最关心的数字。但当这个数字从 68 掉到 55 时，端到端评测集无法告诉你原因。而过程评测集可以：如果“投放数据 Skill 调用成功率”从 95% 掉到 70%，问题就定位到了；如果 Skill 成功率没变、但“数据合并正确率”下降，问题就在另一处。若过程评测集指标未发生波动，但端到端交付率降低，则说明发生了未知异常，需要我们进一步挖掘和归因从而迭代评测集。

一个实用的经验：端到端评测集回答“要不要拉响警报”，过程评测集回答“警报响了该找谁”。只有端到端，你会陷入“知道坏了但不知道哪坏了”；只有过程，你会陷入“每个模块都达标但用户就是不满意”，二者相辅相成。

再次强调，端到端评测集是站在用户视角建立的。也就是说当 Agent 功能逐渐增加之后，需要按照端到端的功能模块建立不同的端到端评测集。例如商家 Agent，门店经营是一个核心功能模块，由若干个 Skill 构成；门店百科又是一个核心功能模块，由查数 Skill 和门店知识库构成。这种情况应该分别建立端到端评测集。

2.1.3 评测集的分层拆解

过程评测集还可以继续往下拆。比如知识库相关的问题，可以单独沉淀成知识库评测集；具体 Skill 调用相关的问题，可以沉淀成 Skill 评测集。后面业务长出新的子场景，也可以继续往下拆。

评测集要随着 Agent 的功能发展、随着问题的出现而不断细化。以商家经营分析为例，可以拆成这样一棵树：

拆解带来的一个额外收益是责任清晰。当过程评测集和组织分工对齐后，某一层的分数下降，就能直接找到对应的负责人，而不需要先开一轮会来确定“这是谁的问题”。

拆解的边界：不要过早拆得太细

分层拆解是演进的结果，不是设计的起点。《Agent 评测漫谈》博客中明确提到评测是一门实践科学，与其设计精妙的评测体系，不如抓住核心场景先跑起来。

正确的顺序是：先建端到端评测集和核心模块的过程评测集跑起来，遇到“知道坏了但不知道哪坏了”的情况，再进一步丰富。让拆解被真实问题驱动，而不是被完备性焦虑驱动。这一点在《冷启动篇》会详细展开。

2.2 回测执行：把评测集用起来

Agent 发生变更时，评测集起到门控的作用。通过回测，我们能保证变更前后核心链路、核心指标的一致性。但“跑一遍评测集”和“建立有效的回测机制”之间还有距离。几个关键的工程考量：

• 多次试验（Trial）取稳定结论。大模型输出天然有随机性，同一个 Task 跑两次结果可能不同。实践中通常对每个 Task 运行多次试验，也就是我们常说的 Pass@k，用通过率（Pass Rate）而非单次通过与否作为结论。
• 分层门禁。不是所有 Rubric 都同等重要。安全类、数据准确性类的检查项应该是“一票否决”，任何一条不过就阻断发布；体验类、加分项则可以设置阈值。
• 接入研发流程才有约束力。真正有效的做法是把回测嵌入 CI/CD 或发布流程，让它成为一道自动执行的关卡。没有接入流程的门禁，本质上只是一个建议。

离线评测的固有局限

必须清醒认识到离线评测能力的边界。它只能发现已知的问题——评测集里没有的场景，回测永远测不出来。

例如商家经营分析的场景：如果评测集里全是“制作 PPT”类任务，那么当用户开始大量提出“帮我对比三家门店的数据”这种新需求时，固定的离线评测集显然无法覆盖到新出现的 Case。

这正是为什么完备的评测体系必须包含在线部分——离线负责守住已知，在线负责发现未知。

三、在线评测与在线监控：真实世界的反馈

离线评测做得再丰富多样，也是无法穷举所有场景的，而在线评测接受真实世界得分反馈，则可以弥补这部分短板。

在线评测和在线监控处理的是线上真实运行时的质量观察。二者关注的层面不同，但有一块重要的交集 —— 巡检。

• 在线评测包括 AB、影子模式和巡检，用于在真实线上环境中观察 Agent 的效果。
• 在线监控则关注 Skill/Tool 成功率、失败率、Token 消耗、异常波动等运行指标。

一个直观的区分：在线评测回答“系统工作得好不好”，在线监控回答“系统有没有在正常工作”。前者是质量视角，后者是运维视角。Skill 调用成功率 100% 但每次都返回了错误的数据，监控是绿的，评测是红的。

3.1 在线评测的三种手段

三者的互补关系：影子模式在上线前用真实流量兜底，AB 在上线后确认业务价值，巡检在日常持续盯住基本盘。

3.2 巡检：两个模块的交集

巡检处在在线评测和在线监控的交集上，核心作用是持续监控线上 Agent 效果的稳定性。巡检是业务上把“线上质量观察”变成“持续可追踪过程”的常用手段。最常见的做法是从离线评测集中抽取一部分代表性的 Task 用于周期性检查线上 Agent 的表现，随着评测精细化，也可以单独维护一套巡检评测集。巡检同时具备两种属性：

• 评测属性：看某类能力有没有持续稳定，比如关键任务成功率是否低于预期。这是在做质量判断。
• 监控属性：把分数变化、失败样本和异常趋势沉淀下来，作为后续 Case 挖掘和归因的输入。这是在做信号产出。

回到商家经营分析的例子，一套合理的巡检可以这样设计：

3.3 在线监控关注什么

在线监控关注的是运行指标，工程中常见的大量稳定性指标，都在在线监控的范围内。常见的监控维度包括：

• 可用性类：Skill/Tool 调用成功率、失败率、超时率、异常类型分布。这是最基础也最容易见效的一层。
• 成本类：Token 消耗、单任务平均步数、平均耗时。
• 行为监控类：任务类型分布、Skill 调用频次分布、平均对话轮次。这一层的价值在于发现用户结构的变化。当某类新任务的占比快速上升，往往意味着评测集需要扩充了。

稳定性指标和行为监控类指标要放在一起看，才能得出有意义的结论。举例来说，任务完成率下降 5 个点，如果同时观察到某个 Skill 的失败率从 2% 涨到 15%，那结论极大概率是工程问题；如果 Skill 都正常，但“数据对比类”任务占比从 10% 涨到 35%，那结论是用户结构变了、Agent 在新场景上能力不足——这两种情况的应对完全不同。这就是 Case 挖掘和归因的范畴了。

四、Case 挖掘与归因：驱动双环演进的枢纽

Case 挖掘与归因主要承接在线评测和在线监控中暴露出来的问题线索，同时也接收线上反馈、真实样本采样和业务规则筛出的样本。

职责分工上：Case 挖掘负责把样本收进 Case 池，归因负责继续往下定位，判断 Agent 流程里的核心问题点。

这个模块是整个体系的枢纽，也是当下火热的“Agent 自进化”的核心切入点。

4.1 Case 挖掘的四大类来源

四类来源需要搭配使用，因为它们的“盲区”不同。只靠线上反馈，你只能看到用户愿意抱怨的那部分问题；只靠监控，你只能看到能被指标刻画的问题；只靠规则挖掘，你只能看到自己已经想到的风险。随机采样是唯一能发现“你根本没想到的问题”的手段，虽然它成本最高、命中率最低，但不可省略。

4.2 Case 池的分化：Good Case 与 Bad Case

挖掘出来的样本进入 Case 池后，可以继续区分为 Good Case 和 Bad Case，分别沉淀成不同类型的资产：

错题集是回报最直接的一类资产。它的逻辑很朴素：每一个曾经犯过的错，都不应该再犯第二次。

而黄金集的价值容易被低估。Bad Case 告诉你哪里不行，但它不能告诉你“到什么程度才算行”。没有黄金集，团队在讨论质量时只能各说各话；有了黄金集，“我们要做到这个水平”就变成了一个可以指着看的具体样本。

4.3 归因：从“这里出了问题”到“为什么出问题”

归因的目标，是定位 Agent 流程里的核心问题点。一个 Bad Case 只能说明“这里出了问题”，还不能说明“为什么出问题”。

归因要继续判断问题发生在哪个环节：常见的做法是将 Agent 执行过程全链路铺开，通过 Trace 日志逐一定位问题点，这个过程与软件问题排查过程中看日志查 bug 高度雷同。正因如此归因高度依赖观测基建 Trace。这个过程可以由人工完成，也可以由机器辅助完成。

一个可操作的归因分层，大致如下：

归因明确之后，正向 Case 一般可以归入评测集中的黄金集、挑战集；负向 Case 则会进入两条不同的路径：

• 进入 Agent 效果迭代——修复、回测、上线。这是 Agent 迭代 Loop。
• 校验 Rubric，如果现有 Rubric 没有准确刻画风险，则需要迭代 Rubric，同时将 Case 流入错题集。这是评测体系迭代 Loop。

很多团队只走了第一条路径——默认“评测说不行就是 Agent 不行”。这种默认假设会带来一个隐蔽的问题：Agent 会被优化成“迎合评测标准”，而不是“解决用户问题”。当评测标准本身有偏差时，优化得越努力，偏离真实需求越远。定期检查“是不是评测判错了”，是评测体系自我校准的必要动作。

五、Agent 观测基建：一切的地基

《Agent 评测漫谈》里有一个朴素的表述：看不见的问题，几乎不可能被稳定解决。观测的核心价值在于让 Agent 链路白盒化。这也是 Agent 研发公式“观测 + 评测 = 持续迭代”中，观测被放在第一位的原因。

Agent 的一次执行是一条长链路：用户输入 → 意图理解 → 任务规划 → 工具/Skill 调用 → 环境交互 → 中间结果处理 → 策略调整 → 最终输出。只要其中任意一层出问题，最终效果都可能劣化。但如果系统只能看到“用户说了什么”和“最后回复了什么”，就几乎无法判断问题根因。这正是工业界发展出 Trace 系统的动因——将黑盒内部的推理过程进行全路径披露，把所有影响模型输出的输入信息都记录下来。前篇博客中已经充分论述了观测之于评测的意义，这里不再赘述。

5.1 观测基建的建设思路

从 Trace SDK，到如今集成在 OpenClaw、Claude Code 当中的 Trace Plugin。观测基建也随着 Agent Harness 高速迭代。

综合前面的讨论，一套支撑完备评测体系的观测基建，至少应该具备以下能力：

由于 Agent Harness 迭代太快，哪怕是开源社区，相关基建也是落后于需求的。观测是地基，但这不意味着必须项目启动之初就需要建立一套完备的系统 。实际落地过程中，观测指标、观测基建也是需要基于需求反向设计的。判断标准很简单：当你发现“想自动化判断某件事，但数据里没有”的时候，就是补埋点的时候。

一个务实的建设思路是：先保证“最小可归因”——至少能拿到完整的模型调用输入输出和 Skill 调用记录，能凭 Trace 复现一个 Bad Case 到底发生了什么。这是冷启动阶段的底线，也是《冷启动篇》会重点讨论的内容。

六、评测体系成熟度自查

实践中，我们观察到各业务方评测体系三种最常见的“部分完备”形态。它们各自能解决一部分问题，但都存在明确的能力缺口。

第三种形态最值得警惕，因为它看起来最“完备”——既有评测集又有监控看板，汇报时数据很齐全。但由于缺少中间的枢纽，两套体系是割裂的：线上发现的问题回不到评测集，评测集的结论也解释不了线上现象。这种形态往往投入不少但收效有限，团队容易陷入“我们该做的都做了，为什么还是这样”的困惑。

最后，把前面的讨论收敛成一张可以直接使用的自查表。建议对照打分，找出自己业务最短的那块板。

如何使用这张表？

不要追求所有维度都达到 L3。不同业务阶段对应不同的合理水位：冷启动阶段，观测 L1 + 评测集 L1 + 回测门禁 L1 就足以支撑起最小闭环；扩量阶段，重点是把评测标准和在线评测推到 L2，少量指标推到 L3；全量运营阶段，才需要考虑 L3 的自动化与规模化。

更有价值的用法是看“短板”和“错配”。如果你的评测标准已经到了 L3（机评规模化），但 Case 挖掘还在 L0（靠用户投诉），那么再精密的机评也只是在重复评测已知的样本——投入应该转向补齐挖掘能力。体系的能力上限，由最短的那块板决定。

七、小结与下一篇预告

回到本篇开头的问题：一套完备的评测体系长什么样？可以概括为四个模块、三种能力、两条 Loop、一套资产：

• 四个模块：离线评测负责守住已知、在线评测与监控负责发现未知、Case 挖掘与归因负责定位和分派、观测基建作为一切的地基。
• 三种能力：发现问题、定位问题、驱动演进。缺一项，体系就会在对应环节卡住。
• 两条 Loop：Agent 迭代 Loop 让能力持续提升，评测体系迭代 Loop 让量具持续校准。二者在 Case 挖掘与归因处共享入口，在评测集处共享资产。
• 一套资产： 覆盖 Agent 各功能模块的端到端和过程评测集，它是 Agent 效果的守门员，是评测体系真正的长期价值，是 Agent 效果稳定性的锚点，也是将来 Agent 自进化的地基。

需要强调的是，这张全景图是“终局”而不是“起点”。没有任何一个团队应该照着这张图从头到尾建一遍——那既不现实，投入产出也不划算。

《Agent 评测漫谈》里有一句话值得在这里重复：Agent 评测是一门实践科学，起步阶段“让数据飞轮高效运转起来”的意义，远大于“设计一个复杂精妙的评测体系”。全景图的价值在于让你在每个阶段都清楚：我现在处在哪里，下一步补哪一块收益最大，以及某一块暂时不做的代价是什么。

那么起点在哪里？在一穷二白、没有评测集的冷启动阶段，如何实现评测飞轮的最小闭环？这正是下一篇《冷启动篇》将要回答的问题。

八、FAQ

Q：Agent 离线评测集只用在回测吗，为什么不可以按照大模型迭代一样必须比上一次得分高才可以发版？

这个问题涉及到 Agent 的评测和大模型评测的核心差异，需要从两个方面回答。

1、Agent 为什么不像基座模型一样打榜？基座模型提供的是通用能力，可以拆解出一系列的通用能力。提醒大家，大模型评测本身也是行业极其专业的领域。目前大家看到的大模型基座能力的评价指标体系是在过去三年中无数论文堆砌而来的。这三年基座模型 benchmark 的含义本身也发生了极大的变化。而 Agent 是服务于垂直业务领域的，最佳的 Agent 指标就是业务指标，所以对 Agent 而言，上线 AB 看业务指标变化是评价其能力的黄金标准。

2、评测集可以拆分为必过集合和挑战集。显然在垂直业务领域里，挑战集的构建是极其困难的，非常容易跟不上 Agent 版本功能迭代。而必过集样本属于 Agent 核心功能，对于已知的问题必须尽可能解决才可以上线。所以日常工作中，经常会出现必考题（必过集）都会了，难题（挑战集）又见不到的情况。

综上，Agent 离线评测更多是用在回测方面，真实效果的好坏直接通过线上 AB 看业务指标。

补充：如果设立了挑战集，一定要及时更新拟合线上真实场景的分布，否则评测集不置信。

引言

随着大语言模型、生成式AI与多模态交互技术的快速发展，数字人直播已突破早期形象僵硬、交互单一的瓶颈，在本地生活、电商、文娱等领域展现出巨大的商业潜力。美团智播，是面向本地生活场景的AI数字人直播解决方案，融合大模型、数字人与多模态交互技术，提供丰富的行业专属数字人形象，支持真人1:1复刻与门店实景定制，30秒生成直播素材，3分钟完成开播配置，7×24小时稳定上播。过去一年，依托生成式AI技术，数字人直播月日均GTV同比增长82.12%，月日均观看人次同比增长163.44%，开播场次提升11倍，充分验证了AI数字人直播在本地生活商业闭环中的实际价值。

2026年7月8日至10日，美团智播在中国互联网大会上完成行业首秀，以“实时交互数字人+直播带货数字人”为主题亮相科技互动展区。展区中，实时交互数字人通过秒级语音问答与观众自然对话，数字人直播间则让参会者发出“完全看不出是数字人”的感叹——这一亮相标志着美团智播正式从内部打磨走向行业舞台。

如何让数字人直播达到真人级表现力，并满足大规模商业化落地的要求？本文将围绕美团智播的核心能力，系统介绍支撑产品的关键技术突破——涵盖高保真形象生成、自然动作驱动、语音手势协调、高效推理部署及系统架构设计，这些技术共同构成了数字人直播从“能用”到“好用”，再到“规模化量产”的完整技术闭环。凭借这些技术积累，美团智播荣获2026年度“中国多媒体企业创新技术奖”，这一奖项由中国计算机学会（CCF）和中国图象图形学学会（CSIG）指导，中国多媒体大会（ChinaMM）设立并颁发，是对美团在数字人直播领域自主创新能力的行业认可。

一、数字人直播的背景与挑战

1.1 业务背景：百万商家的“成本-效率-体验”困境

美团连接数百万商家与数亿消费者，数字人直播正加速渗透商家日常运营。然而，商家直播面临四重现实困境：

1. 准入门槛高：专业数字人形象定制动辄数万元，7×24小时真人主播团队的人力成本更是中小商家难以承受之重；
2. 时效性要求苛刻：限时秒杀、突发热点、天气突变等本地生活场景要求直播内容“分钟级”响应，传统真人主播排班与内容制作的周期无法满足实时营销节奏。
3. 形象与内容同质化：大量商家依赖通用数字人模板，主播形象千篇一律，缺乏与品牌调性匹配的专属感，难以建立差异化认知。
4. 规模化部署成本高：数万商家同时开播，若每路独占大量GPU，推理成本将线性膨胀，数字人直播的普惠化落地无从谈起。

更深层的问题是：现有大部分数字人方案普遍存在“一眼假”——面部僵硬、动作重复、手势与语音脱节，用户停留时长较真人主播明显偏低。如何让数字人直播媲美真人主播，是技术突破的核心方向。

1.2 技术挑战：高质量数字人直播的多维难题

数字人直播为上述问题提供了新思路，但要真正达到规模化商业可用，远非简单的视频生成任务，面临四大相互交织的技术挑战。

挑战一：形象高保真，从“一眼假”到“媲美真人”

任何面部僵硬、五官失调都会让观众一眼识破。更高要求在于：商家需要真人1:1复刻，以及换装、换背景时保持身份一致性。如何在生成与编辑全链路中同时保证高保真度与强一致性，是形象生成技术的核心难题。

挑战二：动作自然多样，从“木偶戏”到“真人感”

7×24小时直播对动作多样性要求极高。有限动作库循环播放导致观众疲劳、留存率下降；动态生成方案又面临质量不稳定、关节扭曲等问题。如何在单一模型中同时实现高质量与高多样性的动作生成，是长时直播的重大挑战。

挑战三：语音语义协调，从“念稿机器”到“音画一致”

优秀主播的手势与语义高度协调，现有技术能生成与节奏同步的自发性动作（点头、摆手），但无法产生与语义精准绑定的协调性手势。如何跨越语音与动作之间的“语义鸿沟”，是互动体验升级的关键瓶颈。

挑战四：规模化推理效率，从“单路昂贵”到“万路并发”

数字人直播系统是多智能体协同平台，如何在保证质量与实时性的前提下，高效协同多个子智能体，大幅压缩单路推理开销，是数字人直播走向普惠的最终门槛。

1.3 技术方案总览

面对上述挑战，美团智播自研关键技术，围绕数字人主播“长得真→动得准→演得活→卖得好”形成完整技术闭环，实现全链路跃升。

• 长得真：高保真数字人形象生成与编辑技术，协同攻克形象生成高保真、多元化难题；
• 动得准：文本驱动高质量动作生成技术，生成高可控、自然流畅的肢体动作，并通过动作迁移生成高表现力的数字人视频；
• 演得活：语音手势协调生成技术，跨越语音与动作的语义鸿沟，让手势与讲解形成语义级配合；
• 卖得好：面向规模化部署的Token压缩和推理加速技术，实现多智能体高效协同，打通万路并发瓶颈。

二、让AI主播“长得真”——高保真数字人形象生成与编辑

2.1 产品痛点与需求

商家对数字人形象有三层递进需求：快速可用（3分钟定制开播）、高度个性化（真人1:1复刻）、灵活可编辑（换装换背景时保持身份一致）。过去的定制化图像生成方法面临身份与姿态耦合、微调耗时长、编辑破坏身份特征等核心问题。

2.2 结构解耦身份个性化与自奖励精准编辑

针对数字人生成中身份保真与灵活编辑的双重挑战，美团智播研发团队提出了结构解耦身份个性化（SDIP）和自奖励精准编辑（SREdit）技术方案。

2.2.1 结构解耦身份个性化

SDIP（Structure-Decoupled Identity Personalization）的核心思想是将姿态、身份、背景三个维度进行结构性解耦，包含两个核心模块：

• 身份与姿态精确分离模块：在Diffusion-Based主干网络中，通过结构残差注入，将身份特征以残差形式融入，避免姿态空间污染；空间解耦正则化损失，以面部为重点，显式约束身份特征的空间分布；区域动态掩码，隔离不同语义区域的特征流动。
• 细节保真度增强模块：为解决细节保真度不足问题，通过视觉参考增强器将参考图像高频细节注入生成，提升纹理还原度；结合掩码感知质量校正策略，对遮挡和边界区域进行精细化修正。

2.2.2 自奖励精准编辑

商家日常运营中常需对数字人进行局部编辑——换应季服装、匹配活动背景、调整妆容。核心约束是：编辑前后身份特征必须保持一致，不能“换了衣服就认不出人”。

针对这一需求，团队提出了SREdit（Self-Rewarding Editing），被ACM MM 2026收录。其技术创新体现在三个层面：

1. SIA指令原子化：在MLLM-DiT架构中，将复杂编辑指令分解为原子级操作单元，每个原子对应明确的空间区域和编辑语义，避免语义模糊导致身份信息被意外修改。
2. 空间奖励重加权：根据编辑区域的空间分布动态调整奖励权重——编辑区域给予较高编辑质量权重，非编辑区域给予较高保真度权重，引导模型在“大胆编辑”与“谨慎保持”间找到最优平衡。
3. 认知闭合架构：同一模型既做编辑器又做评判器，消除了传统方案中编辑器与评判器分离导致的reward hacking（编辑器学会欺骗评判器）。当二者共享同一套视觉理解能力时，优化目标与实际质量目标达成内在一致。

实验结果表明SREdit在公开数据集GEdit-Bench、ImgEdit-Bench、KRIS-Bench上整体性能提升2.5%～3.8%，视觉效果上在保持身份一致性的前提下达到了业界领先的编辑精度。

数字人图像生成与编辑效果示例：

三、让AI主播“动得准”——文本驱动高质量动作

3.1 产品痛点与需求

7×24小时数字人直播介绍商品时，不同商品需要不同风格的动作配合，这对动作生成系统提出双重挑战：保证单个动作质量（流畅、自然、物理合理），同时保证长序列的多样性和可控性。

3.2 MoTiGA：多级因果LLM动作生成

美团智播团队提出的多级因果LLM动作生成MoTiGA（Motion generation via multi-level causal Transformers with LLM-Guided Alignment）方法，被CVPR 2026收录，MoTiGA将大语言模型的自回归生成范式引入人体动作生成，通过多级因果结构和偏好优化实现质量与效率的双重提升。

• Causal RVQ-VAE：传统RVQ-VAE使用双向卷积，训练时模型可“看到未来”，推理时只能自回归生成，导致训练-推理不一致。MoTiGA将卷积全部替换为因果卷积，从根本上消除行为差异。重建FID从0.114降至0.031，质量提升超过72%。
• Time-lagged Causal Prediction：标准自回归生成逐token串行，效率低。MoTiGA观察到RVQ不同量化层间存在时间滞后因果依赖——粗粒度层可直接指导细粒度层预测。基于这一观察，设计了多级因果预测架构，不同量化层token可并行生成，推理效率提升K倍，同时保持因果依赖正确性。
• MHPO（Motion Human Preference Optimization）：业界首个将人类偏好优化引入动作生成的工作。团队在HumanML3D上构建了101,490组偏好对，采用类似DPO的策略直接在偏好数据上优化模型，使生成结果更符合人类对“自然动作”的主观判断。

实验结果表明，MoTiGA在HumanML3D数据集上FID为0.041（较基线降低82.3%）、在KIT-ML数据集上FID为0.180（较基线降低64.7%），生成的动作序列与真实人体动作分布高度吻合，达到了接近真人的自然度与流畅度。

四、让AI主播“演得活”——语音手势协调生成

4.1 产品痛点与需求

真人主播说“这款披萨用料非常足”时会张开双手比划量大，说“请看右边链接”时手指会指向右侧，这种语音与手势的协调是观众判断“数字人是否像真人”的重要线索。现有技术主要关注“自发性手势”（点头、摆手），缺乏与语义内容的深度绑定，无法精准生成“指向商品”、“比划大小”等协调性手势；在模型设计上，传统方案采用全局去噪架构，需等待整段语音结束后一次性生成全部动作，无法满足直播场景对实时性和无限时长的要求。

4.2 StreamingTalk：流式共语动作生成

StreamingTalk 的核心创新在于将全局去噪过程重构为流式因果生成架构，首次实现了非自发性协调动作的流式生成，支持数字人说话时实时、连续、可控地生成同步手势动作，论文已投稿AAAI 2027，其核心技术创新包括：

• 流式因果生成架构：通过下三角时间步调度将全序列去噪转化为逐chunk渐进输出，每个chunk独立提交，推理延迟与总时长无关；活跃窗口内采用双向注意力精炼动作细节，以前方已提交帧作为锚点约束连续性，计算量恒定不随序列增长，实现直播场景下“边说边动”的实时表演。
• 长序列稳定性保障：训练阶段采用Self-Forced Clean Anchoring策略，以模型自身预测替换真实锚点，模拟推理时的误差累积，弥合训练与推理的分布差异；同时引入尾部偏置采样，增加窗口末端帧的训练曝光，补偿滑动窗口的尾部覆盖不足。两者协同确保长时生成的手势质量不衰减、不漂移。
• 时变动作控制机制：每个chunk可绑定独立动作标签，在边界处动态切换表演风格；语音特征通过交叉注意力注入保证节拍同步，动作标签作为语义条件控制手势类型。两层条件协同，使手势既跟随语音节奏，又能根据内容动态切换——介绍产品时双手展示，讲优惠时兴奋挥手，回答问题时托腮思考，全程在一条连续流中平滑过渡。

StreamingTalk首次验证了流式Flow Matching可在恒定延迟、恒定内存下生成无限长高质量手势流，为数字人从“能动但僵硬”升级为“实时演、持久演、灵活演”的高表现力提供了核心技术支撑。

五、让AI主播“卖得好”——高效推理支撑万路并发

5.1 产品痛点与需求

美团智播直播场景具有显著的规模化特征：数以万计的商家需要同时开播，每一路直播都需要实时的视觉理解、智能交互和画面渲染。按照传统的多模态大模型推理方式，每一路直播需要处理大量的视觉token，单路GPU占用高昂；当并发量达到万路级别时，大模型推理成本将成为产品普惠化的根本瓶颈。因此，如何在保证生成质量的前提下大幅压缩视觉推理开销，是产品普惠化的关键。

5.2 Glance2Gaze：扫视融合与注视压缩

美团智播团队提出的Glance2Gaze方法被NeurIPS 2025收录，通过创新的视觉Token压缩策略，在几乎不损失模型性能的前提下实现了75%的Token压缩率和2.5倍的推理加速。其命名灵感来自人类视觉系统的“扫视-注视”机制：人眼首先通过快速扫视（glance）获取场景全局信息，然后通过注视（gaze）聚焦到关键区域获取细节信息。

• Glance Fusion：传统的视觉编码器（如ViT）通常只使用最后一层的输出作为视觉表征，丢弃了中间层的丰富信息。Glance Fusion通过多层特征融合机制，将ViT不同深度层的特征进行聚合，在不增加输出token数量的前提下获得更丰富的视觉表征。这相当于在“扫视”阶段获取了更全面的场景信息，为后续的压缩提供了更好的信息冗余基础。
• Gaze Compression：不同于传统的在视觉编码器输出后进行独立压缩的方案，Gaze Compression将压缩模块直接嵌入到LLM的decoder层中，实现了视觉token的渐进式压缩——从576个token逐步压缩为288个，再进一步压缩为144个。

这种“嵌入式渐进压缩”设计有三个关键优势：压缩过程能够利用LLM的语义理解能力，更智能地判断哪些视觉信息冗余、哪些关键；渐进压缩避免了一次性大幅压缩导致的信息断崖式丢失；完全兼容FlashAttention-2，可以直接部署到现有推理基础设施，无需额外工程适配。

实验结果表明：Glance2Gaze实现了75%的视觉token压缩（576→144），模型在各项视觉理解任务上的性能损失控制在2%以内，推理速度提升2.5倍，将并发成本降低了60%以上。

六、系统架构：双引擎驱动的智播技术中台

单项技术的突破只是基础，如何将多项技术整合为一个高效协同的系统，才是产品落地的关键。美团智播在系统层面构建了“双引擎驱动”的技术中台架构，实现实时交互与内容量产的双重能力。

6.1 实时交互引擎

实时交互引擎是美团智播应对“用户即时互动”场景的核心组件。当观众在直播间提出问题或触发互动时，系统需要在极短时间内完成“语义理解→回答生成→动作合成→画面渲染”的全链路响应。美团智播的实时交互引擎实现了全双工通信，系统并行调度形象、文本生成、数字人驱动等核心能力，通过流式连接，前一阶段部分输出即触发下一阶段计算，最大限度压缩总体延迟。

6.2 内容量产引擎

对于日常直播中的商品讲解、活动介绍等“计划性内容”，美团智播构建了多智能体协同的内容量产引擎。该引擎采用“创意-检索-思考-生成-评测”的五阶段协同架构：

• 创意智能体：基于商品特征和直播风格需求，生成讲解创意方案；
• 检索智能体：从知识库中检索相关的商品信息、卖点话术和成功案例；
• 思考智能体：整合创意方案和检索结果，规划完整的讲解逻辑和动作脚本；
• 生成智能体：调度形象生成、视频生成、数字人驱动等技术模块，生成完整的视频内容；
• 评测智能体：对生成内容进行质量评估，不达标则反馈至上游重新生成。

这种多智能体协同架构使得内容生产实现了“工业化流水线”模式，单条商品讲解视频的生成时间从人工制作的数小时缩短至分钟级，且质量稳定可控。

6.3 知识库支撑体系，“形象-动作-场景”解耦复用架构

支撑双引擎高效运转的，是美团智播精心构建的三大知识库：

• 穿搭美学库：沉淀行业搭配规则与色彩美学知识，指导数字人形象的服装选择和风格搭配；
• 直播专家知识库：汇集优秀真人主播的讲解技巧与互动经验，为AI主播的内容生成提供专业参考；
• AI运营大脑：基于海量直播经营数据构建智能决策系统，实时分析直播间指标，动态调整商品切换、优惠触发、节奏把控等策略，形成数据驱动的持续优化闭环。

美团智播在系统设计上遵循了“形象-动作-场景”三维解耦的核心原则。数字人形象、肢体动作、直播场景三个维度完全独立管理，可以自由组合复用。这种解耦架构使得同一形象可搭配不同动作风格、同一套动作可应用到不同形象、同一场景可快速切换不同主播，组合式复用大幅降低了内容生产的边际成本，使“千人千面”的个性化直播成为可能。

七、总结与未来展望

美团智播已在多个业务线实现规模化落地，核心指标表现亮眼：定制化数字人模特从需求到上线仅需3小时，相比传统的定制拍摄效率提升超10倍；商家闲时交易额平均提升7.3%，7×24小时不间断开播有效填补真人主播休息时段的流量空白；整体开播效率提升60%，AI自动生成话术、装修直播间、触发营销动作，将商家从繁琐的直播准备中解放出来。

展望未来，美团智播将在以下方向持续演进：

• 情感表达与个性化交互：未来数字人主播将具备情感计算能力，面对用户的不同反馈给予恰当的情感回应。
• 自适应风格迁移：基于行业、品牌、时段的差异化需求，数字人主播将自动调节表达风格。
• 高表现力实时交互：持续优化生成和渲染管线，向高表现力的实时交互产品形态迈进。

参考文献：

• [1] Chen X, Bao Q, Liu X, et al. Multi-level Causal LLM-based Text-to-Motion Generation with Human Alignment. CVPR 2026.
• [2] Chen J, Liu H, Ao Y, et al. Glance2Gaze: Efficient Vision-Language Models from Glance Fusion to Gaze Compression. NeurIPS 2025.
• [3] Wang Y, Bao Q, Ao Y, et al. SREdit: A Self-Rewarding Framework with Intrinsically Aligned Critic for Image Editing. ACM MM 2026.
• [4] Zhang Z, Liu K, Chen Z, et al. InfVSR: Toward Consistency-Driven Streaming Generative Video Super-Resolution. ICML 2026.
• [5] Fang F, Yang S, Yang W. CoordSpeaker: Exploiting Gesture Captioning for Coordinated Caption-Empowered Co-Speech Gesture Generation. CVPR 2026.
• [6] Chen X, Liu W, Bao Q, et al. Motion Capture from Inertial and Vision Sensors [J]. IEEE Transactions on Multimedia, 2026.
• [7] Liu H, Bao Q, Chen X, et al. Stable Layout Image Diffusion for Content-Aware Layout Generation. ICASSP 2026.

ACL（Annual Meeting of the Association for Computational Linguistics）是计算语言学和自然语言处理（NLP）领域的国际顶级学术会议，是CCF-A类会议，也是中国计算机学会推荐的自然语言处理方向最高等级国际学术会议。ACL 2026杰出论文奖（Outstanding Paper）在圣地亚哥揭晓，全球共 18 篇入选，美团履约技术团队的《GeoRA:Geometry-Aware Low-Rank Adaptation for RLVR》 就是其中之一。

• 论文下载：GeoRA：Geometry-Aware Low-Rank Adaptation for RLVR
• 讲解视频：ACL2026 杰出论文分享（受智源社区邀请）

RLVR已经成为提升大模型推理能力的关键范式，但它的训练开销较高，于是一个自然的技术就是用 LoRA 这类参数高效微调方法来做 RLVR。但是，LoRA 及其变体几乎都是在 SFT 场景下建立并验证的。而近期一系列机制研究表明，RLVR 与 SFT 的优化几何存在本质差异：RLVR 则更像一次受约束的优化，有效更新分散在稀疏的子空间中，并倾向于避开预训练权重的主方向。因此，把为 SFT 设计的先验直接搬到 RLVR 上，就构成了几何错位，后果是效果欠优、能力遗忘甚至训练崩溃。

针对这个问题，美团与北京大学的研究者提出了 GeoRA（Geometry-Aware Low-Rank Adaptation），把低秩适配显式地对齐到 RLVR 的更新几何上：先用几何先验定位出 RLVR 偏好的稀疏更新区域，再用 SVD（奇异值分解）把它压缩成低秩稠密的适配器。在 1.5B 到 32B 的 Qwen 与 Llama 模型上，GeoRA 在数学、医学、代码三类 RLVR 任务上稳定优于流行的低秩基线。该工作已被 ACL 2026 接收为杰出论文（Outstanding Paper）。

本文介绍了一种专为 RLVR 设计的低秩训练方法，以及它在业务 Agentic RL 中的落地经验。

01 背景、洞察和目标

以 OpenAI o1、DeepSeek-R1 为代表的大型推理模型，把 RLVR 确立为解锁复杂推理能力的关键范式。要理解为什么现有 PEFT 方法在这个范式下不够好，得先看清 RLVR 的更新究竟长什么样。

1.1 RLVR的优化几何

近期一批机制分析工作勾勒出了 SFT 与 RLVR 的分野，表明两者的优化几何存在本质差异：SFT 通过改写权重的主方向来显式注入新信息，RLVR 更像一次受约束的优化，它靠奖励诱导的采样偏置放大模型推理行为，有效更新分散在稀疏的子空间中，并倾向于避开预训练权重的主方向。这个画像还有另一面——RLVR 对更新稳定性敏感，它需要在类信赖域边界内做策略更新，过于激进或落在主方向上的更新则容易引发谱漂移、探索多样性坍塌乃至训练崩溃。

1.2 现有PEFT的错位

几何错位。LoRA 及其变体是当前的事实标准，它们的一个关键差异在于采用了什么谱先验：LoRA 用高斯和全零初始化，与预训练权重无关；PiSSA 对原始权重做 SVD，把可训练预算都分配给主奇异方向；MiLoRA 则取尾部奇异方向。这些先验主要在 SFT 场景下被设计和验证，没有考虑上一节描述的 RLVR 更新规律。以 PiSSA 为例，它把更新强行推到主成分上的强归纳偏置，恰好与 RLVR 偏好的子空间相冲突，这也预示了实验中更容易崩溃的现象。

工程错位。一种直观的做法是：既然 RLVR 只更新一小部分参数，那直接对这个子空间做稀疏微调就好了。这种方式在更新模式上确实更契合 RLVR 的偏好，但现代 GPU 对非结构化稀疏计算并不高效，减少参数量并不意味着效率提升。本文的效率实验里，稀疏微调把训练参数降低 68.0%，训练耗时却增加了 10.8%。

1.3 GeoRA 的目标

一边是计算友好但几何不对，一边是几何对但算不快。GeoRA 要同时解决这两个错位，目标即定位契合 RLVR 的稀疏子空间，用低秩稠密的方式去训练它。

02 方法：GeoRA 的构造

GeoRA 可以拆成三个步骤：

• 构造几何子空间：基于谱先验和欧氏先验，从预训练权重中筛出更稳定、更可塑的参数区域。
• 低秩近似构造适配器：用 SVD 对几何子空间做低秩近似，用以初始化低秩适配器。
• 建立残差锚点：将残差权重冻结，使模型初始化时函数不变，平滑冷启动并保护预训练结构。

整个过程只在训练开始前执行一次，属于一次性预处理；训练阶段的计算图与标准 LoRA 完全一致。

2.1 构造几何子空间

我们用两个互补的掩码（Mask）从预训练权重矩阵 W 中筛选参数区域，两者共用同一个稀疏率 ρ。

• 谱先验 M_Spec 强调稳定性。 先对 W 做秩为 r 的低秩近似得到 Ŵ_r，然后选出 Ŵ_r 中幅值最小的 ρ 比例位置。直觉上，主成分中的高幅值分量也是高曲率区域，改动它们容易破坏预训练结构；把更新限制在低幅值区域，可以改善 RLVR 下的谱稳定性。
• 欧氏先验 M_Euc 强调可塑性。 直接在原始权重 W 上选出幅值最小的 ρ 比例位置。这些接近零的参数在预训练中被「用得少」，可调整空间大，能为训练保留足够的自由度。

最终的几何约束矩阵取两者的并集：W_Geo = W ⊙ (M_Spec ∪ M_Euc)。

两个掩码看起来规则相似，实际选出的参数集合却很少重叠。例如，在 Qwen3-8B 上取 ρ = 0.2，两者各选中 20.0% 的参数，但交集只有 4.55%，Jaccard 相似度仅 0.128。这说明它们捕捉的是两类不同的参数区域，是互补而非冗余关系，论文中的消融实验也印证了这一点：去掉任何一个先验都会带来性能下降。

2.2 低秩近似构造适配器

拿到 W_Geo 之后，对它做 SVD：

W_Geo = U_Geo Σ_Geo V_Geoᵀ

取前 r 个奇异分量来初始化两个低秩矩阵：

A_Geo = Σ_Geo[:r,:r]^(1/2) · V_Geo[:,:r]ᵀ

B_Geo = U_Geo[:,:r] · Σ_Geo[:r,:r]^(1/2)

这样 B_Geo A_Geo 就是 W_Geo 的最优秩-r 近似（Eckart–Young 定理保证了 Frobenius 范数下的最优性）。

这里有一个容易被忽略的要点：GeoRA 取的是 W_Geo 的 top-r 方向，而不是原始权重 W 的 top-r。适配对象的变化，是 GeoRA 与 PiSSA / MiLoRA 的核心区别。

从这个角度看，四种方法的区别可以概括为一句话：LoRA 不看权重，PiSSA 看主方向，MiLoRA 看尾方向，GeoRA 先换一个更合适的适配对象，再在其中取主方向。

2.3 建立残差锚点

最后一步是把剩余权重冻结。按照 LoRA 的缩放约定计算残差矩阵：

W_res = W − (α / r) · B_Geo A_Geo

前向传播时，W_res 冻结，只有适配器可训练：

h = W_res x + (α / r) · B_Geo A_Geo x

这个设计带来两个性质。一是初始化时函数不变，因为两项之和恰好等于 W x，训练启动时模型输出不会突变，避免了冷启动阶段的策略抖动——这对 RLVR 很重要，初期的输出扰动会污染 rollout 采样分布。二是施加了结构约束：优化器只能在 A_Geo、B_Geo 参数化的流形上更新，W_res 作为稳定锚点，防止预训练表示被破坏。

03 实验验证

主实验在 DeepMath-103K 上用 GRPO 算法对 Qwen3-8B 和 Llama-3.1-8B 做数学 RLVR，对比对象包括 LoRA、PiSSA、MiLoRA、稀疏微调（SparseFT）和全参微调（FullFT）。同时在 4B 与 1.5B 模型上用 GSM8K 做了规模验证。

3.1 数学推理与分布外能力

• 在分布内（ID）的数学基准上，GeoRA 在两个骨干模型上都取得了最强的整体表现，对低秩基线的领先在竞赛难度的基准上尤为一致——Qwen3-8B 的 AIME24 达到 23.75%，甚至略高于全参微调。
• 分布外（OOD）结果更值得关注：全参微调在 IFEval、TruthfulQA 上都出现了明显回退，而 GeoRA 基本无损，HumanEval 反而从 76.83 提升到 82.93。

这说明在几何对齐的子空间更新，可以在提升目标域推理能力的同时，显著减少对既有能力的遗忘。

3.2 医学与代码领域

为了确认收益不局限于数学，我们在医学和代码场景做了扩展实验。

两个领域的结论一致：GeoRA 稳定优于低秩基线，并与全参微调相当。

3.3 收敛效率与稳定性

• 收敛效率更高。在训练动态上，GeoRA 全程保持领先，并且达到高位性能的时间点显著早于其他低秩基线。
• 超参鲁棒性更强。这里以学习率为例，GeoRA 在很宽的区间内都维持高奖励，其他方法在大学习率下明显下滑。这意味着实践中 GeoRA 无需精心超参调优。

3.4 计算效率

相比全参微调，GeoRA 使可训练参数降低 99.5%，单步耗时降低 19.9%，显存占用降低 28.5%。对照 SparseFT 的数据可以看得更清楚：它虽然把参数降了 68.0%，但单步耗时反而上升了 10.8%。GeoRA 的关键工程价值，就在于把几何先验落成了稠密低秩计算，因此参数效率能够真正转化为速度与显存收益。

3.5 低秩结构分析

我们进一步做了结构性分析：W_Geo 是一个稀疏矩阵，把它压缩成秩 r 的形式，为什么损失是可控的？我们对奇异值谱做了三组分析来回答。

• 稀疏本身不带来低秩性。作为对照，我们先构造了两个不同稠密度的随机噪声矩阵。两者的奇异值谱几乎重叠，都呈现相对平缓的衰减，说明稀疏本身依然近似各向同性，没有可利用的主方向。
• W_Geo 具有低秩特性。图中 GeoRA Weight（W_Geo）的谱形与预训练权重类似，大部分谱能量集中在少数前导分量上。这说明被选中的区域继承了结构化、可压缩的低秩形态。
• 全参 RLVR 的实际更新也是低秩的。我们直接检验了 ΔW = W_FullFT − W_Pretrain，它也呈现出高度可压缩的重尾谱。

三组分析合起来给出了 GeoRA 的结构依据：低秩特性是 RLVR 具备的内在属性。这也解释了为什么 GeoRA 只训练 0.5% 的参数就能与全参微调效果相当——它逼近的正是 RLVR 更新本身的形态。

04 业务应用

GeoRA 这个工作的出发点不是发论文，而是实际业务中对高效强化学习的需求。我们所处的场景是 AI 骑手招聘：由 Agent 主动触达和跟进候选人，在多轮沟通中识别其意愿、顾虑与决策卡点，针对性地制定下一步策略，进而把候选人逐步推进到面试和入职。过程上这需要类似于销售的情商、策略、话术和临场应变；目标和结果却明确、可验证（约面/入职/ROI），很适合用 RLVR 来优化；而这一垂直域场景也有着特别的训练需求组合：

• 基模大、上下文长。这一 Agent 对基础智能和长程能力要求较高：需要建立在大尺寸基模之上，且单条轨迹的上下文很长，强化学习的资源开销可观。
• 增量能力规模不大。垂直域需要额外构建的知识和能力规模通常不大，训练数据量远小于基模，低秩适配的容量基本足够承载。

一边是训练开销高，一边是增量容量小，这正是面向 RLVR 的低秩高效训练的用武之地。事实上，最早让我们怀疑「为 SFT 设计的低秩先验未必适合 RLVR」的，也是业务训练中的体感：LoRA、PiSSA、MiLoRA 之间效果差异明显，学习率调大训练就不稳甚至崩掉。这说明初始化的几何先验在 RLVR 下是一个大变量，存在优化空间。目前 GeoRA 正在 AI 招聘场景中落地，Agentic RL 实验效果：

效果：与全参训练相当，相比 LoRA 提升约 12%。

效率：与 LoRA 相当，显存相比全参训练降低 54%，若配合 QLoRA 等量化方法可进一步降低。

可见，GeoRA 用 LoRA 的训练成本取得了全参的优化效果，这正是它的应用价值。

落地时还有两点经验，也供同样想在 RLVR 中应用的同学参考：

• 随机 SVD 初始化。SVD 初始化是一次性的预处理，并且由于只需要前 r 个奇异分量，可以用随机 SVD（Randomized SVD）加速，即用随机投影把矩阵压到一个小得多的空间去做分解，即使 72B 模型处理也只需不到 1 分钟。
• 省略参考模型存储。RLVR 需要一个参考策略来算 KL，常规做法是再存一份完整权重。而 2.3 节的函数不变性质给出了免费的替代方案：原始权重 = 残差权重 + 初始适配器，因此只要在 actor 内多留一份冻结的初始适配器（低秩，开销很小），就能现算出准确的参考策略。

05 总结

GeoRA 是首个面向 RLVR 的优化几何设计的低秩训练方法，其核心贡献可以归纳为三点：

• 揭示了 RLVR 更新的结构：RLVR 的更新子空间稀疏但各向异性可压缩，这是低秩适配成立的前提。
• 提出定位加压缩的适配方法：用谱先验与欧氏先验定位 RLVR 偏好的更新区域，再用截断 SVD 压缩为低秩适配器、冻结残差作锚点，这避免了几何错位与稀疏计算的效率瓶颈。
• 广泛实验验证了优越性能：从 1.5B 到 32B 的模型，在数学、医学、代码场景的 RLVR 上验证方法稳定优于基线，分布外遗忘更少，兼具速度与显存的优越性。

除论文实验之外，GeoRA 也在实际业务场景 Agentic RL 中验证，以更低的成本取得更好的训练效果。我们会继续把它推广到更多同类场景，也希望该方法能为 RLVR 的高效训练提供一个新的参考。