Meta OCP 2026のネットワーキング、AIクラスター全体でオープン設計を実用化
MetaはOCPにおけるネットワーキング関連プレゼンテーションを公開し、同社初の液冷ネットワークラックと、ますます分散化するAIインフラを接続するための幅広い取り組みを詳述した。Meta OCP 2026のネットワーキングは、新たなスイッチングハードウェア、トランスポートソフトウェア、共有仕様を組み合わせる。中心的な課題は、異なるサプライヤーや運用環境にまたがって、これらのコンポーネントを連携させることにある。
同社が10月26日に発表した総括は、カリフォルニア州サンノゼで10月12日から15日に開催されたOpen Compute Project Global Summitに続くものだ。そのAIネットワーキングに関するプレゼンテーションでは、Muse Wonder、Muse Spark、Prometheusスーパークラスターを支えるインフラについて説明している。これらは、あらゆる性能主張を独立して評価したものではなく、同社によるアーキテクチャの説明である。
主な緊張関係は、再利用可能なインフラと、導入ごとに固有のまま残る統合作業との間にある。NVIDIAは、この区別が重要である理由を示している。同社はMetaと協業しつつ技術を供給する一方、サプライヤーがAIシステム全体をめぐって競争する市場にも参加している。オープンなインターフェースは、その競争をなくすものではない。サプライヤーが価値を実証すべき場所を変えるものだ。
Meta OCP 2026のネットワーキングはスイッチの枠を超える
Metaの発表が重要なのは、より高速なスイッチを単独で提示するのではなく、AIインフラにおける複数の境界をまとめて扱っている点にある。
スケールアップ・ネットワーキングは、緊密に協調するシステム内でアクセラレーターを接続する。スケールアウト・ネットワーキングは、そうしたシステムをより大規模なクラスターへ接続する。スケールアクロス・ネットワーキングは、拠点間に分散したインフラ間の接続を拡張する。Metaのポートフォリオは3つの領域すべてを対象としているが、各コンポーネントの導入・開発状況は異なる。
IcePackは、Meta初の液冷ネットワーキングラックだ。そのIceCubeスイッチブレードは、1秒当たり102.4テラビットのスイッチング容量を提供し、各800ギガビット/秒で動作する128接続を備える。Metaは、Broadcom Tomahawk 6CおよびNVIDIA Spectrum-6のスイッチングシリコンを使用するバリアントを挙げている。
どちらのバリアントも、Metaのオープンソース・ネットワークオペレーティングシステムであるFBOSSを実行する。ネットワークオペレーティングシステムは、スイッチによるトラフィック転送の仕組みを管理し、運用制御を提供する。ハードウェアのバリアント間で共有ソフトウェアを利用することで、Metaは異なるサプライヤーの機器を運用するための共通の出発点を得る。
オープンネットワーキングのポートフォリオには、更新されたクラスターアーキテクチャと、Meta独自のアクセラレーター向けEthernetベース接続も含まれる。これらの発表は、議論を機器仕様からシステム設計へと広げている。
この区別は、購入者が今回のニュースをどう読むべきかを変える。スイッチで公表される容量は、機器の能力を示すものだ。それだけでは、学習ジョブがどれだけ早く完了するか、インフラがどの程度の頻度で障害を起こすか、保守にどれだけの人手が必要かは分からない。
したがって、有用な評価ではコンポーネントとその運用コンテキストを分けて考える。関連する問いには、トラフィックがどのようにスイッチへ到達するか、輻輳がどのように発生するか、容量が失われた際にアプリケーションがどう応答するかが含まれる。冷却と保守も、この評価に含めるべきだ。
スイッチのバリアントを選択する事業者を考えてみよう。共通のオペレーティングシステムは、両方の選択肢を調査する理由になる。しかし、あらゆるワークロード、ファームウェアバージョン、障害条件で互換の挙動を保証するわけではない。ある選択肢を本番環境に採用できるかどうかは、依然として検証によって決まる。
同じ考え方は液冷にも当てはまる。より高密度な機器を支えるには、施設の準備、監視、修理手順への依存が生じる。ネットワーキングチームは、建物の管理責任者から完全に切り離してラックを評価することはできない。
したがってMeta OCP 2026のネットワーキングは、協調したエンジニアリングの方向性として理解するのが最も適切だ。同社は、ネットワーキングハードウェア、ソフトウェア、物理インフラをともに進化させようとしている。公開資料は、その方向性を評価するための技術的な出発点を提供する。
ただし、それはすべての組織がMetaのアーキテクチャを再現すべきだということを示すものではない。より有用な問いは、周辺インフラが変化しても、どのインターフェースと運用慣行に価値が残るかだ。
分散AI容量が事業者とクラウドパートナーに圧力をかける
直ちに圧力を受けるのは、利用可能なアクセラレーターを信頼できる学習能力へ変換する責任を負う組織である。
MetaはPrometheusを、オハイオ州ニューオールバニ―で相互接続された複数の建物にまたがるスーパークラスターとして説明している。10月19日の説明では、初期フェーズは完了したとしている。同社は、その導入済みインフラと、並列計算に用いられるプロセッサーであるGPUを約100万台へ拡張するという目標を区別している。
この区別は、よくある誤読を避けるために重要だ。クラスターの最終的な設計目標は、現在の機器数ではない。同様に、インフラ拡張の発表は、計画されたすべてのリソースがいつ学習チームに提供されるかを示すものではない。
MetaのPrometheusインフラに関する説明によれば、第1フェーズではMuse基盤モデルを学習させた。同社は、Muse Wonderの事前学習で85%超のgoodputを報告している。goodputは、単に機器が稼働しているかではなく、有用な学習の進捗を測る指標だ。
これらの数値は、Metaが報告した運用結果である。無関係なクラスターに対する性能保証とみなすべきではない。より広い意味で重要なのは、測定対象の選択にある。設置済みハードウェアだけでなく、有用な処理が重要だ。
インフラ事業者にとって、この見方は受け入れ基準を変える。機器の可用性は必要条件だが、分散ワークロードが一貫して進行するかどうかには答えない。チームは、中断、復旧動作、コンピューティングリソースを待機させる通信遅延を理解する必要がある。
クラウドプロバイダーも関連する課題に直面する。大規模な分散ワークロードを持ち込む顧客が必要とするのは、貸し出し可能なマシンの集合だけではない。顧客には、それらのマシンを結ぶ接続全体で予測可能な挙動が必要だ。
これは双方に圧力を生む。プロバイダーは、自らの環境の制約を説明しなければならない。顧客は、ワークロードが必要とする通信パターンを明確にしなければならない。小規模な実証を、より大規模な導入の十分な証拠として扱うことは、どちらの側にも利益をもたらさない。
購入判断の例を挙げると、この問題は具体的になる。学習チームは、複数の拠点で利用可能な容量を見つけるかもしれない。それらにまたがって協調ジョブを割り当てる前に、通信オーバーヘッドが追加アクセラレーターの利点を上回るかを評価しなければならない。
答えはワークロード設計に依存する。比較的独立した部分に分割できるタスクもある。一方で、中間結果を繰り返し交換し、最も遅い参加者を待つタスクもある。利用可能なハードウェアを増やしても、その依存関係自体は解消されない。
これは、インフラの発表がAIプロダクトチームにとっても重要である理由を説明している。アプリケーション開発者がネットワークスイッチを設定することがなくても、モデルのロードマップは最終的に利用可能なコンピューティング容量に依存する。検証の遅れは、チームが実行できる実験の種類に影響する可能性がある。
企業の購入者は、この関係を根拠のない製品予測へ変換することを避けるべきだ。Metaのネットワーキングに関する開示は、将来のアプリケーション応答時間、モデルのリリース日、顧客向け提供開始時期を示すものではない。AI容量を供給するためのエンジニアリング努力を示している。
実務上の圧力は明確だ。事業者とプロバイダーは、提供しようとするシステムそのものを検証しなければならない。コンポーネント数や公称帯域幅は、そのシステムが維持すべきワークロードに関する証拠の代わりにはならない。
トラフィック判断をエンドポイントへ移すことでエンジニアリング負荷が変わる
Metaのアーキテクチャ上の方向性は、トラフィックを送信するデバイスへより多くの責任を移し、トランスポートの挙動をネットワーク設計の中心に据える。
MetaRoCEは、プロセッサーの関与を限定してマシン間でデータを交換できるリモート・ダイレクト・メモリー・アクセス向けのMetaのトランスポートプロトコルだ。同社は、広く利用されるネットワーキング技術群であるEthernet上のAIワークロード向けにこれを設計した。
MetaのAIトランスポート設計によると、MetaRoCEはパケットを複数の経路に分散し、異なる順序で到着することを受け入れる。エンドポイントは個々の経路を追跡し、輻輳や障害に対応する。
パケットを分散する設計は、ルーティングの機会だけでなく、受信側の課題も生むため重要だ。異なる遅延を持つ経路をトラフィックが通る場合、元の送信順序と到着順序は一致するとは限らない。トランスポートは、その挙動を意図的に処理しなければならない。
Metaが示すアプローチは、送信・受信デバイスに通信進行状況に関するより多くの情報を与える。同社によれば、このプロトコルは、ネットワークがロスレス性を維持するためにトラフィックを停止させる必要なく、パケットロスを許容するよう設計されている。
これらはアーキテクチャ上の主張であり、既存のトランスポートに対する普遍的な否定ではない。あるアプローチの価値は、その実装、ワークロード、運用条件に依存する。プロトコルの説明は意図した挙動を示すが、特定の実装がどう動作するかはテストによって明らかになる。
より広い仕組みとしては、責任の再配分がある。アプリケーションが必要とするあらゆる条件をネットワーク単独で維持することを期待する代わりに、エンドポイントが通信管理により積極的に参加する。これにより、経路ごとに挙動が異なる場合にシステムが対応できる手段を増やせる可能性がある。
同時に、新たな義務も生じる。エンドポイントのソフトウェアとハードウェアは、シグナルを正しく解釈しなければならない。事業者には、それらのエンドポイントが行う判断を可視化する手段が必要になる。トラブルシューティングでは、ネットワークが観測した事象とトランスポートが下した判断を結び付けなければならない。
仮に接続品質が低下した場合を考えると、この可視性が重要である理由が分かる。アプリケーションは遅くなっているものの、リンクが完全に停止しているわけではない。調査では、輻輳と機器の問題を区別し、トラフィックが影響を受けた経路から移動したかを判断する必要がある。
アーキテクチャは、選択肢を増やしても、その選択肢を容易に診断できるようにするとは限らない。Meta型のマルチパス・ネットワーキングを評価するチームは、障害発生後にどのように再構成するかを問うべきだ。設計図は、その運用上の問いに答えない。
導入の順序も考慮する必要がある。公開された仕様、ソフトウェア実装、サポートされるハードウェア実装は、それぞれ異なる到達点だ。組織は、提案された導入が実際にどの到達点に依存するのかを特定する必要がある。
ここでは、サプライヤー比較は中立的であるべきだ。NVIDIA、Broadcom、AMD、その他の参加者は、シリコン、ネットワーキングソフトウェア、システム統合能力をそれぞれ異なる組み合わせで提供する。オープンなインターフェースは実装を比較する余地を生むが、あらかじめ勝者を決めるものではない。
購入者にとって有用なのは、より精密な評価プロセスという結果だ。どの挙動が標準化されているか、どれにサプライヤー独自の拡張が必要か、どれが顧客側のエンジニアリングに依存するかを問うことができる。これは、オープンやプロプライエタリーといった大まかなラベルから選ぶよりも有益である。
エンドポイント中心の方向性は、正確性と復旧の責任主体を変えるため、重要な意味を持つ。その成否は、観測可能なアプリケーション動作、対応実装、明確な診断手順によって評価すべきである。
オープンなインターフェースにも残るプラットフォーム統合の課題
共有のフォワーディング・インターフェースがあっても、スイッチングチップ周辺の機器まで自動的に標準化されるわけではない。
Open Switch Platform Architecture（OSPA）イニシアチブは、その残された層に対応するものだ。Meta、Microsoft、Alibabaがこの取り組みを開始した。OCPは同仕様を、現在レビュー中の進行中の提案として説明しており、その位置付けを論じる際には重要な留保となる。
スイッチ・プラットフォーム・アーキテクチャは、電力管理、機器インベントリ、環境監視、ファームウェア保守、診断などの機能を対象とする。ルーティングプロトコルとフォワーディング管理は、明示された対象範囲には含まれない。
この境界こそが、今回の論点の中心である。スイッチはパケットを正しく転送するだけでは不十分だ。ソフトウェアは接続されたコンポーネントを識別し、温度を監視し、更新を管理し、障害時に有用な情報を提供しなければならない。
こうしたインターフェースが製品ごとに異なれば、別のサプライヤーの機器を採用するために追加のエンジニアリングが必要になる可能性がある。OSPAは、共通のリファレンスアーキテクチャを通じて、その作業のより多くを再利用可能にすることを提案している。
潜在的な利点は明快だ。運用者が管理ソフトウェアと手順を再利用できれば、代替機器の評価は基本的な統合の再構築に依存しにくくなる。サプライヤーは、より予測可能な運用インターフェースを公開しつつ、実装品質で競争できる。
ただし、これは市場全体で実証された成果ではなく、あくまで期待される利点にとどまる。仕様があっても、どれだけの製品が実装しているか、どの程度忠実に準拠しているか、顧客がどれほどのエンジニアリング時間を節約できるかは明らかにならない。
したがって、最も重要な懐疑的視点は実装の証拠に関わる。機器は互換性をうたっていても、重要な動作が文書化されていない場合がある。有意義な評価には、通常運用だけでなく、復旧経路、ファームウェア変更、異常条件も検証する必要がある。
たとえば、ファームウェア更新が途中で失敗した場合を考えてみよう。復旧が機能するか、どのコンポーネントが到達可能なままか、運用者にどのような情報が提供されるかが問われる。インターフェース仕様はこうした問いの枠組みを与えるが、最終的にはハードウェアが答えを示さなければならない。
これは特に混在環境で重要である。各プラットフォームで日常的な障害ごとに別々の運用手順書が必要になるなら、共通の管理モデルの価値は限られる。再利用性は初期起動にとどまらず、機器のライフサイクルを通じた保守にまで及ぶべきだ。
OSPAはMetaのより広範な戦略にも、より実務的な側面を与える。同社は、帯域幅に関する発表ほど注目されにくい作業に取り組んでいる。プラットフォーム統合は、追加のハードウェア選択肢が実際に運用可能な選択肢となるかを左右する。
これらの変化を追うエンジニアリングチームでは、文書化において意図された動作と観測された結果を区別すべきだ。適格性評価の結果を検索可能なナレッジベースに残すことで、後の比較が容易になる。
これは特に、機器、ファームウェア、仕様が異なるスケジュールで進化する場合に有用だ。以前の構成で得られた結果は、その構成へ追跡可能な状態に保つ必要がある。そうしなければ、チームはもはや適用できない前提を導入環境へ持ち込むリスクがある。
商業的な意味合いは条件付きだが、具体的である。統合と保守の作業を減らせるサプライヤーは、買い手に検討する理由を与える。買い手には依然として、その削減が実際の運用条件でも維持されるという証拠が必要だ。
Ethernetスケールアップが統合システムの境界を問い直す
MetaのEthernetスケールアップへの取り組みは設計上の境界に挑戦するが、すべてのアクセラレータシステムが同じインターコネクトを利用できることを示すものではない。
Ethernet for Scale-Up Networking（ESUN）は、密接に接続されたアクセラレータシステム向けのEthernetスイッチングとフレーミングに焦点を当てるOCPのワークストリームだ。その範囲はネットワーク動作であり、アクセラレータを取り巻くソフトウェアとハードウェアの完全なスタックではない。
OCPのEthernetスケールアップの対象範囲は、ネットワーク機能をエンドポイント機能から明確に分けている。後者には、ワークロード分割やメモリ順序付けなど、アクセラレータアーキテクチャと密接に結び付く課題が含まれる。
この区分は、取り組みへの参加から読者が推測すべき内容を限定する。ESUNを支持するサプライヤーが、すべてのアクセラレータ、通信ライブラリ、ラック設計が相互交換可能になると約束しているとは限らない。
Metaは、MTIA 300トレーニングシステム向けのEthernetベース・スイッチであるTahanを、スケールアップの方向性の一部として提示している。MTIAは、Metaが社内開発するアクセラレータのファミリーである。同社は将来の設計と継続的な標準開発についても論じている。
稼働中のシステムと将来のアーキテクチャの違いも、ここでは重要である。現在の機器は特定の実装に関する証拠を提供する。プレビューは意図された開発を示す。両者を暗黙のうちに置き換えてはならない。
NVIDIAは、この話を単純な対立構図にせずとも、有用な競争上の参照点を提供する。MetaのインフラはNVIDIA技術を利用する一方で、Metaは独自のアクセラレータも開発し、共有ネットワーキングの取り組みにも参加している。これらの関係は共存し得る。
買い手にとって重要なのは、異なる統合モデルの比較だ。緊密に協調されたシステムは、サポートされる組み合わせの確立されたセットを提供する。よりモジュール型の設計は、追加のコンポーネント選択肢を提供する一方、それらの組み合わせを検証する責任も伴う。
どちらのモデルもエンジニアリング上の制約を取り除くものではない。統合システムでも、顧客のワークロードに対する適格性評価が必要だ。モジュール型システムでも、障害がサプライヤー境界をまたぐ際には、一貫したサポート体制が必要になる。
したがって財務上の検討には、機器選定だけでなくエンジニアリング作業も含めるべきである。組織が生じる組み合わせをサポートできなければ、より広いサプライヤープールに実用上の価値は限られる。逆に、標準化されたインターフェースは、即時のサプライヤー変更がなくても価値を持ち得る。
それは買い手に、より明確な移行経路、より具体的な受け入れテスト、あるいは競合提案を比較する手段を提供できる。こうした利点は、インターフェースが顧客の必要とする動作をどれほど完全に捉えているかに左右される。
開発者にとって、その影響はスタックのより上位に現れる。通信ライブラリとワークロード配置は、アプリケーションが利用可能な接続をどれだけ効果的に使えるかを決定する。ネットワーク標準だけで、あらゆるモデルに最適な分割を選ぶことはできない。
だからこそ、Ethernetスケールアップは宣言された市場成果ではなく、エンジニアリングの経路として注目に値する。その進展は、対応システム、相互運用性の結果、ワークロードの証拠によって測るべきだ。参加発表だけでは、こうした問いに答えることはできない。
Meta OCP 2026のネットワーキングは、その経路を評価する根拠を強める。しかし、既存のシステム境界がすべて消滅したとみなす根拠にはならない。
次に注目すべきは仕様、実装、運用上の証拠
最も有用な追跡証拠は、公開された設計と、組織が自ら評価できる機器やソフトウェアを結び付けるものとなる。
第一のシグナルは仕様の進展だ。今後数カ月にわたり、OSPAのレビューとESUNの開発が、より明確な実装要件へどのように反映されるかを見守るべきである。注目すべき進展は、サポート対象の動作と準拠性に関する精度の向上だ。
改訂文書に意味があるのは、実装者が直面する曖昧さを解消する場合である。参加者のリストが増えても、それに対応する技術的貢献やサポート対象製品がなければ重要性は低い。読者は組織的な勢いと実装上の進展を区別すべきだ。
より明確な要件は、共有インターフェースが反復作業を減らせるというMetaの主張を強める。曖昧さが残れば、特にサプライヤーが同じ要件を異なる形で解釈する領域で、その主張は弱まる。
第二のシグナルは実装の可用性だ。Metaの10月の総括では、利用可能なユーザースペースのMetaRoCE実装が示され、さらなるソフトウェア作業は今後予定されるものとして説明されている。ユーザースペースのソフトウェアはオペレーティングシステムのカーネル外で動作するため、独立した実装カテゴリとなる。
利用可能なコードに、実用的なドキュメント、テスト、明確に記述された制限事項が付属するかを注視したい。リポジトリの存在は調査への招待である。広範な本番サポートと同義ではない。
追加のサポート対象実装が登場すれば、このアーキテクチャは異なる環境で評価しやすくなる。遅延や不明確なサポート境界は、基盤設計の魅力にかかわらず、外部組織が合理的に採用できる範囲を狭める。
第三のシグナルは運用上の証拠だ。構成、障害条件、復旧動作を説明するワークロード測定に注目したい。独立した評価は、企業プレゼンテーションだけでは提供できない視点を加える。
有用な証拠は、具体的な問いに答えるべきだ。接続が劣化しても、システムはアプリケーションの進行を維持できるのか。運用者は問題を特定できるのか。コンポーネントの交換には、約束されたインターフェース外の変更が必要なのか。
これらの問いに答える結果は、再利用可能なインフラの実務的な根拠を強める。大幅な導入固有の作業を示す結果は、標準化がなお不完全な領域を明らかにする。どちらの結果も、また一つのピーク性能の見出しより有益である。
エンタープライズの買い手にとって、当面の行動は評価基準を磨き直すことだ。サプライヤーには、標準化されたインターフェース、実装上の依存関係、検証で対象とした条件を明示するよう求めるべきである。利用可能な製品と将来計画を明確に区別することも求めたい。
開発者とAIプロダクトチームにとっての教訓は、発表された容量だけでなく、利用可能なインフラを追跡することだ。ネットワーキングの進展が重要になるのは、チームが信頼して実行できる実験やワークロードを拡張するときである。
公開されたアーキテクチャから始め、実装、適格性評価レポート、保守動作へと証拠を追跡しよう。実際に運用する必要があるワークロードでシステムを比較する。現行の導入環境とプレビュー、企業測定と独立した知見を分けて扱う。Meta OCP 2026のネットワーキングは、オープンAIインフラに向けた詳細な方向性を提示する。次に有用なのは、どの部分が再現可能な運用成果へと結び付くのかを検証することだ。次のサプライヤー提案や技術更新を評価する際には、具体的にこう問いたい。このシステムを導入し、稼働し続けるものにするのは、どの文書化されたインターフェース、サポート対象実装、あるいは測定済みの動作なのか。
