軽量なオープンソースのリアルタイムAIアバターをセルフホストで試してみた

こんにちは、グループ研究開発本部・AI研究開発室のA.Zです。

今回は、テキストを入力すると話しているアバターの映像がリアルタイムで返ってくる、いわゆる「リアルタイムAIアバター」技術について調査・検証した内容を紹介します。特に、オープンソースで自前デプロイ（セルフホスト）できること、そしてGPUなし・CPUのみで動かせることを条件に据えて技術選定を進めた結果、LiteAvatar というモデルにたどり着きました。本記事では、その選定理由と、実際に組み上げた検証環境のアーキテクチャを詳しく解説します。なお、今回はあくまでPoC（概念実証）レベルの検証であり、プロダクションのアプリケーションではない点はご了承ください。

なぜ「セルフホスト」なのか

AIアバターを実現するだけであれば、商用のクラウドAPI（HeyGen、D-ID、Synthesiaなど）を使うのが手っ取り早い選択肢です。しかし今回はあえてオープンソースモデルの自前デプロイにこだわりました。理由は主に2つです。

1. データプライバシー アバターに喋らせるテキストや音声には、業務上の機密情報や個人情報が含まれるケースがあります。外部APIに送信すると、通信・ログ・キャッシュのどこかにデータが残る可能性があり、コンプライアンス上の懸念が残ります。モデルを自社環境の中で完結させれば、データが外部に出ることはありません。
2. カスタマイズ性 商用APIはアバターの見た目・声・振る舞いが提供側の仕様に縛られます。オープンソースであれば、アバターの素材差し替え、TTS（音声合成）バックエンドの入れ替え、レイテンシのチューニングなど、要件に合わせて自由に手を入れられます。

 

技術要件：GPUなしで動くこと

AIアバターのオープンソースモデルは数多く存在しますが、今回は次の要件を最も重視しました。

GPUなし（CPUのみ）で推論が動くこと。

理由はシンプルで、コストと可用性です。

観点	GPU必須の場合	CPUのみで動く場合
インフラコスト	高価格GPUインスタンス	汎用CPUインスタンス
調達性	高性能GPUは品薄で、確保できないことがある	CPUはいつでも確保できる
サーバーレス適性	GPU予約に失敗するとサービスが起動できない	予約失敗のリスクがない
スケール	GPU台数に上限が縛られる	水平スケールしやすい

 

特に、サーバーレス構成（オンデマンドでコンテナを起動する構成）を検討したとき、GPUの予約に失敗するとそもそもリクエストを処理できないという運用リスクが無視できません。GPU価格の高騰と品薄が続く昨今、「CPUのみで動く」ことは単なる贅沢な制約ではなく、現実的な運用要件でした。

GPUモデルは実際に「重い」

参考までに、当初は高品質なフル生成型アバターである LongCat-Video-Avatar 1.5 も検証しました。しかし、RTX 4090（VRAM 24GB）というコンシューマ最上位クラスのGPUを使っても、実用的な既定バックエンドにはできないという結論でした。

解像度を 360p まで落とし、INT8量子化・蒸留・推論ステップ削減（8ステップ）などあらゆる省メモリ設定を試したところうまくいかなかった。拡散モデル（Diffusion）で毎フレームをフル生成する方式は、品質は高いものの計算コストが重く、今回の要件とは相性が合いにくいという印象です。

LiteAvatarについて

そこで採用したのが、アリババの HumanAIGC チームが公開している HumanAIGC/lite-avatar です。LiteAvatarは今回の要件に対して有望でした。具体的な理由は以下です。

1. アーキテクチャそのものが軽量

LiteAvatarはフル生成型の拡散モデルではなく、2Dパラメトリックな「トーキングヘッド（talking head）」です。処理の流れは大きく3段階です。

1. audio2param：音声波形から口の形状パラメータを推定する（ONNXモデル）。
2. param2img：パラメータから口元の画像を生成する。
3. merge_mouth_to_bg：生成した口元を、あらかじめ用意した背景動画（bg_video.mp4）の該当フレームに合成する。

つまり、毎フレームを一から生成するのではなく、「口元だけ」を差し替える方式です。顔や背景は事前収録済みの映像を使い回すため、拡散モデルのような重い計算が不要になります。この設計が、CPUのみでの動作を可能にしています。

2. CPU実行が公式に想定されている

リポジトリ上でも、GPU利用は明示的にオフにできます。本検証では既定で use_gpu=false としています。また、CPUのみでも十分な性能が出ています。

3. リアルタイム化しやすい粒度

LiteAvatarはフレーム単位で逐次生成できるため、生成したフレームを順次ブラウザへ流す「ストリーミング」に向いています。フル生成型のように「1本の動画が完成するまで待つ」必要が薄いのです。

まとめると、LiteAvatarは次の表のようにこの要件によく一致します。

要件	LongCat（拡散）	LiteAvatar（2Dパラメトリック）
GPUなしで動く	❌ 24GB GPUでも不安定	✅ CPUのみで動作
セルフホスト	✅	✅
リアルタイムストリーミング	苦手（1本生成型）	✅ フレーム逐次生成
出力品質	高い（フル生成）	十分（口元合成）
調達・コスト	GPU依存で高コスト	汎用CPUで低コスト

 

検証環境全体のアーキテクチャ

ここからは、実際に組んだ検証環境の構成を解説します。検証環境はPythonのみ（FastAPI）で構成され、ブラウザUIもPythonがサーバーサイドで生成するHTML/JSで完結しています。

主要コンポーネント

検証環境は、責務ごとに次のコンポーネントに分かれています。

コンポーネント	役割
ブラウザUI	サーバー生成のHTML/JSで、テキスト入力と映像プレビューを提供
サーバー（FastAPI）	リアルタイムAPIの受け口。セッション管理・テキストキュー・配信を担当
永続LiteAvatarワーカー	モデルをロード済みで常駐し、音声→アバター映像の生成を行う別プロセス
WebRTCブリッジ	TTS・アバター生成・トラック配信をつなぐ橋渡し役
TTS抽象レイヤ	音声合成バックエンド（gTTS / Supertonic）を差し替え可能にする抽象

アーキテクチャ図

全体のデータフローは以下の通りです。

 

各コンポーネントの詳細

① ブラウザUIとテキストストリーミング

UIは左側にテキストエリア、右側にプレビュー（<video>）を配置したシンプルな2カラム構成です。ポイントは、テキストエリアへの入力をそのまま全文再送しないことです。ユーザーがタイプするたびに、

• 220msのデバウンス
• .・!・?・改行での文境界、空白での単語境界での chunk 送出
• 850msの停止で未確定テキストをフラッシュ

というルールで「喋らせるべき単位（speakable chunk）」を切り出し、input_mode: "append" で追記分だけを送ります。これにより、すでに喋った内容の再生成を防ぎます。

② 永続ワーカー（Warm Worker）＝レイテンシ削減

リアルタイム性を確保するうえで重要なのがこの設計です。LiteAvatarのモデルロードは重いため、リクエストごとにロードするのはUXが悪く、要件も満たせません。

そこで、モデルをロード済みの常駐プロセスを用意しています。処理のタイミングは次の通りです。

• セッション開始時：まだテキストが来ていない段階でワーカーを起動し、モデルとアバター素材を一度だけロードして「準備完了」状態にする（この間、ブラウザのテキスト欄は無効化しておく）。
• テキスト到着時以降：モデルはすでにメモリ上にあるので、ロードコストを一切払わずに生成へ入れる。

つまり「最初のテキストが来てから起動する」のではなく、「テキストが来る前にウォームアップを済ませておく」ことが肝心です。

サーバー本体とワーカーは、標準入出力を通じた1行1メッセージのJSONプロトコルで通信します。サーバーが「この音声からアバターを生成して」という依頼を1行のJSONで送り、ワーカーが生成フレームや完了通知を1行のJSONで返す、という素朴で堅牢な仕組みです。

ワーカーをあえて独立したプロセス・独立した実行環境に分離しているのには理由があります。LiteAvatarは独自の依存関係（PyTorch、ONNX Runtime、OpenCVなど）を持っており、サーバー本体の環境と混ぜたくないためです。この「アダプタパターン（別プロセス＋専用実行環境＋JSON通信）」は、将来別のアバターバックエンド（EchoMimicなど）に差し替える際にも同じ形で使えます。

③ TTS抽象：日本語はSupertonic

音声合成は共通のインターフェースで抽象化しており、実装を差し替えられます。

• gTTS：既定。Google TTSを使うため手軽（ただしネットワーク依存）。
• Supertonic：ローカルで動く軽量TTS。日本語（ja）を既定言語とし、LiteAvatarのサンプルアバター（女性）に合わせて F1 ボイススタイルを既定にしています。

④ 音声の前処理：ONNXの入力窓に合わせる

LiteAvatarに音声を渡す前に、ffmpegで16kHzモノラルWAVへ変換します。ここに一つ実運用上のハマりどころがありました。最低1秒まで無音パディングしているのがポイントです。リアルタイム入力では「単語1つ」のような極端に短い音声が来ることがあり、そのまま渡すと上流のONNXモデルが期待する30フレームの入力窓を満たせず、エラーで落ちます。短い音声をパディングすることで、この形状エラーを回避しています。

⑤ WebRTCブリッジ：MP4を「同期の真実源」にする

音声と映像がズレる（リップシンクが崩れる）のは、アバター体験を最も損なう問題です。素朴に「TTS音声」と「アバター映像」を別々にブラウザへ送ると、両者の再生タイミングがずれてしまいます。

本検証のWebRTC実装では、この問題を次のように解いています。

1. TTSで合成した音声は、あくまでLiteAvatarへの入力として使う。
2. LiteAvatarが、その chunk に対応するアバター映像のMP4セグメントを生成する。
3. 映像トラックも音声トラックも、この同一MP4から復号する。

つまり、バックエンドがレンダリングしたMP4を「同期の真実源（source of truth）」とすることで、ブラウザに届く音声と映像は常に同一ソース由来となり、ズレません。ブラウザはWebRTCの単一の映像要素（<video autoplay playsinline>）で、同期済みの音声・映像を受け取ります。

さらに再生開始のタイミングにも工夫があります。映像トラック側は、そのセグメントの最初の映像フレームが実際に表示されたタイミングで初めて、対応する音声を再生キューに積むようにしています。これにより「映像より先に音声だけが鳴り出す」という不自然さを防いでいます。音声が来るまでは無音フレームを流し、映像の頭出しと音声の鳴り始めを揃える、というのがポイントです。

⑥ フォールバック：MJPEG + SSE

WebRTC（aiortc）が使えない環境向けに、フォールバック経路も用意しています。

• 映像：multipart/x-mixed-replace によるMJPEGストリーム（<img> 要素）。
• 音声：Server-Sent Events（SSE）で音声URLを別配信し、<audio> 要素で再生。

この経路は映像と音声が別要素になるため、同期はベストエフォートです。音声・映像の同期が重要ならWebRTCを使う、というのが基本方針です。

リクエストの流れ（WebRTCモード）

セッション開始からアバターが喋るまでの一連の流れをまとめます。

[1] セッション開始
      → セッション作成 + ワーカーをウォームアップ（この間テキスト欄は無効化）
[2] ブラウザがWebRTC接続を確立（SDP交換）
      → サーバーがブリッジを起動
[3] テキスト欄が有効化。ユーザーがタイプ
      → 追記分の chunk をサーバーに送信（キューに積むだけ）
[4] ブリッジのレンダリングループ:
      TTS合成 → 16kHz WAV変換 → LiteAvatarでMP4生成 → MP4から映像/音声を復号
[5] ブラウザの映像要素に同期済みの音声・映像が届く

このフローには「テキスト送信時にはTTSを走らせず即座に返す」「ワーカーは最初のテキストではなくセッション開始時に起動する」といった工夫が入っており、サーバー側で避けられる遅延をできるだけ削るようにしています。

デモ

実際にブラウザから動かした様子です。テキストを打ち込むと、アバターがそれに合わせて反応します。まだタイムラグがありますが、これからはより最適化処理を行います。

 

いくつかの定量的な計測値や環境情報は以下のとおりです。

項目	値
実行環境	Macbook Pro M2
TTSバックエンド	Supertonic（日本語 ja / F1）
セッション開始〜ワーカー ready	約 20 秒
テキスト送信〜初回フレーム表示（first-frame lag）	約 7~10 秒

 

検証結果と所感

現時点での検証を通じて得られた知見をまとめます。

うまくいった点

• CPUのみで、リアルタイムに近い動作を実現できた。GPUを必要としないため、コスト・調達性・サーバーレス適性の面で運用しやすい。
• 永続ワーカーとWebRTCを組み合わせた構成により、テキスト入力に対してアバターが逐次応答するインタラクティブな体験を実現できた。
• レンダリング済みのMP4を同期の真実源（source of truth）とする設計により、音声と映像のズレを抑えられた。

改善必要な点

• 音声とアバターの口の動きの同期がまだ完全ではなく、リップシンクの精度をさらに高める必要がある。
• 応答までの遅延がまだ大きく、よりスムーズに返せるようレイテンシを改善する必要がある。

まとめ

本記事では、「オープンソースでセルフホストできる」「GPUなし・CPUのみで動く」という要件からリアルタイムAIアバター技術を調査し、LiteAvatar を採用してWebアプリケーションベースの検証環境に組み込んだ過程を紹介しました。

拡散モデルによるフル生成型アバターは、品質こそ高いものの、GPUメモリの制約が厳しく、低コストでの安定運用は難しいという印象でした。一方、口元だけを合成する2DパラメトリックなLiteAvatarは、CPUのみで動作し、フレームの逐次生成にも向いており、今回の要件によく合っていました。

とはいえ、課題や改善すべき点はまだ多く残っています。システムのさらなる最適化に加え、別モデルの検証も引き続き必要だと考えています。

最後に

AI研究開発室では、データサイエンティスト/AIエンジニアを募集しています。AI/LLMを活用したシステム開発、AI×ロボットなどにご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。皆さんのご応募をお待ちしています。

 

参考資料

• LiteAvatar (HumanAIGC): https://github.com/HumanAIGC/lite-avatar
• LongCat-Video-Avatar: https://github.com/meituan-longcat