Runway、570億引数のリアルタイム動画モデルを4台のH100で動作可能に

リアルタイムの対話アバターにおいて、わずかコンマ数秒の遅延やフレーム落ちは、人間らしさの錯覚を一瞬で壊してしまいます。

Runwayは対話型アバター機能「Runway Characters」を支える約570億（57B）パラメータの動画拡散モデルについて、推論システムを刷新した研究論文を公開しました。1セッションあたりのハードウェア要件を、従来のH100 8台から4台へと半減させつつ、24fpsのリアルタイム動画生成を維持することに成功しています。

キャッシュ処理を「書き込み時」に集約

通常のAI推論はバッチ処理でGPU効率を高めますが、1対1のビデオ通話ではそれが通用しません。バッチサイズ1の専用ストリームを維持しながら、24fpsを保つには166.7ミリ秒ごとに4フレームを生成し続ける必要があります。

4台のH100構成において、初期のソフトウェアは1拡散ステップに240.9ミリ秒を要し、要求水準を大きくオーバーしていました。

ボトルネックを調査したところ、全GPU時間の29%がキャッシュの再処理に浪費されていました。毎ステップ240回発生するアテンション処理のたびに、RoPEの再適用やFP8への再量子化、ウィンドウのメモリコピーを行っていたためです。

Runwayはキャッシュをリングバッファ構造に改め、RoPE適用とFP8量子化をフレーム書き込み時の1回だけで済ませる設計に変更しました。これにより、キャッシュの維持コストは1ステップあたり69.7ミリ秒から6.2ミリ秒へと激減しました。

通信と計算の融合、そして予期せぬ障害

続いて着手したのが、テンソル並列に伴う全ノード間通信（all-reduce）の削減です。ParallelKittensの技術を拡張し、FP8行列乗算とall-reduceカーネルを一体化させました。

計算結果のタイルが出力された瞬間にNVLinkスイッチ上で順次通信を行うことで、通信オーバーヘッドの54〜68%を計算の裏に隠蔽することに成功。ステップ時間は147.4ミリ秒まで短縮されました。

さらに、1ステップあたり114ミリ秒を要する動画デコーダーを独立したGPUに逃がし、拡散処理とパイプライン並列化させています。

論文では生々しい本番障害も明かされています。FP8のスケール値を監視するために何気なく追加した1行の「.item()」コードがCPUとGPUの同期を強制し、ステップ時間を一気に278ミリ秒まで悪化させていた事例などが克明に記録されています。

なぜ重要か

開発者や事業者にとって、この最適化は高精度なリアルタイムアバターを実用化するための決定的な分岐点となります。57B規模の大規模動画モデルをユーザー1人あたり4台のGPUで常時動かせるようになれば、クラウドの運用コストは単純計算で半額になり、ビジネスとして成立する領域が一気に広がります。

業界全体にとっても、動画生成AIの主戦場が「時間をかけて綺麗な短尺動画を書き出す」フェーズから、「バッチサイズ1で極低遅延に対話する」ストリーミング技術へと移行していることを示しています。

ただし、課題も残されています。Runwayが計測した会話ターンの応答遅延の中央値は2.13秒で、動画パイプラインの処理時間は0.49秒に収まっているものの、手前の音声AIが1.42秒を消費していました。人間の自然な会話の間（ま）はおよそ200ミリ秒とされており、真に自然なリアルタイム対話を実現するには、音声エージェント側の高速化が次の壁になると考えられます。