WebRTC

如果你正在评估“AI 数字人”项目，我建议先别急着问哪个 talking-head 模型最逼真。 更该问的是：这套东西能不能被放进一个真实产品里？能不能接企业自己的 LLM、知识库、TTS、语音识别、权限系统和 GPU 推理服务？用户打断说话时，前端、音频、字幕和视频流会不会一起乱掉？ 这也是我这次关注 OpenTalking 的原因。它不是单个唇形同步模型，而是一个试图把 LLM 回复、STT、TTS、WebRTC 播放、角色资产、会话状态和数字人渲染后端串起来的开源编排框架。项目在 Hacker News 新帖里出现时分数不高，但仓库本身已经有 2600+ stars、最近仍在更新，并且 README 和文档都把“私有部署”和“可替换模型后端”放在很靠前的位置。 坦白说，这比“又一个更像真人的演示视频”更值得写。 因为数字人真正难的地方，不是让一段 demo 看起来惊艳，而是让一条长链路稳定工作。 OpenTalking 的定位很清楚：它把数字人产品拆成几个相对独立但必须协同的层。前端负责 WebUI 和播放，后端 API/Worker 负责会话与任务编排，Redis 负责状态，模型侧可以从 Mock 模式起步，再接 QuickTalk、Wav2Lip、MuseTalk、FasterLivePortrait、FlashTalk 等后端，音频侧则可以接 SenseVoice、CosyVoice、IndexTTS、F5-TTS、Qwen3-TTS 等组件。官方文档也明确说，它连接的是 frontend interaction、session state、LLM responses、TTS、subtitle events、WebRTC playback 和本地或远程的 synthesis backends，而不是只提供一个 talking-head 模型。 用人话说：OpenTalking 想做的是“数字人的胶水层”。模型负责生成，OpenTalking 负责把生成能力变成一个可操作的产品流水线。 这点很关键。很多企业做数字人 PoC 时会踩一个坑：拿到一个效果不错的视频生成模型，以为剩下只是接 API。结果真正上线时才发现，用户语音识别有延迟，LLM 回复长度不可控，TTS 输出和口型驱动节奏不一致，WebRTC 推流卡顿，角色资产版本混乱，后台任务失败后前端没有状态回滚。单个模型论文不管这些，但产品必须管。 OpenTalking 的工程价值就在这里。它的 README 给了一个比较现实的部署路径：先用 mock / driverless mode 在 CPU 或无 GPU 环境里验证 API、TTS、WebRTC 和浏览器播放链路；再切到 QuickTalk / Wav2Lip 这类入门后端，在 RTX 3050 Laptop、RTX 3060、RTX 4060 等设备上做真实渲染验证；如果要更接近实时的本地 demo 或轻量预生产，再考虑 RTX 3090 / 4090 级别的单机 GPU；更复杂的方案则通过 OmniRT 这类远程推理后端承载。 ...