H3 Lightning、MiniMax H3の動画生成を4ステップに短縮。ただし12.2倍の高速化は未公開の重みに依存

RunningHubはH3 Lightningをリリースし、MiniMax H3の動画・音声生成モデルをSGLangの`multimodal_gen`ランタイムに統合するとともに、ソフトウェアのバージョン、モデルrevision、起動パラメータ、測定手順を固定した。これは単一の新しいカーネルではなく、計算量の削減と実行レイヤーの最適化を積み重ねたものだ。まず、後学習／ステップ蒸留によってベースラインの50回のデノイジングステップを4回に減らし、次にSageAttention2でAttentionを高速化し、Cache-DiTで中間計算の一部を再利用する。最後に`torch.compile`で計算グラフをコンパイルする。

NVLinkを搭載せず、PCIeのみで接続された8基のRTX 6000D上で、チームは1344×768、5秒のText-to-Video生成について、BF16ベースラインの348.8秒から43.0秒への短縮を測定した。さらに実行時最適化をすべて適用すると28.7秒まで短縮され、12.2倍の高速化に相当する。別の15秒動画のテストでは、並列化戦略をTP4＋Ulysses2からTP2＋Ulysses4へ変更することで、レイテンシを54.0秒から48.2秒に短縮し、GPUメモリ使用量も約14 GiB削減できた。これはNVLinkを持たないPCIeサーバーにとって特に参考になる。動画生成に最適な分割方法が、大規模言語モデルの純粋なtensor parallel構成と同じとは限らないためだ。

エンジニアリングの観点では、12.2倍という数値を要因別に捉える必要がある。効果の大部分は50ステップを4ステップに減らしたことによるもので、同一の数値計算を損失なく高速化した結果ではない。また、SageAttentionはAttention内部で量子化も使用している。さらに重要なのは、公式結果に使用されたRH内部の高速化用の重みがまだ公開されておらず、リポジトリで提供されているのはコミュニティ製LoRAによる代替のみだという点だ。そのため、現時点で再現できるのはデプロイ手順であり、ベンチマーク結果全体ではない。テストからは、モデルのロード、初回コンパイル、キュー待ち、ダウンロードの時間も除外されている。導入者はprompt、seed、解像度、モデルrevisionを固定し、コールドスタートと定常状態のレイテンシを個別に測定するとともに、人物の一貫性、動きの連続性、promptへの準拠、音声と映像の同期を人手で確認すべきだ。次に注目すべき重要なシグナルは、内部の重みが公開されるかどうか、そして第三者が異なるBlackwell／Hopperトポロジー上で品質と速度のトレードオフ曲線を再現できるかどうかである。