なぜ推薦モデルはGPUで性能を出し切れないのか

「AI学習」と聞いて多くのエンジニアが思い浮かべるのは、大規模言語モデル（LLM）でしょう。膨大な浮動小数点演算（FLOPS）を必要とするLLMには、GPUが最適です。しかしMetaが実際に収益を生み出しているのは**推薦モデル（Recommendation Model）**です。Instagramのリール、Facebookのフィード、友達推薦——これらすべてが推薦モデルが生成する成果物です。

問題は、この推薦モデルがLLMとはまったく異なるボトルネックを抱えている点にあります。

  • **埋め込みテーブル（Embedding Table）**がモデルパラメータの99%以上を占める
  • 数百のアクセラレータ間でAllReduce、AllToAll、AllGather集団通信が毎秒無数に発生
  • 結果として演算（Compute）ではなく通信（Communication）がボトルネックになる

ここで決定的な問題が生じます。GPUではNCCLなどの通信ライブラリがGPUカーネルとして実行されます。つまり、通信のために学習演算に使うべきSM（Streaming Multiprocessor）を奪う構造になっているのです。通信と学習が同時に走ると双方が遅くなります。実際、GPUクラスタでは集団通信と大規模GEMMが重なると20%以上の演算性能低下が発生すると報告されています。

Metaはこの点で根本的に異なる選択をしました。通信を「後で処理する付加機能」ではなく、**チップ設計の一級市民（first-class citizen）**にしたのです。その成果がMTIA 300です。（詳細なシリコン設計はISCA 26論文で確認できます。）

なお、本記事の根拠資料はMeta Engineering Blogです。

Meta MTIA 300 AI accelerator chip package diagram showing integrated NIC chiplets for recommendation model training IT Technology Image

MTIA 300の核心設計：NICをチップ内部へ

1. パッケージ内蔵NIC（Network-in-Package）

MTIA 300は、ネットワークインターフェースがチップパッケージ内部に存在します。

[従来のGPUアーキテクチャ]
CPU ──PCIe──> GPU ──PCIe──> NIC ──> ネットワーク
         （ホストが仲介、ボトルネック発生）

[MTIA 300アーキテクチャ]
┌──────────── チップパッケージ ────────────┐
│  PE Grid (12×6)  │  NIC Chiplet      │
│                  │  (6× 800Gbps)     │
│  Message Engines │  NIC Chiplet      │
│  (16個, RISC-V)  │  (6× 800Gbps)     │
└──────────────────┴───────────────────┘
         PCIeバスを経由しない
  • 2つのNICチップレット、それぞれ6個のカスタム800 Gbps RDMA NICを搭載
  • 合計1.2 TB/sのI/O帯域幅をPCIeバスなしで確保
  • 従来GPUのホスト-デバイス-NICボトルネックを排除

2. 12個のイーサネットNICを柔軟に分割

同一のNICをスケールアップ（ラック内16ノード、最大1 TB/s）とスケールアウト（ラック間、200 GB/s）の両方に使用します。ハードウェアを変更せず、ネットワーク再構成のみで分割比率を調整できます。

レイテンシ最小化のためにexpress doorbellsを導入しました。work request write自体がdoorbellの役割を果たし、追加のメモリ読み取りを排除してオペレーションあたり約800nsを節約します。

3. 演算グリッドから通信を完全分離

MTIA 300は**16個の専用Message Engine（ME）**を別途搭載します。各MEは：

  • RISC-Vコア：ワークロードのオーケストレーション
  • NICインターフェース：リクエストを正しいNICへルーティング
  • NMC（Near-Memory Compute）ブロック：128 bytes/cycleでリダクション実行

NMCはHBMとキャッシュの隣、チップ端に配置され、合計2.8 TB/s以上のリダクション処理量を提供します。これはI/O帯域幅の2倍以上であり、AllReduce/ReduceScatterを演算グリッドに触れることなくline-rateで実行可能にします。

結果： 大規模GEMMと集団通信を同時実行しても演算処理量の低下は0.5%未満です。GPUの20%以上の低下と比較すると劇的な差です。

4. HCCL：コンパイル型通信モデル

Metaの通信ライブラリHCCLは、MTIA 300とゼロから共同設計されました。

# 概念的フロー（実際のAPIはPyTorch c10d/torchcommsと統合）
# 1. torch.compileで集団通信をトレース
# 2. HCCLが各集団をサブグラフにコンパイル
# 3. ワークキューエントリ配列 + 明示的依存関係でMEにディスパッチ
# 4. デバイス到達後、ホストは完全に不関与

# スケールアップ/スケールアウト帯域の非対称性を活用する
# トポロジー認識アルゴリズムを選択 → ラック間トラフィックを最小化

ホストが実行中に通信を駆動するのではなく、各集団を完全なサブグラフにコンパイルしてMEに渡せば、デバイスが自律的に実行します。

5. 本番環境での性能

  • 単一ラック内で最大940 GB/sの通信帯域幅
  • 150Bパラメータの本番推薦モデル、40アクセラレータ環境で
  • MTIA 300の総通信時間は同等GPUクラスタより3.9倍高速

HCCL communication library dispatching collective operations to message engines on MTIA 300 chip without host CPU involvement System Abstract Visual

MTIA 300 vs 従来GPUアーキテクチャの比較

項目従来GPU（NCCL）MTIA 300（HCCL）
ネットワーク位置ホスト外部NIC、PCIe経由チップパッケージ内蔵NICチップレット
通信実行主体SM（演算コア）がカーネル実行専用Message Engine 16個
リダクション処理SMリソースを共有NMCが2.8 TB/sを専任
ホスト関与実行中に継続的に関与デバイス到達後は完全自律
通信+演算同時実行時の低下20%以上0.5%未満
ラック内通信帯域モデル/トポロジー依存最大940 GB/s
スケールアップ/アウト分割ハードウェア固定ネットワーク再構成で柔軟調整

この設計の限界と注意事項

  1. 推薦モデル特化：MTIA 300は最初からranking/recommendationモデル学習に最適化されています。LLM学習のようなFLOPS中心のワークロードでは、GPUに対する優位性は限定的です。
  2. ソフトウェアエコシステムへの依存：HCCLはPyTorch c10d/torchcommsと統合されていますが、CUDAエコシステムほどの汎用性とサードパーティライブラリのサポートはまだ不十分です。
  3. ベンダーロックイン：自社チップ + 自社通信ライブラリの組み合わせは性能最適化には有利ですが、Meta外部では再現・移植が困難です。
  4. 提示数値の文脈：「3.9倍高速」は特定のワークロード（150B推薦モデル、40アクセラレータ）と特定のクラスタ構成での結果です。すべてのワークロードに一般化することはできません。

次のステップ学習方向

  • RDMAとRoCEv2：NICチップレットが使用する800 Gbps RDMAのプロトコルスタック理解
  • 集団通信アルゴリズム：Ring/Tree/Hierarchical AllReduceのトレードオフ
  • torch.compileとグラフコンパイル：HCCLが演算グラフとどう統合されるか
  • 異種学習（Heterogeneous Training）：CPUオフロードと1:1 CPU-to-accelerator比率の活用

Performance comparison chart of MTIA 300 versus GPU clusters for 150B parameter recommendation model training Dev Environment Setup

まとめ：「通信を一級市民に」という設計哲学

MTIA 300の本当のメッセージは、特定チップの性能ではありません。**「通信を後で処理する付加機能として扱わない」**というアーキテクチャ哲学です。

GPUは汎用性のために、演算と通信が同一リソースを共有する構造を選びました。この選択はLLM時代には適していましたが、推薦モデルのように通信集約的なワークロードでは明確な限界を露呈します。Metaはその限界をハードウェアレベルで解決し、その代償としてソフトウェアエコシステムの汎用性を放棄しました。

日本の開発者にとって、この事例が示す示唆は明確です。「汎用ハードウェア + 汎用ライブラリ」が常に正解とは限らないということ。ワークロードのボトルネックが明確であれば、それをハードウェアレベルで除去することが、ソフトウェア最適化よりもはるかに大きな効果を生む可能性があります。

特に推論がreasoning、agentic、long-contextへと進化するにつれ、メッセージはより小さく、より頻繁に、よりレイテンシに敏感になっています。ネットワークを「一級のシステム制約」として扱うアーキテクチャの重要性は、今後さらに高まるでしょう。

あわせて読みたい記事

参考： 本分析はMeta Engineering BlogのMTIA 300発表資料を基に再構成しました。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。