Runwayが57B動画拡散モデルを実時間会話向けに提供　4台H100での運用最適化が焦点

編集: グリットアーツ編集部

公開日：2026年11月6日

3行解説

ニュースの概要

Runwayは、2026年11月3日にarXivへ「Runway Characters: Serving a 57B Video Diffusion Transformer for Real-Time Conversation」を投稿した。論文では、会話しながら動画を生成するキャラクター機能の裏側として、約57Bパラメータの自己回帰型動画拡散Transformerを、4台のH100 GPU上で動かす仕組みを説明している。対象は704×1088解像度、24fps、batch size oneの実時間処理で、音声エージェントも同時に動かす構成だ。

何が新しいのか

新しい点は、単に大きなモデルを動かしたことではなく、実時間会話に必要な遅延予算へ落とし込んだことにある。論文では、1チャンクあたり4回のdenoising passを行いながら、240回のattention呼び出しを含む処理を最適化した。特に、KVキャッシュの再計算を減らし、書き込み時に一度だけ処理する方式へ移したことが効いている。最適化前はdiffusion stepが240.9msだったが、最適化後は159.3msまで短縮された。

さらに、tensor-parallelのall-reduceをFP8 GEMMに融合し、デコーダーを別GPUに分けるなど、GPU間通信と役割分担も詰めている。論文では、融合カーネルを使うと147.4msまで到達し、43%のFP8 peakに達したとしている。一方で、このカーネルは一度本番でロールバックされ、その後再有効化されたと明記されており、性能だけでなく運用上の切り戻しも重要だったことが分かる。

グリットアーツ編集部の分析

この論文で実務上の価値が高いのは、57Bモデルを4台のH100で24fps級に載せた点よりも、その過程で「何がボトルネックだったか」を具体的に示していることだ。KVキャッシュの再計算、FP8量子化、通信融合、デコーダー分離という分解は、同種の推論基盤を設計する際のチェックリストになる。平均性能だけでなく、7週間のproductionで99.5%のセッションが23.5fps超を維持した点は、SLA設計の参考になるが、同時にピーク時の劣化や切り戻し手順まで見ないと本番化は難しいと分かる。

日本の現場で考えると

日本でこの種の基盤を使うなら、まずはGPUの調達と電力・冷却の見積もりが前提になる。4台のH100を前提にした構成は、単なるクラウド利用よりも、GPU枠の確保やノード障害時の冗長化をどう組むかが重要だ。制作現場や接客用途では、24fpsを維持できても、音声エージェントとの干渉やネットワーク遅延で体感品質が落ちる可能性があるため、映像単体ではなく会話全体で評価する必要がある。

向いているのは、リアルタイム性が強く求められる対話型の動画生成や、品質を優先して専有GPUを確保できる用途だ。一方で、低コストで広く配る用途や、解像度を大きく落としてもよい用途では、ここまでの最適化は過剰になる可能性がある。既存のオープンソース実装では、同条件でリアルタイムを満たせないか、1秒超の遅延が出たとされており、用途の境界を先に決めることが重要だ。

導入・検討時に確認したいこと

• 必要なGPU枚数と、1セッションあたりのVRAM余裕がどれだけ必要か。
• 音声エージェントを同時に動かしたときの遅延増加と干渉の有無。
• 24fps維持の条件が、解像度やdenoising回数でどこまで変わるか。
• 最適化カーネルを切り戻した場合の性能低下と、再有効化の手順。
• 継続セッションでの維持率をSLAや監視指標にどう反映するか。

現時点で分かっていないこと

論文からは、実運用に必要なGPUコスト、電力消費、保守体制は分からない。また、4台H100以外の構成で同じ性能が出るか、他の解像度や長時間セッションでどこまで安定するかも未確認だ。一般公開向けの提供条件や、どの程度の利用者数までスケールするかも本文では示されていない。

大規模な動画生成やAI推論基盤では、性能だけでなく、GPU構成や切り戻し手順まで含めた設計が重要です。自社のAI基盤や運用要件を整理したい場合は、要件定義の段階から検討材料をそろえておくと判断しやすくなります。

出典: arXiv (cs.DC)