Runway Characters：リアルタイム動画アバターの稼働環境が8基から4基のH100 GPUへ半減

リアルタイムで動画応答するアバターは、一瞬の遅延も許されない。Runwayは11月5日に公開したリサーチブログおよび技術論文において、単一の画像から生成される対話型キャラクター「Characters」を、約570億パラメータの動画モデルでいかに配信しているかという課題を解説した。

停止が許されないクロック

従来の動画生成はモデル自身のペースで処理される。プロンプトを入力し、生成を待ち、完成した動画を受け取るという流れだ。これに対し、対話するキャラクターは相手のテンポに追従しなければならない。毎秒24フレームを維持するためには、対話が続く限り、704×1088解像度の4フレームブロックを166.7ミリ秒ごとに生成し続ける必要がある。各フレームには対応する音声が含まれており、ブロックの生成が遅れると顔の描画が止まるだけでなく音声も同時に途切れてしまう。

さらに、多くのAIサービスのように複数ユーザー間で計算リソースを集約・共有することはできない。各セッションは一対一のプライベートなストリームだからだ。したがって、すべての効率化は単一ステップ内の計算処理そのものから生み出す必要があった。

セッションあたりのGPU数を半減

初期リリース時、Charactersは1セッションにつき8基のH100を消費していた。4基の環境では初期ソフトウェアで1ステップあたり240.9ミリ秒を要し、実用には到底及ばなかった。Runwayの分析によると、GPU時間の29%がほぼ変更のないキャッシュの再処理に費やされていた。各フレームの書き込み時にこの処理を1度だけ行うよう変更したことで、キャッシュ管理時間は1ステップあたり69.7ミリ秒から6.2ミリ秒へと劇的に短縮された。さらに、計算とGPU間通信を統合するカーネルの導入と、画像デコード専用のGPUを割り当てる設計を組み合わせた。その結果、4基のH100環境で1ステップあたり159.3ミリ秒（毎秒24.5フレーム）を達成し、統合カーネル適用時には147.4ミリ秒まで短縮された。このシステムは3基のB200環境でも動作する。

品質低下を防ぐ検証として、Runwayは51本のクリップでリップシンク精度を比較した。結果としての差異は、同一設定で再実行した際のブレ幅と同水準にとどまった。ブログ記事ではトラブル事例も明かされている。ソフトウェア更新後のメモリリークや、単純な監視用呼び出しが原因で1ステップの所要時間が168.5ミリ秒から278ミリ秒に跳ね上がったケースなどが報告されている。

真のボトルネックは音声

51回の発話交代で測定した結果、ユーザーの文末からキャラクターの音声応答までの遅延の中央値は2.13秒であった。このうちRunwayの動画パイプラインが要したのは0.49秒にすぎず、音声エージェント側の処理が1.42秒を占めていた。Runwayの指摘によると、人間同士の会話における沈黙の時間は平均約208ミリ秒である。