4小时前 OmniHumanoid：让机器人“继承”人类动作，只需要少量视频就能适配新本体

出品：具身释界

如果给模型一段人类视频，它能不能生成“同样动作、同样场景下，一个机器人正在完成这个动作”的视频？

比如，输入是一段人类在厨房里拿杯子、搬椅子、开门的视频，模型输出的不是普通的人类视频，也不是简单把机器人贴上去，而是一个目标机器人在同样环境中完成同样动作的视频。

这就是 OmniHumanoid 想解决的问题。

论文的全名是 OmniHumanoid: Streaming Cross-Embodiment Video Generation with Paired-Free Adaptation。从标题就能看出，这篇工作关注的是 cross-embodiment video generation，也就是跨本体视频生成。

简单来说，它想做的是：

把一个 embodiment 的动作视频，转换成另一个 embodiment 的视频。

这里的 embodiment 可以是人，也可以是机器人，还可以是不同类型的人形机器人。比如：

人类视频 → 人形机器人视频

机器人 A 视频 → 机器人 B 视频

数字人视频 → 真实机器人风格视频

这类技术对于具身智能很有意义。因为真实机器人数据非常贵，每一个机器人平台都要收集大量遥操作数据，成本很高。如果能把已有的人类视频或其他机器人视频转换成目标机器人的视频，就可以低成本扩展机器人数据，为后续的 VLA、world model 或机器人策略学习提供更多训练素材。

为什么跨本体视频生成这么难？

Figure 1 展示了 OmniHumanoid 的核心目标：给定源视频和目标机器人本体，模型生成目标机器人在同样场景中执行同样动作的视频。

乍一看，这个任务好像只是“换个角色”。但实际上，它比普通的视频编辑难很多。

因为不同机器人之间，甚至人和机器人之间，并不只是外观不同。它们的身体比例、关节结构、运动方式、材质、颜色、肢体长度都不一样。

人可以自然弯腰、转身、伸手，但机器人未必有完全相同的关节自由度。一个机器人可能手臂更长，另一个机器人可能腿部结构更机械化。如果模型只是简单地“把人换成机器人”，就很容易出现几个问题：

第一，动作会漂移。

源视频里人类明明在伸手拿东西，生成出来的机器人可能只是大概抬手，动作轨迹和时间节奏都对不上。

第二，机器人身份会不稳定。

视频前几帧还是某个机器人，后面可能身体比例变了，颜色变了，甚至结构开始扭曲。

第三，背景会被破坏。

机器人运动时，周围场景可能出现闪烁、扭曲、重绘错误，尤其是在复杂室内场景里更明显。

第四，生成速度太慢。

高质量视频生成模型通常需要很多步 denoising，很难用于大规模数据生产，更不用说实时或接近实时生成。

所以，OmniHumanoid 并不是简单做一个“视频换脸”或者“机器人替换”工具。它真正要解决的是：

如何在保持源视频动作的同时，稳定生成目标机器人的外观和结构，并且还能适配新的机器人。

核心思想：动作可以共享，身体外观不能共享

OmniHumanoid 最重要的思想可以概括成一句话：

把“怎么动”和“长什么样”分开学。

论文认为，在跨本体生成中，motion 和 embodiment appearance 是两类不同的信息。

motion 是相对可迁移的。

比如“走路”“转身”“伸手”“搬东西”这些动作模式，在人和机器人之间是有一定共性的。虽然具体关节不同，但动作的时序、轨迹和任务逻辑是可以共享的。

但 embodiment appearance 是本体特定的。

不同机器人长得不一样，身体比例不一样，机械结构不一样，甚至材质和颜色也不一样。这部分不应该被强行放进一个通用模型里混着学。

所以，OmniHumanoid 把模型拆成两个部分：

一个是 Shared Motion Transfer Model，负责学习跨本体共享的动作迁移能力。

另一个是 Embodiment Video LoRA，负责学习某一个具体机器人或数字人的外观、形态和结构。

这就有点像：

Shared Motion Model 学的是“动作语法”。

Embodiment LoRA 学的是“这个机器人长什么样”。

当来了一个新的机器人，不需要重新训练整个大模型，只需要为这个机器人训练一个轻量级 LoRA，模型就可以把已有的动作迁移到这个新机器人身上。

这就是标题里 paired-free adaptation 的核心意义： 适配新机器人时，不需要成对的“源视频—目标机器人视频”，只需要这个机器人自己的未配对视频。

模型怎么做：共享动作模型 + 机器人 LoRA

Figure 2 是这篇论文最关键的一张图。它看起来信息很多，但其实可以拆成三部分来看：

左边是 Embodiment Video LoRA Training，也就是先为不同机器人训练各自的外观 LoRA。 中间是 Action Transfer Module Training，也就是训练共享的动作迁移模块。 右边是 Decoupled Attention Design，也就是论文真正用来解耦动作和外观的注意力设计。

我们先看中间的主模型。

OmniHumanoid 基于 DiT 视频生成骨干网络，可以把它理解成一个扩散式的视频生成模型。它不是一下子生成清晰视频，而是从带噪声的视频 latent 开始，一步步去噪，最后得到目标视频。

在这个过程中，模型里有三类信息：

第一类是 Text Branch，也就是文本分支。 它处理 prompt，比如告诉模型要生成什么类型的视频、目标是什么。

第二类是 Condition Branch，也就是条件分支。 它输入的是 source video，也就是源视频。比如源视频里是一个人在转身、伸手、搬东西，那么 condition branch 负责从这个视频里提取动作信息，包括动作轨迹、身体姿态变化、运动节奏、人与环境的交互关系等。

第三类是 Denoise Branch，也就是去噪分支。 它处理的是正在被生成的 target video latent。简单来说，它就是模型真正“画出目标视频”的地方。最终生成的目标机器人视频，就是从这个分支一步步去噪出来的。

所以，condition branch 和 denoise branch 的关系可以这样理解：

condition branch 负责看懂源视频怎么动； denoise branch 负责把这个动作画成目标机器人视频。

举个更直观的例子。

假设源视频里是一个人在房间里抬手拿东西。Condition branch 要做的是理解这个动作：这个人什么时候抬手、手臂往哪个方向移动、身体有没有转动、动作节奏是快还是慢。

但是目标视频里不能还是这个人，而是要变成某个机器人。所以 denoise branch 要做的是：在生成目标视频时，把刚刚提取到的动作迁移到目标机器人身上，同时保持这个机器人的身体比例、机械结构、颜色和外观细节。

这就引出了 OmniHumanoid 的核心设计：动作信息和机器人外观信息不能混在一起。

如果模型把二者混在一起学，就很容易出问题。比如，模型可能把源视频里人的身体形态也带到目标视频里，导致机器人看起来不像原本的机器人；也可能把某个机器人的身体结构错误地学进动作表示里，导致换一个机器人之后动作迁移不稳定。

因此，OmniHumanoid 做了一个很清晰的分工：

源视频动作主要通过 condition branch 进入模型； 目标机器人外观主要通过 denoise branch 上的 Embodiment Video LoRA 控制。

也就是说，condition branch 更像是“动作导演”，负责告诉模型这个动作应该怎么发生；denoise branch 更像是“动画师”，负责把这个动作画成目标机器人版本。

左边的 Rolling LoRA Bank 就是为不同机器人准备的外观模块。每个机器人都有自己的 Video LoRA。比如 Robot 1 有自己的 LoRA，Robot 2 也有自己的 LoRA。这个 LoRA 主要学习的是该机器人自己的外观和形态：身体比例、机械结构、颜色、材质，以及运动过程中如何保持身份一致。

训练共享动作迁移模块时，论文会根据当前训练样本的目标机器人，切换对应的 LoRA。图里写的 “switch every 50 steps” 就是在表示这种 rolling LoRA loading 策略。这样做的目的，是让共享动作模块不要依赖某一个固定机器人，而是学到跨机器人都成立的动作规律。

再看右边的 Decoupled Attention Design。

这部分是整篇方法里最关键的地方。论文不是简单地把 source video 和 target video token 放到一起做 attention，而是限制了信息流动的方向。

简单来说：

denoise branch 可以读取 condition branch 里的动作信息； 但是 condition branch 不能反过来读取 denoise branch 里的机器人外观信息。

换句话说，目标视频生成时可以参考源视频动作，但源视频的动作表示不能被目标机器人的外观 LoRA 反向影响。

这听起来有点抽象，可以用一个比喻来理解。

假设 condition branch 是导演，denoise branch 是画师，Embodiment LoRA 是机器人的角色设定。

导演负责说：“这里要转身，下一步抬手，然后往前走。”

画师负责根据导演的动作说明，把这个动作画成 Unitree G1 或其他机器人的样子。

角色设定负责告诉画师：“这个机器人身体是什么比例、颜色是什么、机械结构是什么。”

但是角色设定不能反过来修改导演对动作的理解。否则导演可能会把某个机器人的身体特征误认为动作本身。这样一来，换一个机器人时，动作就不一定还能正确迁移。

所以，OmniHumanoid 的单向信息流设计，本质上是在做一件事：

让动作保持干净，让外观只影响最终生成。

这样模型就更容易实现两个目标：

第一，生成的视频动作要像源视频。

第二，生成的视频外观要像目标机器人。

如果不做这种解耦，动作和外观就会互相干扰。模型可能既不能准确保留源视频的动作，也不能稳定保持目标机器人的身份。论文后面的消融实验也说明了这一点：去掉 decoupled attention 后，机器人的外观一致性和动作一致性都会明显下降。

所以 Figure 2 其实可以用一句话概括：

OmniHumanoid 用 condition branch 学源视频动作，用 denoise branch 生成目标机器人视频，再用 Embodiment LoRA 控制机器人外观，并通过单向注意力机制防止动作和外观互相污染。

这就是它能够适配新机器人、同时保持动作迁移能力的关键。

训练流程：先学机器人长什么样，再学动作怎么迁移

OmniHumanoid 的训练分为两个阶段。

第一阶段是 Embodiment Video LoRA Pretraining。

这一阶段只训练每个本体自己的 LoRA。训练数据不需要配对，只需要某个机器人或数字人自己的视频。模型在这个阶段学习：

这个机器人长什么样，

身体比例是什么，

颜色和材质是什么，

运动过程中外观如何保持一致。

也就是说，这一步主要解决“目标机器人身份保持”的问题。

第二阶段是 Shared Motion Transfer Training。

这一阶段使用 motion-aligned paired videos。所谓 motion-aligned，就是不同本体在同样场景、同样相机视角下执行同样动作。这样模型就可以明确知道：这两个视频虽然角色不同，但底层动作是一样的。

在训练时，论文会根据当前目标机器人加载对应的 LoRA，同时冻结这些 LoRA，只训练共享动作迁移模型。

这个策略很巧妙。

因为 LoRA 已经负责“机器人长什么样”，共享模型就不用再记外观，而是可以专心学习“动作怎么从源视频迁移到目标视频”。

为了避免模型偏向某一个机器人，作者还使用了 rolling LoRA loading，也就是训练过程中不断切换不同机器人的 LoRA。这样共享模型会更倾向于学习跨机器人通用的动作规律。

新机器人怎么适配？不需要成对数据

这篇论文一个很重要的卖点是：适配新机器人时，不需要 paired source-target videos。

在传统设定下，如果想让模型学会“人类视频 → 某个新机器人视频”，最好要有大量成对数据：同样动作、同样场景下，人类一版，机器人一版。但现实中这种数据非常难收集。

OmniHumanoid 则换了一个思路。

对于一个新机器人，只需要收集它自己的若干未配对视频，然后训练一个新的 Embodiment Video LoRA。共享的 motion transfer model 保持不变。

推理时，输入一段源视频，再加载这个新机器人的 LoRA，模型就可以生成这个新机器人执行源视频动作的结果。

这也是这篇论文相比普通视频编辑模型更适合机器人场景的地方：它不是每来一个机器人就从头训练，而是把“通用动作迁移能力”和“机器人本体适配能力”拆开了。

数据集：用合成渲染构造 motion-aligned paired videos

跨本体视频生成最大的问题之一，是很难获得严格对齐的 paired data。

所以作者构建了一个 Unity-based synthetic cross-embodiment dataset。Figure 3 展示了整个数据生成流程。

首先，他们使用 Humoto motion library，里面有 700 多个 humanoid motion sequences，覆盖物体操作、环境交互、移动和日常全身动作。

然后，他们准备了 10 个 humanoid assets，包括 5 个机器人和 5 个数字人角色。

为了让不同本体能够执行同一套动作，作者先在 Blender 中统一骨架拓扑，再在 Unity 中进行 motion retargeting。这样，同一个 motion 可以被重定向到不同机器人或数字人身上。

接着，他们在 100 个不同场景中渲染视频，包括办公室、工厂、户外环境等。渲染时保持动作、场景布局、相机视角一致，只替换 humanoid asset。

这样就可以得到严格对齐的视频对：

同一个动作，

同一个场景，

同一个相机，

不同本体。

最终，论文构建了 7,200 个 paired training samples。视频分辨率为 1920×1080，30 FPS，每段视频大约 300 帧。

这个合成数据集的作用非常明确：

它不是为了完全替代真实世界，而是为了提供可控的跨本体动作对齐监督，让模型先学会“动作和本体外观如何解耦”。

泛化效果：见过的机器人和没见过的机器人都能生成

Figure 4 展示了模型在新场景、新任务，以及 seen / unseen robot embodiments 上的生成效果。

图中上半部分是训练中见过的机器人，下半部分是训练中没见过的机器人。给定源视频和目标机器人的 LoRA，模型可以把源视频动作迁移到目标机器人身上，并在新的环境和动作配置下生成视频。

这张图想说明的是：OmniHumanoid 不是简单记住训练集里的“某个机器人在某个场景做某个动作”，而是具备一定组合泛化能力。

它要泛化的维度包括：

新场景，

新动作，

新机器人本体。

这对于机器人数据生成非常关键。因为真实应用中，我们关心的不是训练集里的几个固定动作，而是模型能不能扩展到更多机器人和更多任务。

和其他视频生成模型相比，OmniHumanoid 强在哪里？

Figure 5 对比了 OmniHumanoid 和其他视频生成 / 视频编辑方法的结果，包括 Runway Gen-4、Kling、Wan2.1-VACE、X-Humanoid 等。

从论文的定性结果来看，通用视频生成模型虽然画面质量可能不错，但在机器人场景中容易出现几个问题：

机器人结构不稳定，

肢体动作和源视频不一致，

关节运动不自然，

目标机器人身份保持不够好，

复杂动作中容易产生视觉伪影。

这是因为这些模型本质上不是专门为跨机器人本体迁移设计的。它们可以做 reference-guided generation 或 video editing，但并没有显式区分“动作迁移”和“机器人外观保持”。

OmniHumanoid 的优势就在于，它把这两部分拆开建模。共享模型负责动作，LoRA 负责机器人外观，因此更容易同时保持 motion fidelity 和 embodiment consistency。

从 Table 1 的定量结果来看，在 Synthetic Held-out Embodiment Benchmark 上，OmniHumanoid 的 PSNR、SSIM、MSE 都优于其他方法，同时 motion、embodiment 和 background consistency 也表现较好。

它在合成 held-out 机器人测试中的结果是：

PSNR：25.47

SSIM：0.9039

MSE：0.0033

Motion score：9.06

Embodiment score：8.43

Background score：9.94

这些指标说明，OmniHumanoid 在保持动作、目标机器人身份和背景稳定性方面确实有优势。

不过也有一个小细节值得注意：在 real-world benchmark 的 overall score 上，Table 1 里 Kling O1 是 8.53，OmniHumanoid 是 8.39，并不是所有指标都完全第一。所以更准确地说，OmniHumanoid 的优势主要体现在跨本体动作迁移和机器人身份保持上，而不是每一个综合指标都绝对最高。

为什么“动作-外观解耦”这么重要？

Figure 6 和 Table 2 是这篇论文里非常关键的消融实验。

论文比较了去掉 decoupled attention 的版本和完整模型。结果非常明显：

如果没有 motion-appearance decoupling，embodiment score 从 8.43 掉到 2.53，motion score 从 9.06 掉到 6.35。

这说明，直接把源视频动作信息和目标机器人外观信息混在一起，会产生强烈干扰。

直观来说，模型会搞不清楚：

哪些信息是“动作本身”，

哪些信息是“这个机器人特有的身体结构”。

结果就是，生成的视频既可能动作不对，也可能机器人长得不对。

这也是 OmniHumanoid 整篇论文最核心的技术点：

它不是单纯加一个 LoRA，也不是只靠更多数据，而是通过结构设计，让动作迁移路径和机器人外观路径尽量分开。

Streaming Distillation：从高质量生成走向高效率生成

前面讲的是生成质量，但机器人数据生成还有一个现实问题：速度。

如果一个模型每生成一段视频都很慢，那它就很难真正用于大规模数据生产。

因此，OmniHumanoid 进一步提出了 streaming video-to-video distillation，把原来的双向 teacher model 蒸馏成一个 causal streaming student。

原始 teacher model 需要 50 步 denoising，质量高但速度慢。论文中 teacher model 速度大约只有 0.10 FPS。

蒸馏后的 student model 只需要 4 步 denoising，可以达到接近 5 FPS，并支持 720p 长视频生成。

它的核心思路是把视频分成多个 chunk，让模型按时间顺序自回归生成。当前 chunk 可以看见 reference、之前已经生成的 chunks，以及当前的 source condition chunk，但不能看未来信息。

这样模型就从“整段视频一起生成”变成了“流式逐段生成”。

这对实际应用很重要。因为未来如果要用这类模型批量生成机器人视频数据，或者接入更交互式的系统，效率会变得非常关键。

当然，速度提升也有代价。论文在 limitation 中也承认，4-step streaming student 相比 full teacher 会出现一定质量下降，比如细节变弱、时间平滑性下降、复杂动作 fidelity 下降。

所以，这里本质上是一个 speed-quality trade-off：

teacher model 更高质量，

streaming student 更高效率。

这篇论文对具身智能有什么意义？

OmniHumanoid 的意义不只是“生成了更像机器人的视频”。

更重要的是，它提出了一种比较清晰的数据扩展思路：

用可迁移的人类/机器人动作视频，生成目标机器人本体下的视频数据。

过去机器人学习高度依赖真实机器人数据。每换一个机器人，就可能要重新收集一批遥操作数据。而 OmniHumanoid 这类方法提供了另一种可能：

先从人类视频、合成视频、其他机器人视频中获得丰富动作经验，

再通过轻量级本体适配，把这些经验转换成目标机器人的视觉数据。

这和最近很多具身智能工作中的趋势是一致的：

机器人不一定只能从真实机器人数据中学习，也可以从更大规模的人类视频或跨本体数据中获得先验。

当然，OmniHumanoid 生成的是视频，不是直接输出机器人可执行动作。它更像是一个 robot video data generation / robotization tool，可以为后续的 world model、VLA 或策略学习提供数据基础。

所以它和直接控制机器人的 VLA policy 不是同一类方法，但可能成为机器人学习数据链路中的重要一环。

局限性：它还不是完整的机器人策略模型

虽然 OmniHumanoid 的思路很有启发性，但也有一些明显局限。

第一，它依赖大量合成 paired data 进行 motion transfer training。

合成数据方便构造对齐样本，但和真实世界之间仍然存在 domain gap。真实视频中的光照、遮挡、物体交互和相机运动会更加复杂。

第二，它生成的是视频，不是动作。

模型可以生成“机器人看起来在做某个动作”的视频，但这不代表机器人真的能执行这段动作。要把视频变成可执行策略，还需要额外的动作建模、控制建模或 robot policy learning。

第三，paired-free adaptation 并不等于 zero-shot adaptation。

新机器人虽然不需要 paired source-target videos，但仍然需要它自己的 unpaired videos 来训练 LoRA。如果一个机器人完全没有视频数据，模型也无法直接适配。

第四，streaming student 存在质量损失。

为了提升速度，模型从 50-step 变成 4-step，细节和复杂动作的稳定性会下降。这也是目前视频扩散模型蒸馏中比较普遍的问题。

总结

OmniHumanoid 这篇论文可以用一句话概括：

它通过解耦“可共享的动作迁移”和“机器人特定的外观形态”，实现了可扩展的跨本体视频生成，并且可以用少量未配对视频适配新的机器人。

它的核心贡献主要有三点：

第一，提出了 Shared Motion Transfer Model + Embodiment Video LoRA 的解耦框架，让动作迁移和机器人外观建模分工明确。

第二，构建了 motion-aligned synthetic cross-embodiment dataset，用合成渲染方式获得严格对齐的跨本体视频对。

第三，通过 streaming video-to-video distillation，把高质量但慢速的 teacher model 蒸馏成更高效的 causal streaming student，实现更适合长视频和大规模生成的推理方式。

从具身智能角度看，OmniHumanoid 不是直接解决机器人控制问题，而是在解决一个更上游的问题：

如何低成本生成目标机器人本体下的大规模视频数据。

如果未来这类跨本体视频生成方法能够进一步和 world model、VLA、robot policy learning 结合起来，它可能会成为机器人数据扩展的一条重要路径。

毕竟，对于机器人来说，真正稀缺的不只是模型能力，还有数据。

而 OmniHumanoid 想做的，就是让机器人不必从零开始收集每一个动作，而是能够“借用”人类和其他机器人的动作经验，再转换成属于自己的身体经验。