22万個のGPUを使い切る：SpaceXがAIスタックを「純粋なC言語」で構築した理由

2026年6月8日 H.Ueda

先日、SpaceX just COOKED every other AI lab. With C. という刺激的な記事を読みました。大規模なAIインフラを支える技術のあり方について、ハードウェアに近い低レイヤーの視点から非常に考えさせられる内容だったので、こちらでポイントを整理してみたいと思います。

これ凄いですよね。まるで昔の職人芸的プログラミングですね。ちょっと興味あるなぁ。

AI開発といえば、PyTorchやJAXといったPythonベースのフレームワークを使うのが一般的です。しかしSpaceXは、独自の学習スタックを「純粋なC言語」で書き上げたとされています。なぜ彼らは、あえてモダンなフレームワークを避けて、古典的とも言えるC言語を選んだのでしょうか。

既存フレームワークが抱える「抽象化の代償」

現在のAI開発のデファクトスタンダードは、C++やCUDAで書かれたコアライブラリの上に、Pythonのインターフェースを被せる構成です。開発効率は非常に高いのですが、その分、計算資源を極限まで使い切ろうとすると無視できないオーバーヘッドが発生します。

SpaceXが懸念したのは、以下のようなコストだと思われます。

要素	発生するコスト・課題
Python GIL	グローバルインタプリタロックにより、マルチスレッド実行が制限される。
インタプリタの遅延	オペレーションを呼び出すたびに発生するわずかなラグ。
C++の抽象化	仮想関数テーブル（vtable）のルックアップや例外処理の仕組み。
動的なスケジューリング	NCCLなどが実行時にトポロジーを推測する際の不確実性。

数個から数百個のGPUを動かす程度なら、これらは「誤差」かもしれません。しかし、SpaceXが構築しているのは22万個のBlackwell Ultra（GB300）という、桁外れの規模のクラスターです。この規模になると、わずかなオーバーヘッドが積もり積もって、システム全体のボトルネックになってしまいます。

カーネルエンジニアとしての最適化

SpaceXのエンジニアたちは、自らを「MLエンジニア」ではなく「カーネルエンジニア」として定義しているようです。抽象化されたライブラリを使いこなすのではなく、ハードウェアを直接制御する道を選んだということです。

純粋なC言語を採用することで、以下のような要素をエンジニアが完全にコントロールできるようになります。

メモリレイアウトの厳密な設計
キャッシュラインのアライメント
プリフェッチ（データの事前読み込み）のヒント
物理トポロジーに最適化された通信パス

「厳密なマッピング（Exact-maps）」という考え方

記事の中で特に興味深いのが、Exact-mapsという表現です。通常、NCCL（NVIDIA Collective Communications Library）などのライブラリは、実行時に最適な通信経路を「推測」して構築します。

しかしSpaceXは、ハードウェアの物理的な接続（トポロジー）をソフトウェア側で完全に把握し、それをコードにハードコードしているようです。ソフトウェア上の論理的な構造と、シリコンの物理的な配置を1対1で対応させることで、推測に伴う無駄を一切排除しているわけです。

22万個のGPUを支える並列化戦略

22万個のGPUという規模は、GPT-4の学習に使われたとされるA100（約2.5万個）の約9倍に相当します。これほどの規模になると、単純なデータ並列（Data Parallelism）では通信量が爆発し、学習がまともに進みません。

そこで彼らが重視しているのが、パイプライン並列（Pipeline Parallelism）です。

flowchart LR
    subgraph Cluster_A[クラスターA]
        L1[レイヤー1-N]
    end
    subgraph Cluster_B[クラスターB]
        L2[レイヤーN+1-M]
    end
    subgraph Cluster_C[クラスターC]
        L3[レイヤーM+1-K]
    end

    Input --> Cluster_A
    Cluster_A -- アクティベーション --> Cluster_B
    Cluster_B -- アクティベーション --> Cluster_C
    Cluster_C --> Output

このようにモデルを層（レイヤー）ごとに分割して、工場のアセンブリラインのようにデータを流します。この手法の利点は、ノード間でやり取りするのが「アクティベーション（活性化値）」だけで済む点です。全GPU間で重みの勾配を同期させるAllReduceに比べると、通信負荷を劇的に抑えることができます。

おそらく実際には、データ並列、テンソル並列、パイプライン並列を組み合わせた「3D並列」を駆使しているはずですが、その中心にパイプライン並列を据え、C言語で各ステージを厳密に制御している点が、JAXに対して10倍高速という主張の裏付けになっているのかもしれません。

まとめ

SpaceXの事例は、汎用的なフレームワークがいかに便利であっても、究極のパフォーマンスを求める局面では「ハードウェアを直接叩く」という泥臭い最適化が最強の武器になることを示しています。

もちろん、すべての開発者がC言語でAIを書くべきだという話ではありません。しかし、マイクロアーキテクチャの性能を引き出すという観点では、以下のようなアプローチが改めて重要になるかと思います。

抽象化のレイヤーを疑ってみる：Pythonの裏側で何が起きているかを把握する。
物理構造を意識する：GPUの接続トポロジーやキャッシュの特性に合わせたコードを書く。
カーネルエンジニアの視点を持つ：ライブラリの利用者ではなく、ハードウェアの制御者として考える。

JAXより10倍速いという数字は、一見すると信じがたいかもしれませんが、22万個という極限環境においては、ソフトウェアがハードウェアのポテンシャルを「邪魔しない」こと自体が、最大の加速要因になるのではないでしょうか。

MicroArchitectures

H.Ueda

Programmer

ブログ