企业官网建设流程全解析

实时数字人怎么做选型与部署？LiveTalking 架构拆解与落地清单

【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream

LiveTalking 是一个实时交互流式数字人引擎：输入文本或语音，经 LLM 生成回复、TTS 合成语音、实时口型同步，最终经 WebRTC / RTMP / 虚拟摄像头推流输出，覆盖虚拟主播、AI 数字人客服、培训授课等场景。

跑通之前，开发者最常问的其实是这么几个问题：数据到底怎么流？三个模型怎么挑？部署卡在哪一步？形象怎么换？并发到底扛得住几路？这篇按问题拆开讲。

问题一：一条消息进来，到画面输出要经过哪几步？

整条链路可以拆成五段，这也是 README.md 里架构图想表达的事：

• API 层：/human接文本（echo 复读或 chat 对话两种模式），/humanaudio直接接音频文件；每条连接分配独立sessionid，天然支持多会话并发。
• LLM 引擎：默认对接 Qwen 系列（dashscope），也可换成任意 OpenAI 兼容网关，在 llm.py 里注册 provider 即可。
• TTS 引擎：模块化设计，tts/ 目录下内置 edgetts、gpt-sovits、cosyvoice、tencent、doubao 等 9 种引擎，--tts参数切换。
• 特征提取 + 渲染层：从音频里抽 Mel 等声学特征喂给口型模型推理，生成的口型区域再平滑贴回原始高清视频。
• 推流层：WebRTC、RTMP、虚拟摄像头三选一，详见问题五。

打断也在这套链路里实现：说话过程中新的输入到达，TTS 直接截断重合成，口型跟着新音频走，不需要重启会话。

问题二：wav2lip、musetalk、ultralight 三个模型怎么选？

这是参考文档里最缺的一张表。三个内置数字人模型的定位和官方实测性能如下（数据来自 README 的实测记录）：

选型逻辑一句话：显存紧张、要堆并发选 wav2lip256；单路画质优先选 musetalk；边缘设备或显存捉襟见肘选 ultralight。启动参数--model指定模型，--avatar_id指定形象，两者是配对关系——不同模型的形象文件不通用。

问题三：8G 显存环境的完整部署清单

官方在 Ubuntu 22.04 + Python 3.12 + PyTorch 2.9.1 + CUDA 12.8 环境验证过，部署分四步。

第一步，拉代码建环境：

git clone https://gitcode.com/GitHub_Trending/me/metahuman-stream conda create -n livetalking python=3.12 conda activate livetalking pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 --index-url https://download.pytorch.org/whl/cu128 pip install -r requirements.txt

第二步，放模型。wav2lip256.pth拷进models/目录并改名为wav2lip.pth；形象包wav2lip256_avatar1解压到data/avatars/下。第三步，注意端口：服务端要开放 TCP 8010 和 UDP 1–65536，WebRTC 走 UDP 打洞，内网部署忘开 UDP 是连不上的第一嫌疑。最后启动：

python app.py --transport webrtc --model wav2lip --avatar_id wav2lip256_avatar1

浏览器打开http://<serverip>:8010/index.html点"开始连接"，输入文字就能看到数字人开口。

首页就是最完整的联调面板：WebRTC 连接控制、文本驱动（POST /human）、音频驱动（POST /humanaudio）、录制控制（POST /record）都在这一个页面里，右上角还能跳到 Avatar 生成页和管理后台。想走纯 API 对接的话，接口文档在 docs/api.md。

问题四：不用现成形象，怎么换成自己的数字人？

有两条路，都能 5 分钟内走完。

网页路径：访问/avatar.html，上传一段真人视频，后端自动完成人脸检测、特征提取、形象参数生成，产物落到data/avatars/目录，拿到新的 avatar_id 即可用。

API 路径：批量或程序化生成时调 Avatar 生成接口（任务提交、进度查询、任务删除三件套），文档见 docs/avatar_api.md。

生成之后不用改代码——app.py 里global_avatars对已加载形象做全局缓存，请求参数里换个avatar_id就是换个形象，同一进程可以同时服务多个数字人。另外custom_config参数支持动作编排 JSON：不说话的空档播自定义视频，让形象别一直干站着。

问题五：输出到浏览器还是直播间？四种 transport 的区别

--transport参数控制出口，四种模式各有适用面：

• webrtc（默认）：浏览器低延迟直连，适合对话类产品，延迟体验最好。
• rtmp：推流到直播平台的标准协议，适合无人直播挂机。
• rtcpush：服务端主动发起推送，多路并发时按max_session循环分配推流地址，--push_url配目标地址。
• virtualcam：把数字人注册成系统虚拟摄像头，钉钉、腾讯会议、OBS 这类工具直接当真人摄像头用——会议里选到 "OBS Virtual Camera" 就是它在工作。

虚拟摄像头模式和 RTMP 模式有个细节：启动时后台直接拉起渲染线程开始推流，不等客户端连接。这意味着这两类模式下服务一启动就在烧 GPU，空跑时留意功耗。

问题六：并发几路算实时？怎么判断不达标？

先给判定标准：后端日志里有inferfps（GPU 推理帧率）和finalfps（最终推流帧率）两个指标，两者都 ≥ 25 才算真实时——视频按 25fps 生成，低于这个值画面就开始掉帧。

然后是并发瓶颈的分布规律，这点比"支持 N 路并发"的说法更有用：

• 所有人都不说话时，并发上限取决于CPU（每路视频压缩编码耗 CPU）；
• 所有人同时说话时，瓶颈转到GPU（每路口型推理耗显存和算力）。

所以压测要看双场景：静默并发和全量说话并发，取短板。并发上限本身由--max_session控制，config.yaml 默认 5 路；--batch_size（默认 16）是推理批大小，显存富余时可以调大换吞吐。

问题七：想接自己的 TTS 或 LLM，从哪下手改？

扩展入口是 registry.py：TTS、Avatar、Output 三类模块都走同一套去中心化注册机制，新模块写一个文件、打注册标记，不用动主流程。实际要改的位置基本就三处：

• 换 TTS：在 tts/ 里按base_tts.py实现接口，--tts指定插件名；
• 换 LLM：改 llm.py 里的 provider 配置（环境变量名、默认模型），或直接用--llm_provider orcarouter走 OpenAI 兼容网关；
• 全局配置：config.yaml 集中管理模型、音色（REF_FILE/REF_TEXT 支持声音克隆）、端口、并发数，CLI 参数优先级更高，适合临时覆盖。

管理侧还有两个现成页面：/admin.html实时监控会话状态和全局配置，/asr是独立的语音识别测试页，接口见 docs/admin_api.md。

LiveTalking 把实时数字人的完整链路——文本/语音进、口型同步、四路出口——都做成了可插拔模块，选型、部署、换形象、调并发各有明确抓手。下一步：clone 仓库、按问题三下载模型权重，先跑通第一路 WebRTC 会话，再按需加并发。

【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream