共计 4481 个字符，预计需要花费 12 分钟才能阅读完成。
池炜恒（池化）投稿
量子位 | 公众号 QbitAI
全新的开源数字人实时对话 Demo 已正式发布～
它支持 语音输入与实时互动 ，并且数字人的 外观可以自定义。
生成的数字人效果如下：
[视频内容] 本文包含视频内容
目前，这款数字人实时对话 Demo 已在阿里巴巴 ModelScope 魔搭社区中上线。
用户可以无需预先训练，直接使用自定义的数字人形象进行实时对话，支持选择不同的数字人形象和声音，首包对话延迟 可低至 3 秒。
该项目基于开源技术，采用模块化设计，各个模块能够快速替换，开发者可以自由进行扩展和优化，适合多种应用场景，例如直播、新闻播报和聊天助手等。
此外，该项目通过 Gradio 5 实现流式视频输出，便于快速部署和构建交互式数字人应用。
项目概述
当前流行的开源数字人项目主要包括以下几种：
Linly Talker 是一个基于 Gradio 的数字人对话平台，集成了多种模型，功能多样，但不支持实时对话和流式输出。
LiveTalking 是一个基于流媒体技术的数字人生成项目，反应速度较快，但其交互界面较为简单，且配置服务器的过程相对复杂，部署难度较大。
awesome-digital-human-live2d 是一个基于 Dify 编排的数字人互动项目，具有轻量化和丰富的交互方式，但其数字人形象的真实感不足，并且不支持口型同步功能。
为了解决现有开源项目的不足，本项目推出了一个基于开源技术的解决方案，支持语音输入和实时对话，数字人形象真实且实现了口型同步，并且可在线试用的开源数字人实时对话 Demo。
技术选择
考虑到目前缺乏优秀的开源端到端语音 / 视频对话模型，本项目选择了多模块级联的技术方案。
首先，通过语音识别 （ASR） 模块将用户的语音输入转化为文本，接着将文本输入到大语言模型 （LLM） 模块以生成相应的文本回复。然后，文本转语音 （TTS） 模块会根据生成的文本进行语音合成，最后通过说话人生成 （THG） 模块，得到具有唇形同步的数字人说话视频，实现用户语音输入与数字人视频输出之间的对话效果。
此外，为了便于在线试用和快速本地部署，采用了流行的 Gradio 框架来构建交互式应用。
下面将对各个模块所采用的开源技术进行详细说明。
语音识别 （Automatic Speech Recognition，ASR） 模块的主要任务是把用户的语音输入转换为文本。在这个项目中，我们选择了功能强大的工业级语音识别工具包——FunASR。
与 PaddleSpeech、kaldi 等同类型的项目相比，FunASR 展现了更为多样的功能，包括语音识别、语音端点检测、标点恢复、语言模型、说话人验证、说话人分离以及多人对话语音识别等。
这不仅使得开发者能够在现有的演示基础上进行扩展，增加更多的语音功能，还能简化部署过程，确保提供高效且精准的语音识别服务。
大语言模型 （Large Language Model，LLM） 模块的职责是生成回复内容。
为此，我们引入了目前广受关注的开源 LLM——通义千问，用以生成对话的结果。
为了提升 LLM 模块的响应速度而又不妨碍对话的效果，我们采用了轻量级的模型，专门用于日常聊天场景。
若开发者希望拓展至其他应用场景，可以选择更大参数规模的模型或多模态 LLM，如 Qwen-VL、Qwen-Audio 等，以适应更复杂的对话需求。
本项目支持单轮对话与互动对话两种模式。其中，互动对话模式利用 OpenAI 的 meta-prompt 来生成提示词，每次仅回复简短的内容，从而实现高效的一问一答互动。
文本转语音 （Text to Speech，TTS） 模块的主要功能在于将生成的文本内容转化为流畅自然的语音。
通过工程优化，GPT-SoVITS 实现了推理速度的提升，支持并行处理，以提高 TTS 的响应效率。
与之相比，另一受欢迎的项目 ChatTTS 虽然在语气和韵律的表现上更接近人类，但推理速度却相对较慢，并且在短文本的情况下，其韵律的优势并不明显。
从现阶段来看，GPT-SoVITS 显然更适用于实时对话的场景。
此外，对于计算能力有限的开发者，可以考虑使用开源项目 edge-tts 进行语音合成。该项目利用微软 Edge 浏览器提供的免费在线语音合成服务，合成速度相比 GPT-SoVITS 更为迅速。
该演示还支持调用开源项目 CosyVoice 的 API，得到了阿里云大模型服务平台百炼 （Model Studio） 的支持。
说话人生成 （Talking Head Generation，THG） 模块的任务是基于输入的语音创建一个人物的讲话视频。
该项目采用了当前实时性最佳的 THG 方案MuseTalk。
MuseTalk 专注于处理视频中角色嘴唇周围的图像。通过将输入的图像和音频进行编码，系统采用交叉注意力机制来实现二者的融合，最后利用轻量化的 Unet 模型进行推理。
在经过预处理之后，MuseTalk 在 V100 上能够实现超过 30fps 的处理速度，这一性能满足了当前数字人实时生成的需求。
与其他开源的唇形同步方案（如 Wav2Lip、TalkLip、VideoRetalking 等）相比，MuseTalk 在提高生成速度和视频清晰度的同时，依然保持了良好的唇形同步效果，并且不需要额外的训练便可完成推理。
尽管基于扩散模型的开源方案（例如 EMO、Echomimic、Vasa- 1 等）生成的视频结果缺乏多样性，但考虑到这类方案通常需要几分钟的生成时间以及巨大的训练和推理开销，它们显然不适用于实时对话的场景。
更进一步讲，唇形同步方案是依据特定人物视频生成的，因此通过丰富输入人物视频中的动作和表情，可以显著提升整体的视觉效果。
若需根据输入的角色图像生成视频，可以利用 MuseTalk 团队的开源项目 MuseV 和 MusePose 来创建具有表情和动作的人物视频，亦可采用图生视频模型来达到所需效果。
如果不受限于特定角色形象，还可以运用文生视频模型来激发更丰富的想象力。
前后端 部分选择了适合进行在线演示和本地快速部署的 Gradio。为实现视频流的传输，本项目采用了 Gradio 5 的 Video Streaming 功能。
由于 Gradio 5 刚刚发布且进行了较大改动，创空间暂时尚不支持，因此在创空间上的演示使用的是支持 Video Streaming 的 gradio 4.40.0 测试版，用户在本地部署时可以直接使用最新的 Gradio 5。
此外，本项目还借助 ModelScope 提供的高阶自定义 Gradio 组件库，其中包含升级版的 chatbot 组件，具备输出图片、视频等多模态内容的能力。
同时，Lifecycle 组件和 Gradio 的 State 组件可以有效管理不同用户的聊天记录。借助这些组件，开发者无需具备任何前端知识即可创建功能丰富的在线互动应用。
系统架构
鉴于 LLM、TTS 和 THG 这三大模块均需一定的处理时间，如果等前一个模块完全处理完再开始下一个，将无法实现实时对话的目标。为此，本项目采取了如下措施：
开源方案代码重构与流式输出优化分析
- 对所选的开源方案进行了代码重构，将模型的初始化和推理过程分开，并在正式推理之前进行模型热身，以避免在首次推理时产生额外的初始化开销，从而提升模型的推理速度。
- 引入了支持流式输出的并行处理流水线，实现边推理边播放的功能，显著提高了数字人的响应速度。
接下来，我们将详细探讨这个流式输出的并行处理流水线。
通过使用 LLM 的流式输出模式，系统在接收到一定数量的文本后可立即启动后续处理。出于以下原因，本项目决定 以句子为处理单位：
- TTS 模块中的 GPT-SoVITS 需要根据输入文本的上下文来调整语音的语调和停顿等韵律，为了确保语音流畅，需等到 LLM 输出若干完整句子后再进行 TTS 处理。
- THG 模块的 MuseTalk 必须依赖一定长度的音频上下文来实现唇形同步推理。
- Gradio 的 Video 组件只能接收带音轨的视频片段而非字节流，且还需要结合 ffmpeg 工具将 TTS 模块输出的音频与 THG 模块生成的视频帧合成为 ts 或 mp4 格式的视频。
基于此，本项目维护多个队列，分别存储 LLM 生成的句子、TTS 生成的音频和 THG 生成的视频帧，并利用多线程实现并行处理。这种策略使得在处理完第一个句子后，数字人的响应可以立即开始，从而实现边推理边播放，显著减少用户的等待时间。
上图中绿色标注的处理时间即为与数字人对话的首包延迟。
考虑到 MuseTalk 的推理时间与输入音频的长度呈正相关，为了确保推理时的流畅性，研究人员指出需尽量保持每次处理片段的长度均匀。
鉴于不同句子的长度各异，本项目设定了一个最小长度，只有当 LLM 缓冲区中的句子长度超过该值时，才将这部分内容作为一个包送入流水线进行处理。这个最小长度需要根据 GPU 性能动态调整，以平衡首包延迟和整体流畅度。
时延分析
以语音输入“今天天气怎么样”为例，研究团队在单张 A100 显卡上测试了各个模块的耗时和播放延迟。
为确保后续包的流畅性，最小长度设定为 10 个字符，只有在 LLM 生成的句子累计超过 10 个字符后才开始处理。这一设置保证了流式播放时，后续包的延迟保持在较低水平。
就首包而言，用户感受到的播放延迟是所有模块耗时的总和。从上图可以看出，除了首包外，后续包的播放延迟均低于 0.5 秒。
由于句子之间本身存在停顿，这种延迟几乎不会对用户体验产生影响。
若想在本地运行该项目，可以参考项目的 README 进行环境配置，支持更换各个模块的技术选型，并能加入自定义的数字人音色和形象视频。
接下来的步骤中，本项目将从以下几个方面进行优化：
- 链路优化：目前 THG 模块需要接收一段完整的音频作为输入，因此包与包之间的延迟会受到音频长度的影响。计划对这部分链路进行优化，以提高整体性能。
- 端到端语音聊天：OpenAI 在本月初发布了端到端的实时语音聊天 API，可以有效替代现有的级联链路，缩短数字人的响应时间。待 OpenAI 正式上线 API 或有其他开源的端到端方案后，将进行相应更新。
- 流式视频播放：当前 Gradio 5 的 Video Streaming 功能是基于 HLS 协议实现的，计划在后续版本中采用性能更优的方案，以提升用户体验。
对本项目感兴趣的朋友可以试用在线 demo～
项目链接：https://www.modelscope.cn/studios/AI-ModelScope/video_chat
项目 README：
https://www.modelscope.cn/studios/AI-ModelScope/video_chat/file/view/master?fileName=README.md&status=1
创空间体验地址：
https://www.modelscope.cn/studios/AI-ModelScope/video_chat
代码仓库：https://github.com/Henry-23/VideoChat
— 完 —
量子位 QbitAI · 头条号签约
关注我们，第一时间获知前沿科技动态
