MAGI-2-previewがSGLangに登場: 新しいサービングPRが明らかにするもの

Sand.ai の1140億パラメータの Mixture-of-Experts（MoE）動画生成モデルである MAGI-2-preview は、2026年8月5日にオープンソース化されました。そして11日後、同モデルがまもなく本番グレードのサービング基盤を手に入れることを示す最初の兆候が現れました。8月16日、SGLang リポジトリに [diffusion][Model] Support MAGI-2-preview というタイトルのプルリクエストが開かれました（sgl-project/sglang、PR #35014）。このタイトルは正確です。これは、SGLang のディフュージョンスタックに MAGI-2-preview のネイティブなサービングサポートを組み込むものです。また、本稿執筆時点では、これはまだプルリクエストのままです。オープン状態で、コードオーナーのレビュー待ち、CIチェックは失敗しています。何もマージされていないため、まだ何もサービス提供できません。しかし、MAGI-2-preview を Sand.ai のリファレンス用 Docker-and-torchrun セットアップから主流のサービングランタイムに移行できるかどうかを検討している人にとって、このPRは詳細なロードマップです。

ですから、これはリリースノートではなく、これまでに判明している情報をまとめたものとして扱ってください。モデルは実在し、リリース済みです。それは8月5日に行われ、ウェイトはHugging Face、コードはGitHub上でApache-2.0ライセンスの下で公開されています。未検証なのはサービングの作業です。SGLang統合は単一のオープンなプルリクエストであり、その詳細はレビュー中に変更される可能性があります。そして、それがマージされるまで、SGLangは実際にはMAGI-2-previewを実行できません。価値があるのは、そのPRがモデルと、実際のランタイムで実行するまでの道筋について明らかにしている点です。

PRの対象モデルについて、1段落で説明してください。

MAGI-2-previewは、Sand.aiが言語モデルのスケーリングと同様の方法（すなわちMoE、混合専門家）で動画生成をスケールさせようとする試みであり、オープンソースのMAGI-1（2025年4月公開の24B自己回帰型動画モデル）の後継モデルである。この新モデルは合計約114Bパラメータを備えるが、トークンごとに活性化されるのは約6Bのみである。極めて細粒度のマルチヘッドMoEを採用しており、3,072次元の隠れ状態が12個の256次元ヘッドに分割され、各ヘッドは256個のエキスパートのうち6個にルーティングする。これにより、各MoE層あたり3,072個のエキスパートユニット、36層全体ではトークンあたり72個のエキスパートが活性化されることになる。これは統合型の単一ストリーム音声・動画モデルであり、テキスト、動画、音声は同じトランスフォーマーを通過し、別個のクロスアテンションパイプラインではなく、各層の自己注意（セルフアテンション）を通じて情報を交換する。テキストから動画への生成と画像から動画への生成に対応し、サポートされる唯一の長さである10秒のクリップを生成する。同期されたステレオサウンドトラックは同じデノイジング軌道内で生成され、出力ファイルに多重化される。

生成は2段階で実行されます。最初のmagi2_previewステージは512×896でノイズ除去を行い、次にmagi2_refinerステージが1088×1920にアップスケールします。ベースリリースでは、プレビュー100ステップとリファイナー5ステップのノイズ除去を使用します。Sand.aiによると、ステップ数がはるかに少ない蒸留版が登場予定です。チェックポイントセットは、約307 GBの単一のHugging Faceリポジトリです。内訳は、228 GBのプレビューステージ、Qwen3.5-27Bテキストエンコーダー、14 GBのリファイナー、5 GBのオーディオVAE、Wan2.2-TI2V-5Bから借用したビデオVAE、そしてデフォルトで使用される蒸留ターボVAEデコーダーです。ハードウェア要件は、NVIDIA Hopper（H100クラス）GPU 8基です。リファレンスランチャーを使用すると、各フェーズでテキストエンコーダー、プレビュー、リファイナー、VAEをCPUとGPUの間でオフロードできます。

パフォーマンスに関して、流れている数字は報道されたものであり、独立して再現されたものではない。主張内容 — VBenchスコア86.54%で、同じ中国報道においてSora 2（84.37%）やKling 2.0（84.20%）を上回るというもの、そしてArtificial Analysisの画像から動画へのリーダーボードでElo約1106で6位というもの — はベンダーとローンチ時の報道に由来しており、リリースから11日間、独立した第三者による実行は一切行われていない。Sand.aiはまた、推論コストをH100を8台使用した場合の10秒・1080pクリップあたり約0.5元（約0.07ドル）、つまり主流の動画モデルの約10分の1と見積もっている。誰かが実際に測定するまでは、これらすべてをベンダーおよび報道による報告として受け取ってほしい。

なぜ送達プルリクエストが本当のニュースなのか

これまで、MAGI-2-preview を実行するための公式にサポートされた方法は、正確に1つだけありました。それは、Sand.ai 自身のリファレンススタック、つまり Docker イメージと torchrun を8基の NVIDIA Hopper H100 上で使うというものです。それは実用可能ですが特注の道であり、Sand.ai のランチャー、そのオフロード決定、そしてテキストエンコーダ、プレビュー、リファイナー、VAE をメモリ階層間でステージングするという独自の方法を引き継ぐことになります。SGLang にモデルを追加するプルリクエストが重要なのは、SGLang が、セルフホスト型生成AIの世界の大きな部分が実際に本番環境でデプロイしているサーバーランタイムだからです。ファーストクラスサポートとは、MAGI-2-preview が、SGLang のメカニズム——Ulysses シーケンス並列処理、エキスパート並列処理、アクティベーションオフロード、VAE、スケジューラ、パイプラインステージのインフラストラクチャ——を背後に備えた、主流のランタイムで実行可能になることを意味します。それが「彼らのスタックで実行できる」と「自分のチームがすでに運用しているスタックで実行できる」の違いです。

このPRが実際に構築するもの

この統合は、既存の{{1}}SGLangマシナリー{{/1}}上に構築されており、{{2}}リファレンスのtorchrunパス{{/2}}には基づいていません。このPRは、{{3}}マルチヘッドMoE層、アテンションシンクの配管、リファイナーステージ用のブロックウィンドウ・ローカルアテンション、およびマルチストリーム・ハイパー接続{{/3}}を追加します。これらは、{{4}}汎用レイヤーではまだ表現されていないMagiMoEのアーキテクチャ構成要素{{/4}}です。これらの周辺では、SGLangの既存の{{5}}Ulyssesシーケンス並列処理、エキスパート並列処理、オフロード、VAE、スケジューラ、およびパイプラインステージコンポーネント{{/5}}を再利用しています。また、ドキュメント（{{6}}SGLangの拡散ドキュメント用のMAGI-2クックブックページ{{/6}}）と{{7}}47件のGPU不要のユニットテスト{{/7}}も同梱しており、これは{{8}}H100を8台レンタルすることなく{{/8}}モデルの動作のどれだけを検証できるかを示す良い指標です。

また、このPRはモデルの制約を明示しています：

• ハードウェア — NVIDIA Hopper H100を8基搭載。リファレンススタックのcpu / gpu / roundtripオフロードモードは、テキストエンコーダ、プレビュー、リファイナー、VAEがフェーズ間のどこに配置されるかにマッピングされます。

• 並列性 — --num-gpusはすべてのヘッド軸を割り切る必要がありますが、--tp-size、--ring-degree、および--enable-cfg-parallelは拒否されます。これはルーティング次元が多いモデルであり、並列性レイアウトはそれらと整合させる必要があります。

• 出力 — 受け付けられるのは 1920×1088 と 896×512 の解像度のみで、クリップは 10 秒のみ。torch.compile はサポートされていません。

最後のセットは、デプロイを計画しているなら二度読む価値がある。これは、少なくともこの初期統合の時点では、2つの解像度と1つの持続時間に固定されているモデルだ。

まだ未確認なのは何ですか？

サーブ（サービング）ワークに関するすべて。PRはオープンのままで、コードオーナーのレビュー待ちであり、CIチェックは8月16日時点で失敗していました。この規模のプルリクエストは、レビューに数日から数週間かかることがあります。マージされた状態も、リリースも、SGLangからのアナウンスもありません。そしてモデル側の主張——VBenchスコア、Artificial Analysisのランク、0.5元というコスト数値——は、ベンダーと報道による報告であり、独立に再現されたものではありません。今日このPRの上にワークフローを構築するなら、それはランタイムではなくロードマップの上に構築していることになります。

コスト計算にとっての意味

MAGI-2-preview が注目を集めた理由は、その経済性にある。トークンごとに6Bパラメータを活性化し、114Bの容量を持つモデルは、クリップあたりの実行コストが安い。Sand.ai は8台のH100で10秒の1080pクリップあたり約0.5元としている。そして、そのような数字が、小規模チームが動画生成を利用できるかどうかを左右する。しかし、その0.5元という数字は、リファレンススタック、H100クラスター、そしてサービングオーバーヘッドを前提としている。このようなオープンモデルが広く利用可能になる通常の方法は、マネージドAPIである。つまり、誰かがホストし、クリップごとに価格設定し、8台のH100をレンタルする必要がない。

ホストされたルートが存在する場合、ルーティングの観点が重要になります。ルーティングプラットフォームでは、ベンダーがMAGI-2-previewクリップに対して設定したリスト価格がそのまま支払額になります。OrcaRouterはプロバイダーのリスト価格をゼロマークアップで透過するため、ベンダーの値下げは、再交渉なしに、リリースされたその日に当社側でも有効になります。また、独立したベンチマークがない11日前のオープンウェイトのチェックポイントは、自動フェイルオーバーの背後に置きたいまさにその種のモデルです。評価のためにルートをそのチェックポイントに向け、同じエンドポイントに実績のあるフォールバックを維持しておけば、初期のチェックポイントが停止したり、使えない出力を生成したりした瞬間に、パイプラインではなく呼び出しがフェイルオーバーします。これこそが、実証されていないモデルを、本番経路を賭けずに試す方法です。

私たちが今見ているもの

• PRがマージされるかどうか、そしてレビューで何が変更されるか。制約リスト — 2つの解像度、1つの時間、torch.compileなし — は最終的なものではない可能性があります。

• 蒸留チェックポイント。Sand.aiによると、少ないステップ数のウェイトが間もなく登場する予定で、それが0.5元という数字を実験室での測定値から、現実的なクリップあたりのコストへと変えることになる。

• 初の独立ベンチマーク。VBenchとリーダーボードの数値はベンダーおよび報道機関による報告であり、第三者による実行が6B-activeという主張の妥当性を明らかにするだろう。

他のランタイムが追従するかどうか。SGLang は MAGI-2-preview を採用した最初の主要サービングランタイムであり、vLLM などもそう遠くないうちに追従するかもしれません。

• マネージドAPIが登場するかどうか。このモデルの売りは、規模が大きくなったときの低コストにあります。ホスト型ルートが存在する瞬間、上記のパススルー価格計算が有効になります。

正直なまとめ：MAGI-2-previewは公開から11日しか経っていないオープンモデルであり、そのコスト構造が重要になり得る。SGLangのPRは、エコシステムがこれを真剣に受け止めていることを示す、これまでで最も明確なシグナルだ。ただし、サービングサポートはオープンなプルリクエストであって、出荷済みの機能ではない。ロードマップは本物として扱い、ランタイムはまだ未整備と見なすべきだ。そして、モデルが実際のAPIの背後に登場したときには、フェイルオーバー優先のアプローチこそが、誰も独立にベンチマークしていないチェックポイントに本番パスを賭けずに採用する方法なのだ。