7倍速うたう動画生成、依存不足で動作せず

Wave Forcingはストリーミング動画生成の特定のボトルネックを狙う。素朴な拡散モデルでは、新しいチャンクが前のチャンクの完全なノイズ除去を待つため、GPU間のパイプライン処理が妨げられる。この手法はチャンクレベルの因果アテンションを再設計し、新チャンクがきれいな前チャンクだけでなく混合ノイズのフロンティアを条件にできるようにする。これにより、チャンク処理の各段階を別々のGPUレプリカで実行するWave Parallelismが可能になる。専用のWaveRTランタイムがK/V状態のGPU間交換を担い、長めのアテンション計算の裏で通信を先読みする。リポジトリには複数の交換モード実装（sync、overlap、one-sided、staggered、relay、paged）が含まれる。

設計と分散コードの間のギャップが中心的な問題だ。READMEのクイックスタートは8GPUの5+2構成を最小とし、config.pyはwp_size=1がrf_step=0の縮退ケースに潰れるよう並列度を制約しており、実質的にこの手法が提供すべきパイプライン処理を排除してしまう。しかも公開された依存関係の連鎖はその構成すら支えない。uv syncはsglangを入れず、WanRollingForcingPipelineのレジストリ参照が失敗する。config.py以外にRollingForcingへの言及はなく、このクラスが非公開フォークにあることを示す。別の比較スクリプトもAPI不一致に当たる。maybe_init_distributed_environment_and_model_parallel()がcfg_degreeを受け付けず、enable_cfg_parallelを期待している。この不一致を直しても、欠けたパイプラインがブロッカーとして残る。

ライセンスと重みは公開され推論には寛容だが、公開されたREADMEとpyproject.tomlから再現性を得るにはほど遠い。筆者はこれをハードウェア環境の制約ではなく、ツールの公開依存範囲の欠陥と位置づけている。つまり十分なGPU能力を持つチームでも、著者の内部パッケージにアクセスできなければ報告された高速化を検証できない。