Meta Muse 实时数字人上线：870ms 响应、语音与表情同步技术

11 月 5 日，Meta 为个人 AI Agent Muse 上线了实时语音和动态数字人功能。用户可以直接和 Muse 说话，屏幕上的虚拟角色会跟着回答做出口型、表情和手势。用户中途插话，Muse 也能停止原来的回答，继续处理新的问题。这项功能首先面向美国用户推出，支持手机、网页和 Mac。用户可以选择纯语音模式，也可以让数字人显示在聊天界面旁边，或者全屏与其交流。Meta 还提供了数百种声音选项，允许用户调整角色的声音风格。

Meta 公布的性能数据显示，系统能以每秒 25 帧生成 448×768 的竖屏视频，从用户结束发言到收到同步音视频的首字节，延迟约为 870 毫秒。

为了让视频生成跟得上实时对话，研究团队还将每个视频片段所需的模型评估次数从 120 次压缩至 2 次，并围绕 GPU 推理、缓存和多会话调度做了专门优化。

---

一. Meta Muse 上线了哪些实时交互功能？

1. 从文字聊天变成面对面语音交流

Muse 是 Meta 在 2026 年 9 月推出的个人 AI Agent。它除了回答问题，还可以在获得用户授权后处理任务，例如规划行程、整理信息和操作支持的应用。

此前，Muse 已经具备基于文字的任务交互能力。11 月 5 日上线的实时语音，使用户可以通过对话逐步提出要求，不必每次都完整输入文字指令。

Meta 举出的应用包括旅行规划、面试练习、演讲准备和日常任务处理。用户可以一边说话一边补充想法，Muse 根据当前对话继续回应。

在动态数字人模式中，用户还可以看到角色的表情与动作。Meta 展示的形象不局限于真人头像，也包括动物、插画人物和其他非写实角色。

不过，这次推出的数字人主要根据语音对话作出反应。不能把“数字人会看着用户说话”理解为它已经具备实时视觉感知用户的能力。TechCrunch 在报道中也特别指出，Muse 的动态角色会根据听到的内容回应，但并不是通过摄像头观察用户的表情。

2. 角色不仅能说话，也能在聆听时作出反应

多数语音助手在等待用户讲话时，界面只显示音频波形或一个简单的聆听图标。

Muse 则尝试让数字人在不同对话阶段表现出相应状态。

当用户讲话时，数字人可以保持聆听状态并出现细微动作；当 Muse 回复时，角色的嘴部运动、表情和手势随语音变化。

这对角色渲染提出了新的要求。系统不仅需要生成说话时的嘴部动作，还要处理停顿、轮次切换和不说话时的自然姿态。

如果数字人只在输出语音时移动嘴巴，其他时间完全静止，连续对话很容易显得生硬。反过来，如果动作过于频繁，也可能干扰用户注意力。

Meta 在研究中专门提到了角色外观和动作的长期一致性，说明它希望数字人能在多轮对话中保持相对稳定的形象，而不只是生成一小段演示视频。

3. AI 眼镜和 Muse Charm 还需要等待

Meta 表示，实时语音和动态数字人目前先在美国的 Muse 应用中上线。

未来计划将语音交互扩展到 AI Glasses 和 Muse Charm，但截至 11 月 5 日的官方公告，这两类设备上的相关体验仍属于后续计划。

对于智能硬件开发者，这个方向值得继续关注：当 Agent 从手机屏幕进入眼镜或可穿戴设备后，交互界面、语音采集和任务反馈都可能发生变化。

但目前还不能根据 Muse 手机端的性能数据，推断相同的动态数字人模型能够直接在眼镜芯片上本地运行。

---

二. Muse 如何让声音、口型和表情同步生成？

实时数字人通常需要完成两个任务：生成能够回答用户的语音，以及生成与这段语音匹配的人物画面。

常见的实现方式是先通过语言模型生成文本，再由 TTS 输出音频，最后通过音频驱动模型生成口型和面部动作。

这种架构可以工作，但如果每个环节都必须等待上一个环节完整结束，用户就要承担多次处理等待。开发者通常需要使用流式处理，让各模块尽可能并行运行。

Muse Realtime Avatar 采用了更紧密的语音与视频生成方式。

1. 语音与视频共享同一条 Speech Token 流

根据 Meta AI Research 的技术说明，Muse Realtime Voice 负责对话理解和语音生成，并持续输出语音 Token（官方称为 Speech VQs）。

这些 Token 包含语音内容及表达方式相关的信息，随后被两个模块共同使用：

• Audio Decoder：将语音 Token 解码成实际可以播放的声音。
• Muse Realtime Avatar：使用同一条 Token 流生成相应的口型、表情和动作画面。

也就是说，音频和视频并不需要各自从完全独立的文本输入开始工作。数字人视频模型可以直接获得与语音生成过程相关的信息。

共享语音 Token 可以帮助视频模型理解当前语音表达，使口型、表情与语音之间建立更直接的对应关系。

但这并不意味着音视频天然就能在所有终端上精确同步。实际播放仍涉及视频生成缓冲、音频解码、媒体时间戳和网络传输。Meta 没有在这篇研究中公布完整的客户端媒体同步协议。

2. 数字人的表情不是简单的音量驱动动画

传统的简单数字人动画，可能只根据音频音量控制嘴巴开合。声音大时嘴巴张开，声音小时闭合。

这类实现成本低，但很难准确表现不同音素的嘴型，也不能自然生成头部动作、表情变化或全身手势。

Muse Realtime Avatar 使用的是以语音信息为条件的生成式视频模型。它结合参考形象、语音 Token 和前面生成的视频信息，预测下一段画面。

因此，它能够处理比口型开合更复杂的视觉内容，例如人物微笑、调整姿态，或者让插画中的角色随着说话内容产生动作。

不过，研究模型能够生成这些效果，不代表每个动作都受到独立的语义指令精确控制。Meta 尚未公开可让开发者逐项指定手势或表情的完整 Avatar 控制接口。

---

三. 一段对话可能持续十几分钟，视频如何一直生成？

将一张图片生成三秒钟视频，和让同一个角色连续对话十几分钟，是不同的计算问题。

短视频生成可以一次处理固定长度的画面，之后直接输出结果。实时数字人则需要持续接收新的语音内容，并不断生成后续画面。

如果模型每次生成新片段，都重新处理此前所有的视频帧，计算和显存开销会随着对话长度增长。

Meta 的方案采用因果分块生成（Causal Chunk Generation）来处理这个问题。

1. 使用 Diffusion Transformer 生成短视频片段

Muse Realtime Avatar 的核心是音频驱动的 Diffusion Transformer（DiT）。

Diffusion 模型通过多次预测与修正，将噪声逐步转换为目标内容。用于视频生成时，模型需要同时考虑角色形象、动作变化以及相邻视频帧之间的连续性。

Meta 没有让模型一次生成整场对话的视频，而是采用连续的短片段生成方式。

系统接收当前语音 Token、参考形象和近期生成的视频潜在表示（Video Latents），生成下一小段视频。

随后，将新视频片段中的部分潜在表示保留下来，作为后续生成的上下文。

2. 为什么需要保留最近生成的视频信息？

假设数字人上一段视频里刚刚抬起右手，接下来又要生成新的画面。

如果模型完全不知道上一段动作，下一段可能突然出现姿势跳变：刚刚抬起的手瞬间放下，人物头部转向发生突变，甚至面部特征也出现轻微变化。

因此，Muse 会保留一段滚动的视频潜在表示，供下一次生成使用。

它相当于告诉模型：当前角色长什么样、身体处于什么姿态、刚才正在做什么动作。

新片段生成后，再更新这段上下文。

这种方式能够把计算限制在相对固定的窗口内，同时保留近期动作信息。但它不能自动保证长时间生成完全没有漂移，角色一致性仍然是模型训练需要解决的问题。

3. Self-Forcing 如何减少连续生成中的画面漂移？

Meta 在研究中提到，团队使用 Self-Forcing 和 Distribution Matching Distillation（DMD）训练实时生成模型。

连续生成模型容易遇到一个问题：训练阶段使用高质量的真实上下文，实际运行时却只能依赖自己之前生成的内容。

如果每段画面都有一点误差，这些误差可能在后续生成中不断累积。

Self-Forcing 的思路，是让学生模型在训练时也接触自己生成的上下文，从而学习如何处理连续生成过程中实际会遇到的偏差。

这与只用真实视频片段训练模型有所不同。它关注的不仅是单段视频好不好看，还包括模型在连续生成时能否维持稳定。

对于需要长时间运行的 AI 数字人，这一点尤其重要。角色不能每回答几个问题就重新生成一张脸，也不能因为视频持续播放而逐渐改变原有形象。

---

四. 120 次计算压缩到 2 次，Meta 如何降低视频生成成本？

实时数字人要在用户等待时间内生成视频，单靠大型扩散模型直接推理通常会面临较高的计算开销。

Meta 在研究中公布了一项关键优化：通过模型蒸馏，将每个视频片段的神经网络评估次数从 120 次降至 2 次。

1. 原始教师模型需要 120 次模型评估

Meta 先训练了一个高质量的双向生成模型，作为 Teacher Model（教师模型）。

该模型使用 40 个扩散步骤，并采用三路 Classifier-Free Guidance（CFG）。每个步骤需要进行三次模型评估，因此总计需要：

40 个扩散步骤 × 每步 3 次模型评估 = 120 次模型评估。

这种方式可以追求较高的视频质量，但计算量不适合直接用于要求快速响应的大规模实时会话。

2. 学生模型只需要两次评估

Meta 使用自定义的蒸馏方法，将扩散过程及 CFG 的效果压缩到一个两步生成的学生模型中。

学生模型不再需要原来的三路引导评估，生成一个视频片段只需要两次神经网络评估。

按照模型评估次数计算，减少幅度为：

120 ÷ 2 = 60 倍。

这里的 60 倍并不等同于完整产品响应速度提高 60 倍。实际延迟还涉及语音模型、数据传输、缓存、音视频同步和 GPU 调度。

Meta 在内部评估中表示，蒸馏后的模型基本保留了教师模型的视觉质量，并在整体偏好测试中接近教师模型。

这一结论来自 Meta 自己的研究结果，尚不能当作所有复杂动作和长时间对话场景下的独立质量保证。

3. KV Cache、量化和动态批处理进一步降低成本

除了模型蒸馏，Meta 还针对实时视频推理服务做了多项优化。

• Persistent KV Cache：缓存部分历史计算结果，减少连续视频片段生成时的重复计算。
• 4-bit Quantization-Aware Training：在训练中考虑低比特量化，减少推理时的计算与内存负担。
• Cache-Aware Routing：调度时考虑缓存状态，尽量复用已有计算资源。
• Latency-Aware Dynamic Batching：根据延迟要求动态组合推理任务，平衡单会话响应和多会话吞吐。
• Fused Kernels 与 CUDA Graph：减少 GPU 内存访问和计算调度开销。

这些优化服务于同一个目标：让模型能够在持续生成视频的同时，处理更多用户会话。

对于生产环境而言，单路 Demo 能够达到实时速度只是第一步。多个用户同时调用模型时，能否保持稳定的首帧时间和流畅帧率，同样决定系统是否可用。

---

五. 870ms、25 FPS、12 路并发，应该怎样理解这些数据？

Meta 公开的性能数据比较具体，但不同指标代表的含义需要区分。

指标	Meta 公布的数据	实际含义
端到端首响应	约 870ms	用户轮次结束到收到同步音视频首字节
视频规格	448×768、25 FPS	研究系统输出的竖屏视频分辨率与帧率
单步视频生成	20ms 生成 8 帧	单路 GB200 测试中的模型计算耗时
每段播放时长	320ms	8 帧在 25 FPS 下对应的播放时间
单卡并发	12 路视频会话	单张 NVIDIA GB200 在指定配置下的并发视频生成能力
服务容量提升	8 倍	相对于 Meta 的两步 BF16 基线配置

1. 870ms 是首字节延迟，不是完整回答时间

Meta 对 870ms 的定义是：从用户结束一轮讲话，到客户端收到同步语音和视频回复的第一个字节。

这意味着系统已经开始输出音视频，并不意味着整个回答已经生成完毕。

对于持续对话，后面的声音和画面还需要边生成边传输。

因此，870ms 不能直接与其他模型公布的 LLM 首 Token 延迟、TTS 首音频延迟或完整视频生成时间比较。

不同测试是否包含网络传输、播放器缓冲、音频解码等环节，也会影响指标的可比性。

2. 20ms 生成 8 帧，不代表观众只需要等 20ms

Meta 披露，在单张 GB200 上，模型的一次生成步骤可以用约 20ms 计算出 8 帧视频。这 8 帧在 25 FPS 下对应 320ms 的播放时长。

换算下来，模型平均每帧计算时间约为 2.5ms。

这说明模型的视频生成吞吐能力超过了实时播放所需的速度，为多会话调度和传输留下了计算空间。

但这里统计的是模型生成阶段，不包括完整语音理解、回复生成、媒体编码、网络传输和客户端显示的全部耗时。

3. 12 路并发反映的是特定 GPU 配置下的视频容量

Meta 表示，经过 4-bit 量化、缓存复用和推理调度优化后，单张 GB200 可以支持 12 路实时数字人视频生成会话。

与其两步 BF16 基线相比，视频服务容量提升了 8 倍。

这里有两个限制。

首先，这是 Meta 在指定软硬件配置下获得的内部测试结果，不能直接用于其他 GPU 或第三方模型部署。

其次，12 路属于视频生成侧的并发能力，不代表语音模型、应用服务器和网络分发在所有部署中都能以相同容量运行。

如果要计算实际业务成本，还需要结合语音推理、视频生成实例利用率、网络和存储成本进行完整评估。

---

六. 用户打断数字人时，系统需要处理什么？

Meta 在 11 月 5 日的产品公告中明确表示，用户可以在 Muse 讲话过程中插话，Muse 会根据新的对话继续回应。

但这项能力涉及的不只是语音识别。

1. 旧语音停止后，旧视频也必须停止

假设 Muse 正在解释一个旅行计划，用户突然要求换一个目的地。

如果系统已经识别到新的指令，却仍然继续播放之前生成的语音和数字人动作，用户就会感觉打断没有生效。

因此，实时数字人在处理中断时，需要让语音播放与视频生成的状态保持一致。

如果新的回复已经开始，而旧视频片段仍留在播放队列中，就可能出现声音已经改变、画面却仍在执行上一段动作的情况。

Meta 公布了 Muse 支持打断的产品能力，但没有公开完整的音视频队列清理策略、打断后上下文修正方式，以及毫秒级打断响应测量。

这些细节仍属于值得进一步研究的工程问题，不能直接从其生成模型架构推断出具体实现。

2. 数字人需要在聆听和说话状态之间切换

用户插话后，角色不应该继续表现出正在讲话的状态。

合理的交互过程，是语音系统识别新的输入，当前播报终止，数字人转入聆听状态，随后根据新回复继续生成画面。

这里还要处理短暂静音、说话人切换和环境噪声等问题。如果系统把背景人声误判为用户打断，可能频繁中止回复。

尤其在多人环境或智能硬件场景中，目标说话人的识别和音频输入管理会影响交互稳定性。

Meta 尚未公开 Muse 当前版本在这些场景下的完整测试数据。

3. 查询外部信息时，Muse 仍可能短暂停顿

11 月 5 日上线后，The Verge 的实际体验报道提到，Muse 的语音回复总体较快，但当系统需要查找信息时，仍可能出现短暂等待。

这个现象并不难理解。

实时语音模型可以缩短语言生成和语音输出的等待，但当任务需要搜索信息、访问工具或处理外部服务时，系统仍然要等待真实结果。

对这类 Agent 而言，如何在工具调用期间保持自然的对话节奏，是与数字人视频生成不同的另一个工程问题。

目前的公开资料不足以证明 Muse 已经对所有工具调用实现了完全非阻塞的连续语音播报。

---

七. 实时数字人正在进入哪些产品场景？

1. AI 陪伴：角色能够持续参与对话

对于 AI 陪伴产品，数字人形象、语音、表情和动作共同构成角色体验。

如果角色能够在用户说话时表现出聆听状态，在回复时自然生成口型与动作，交互方式就会更接近面对面交流。

但这类产品还需要处理角色记忆、用户隐私、未成年人保护及长期使用中的行为边界。

2. 教育与培训：从语音陪练扩展到可视化教学角色

Meta 将面试练习和演讲排练列为 Muse 的使用场景。

如果进一步用于语言教育，动态数字人可以提供可视化的对话对象。例如，学生练习口语时，可以听到老师回复，并看到角色的表情和说话动作。

不过，数字人的口型生成质量不能直接等同于准确的发音教学能力。如果产品需要教授音素和口型，还需要验证生成画面是否具有足够的语音学准确性。

3. 游戏与虚拟角色：减少固定动画的限制

游戏 NPC 通常依靠预制语音和动画表现角色性格。

实时数字人模型允许角色根据当前对话生成新的声音与动作，适合需要开放式交流的游戏场景。

但对于大量角色同时出现的游戏，推理成本和并发容量会成为重要限制。并不是每个 NPC 都适合长期运行一套高规格的实时视频生成模型。

4. 智能硬件：小屏幕也可能成为 Agent 的交互界面

Meta 已经计划把 Muse 语音能力扩展到 AI 眼镜和 Muse Charm。

对于带屏幕的可穿戴设备，动态角色可以用于反馈 Agent 当前是在聆听、执行任务还是等待用户确认。

但受限于设备体积、算力、续航和散热，实际产品可能需要采用云端生成、轻量级本地动画或两者结合的方式。

目前不能把 Muse 在 GB200 上取得的视频生成性能，直接当作智能眼镜或微型穿戴设备的端侧运行能力。

---

八. 实时数字人还有哪些实际限制？

1. 视频生成仍然需要较高算力

Meta 在单张 GB200 上实现 12 路实时视频生成会话，是经过专门模型蒸馏和推理优化后的结果。

这表明生成式数字人已经具备更强的实时服务能力，但运行成本仍然需要评估。

对于面向大量用户的商业产品，动态视频模式与纯语音模式可能需要采用不同的资源分配策略。

2. 实时视频生成不等于实时视频通信

Muse 的主要技术创新发生在语音与视频内容生成环节。

内容生成后，仍需要经过音视频编码、网络传输、解码和终端播放。

网络抖动、播放缓冲和终端渲染都会影响用户看到的实际效果。

因此，研究中的 870ms 首字节指标不能完整代表所有网络环境下的最终交互体验。

3. 生成式数字人需要明确内容来源

当模型能够根据一张照片生成自然讲话的人物视频时，也会带来身份冒用和未经授权使用肖像的问题。

Meta 在研究中提到使用 Meta Video Seal，为生成的视频嵌入不可见水印，以支持内容来源识别。

官方表示，这种水印处理不会增加实时生成延迟。

但水印并不能替代肖像授权、内容审核或用户身份保护机制。Meta 也明确说明，研究文章中的演示形象不代表全部都能在 Muse App 中使用，Muse 面向 18 岁及以上用户。

---

九. 从 Muse 看实时数字人技术走到了哪一步

从技术上看，Muse 值得关注的地方是它将语音和视频生成放到同一个持续运行的系统中，并通过两步扩散蒸馏、滚动上下文缓存及 GPU 调度，使数字人能够跟随实时对话不断生成新画面。

870ms 的同步音视频首字节延迟、25 FPS 视频输出和单卡 12 路视频并发，提供了一组可以具体讨论的工程指标。

但这些指标仍来自 Meta 的研究与内部测试。实际部署中，长时间画面稳定性、网络传输、生成成本和用户打断体验，还需要更多生产环境数据。

对于开发者，这次发布最有参考价值的，是 Meta 如何将一个计算量很大的生成式视频模型，改造成能够持续输出、支持多轮对话的实时服务。