Helios：あらゆるショートカットを排除したリアルタイム長尺動画生成モデル

私がビデオ生成モデルに必要だと思っているものがある：高速化のためのKVキャッシュ、メモリのためのスパースアテンション、ドリフト防止のためのキーフレームサンプリング。PKU-YuanGroupのHeliosはそのすべてを捨て去り、それでもシングルH100で19.5 FPSを達成している。この矛盾こそが、私のスクロールを止めた理由だ。

私はDoraです。ここ数日、Heliosの論文とリポジトリを読み込み、できる範囲でローカル実行を試し、「革命的」な主張で何度も裏切られてきた人間として、なぜこのアプローチが従来の常識に反して機能するのかを理解しようとしてきた。これはベンチマークレビューではない。どちらかといえば、証拠を求める人間のノートのようなものだ。

Heliosとは何か

Heliosは自己回帰型ビデオ生成モデルで、チャンクあたり33フレームを生成し、それをつなぎ合わせてミニッツスケールの動画を作成する。24 FPSで最大1,452フレーム、つまり約60秒の連続映像だ。

それ自体は驚くべきことではない。異例なのは、使っていないものの一覧だ：

• KVキャッシュなし
• Causalマスキングなし
• スパースまたは線形アテンションなし
• TinyVAEなし
• プログレッシブノイズスケジュールなし
• 量子化なし
• セルフフォーシング、エラーバンク、キーフレームサンプリング（標準的なアンチドリフトツールキット）なし

このリストを読んだとき、エンジンなしで走る車を説明されているような感覚だった。これらのテクニックはすべて、ビデオ生成がコスト高で、メモリを大量に消費し、長いシーケンスで品質が劣化しやすいという理由で存在している。Heliosはそのすべてを回避しながら、リアルタイム推論を実現する。機能するかどうかではなく——デモは公開されている——どうやって機能するのかが問題だ。

3段階の学習パイプライン

Heliosは3つのモデルバリアントを提供しており、それぞれが学習ステージに対応している。各ステージを理解することで、設計の論理が見えてくる。

Stage 1: Helios-Base

基盤となるモデル。コアとなるアーキテクチャの革新はここに集約されている：

• Unified History Injection — 通常のエラー蓄積ペナルティなしに、モデルが前のチャンクを条件として取り込む
• Easy Anti-Drifting — ほとんどの自己回帰型ビデオモデルが依存する推論時のハック（セルフフォーシング、エラーバンク）を置き換える学習時戦略
• Multi-Term Memory Patchification — 長い時間的コンテキストを扱うためのメモリ効率の高いアプローチ

Helios-BaseはV予測と標準的なclassifier-free guidanceを使用する。3つのバリアントの中で最も高い生の品質を生み出すが、推論時のコストも最大で、チャンクあたり50拡散ステップが必要だ。

Stage 2: Helios-Mid

トークン圧縮のためのPyramid Unified Predictor Correctorを導入した中間チェックポイント。モデルが限界的な品質を犠牲にして意味のある速度向上を追求し始める段階だ。CFG-Zero*を使用することで、推論中の無条件モデル評価が不要になる。

拡散モデルを扱ったことがあれば、CFGが通常2倍の計算を要する理由がわかるだろう——プロンプトありとなしで、ステップごとにモデルを2回実行するからだ。その要件をなくすことは、大幅な効率向上を意味する。

Stage 3: Helios-Distilled

最終バリアントはAdversarial Hierarchical Distillationを使用して、50拡散ステップをわずか3ステップに圧縮する。V予測からx0予測に切り替え、カスタムスケジューラ（HeliosDMDScheduler）を採用し、CFGの要件を完全に排除する。

これが19.5 FPSを達成するバリアントだ。3ステップ、CFGなし、加速トリックなし——ただ、最初から正確に生成するよう学習されたモデルだ。

「ショートカットなし」アプローチが重要な理由

ビデオ生成における加速化の取り組みの多くは加算的だ。モデルを作る、遅すぎる、だからKVキャッシュを追加する。まだメモリが足りない、だからスパースアテンションを追加する。長いシーケンスで品質がドリフトする、だからキーフレームサンプリングを追加する。各修正は独自の障害モードと複雑さをもたらす。

Heliosは逆の道を歩む：ボルトオンが不要なほど効率的な基盤モデルを作ることだ。学習パイプラインが、推論時のトリックが通常担う重い仕事をこなす。

ここに見落とされがちな実用的な帰結がある。可動部品が少ないほど、壊れるものが少ない。 KVキャッシュの破損問題をデバッグしたり、スパースアテンションが特定のフレーム境界でアーティファクトを生み出すのを見たりしたことがあれば、それらのシステムが課す代償を知っているはずだ。Heliosはその代償を払わない。

メモリの話も同様に印象的だ。論文によれば、画像拡散スケールのバッチサイズを使用して、学習中に80 GBのGPUメモリ内に14Bパラメータモデルを4つ収めることができるという。これは通常、膨大なリソースフットプリントを持つモデルの積極的な圧縮だ。

できること

Heliosは3つのバリアントすべてで4つの生成モードをサポートしている：

• テキストtoビデオ — プロンプト入力、ビデオ出力
• 画像toビデオ — 最初のフレームとプロンプト
• ビデオtoビデオ — スタイル転送、リタイミング、修正
• インタラクティブモード — 反復的な精緻化

フレームの計算は具体的で、チャンクあたり33フレームの倍数で作業する。約30秒が欲しい？それは22チャンク＝726フレーム。1分間？44チャンク＝1,452フレーム。チャンク境界が自己回帰的なハンドオフが起きる場所で、私が見たデモでは、その継ぎ目が驚くほど自然だ。

最後の点は強調に値する。自己回帰型ビデオモデルは通常、チャンク境界で最悪の振る舞いを見せる——モーションのスタッター、色のずれ、オブジェクトのドリフト。「Easy Anti-Drifting」学習戦略はこれを本当に解決しているようだが、問題が解決されたと宣言する前に、より多様なテストケースを見たい。

統合とエコシステム

Heliosはすでに複数の推論バックエンドをサポートしている：

• Hugging Face Diffusers — ModularPipelineインテグレーション
• vLLM-Omni — ステージベースのグラフアーキテクチャによる分解型サービング
• SGLang-Diffusion — 最適化されたカーネルを持つ統合パイプライン
• Ascend NPU — Day-0ハードウェアサポート（Ascendで約10 FPS）

Diffusersインテグレーションが最もアクセスしやすい。vLLM-Omniのパスは、異なるハードウェアにわたってプリフィルとデコードのステージを分離したい本番環境デプロイに興味深い。SGLang-Diffusionは将来を見据えたオプションで、リアルタイムアプリケーションを実現するバッチ処理、パイプライン化されたサービングのために設計されている。

Ascend NPUのサポートは戦略的なシグナルだ。非NVIDIAハードウェアへのDay-0サポートは、後付けではなかったことを示唆している。Ascendでの約10 FPSはH100より遅いが、多くのアプリケーションで十分に使用可能だ。

HeliosBench

チームは独自のベンチマーク——HeliosBench——を構築した。これはリアルタイムの長尺ビデオ生成の評価に特化して設計されている。既存のビデオベンチマークの多くが短いクリップ（4〜16秒）に焦点を当て、ミニッツスケールの長さで現れる障害モード——時間的ドリフト、モーションの劣化、オブジェクトの持続性の失敗——を捉えられていないため、これは注目に値する。

目的に特化したベンチマークが客観性を保証するわけではないが、少なくとも正しいものを測定しようとしていることを意味する。HeliosBenchを使用した独立した評価で方法論を検証してほしい。

まだ考えていること

極端な状況での品質。 33フレームのチャンク設計はエレガントだが、44回の連続した自己回帰ステップは蓄積エラーの機会が多い。デモは綺麗に見えるが、デモは常に綺麗に見える。複雑なカメラモーション、多くの相互作用するオブジェクト、1分間を通じた劇的な照明変化など、敵対的なプロンプトを見たい。

蒸留のトレードオフ。 50ステップから3ステップへの削減は積極的だ。蒸留されたモデルは一般に、速度のために多様性と細部の精細さを犠牲にする。Helios-Baseバリアントが存在する理由がある——品質が速度より重要な場合、17倍の計算コストを払う。これは2つの動作点の間の大きなギャップだ。

エコシステムの成熟度。 モデルはオープンソース（Apache 2.0）で、それは素晴らしい。しかしオープンソースのビデオモデルが実用的になるには、コミュニティのツール——ComfyUIノード、ファインチューニング用の学習スクリプト、LoRAサポート——が必要だ。そのエコシステムの発展には時間がかかり、今のHeliosは生まれたばかりだ。

ハードウェア要件。 H100でのリアルタイムは印象的だ。しかしH100は多くの人のデスクに遊んでいるわけではない。多くのユーザーにとってより関連性の高い問いは：4090ではどうか？A100では？論文はH100とAscendのパフォーマンスについては明確だが、ハードウェアの長い裾野についてはあまり明確ではない。

なぜこれが際立っているか

過去1年間、多くのビデオ生成の発表を見てきた。そのほとんどは漸進的なものだ：より良いFIDスコア、わずかに長いクリップ、わずかに速い推論。Heliosが異なって感じるのは、私が内面化していたと気づかなかった前提に挑戦しているからだ——リアルタイムの長尺ビデオ生成には、互いに積み重ねられた推論最適化の塔が必要だという前提。

Heliosが提案する答えは：モデルをより良く学習させたら何が起きるか？ 複雑さを推論スタックではなく学習パイプラインに押し込む。効率を後付けするのではなく、モデルを本質的に効率的にする。

そのアプローチがスケールし、汎化し、本番ワークロードとの接触を生き延びるかどうかは未解決の問いだ。しかし方向性は説得力がある。可動部品が少なく、アーキテクチャがクリーンで、パフォーマンス数値が自ずと語る。

コードとウェイトはGitHubにある。Apache 2.0。H100と午後の時間があれば、試してみる価値がある。