OpenTalking とは？AI デジタルヒューマン対話を動かすためのオープンソースフレームワーク

OpenTalking は、datascale-ai が公開しているリアルタイムデジタルヒューマン対話のオーケストレーションフレームワークだ。解決しようとしているのは、「1枚の画像に口の動きを付ける」だけの単発問題ではない。デジタルヒューマン対話プロダクトでよく必要になる、フロントエンド操作、セッション状態、LLM 応答、TTS と音色選択、STT、字幕イベント、割り込み制御、WebRTC による音声・映像再生、そしてローカルまたはリモートの合成バックエンドをつなぐことが目的だ。

そのため OpenTalking は、特定のデジタルヒューマンモデルの起動スクリプトとして見るより、デジタルヒューマン制作ラインのためのエンジニアリング骨格として見るほうが近い。モデルは差し替えられる。音声サービスも差し替えられる。推論バックエンドはローカルでもリモートでもよい。フロントエンドは、キャラクター、音色、モデル接続状態、リアルタイム対話体験をひとつにまとめる。

何に向いているか

OpenTalking は主に3種類のニーズに向いている。

1つ目は、デジタルヒューマン対話プロダクトの素早い検証だ。プロジェクトには mock モードがあり、最初からモデル重みをダウンロードしたり、映像推論バックエンドを立てたりする必要がない。それでも API、LLM、TTS、STT、WebRTC、ブラウザ再生の一連の流れを確認できる。画面は静的なモックフレームだが、対話、字幕、ストリーミング TTS、伝送経路は先に検証できる。

2つ目は、コンシューマー向け GPU での単一マシンリアルタイムレンダリングだ。ローカルバックエンド経由で quicktalk、wav2lip、musetalk などのモデルを接続でき、3090 / 4090 クラスのマシンで実映像レンダリング、リップシンク、カスタムアバター検証を行う用途に向いている。

3つ目は、高品質またはプライベートデプロイだ。画質、複数 GPU、リモート 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 モードで全体の流れを通すのがおすすめだ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

デフォルトのフロントエンド URL は次の通り。

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 ルートは次の通り。

1
2
3
4
5
6

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

4つのデプロイルートをどう選ぶか

OpenTalking の README はデプロイルートをかなり明確に分けている。実用上は、まず本物の映像レンダリングが必要かを考え、次に推論を Web サービスと同じマシンに置くかを考えるとよい。

単に全体の流れを検証したいだけなら mock を使う。GPU もモデル重みも不要で、初日にシステムを起動する用途に向いている。

コンシューマー向け GPU があり、単一マシンで本物のデジタルヒューマンのリアルタイムレンダリングをしたいなら、quicktalk から始めるとよい。プロジェクトが示す目安は 3090 / 4090 クラスのマシンで、カスタムアバターとリアルタイム映像効果の検証に向いている。

軽めのリップシンクとカスタムアバター検証だけでよい場合は、wav2lip を見るとよい。デプロイ負荷が比較的低く、軽量ルートとして使いやすい。

完全ローカルのプライベート音声チェーンにしたい場合は、sensevoice、local_cosyvoice、quicktalk を組み合わせ、STT と TTS もローカルモデルに切り替える。このルートは重いが、クラウド音声サービスに依存したくない場面に合う。

高品質映像、複数 GPU、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。VRAM 要求はより高い；
• soulx-flashtalk-14b：portrait + audio。OmniRT 経由で複数 GPU / NPU にデプロイする用途向き；
• soulx-flashhead-1.3b：portrait + audio。同じく高品質リモート推論寄り。

README にはコンシューマー GPU の参考値もある。quicktalk を RTX 3090 で template video + audio 入力として使う場合、出力は 720x900 / 25fps、VRAM 使用量は約 3.8 GiB、生成スループットは約 35 fps とされている。この数値はデプロイ前の大まかな目安になるが、実際の体験は初回フレーム構築、キャッシュ、解像度、音声モデル、マシン環境にも左右される。

設定で注意すること

OpenTalking は設定項目が多い。特に LLM、STT、TTS は単一の fallback key を共有しない。同じ DashScope key を使う場合でも、対応する環境変数へそれぞれ書く必要がある。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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 をローカルで動かしたい；
• プライベートデプロイやリモート複数 GPU 推論が必要で、推論と Web オーケストレーションを分けたい；
• WebUI でデジタル人物、音色、モデル、対話検証を管理したい。

一方、「ワンクリックでデジタルヒューマン動画を生成したい」だけのユーザーにはあまり向かない。OpenTalking はよりエンジニアリングフレームワーク寄りで、うまく使うにはモデル重み、音声サービス、推論バックエンド、ポート、環境変数、ブラウザのリアルタイム伝送を理解する必要がある。

まとめ

OpenTalking の価値は、リアルタイムデジタルヒューマン対話を、段階的に差し替え、段階的にデプロイできるエンジニアリングチェーンへ分解している点にある。mock から始めて API、LLM、TTS、STT、WebRTC だけを検証できる。ローカル quicktalk に切り替えて本物の映像レンダリングもできる。さらに高品質または production 向けには、OmniRT 経由で推論をリモート GPU / NPU に置ける。

デジタルヒューマンアプリ、ライブ配信インタラクション、バーチャルキャスター、コンパニオン製品、企業内プライベート検証に取り組んでいるなら、OpenTalking は調べる価値がある。敷居は低くないが、demo からデプロイ可能なシステムへ進む途中で崩れやすいエンジニアリング層を扱っている。

参考：datascale-ai/opentalking GitHub リポジトリ、OpenTalking ドキュメントサイト