AI编舞

4 步采样出 1 万帧舞蹈：腾讯 IEG 和人大把动作生成模型压到 60M，代码和 6 个权重全放出来了

2026年11月12日1 次阅读
4 步采样出 1 万帧舞蹈：腾讯 IEG 和人大把动作生成模型压到 60M，代码和 6 个权重全放出来了
AI 编舞 · 动作生成

先讲结论：3分钟看懂这件事

以前做 AI 编舞或动作生成，你必须在两件事里选一个：要质量，就得几十步慢慢采样；要速度，动作就会抖。FlashMotion 的答案是——两个都要，而且模型只有约 6000 万参数。

2026 年 11 月 10 日，腾讯 IEG Motus 组与中国人民大学等团队把论文挂上 arXiv（编号 2611.13626）；11 月 11 日，训练与推理代码以 MIT 许可证开源，同日在 Hugging Face 放出论文里的 6 个权重（三个任务各一个 1 步版、一个 4 步版）。基于论文、项目页与官方代码仓库整理，并有 PulseAugur、CatalyzEx 等技术媒体的转述报道作为交叉印证（本文基于多家媒体转述整理）。

它的核心数字只有一个值得记住：生成 10,000 帧（约 5 分半、30fps）的舞蹈动作，4 步采样约 0.25 秒就能算完（10,000 ÷ 40,545 FPS）——比此前最快的同类模型快 9.8 倍。换成 1 步版是 159,800 FPS，约 0.06 秒。

为什么这件事值得单独讲

做动作生成的人都知道一个尴尬现实：论文里的 SOTA 往往跑不动。

原因是两个瓶颈叠在一起。第一是采样步数——扩散模型要几十步去噪才出好结果，流匹配（Flow Matching）好一点也要 10 步。第二是每一步都很贵——序列一长，注意力机制的计算量按平方增长，1 万帧的动作序列根本跑不动。

这两个瓶颈是耦合的：步数多，每步又贵，乘起来就是灾难。FlashMotion 的做法是两头同时下手。

还有一层现实意义：动作生成的下游不是"生成一段好看的视频"，而是绑骨、重定向、渲染，甚至直接驱动机器人。这些环节都要算力。如果生成这一步就吃满了显存，后面的活就没法干了。

关键设计一：MeanFlow 搬到动作空间

标准流匹配学的是"瞬时速度"——告诉模型此刻该往哪个方向走一小步。这在步数多的时候没问题，但你要是只走 4 步，每一步的跨度就很大，瞬时速度近似会积累明显误差。

MeanFlow 的思路是学区间平均速度：不学"此刻的速度"，学"从这一刻到下一刻，整体平均该走多远"。步数越少，这个改动的收益越大。

但论文指出，直接把 MeanFlow 套到 3D 动作上有个问题：它是直接预测速度的，你很难对生成的动作施加结构约束。而人体动作恰恰是强约束的——关节角度、骨骼长度、脚不能穿地、重心不能乱飘。大跨度更新一旦出错，表现出来就是抖动、根节点漂移、脚底打滑。

所以 FlashMotion 没有预测速度，而是直接预测"干净的动作"，再换算成区间平均速度。这样运动学约束（关节轨迹要连贯）和动力学约束（物理上站得住）可以直接加在预测目标上，而不是加在一个中间量上。

第二个组件是时间衰减软掩码（time-decayed soft mask），用于动作编辑：你给一段动作的前半段，让它补后半段。传统做法是一条硬边界，已知区和生成区泾渭分明，接缝处容易跳。软掩码让约束在采样过程中逐渐放松，过渡就自然了。

关键设计二：BiMamba，训练短、推理长

架构上的关键选择是放弃 Transformer 的注意力，改用双向 Mamba。

原因很直接：注意力是 O(N²)，序列翻十倍，计算量翻一百倍。Mamba 这类状态空间模型是线性的，长序列才跑得动。

但 Mamba 有个天然短板——它是单向的，而动作序列需要"看前也看后"。FlashMotion 用的是双向 Mamba（BiMamba），并且在里面塞了两个调节机制：

  • 条件引导的状态选择：让模型自己决定在每个时间点该从条件（文字/音频/语音）里取多少信息进来。
  • AdaIN 条件融合：用逐帧的缩放和偏移把条件注入动作特征，而不是用交叉注意力去算两两相似度。

这两个设计加起来，让模型在固定特征宽度下只有 O(N) 复杂度。

最实用的一点是：因为所有帧是一次性非自回归预测的，共享的逐帧投影里没有跟序列长度绑定的参数——这意味着训练时只看 240 帧的窗口，推理时可以直接生成 1 万帧，不用滑窗拼接，也不会有自回归模型那种误差累积。

数字：快是真的，但有一项退步

评测在 RTX 3090、batch size 1 上做，只计生成时间，不含绑骨和渲染。

音乐生成舞蹈（FineDance 数据集），对比此前的强基线 FlowerDance：

  • FID_k 从 29.73 降到 15.15（降 49.0%）
  • DIV_k 从 8.42 升到 9.55（升 13.4%）
  • BAS（节奏对齐）从 0.232 升到 0.240（升 3.4%）
  • 吞吐从 4,145 FPS 升到 40,545 FPS（9.8 倍）
  • 但 DIV_g 从 7.18 掉到 6.58，比基线差

最后一项必须点出来：DIV_g 衡量的是动作的全局多样性，这项 FlashMotion 是退步的。论文自己的说法是"1 步版本能追平真人的 DIV_g"，也就是 4 步版在多样性上做了取舍。做编舞的人要清楚这一点——你要是追求动作不重样，它不是无脑最优解。

文生动作（BABEL 长序列）：R@1 从 25.8 左右提到 29.13（ST2M 是 25.79），而两项衡量动作连贯性的误差指标 ΔPJ 和 ΔAUJ 分别降到 0.00027 和 0.01295——比最强基线低 97.9% 和 91.2%。吞吐 46,303 FPS，13.6 倍。

语音生成手势（BEAT2）：FGD 0.3242（基线 CaMN 是 0.5120），BC 0.6006，吞吐 34,655 FPS，4.4 倍。

一句话总结：质量和速度同时改善是真的，但不是每一项都赢。

不只是"生成一段视频"

论文的第五节列了三个落地方向，其中两个值得注意：

机器人：用带 GPT-6 Astra 辅助的实现，把生成的人体动作重定向到 Unitree G1，再用预训练控制器在 MuJoCo 里跟踪。"从拳击到踢腿"那个例子，演示的是语言条件、全身协调的动作能直接转成物理仿真里的行为。这对做机器人行为原型的人省掉了手工编排轨迹。

手机端：把语音请求转成文字条件，把动作重定向到移动端虚拟形象。靠缓存文本嵌入、量化和优化算子，在 iPhone 17 上用 4 步采样生成 200 帧动作约 400 毫秒。这个数字说明它不只是"服务器上跑得快"。

第三个方向是 XR 角色动画，通过骨骼重定向把动作映射到虚拟角色，做语义级的行为控制。

怎么用：三步能跑起来

官方仓库写得相当老实，流程是三步：

第一步，建环境。三个任务各一套 conda 环境，目标 Linux x86_64 + Python 3.10.12 + PyTorch 2.7.1 + CUDA 12.8：

conda env create -f environments/m2d.yaml
conda activate flashmotion-m2d

第二步，拿权重和数据。6 个 checkpoint 在 huggingface.co/yangkaixing/FlashMotion-models 上直接下；数据集在 yangkaixing/FlashMotion-data，需要申请访问，33 个文件共 35.19 GB。

注意三个数据集各有各的门：BABEL、BEAT2、FineDance 都要向原提供方申请，SMPL-X 人体模型另有自己的许可条款。

第三步，跑评测。以音乐生成舞蹈的 4 步版为例，命令是：

python -B tasks/m2d/run.py eval --version genre \
  --paths /path/to/m2d.nfe4.paths.json \
  --checkpoint /path/to/models/m2d/genre/train-2100.pt \
  --epoch 2100 --nfe 4 --dry-run

先用 --dry-run 检查源码和配置，再换成 --prepare 生成评测副本，最后 --execute 才真正生成并打分 84 段片段。官方明确说明：dry run 不测 GPU 执行。

数据格式也别想当然：音乐特征要保留原生的 35 维，动作是 151 通道，其中解码器用 147 个姿态通道（另外 4 个是接触通道）。训练窗口 240 帧、30 FPS；评测用 84 个有序的 1020 帧窗口。

适用场景与不适用场景：谁该用，谁别碰

适合：

  • 做游戏、XR、虚拟人，需要长序列（分钟级）动作且不能等几十秒的
  • 要做机器人动作原型，希望生成的动作能重定向并被控制器跟踪
  • 想在消费级显卡上跑（论文的数字是单张 RTX 3090）
  • 需要动作补全/编辑，给前半段补后半段

不适合：

  • 要面部表情和手指细节的。论文在结论里自己承认，面部和更细的手指关节还没建模。
  • 追求极致动作多样性的。DIV_g 是它明确的短板。
  • 只有 macOS 或 AMD 显卡的。官方只给 Linux + NVIDIA 路线，且要求 CUDA 12.8。
  • 想开箱即用的非技术用户。这是研究代码，不是产品。

避坑：四个已经写明的雷

第一个雷，别指望 clone 完就能跑。 仓库里没有大文件，权重、数据集全在外链。官方环境文档自己写了一句很罕见的话：全新的 conda 求解、扩展编译和"在新机器上重放 6 个 checkpoint"尚未测试，装包成功不代表能复现论文指标。

第二个雷，训练脚本不能直接跑。 原始训练入口在 import 时就会写入，官方要求先跑 --prepare 生成一份适配副本，再用生成的 full_control.py 控制器启动。而且训练配置是 4 张 GPU、每卡 batch 64（总计 256）、4000 个 epoch、FP32——这不是单卡能玩的。

第三个雷，planner 的 --execute 模式没实现。 文档里明写"not implemented"，别在那边调试半天。

第四个雷，许可证要分开看。 代码是 MIT，但论文用的是 arXiv 永久非独占许可；SMPL-X 人体模型、BABEL、BEAT2、FineDance 各自有自己的条款，其中不少限非商用。商用前逐个确认，别只看仓库首页那个 MIT 徽章。

成本和时间

  • 硬件：推理单张 RTX 3090 就够（论文的评测环境）。参考运行时用的是 H200 + 驱动 580.95.05，但那是他们的记录环境，不是必需。
  • 显存：官方没给单条数字；按 60M 参数 + 非自回归长序列推理推断，主要吃的是 1 万帧序列的激活值，而不是权重。要跑 1 万帧建议留足余量，先从 1020 帧的评测配置试。
  • 存储：数据 35.19 GB，加上 6 个 checkpoint 和输出目录，预留 80–100 GB 比较稳。
  • 时间：环境搭建按官方描述是"未测试"状态，保守估计半天到一天；跑通一次评测（84 段片段）另算。

行动建议

第一步，先看 demo 再决定要不要动手。 项目页（sun-happy-ykx.github.io/FlashMotion-Project）有一段 4 分 29 秒的视频，含对比、采样步数展示和消融，能快速判断它的动作质感够不够你用。

第二步，如果只是想要"音乐生成舞蹈"这一件事，先只下 M2D 的两个 checkpoint（m2d/genre/train-2250.pt 是 1 步版，train-2100.pt 是 4 步版），别一上来拉全套 35 GB 数据。1 步版在 FID_k 上是 18.32，比 4 步版的 15.15 差一点，但吞吐是 159,800 FPS——做实时交互优先选 1 步。

第三步，把 DIV_g 的退步当成选型条件写进评估表。 如果你的场景是"同一首歌要生成多种不同跳法"，先用你自己的素材跑 20 条对比再定。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...