出品：Yuanxq      出品：具身智能研究室

01

问题定义：不是生成一整段舞蹈，而是每一刻都要出动作

很多音乐生成动作的方法，默认是离线生成。

模型可以看到完整音乐，可以使用未来上下文，也可以反复优化整段动作。这个设定适合做视频、动画和固定舞蹈片段，但不适合现场控制。

DiscoForcing 把问题改成了在线流式生成：

在当前时刻，模型只能看到已经到来的音频，以及前面生成过的一小段动作历史，然后预测接下来的短动作片段。

这个设定里有三个硬约束。

第一，因果性。模型不能使用未来音乐。它只能根据当前滑动窗口里的音频特征做判断。

第二，低延迟。每一帧都要在很短时间内算出来，否则动作会慢半拍。放到机器人乐队里，慢半拍比动作不够华丽更致命。

第三，长时程稳定。在线生成不是生成 5 秒就结束，而是要一直滚动。前面生成过的动作会进入下一步历史，一点小误差可能会慢慢放大，最后变成漂移、抖动、节奏错位。

这张图展示的就是这个问题：前面静音，角色保持安静；音乐恢复，动作立刻起来；中间发生多次音乐切换，动作还要继续保持连续。

所以 DiscoForcing 不是单纯问“动作像不像舞蹈”，而是在问：

当音频条件不断变化时，生成模型能不能持续给出稳定、同步、低延迟的身体动作。

02

第一步：把实时音乐编码成节奏和相位

整个算法的入口是音频流。

系统会维护一个滑动音频窗口。每到一个时间步，它只处理当前已经听到的这段音频，而不是整首音乐。

这里用了一个因果音乐编码器，核心是 VQ-PAE。它把音乐特征拆成两部分：

第一部分是离散节奏 token。可以理解成模型对鼓点、节拍、节奏模式的离散归纳。

第二部分是连续相位特征。它描述节奏在周期里走到哪里，帮助动作和音乐相位对齐。

直白一点说，这一步要解决两个问题：

这一拍在哪里？现在节奏走到哪一段？

如果没有这一步，后面的动作生成就只能看到一堆原始音频特征，很难稳定对齐节奏。对于机器人乐队来说，这相当于先把“听见声音”变成“听懂节拍”。

03

第二步：把全身动作压到更适合实时生成的潜空间

音频处理完之后，模型还要生成身体动作。

问题是，全身动作维度很高。如果直接在原始动作空间里做扩散生成，实时性会很吃力，动作也容易抖。

DiscoForcing 先设计了一种动作表示，再用 VAE 把动作压缩到潜空间。

论文里的动作表示是 272 维，里面包括根部速度、根部角速度、局部关节位置、关节速度和关节旋转。

这里有一个很工程的选择：它没有只用常见的 HumanML3D 263 维表示，因为 263 维表示缺少关节旋转，后面要恢复可执行动作时还需要额外 IK 或拟合。

DiscoForcing 选择 272 维表示，是为了让动作可以更直接地通过正向运动学恢复出来，减少实时部署时的后处理成本。

这点很重要。

如果只是离线生成，后处理慢一点问题不大；但如果要接到实时 Avatar 或人形机器人平台，每一个额外步骤都会变成延迟。机器人乐队场景尤其不能等。

04

第三步：用 Diffusion Forcing 做流式动作生成

现在有了音乐特征，也有了动作潜空间，接下来就是核心生成模型。

DiscoForcing 用的是 Diffusion Forcing Transformer。

这里不要把 Diffusion Forcing 直译成“扩散力”。它更像是一种面向序列生成的训练方式：同一条时间序列里，不同位置可以处在不同噪声水平下，模型要学会在不完整、不可靠的历史条件下继续生成后续动作。

为什么这对实时生成重要？

因为在线系统里的历史动作并不总是可信。前面生成过的动作可能有漂移，旧音乐节奏可能已经过时，用户也可能突然换了一段输入。如果模型太相信历史，它就会反应慢；如果完全跟随新音频，动作又可能断掉。

DiscoForcing 的核心难点，就是在“相信历史”和“响应新音乐”之间做平衡。

论文里设计了几种噪声调度方式，其中比较关键的是梯形噪声调度。它会对比较远的历史加更高噪声，相当于告诉模型：远处历史可以参考，但别被它绑死。

这样做的好处是，节奏发生变化时，模型更容易从旧动作惯性里抽出来，同时又不会完全丢掉动作连续性。

05

第四步：推理时用滑动窗口，一边去噪一边输出

训练是一回事，真正在线推理又是另一回事。

DiscoForcing 在推理时维护一个 FIFO 滑动窗口。每次生成时，它会在窗口尾部加入一个新的噪声 token，然后对窗口里的 token 做逐步去噪。

当窗口最左边的 token 被去噪到足够干净时，就把它作为当前输出动作发出去。然后窗口向前滑动，再加入新的噪声 token，继续生成下一步。

这个过程很像流水线：

新音频进来，新动作 token 加进来，窗口内部去噪，最早完成的动作被输出，系统继续滚动。

为了进一步平衡稳定和响应，论文还用了 Temporal Guidance。

它会同时看两种趋势：一种更依赖历史，用来维持动作连续；另一种更依赖当前音频，用来快速响应变化。最后把两者组合起来，得到当前输出方向。

这就是它能在音乐切换时继续生成动作的关键。

这张图可以按这条链路读：

音频输入经过因果音乐编码，变成节奏和相位特征；这些特征进入 Diffusion Forcing Transformer；模型结合历史动作缓冲区，生成下一段全身动作；动作再送到在线 Avatar 或人形机器人部署流程里。

换成机器人乐队的话，就是：

听见音乐，理解节奏，生成身体动作，再把动作交给身体执行。

06

实验最值得看的，是实时性怎么被算进账本

论文在 FineDance 和 AIST++ 上做了常规对比，和 FACT、Bailando、EDGE、Lodge、MEGADance 等方法比较动作质量、节奏对齐和多样性。

这些指标可以说明 DiscoForcing 生成效果不差。但我更关心消融实验里的延迟。

表里有一个很直接的结果：100 步去噪时，某些指标会更好，但延迟到了 261.91 ms/frame；10 步去噪时，延迟大约是 26.26 ms/frame，更适合 30 FPS 实时生成。

这就是实时系统的账本。

离线生成可以为了指标多跑几轮，现场系统不行。机器人乐队里，动作慢半拍，观众马上就能看出来。

所以 DiscoForcing 的重点不是把离线指标刷到极限，而是在动作质量、节奏响应和实时延迟之间做取舍。

论文最后选择 10 步去噪，就是因为它在效果和实时性之间更均衡。这个选择比单纯追最高指标更接近部署需求。

07

它离真正机器人乐队还差什么？

DiscoForcing 还不能直接等同于机器人乐队。

它解决的是“音乐驱动身体动作”的实时生成问题，但真正机器人乐队还会多出几层更硬的约束。

第一，乐器演奏需要接触和力控制。打鼓、弹琴、拨弦都不是单纯摆姿态。机器人要在正确时间、正确位置，用合适力度触碰乐器。

第二，多机器人需要同步和分工。一个角色跟音乐动起来，和一组机器人共同演奏，是两个难度。鼓手、贝斯、键盘和主唱对节奏的依赖都不一样。

第三，全尺寸人形机器人还要考虑稳定性和安全。重心、碰撞、关节限位、安全停止、长时间运行，这些都不是当前论文的重点。

第四，音乐理解还可以更复杂。现在主要是节奏和相位层面的响应。真正乐队还涉及段落结构、主旋律、情绪变化、即兴空间和人机协作。

更准确的说法是：

DiscoForcing 补的是机器人乐队最底层的一块：实时音乐变化时，身体怎么连续、及时、稳定地回应。

08

写在最后

这篇论文最有意思的地方，是它没有停在离线生成。

它把扩散模型放到了一个更接近现场的设定里：输入是流式的，未来不可见，动作必须马上输出，历史误差还会影响下一步。

这件事看起来像音乐舞蹈生成，往深处看其实很具身。

因为具身智能最终面对的就是一个持续变化的世界。人说话会停顿，音乐会转段，环境会变化，任务会中断，机器人自己的动作也会反过来改变下一步状态。

机器人乐队只是一个很容易被看见的场景。

它把问题压缩成一句话：

身体能不能听见变化，并且立刻用动作回应。

DiscoForcing 还只是其中一块，但这块位置很清楚。

机器人乐队真正难的，不只是让机器人发出声音，而是让机器人身体进入音乐现场