仕事に応じてサービスクラスを分ける
制作プレビューには短い待ち時間が必要です。モーション転送では、より長い出力に元の演技を保つ必要があります。高解像度の映像・音声リクエストは複数の GPU を同時に占有することがあります。最適化には精度、アテンション、メモリ常駐、並列化、コンパイル、品質にまたがる判断が必要です。
ProsGrow は、RTX PRO 6000 Blackwell を 8 基搭載したノードでこれらのサービスクラスを評価しました。MiniMax-H3 の比較では、同じ GPU 8 基で同じ BF16 Turbo リクエストのサーバー推論を 19.392 秒から 8.913 秒へ短縮し、レイテンシを 54.0% 削減しました。Wan と Animate の別実験は、納期、総需要、品質要件により適切な設定が変わることを示しています。
ワークロードの条件を定義し、ボトルネックを分析し、候補となる動作点を比較し、選定結果を検証しました。各実験は、測定した改善をリソースと品質の制約に結び付けています。
MiniMax-H3：レイテンシ、メモリ、品質
MiniMax-H3 では、大規模な映像・音声負荷を PCIe ノードに分散するコストが明らかになりました。並列処理の分け方を変えることで、同じ GPU 8 基でサーバー推論を19.392 秒から 8.913 秒へ短縮しました。同じ BF16 Turbo リクエストでレイテンシ 54.0% 削減です。
テンソル並列とシーケンス並列では、通信とメモリの要件が異なります。制御した測定は、この負荷で通信負担を減らす方針を支持しましたが、原因をカーネル単位で特定できる有効なトレースは得られませんでした。選定した低レイテンシ設定はGPU 当たり約 84.2 GBを使用し、メモリ余裕の大きい設定にはレイテンシの代償がありました。
上流の SGLang MiniMax-H3 スタックがモデル配信と並列化の構成要素を提供しています。ProsGrow は、このハードウェアでの挙動を評価し、サービス目標に沿って選択しました。
別の近似計算実験では中間計算を再利用し、サーバー推論を8.913 秒から 7.092 秒へ、さらに 20.44%短縮しました。API 完了時間は10.045 秒から 8.040 秒へ減少し、引き続き 8 基すべてを 1 リクエストに割り当てています。デコード時間はほぼ変わりませんでした。
追加の改善には別の受け入れ条件があります。近似計算には品質ゲートが必要です。選定候補は 1 シーンに限った数値整合性チェックを通過しました。これは候補動作点を支持する証拠であり、広い範囲の知覚的同等性や、すべての顧客負荷への承認ではありません。
Wan2.2：4 ステップの制御比較
| 指標 | 蒸留済み BF16 ベースライン | 選定した LightX2V 設定 |
|---|---|---|
| ウォーム時パイプライン | 22.164 s | 9.062 s · 59.1% 削減 |
| ノイズ除去 | 19.164 s | 6.076 s |
| VAE デコード | 約 2.37 s | 約 2.36 s |
選定経路は低精度化、疎なアテンション、GPU 常駐を組み合わせます。これらは、量子化を考慮したステップ蒸留も含め、上流の LightWan2.2 モデルと LightX2V ランタイムが提供する機能です。ProsGrow は実行経路を統合・検証し、ローカルの対照条件を設け、サービス上のトレードオフを測定しました。
標準の 40 ステップ BF16 実行には 357.640 秒かかりました。この参照との差の多くは上流のステップ蒸留によるものです。4 ステップ BF16 の対照実験では、蒸留による効果とは別に、ランタイム変更の複合効果として追加の 2.45×高速化を測定しています。
精度、アテンション、常駐配置の相互作用
改善の余地は実行経路の複数レイヤーにありました。
- 精度とアテンション：小さな数値表現と疎なアテンションでノイズ除去の処理量を減らしました。複合効果はモデルと対応する実行経路に依存し、形式を変えるだけでは高速化を保証できません。
- GPU 常駐：小さくなったエキスパート重みを GPU メモリに置いたままにでき、ホストからデバイスへの転送をクリティカルパスから除けました。メモリ節約は演算量だけでなく、計算を実行できる場所も変えました。
- パイプラインのバランス：デコードは約 2.36 秒のままでした。ノイズ除去が速くなると、ほぼ変わらないこの段階の比率が増し、さらなるノイズ除去高速化の効果を制限します。
- ウォームとコールドのサービス：最適化した独立プロセスは、モデル読み込み、ウォームアップ、終了を含め 72.12 秒かかりました。短いウォーム推論時間を得るには、起動処理と常駐を管理するサービスが必要です。
制御実験の結果はこれらの変更全体を測っています。各レイヤーに独立した因果的高速化を割り当てるものではありません。そのため、最適化には段階別の時間とエンドツーエンドの提供範囲の両方が必要です。
ノードの同期実行では、各 GPU のウォームレイテンシは同程度でした。最も遅い完了時間から換算すると、このプレビュー条件で約 3,138 クリップ/時になります。これは 1 回の測定からの能力換算で、1 時間継続した API 試験ではありません。品質も制約になります。生成構図は異なり、知覚的同等性は確認していません。
Animate-2：非同期サービス向けの処理量
Animate-2 は参照画像と元動画から 11.21 秒のモーション転送動画を生成します。このような長い処理は非同期キュー向けで、対話的プレビューの期限より、完了した出力数と仕事当たりのエネルギーが重要です。
ProsGrow は検証済みの FP8 実行経路と永続的なコンパイルキャッシュを組み合わせました。コンパイル済みコードの再利用は起動時の反復作業を減らし、精度変更は定常実行のコストを変えました。両者とも、このサービスが使う起動全体の計測範囲で測定しました。
| 指標 | BF16 ベースライン | FP8 + コンパイルキャッシュ |
|---|---|---|
| ノードの出力速度 | 24.382 出力/時 | 28.678 出力/時 · +17.62% |
| ノード全体の平均電力 | 6.581 kW | 6.575 kW |
| 出力当たりのエネルギー | 0.270 kWh | 0.229 kWh |
サーバー電力がほぼ一定のまま処理量が上がり、出力当たりのエネルギーが約 15.1%減少しました。選定設定のGPU メモリ余裕は約 4 GiBしかなく、出力形状と同時実行が導入時の重要な制約になります。
コンパイルキャッシュも運用成果物です。ハードウェア、ランタイム、モデル形状、コンパイル設定が変われば、バージョン管理や再構築が必要です。有用な結果には、処理量と視覚的回帰チェックに加え、このライフサイクル判断も含まれます。
顧客に合う動作点を選ぶ
ノード全体を使えば 1 リクエストを短縮できます。容量を小さなレプリカに分ければ、独立した処理の総完了数を増やせます。上流のモデル枝刈りと Turbo アダプターを用いた別の MiniMax 実験では、同期実行 1 回から478.14 クリップ/時を換算し、各リクエストは約 30.1 秒でした。モデルとサービス構成が異なるため、専用の品質評価が必要です。
| サービスクラス | 主な目標 | 引き継ぐべき制約 |
|---|---|---|
| 対話的プレビュー | 短いリクエスト完了時間 | ウォーム常駐、待ち行列、許容できる視覚的変化 |
| 総生成量 | ノード当たりの合格クリップ数 | レプリカメモリ、リクエスト待ち時間、品質 |
| 非同期モーション転送 | 完了ジョブ数と出力当たりのエネルギー | コンパイルのライフサイクル、メモリ余裕、元素材への忠実性 |
これらすべての目標に共通する唯一の最適設定はありません。成果は、レイテンシ、処理量、メモリ、エネルギー、品質の間の測定済み選択肢です。実験はサービスクラス選択の根拠を示します。その後、顧客の試験導入で代表的な素材を使い、合格出力、待ち行列、納期を検証する必要があります。
方法と制約
| 実験 | 出力条件 | 計測範囲 |
|---|---|---|
| Wan2.2 / LightWan2.2 | 81 フレーム、832×480、16 FPS、5.0625 s。プロンプトとシードを固定 | LightX2V。ウォーム状態の同期パイプラインからエンコード/保存まで。モデル読み込みとウォームアップは除外 |
| Wan2.2 Animate-2 14B | 269 フレーム、713×1264、24 FPS、11.2083 s、元音声。同じ参照素材、4 セグメント × 10 ステップ | LightX2V。起動全体の実時間。選定結果はコンパイルキャッシュを用意 |
| MiniMax-H3 FL2VA Turbo | 1344×768、124 フレーム、24 FPS、5.175 s のファイル、生成音声。同じプロンプトとシード、観測したノイズ除去器の評価 4 回 | SGLang。サーバー推論と API 完了全体を別々に測定 |
- ハードウェアと反復：RTX PRO 6000 Blackwell GPU 8 基のノード 1 台、GPU 当たり公称 96 GB。Wan は各ワーカーでウォーム生成を 1 回測定。Animate の採用値はノード実行 2 回のうち遅い方です。各 H3 レイテンシ候補はウォームアップ 1 回と測定リクエスト 1 回で、レプリカ速度は同時実行 1 回から得ています。短時間の実験であり、持続負荷の SLA やレイテンシ百分位を確立するものではありません。
- Wan の品質：一覧画像の確認では一貫した動画でしたが、試した 1 シーンでは標準 40 ステップの参照の方がプロンプトの字義に忠実でした。蒸留、疎化、精度変更による知覚的同等性は確認していません。
- Animate の品質：269 フレームすべてを BF16 と比較し、SSIM 0.9534、PSNR 31.74 dB でした。これは入力 1 件での視覚的回帰チェックです。
- H3 の品質：選定した近似は参照に対し SSIM 0.8128 で、ローカル並列化設定間で観測した下限 0.8102 をわずかに上回りました。この数値チェックは、動き、プロンプトへの忠実度、音声同期、人の好みを複数プロンプトで確認する代わりにはなりません。別の枝刈りモデル処理量実験は、元モデル参照に対して SSIM 0.8815 でした。
- 貢献と計時：上流のモデルとランタイムが最適化の構成要素を提供しています。複合変更では各要素の効果を分離できません。H3 のサーバー推論はクライアントのポーリングとダウンロードを除きます。8.913 秒のサーバー結果と 10.045 秒の API 結果は、比較でも区別する必要があります。
Wan は 2026 年 8 月 12〜18 日、MiniMax の追加実験は同年 9 月 1〜2 日に測定しました。結果は記載した素材と出力条件に適用されます。
プライベート MiniMax-H3・Wan 動画生成
MiniMax-H3 または Wan2.2 を使うプライベート動画生成では、最初に、速いプレビューと一定時間内の完了ジョブ数のどちらを重視するサービスかを決める必要があります。サーバー推論遅延、API 全体の完了、生成スループットはそれぞれ異なる測定範囲を表します。顧客評価では、出力形状、元メディア、許容できる見た目の変化を各結果と併せて扱う必要があります。