XiaohongshuがBigMacをオープンソース化、マルチモーダル学習のトレードオフに挑む

XiaohongshuはBigMacをオープンソース化し、注目すべき主張を打ち出している。新しい学習パイプラインは、バッチサイズの増加に伴って活性化メモリを増大させることなく、テスト対象のベースラインよりもマルチモーダルワークロードを1.08～1.9倍高速に実行するという。このシステムは、マルチモーダルモデルの学習における根深い対立を対象としている。通常、チームはより多くの中間データを保持することで速度を高めるか、GPUのアイドル時間と通信量の増加を受け入れてメモリを節約する。

BigMacは新しい基盤モデルを導入するものではない。既存のマルチモーダルモデルの各コンポーネントをアクセラレータクラスタ上でスケジューリングする方法を変える。Xiaohongshuの研究者たちは、依存関係を維持しながら、エンコーダとジェネレータの処理を言語モデルのパイプライン内に配置する。その結果を「依存関係を安全に保つネスト型パイプライン」と呼んでいる。

この違いが重要なのは、従来のシステムが問題の異なる側面に取り組んでいたためだ。Optimusは、言語モデルのパイプライン内にあるアイドル時間を埋めることに重点を置いた。DistTrainは、異種コンポーネントを分離し、それぞれがより適切な並列構成を利用できるようにした。BigMacは、高い使用率と活性化メモリの上限維持を両立させようとしており、真の競争軸を、計算効率の高いスケジューリング対メモリ効率の高いスケジューリングへと変えている。

結果は有望だが、依然として著者自身による報告にとどまる。BigMacの論文はプレプリントであり、最も広範な本番環境に関する主張は、大規模クラスタで独立に再現されていない。したがって、その重要性は2つの問いにかかっている。外部のチームがその性能向上を再現できるのか、そして学習スタックを再構築せずにスケジューラを統合できるのか、という問いだ。

Xiaohongshuが異なる種類のボトルネックに向けてBigMacをオープンソース化

BigMacは、マルチモーダル学習をハードウェアの問題として扱う前に、スケジューリングの問題として捉える。

マルチモーダル大規模言語モデルは、言語モデルとモダリティ固有のコンポーネントを組み合わせたものだ。たとえばビジョンエンコーダは、画像を言語モデルが処理できる表現へと変換する。ジェネレータは、言語モデルの出力を画像、動画、音声、またはその他の非テキスト形式へと変換できる。

これらのコンポーネントが同じように計算資源を消費することはほとんどない。言語モデルは、比較的均一な多数のトランスフォーマー層で構成される場合がある。ビジョンエンコーダは、パラメータ数、シーケンス構造、最適な並列化方式が異なる可能性がある。拡散ベースのジェネレータは、さらに別の計算パターンと依存関係を持ち込む。

その結果、モデルは各工程が異なる速度で動作する生産ラインのようになる。あるコンポーネントに割り当てられたGPUは、処理を早く終えて別のコンポーネントを待つことがある。このようなアイドル区間は一般にパイプラインバブルと呼ばれ、必要なデータがまだ到着していないため、アクセラレータが有用な処理を実行できない時間を指す。

BigMacの研究者たちは、既存の解決策が、しばしば希少な資源の一方をもう一方と引き換えにしていると主張する。スケジューラはより多くの処理を進行中の状態に保ってバブルを減らせるが、その処理を保持すると活性化メモリが増加する。活性化とは、後の誤差逆伝播で必要になるため、順伝播中に保存される中間値のことだ。

別の方法として、システムは活性化をより早く解放したり、モデルのコンポーネントをより積極的に分割したりできる。この手法はメモリ負荷を下げるものの、通信、同期、またはアイドル時間を増加させる可能性がある。論文では、これらの選択肢をパレートフロンティアとして捉えており、計算効率を改善するとメモリ効率が悪化しやすいとしている。

BigMacの中心的な工夫は、元の言語モデルパイプラインをスケジューリングの骨格として維持することだ。その上で、依存関係上実行可能な場合に限り、エンコーダとジェネレータの処理をその骨格にネストする。スケジューラは、空いているGPUサイクルを見つけるために数学的な処理を恣意的に並べ替えるわけではない。

研究チームは、2026年5月25日に公開されたBigMacプレプリントで、この構造について説明している。論文には11人の著者が名を連ね、マルチモーダル理解と生成の両方のワークロードを評価している。Xiaohongshuはその後、自社の技術系媒体を通じて、dotsモデルチームが利用するオープンソースコンポーネントとしてこのシステムを紹介した。

報告された性能範囲には文脈が必要だ。結果の詳細な分析によると、テストされた設定においてBigMacはOptimusより1.08～1.1倍高速だった。よりメモリ効率を重視するMegatron-DistTrainのベースラインに対しては、報告された優位性は1.5～1.9倍だった。

これらの比較は、すべての学習ジョブが90％高速になることを意味しない。より大きな数値は、特定のベースラインとワークロードの組み合わせから得られたものだ。ハードウェアトポロジー、モデルアーキテクチャ、バッチ構成、パイプラインの深さ、通信帯域幅はいずれも結果を変え得る。

それでも、この変化には意味がある。Xiaohongshuは、理解モデルと生成コンポーネントを備えたモデルの双方を対象とするシステム技術を公開した。また、BigMacは研究室でのテスト段階を越え、同社のdotsマルチモーダルモデルの本番学習経路に導入されているとしている。

マルチモーダル学習がGPUに不利な選択を迫る理由

圧力の原因は、単にモデルが大規模化することではなく、モデルの異種性にある。

テキスト専用トランスフォーマーのスケーリングでさえ、チームはデータ並列、テンソル並列、パイプライン並列、メモリ管理を調整する必要がある。マルチモーダル学習では、単一の共通戦略ではきれいに分割できないコンポーネントが加わる。

パイプライン並列では、連続するモデル層のグループを異なるデバイスに割り当てる。マイクロバッチは、工場の製品のように各ステージを通過する。大規模モデルを効率的に分散できる一方、パイプラインへの投入と排出を慎重に管理しなければならない。

ビジョンエンコーダは、関連する言語モデルのステージが結果を利用できるようになる前に、自身の処理を終える場合がある。ジェネレータは、言語モデルが適切な出力を生成するまで待たなければならない。逆伝播中には、勾配が正しい順序でこれらのコンポーネントを通って戻る必要がある。

単純なスケジューラは、エンコーダを早めに実行し、その活性化を保存できる。これにより言語モデルへ渡す入力を準備しておけるが、より多くのマイクロバッチがパイプラインに入るにつれて、保存された活性化が蓄積する。その結果、グローバルバッチサイズを増やすと、ピークメモリ使用量も増加する。

このパターンは実用上の上限を生み出す。チームはより大きなバッチを処理するのに十分な演算能力を持っていても、すべての中間状態を保持するためのメモリが不足している可能性がある。バッチを小さくするか、より多くの活性化にチェックポイントを適用すれば実行可能になるが、どちらの選択肢も実効スループットを低下させ得る。

Optimusはアイドル時間に直接取り組んだ。その研究者たちは、エンコーダのカーネルが言語モデルのスケジュール内のバブルを活用できることを確認した。公開されたOptimusシステムでは、3,072基のGPU上でViT-22BとGPT-175Bを組み合わせた場合、学習速度が20.5～21.3％向上したと報告されている。

この手法は重要な原則を確立した。異種コンポーネントは、必ずしも分離された連続的な実行枠を必要としない。本来ならアイドル状態になる時間に、有用なエンコーダ処理を挿入できる。

しかし、バブルを埋めても、活性化が保持される時間を自動的に制御できるわけではない。対応する逆伝播処理よりもエンコーダが大幅に先行すると、システムはより多くの中間データを保持することになる。計算資源の使用率が向上する一方で、メモリ負荷は高まる。

DistTrainは、分離によって異種性に対処した。モデルの各コンポーネントに個別のリソース計画と並列化計画を割り当て、モダリティ間の不均衡を減らすためにデータを再編成した。DistTrainの研究では、1,172基のGPU上で720億パラメータのマルチモーダルモデルを実行した際、モデルFLOPs使用率54.7％を達成したと報告されている。

同じ研究では、評価した設定においてMegatron-LMの最大2.2倍のスループットも報告された。しかし、分離は通信とオーケストレーションのコストをもたらす可能性がある。メモリを保護し、異なるコンポーネントに対応するシステムであっても、性能を十分に引き出せないことがある。

BigMacは、チームがもはや両者の間で選択する必要はないと主張し、双方のアプローチに圧力をかけている。その直接の競争相手は、特定の企業やフレームワークではない。計算効率の高いマルチモーダルスケジューリングには、増大し続ける活性化メモリが不可欠だという前提そのものだ。

この圧力は、汎用学習フレームワークを基盤として構築するプラットフォームチームにも及ぶ。NVIDIAのMegatron Coreは、大規模トランスフォーマーとマルチモーダルワークロード向けの分散学習コンポーネントを提供する。このような基盤を使用するチームにも、各アーキテクチャ固有の依存関係を反映したスケジュールが必要だ。

大規模AI研究所にとって、スケジューリングの改善はベンチマーク速度以上の影響をもたらし得る。スループットが向上すれば、実験間の所要時間が短縮される。メモリ使用量に上限を設けられれば、既存のクラスタ上で、より大きなバッチ、より長いシーケンス、より負荷の高いエンコーダ、またはより大規模なジェネレータを利用できる可能性がある。

モデルAPIを呼び出すだけのアプリケーション開発者にとって、その価値はそれほど直接的ではない。それでも学習効率は、どのマルチモーダル機能が本番環境に到達するかに影響する。モデルチームが追加のデータ学習、アーキテクチャテスト、または高解像度の学習段階を実施できるかどうかを左右し得る。

BigMacは活性化を蓄積させずに処理をネストする

その仕組みは、空き時間により多くのカーネルを詰め込むだけでなく、処理が実行可能になるタイミングを制御することに依存している。

BigMacは、インターリーブ型の言語モデルパイプラインから始まる。インターリーブでは、複数の仮想モデルセグメントを物理パイプラインステージに割り当てることで、順伝播処理と逆伝播処理をより緊密に交互実行できるようにする。言語モデルの確立されたスケジュールが、引き続き全体の基準となる。

スケジューラは、エンコーダのワークロードを言語モデルの入力に対応する単位へ分解する。そして、入力が消費される前に、限られた数のエンコーダ順伝播単位を配置する。論文で分析されたスケジュールでは、エンコーダをバッチ全体にわたって先行させるのではなく、一定の先読み幅を使用している。

この先行幅の制限が、メモリに関する主張の中心となる。エンコーダの活性化は、言語モデルがその出力を消費し、誤差逆伝播によって対応する勾配が返されるまで保持すればよい。BigMacは、その依存関係が満たされ次第、エンコーダの逆伝播処理をスケジューリングする。

論文のインターリーブ型スケジュールでは、一度にアクティブな状態を維持する必要があるエンコーダ単位は一定数だけだ。研究者たちは、エンコーダの活性化メモリ計算量をO(1)と説明している。簡単に言えば、該当するメモリはマイクロバッチ数に比例して増加しない。

O(1)はメモリが不要という意味ではない。これは、提示されたスケジュールのもとで、同時に保持されるエンコーダ活性化単位の数が一定範囲内に収まることを意味する。実際のメモリ使用量は、依然としてエンコーダの規模、画像解像度、シーケンス長、精度、実装の詳細に左右される。

ジェネレータも同様のパターンに従う。その順伝播計算は、言語モデルが必要な出力を生成した時点で開始される。BigMacは、必要な順伝播の依存関係の直後にジェネレータの逆伝播処理を配置し、多数のマイクロバッチにわたってジェネレータの活性化が蓄積するのを防ぐ。

このスケジューリングの選択は、特にマルチモーダル生成に関連する。大規模な拡散トランスフォーマーや同様のジェネレータは、相当量のメモリを消費し得る。逆伝播より前に複数のジェネレータ順伝播を実行すると、言語モデル自体は収まっていても、アクセラレータのメモリを使い果たす可能性がある。

依存関係の安全性がガードレールとなる。ネストされたすべての処理は、モデルの順伝播および逆伝播グラフを遵守しなければならない。まだ利用できないデータを消費したり、後で必要になる情報を上書きしたりする場合、スケジューラは魅力的な空き時間であっても処理を埋めることはできない。

研究者らはまた、ネストされた処理によって元の言語モデルのスケジュールにバブルが追加されることはないと主張している。これが、その主張における計算面の根拠だ。BigMacは、すべてのアクティベーションを保持できる十分なメモリを備えた仮想的なスケジュールの効率を維持しつつ、そのスケジュールで増大するメモリ使用量を回避することを目指している。

報告されたテストでは、Qwen3-30B-A3B言語モデルと13億パラメータのビジョントランスフォーマーを中心に構築された理解タスク用構成が使用された。生成ワークロードには、200億パラメータのマルチモーダル拡散トランスフォーマー生成器が追加された。

評価対象となった各ワークロードにおいて、BigMacは最短のイテレーション時間を達成したと報告されている。バッチサイズが増加してもピークメモリは安定していた一方、計算効率重視のベースラインではメモリ使用量が増加し、一部の生成設定では最終的にメモリ不足エラーが発生した。

論文では、長いシーケンスを複数のデバイスに分割するコンテキスト並列処理についても検証している。マルチモーダルの各コンポーネントでは、異なるコンテキスト並列グループサイズが有効な場合がある。BigMacの分離構成は、均一な構成と比べて最大1.45倍の速度に達したと報告されている。

別の実験では、完全シャード型データ並列処理の通信方式を変更した。完全シャード型データ並列処理は、パラメータ、勾配、オプティマイザーの状態をワーカー間に分散し、デバイス当たりのメモリ使用量を削減する。BigMacは標準的な集合型ギャザーパターンを片方向プル方式に置き換え、最大1.03倍の改善を報告した。

こうした副次的な向上幅は主要な数値レンジより小さいものの、この設計の野心を示している。BigMacは単に空きスロットへエンコーダーカーネルを挿入するだけではない。パイプラインスケジューリング、コンポーネント固有の並列処理、パラメータ移動を、単一の依存関係モデルの下で調整しようとしている。

チームは、128回のイテレーションにわたる数値検証も報告している。論文の結果によると、比較における損失の平均絶対差は0.001未満にとどまった。このテストは意味的な一貫性を裏付けるが、モデルやソフトウェア環境をまたいだ普遍的な再現性を証明するものではない。

本番運用に関する主張は公開された証拠よりも強い

BigMacの最も重要な成果はその本番規模であり、同時に外部の人々が最も容易には検証できない成果でもある。

Xiaohongshuによると、BigMacは1,536基のNVIDIA Hopper GPU上で3,450億パラメータのマルチモーダルモデルを学習した。報告された実行は18,000回を超えるイテレーションにわたって継続し、損失は減少し、勾配ノルムは一定範囲内に保たれた。

この導入により、プロジェクトはシミュレーターや小規模な実験用クラスターの段階を超えた。ネットワーク競合、ハードウェア障害、データの不均衡、集合通信を隠蔽することが難しくなるため、スケジューリングシステムは大規模環境で異なる挙動を示す可能性がある。

しかし、本番運用の証拠は依然として著者らによって管理されている。プレプリントには測定結果と実装の詳細が記載されているが、外部チームが3,450億パラメータの実行を公に再現した例はない。学習済みの本番モデルと完全な運用環境は、移植可能なベンチマークと同等ではない。

スケジューラーをオープンソース化しても、統合作業がなくなるわけではない。学習スタックには、カスタムデータローダー、チェックポイント形式、並列グループ管理、混合精度ロジック、障害復旧、監視が含まれる。依存関係の安全性を確保したスケジュールは、それらすべてと正しく連携する必要がある。

現在の設計は、適切なインターリーブ型パイプライン構造も前提としている。論文における一定のエンコーダー先読みは、仮想パイプライン並列処理に関連するスケジューリング特性に依存している。異なるパイプラインスケジュールを使用するチームは、適応なしでは同じメモリ上限を得られない可能性がある。

ワークロードのバランスも別の不確実性を生む。マルチモーダルのバッチに含まれる画像、動画、音声セグメント、テキスト長が均一であることはほとんどない。制御された形状では高密度に見えるスケジュールでも、実際のサンプルごとに必要な計算量が異なると、空き時間が生じる可能性がある。

データを考慮したパッキングは役立つ可能性があるが、パッキング自体にも制約がある。最適化の意味論を変えたり、過剰なパディングを発生させたりすることなく、サンプルを効率的にグループ化しなければならない。論文では、より広範なスケジューリング対応とデータを考慮したパッキングを今後の方向性として挙げている。

BigMacが最適化するのはシステム効率であり、モデル品質ではない。イテレーションの高速化が、推論、視覚理解、画像生成、アラインメントの向上を保証するわけではない。それによって研究者が利用可能な計算資源は増えるが、得られるモデルは依然としてデータ、目的関数、アーキテクチャ、評価に左右される。

Optimusとの比較にも同様の注意が必要だ。計算効率の高いベースラインに対するBigMacの1.08倍から1.1倍という優位性は有用だが、最大1.9倍という主要数値よりはるかに小さい。読者は、異なるベースラインに対する結果を一つの普遍的な高速化の主張として混同すべきではない。

Megatron-DistTrainに対する1.5倍から1.9倍という範囲は、別のトレードオフを反映している。このベースラインは、分離実行による安定したメモリ使用を重視している。BigMacのより大きな優位性は、少なくともテスト条件下では、ネスト型スケジューリングによって保守的なオーケストレーションで失われた性能を取り戻せる可能性を示している。

名称に関する混同の恐れもある。別の無関係なAIプロジェクトが、通信効率の高いmixture-of-expertsアーキテクチャにBigMacという名称を使用している。XiaohongshuのBigMacはマルチモーダル学習パイプラインであり、そのMoEモデル構造ではない。リリースを評価するチームは、文書やリポジトリが2026年のパイプライン論文を指していることを確認すべきだ。

したがって、独立した再現実験では、生のイテレーション時間以外も測定すべきである。信頼できる評価では、ピークメモリ、アクセラレーター使用率、通信量、収束、障害復旧、統合に必要なエンジニアリング上の変更を報告する必要がある。

また、同等の学習条件を比較すべきである。バッチ構成、アクティベーションチェックポイント、数値精度、実効トークン数を一致させる必要がある。そうしなければ、見かけ上高速なスケジュールが、実際には処理量を減らしていたり、保持する情報を少なくしていたりする可能性がある。

オープンソースでの公開により、こうしたテストは可能になるが、その結果があらかじめ決まるわけではない。BigMacを最も強く解釈すれば、異例の大規模な本番運用の証拠を伴う、企業主導のシステム成果である。最も弱く解釈すれば、Xiaohongshuのスタック外では効果が縮小する特殊なスケジュールである。

答えはおそらく、その両極端の間にある。この仕組みは具体的であり、既知のシステム上の競合に直接対処している。残る問題は、この実装が異なるアーキテクチャ、クラスター、学習フレームワークにどれほど広く移植できるかだ。

BigMacがマルチモーダル学習を変えるかを示す3つの兆候

次の段階で重要なのは、さらなる注目度の高いベンチマークではなく、採用と再現である。

最初の兆候は、OptimusおよびDistTrain形式の構成に対する独立したベンチマークである。信頼できる再現実験では、少なくとも一つの理解ワークロードと、大規模な生成器を備えた一つのワークロードを使用すべきである。また、バッチサイズの増加に応じたイテレーション時間とピークメモリを公開すべきだ。

そのテストでBigMacの安定したメモリ曲線と速度優位性の大部分が維持されれば、論文の中心的な評価はより強固になる。ソフトウェアバージョンと並列設定を揃えた後に効果が消えるなら、その結果は環境への依存性がより強いものに見える。

2つ目の兆候は、追加の言語モデル用パイプラインスケジュールへの対応である。多くの組織は、一つのマルチモーダル最適化を導入するためだけに、確立済みのスケジュールを置き換えることはできない。非インターリーブ構成、異なる仮想パイプラインサイズ、動的ワークロードとの互換性があれば、対象となるユーザー層は広がるだろう。

より幅広いスケジュールへの対応は、依存関係の安全性を確保したネスト処理が、精密に調整された本番用レシピではなく、汎用的な抽象概念であることを示すだろう。一つのパイプラインパターンに関する制約が残り続ければ、たとえXiaohongshuが社内で使用し続けたとしても、その解釈は弱まる。

3つ目の兆候は、外部の学習フレームワークやモデルプロジェクトで目に見える形で採用されることだ。保守されている統合、再現可能な構成、公開された課題履歴から、このシステムの運用がどれほど難しいかが明らかになるだろう。ダウンロード数やリポジトリへの注目だけでは、ほとんど判断材料にならない。

統合が成功したといえるためには、スケジューラーを書き直すことなく、ユーザーがエンコーダー、言語モデル、生成器の依存関係を指定できるかどうかが明らかになるべきだ。また、BigMacがチェックポイントからの復旧、不均一なバッチ、ハードウェア障害をどのように処理するかも示す必要がある。

こうした兆候が重要なのは、マルチモーダル学習が構造的により複雑になっているためだ。モデルは、ビジョンエンコーダー、言語バックボーン、拡散生成器、音声モジュール、ルーティング機構を組み合わせる傾向を強めている。ハードウェアを追加しても、これらの部分間の依存関係をなくすことはできない。

XiaohongshuがBigMacをオープンソース化したのは、効率化の取り組みが個別のカーネルからシステム全体のオーケストレーションへと移行しつつある時期である。行列乗算の高速化は依然として重要だが、アイドル状態のアクセラレーターや長時間保持されるアクティベーションによって、カーネルレベルの向上が無駄になる可能性がある。

AIインフラストラクチャチームが直ちに取るべき行動は明確だ。BigMacを保証された倍率向上ではなく、ベンチマークする価値のあるスケジューリング設計として扱うべきである。まずメモリ曲線を再現し、その後、自組織にとって重要なアーキテクチャとデータ分布の下で速度を測定する。

モデル構築者は、入力が変化してもスケジューラーが安定しているかを注視すべきだ。高解像度画像、長時間動画、理解タスクと生成タスクが混在するバッチは、均一なマイクロベンチマークよりも厳しくその前提を試すことになる。

それ以外のすべての人にとって、より大きな教訓は、将来のマルチモーダルの進歩がモデルの大規模化だけから生まれるわけではないということだ。各コンポーネントをいつ実行するか、中間状態をどこに配置するか、その状態をどれだけ速く解放できるかを厳密に決めることからも生まれる。

独立したチームはBigMacが主張するバランスを再現するのか、それとも最良の結果がXiaohongshuの本番スタックに依存していることを突き止めるのか。その答えによって、このリリースが再利用可能な学習パターンになるのか、それとも印象的ではあるものの特殊なシステム成果にとどまるのかが決まる。