OpenTalking 是什麼？一個把 AI 數字人對話跑起來的開源框架

Thu, 11 Jun 2026 08:22:48 +0800

OpenTalking 是 datascale-ai 開源的即時數字人對話編排框架。它要解決的不是「給一張圖配個口型」這麼單點的問題，而是把一個數字人對話產品裡常見的鏈路串起來：前端互動、會話狀態、LLM 回覆、TTS 和音色選擇、STT、字幕事件、打斷控制、WebRTC 音影片播放，以及本地或遠端數字人合成後端。

所以看 OpenTalking 時，最好不要只把它理解成某個數字人模型的啟動腳本。它更像一條數字人產線的工程骨架：模型可以換，語音服務可以換，推理後端可以本地也可以遠端，前端則負責把人物、音色、模型連線狀態和即時對話體驗統一起來。

它適合做什麼

OpenTalking 適合三類需求。

第一類是快速驗證數字人對話產品。專案提供 mock 模式，不需要先下載模型權重，也不需要部署影片推理後端，就能跑通 API、LLM、TTS、STT、WebRTC 和瀏覽器播放鏈路。數字人畫面使用靜態幀佔位，但對話、字幕、串流 TTS 和傳輸鏈路都可以先驗證。

第二類是消費級顯卡上的單機即時渲染。專案支援透過本地後端接入 quicktalk、wav2lip、musetalk 等模型，適合在 3090 / 4090 這類機器上做真實影片渲染、口型同步和自訂形象驗證。

第三類是高品質或私有化部署。對畫質、多卡、遠端 GPU/NPU、 production 隔離有要求時，可以透過 OmniRT 接入 flashtalk、flashhead 等高品質模型，把編排層和推理層拆開部署。

WebUI 的價值

OpenTalking 提供 Web 服務介面，用來管理數字人對話鏈路。你可以在介面裡選擇或新建數字人物，配置音色、LLM、TTS、STT 和數字人驅動模型，查看模型連線狀態，並在同一頁面裡驗證即時對話、字幕和音影片播放。

這件事在工程上很重要。很多數字人 demo 看起來只是「模型能不能跑」，但真正做成產品時，還會遇到這些問題：

人物資產怎麼管理；
音色和 TTS provider 怎麼切換；
LLM、STT、TTS 的 key 和 base URL 怎麼配置；
模型後端是否在線；
首幀延遲、打斷、字幕和音畫同步怎麼觀察；
普通使用者如何在瀏覽器裡完成測試，而不是只讓工程師看日誌。

OpenTalking 的 WebUI 把這些入口放到一起，降低了從模型 demo 走向產品原型的摩擦。

快速開始路線

第一次接觸專案，建議先用 Mock 模式跑通完整鏈路。

export DIGITAL_HUMAN_HOME=/opt/digital_human
mkdir -p "$DIGITAL_HUMAN_HOME"

cd "$DIGITAL_HUMAN_HOME"
git clone https://github.com/datascale-ai/opentalking.git && cd opentalking

export UV_DEFAULT_INDEX=https://pypi.tuna.tsinghua.edu.cn/simple
uv sync --extra dev --python 3.11
source .venv/bin/activate
cp .env.example .env

環境要求包括 Python 3.10+（推薦 3.11）、Node.js 18+ 和 FFmpeg。.env 裡至少要配置 LLM / TTS 相關項；如果使用 edge TTS，則不需要 key。

Mock 模式啟動：

1
2

cd "$DIGITAL_HUMAN_HOME/opentalking"
bash scripts/start_unified.sh --mock

預設前端地址是：

`1`	`http://localhost:5173`

如果要改連接埠，可以指定：

`1`	`bash scripts/start_unified.sh --mock --api-port 8210 --web-port 5280`

這一步的目標不是追求畫面效果，而是確認瀏覽器、API、LLM、TTS、STT、字幕事件和 WebRTC 傳輸都能連起來。鏈路打通後，再決定是否下載模型權重和部署推理後端。

常用啟動參數

專案推薦用 scripts/start_unified.sh 作為統一入口。常用參數可以按用途理解：

--mock：使用內建 Mock，不需要模型權重或影片推理後端；
--backend <mock|local|omnirt|direct_ws>：指定推理後端；
--model <name>：指定模型，例如 quicktalk；
--omnirt <url>：連接 OmniRT 推理服務；
--api-port <port>：指定 OpenTalking 後端連接埠；
--web-port <port>：指定 WebUI 連接埠；
--host <host>：指定 WebUI 監聽地址；
--env <file>：指定 env 檔案位置。

例如，本地 QuickTalk 路線：

`1`	`bash scripts/start_unified.sh --backend local --model quicktalk`

遠端 OmniRT 路線：

bash scripts/start_unified.sh \
  --backend omnirt \
  --model flashtalk \
  --api-port 8210 \
  --web-port 5280 \
  --omnirt http://<gpu-server>:9000

四條部署路線怎麼選

OpenTalking 的 README 把部署路線拆得比較清楚。更實用的理解方式是：先問自己要不要真實影片渲染，再問推理要不要和 Web 服務放在同一台機器上。

如果只是驗證鏈路，用 mock。它不需要 GPU，不需要模型權重，適合第一天把系統跑起來。

如果有消費級顯卡，希望在單機上做真實數字人即時渲染，可以從 quicktalk 開始。專案給出的參考是 3090 / 4090 級別機器，適合驗證自訂形象和即時影片效果。

如果只需要較輕的口型同步和自訂形象驗證，可以看 wav2lip。它的部署壓力低一些，更適合作為輕量路線。

如果要走全本地私有化音訊鏈路，可以組合 sensevoice、local_cosyvoice 和 quicktalk，把 STT 和 TTS 也切到本地模型。這條路線更重，但適合不希望依賴雲端語音服務的場景。

如果追求高品質畫面、多卡或 production 隔離，就把推理層放到遠端，透過 OmniRT 接入 flashtalk 或 flashhead。這時 OpenTalking 更像編排層，負責會話、前端、服務配置和推理 endpoint 呼叫。

模型支援和資源預期

專案目前支援的模型路線大致可以這樣看：

mock：靜態幀佔位，不需要 GPU；
quicktalk：template video + audio，本地 CUDA GPU，推薦 3090 / 4090；
wav2lip：參考圖或 frames + audio，適合 local 或 omnirt；
musetalk：full frames + audio，顯存需求更高；
soulx-flashtalk-14b：portrait + audio，適合透過 OmniRT 部署在多卡 GPU / NPU 上；
soulx-flashhead-1.3b：portrait + audio，同樣更偏高品質遠端推理。

README 裡還給了一個消費級顯卡參考：quicktalk 在 RTX 3090 上使用 template video + audio，輸出 720x900 / 25fps，顯存佔用約 3.8 GiB，生成吞吐約 35 fps。這個資料適合作為部署前的粗略預期，但實際體驗還會受首幀構建、快取、解析度、音訊模型和機器環境影響。

配置上要注意什麼

OpenTalking 的配置項比較多，尤其是 LLM、STT、TTS 不再共用一個 fallback key。即使你用的是同一把 DashScope key，也要分別寫到對應的環境變數裡，例如：

OPENTALKING_LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
OPENTALKING_LLM_API_KEY=sk-your-key
OPENTALKING_LLM_MODEL=qwen-flash

OPENTALKING_STT_DEFAULT_PROVIDER=dashscope
OPENTALKING_STT_DASHSCOPE_MODEL=paraformer-realtime-v2
OPENTALKING_STT_DASHSCOPE_API_KEY=sk-your-key

OPENTALKING_TTS_DASHSCOPE_API_KEY=sk-your-key
OPENTALKING_TTS_DEFAULT_PROVIDER=edge
OPENTALKING_TTS_EDGE_VOICE=zh-CN-XiaoxiaoNeural

這套配置方式看起來繁瑣，但好處是邊界清楚：LLM、語音識別、語音合成和音色復刻可以分別替換 provider，不必把所有能力綁死在一個服務上。

工程結構

OpenTalking 的程式碼結構也體現了它的定位。核心編排層在 opentalking/ 裡，包含協議、provider、模型適配、avatar、voice、media、pipeline 和 runtime；apps/ 裡有 FastAPI 服務、統一啟動模式、React 前端和 CLI；configs/ 放 YAML 配置；docker/ 和 docker-compose.yml 用於容器化部署；scripts/ 提供統一啟動和 quickstart 工具；docs/ 則補充模型、部署和配置說明。

這種結構說明專案不是單模型倉庫，而是在做「數字人產品鏈路」的拆分：前端、後端、模型推理、語音、資產和執行時各有邊界。

適合誰關注

OpenTalking 適合這些人關注：

想做即時數字人對話產品原型；
需要把 LLM、TTS、STT、WebRTC 和數字人模型串成完整鏈路；
想先用 Mock 驗證系統，再逐步替換真實模型；
有消費級 GPU，想本地跑 QuickTalk / Wav2Lip / MuseTalk；
需要私有化或遠端多卡部署，把推理和 Web 編排拆開；
希望用 WebUI 管理數字人物、音色、模型和對話驗證。

它不太適合只想「一鍵生成一段數字人影片」的使用者。OpenTalking 更偏工程框架，真正用好它需要理解模型權重、音訊服務、推理後端、連接埠、環境變數和瀏覽器即時傳輸。

結論

OpenTalking 的價值在於把即時數字人對話拆成一套可以逐步替換、逐步部署的工程鏈路。你可以從 mock 開始，只驗證 API、LLM、TTS、STT 和 WebRTC；也可以換成本地 quicktalk 做真實影片渲染；更高品質或 production 場景下，再透過 OmniRT 把推理放到遠端 GPU / NPU。

如果你正在做數字人應用、直播互動、虛擬主播、陪伴產品或企業內私有化數字人驗證，OpenTalking 值得研究。它的門檻不低，但它處理的是數字人產品從 demo 到可部署系統之間最容易散掉的那一段工程鏈路。

參考來源：datascale-ai/opentalking GitHub 倉庫、OpenTalking 文件站

WebRTC on KnightLi的博客