具身智能这个圈子最近有个现象挺有意思打开任何一个机器人学习相关的技术群十篇论文分享里至少有六篇在讲Flow Matching。做运动规划的、做抓取策略的、做VLA动作头的好像不挂上Flow Matching这个词就不好意思发出来。与此同时Diffusion Policy那套东西似乎一夜之间从标配变成了上一代方案。但真实情况到底是什么Flow Matching真的全面取代Diffusion了吗还是说这只是一波学术圈的跟风潮我自己在过去大半年里从零复现过Diffusion Policy也在几个机械臂操作任务上跑过Flow Matching的训练和推理踩过的坑不算少。这篇文章不打算给你一个谁赢谁输的简单结论而是把这两个东西在具身智能场景下的真实差异、各自的适用边界、以及实际落地时那些论文里不会写的细节一条一条拆开讲清楚。如果你正在选型、正在复现、或者正在纠结要不要把手头的Diffusion方案换掉这篇内容应该能帮你省下不少试错时间。1. 流匹配在具身智能里到底解决了什么痛点1.1 从Diffusion Policy的推理瓶颈说起Diffusion Policy在2023年前后几乎成了机器人策略学习的默认范式。它的核心思路很直观把动作序列的生成建模成一个去噪过程从纯噪声出发经过多步去噪最终得到一条可执行的动作轨迹。这个思路在图像生成领域已经被验证得非常充分搬到机器人动作生成上效果也确实不错——多模态分布拟合能力强训练稳定对演示数据的利用效率高。但问题出在推理速度上。标准的DDPM需要几十甚至上百步去噪即使用DDIM加速通常也要10到20步。对于机械臂控制来说这意味着每次决策要跑10到20次完整的网络前向。如果你的控制频率是10Hz那勉强能撑住但如果要做高频力控或者灵巧手操作需要50Hz甚至100Hz的决策频率Diffusion Policy的推理延迟就成了硬伤。我当初在一个UR5机械臂上跑Diffusion Policy做插孔任务控制频率设到20Hz单次推理在RTX 4090上大约需要35毫秒。听起来还行但加上传感器读取、坐标变换、安全校验这些环节整个控制循环就超过了50毫秒实际控制频率掉到了15Hz左右。插孔这种需要精细力反馈的任务15Hz的响应明显感觉迟钝接触瞬间的力控调整跟不上。1.2 Flow Matching的核心思路把去噪换成走直线Flow Matching的思路和Diffusion有本质区别。Diffusion是从噪声一步步去噪而Flow Matching是从噪声沿一条路径直接流向目标。具体来说Flow Matching训练一个速度场velocity field这个速度场定义了一个常微分方程ODE从初始噪声出发沿着这个ODE积分就能到达目标动作分布。关键区别在于Flow Matching的路径可以是直线的。在最优传输Optimal Transport意义下Flow Matching可以学到一个近似直线的概率路径这意味着从噪声到目标只需要很少的积分步数——理论上甚至可以一步到位。这里说的直线是概率路径意义上的直线不是指动作轨迹本身是直线。概率路径描述的是分布如何从噪声分布变换到目标分布和动作的空间形状是两回事。这个特性直接击中了Diffusion Policy的推理瓶颈。我后来在同一个UR5插孔任务上换成Flow Matching用10步欧拉积分单次推理降到了8毫秒左右控制频率轻松跑到50Hz。而且因为路径更直即使用5步积分动作质量也没有明显下降。1.3 为什么具身智能社区对推理速度如此敏感很多人可能会问图像生成慢一点无所谓为什么机器人控制对推理速度这么敏感原因在于闭环控制的本质。机器人不是生成一张图就完事而是生成动作→执行→观察结果→再生成动作的循环。这个循环的频率直接决定了系统能处理多快的动态变化。对于抓取移动物体、插孔、拧螺丝、折叠衣物这类任务环境状态在几十毫秒内就会发生变化如果策略推理太慢等你算出动作物体已经不在原来的位置了。另外具身智能的部署场景往往是边缘设备。你不可能在每个机器人上都装一张4090。在Jetson Orin这样的边缘计算平台上Diffusion Policy的多步推理会变得非常吃力而Flow Matching的少步推理优势就更加明显。我在Jetson Orin AGX上做过对比测试同样的任务Diffusion Policy用DDIM 10步推理需要120毫秒左右Flow Matching用5步欧拉积分只需要45毫秒。这个差距在边缘部署场景下是决定性的。2. 拆开看Flow Matching和Diffusion在动作生成上的真实差异2.1 训练目标的数学差异与直觉理解Diffusion的训练目标是让网络学会预测噪声或者预测去噪后的样本。具体来说给定一个干净的动作序列$a_0$在时间步$t$加入噪声得到$a_t$网络学习从$a_t$中恢复出$a_0$或者预测加入的噪声$\epsilon$。这个过程需要定义一个噪声调度noise schedule通常是余弦调度或者线性调度。Flow Matching的训练目标则是让网络学会预测速度。给定噪声$a_1$和目标动作$a_0$构造一条从$a_1$到$a_0$的路径网络学习这条路径上的速度场$v(a_t, t) da_t/dt$。最简单的路径是直线路径$a_t (1-t)a_1 t \cdot a_0$对应的速度就是$a_0 - a_1$一个常数。用生活化的类比Diffusion像是从一团迷雾中一步步走出来每一步都要判断我现在离目标还有多远Flow Matching像是直接朝着目标方向走速度场告诉你往哪个方向走、走多快。这个差异带来的实际影响是Flow Matching的训练目标更简单、更稳定。因为速度场在直线路径下是常数网络不需要学习复杂的噪声调度相关的变化。我在实际训练中发现Flow Matching的loss曲线比Diffusion平滑得多收敛也更快通常少用20%到30%的训练步数就能达到差不多的效果。2.2 推理步数与动作质量的实际权衡理论上Flow Matching可以一步生成但实际中一步生成的动作质量往往不够好。原因在于虽然训练时路径是直线但网络学到的速度场是有误差的一步积分会把所有误差累积到最终结果上。多步积分相当于用数值方法求解ODE步数越多对速度场的利用越充分误差越小。我在PushT任务上做过一组对比实验固定网络结构和训练数据只改变推理步数推理方法步数任务成功率单次推理延迟RTX 4090DDPM10078%320msDDIM2076%68msDDIM1072%35msFlow Matching欧拉1079%28msFlow Matching欧拉577%15msFlow Matching欧拉371%10msFlow Matching欧拉152%4ms从这组数据能看出几个关键点Flow Matching在10步时的成功率和Diffusion的100步相当但速度快了10倍以上5步时仍然保持了不错的成功率这是Diffusion很难做到的但1步生成的成功率断崖式下跌说明一步到位在复杂任务上还不现实。实际选型时我通常建议Flow Matching用5到10步。3步以下只在任务非常简单、动作维度很低的情况下考虑。1步生成目前更适合作为快速草稿后面再接一个精修网络。2.3 多模态动作分布的拟合能力对比Diffusion Policy的一个核心卖点是多模态拟合能力——同一个观测下可能有多种合理的动作Diffusion能很好地覆盖这些模态。比如面对一个杯子你可以从左边抓也可以从右边抓Diffusion会学到这两个模态。Flow Matching在这方面理论上不输Diffusion因为两者都是在建模整个分布。但实际中有一个微妙差异Flow Matching的直线路径假设在训练时会对多模态分布做平均如果两个模态之间的区域没有数据支撑直线路径会穿过这个空白区域导致学到的速度场在中间区域不可靠。这个问题在实操中表现为当初始噪声落在两个模态中间时Flow Matching生成的动作可能会卡在中间既不是左边也不是右边而是一个不合理的中间状态。Diffusion因为是多步去噪每一步都在做选择反而不容易卡在中间。我的应对方法是在训练时增加模态标签或者使用条件Flow Matching让网络知道当前应该走哪个模态。另外增加训练数据的模态覆盖度也能缓解这个问题。如果任务本身模态很丰富建议还是用Diffusion或者增加Flow Matching的推理步数。3. 具身智能项目里Flow Matching的落地实操3.1 网络结构选型动作头怎么设计在具身智能场景下Flow Matching通常不是单独使用的而是作为一个动作头接在视觉编码器或者VLM后面。常见的结构是视觉观测经过编码器提取特征然后Flow Matching网络以这些特征为条件生成动作序列。网络结构的选择上我试过几种方案MLP-based最简单把观测特征和噪声动作拼接后送入几层MLP。适合动作维度低、任务简单的场景。训练快推理快但表达能力有限。Transformer-based用交叉注意力让动作token关注观测特征。适合动作维度高、需要长时序建模的场景。我目前在用的方案在灵巧手操作任务上效果明显好于MLP。UNet-basedDiffusion Policy的经典结构搬到Flow Matching上也能用。但UNet的参数多推理慢在Flow Matching的少步推理优势下UNet的推理开销反而成了瓶颈。如果追求推理速度优先考虑MLP或轻量Transformer。UNet在Flow Matching场景下性价比不高除非你的动作维度特别高比如双臂灵巧手动作维度超过50。具体到Transformer动作头的设计我的配置是观测特征作为key和value动作token作为query做4层交叉注意力每层8个注意力头隐藏维度256。动作token的数量等于预测的动作序列长度比如预测未来16步动作就用16个token。时间步$t$通过正弦位置编码注入到每个动作token中。3.2 训练细节路径设计、损失函数与优化器Flow Matching的训练循环比Diffusion简单不少。核心步骤就四步从演示数据中采样一个动作序列$a_0$采样一个时间步$t \sim U(0,1)$采样噪声$a_1 \sim \mathcal{N}(0, I)$构造直线路径上的点$a_t (1-t)a_1 t \cdot a_0$计算目标速度$v^* a_0 - a_1$网络预测速度$v_\theta(a_t, t, \text{obs})$损失为$|v_\theta - v^*|^2$损失函数就是简单的MSE不需要像Diffusion那样对噪声调度做加权。优化器我用AdamW学习率3e-4weight decay 1e-4batch size 256。训练步数根据任务复杂度简单任务5万步左右复杂任务20万步。有几个训练细节值得注意时间步采样策略均匀采样$U(0,1)$是最简单的但实际中我发现对$t$靠近0和1的区域增加采样密度能提升效果。因为这两个区域对应接近噪声和接近目标的状态网络在这些区域的速度场精度对最终生成质量影响最大。我通常用Beta分布采样$t$参数设为(2, 2)让采样更集中在两端。噪声尺度标准Flow Matching用的是标准高斯噪声但在动作生成场景下动作的尺度通常很小比如关节角度变化在0.1弧度以内。如果直接用标准高斯噪声噪声的尺度和动作尺度不匹配网络需要学习一个很大的速度场。我的做法是把噪声尺度缩放到和动作数据相同的量级这样速度场的数值范围更合理训练也更稳定。EMA的使用和Diffusion一样Flow Matching也受益于指数移动平均EMA。我用EMA decay 0.999在推理时使用EMA参数生成的动作明显更平滑。3.3 推理加速从10步到3步的工程技巧虽然Flow Matching本身已经比Diffusion快很多但在实际部署中进一步压缩推理步数仍然很有价值。我总结了几个有效的技巧技巧一自适应步长。欧拉积分用固定步长但速度场在不同区域的变化率不同。在速度场变化快的区域用小步长变化慢的区域用大步长可以在保持精度的同时减少步数。实现上可以用简单的启发式根据相邻两步速度场的差异动态调整步长。技巧二蒸馏。用一个已经训练好的多步Flow Matching模型作为教师训练一个少步学生模型。学生模型直接学习从噪声到目标的映射跳过中间的积分步骤。我试过用10步教师蒸馏到3步学生成功率只下降了2个百分点但推理速度快了3倍。技巧三缓存观测特征。在很多任务中视觉观测的变化频率远低于动作决策频率。如果观测没有显著变化可以复用上一帧的观测特征只重新跑动作生成部分。这个技巧在控制频率高、视觉变化慢的任务上能省下不少计算。蒸馏虽然有效但需要额外的训练流程和超参调优。如果项目时间紧优先用自适应步长和特征缓存这两个无训练技巧。4. 实际项目中的选型决策什么时候用Flow Matching什么时候留Diffusion4.1 任务维度与控制频率的决策矩阵选型不是哪个新用哪个而是要看具体任务的需求。我整理了一个决策矩阵供参考任务特征推荐方案理由控制频率10Hz动作维度10Diffusion Policy推理速度不是瓶颈Diffusion生态成熟控制频率10-30Hz动作维度10-20两者皆可Flow Matching略优但Diffusion也能用控制频率30Hz动作维度20Flow Matching少步推理优势明显任务模态非常丰富Diffusion或条件Flow Matching纯Flow Matching可能卡在模态中间边缘设备部署Flow Matching计算量小适合Jetson等平台需要快速原型验证Diffusion Policy开源实现多调参经验丰富这个矩阵不是绝对的但能帮你快速缩小选型范围。我的经验是如果你的任务对推理速度没有硬性要求Diffusion Policy仍然是更稳妥的选择因为它的开源生态更成熟遇到问题更容易找到解决方案。但如果你要做高频控制或者边缘部署Flow Matching的优势就很难忽视了。4.2 从Diffusion迁移到Flow Matching的实操路径如果你决定从Diffusion迁移到Flow Matching不需要从头重写整个pipeline。大部分代码可以复用主要改动在三个地方第一替换训练目标。把Diffusion的噪声预测损失换成Flow Matching的速度预测损失。网络结构基本不变只是输出层的含义从预测噪声变成预测速度。第二替换推理循环。把多步去噪循环换成ODE积分循环。如果用欧拉积分代码量比DDIM还少。第三调整超参数。学习率、batch size、训练步数都需要重新调。Flow Matching通常可以用稍大的学习率收敛也更快。我实际迁移一个Diffusion Policy项目到Flow Matching代码改动大约200行训练时间从3天缩短到1.5天推理速度提升了4倍。但需要注意的是迁移后需要重新做一轮超参搜索不能直接套用Diffusion的超参。4.3 那些论文不会告诉你的坑最后分享几个我在实操中踩过的坑这些在论文里基本不会提坑一动作归一化。Flow Matching对动作的尺度很敏感。如果不同维度的动作尺度差异很大比如关节角度是0.1量级夹爪开合是0.01量级训练会不稳定。我的做法是对每个动作维度单独做归一化推理时再反归一化。坑二时间步编码。Flow Matching的时间步$t$是连续值位置编码的频率范围需要根据实际训练的时间步分布来调整。如果编码频率范围设得太宽网络对$t$的分辨率会下降设得太窄又会丢失时间信息。我通常用10个频率范围从1到1000。坑三推理时的初始噪声。Flow Matching的初始噪声分布应该和训练时一致。如果训练用标准高斯推理时也用标准高斯。我见过有人推理时用均匀分布结果动作质量大幅下降。坑四多步积分的数值稳定性。欧拉积分在步数很少时可能不稳定特别是当速度场的 Lipschitz 常数较大时。如果发现生成的动作有跳变可以换成中点法或者RK4但计算量会增加。折中方案是用欧拉但限制每步的最大变化量。坑五和VLM的接口。现在很多工作把Flow Matching动作头接在VLM后面。这里有个细节VLM输出的特征维度通常很大比如4096而动作头的隐藏维度可能只有256。直接做交叉注意力会导致计算量爆炸。我的做法是先用一个线性层把VLM特征降到256维再做注意力。这个降维层需要和动作头一起训练不能冻结。5. 具身智能学习路线中Flow Matching的定位5.1 先学Diffusion还是先学Flow Matching如果你刚开始入具身智能这个方向我的建议是先学Diffusion再学Flow Matching。原因有三第一Diffusion的数学框架更成熟理解Diffusion有助于建立对生成模型的基本直觉。Flow Matching的很多概念比如概率路径、速度场在Diffusion里都有对应先学Diffusion能降低理解难度。第二Diffusion的开源资源更丰富。Hugging Face的diffusers库、Diffusion Policy的官方实现都是很好的学习材料。Flow Matching的开源实现相对分散质量参差不齐。第三Diffusion的调参经验更通用。理解了噪声调度、采样步数、引导尺度这些概念迁移到Flow Matching上会容易很多。但如果你已经有Diffusion的基础那直接上手Flow Matching完全没问题。Flow Matching的训练循环比Diffusion简单代码量也更少一两天就能跑通一个demo。5.2 从Diffusion Policy到Flow Matching的进阶路径我给一个具体的学习路径按这个顺序走大概两到三周能建立起完整的认知第一周复现Diffusion Policy在PushT或Robomimic上的baseline。重点理解观测编码、动作序列生成、多步去噪这三个环节。第二周把Diffusion Policy的去噪循环换成Flow Matching的ODE积分。保持网络结构不变只改训练目标和推理循环。对比两者的成功率和推理速度。第三周尝试把Flow Matching动作头接到一个预训练的VLM后面。可以用开源的VLM比如CLIP或SigLIP作为视觉编码器训练一个简单的Flow Matching动作头。这一步能帮你理解VLMFlow Matching的接口设计。走完这三步你对Flow Matching在具身智能里的应用就有了实操级别的理解而不是停留在看过论文的层面。5.3 当前技术栈的局限与未来可能的方向Flow Matching不是万能的。它目前最大的局限在于对多模态分布的处理不如Diffusion稳健少步推理的精度损失在复杂任务上仍然明显和VLM的结合还处于早期阶段。从社区的趋势看接下来可能会有几个方向的发展一是Flow Matching和Diffusion的混合方案用Flow Matching做快速草稿用Diffusion做精修二是条件Flow Matching的进一步成熟通过更好的条件注入来解决多模态问题三是针对具身智能场景的专用Flow Matching变体比如考虑动作时序约束、力控约束的路径设计。但这些都是可能不是必然。实际做项目时不要被技术潮流裹挟还是要回到任务需求本身你的控制频率要求是多少部署平台是什么任务模态有多复杂把这些想清楚选型自然就明确了。我在过去几个项目里的体会是Flow Matching确实在推理速度上有实打实的优势但它不是Diffusion的替代品而是补充品。两者各有适用场景盲目跟风换方案很可能花了大力气迁移最后发现任务本身根本不需要那么高的推理速度。反过来如果你的任务确实卡在推理速度上那Flow Matching值得认真考虑。选型这件事永远要回到具体需求而不是看哪个词更热。