AI 数字人直播如何实现实时互动？从语音生成到画面同步

Live Play Mobile 是一家以互动游戏直播为核心业务的公司，旗下 Live Play Bingo 将真人主持、宾果游戏和电视节目式的直播内容结合起来。但主持人的工作时间有限，为填补没有真人主持的时段，Live Play Mobile 开始将 AI 数字人引入游戏直播，让虚拟主持人承担播报、交流和游戏互动等工作。

公司利用超过 10 万小时的真人主持视频与文字记录，为 AI 主持人的设计提供参考，并通过声网对话式AI引擎 和实时通信基础设施构建数字人主持系统。其AI 主持人已经用于三款游戏，覆盖原本每天有 16 小时没有真人主持的时段。与无主持人的游戏场次相比，数字人主持场次的玩家留存率提升 75%，每用户收入达到 1.75 倍。

本文结合 Live Play Mobile 的实际案例与 LiveTalking 开源项目，介绍 AI 数字人直播的技术架构及实时互动实现方式。

---

一. AI 数字人直播如何参与真实业务？

1. Live Play Mobile：让 AI 主持人接入正在运行的游戏

Live Play Mobile 的特点是把游戏与节目直播结合起来。游戏流程持续进行，主持人负责活跃气氛、解释玩法、播报游戏状态，并与参与者建立互动。

这类主持工作需要持续获取游戏信息，不能只依靠提前录制的话术。

例如，宾果游戏中的号码抽取、局势变化、玩家参与情况，都可能成为主持内容的一部分。AI 主持人需要根据真实游戏状态安排播报，而不是自行编造游戏结果。

在技术实现上，应用可以将游戏状态通过受控业务接口传递给 Agent，再由语言模型生成适合直播场景的表达。

例如，游戏服务发出某个号码已抽取的事件后，主持系统可以据此生成播报内容；当玩家提出有关规则的问题时，Agent 再调用相应知识库或业务接口获取信息。

2. 数字人直播通常有三种交互方式

按照内容生成和用户参与方式，数字人直播可以分为三类。

第一类是预设内容播报。系统依据既定脚本生成语音与画面，按照节目计划播放。新闻播报、产品介绍和固定培训内容通常可以采用这种方式。

第二类是事件驱动直播。游戏状态、活动开始、礼物事件、业务系统通知等触发数字人发言。模型需要根据事件内容选择话术，但不一定直接与某个用户进行多轮对话。

第三类是实时对话互动。观众通过文字、语音或连麦参与，数字人根据输入内容生成新的回复。此时系统还要处理多轮上下文、用户优先级、轮次判断和打断。

这三类方式可以组合使用。例如，数字人主播在正常时段按照节目脚本介绍产品，收到用户提问后切换到问答状态，再根据直播活动继续播报。

开发时需要根据实际场景确定交互方式。并非所有数字人直播都需要完整的全双工语音 Agent，也不是所有弹幕都值得交给大模型处理。

---

二. AI 数字人直播的完整技术链路

对于需要实时互动的数字人直播，通常可以将系统拆成输入、对话生成、语音合成、数字人渲染和直播分发五个部分。

1. 观众输入：弹幕、语音和游戏事件需要统一管理

数字人直播的输入并不只有用户发来的文字。

一场游戏直播可能同时产生用户弹幕、礼物事件、游戏进度变化、活动通知和人工运营指令。

如果每条消息都直接触发 LLM 生成回复，数字人很容易被高频事件打断，还会产生大量不必要的推理与语音合成成本。

因此，通常需要一层事件调度系统，负责对消息进行分类、去重、限流和优先级管理。

例如，普通的问候弹幕可以合并处理，游戏关键事件优先播报，涉及规则或订单的问题交给知识库与业务接口处理。

直播平台的外部弹幕需要通过平台允许的 API 或事件机制接入。接入声网 RTM 并不意味着能够直接读取抖音、视频号或其他外部平台的弹幕。

2. LLM：除了生成文案，还要维护直播状态

AI 主持人的回复必须与正在发生的节目保持一致。

例如，某一轮游戏已经结束，主持系统不能继续回答上一轮的实时进度；某个活动已经下线，也不能继续播报过期优惠。

因此，LLM 应获取经过业务系统确认的状态信息，并根据直播节奏生成内容。

一种可行的方式是将结构化事件和自然语言生成分离：

• 游戏服务器负责提供真实游戏结果。
• 调度系统决定当前应该播报什么。
• LLM 负责组织自然、符合角色设定的语言。
• 业务规则负责限制不允许生成或执行的操作。

对于固定游戏规则、中奖结果、价格和促销信息，不能只依靠模型记忆或生成内容，应通过业务数据校验。

3. 流式 TTS：数字人不必等待完整回答生成

TTS（Text-to-Speech）负责把 AI 生成的文字转换为语音。

传统处理方式可能等待 LLM 完整生成回复，再将整段文本提交给 TTS。如果回答较长，用户会感受到额外等待。

流式 TTS 可以接收分段文本，并持续输出音频，使系统较早开始播报。

例如，一段回答可以按照语义较完整的短句分段处理。前一段正在合成或播放时，LLM 可以继续生成后面的内容。

但文本切分不能过于激进。过短的片段可能缺少上下文，导致语音停顿、重音和语调不自然。

数字人直播还需要考虑 TTS 输出与口型驱动的数据接口。部分 TTS 系统可以输出音素或 Viseme（可视语音单元）及时间信息，便于渲染引擎直接匹配口型；其他系统则需要从生成的音频中提取声学特征。

因此，选择 TTS 服务时，除了音色与首包延迟，也要检查它是否能满足数字人渲染模块的数据需求。

---

三. 数字人的嘴型为什么容易和声音对不上？

数字人直播同时生成音频和视频。两路内容来自不同的处理过程，如果没有统一的时间基准，就容易出现嘴巴已经动了、声音还没播放，或者人物已经停止说话、音频仍在继续的情况。

1. Lip Sync 如何从声音生成口型？

Lip Sync 指口型同步。数字人系统需要依据语音内容或声音特征，让虚拟角色的嘴部动作与实际发音对应。

常见实现方式包括音素或 Viseme 驱动、音频特征驱动，以及利用神经网络直接生成说话面部画面。

例如，在音素驱动方案中，TTS 或对齐模型提供语音对应的音素和时间位置，渲染程序将音素映射到角色的口型参数。

对于 3D 数字人，这些参数可以驱动 Blendshape（表情混合形变）或骨骼；对于 2D 数字人，可以用于切换嘴部形状；对于照片级数字人，则可能通过生成式模型合成新的嘴部区域。

不同方案的计算成本和视觉效果差异很大，不能用一个通用的 Lip Sync 算法概括所有数字人。

2. LiveTalking：一个可参考的实时数字人开源架构

LiveTalking 是由开发者 Hengzhong Li 维护的实时交互数字人项目，支持 Wav2Lip、MuseTalk 和其他数字人模型，同时提供 WebRTC、RTMP 和虚拟摄像头等输出方式。

根据项目公开架构，系统可以接收 LLM 生成的文本，再通过 TTS 得到语音，从音频中提取声学特征，驱动模型生成相应的口型画面。

在部分模型路径中，系统将生成的嘴部区域与原始形象画面组合，再进行音视频输出。

LiveTalking 还提供不说话时的动作编排、数字人中途打断和多会话管理等功能。

项目 README 公布了不同 GPU 条件下的推理帧率。例如，Wav2Lip256 在 RTX 3060 上报告约 60 FPS，MuseTalk 在 RTX 3080 Ti 上约 42 FPS。这些是项目维护者披露的特定模型和硬件测试数据，不代表完整 LLM → TTS → 视频分发链路能够达到相同帧率或延迟。

项目还特别区分两个指标：

• inferfps：GPU 模型生成画面的推理帧率。
• finalfps：最终输出视频流的实际帧率。

即使 GPU 推理帧率足够，如果后处理、编码或 CPU 计算出现瓶颈，最终视频仍可能卡顿。

3. 声音与画面需要使用一致的时间基准

假设一段 TTS 音频持续 3 秒，数字人渲染模块需要生成对应时长的口型画面。

在每秒 25 帧的视频输出条件下，理想情况下对应约 75 帧画面。但系统真正需要保证的并不是简单的帧数相等，而是每个视频帧显示时，对应的语音片段能够在正确时间播放。

在流式生成过程中，TTS 音频与数字人视频通常分别经过缓冲、渲染和编码。开发者需要建立统一的媒体时间轴，为音频片段和对应视频帧分配时间戳，再交由媒体传输与播放系统处理。

如果某一段视频来不及生成，可能需要根据业务要求延长缓冲、补帧、降低渲染复杂度，或者采用预先准备的过渡动作。

但不能无限制增加缓冲，否则数字人虽然口型准确，整场直播的互动延迟却会越来越大。

4. 表情和动作也要与语音内容匹配

口型同步只是数字人表现的一部分。

真实主持人讲话时还会有点头、手势、目光和表情变化。对于游戏、教育或营销场景，角色可能需要根据话题调整动作。

一种可行架构是将语音内容与动作意图分开输出。

例如，业务系统在生成中奖播报时，同时传递一个庆祝动作事件，由角色渲染系统执行相应动作。

这些动作既可以来自预先制作的动画，也可以由模型生成或选择。

但涉及“恭喜中奖”“活动成功”“订单完成”等具有实际业务意义的表达，必须以业务系统确认的状态为准，不能让数字人仅凭生成文本擅自触发。

---

四. 数字人已经生成了回答，为什么直播间还是感觉慢？

数字人直播至少存在两段需要分别衡量的延迟：一段是观众输入到数字人生成回复，另一段是数字人生成的音视频到达观众。

1. AI 响应延迟与直播分发延迟不能混为一谈

对于语音连麦，系统需要经过语音传输、识别、轮次判断、语言模型处理和 TTS 合成。

对于文字弹幕，则可以省略 ASR，但仍需要获取平台消息、调度问题、生成回复、合成语音和渲染画面。

最终，数字人音视频还要经过编码、推流、分发、解码和播放。

可以将整体耗时拆分为：

处理阶段	主要指标	影响
用户输入	消息到达时间、语音判停时间	Agent 何时获得有效问题
LLM	首 Token 延迟	回复生成速度
TTS	首音频生成时间	数字人何时能够开口
口型与画面生成	推理帧率、渲染延迟	角色动作是否流畅
直播分发	端到端媒体延迟、卡顿率	观众实际看到与听到的时间

由于流式推理和流水线处理可以重叠执行，以上各阶段的耗时不一定能简单相加。

产品体验测试应该从观众真实发起问题开始，一直记录到观众听见并看到对应回答，而不只是统计 LLM 的推理速度。

2. RTC 和 CDN 适用于不同的直播参与方式

如果直播间需要用户与 AI 数字人进行语音连麦，双方需要持续交换音频，通常更关注低延迟双向通信。

而对于大量只观看、不参与语音互动的观众，平台可能采用更适合大规模分发的直播网络。

例如，数字人渲染系统可以先生成一条音视频流，通过 RTC 提供低延迟互动，再根据实际业务需要通过 RTMP、RTMPS 等协议推送至 CDN 分发。

两种分发方式并不是互斥的。

在同一直播产品中，可以让主播与连麦用户处于 RTC 实时互动频道，而普通观众通过 CDN 观看经过处理的直播内容。

但 CDN 通常会引入额外的播放缓冲，观众看到的内容可能明显晚于互动端。因此，直播间如果需要所有观众围绕同一个实时事件参与答题、投票或竞猜，就必须考虑媒体播放进度与业务事件之间的对齐。

3. 不同观众可能正在观看不同时间的画面

一场直播中，使用 RTC 观看的用户与通过 CDN 观看的用户，可能存在不同的播放延迟。

如果数字人宣布“现在开始十秒倒计时”，后台立即按服务器时间开始计时，而部分观众还没有看到这段视频，就会出现体验不一致。

因此，对于抽奖、互动答题和游戏事件，应用应采用统一的业务事件 ID、时间戳和状态管理机制，并根据实际媒体播放策略设计参与窗口。

高实时性游戏可以采用更严格的互动延迟要求；普通商品讲解或娱乐直播，则可以根据业务成本和并发规模选择不同的分发策略。

---

五. 直播间几千条弹幕，AI 数字人应该回答哪一条？

1. 需要独立的消息调度层

在高并发直播中，观众发送消息的速度可能远高于数字人能够播报的速度。

即使模型能够同时生成多个回答，数字人仍然只有一条主要的语音播放时间线。

因此，需要在 LLM 之前建立消息调度机制。

例如，将弹幕分为普通互动、业务咨询、游戏事件、需要人工处理的问题等类型，再根据业务优先级、消息时效和去重策略选择需要处理的内容。

对于大量重复问题，可以聚合成一次统一回答。

例如，几十名观众同时询问活动什么时候结束，系统只需要查询一次真实活动时间，再由数字人进行统一播报。

2. 文字弹幕不应全部打断当前播报

直播主持需要保持基本的内容连续性。

数字人正在介绍玩法时，普通弹幕可以进入等待队列；如果出现游戏结果、系统异常或需要立即回应的业务事件，则可以根据优先级中断当前内容。

但中断需要同时处理三个部分：停止当前 TTS、清理尚未播放的音频和视频片段，以及更新当前主持任务的状态。

如果只停止语言模型生成文本，已经进入 TTS 或视频渲染队列的内容仍可能继续播出。

这也是数字人直播比纯文本聊天复杂的地方：一次打断可能涉及多个正在运行的处理模块。

3. 语音连麦需要自然打断和轮次判断

如果用户通过连麦直接与数字人交流，系统还需要判断用户何时说完，以及是否在数字人播报过程中提出了新问题。

这涉及 VAD、语义轮次判断、音频播放控制和上下文管理。

尤其需要区分直播间公共声音和目标连麦者的语音。如果所有背景人声都可能触发打断，数字人的对话状态会非常不稳定。

在实际产品中，可以根据连麦权限、参与者身份和音频通道设计明确的语音输入规则。

4. 事件需要与实际播报完成状态关联

当数字人说完“恭喜某位玩家完成任务”时，业务系统可能需要触发庆祝动画或更新直播界面。

此时不能只以 LLM 已经生成完文本作为事件完成条件。

更合理的做法是区分生成完成、音频合成完成、媒体已发送和实际播放完成等状态。

对于需要与声音严格同步的动作，可以将事件绑定到音频或视频时间轴；对于仅需逻辑顺序一致的业务操作，则可以使用业务消息及确认机制。

---

六. 声网如何支持 AI 数字人实时直播？

Live Play Mobile 的实践已经验证了 Agora 实时通信与对话式 AI 技术在游戏数字人主持场景中的应用。

对于开发者而言，可以结合声网对话式 AI 引擎、RTC、RTM 以及第三方数字人渲染服务，搭建完整的实时数字人系统。

1. 对话式 AI 引擎：处理实时语音交互与模型编排

声网对话式 AI 引擎支持接入主流 ASR、LLM 和 TTS 服务，用于实现自然语音对话。

对于数字人直播，可以由业务服务选择需要回复的弹幕或连麦问题，再根据实际模式调用 Agent 生成内容。

如果需要自然语音交互，还可以结合对话轮次判断、智能打断和流式语音处理等能力，减少用户等待。

不过，直播间弹幕调度、外部平台消息接入和游戏业务规则，仍需要由直播应用自身实现。

2. 数字人能力：通过第三方供应商提供形象与口型

声网对话式 AI 引擎支持第三方数字人能力。开发者可通过智能体配置中的 avatar.enable、avatar.vendor 和 avatar.params 等参数启用兼容的数字人服务。这使语音交互系统能够与第三方数字人形象和口型生成服务结合。

但需要注意，数字人渲染的具体效果、模型成本和同步性能取决于选用的供应商，不能直接用对话式 AI 引擎的语音响应指标代替数字人音视频整体性能。

3. RTC：承担实时音视频传输与互动

数字人生成的音视频需要通过通信网络传输到观众或连麦参与者。

开发者可以使用声网 RTC提供实时音视频通信，并根据数字人引擎的输出接口配置合适的媒体输入方式。

例如，数字人渲染服务可能输出独立音视频帧、编码流或其他媒体接口。实际集成时，需要结合 SDK 平台、自定义媒体源能力和编码格式确定方案。

RTC 负责低延迟传输，不直接替代数字人模型的视频生成、口型渲染和动画制作。

4. RTM：同步互动事件和 Agent 状态

在自建直播应用中，开发者可以使用声网 RTM传递实时消息、互动状态和必要的业务事件。

例如，数字人进入播报状态、当前问题发生变化、直播活动切换等信息，可以根据业务协议发送至客户端。

声网对话式 AI 引擎客户端组件也提供 onAgentStateChanged 等事件，用于监听智能体的静默、聆听、思考和说话状态。

但这些状态事件不等于精确的音视频帧时间戳。如果需要实现逐词字幕或口型、动作的精确对齐，还需要结合媒体时间轴和数字人引擎输出的数据。

5. 媒体服务：将互动直播扩展到 CDN 分发

对于需要兼顾实时互动和大量普通观看用户的产品，可以根据场景使用声网旁路推流服务。

根据官方文档，旁路推流可将声网频道中的音视频流转为 RTMP 或 RTMPS，并推送至 CDN。

对于单路主播视频，可以按需采用不转码推流；对于多人连麦等场景，可以通过转码合流生成统一的直播画面。

不过，CDN 分发会产生额外的媒体延迟，具体表现取决于所选 CDN、直播协议和播放器配置。

因此，在游戏互动、实时答题和数字人连麦场景中，需要根据实际延迟要求设计 RTC 与 CDN 的用户分层，而不是默认所有观众都采用同一条播放链路。

---

七. 数字人直播怎样控制 GPU、带宽和并发成本？

1. 一路公共数字人直播与多个独立数字人会话，成本差异很大

如果所有观众观看同一个 AI 主持人，可以由一套数字人渲染服务生成公共音视频流，再将其分发给多个观众。

此时，增加观众数量不一定要求同步增加数字人模型推理实例，主要需要扩展的是直播分发能力。

但如果每个用户都与自己的数字人单独对话，就需要分别维护会话状态、模型上下文、TTS 输出以及可能独立的数字人渲染任务。

这两种架构的成本模型完全不同。

LiveTalking 开源项目也指出，数字人不说话时的并发能力更多受到 CPU 处理影响，而多路同时说话时，GPU 推理资源会成为重要限制。

因此，在直播产品中，应先判断是否真正需要为每位观众生成独立数字人视频。

2. 流式生成与预生成内容可以混合使用

游戏规则介绍、固定活动通知和标准产品资料，不一定每次都需要重新调用 LLM、TTS 和视频生成模型。

对于可以提前确定的内容，可以预先生成语音和数字人动画，在需要时直接播放。

实时变化的用户问题和业务事件，再交给生成式系统处理。

这种混合方案可以减少重复推理，降低首播等待和 GPU 成本。

但需要为内容设置有效期。产品价格、库存、活动规则和游戏结果等实时数据不能无条件复用旧内容。

3. 渲染质量与运行成本需要分层设计

不同数字人模型对计算资源的要求不同。

例如，LiveTalking 支持不同的口型生成模型，可以根据形象质量、分辨率与推理速度选择实现方式。

直播场景还需要测试长时间运行的稳定性，包括 GPU 显存占用、推理队列积压、视频编码负载和会话资源释放。

一次几分钟的演示不能代替连续数小时直播的稳定性测试。

生产环境建议分别记录推理帧率、实际输出帧率、音视频同步偏差、首音频时间、视频冻结次数和每路直播的资源成本。

---

八. AI 数字人直播的技术重点在哪里？

Live Play Mobile 的案例体现了数字人参与持续性互动节目的应用价值。真人主持不在线时，AI 数字人可以承担部分播报和互动工作，让直播内容保持连续。

但要让数字人具备实时互动能力，需要把多个独立系统衔接起来。业务事件决定说什么，LLM 负责组织语言，TTS 负责生成声音，数字人引擎负责口型与动作，RTC 或直播网络负责向观众传输最终画面。

其中最容易影响体验的，是直播消息调度、音视频时间同步和媒体分发延迟。

对于产品开发团队，建议先确定数字人是面向所有观众统一播报，还是与每位用户分别对话。这个选择直接影响 Agent 会话管理、数字人渲染数量、推流架构和整体成本。

在此基础上，再根据互动场景选择流式 TTS、数字人模型、RTC 与 CDN 分发方式，并通过真实播放端数据验证效果。

数字人能够持续生成声音和画面，只是系统可运行的第一步。能否及时处理直播间事件、准确同步口型和动作，并在长时间运行中保持稳定，才是实时数字人直播需要持续优化的工程问题。