跳到主要内容

视频会议中的数字人:构建用于视频会议的实时对话头像 AI

· 阅读需 13 分钟
Tian Pan
Software Engineer

拥有面孔的语音智能体并非简单的“带脸的语音助手”。它是一个同步视频 AI 系统,当人类第一次看到口型落后于音频三帧,并下意识地(即使无法准确说出原因)判定屏幕上的东西是假的时候,这种差异就显现出来了。那些构建了 300 毫秒语音流水线,然后又在末尾强行塞入一个渲染模型的纯语音团队,刚刚继承了一个他们在路线图中未曾预料到的实时多模态问题。

这个门槛并不宽松。在音视频偏移低于约 45 毫秒时,观众会认为是完美同步。一旦音频领先超过 125 毫秒或音频滞后超过 45 毫秒,大脑就会将这种不匹配标记为错误,即使观众无法指出具体原因。在一个数字人必须同时倾听、思考、说话和渲染的对话循环中——且在你和用户之间还隔着网络——音频输出和渲染面孔之间没有任何余地来容纳拙劣的衔接。

当你将 AI 数字人集成到会议产品中时,这才是真正重要的标准。不是“在工作站录制的演示中看起来令人惊叹”,而是“在住宅 Wi-Fi 连接下,当 LLM 因为缓慢的工具调用而卡顿时,依然能保持同步”。那些成功做到的团队已经不再将数字人视为图形输出,而是将其视为一个恰好包含面孔的实时流。

延迟预算比语音预算更紧张

一个体面的语音智能体运行在 300 毫秒的响应预算内——当用户还在说话时,语音转文字(STT)就开始输出部分转录,语言模型在获得足够上下文后开始生成,文字转语音(TTS)在每个 Token 块到达时将其转化为音频,用户在说完话后的 300 毫秒内就能听到第一个词。组件级的详细拆解可以参考已发布的语音 AI 流水线分析:仅 TTS 本身贡献的首字节时间就不应超过 100–200 毫秒。

增加面孔并不会增加这个预算,反而会消耗它。数字人流水线现在必须渲染口型与 TTS 正在生成的音频相匹配的帧,而且必须在不产生足以破坏语音循环响应目标的音频缓冲的情况下完成。Tavus 的 Phoenix-4 发布其实时面部合成的延迟约为 600 毫秒,这让你对生产级系统实际交付的水平有了直观感受;Anam 的 CARA-3 报告在 25fps/720x480 下的中值延迟为 180 毫秒。较新的流式研究模型——在单个 GPU 上达到 16fps 的 JoyStreamer-Flash,以及通过潜空间修复保持 30+ fps 的 MuseTalk——才是那些能够被链接到对话循环中而不让用户等待两倍时间的幸存者。

大多数团队在结构选择上都犯了错:他们将语音和面部视为顺序流水线。语音结束,然后渲染面孔。这种模式对于预制视频没问题,但在会议中是致命的,因为数字人必须在完整句子生成之前就开始动嘴。有效的架构将渲染阶段视为流式 TTS 的流式消费者——音素流入视素表,视素表驱动面部解码器,每一帧视频在发出时都带有一个与其对应的音频采样绑定的呈现时间戳。

音视频同步已是成熟技术——直到你加入了生成帧

WebRTC 利用 RFC 3550 处理口型同步已有十年之久——RTCP 发送端报告携带与 RTP 时间戳配对的 NTP 时间戳,接收端重建音视频流之间的挂钟时间关系,渲染器将视频帧从属于音频时钟。音频中断比丢弃视频帧更容易被察觉,因此当网络出现抖动时,宁愿跳过视频也不愿让语音停顿。这是人与人通话中经过验证的成熟路径,直到其中一个流是由云端 GPU 上的神经网络逐帧生成时,情况发生了变化。

生成式视频打破了这些假设。编码器不再是以固定频率采集的摄像头,而是一个吞吐量随提示词复杂度、GPU 竞争以及前一帧潜状态复用程度而波动的模型。如果模型偶尔需要 80 毫秒而不是 33 毫秒来生成一帧,音频时钟会继续前进,而口型就会落后。解决办法不是放慢音频,因为用户会立刻察觉到;解决办法是设计系统,使帧生成与帧交付重叠并异步,并在两者之间设置一个小的抖动缓冲区。

生产级数字人系统大都趋向于类似的形态。D-ID 的流水线并行运行多个阶段,据报道其内部生成的视频达到 100fps,约为播放速度的四倍,这样偶尔的慢帧会被缓冲区吸收而不会导致衔接停顿。生成的帧进入本地队列,进行异步编码,并带上引用其应对齐音频的时间戳发出。当缓冲区健康时,系统流畅传输;当缓冲区耗尽时,选择是丢帧或在最后一帧好帧与下一帧之间进行插值——绝不延迟音频。

在生成负载下,另一件会崩溃的事是时钟漂移。WebRTC 对于摄像头画面可以很好地容忍发送端和接收端之间 0.1% 的漂移,因为摄像头和网卡共享硬件振荡器。但如果模型运行在 GPU pod 上,音频路径运行在 CPU pod 上,而网络出口又有自己的时钟——这三个时间基准的漂移速度之快,如果系统不定期根据 RTCP 发送端报告进行重新同步,一个五分钟的通话就会积累出明显的滞后。

离线评估中无法发现的失败模式

你用来评估数字人模型的评估集是在工作站上运行的,具有确定性的 GPU 调度,且不涉及网络延迟。在生产环境中,真正重要的失败模式是那些仅在实时条件下才会显现的模式,它们具有特定的特征:微妙、大多难以察觉,但又足够连贯,以至于人类观众在观看后会有一种“哪里不太对劲”的模糊感觉。

三帧的口型同步(lip-sync)漂移就是一个典型的例子。在 30 fps 的帧率下,三帧意味着 100 ms —— 这远超出了 45 ms 的“音频滞后于视频”的感知阈值,正好处于大脑能察觉到不匹配但又无法准确定位的区间。检测研究从相反的方向得出了同样的观察结果:像 LIPINC 以及最近关于嘴部不一致性的 vision-temporal-transformer 研究表明,识别口型同步深度伪造(deepfake)最可靠的信号,正是嘴部区域这种微小的时序漂移。如果鉴定模型能发现,人类也能发现,即使人类只能将结果描述为“感觉不对”。

其他在离线评估中无法发现的失败模式包括:

  • 流式传输下的音素-视素(Phoneme-viseme)错位。 TTS 以块(chunks)的形式输出,而视素调度是在线计算的。如果块边界恰好落在音素中间 —— 例如跨越两个块的长音 /sh/ 或 /aɪ/ —— 面部解码器可能会过早地切换视素形状,产生一个在静态帧中不可见但在动态中非常刺眼的短暂闪烁。
  • 流重启时的表情连续性。 当 WebRTC 流重新协商时 —— 例如网络跳点改变、编码器重新初始化、数字人状态必须重置 —— 面部可能会猛然切换到中性表情,然后再重新进入状态。在会议中,这会被解读为“眼神中瞬间失去了神采”。
  • 背景运动卡顿。 数字人的身体和手部动作的时序频率比嘴唇低得多。当嘴部持续运动时,身体若出现微妙的冻结,会发出“由两个模型拼接而成”而非“真实人类”的信号。
  • 停顿期间的目光漂移。 当数字人在倾听而非说话时,目光模型没有音频流可以驱动,简单的系统会让眼睛漫游到一个默认的注意力点。人类会将停顿期间的目光游离解释为注意力不集中,这与产品想要传达的效果恰恰相反。

这些都无法通过单帧质量指标捕捉到。你真正需要的评估信号是时序性的 —— 多秒窗口内的同步偏差、视素转换的平滑度、基于语音状态的目光稳定性 —— 而大多数团队并不具备这种评估能力。

目光与存在感是产品的一个维度

视频通话中的眼神接触问题并不新鲜。摄像头位于屏幕上方或侧面,因此当用户注视屏幕上的脸部时,他们并没有直视摄像头。NVIDIA Broadcast、Apple 的 FaceTime 目光矫正以及越来越多的消费级工具,至少从 2023 年起就针对这一问题的人类端推出了修复功能。对于 AI 数字人来说,等效的问题更难:数字人没有真实的摄像头,也没有真实的眼睛位置,因此它的目光取决于渲染模型,而模型必须在每一帧都做出决定。

做得好的团队会将目光视为一个产品维度,而非仅仅是一个模型输出。数字人在说话时应该注视摄像头,而在思考停顿时应该略微移开视线,因为持续盯着镜头看会让人感到具有威胁性,而不是专注。在多人通话中,它应该根据发言者的切换来重定向目光,因为在三个人中的一个正在说话时,它如果一直盯着前方看,会显得非常迟钝。每一刻的目光轨迹应该是渲染模型的一个输入信号,而不是某个激活的潜状态(latent state)的副作用。

同理也适用于微表情。一个真实的人在听坏消息时不会保持中性表情 —— 眉毛会有轻微的动作,头部会略微倾斜,嘴唇会有一瞬间的紧闭。如果通话另一端的人正在传达沉重的信息,而数字人却保持着平稳的中性表情,这比完全没有表情更令人不安,因为在强烈情感内容面前缺乏表情会被解读为异常。产品层面的问题是决定渲染哪些表情以及何时渲染,而不是模型是否具备产生这些表情的能力。

设计衔接处

针对会议中播报型(talking-head)AI 的可靠工程架构已经收敛于几个原则,这些原则与其说是为了把模型做得更大,不如说是为了让音频输出和渲染面部之间的衔接(seam)能够在实时流中存续。

将音频视为基准时钟(Master Clock)。 以固定的节奏块(通常为 20 ms 或 40 ms)生成音频,根据单一单调时钟(monotonic clock)为每个块添加时间戳,并将视频帧的生成从属于这些时间戳。当模型变慢时,音频仍按时发送;当网络发生抖动时,接收端的抖动缓冲区(jitter buffer)会进行吸收;当两者同时失效时,先丢弃视频帧,也绝不延迟音频。

构建视素调度表,而非帧流。 渲染模型应该接收由 TTS 输出生成的(视素、开始时间、持续时间、强度)元组序列,而不是标记化的(tokenized)文本流。这解耦了语音计时与渲染吞吐量,使得在渲染变慢时,可以通过在预定视素之间进行插值来恢复,而不是停顿。

运行带显式缓冲区的并行阶段推理。 音频合成、视素调度、面部解码和帧编码应当各自作为独立阶段运行,并在它们之间设置有界队列。当队列填满时,你有一个清晰的背压(backpressure)信号;当队列耗尽时,你确切地知道哪个阶段是瓶颈。东北大学(Northeastern)发表的关于实时数字人系统的论文将此规范化为带队列的重叠阶段,每个在延迟预算内生存下来的生产系统最终都会呈现出这种形式。

基于时间切片而非单帧进行评估。 建立评估体系,对同步偏差、视素转换平滑度、跨语音状态切换的目光稳定性以及跨流重启的表情连续性进行评分。单帧质量是必要的,但远远不够。

为重新协商(Renegotiation)情况做准备。 在真实的会议中,网络跳点变化、编解码器更改和流重启都会发生。在这些事件发生时持久化足够的数字人状态,使面部不会出现明显的重置,并将恢复时间定在音频的自然停顿处,而不是句子中间。

走向何方

语音 AI 赛道迅速商品化。第一波产品的差异化在于 LLM 和 prompt;第二波在于语音克隆和延迟;第三波则在于渲染的面部,而这一领域的竞争门槛比语音领域高出几个数量级。在这个层级胜出的团队,靠的不是最好的模型,而是最严谨的实时工程能力——音频主时钟、视位调度(viseme schedule)、阶段式推理流水线,以及时间维度评估(temporal evals)。

对于产品形态而言,问题不在于你的会议产品能否渲染出数字人,而在于该数字人能否在 5 分钟、两跳网络、三人参与的通话中,始终不让观看的人感到违和。这是一个纯语音路线图中未曾包含的多模态实时工程问题。尚未开始为此布局的团队,其交付的路线图将止步于下一个产品形态的门槛。

References:Let's stay in touch and Follow me for more thoughts and updates