開(kāi)源數(shù)字人實(shí)時(shí)對(duì)話(huà)：形象可自定義，支持語(yǔ)音輸入，對(duì)話(huà)首包延遲可低至3s

西風(fēng) 2024-10-24 14:24:59 來(lái)源：量子位

池?zé)樅悖ǔ鼗?投稿

量子位 | 公眾號(hào) QbitAI

開(kāi)源數(shù)字人實(shí)時(shí)對(duì)話(huà)Demo來(lái)了～

支持語(yǔ)音輸入和實(shí)時(shí)對(duì)話(huà)，數(shù)字人形象可自定義的那種。

生成的數(shù)字人效果belike：

https://toutiao.com/article/7429207653936661044/

目前這個(gè)數(shù)字人實(shí)時(shí)對(duì)話(huà)Demo已在阿里巴巴ModelScope魔搭社區(qū)上線。

無(wú)需預(yù)訓(xùn)練即可使用自定義的數(shù)字人形象進(jìn)行實(shí)時(shí)對(duì)話(huà)，支持選擇不同的數(shù)字人形象和音色，對(duì)話(huà)首包延遲可低至3s。

基于開(kāi)源技術(shù)，該項(xiàng)目采用模塊化系統(tǒng)設(shè)計(jì)，各模塊均可快速更換，開(kāi)發(fā)者可以自由擴(kuò)展和優(yōu)化，適用于多種應(yīng)用場(chǎng)景，包括但不限于直播、新聞播報(bào)和聊天助手等。

此外，該項(xiàng)目基于Gradio 5實(shí)現(xiàn)流式視頻輸出，方便部署和快速構(gòu)建交互式數(shù)字人應(yīng)用。

項(xiàng)目介紹

現(xiàn)有的熱門(mén)開(kāi)源數(shù)字人項(xiàng)目主要有以下幾個(gè)：

Linly Talker，基于Gradio的數(shù)字人對(duì)話(huà)項(xiàng)目，多模型集成，功能豐富，但不支持實(shí)時(shí)對(duì)話(huà)和流式輸出。

LiveTalking，基于流媒體的數(shù)字人生成項(xiàng)目，數(shù)字人響應(yīng)快，但交互界面比較簡(jiǎn)陋，且需要配置服務(wù)器，部署難度較高。

awesome-digital-human-live2d，基于Dify編排的數(shù)字人互動(dòng)項(xiàng)目，輕量化，交互方式豐富，但數(shù)字人形象不夠真實(shí)，且不支持口型同步。

針對(duì)現(xiàn)有開(kāi)源項(xiàng)目存在的問(wèn)題，本項(xiàng)目實(shí)現(xiàn)了一個(gè)基于開(kāi)源的技術(shù)方案、支持語(yǔ)音輸入和實(shí)時(shí)對(duì)話(huà)、數(shù)字人形象真實(shí)且口型同步、可在線試用的開(kāi)源數(shù)字人實(shí)時(shí)對(duì)話(huà)demo。

技術(shù)選型

由于目前缺乏效果較好的開(kāi)源端到端語(yǔ)音/視頻對(duì)話(huà)模型，本項(xiàng)目采用多模塊級(jí)聯(lián)的技術(shù)方案。

首先，使用語(yǔ)音識(shí)別（ASR）模塊將用戶(hù)輸入的語(yǔ)音轉(zhuǎn)為文本，然后將該文本輸入大語(yǔ)言模型（LLM）模塊生成相應(yīng)的文本回復(fù)，文本轉(zhuǎn)語(yǔ)音（TTS）模塊會(huì)根據(jù)這部分文本內(nèi)容進(jìn)行語(yǔ)音合成，最后使用該語(yǔ)音驅(qū)動(dòng)說(shuō)話(huà)人生成（THG）模塊，得到唇形同步的數(shù)字人說(shuō)話(huà)視頻，實(shí)現(xiàn)用戶(hù)語(yǔ)音輸入、數(shù)字人視頻輸出的對(duì)話(huà)效果。

此外，為了方便在線試用和本地快速部署，使用流行的Gradio框架來(lái)構(gòu)建交互式應(yīng)用。

接下來(lái)介紹一下各個(gè)模塊使用的開(kāi)源技術(shù)。

語(yǔ)音識(shí)別（Automatic Speech Recognition，ASR）模塊負(fù)責(zé)將用戶(hù)輸入的語(yǔ)音轉(zhuǎn)化為文本。本項(xiàng)目選用了提供工業(yè)級(jí)語(yǔ)音識(shí)別的工具包FunASR。

與PaddleSpeech、kaldi等同類(lèi)項(xiàng)目相比，F(xiàn)unASR具有更加豐富的功能，包括語(yǔ)音識(shí)別、語(yǔ)音端點(diǎn)檢測(cè)、標(biāo)點(diǎn)恢復(fù)、語(yǔ)言模型、說(shuō)話(huà)人驗(yàn)證、說(shuō)話(huà)人分離和多人對(duì)話(huà)語(yǔ)音識(shí)別等。

不僅方便開(kāi)發(fā)者在現(xiàn)有demo的基礎(chǔ)上進(jìn)行擴(kuò)展，加入更加豐富的語(yǔ)音功能；還便于部署，能夠提供高精度、高效率的語(yǔ)音識(shí)別服務(wù)。

大語(yǔ)言模型（Large Language Model，LLM）模塊負(fù)責(zé)生成回復(fù)內(nèi)容。

本項(xiàng)目選用了目前備受關(guān)注的開(kāi)源LLM——通義千問(wèn)，來(lái)生成對(duì)話(huà)結(jié)果。

為了提高LLM模塊的響應(yīng)速度且不影響對(duì)話(huà)效果，使用了輕量級(jí)模型來(lái)支持日常聊天場(chǎng)景。

如果開(kāi)發(fā)者希望擴(kuò)展到其他應(yīng)用場(chǎng)景，可以選用參數(shù)規(guī)模更大的模型或多模態(tài)LLM如Qwen-VL、Qwen-Audio等，以支持更復(fù)雜的對(duì)話(huà)場(chǎng)景。

本項(xiàng)目提供了單輪對(duì)話(huà)和互動(dòng)對(duì)話(huà)兩種模式，其中互動(dòng)對(duì)話(huà)模式使用OpenAI的meta-prompt生成提示詞，每次只回復(fù)較短的內(nèi)容，從而實(shí)現(xiàn)一問(wèn)一答的互動(dòng)效果。

文本轉(zhuǎn)語(yǔ)音（Text to Speech，TTS）模塊負(fù)責(zé)將生成的回復(fù)內(nèi)容轉(zhuǎn)化為自然的語(yǔ)音。

GPT-SoVITS針對(duì)推理速度進(jìn)行了工程優(yōu)化，支持并行推理，從而提高了TTS的響應(yīng)速度。

相比之下，另一個(gè)熱門(mén)項(xiàng)目ChatTTS雖然提供了更加接近真人的語(yǔ)氣和精細(xì)的韻律特征，但推理速度較慢，且在輸入文本較短時(shí)韻律優(yōu)勢(shì)不明顯。

目前來(lái)看，GPT-SoVITS更加適合實(shí)時(shí)對(duì)話(huà)場(chǎng)景。

此外，機(jī)器性能有限的開(kāi)發(fā)者還可以選擇使用開(kāi)源項(xiàng)目edge-tts來(lái)進(jìn)行語(yǔ)音合成，該項(xiàng)目利用微軟Edge瀏覽器的免費(fèi)在線語(yǔ)音合成服務(wù)，能夠提供比GPT-SoVITS更快的合成速度。

demo還提供了開(kāi)源項(xiàng)目CosyVoice的API調(diào)用，由阿里云大模型服務(wù)平臺(tái)百煉（Model Studio）支持。

說(shuō)話(huà)人生成（Talking Head Generation，THG）模塊根據(jù)輸入的語(yǔ)音生成一段人物說(shuō)話(huà)視頻。

本項(xiàng)目選用了目前實(shí)時(shí)性最好的THG方案MuseTalk。

MuseTalk只對(duì)輸入視頻中人物嘴唇周?chē)膱D像進(jìn)行處理，將輸入的圖片和音頻編碼后使用交叉注意力機(jī)制進(jìn)行融合，然后使用輕量化的Unet完成推理。

在完成預(yù)處理的情況下，MuseTalk在V100上可以達(dá)到30fps以上的處理速度，能夠滿(mǎn)足當(dāng)前場(chǎng)景下數(shù)字人實(shí)時(shí)生成的要求。

與其他開(kāi)源唇形同步方案（Wav2Lip、TalkLip、VideoRetalking等）相比，MuseTalk在提高生成速度和視頻分辨率的同時(shí)，保留了較好的唇形同步效果，并且無(wú)需額外訓(xùn)練即可完成推理。

相比基于擴(kuò)散模型的開(kāi)源方案（EMO、Echomimic、Vasa-1等），雖然唇形同步方案生成的視頻結(jié)果不夠多樣化，但考慮到基于擴(kuò)散模型的方案通常需要數(shù)分鐘的生成時(shí)間以及巨大的訓(xùn)練/推理開(kāi)銷(xiāo)，它們顯然不適合實(shí)時(shí)對(duì)話(huà)場(chǎng)景。

更進(jìn)一步地說(shuō)，由于唇形同步方案是基于給定的人物視頻生成結(jié)果，可以通過(guò)增加輸入人物視頻的動(dòng)作和表情的豐富度來(lái)優(yōu)化整體的觀感。

如果需要根據(jù)輸入的人物圖片生成視頻，可以使用MuseTalk團(tuán)隊(duì)的配套開(kāi)源項(xiàng)目MuseV和MusePose來(lái)生成有表情和動(dòng)作的人物視頻，也可以使用圖生視頻模型來(lái)生成滿(mǎn)足需求的結(jié)果。

如果不受限于特定的人物形象，還可以利用文生視頻模型來(lái)發(fā)揮想象力。

前后端部分選用了適合做在線demo展示和本地快速部署的Gradio，為了實(shí)現(xiàn)視頻的流式傳輸，本項(xiàng)目使用了Gradio 5的Video Streaming功能。

由于Gradio 5剛發(fā)布且改動(dòng)較大，創(chuàng)空間暫時(shí)不支持，因此創(chuàng)空間上的demo使用了支持Video Streaming的gradio 4.40.0測(cè)試版，用戶(hù)在本地部署時(shí)可直接使用最新發(fā)布的Gradio 5。

此外，本項(xiàng)目還使用了ModelScope提供的高階自定義Gradio組件庫(kù)，其中包括升級(jí)版的chatbot組件，支持輸出圖片、視頻等多模態(tài)內(nèi)容。

同時(shí)，Lifecycle組件和Gradio的State組件能夠管理不同用戶(hù)的聊天記錄。利用這些組件，開(kāi)發(fā)者無(wú)需任何前端知識(shí)即可實(shí)現(xiàn)功能豐富的在線交互式應(yīng)用。

系統(tǒng)架構(gòu)

考慮到LLM、TTS和THG這三個(gè)模塊均需要一定的處理時(shí)間，如果等待前一個(gè)模塊完全結(jié)束后再開(kāi)始處理，則無(wú)法達(dá)到實(shí)時(shí)對(duì)話(huà)的要求。為了解決這一問(wèn)題，本項(xiàng)目進(jìn)行以下處理：

• 對(duì)所選開(kāi)源方案的代碼進(jìn)行了重構(gòu)，將模型的初始化與推理過(guò)程分離開(kāi)，并在正式推理前進(jìn)行一次模型熱身，以避免首次推理時(shí)產(chǎn)生額外的初始化開(kāi)銷(xiāo)，提高了模型的推理速度。
• 采用了支持流式輸出的并行流水線，邊推理邊播放，提高了數(shù)字人的響應(yīng)速度。

下面展開(kāi)來(lái)講講這個(gè)流式輸出的并行流水線。

通過(guò)使用LLM的流式輸出模式，系統(tǒng)在收到一定數(shù)量的文本后即可啟動(dòng)后續(xù)處理。基于以下考慮，本項(xiàng)目選擇以句子為單位進(jìn)行處理：

• TTS模塊的GPT-SoVITS需要根據(jù)輸入文本的上下文來(lái)決定語(yǔ)音的語(yǔ)調(diào)、停頓等韻律，為了確保語(yǔ)音的流暢性，需要等待LLM輸出若干完整句子后再進(jìn)行TTS處理。
• THG模塊的MuseTalk需要一定長(zhǎng)度的音頻上下文來(lái)進(jìn)行唇形同步推理。
• Gradio的Video組件只能接收帶音軌的視頻片段而非字節(jié)流，還需要將TTS模塊輸出的音頻和THG模塊輸出的視頻幀使用ffmpeg工具合成ts或mp4格式的視頻。

在此基礎(chǔ)上，本項(xiàng)目維護(hù)多個(gè)隊(duì)列，分別保存LLM生成的句子、TTS生成的音頻和THG生成的視頻幀，并結(jié)合多線程進(jìn)行并行處理。這使得在完成第一個(gè)句子的處理后即可開(kāi)始數(shù)字人的響應(yīng)，邊推理邊播放，極大地降低了用戶(hù)的等待時(shí)間。

上圖中綠色標(biāo)注部分所需的處理時(shí)間即為與數(shù)字人對(duì)話(huà)的首包延遲。

考慮到MuseTalk的推理耗時(shí)與輸入音頻的長(zhǎng)度正相關(guān)，為了確保邊推理邊播放的流暢性，研究人員表示需要盡可能保證每次處理的片段長(zhǎng)度均勻。

鑒于不同句子長(zhǎng)度不一致，本項(xiàng)目設(shè)定了一個(gè)最小長(zhǎng)度，當(dāng)且僅當(dāng)LLM緩沖區(qū)中的句子長(zhǎng)度超過(guò)這個(gè)值時(shí)，將這部分內(nèi)容作為一個(gè)包送入流水線開(kāi)始處理。這個(gè)最小長(zhǎng)度需要根據(jù)GPU性能動(dòng)態(tài)調(diào)整，以平衡首包延遲和整體流暢度。

時(shí)延分析

以語(yǔ)音輸入“今天天氣怎么樣”為例，研究人員在單張A100上測(cè)試了各個(gè)模塊的用時(shí)和播放延遲。

為了確保后續(xù)包的流暢性，最小長(zhǎng)度被設(shè)定為10個(gè)字符，即在LLM生成的句子累計(jì)超過(guò)10個(gè)字符后才開(kāi)始處理。這種設(shè)置確保在流式播放時(shí)，后續(xù)包具有較低的延遲。

對(duì)于首包，用戶(hù)感知的播放延遲是所有模塊耗時(shí)之和。從上圖中可以看出，除了首包之外，后續(xù)包的播放延遲均小于0.5秒。

由于句子之間本身存在停頓，這種延遲對(duì)用戶(hù)體驗(yàn)幾乎沒(méi)有影響。

如果想在本地運(yùn)行本項(xiàng)目，可參考項(xiàng)目的README完成環(huán)境配置，支持更換各個(gè)模塊的技術(shù)選型，支持加入自定義的數(shù)字人音色和形象視頻。

下一步，本項(xiàng)目將會(huì)從以下幾個(gè)方面展開(kāi)優(yōu)化：

• 鏈路優(yōu)化：目前THG模塊需要接受一段完整的音頻作為輸入，包與包之間的延遲會(huì)受音頻長(zhǎng)度的影響。計(jì)劃對(duì)這部分鏈路進(jìn)行優(yōu)化，以提高整體性能。
• 端到端語(yǔ)音聊天：OpenAI在本月初發(fā)布了端到端的實(shí)時(shí)語(yǔ)音聊天API，可以取代現(xiàn)有的級(jí)聯(lián)鏈路，有效縮短數(shù)字人的響應(yīng)時(shí)間。待OpenAI上線正式API或有其他開(kāi)源的端到端方案后，將進(jìn)行更新。
• 流式視頻播放：目前Gradio 5的Video Streaming功能基于HLS協(xié)議實(shí)現(xiàn)。計(jì)劃在后續(xù)版本中采用性能更好的方案，以提升用戶(hù)體驗(yàn)。

對(duì)本項(xiàng)目感興趣的小伙伴可以試用在線demo～

項(xiàng)目鏈接：https://www.modelscope.cn/studios/AI-ModelScope/video_chat
項(xiàng)目README：
https://www.modelscope.cn/studios/AI-ModelScope/video_chat/file/view/master?fileName=README.md&status=1
創(chuàng)空間體驗(yàn)地址：
https://www.modelscope.cn/studios/AI-ModelScope/video_chat
代碼倉(cāng)庫(kù)：https://github.com/Henry-23/VideoChat