前两天在 V2EX 分享过一次 OpenTalking ，当时主要介绍的是实时数字人完整链路：LLM 、STT 、TTS 、数字人视频驱动、WebRTC 播放、字幕同步和用户打断。
这两天我们又继续往前推进了一版，重点不是单独换某个模型，而是把实时数字人里比较影响体验的工程链路再补一补。
项目地址： https://github.com/datascale-ai/opentalking
这次主要做了几件事：
1. Avatar 资产管理和缓存预热
2. 新增了几个内置的 Avartar 资
之前做数字人 demo 的时候，一个比较麻烦的地方是：不同后端对 Avatar 资产的要求不一样。
比如 Wav2Lip 需要预处理帧和嘴型 metadata ，QuickTalk 会有自己的 template 和 face cache ，FlashTalk 又是另外一套实时推理链路。
如果每个模型都各管各的，后面加角色、切模型、做 WebUI 展示都会很乱。
所以这两天主要在整理 Avatar 资产结构，让前端选择一个角色之后，后端能更明确地知道：
这个 Avatar 支持哪些模型；
哪些缓存已经准备好；
哪些需要提前预热；
缺失时应该怎么提示或自动准备。
目标是让用户不是“点一下角色，然后等模型慢慢现算”，而是尽量把可以提前做的事情前置掉。
QuickTalk / Wav2Lip 的链路继续对齐
上次我们已经支持了 wav2lip 、musetalk 、flashtalk 、quicktalk 等几种模式。
这次继续补的是 QuickTalk 和 Wav2Lip 的资产处理一致性，尤其是预览、缓存、模板视频和 runtime 之间的关系。
简单说，就是希望同一个 Avatar 在 WebUI 里看起来是一个角色，而不是用户需要理解背后每个模型各自的目录结构。
对开发者来说，这样后面新增 Avatar 或者新增模型后端也会更清楚一点。
本地 ASR / TTS 方向开始整理
之前为了让大家更容易跑起来，默认链路里很多语音能力会走云 API 。
这两天也开始把本地语音链路补起来，比如本地 SenseVoiceSmall 做 ASR ，本地 CosyVoice 做 TTS ，并且在前端里标注清楚哪些是本地模型，哪些是云端 API 。
这个方向还在继续调，但目标很明确：OpenTalking 不能只做一个云 API 拼起来的 demo ，也要能支持更本地化、更可控的部署方式。
端到端 benchmark 工具
实时数字人最怕只看单点效果。
单独看 TTS 很快，或者单独看 talking head 模型能跑，不代表完整体验就顺。
所以这次也加了端到端 benchmark 的方向，用来更系统地看：
语音输入到识别；
LLM 流式回复；
TTS 首包；
视频首帧；
字幕和播放状态；
打断和下一轮恢复。
后面优化低延迟体验的时候，不能只凭感觉说“快了”，需要有一套能复现的指标。
目前项目还比较早期，但这几天的方向基本是：从“能跑一个 demo”，继续往“更容易部署、更容易加角色、更容易评估体验”走。
后面还会继续做：
更低的首帧延迟；
更清晰的 Avatar 资产库；
更多本地模型组合；
QuickTalk / Wav2Lip / FlashTalk 等后端的体验对齐；
面向电商、主播、客服、培训等场景的案例整理。
欢迎大家继续试用、提 issue 、拍砖。
也想听听大家对实时数字人最在意的是哪块：低延迟、本地部署、口型效果、音色复刻、Avatar 制作，还是完整产品链路？
这两天我们又继续往前推进了一版，重点不是单独换某个模型，而是把实时数字人里比较影响体验的工程链路再补一补。
项目地址： https://github.com/datascale-ai/opentalking
这次主要做了几件事：
1. Avatar 资产管理和缓存预热
2. 新增了几个内置的 Avartar 资
之前做数字人 demo 的时候，一个比较麻烦的地方是：不同后端对 Avatar 资产的要求不一样。
比如 Wav2Lip 需要预处理帧和嘴型 metadata ，QuickTalk 会有自己的 template 和 face cache ，FlashTalk 又是另外一套实时推理链路。
如果每个模型都各管各的，后面加角色、切模型、做 WebUI 展示都会很乱。
所以这两天主要在整理 Avatar 资产结构，让前端选择一个角色之后，后端能更明确地知道：
这个 Avatar 支持哪些模型；
哪些缓存已经准备好；
哪些需要提前预热；
缺失时应该怎么提示或自动准备。
目标是让用户不是“点一下角色，然后等模型慢慢现算”，而是尽量把可以提前做的事情前置掉。
QuickTalk / Wav2Lip 的链路继续对齐
上次我们已经支持了 wav2lip 、musetalk 、flashtalk 、quicktalk 等几种模式。
这次继续补的是 QuickTalk 和 Wav2Lip 的资产处理一致性，尤其是预览、缓存、模板视频和 runtime 之间的关系。
简单说，就是希望同一个 Avatar 在 WebUI 里看起来是一个角色，而不是用户需要理解背后每个模型各自的目录结构。
对开发者来说，这样后面新增 Avatar 或者新增模型后端也会更清楚一点。
本地 ASR / TTS 方向开始整理
之前为了让大家更容易跑起来，默认链路里很多语音能力会走云 API 。
这两天也开始把本地语音链路补起来，比如本地 SenseVoiceSmall 做 ASR ，本地 CosyVoice 做 TTS ，并且在前端里标注清楚哪些是本地模型，哪些是云端 API 。
这个方向还在继续调，但目标很明确：OpenTalking 不能只做一个云 API 拼起来的 demo ，也要能支持更本地化、更可控的部署方式。
端到端 benchmark 工具
实时数字人最怕只看单点效果。
单独看 TTS 很快，或者单独看 talking head 模型能跑，不代表完整体验就顺。
所以这次也加了端到端 benchmark 的方向，用来更系统地看：
语音输入到识别；
LLM 流式回复；
TTS 首包；
视频首帧；
字幕和播放状态；
打断和下一轮恢复。
后面优化低延迟体验的时候，不能只凭感觉说“快了”，需要有一套能复现的指标。
目前项目还比较早期，但这几天的方向基本是：从“能跑一个 demo”，继续往“更容易部署、更容易加角色、更容易评估体验”走。
后面还会继续做：
更低的首帧延迟；
更清晰的 Avatar 资产库；
更多本地模型组合；
QuickTalk / Wav2Lip / FlashTalk 等后端的体验对齐；
面向电商、主播、客服、培训等场景的案例整理。
欢迎大家继续试用、提 issue 、拍砖。
也想听听大家对实时数字人最在意的是哪块：低延迟、本地部署、口型效果、音色复刻、Avatar 制作，还是完整产品链路？
Select Language