1. 多模态轨迹生成到底难在哪做自动驾驶规划的人看到“纯规划434FPS”这个数字第一反应通常是不太敢信。过去几年业内为了把轨迹生成的延迟压进30毫秒不知道折腾了多少轮。现在MeanFuser直接把规划模块干到每秒400多帧相当于单帧耗时2.3毫秒左右还是在多模态生成的前提下。这个结果出现在CVPR‘26上来自自动化所和小米的联合工作核心卖点就是极速、单步、多模态轨迹生成。对做决策规划、预测、以及部署的朋友来说这基本是必须认真看一遍的工作。先说明这篇文章的定位它不是讲感知也不是讲端到端大模型而是聚焦在“规划”这一步解决的是从场景理解到轨迹生成这一段怎么才能又快又稳。适合三类人读一是做自动驾驶预测与规划算法的二是正在做车端推理部署的三是对生成式模型在机器人任务里落地感兴趣的。读之前你不需要太深的扩散模型基础但如果你知道一点点去噪扩散、流匹配这些概念理解起来会顺很多。1.1 为什么不能只输出一条轨迹很多刚接触轨迹规划的人会问规划不就是算一条最优路径吗实际不是。真实路况下一个自车状态和一张矢量地图对应着太多合理的未来行为。直行可能要让行、可能加速通过左转可能走大弯、可能走小弯旁边有骑手时还要考虑什么时候避让。这些行为在时间轴上是互斥的但在规划时刻都合理最终选哪条取决于下游的安全校验和决策策略。如果模型只给一条轨迹遇到长尾场景很容易直接“锁死”在一个错误意图里连纠偏的机会都没有。所以多模态轨迹生成要解决的是给定同样的感知输入一次性输出若干条候选轨迹每一条代表一种可行的驾驶意图并且要在空间和时间上合理。理想情况下这几条轨迹的分布能覆盖真实道路结构同时不能出现“生成一堆但全是同一套路”的退化问题。MeanFuser这类工作本质上就是冲着“又快又多模态”这个矛盾去的。1.2 传统方案的三大痛点过去做多模态轨迹生成最有代表性的就是基于扩散模型的方法。扩散模型在图像生成领域已经把单步生成的效率问题冲得很厉害了但把它搬到自动驾驶轨迹生成上还是有几个老毛病。第一迭代去噪的延迟太高。标准扩散要做几十步甚至上百步采样每一步都要过一次神经网络。轨迹生成场景里输入维度不高单次前向不算太慢但乘上采样步数实时性就很紧张。有的方案压缩到8步、4步可一旦加入碰撞约束、车道约束等后处理预算又超了。第二两阶段方案割裂。很多工程方案是先让预测模块生成几百条候选再用一个打分网络去挑选然后交给优化器平滑才能得到最终轨迹。这个流程在篮球赛里等于“先全队瞎跑再教练挑人”候选再多跑偏了也救不回来。而且两阶段的训练要分别维护两个模型数据和损失函数很难对齐。第三模式坍缩非常容易。用常规的回归损失训练多模态生成器模型会倾向于输出所有模态的均值结果就是几条轨迹粘在一起毫无区分度。这也是为什么早期很多轨迹预测模型输出K条轨迹时实测NAC指标不差但可视化之后发现全是重合线。2. MeanFuser的设计思路拆解MeanFuser的名字其实已经把核心思路写出来了MeanFuser一个跟“均值”有关一个跟“融合”有关。它不是简单地把多条轨迹求个平均而是把多模态分布压缩成显式可控制的表示再用高效生成器一步到位地还原出多条候选轨迹。2.1 名字里的信息MeanFuser到底融合了什么按我对这一类方法的理解MeanFuser应该是把多模态预测问题拆分成了两个阶段先用一个轻量的场景编码器理解当前环境再把场景中不同类型的信息矢量地图、动态障碍物、自车状态、道路拓扑融合成一组潜变量。这个潜变量不能只是一个向量得是一组分量的集合每个分量对应一个可能的驾驶意图。这里最关键的创新点我猜测是“可学习的均值表示”。常见的多模态生成模型比如CVAE是让隐变量z服从先验分布然后采样后丢给解码器。问题是采样的随机性很难控制而且解码器经常忽略z导致生成结果不受隐变量影响。MeanFuser的做法很可能反过来先预测K个均值表示也可以理解成K个“意图原型”再让生成器基于这些均值表示直接生成K条轨迹随机性被压缩在训练阶段推理阶段完全确定。这么做的好处显而易见推理时不需要采样随机噪声避免了“抽卡”一样的不确定性均值表示本身就是对多模态分布的一种结构化建模训练起来比纯隐变量稳定得多。说白了它把“模糊的分布”换成了“明确的几个锚点”再用一个强生成器把锚点展开成真实轨迹。2.2 单步生成如何替代逐步去噪单步生成是MeanFuser最吸引人的地方。这里要澄清一个概念单步生成不是说模型只有一个网络层而是整个生成过程只需要一次前向计算。传统扩散模型里的去噪过程是从纯噪声开始一点一点地把结构“雕刻”出来。单步方法想干的事情是让网络学会直接输出那条最终结果跳过多步迭代。行业内做单步生成主流路线有三种蒸馏、一致性模型、流匹配的直方图/直线化。MeanFuser团队最终选哪种论文里应该有详细说明。从我这边经验看如果目标是“极速稳定”基于流匹配的简化版本往往更好训因为它的训练目标比一致性损失更直观也不会像蒸馏那样容易被源模型的质量瓶颈卡死。单步生成的难点在于模型要在一次前向里同时完成“理解场景”和“细化轨迹”两件事。所以输入特征不能只给个目标点必须把地图的拓扑关系、历史轨迹的动态特征都压进高维向量里。推理时从场景编码到K条轨迹输出整个过程就是一次前向没有任何循环这也是FPS能冲高的底层原因。2.3 多模态条件怎么注入条件注入决定生成器能不能真正利用场景信息。我在复现类似方案时最怕的是模型把地图条件当成噪音忽略掉只顾着按训练集统计分布“背答案”。MeanFuser应该采用了一种比较强的条件机制。具体来说场景编码器分别提取矢量地图中车道线的几何信息、邻居车相对位置与速度、红绿灯状态等然后用注意力机制把这些特征交互起来。每一层交互之后再和均值表示做一次融合保证K个意图原型都能看到“同一份道路结构但关注不同区域”。比如直行意图的潜变量会更关注前方车辆间距变道意图的潜变量会更关注目标车道的占用情况。训练时需要用真实轨迹给每个均值表示分配监督信号。通常的做法是计算每条真值轨迹和K个原型之间的匹配代价用匈牙利算法或最优传输做一对多分配。这样每个均值表示只负责一类轨迹模式不会出现两个原型抢同一批样本、另外几个原型没人认领的情况。3. 434FPS和纯规划性能是怎么测出来的434FPS这个数字很抢眼但脱离测量口径谈性能就是耍流氓。这里说的434FPS单位是“规划模块每秒能处理的帧数”属于纯规划吞吐不是端到端系统延迟的倒数。搞清楚这个口径你才能判断它有多大价值。3.1 FPS口径从端到端延迟到纯规划吞吐先做一个简单换算434FPS意味着平均每帧处理耗时约2.3毫秒。如果你的规划模块运行周期是20毫秒那它只占了11.5%的预算剩下的时间可以留给感知、后处理、安全校验和底盘控制。但如果有人告诉你“全系统434FPS”那是不可能的因为感知和渲染通常要比规划重得多。“纯规划”的意思是指测试时只统计从“场景编码输入”到“轨迹输出”这一段。感知预处理的时间、可视化时间、日志写入时间都不算在里面。这种口径在论文里很常见但工程落地时要小心真实系统里上游给它一个场景表示可能就需要10毫秒下游碰撞检测再花几毫秒整体延迟肯定不是2.3毫秒。我做部署测试时一般会同时测几个指标单帧延迟一次推理从输入到输出、吞吐固定batch下每秒处理帧数、以及P99延迟。MeanFuser的434FPS更像最大吞吐实际系统里要留余量不能拿峰值去做控制周期预算。尤其是车端芯片的降频、内存带宽波动都会让P99比平均差很多。3.2 与主流方法的性能对比如果把MeanFuser和几个典型方案放在一起比性能优势会更直观。下面这张表里的量级是我按常见实现和公开数据整理的具体数值以正式论文为准但比值关系是可以参考的方法类型采样/推理方式平均单帧耗时多模态能力主要瓶颈扩散规划器DDPM数十步迭代去噪50-100ms强延迟太高实车预算不够扩散规划器加速版DPM-Solver4-8步求解15-30ms强步骤多了仍偏慢步骤少了会丢细粒度约束两阶段候选生成打分先生成候选再筛选20-60ms中模块割裂候选质量依赖第一阶段MeanFuser式单步生成1次前向约2.3ms强训练难度高对场景编码质量敏感能看到单步方案的最大价值是把“多模态能力强”和“延迟低”两个指标同时做到了。之前大家普遍觉得必须做折中要多模态就得多采样想快就只能退化成单峰回归。MeanFuser展示的路线是把多模态能力提前融进特征和均值表示里推理时一次前向就能还原出全部模态。3.3 在车端部署的约束性能跑到实验室和跑到车上是两码事。434FPS大概率是在单张桌面级GPU上测出来的比如A100或者4090。车端平台的算力通常小一个量级Orin、Thor这类芯片跑相同模型FPS会明显下降。但只要模型结构合理、算子不冷门用TensorRT或者转化精度到FP16后也依然可以做到几十甚至上百FPS。关键是别把模型里那些动态shape、自定义算子带到部署阶段。实际工程里我遇到过很多“论文FPS很好看导出TensorRT却跑不动”的坑根源一般是几个用了比较小众的算子导致插件回退、轨迹数量K设置过大导致后处理成为瓶颈、或者输出层把几百条轨迹全部做nms导致CPU-GPU同步频繁。MeanFuser这类单步模型如果K值控制在6到10条后处理的负担其实非常可控这是它的潜在工程优势。4. 从论文到实践复现与接入的关键环节理论再漂亮落地才算数。我按照常见实践思路把复现和接入MeanFuser这类单步多模态规划器的关键环节拆出来结合我踩过的坑一起说。4.1 训练数据与标签构造多模态轨迹生成的学习目标不是一条轨迹而是一组轨迹。数据层面首先得解决“真值多模态从哪来”的问题。公开自动驾驶数据集一般每帧只提供一个真值未来轨迹这是单一模态的。要得到多模态监督信号常见做法是把一个场景里不同时间、不同车辆、不同意图的轨迹聚类聚合出几类典型行为再作为训练标签。我处理过的方案里常用的是两步先按目标车道、转向行为、速度曲线做粗略分组再在每个组内用K-Means或最优传输做轨迹聚类生成K簇中心作为原型初始化。MeanFuser里的“Mean”部分很可能就是从这里得到的灵感用每一簇的均值轨迹作为该模态的代表而不是随机初始化隐变量。训练时要注意标签不均衡。左转轨迹可能只占5%但如果模型生成的5条轨迹里没把它覆盖到NACneed accuracy指标就很难看。解决思路是给低频率模态更大的匹配权重或者调整采样策略让每帧真值在不同epoch里绑到不同原型上。你直接复制损失函数而不处理标签均衡大概率会把低频行为丢掉。4.2 损失函数与训练技巧单步生成器的训练本质上是一个“用一次前向逼近多模态分布”的优化问题。典型损失组合包含三块回归损失、分布损失、约束正则。下面给一段我常用的伪代码框架你可以按MeanFuser论文里的实际损失替换# 伪代码单步多模态轨迹生成训练逻辑 # pred: [B, K, T, 2] 预测的K条轨迹 # gt: [B, T, 2] 真值轨迹 # scene_feat: [B, D] 场景编码 # 1. 用匈牙利算法匹配每个真值到最优预测轨迹 match_idx hungarian_matching(pred, gt) # shape [B, K], 每帧K条轨迹各自匹配 # 2. 回归损失只让匹配到的轨迹去学真值 reg_loss 0 for k in range(K): mask (match_idx k).float() # 哪些帧的pred[k]匹配真值 mask mask.unsqueeze(-1).unsqueeze(-1) # 对齐维度 reg_loss smooth_l1_loss(pred[:, k], gt, reductionnone) * mask # 3. 分布损失让预测轨迹的概率分布贴近先验意图分布 intent_logits model.intent_head(scene_feat) # [B, K] dist_loss cross_entropy(intent_logits, match_onehot_for_each_frame) # 4. 约束正则用可微代价函数惩罚碰撞、驶出道路的轨迹 constraint_loss differentiable_safety_cost(pred, lane_polylines, agents) loss reg_loss.mean() 0.1 * dist_loss.mean() 0.01 * constraint_loss.mean()这段代码里匈牙利匹配是关键。如果不做匹配直接用MSE让每条预测轨迹都去逼近真值模型一定会收敛到“所有轨迹都是平均线”模态全丢。分布损失则是为了让intent_logits能反映真实意图分配情况避免匹配到的原型在训练中频繁切换。训练过程中单步模型最容易出现的问题就是“追求平均导致退化成单模态”。我试过最有效的手段是提高分布损失的权重同时给每条预测轨迹加一个自车初始位置的约束让K条轨迹至少起点一致、末端分开。另外真值聚类中心作为原型初始化很重要。随机初始化原型会让训练前期匹配关系不停抖动损失曲线像心电图一样上下跳。4.3 推理阶段实现细节推理阶段的理想流程是这样拿到上游的场景表示后模型一次前向输出K条轨迹和一个意图置信度。随后做轻量后处理比如把超出道路边界的轨迹裁剪、把碰撞轨迹过滤、按置信度排序最后输出给下游控制器。整个过程由于没有循环生成特别适合用标准推理框架优化。部署时我会做下面几个动作。先保证输入输出shape固定把K值固定不要用动态循环。然后用TensorRT做FP16转换如果模块算力紧张可以再把场景编码器量化成INT8轨迹生成头保持FP16这样精度损失会小很多。测量FPS时要先跑50轮warm-up再取500帧以上的平均耗时最好还要记录P95和P99因为自动驾驶场景里平均值不危险偶发的卡顿才危险。另外最好不要把轨迹生成器和碰撞检测用CUDA Graph硬绑定在一起除非你确认每个batch的候选数量始终一致。我在实际项目中吃过亏候选轨迹数不一致导致碰撞检测用了动态shapeCUDA Graph反复重捕获帧率直接掉了一半。5. 常见问题与排查实录不管你是复现论文还是把这类单步规划器接入自己的系统有几类问题几乎一定会遇到。我按实战经验整理成速查表下面逐个展开讲。5.1 训练发散损失曲线忽高忽低单步生成器训练发散最常见的元凶是匹配关系不稳定。匈牙利匹配在训练初期会频繁切换索引今天真值轨迹被分到第0个原型明天又分到第3个原型梯度方向反复横跳。出现这种情况先不要调学习率先把原型初始化改成聚类中心再把匹配部分做成“冻结匹配回传梯度”让匹配关系在warm-up阶段固定几百步。还有一种情况是分布损失和回归损失的尺度不对等。回归损失量级通常是0.1到10交叉熵损失通常在0到1之间直接相加的话分布损失根本不起作用。我一般会给分布损失一个较大的系数比如1.0到5.0或者先单独预训练场景编码器再端到端微调。5.2 模式坍缩生成的轨迹全部重合模式坍缩是轨迹生成行业的老朋友了。如果你发现K条预测轨迹起点和终点都重在一起先查两件事一是匹配损失是否被平均掉了二是原型表示之间是否缺少多样性正则。针对第二个问题我建议在损失里显式加一项“原型间距正则”让K个均值表示在特征空间互相远离。简单实现是用余弦相似度惩罚矩阵对角以外的元素让任意两个原型的向量夹角至少超过一个阈值。实测下来这一项能把轨迹重合率从60%降到10%以下。训练集里如果某个场景只有单一行为真值也要小心。比如高速巡航所有真值都沿着车道中心线走K条轨迹完全重合其实是对的。这时候不要强行让轨迹分开而是看它在复杂路口场景下的重建能力。模式坍缩不能只看一个整体指标要按场景分层评估。5.3 指标好看但实车抖动这是部署中最头疼的问题离线指标一切正常FPS也达标上了实车却发现输出轨迹在相邻控制周期里来回跳。原因通常是单步模型对输入噪声非常敏感上游感知结果有一点波动生成轨迹就会在几个模态之间横跳。这不是模型“坏了”而是它过于灵敏地响应了输入变化。解决思路有三层。第一层在输入端做状态平滑比如用卡尔曼滤波处理自车速度、前车位置。第二层在输出端加时间域平滑项把上一帧轨迹的末段作为当前帧的起点约束。第三层更彻底的办法是加一个“意图锁存器”如果相邻两帧的意图置信度没有明显反转就不允许切换到另一个模态。我实际验证过第三个方法对消除轨迹抖动最有效代价是会引入最多50到100毫秒的意图切换延迟但车内体感会稳定很多。现象优先检查常用解决手段损失震荡不收敛匹配不稳定、损失尺度失衡固定匹配warm-up调节损失权重轨迹重合无多样性原原型退化、缺少正则聚类初始化加原型间距正则实车轨迹跳变输入噪声敏感、意图切换频繁状态平滑输出平滑意图锁存导出部署变慢动态shape、小众算子固定K值替换算子FP16重测低频行为丢失数据不均衡、匹配权重失控低频模态加权调整聚类簇数碰撞检测拖后腿后处理与模型耦合过紧解耦后处理CUDA Graph单独优化5.4 后处理与安全校验建议最后聊一下单步生成器下游的环节。模型输出K条轨迹之后一定不能直接发给执行器。安全校验至少要包含这几步道路边界检查、碰撞检查、动态可行性检查、舒适性检查。碰撞检查不要只查当前帧要沿轨迹时间轴扫多个采样点考虑障碍物速度预测的不确定性。偏差发生在“纯规划FPS很高”和后处理“FPS很低”之间。很多团队把时间都花在加速模型结果后处理里一个用Python写的轨迹扫掠碰撞检测成了瓶颈。建议把后处理也用C或者CUDA重写或者用层次化策略先用AABB粗筛再用精确几何检测最后做时空安全检查。这样才能把MeanFuser省出来的那十几毫秒真正留给安全冗余和底盘执行。我个人在实际操作中的体会是MeanFuser这类单步多模态方法最大的价值不是那434FPS本身而是它把这个矛盾解开了多模态能力不需要靠多次推理堆出来。之前做轨迹规划代码里到处都在平衡采样步数和延迟模型一多部署就变得很脆。单步生成的思路让我把注意力从“怎么把推理跑快”转移到“怎么让特征表达更准”上这件事对工程效率的影响比数字看起来大得多。最后再分享一个小技巧如果你们团队准备复现或改造MeanFuser建议先不追性能先把K4的配置完整复现到真值聚类、匹配、单步训练全链路跑通再逐步拉高K和场景复杂度。K值越大匹配的稳定性越难控制等把K4的细节都吃透了再去碰高难配置会比直接上手省下很多排查时间。多模态轨迹生成这条赛道以后大概率还会有更快、更稳的方案出来但单步化这个方向从我目前看到的结果来说已经值得写进下一版规划架构的技术选型候选清单了。