会说话的数字人，为什么身体总跟不上嘴巴

你有没有看过那种AI生成的虚拟主播视频，嘴巴对得上口型,可身体却僵在那里，像被点了穴一样一动不动？或者更糟的，身体动是动了，但动作和话完全对不上，说着"我今天特别开心"，手却在那里毫无理由地乱挥。

这不是个别现象，而是整个行业的通病。

原因说出来其实挺简单的：让AI"说话"和让AI"做动作"，一直是两拨人在做两件事。语音对话模型专攻嘴巴，输入一句话，吐出一段语音，从头到尾没考虑过身体要怎么配合。动作生成模型专攻身体，但它得先拿到一段现成的音频才能干活，说白了就是个"听音乐跳舞"的角色，音乐从哪来它不管。

于是行业里最常见的解决方案就是串联：先让语音模型把话说完，录成一段完整的音频，再把这段音频喂给动作模型，让它对着音频生成一套动作。

这套流程能跑通，但代价不小。

拼接的代价：慢，而且没法互相纠错

先说最直观的问题，慢。

语音模型说完一句话需要时间，动作模型再对着这段音频重新算一遍动作，又需要时间。两段时间是叠加的，不是并行的，因为动作模型必须等语音全部生成完毕才能开始工作。这就好比你请了两个师傅装修房子，一个刷墙一个铺地板，但你规定铺地板的师傅必须等墙全干透了才能进场，哪怕他其实可以一边等墙干一边先把材料裁好。工期硬生生拖长了。

论文里给出的实际数字很扎心：跑一遍完整的"语音+动作"串联流程，响应时间是23.35秒，而如果两个环节能融合到一起同步进行，只需要4.32秒。差了5.4倍。

第二个问题更隐蔽,但可能更致命：两个模型之间没法互相学习。

动作模型只能看音频波形这个"结果"，它看不到语言模型在生成这句话时脑子里到底在想什么。比如这句话哪个词是重音，说话人此刻情绪是激动还是平静，这些信息原本就藏在语言模型生成语音之前的中间状态里，可惜串联架构里这些信息全被丢弃了，动作模型只能靠一段干巴巴的声波去猜。

这就像一个哑剧演员被要求给一段广播剧配动作，他只能听录音,却看不到剧本、看不到演员的表情设计稿。他能大概跟着音量起伏比划两下，但很难演出那种"这句话说的时候其实是在强忍愤怒"的细腻层次。如果不让两个系统共享信息,动作永远只能捕捉到声音的表层节奏，抓不住话语背后真正的意图。

这篇论文要解决的，就是这两个问题：怎么让动作和语音同时生成、共享同一套内部状态，而不是先后接力。

端到端联合生成：动作从哪里"看"到语音的意图

论文提出的系统叫做Motion-Omni，它的核心思路是让动作生成器直接"偷看"语音生成器的内部工作状态，而不是等语音说完了再去分析录音。

**这个设计的关键在于，动作不是从声音波形里抠出来的，而是从生成语音的那套神经网络的隐藏状态里直接长出来的。**

具体来说，整个系统分成四个部件。用户的语音先经过一个语音编码器，转换成模型能理解的特征；这些特征交给一个大语言模型（也就是常说的LLM，负责理解对话内容并决定该怎么回应）；语言模型的输出再交给一个专门的语音生成器，把文字变成一串串离散的语音单元；最后，动作生成器接入语音生成器内部，实时读取它此刻的隐藏状态，同步生成脸部表情、手部、上半身、下半身四路动作。

这四个部件不是各自独立训练完再拼起来的，而是被联合训练，让语音这条线和动作这条线共用一套认知，互相校准。

这里有个技术细节值得说一下，语音单元的更新速度是每秒12.5次，而动作需要每秒30帧才够流畅，两者的节奏对不上。

**为了解决这个速度差，Motion-Omni设计了一种双输入机制：动作生成器一边通过"键值对"读取语音生成器的完整上下文信息，一边通过插值的方式把语音单元的节奏拉伸到动作的帧率上，当成查询请求去问"现在该做什么动作"。**

这套机制有个专门的名字，叫做Token-as-Query Gated Fusion（简称TQGF）。

TQGF：一种让模型自己决定"该吸收多少上下文信息"的融合方式。它给每个信息通道装了一个可学习的"阀门"（用sigmoid函数实现，取值在0到1之间），阀门开多大，取决于当前这个动作部位到底需不需要那部分上下文。

打个比方，这就像四个不同专业的翻译同时坐在一个会议室里，脸部表情翻译员、手部动作翻译员、上半身翻译员、下半身翻译员，他们听的是同一段发言人的完整讲话录音（也就是语音生成器的隐藏状态），但各自只挑自己关心的信息记下来。脸部翻译员在意的是情绪起伏，手部翻译员在意的是有没有提到方位或数量，如果没有这个各自过滤的阀门，四个人就得把发言人说的每一个字都一股脑记下来，效率低，还容易把不相关的信息也带进自己的翻译里，最后翻出来的东西反而失真。

论文还提到一个很实际的实验现象：如果在训练时把语音生成器的参数冻结住，只让动作生成器单方面去学，动作的损失值会卡在一个较高的水平下不去，渲染出来的动作明显和语音对不上。

只有让语音生成器也跟着动作的训练信号一起调整，损失才能进一步下降，动作和语音的贴合度才真正改善。

这说明单向的信息传递是不够的，动作生成需要反过来影响语音生成的内部表示，让语音这条线本身也保留更多和动作相关的时序和语境线索。这就是论文标题里"联合训练不是可选项"这句话的由来。

数据从哪来：没有真人语料，就自己造一套

联合训练需要大量成对的"语音+动作"数据，但现实中很难凑齐。

市面上确实有一些录制好的真人对话视频数据集，比如论文提到的Seamless Interaction语料库，但这类数据有个致命问题：里面是无数个不同的说话人，声音各不相同。而Motion-Omni训练出来的语音生成器，目标是稳定输出同一个人的声音，这样才能保证虚拟人形象的一致性。用一堆不同人的声音去教一个只会说"一种声音"的模型，等于牛头不对马嘴。

于是研究团队想了个变通办法：伪标签流水线。

**具体做法是，先拿一批已经配好文字和语音的对话语料（论文用的是InstructS2S-200K数据集），让语音模型统一用同一个目标声音把这些对话都念一遍，生成声音风格一致的音频；再找一个现成的、训练好的动作生成模型当"老师"，把这些音频喂给它，让它给每段音频预测一套配套动作，作为动作的训练标签。**

这个"老师"模型在论文里选用的是LOM（Language of Motion的缩写，一个用四组独立编码本分别处理脸部、手部、上半身、下半身动作的生成模型）。

这套流程听起来简单，但有个隐藏风险：老师自己生成的标签质量参差不齐，有些音频对应的动作预测得很离谱，直接拿来训练只会把噪声一起学进去。

为此论文设计了一套双指标质量打分机制。

第一个指标叫加权VQ-VAE重建误差，衡量的是动作能不能被编码本忠实还原，如果误差很大，说明这段动作本身就落在了编码本"擅长表达"的范围之外，标签本身就不靠谱。

第二个指标是节拍相关性（Beat Correlation，简称BC），衡量的是动作的节奏和音频的节奏对不对得上，如果一段动作和音频压根不同步，哪怕动作本身编码得很精确，也不该被当成好标签用。

两个指标各占一半权重，合成一个总分，再按这个总分把数据分成难度递增的四档，训练时先喂最容易学、质量最高的一档，再逐步过渡到全部数据。

这套两层筛选逻辑很像挑选食材时的双重检验：既要看食材本身有没有变质（对应重建误差），也要看这批食材是不是真的适合眼下这道菜（对应节拍相关性）。只检查一项是不够的,如果只看新鲜度不看适配度，你可能拿到一块非常新鲜但根本不适合这道菜的肉，做出来的东西照样难吃。论文里提到，如果不分档、直接把全部未经排序的数据一股脑扔给模型训练，训练过程直接发散了，模型学不出个所以然。分档之后，同一套评估指标（教师参考FGD，一种衡量生成动作和参考分布距离的指标）从第一档的0.3974一路降到最终的0.3040，说明这套课程式的训练确实在让模型逐步学得更稳。

最终这套流水线产出了422,856对高质量样本，总时长1,402小时。

怎么证明它真的做到了：一套专门为"边说边动"设计的评测体系

光有模型和数据还不够，怎么证明这套系统真的比串联方案好，还得有一套靠谱的评测标准。

这里论文又踩了一个坑：市面上现有的动作评测基准，要么是给你一段固定的语音去配动作（不测试模型自己生成的、不可预测的语音会不会配上合适动作），要么是只测脸部动画，不管全身。换句话说，没有一个现成的评测协议是专门为"开放式对话中自己决定要说什么、同时决定身体怎么动"这种场景设计的。

于是论文自己造了一个，叫SwDA-500。

**这个评测集从Switchboard Dialog Act语料库（一个经典的英语对话文本数据库）里挑选了500条对话提示，覆盖66个话题，每个话题保留7到8轮完整的对话，同时把不适合被朗读出来的转写痕迹清理掉。**

评测的关键设计是"音频对齐"：让所有参与对比的系统，不管是Motion-Omni自己，还是各种串联方案，都用同一段音频去驱动动作生成。

这一步很重要，如果不这样做，不同系统说出来的话内容、语气、时长都不一样，动作差异到底是因为动作模型本身强弱不同，还是因为说的话根本不一样，根本说不清楚。

结果显示，在这套音频对齐的评测下，Motion-Omni在节拍相关性和动作多样性两项指标上，超过了所有不需要在推理时调用动作老师模型的系统。

有意思的是,它在参考自由指标上，和"用同一段音频跑一遍完整教师级联"这个理论上限相比，差距只有约2%，但响应速度快了5.4倍。

换句话说，它几乎摸到了天花板的效果，却只花了原来五分之一多一点的时间。

论文还做了小规模的人工评测。找了四位受过训练的年轻评委，让他们对着同一段音频驱动的不同动作系统打分，从节奏、语义对齐、身体自然度三个维度判断哪个更好。结果显示，Motion-Omni相较于EMAGE（另一个知名的全身动作生成模型）在这三项上净胜25票（45胜10平20负），而相较于动作老师模型LOM本身，则打成了几乎平手（25胜27平23负），差距在这么小的样本量下已经很难说谁真的更优。

论文对这个结果给出了一个挺有意思的解释：EMAGE和LOM这些baseline模型的训练数据（一个叫BEAT2的数据集）里混杂了大量演讲、独白类的录像素材，而不是纯粹的日常对话，导致它们生成的动作有时候会带着"公开演讲"的架势，比如踱步、侧身转体、夸张挥臂，这些在真实对话场景里反而显得不自然。而Motion-Omni的动作训练数据全部来自对话场景的伪标签，风格上更贴近聊天该有的样子。

语音质量没有被牺牲：联合训练不等于顾此失彼

一个很自然的担心是：既然要兼顾动作，语音质量会不会打折扣？

论文用了几组指标来回答这个问题。

先看词错误率（WER，指语音识别出的文字和真实文字之间的错误比例，数值越低说明语音越清晰易懂）。Motion-Omni在Seed-TTS-Eval这个标准测试集的英文子集上跑出2.62%的成绩，在同类"既要说话又要处理其他模态"的全能型模型里排第一，比Qwen2.5-Omni（2.72%）和Ex-Omni（2.67%）都低。当然，一些专门只做语音合成、不用管对话逻辑和动作的专用TTS模型（比如Qwen3-TTS只有1.24%）确实更强，这也符合预期，毕竟它们只需要专注把一句现成的话念清楚，任务更单一。

再看对话能力有没有被动作训练拖累。论文在VoiceBench这个覆盖开放对话、事实问答、推理、指令遵循、安全性等九个维度的基准上测试，Motion-Omni综合得分47.63，超过LLaMA-Omni（41.12）、Ex-Omni（43.57）、Mini-Omni2（33.49）和Moshi（29.51）。

这个结果说明一件事：给语言模型加上一个动作生成的额外任务，并没有把它原本的对话理解能力冲垮，反而在联合训练的过程中保留住了。这背后其实有个训练设计上的巧思，论文在最后一个训练阶段里特意混入了一批纯文本对话数据（约21万条，来自SODA、WildChat等六个公开数据集），专门用来防止模型在只专注学动作和语音的过程中，把"怎么好好接话"这项本领给忘了。论文提到，如果去掉这部分文本数据，模型的回复会更容易陷入机械地重复用户输入的问题。

这就像一个人同时学两门乐器，如果不刻意抽时间复习第一门乐器的基本功，很容易在专攻第二门乐器的过程中把手感生疏掉。

写在后面

读完这篇论文，最触动我的其实不是那个5.4倍的速度提升，而是那个看似不起眼的细节：当研究者尝试冻结语音模型、单独训练动作模型时，动作质量卡住了，怎么调都上不去。这个失败的实验其实比成功的实验更有信息量，它证明了一件反直觉的事情，动作生成这件事，并不是一个"看图说话"式的单向映射任务，动作模型不能只是被动接受语音的产出，它需要反过来影响语音生成过程中留下的中间痕迹，才能真正对齐。这种双向塑造关系，让我想起团队协作里那种"必须互相看着彼此工作"才能配合默契的状态，如果一方只把成品甩给另一方，配合永远是滞后和生硬的。

另一个让我意外的地方是，论文花了整整一个附录去讲一个失败的尝试，用视频输入的大语言模型（Gemini）去自动打分替代人工评测。结果发现这个"AI裁判"和人类评委的相关性低得可怜，在身体动作自然度这个维度上，AI裁判甚至系统性地偏爱那些幅度更大、看起来"更用力"的动作，而人类觉得这种夸张动作反而显得不自然。研究者诚实地把这个负面结果写了出来，而不是悄悄藏起来只报喜不报忧，这种态度本身值得肯定。这也提醒我们，在这个人人都想用大模型当裁判来节省人工评测成本的当下，至少在评价"一个虚拟人的肢体语言像不像真人聊天时的样子"这件事上，机器还替代不了人的直觉判断。

如果有一天,你面前的虚拟数字人说话时的每一个停顿、每一次抬手，都恰好卡在它该出现的地方，你会不会突然意识到，那种"活人感"其实一直靠的是背后两套系统有没有真正共享同一个大脑。

Q&A

Q1：Motion-Omni是什么？

A：Motion-Omni是一个端到端的语音动作联合生成框架，它让对话语言模型能同时生成语音和配套的全身动作（包括表情、手部、上半身、下半身），动作直接来自生成语音过程中的内部隐藏状态，而不是先生成完语音再单独跑一个动作模型。

Q2：Motion-Omni相比传统的语音加动作串联方案有什么优势？

A：主要优势是速度快和动作更贴合语境。串联方案要先生成完整语音、再跑动作模型，响应时间23.35秒；Motion-Omni同步生成只需4.32秒，快5.4倍，同时动作质量在参考自由指标上与顶级串联方案相差不到2%。

Q3：Motion-Omni的训练数据是怎么来的？

A：研究团队设计了一套伪标签流水线，先用统一声音生成对话语音，再用现成的动作生成模型LOM作为老师给音频打上动作标签，并通过重建误差和节拍相关性两个指标筛选质量，最终产出42万余条高质量样本，共1402小时。