アバター動画が本当に信頼できるものに感じられるのは、時間が経っても人物の見た目や動きが一貫している場合だけです。顔がずれたり、歯の形が変わったり、リップシンクが外れたり、クリップの切り替えで動きがリセットされたりすると、人はすぐに違和感に気づきます。視聴者は特定の人物が話す様子を、しばしば近い距離から長時間見続けるため、これは多くの他の動画生成タスク以上にアバターにとって重要なポイントです。
現在の動画生成の世界では、再生時間は依然として最も目に見える制約のひとつです。多くのモデルやプロダクトは、生成結果を数秒程度の固定長クリップとして提供しており、数分以上を生成できるシステムはほとんどありません。アバター系プロダクトでは、この制約がそのまま顧客のワークフローに影響します。顧客は、トレーニング動画、セールスデモ、プロダクトのウォークスルー、教育コンテンツ、サポート、そしてタスクが完了するまで話し続けるエージェントのために、より長く一貫したシーン／動画を求めています。同時に、プロンプトやモーション、スクリプトを素早く試行錯誤できる高速なプレビューも望んでいます。
HeyGenでは、それが次の3つの具体的な要件として表れました。
- 長尺シーンでの一貫性。アバターは、短いクリップ1本だけでなく、生成された多数の動画チャンク全体にわたって、人物の特徴、リップシンク、表情、動きの連続性を維持する必要があります。
- 固定された時間制限なし生成は10秒、10分、あるいは時間無制限のリアルタイムセッションになる場合もあります。
- 高速プレビュー、リアルタイムまたはリアルタイムを超える速度での生成。システムはすばやくフレームの生成を開始し、推論処理が進行中であっても、生成されたフレームをストリーミング配信できるようにする必要があります。
この投稿では、これらの要件を満たすために構築した推論フレームワークについて順を追って解説します。
基盤となるモデルアーキテクチャ
このフレームワークは、HeyGen のアバター動画生成モデルである Avatar IV および Avatar V ファミリーを中心に構築されています。大まかに言うと、このモデルは参照用の画像／動画、ドライビングオーディオ、任意のテキストまたはシーン条件を入力として受け取り、そのアバターが正しい人物性、表情、動きで話している動画を生成します。
コアとなる生成モデルは、フローマッチングで学習された Diffusion Transformer（DiT）です。人物を小さなアイデンティティ埋め込みに圧縮するのではなく、豊富な参照トークンを条件として利用することで、アバターにとって重要なディテール――顔の輪郭、歯、肌の質感、口の動き、ジェスチャーのスタイル、話すリズム――を忠実に保つことができます。
本番環境での推論プロセスは、主に3つのステージで構成されています。
- 音声から動画の生成 基本となる DiT が、参照となる人物のアイデンティティ、音声特徴量、および各種コンディショニング信号から、低解像度の動画潜在表現を生成します。このステージでは、動き、リップシンク、時間的な一貫性に重点を置きます。
- アイデンティティ認識型スーパー解像。第2のモデルがこれらの潜在表現を高解像度の出力へと洗練し、とくに顔や口元など、人がアーティファクトに最も敏感な領域に重点を置いて処理します。
- ストリーミング VAE デコードVAE デコーダーが高解像度の潜在表現をチャンクごとに RGB フレームへ変換することで、動画全体が生成される前にフレームを順次出力できます。
長尺の動画を生成するために、このシステムはデータをチャンク（小さなまとまり）ごとに処理します。最初のチャンクは静的なリファレンスのみに依存しますが、以降のチャンクは直前のセグメントから引き継いだ境界データを利用します。これにより、アバターは姿勢やアイデンティティを一からリセットすることなく、自然に話し続けることができます。
ストリーミングフレームワークとパイプラインループ
チャンク単位の実行に対応するため、推論フレームワークはモジュール化された3層アーキテクチャを採用しており、時間的に局所化されたウィンドウ上で動作し、各チャンクの処理が完了するとすぐにリソースを解放します。
- モジュール：特定のモデルとそのチェックポイントをまとめたラッパー（例：A2V DiT、Super-Resolution DiT、VAE コンポーネント、テキスト／オーディオエンコーダーなど）。
- ステージ：1つ以上のモジュール（例：コンテキスト生成、超解像）を連携させる型付き実行ユニットです。
- パイプライン：ステージ同士を接続し、共有状態を管理し、ストリーミングまたはバッチ実行モードを調整する実行グラフ。
初期化フェーズでは、参照となるアイデンティティをリクエストごとに一度だけ潜在表現へエンコードします。その後、パイプラインは入力音声ストリームが尽きるまで、残りのステージを連続ループで実行し続けます。
- コンテキスト生成：入力された音声セグメントを特徴量に変換し、テキストまたはシーン条件と組み合わせて、ターゲットとなるノイズテンソルを生成する準備を行います。
- 音声から動画へ：複数ステップの拡散処理を実行して、低解像度の潜在表現を生成します。この段階では、現在のチャンクを前のチャンクの境界フレームに基づいて条件付けし、動きの連続性を維持します。
- 超解像：モーション潜在表現をワンステップでフル解像度までアップスケールし、顔の空間的なディテールを優先的に強調します。
- VAE デコード＆パブリッシュ：高解像度の潜在表現を RGB フレームにデコードし、出力エンコーダー（H.264 / AAC）に直接書き込むことで、即時保存やライブ再生を可能にします。
境界の連続性とチャンクの一貫性
動画を個別のセグメントとして生成すると、境界部分で不連続性が生じる可能性があります。本フレームワークでは、これを軽減するために、2種類の異なるチャンク分類を用いています。
- N チャンク：アバターのメインタイムラインを生成するセグメントです。
- I チャンク（補間）: 連続する N チャンク間の遷移を滑らかにするために設計されたセグメント。
実行シーケンスは次のように構成されています。
N0 -> N1 -> I0 -> N2 -> I1 -> N3 -> I2 -> ...
Iチャンクは、その前後のNチャンクが完了した後にのみ生成されます。前のNチャンクの最終フレームと、現在のNチャンクの初期フレームをアンカーフレームとして用い、遷移モーションを計算します。生成後は、冗長なアンカーの予測結果を破棄し、滑らかに補間された遷移部分のみを残します。この仕組みにより、必要なコンテキストウィンドウが制限されつつ、時間的一貫性が維持されます。
時間経過に対して一定のメモリ使用量
従来型の動画パイプラインでは、実行中に潜在表現やデコード済みフレーム、アテンションコンテキストが蓄積されていくため、GPUメモリの消費量が動画の長さに比例して増加します。
オープンエンドな生成を可能にするために、このフレームワークは厳密なローリング状態を維持します。システムは、チャンク間の遷移に必要な最小限のアンカーテンソルと静的な参照コンディショニングのみを保持します。オーディオ特徴量、ノイズテンソル、内部アクティベーション、生のRGBフレームを含むすべての中間アセットは、各チャンクのデコードと書き出しが完了した直後にメモリから破棄されます。
その結果、短いクリップを生成する場合でも長いシーケンスを生成する場合でも、GPUメモリ使用量のピークプロファイルは一定に保たれ、セッション全体の長さではなく、定義されたチャンクサイズに応じてリソース使用量がスケールします。
パイプライン内のロード／オフロード段階
各リクエストは 8 GPU ノード全体で実行されます。私たちは FSDP を用いて、大規模モデルのパラメータを GPU 間で分割（シャーディング）しています。各ランクは重みの一部だけを保持し、計算に必要なパラメータをその都度集約してから、再び解放します。これにより、ベース DiT、超解像 DiT、テキストエンコーダー、オーディオエンコーダー、VAE といった複数の大規模モデルを 1 つのノード上に収めることができます。
トレードオフがあります。FSDP では、推論時にパラメータを順伝播のたびに集約する必要があるため、通信のオーバーヘッドが発生します。私たちは、そのオーバーヘッドを隠し、使用していないときには同一ノード上のモデルを GPU から外しておくために、複数の手法を組み合わせて活用しています。
- フォワードプリフェッチ。次のブロックのパラメータに対するAllGatherを事前に実行し、現在のブロックの計算と重ね合わせることで、クリティカルパス上の集約レイテンシを隠します。
- CPU からのブロック単位のレイジー・アンシャーディング。モデルをピン留めされた CPU メモリから復帰させる際、最初に全ての重みをまとめて転送することはしません。各トランスフォーマーブロックは、その順伝播の直前に（ホストからデバイスへのコピー＋AllGather によって）アンシャーディングされるため、ブロック n+1 の H2D 転送はブロック n の計算とオーバーラップします。
- ステージ間でのピン留めCPUオフロード。現在実行されていないモデルのパラメータはピン留めされたCPUメモリ上に保持されるため、同一マシン上の複数モデル（ベースDiT、超解像DiT、テキストエンコーダー、オーディオエンコーダー、VAE）が同時にGPU上に重みを保持しておく必要がありません。ピン留めメモリによって、H2Dコピーを計算とオーバーラップさせるのに十分な速度で実行できるようになります。
- NUMA を考慮したプロセス配置。各プロセスは割り当てられた GPU と同じ NUMA ノードに固定されるため、ソケット間インターコネクトを経由することなく、CPU↔GPU 間の転送を PCIe/NVLink のフル帯域幅で実行できます。
ステージ間で10ms未満のモデル切り替え
上記の手法による実用的なメリットは、GPU をあるステージのモデルから次のステージのモデルへ受け渡す処理が、事実上コストゼロになることです。たとえば A2V DiT → Super-Resolution DiT や、SR DiT → VAE デコーダーといった切り替えがそれにあたります。送信側のモデルは非同期にオフロードされ、受信側モデルの最初のブロックは必要なタイミングでアンシャーディングされるため、H2D コピーと AllGather の両方が、すでに走っている計算の裏側に隠れる形になります。エンドツーエンドで見ると、スイッチ 1 回あたりに観測されるオーバーヘッドは 10ms 未満であり、ターゲットとするフレームレートにおける 1 フレーム分の予算を大きく下回ります。具体的には、これによってストリーミングパイプラインのループ（Context Gen → A2V → SR → VAE Decode-and-Publish）が、チャンクごとに複数の大規模モデルを切り替えながら処理しても、モデルの入れ替え自体がボトルネックにならないようにできています。
リアルタイムストリーミング配信
モデルをリアルタイム配信に十分な速度で動作させるため、多くの推論最適化を行いました。詳しくは、https://www.heygen.com/research/avatar-v-inference をご参照ください。
パイプラインがリアルタイムで動画をチャンクごとに出力するようになると、ストリーミング配信は、別個のポストプロセスではなく、推論処理の自然な延長となります。
ブロードキャスト型のリアルタイム経路では、生成されたフレームを Amazon Kinesis Video Streams（KVS）に配信します。KVS は通常、カメラや IoT デバイス、アップロードされたメディアといった文脈で語られますが、私たちの場合の「カメラ」は推論パイプラインそのものです。フレームはモデルによって生成されるとすぐにエンコードされ、ライブストリームとして KVS に送信されます。
出力ライターは、ストリーミング VAE からデコード済みの RGB フレームを受け取り、それらを GStreamer パイプラインに送ります。動画は H.264、音声は AAC でエンコードされ、その後どちらのトラックも KVS のプロデューサーシンクである kvssink に送られます。そこから、視聴者は生成処理が進行中のまま、そのセッションをライブストリームとして再生できます。
結果と学び
このフレームワークにより、Avatar IV と Avatar V の生成は、固定シーンのレンダリングから、オープンエンドなストリーミング生成へと変わりました。最も重要な成果はシンプルで、Avatar IV と Avatar V におけるシーンの長さの制限を取り除いたことです。リアルタイムの Avatar IV 生成では、最初のフレームまでの時間を 5 秒未満に抑え、720p の Avatar IV 動画で 1 秒あたり 27 フレーム以上の生成を実現しており、実際の再生速度よりも高速に動作しています。