情報開発と利活用

令和維新

2004年4月から企業を離れ、コンサルタントや情報起業を試行しながら、失われた２０年を取り戻し、日本再生をめざす私の歩みをみて一人でも多くの後継者が出てくれることを祈りつつ友達から紹介されたこのホームページの更新を続け、これまでの活動の記録と今やビッグデータ、AI,、IOT,ブロックチェーン、仮想通貨の時代になってしまいましたが、私の現状認識と関連技術を紹介していきたい。

フォローする

UX

(0)

オンライン

(0)

ソーシャルメデイア

(0)

開発

(0)

スマートマネー

(0)

教育訓練開発手法の紹介

Headline News

Shopping List

お買いものレビューがまだ書かれていません。

< 新しい記事

新着記事一覧(全8812件)

過去の記事 >

2026.11.09

（2）SpaceXは、他のすべてのAI研究所をC言語で打ち負かした。（SpaceXは、他のすべてのAI研究所をC言語で打ち負かした。）

テーマ：人工知能(918)

カテゴリ： AI

You cannot run data parallelism across 220,000 GPUs — synchronizing gradients across that many nodes creates catastrophic communication overhead.
22万基のGPU全体でデータ並列処理を実行することは不可能である。それほど多数のノード間で勾配を同期させると、壊滅的な通信諸経費が生じる。

The AllReduce alone would serialize your training run.
AllReduceだけでも、トレーニングの実行が直列化してしまうだろう。

Tensor parallelism needs extremely high intra-node bandwidth which NVLink handles, but it breaks down cross-node because inter-node bandwidth is orders of magnitude slower.
テンソル並列処理には、NVLinkが処理する極めて高いノード内帯域幅が必要であるが、ノード間帯域幅は何桁も遅いため、ノー-ド間では破綻してしまう。

Pipeline parallelism splits the model by layers — cluster A handles the first N layers, cluster B handles the next N, data flows through like an assembly line.
パイプライン並列処理はモデルをレイヤーごとに分割する――クラスターAが最初のN層を処理し、クラスターBが次のN層を処理し、データはまるで流れ作業のコンベアベルトのように流れていく。

ノード間通信は、パイプラインのステージ間を通過する活性化の値だけであり、完全な勾配の同期よりもはるかに小規模なデータ量である。

At this scale they’re almost certainly doing 3D parallelism — data plus tensor plus pipeline combined — but the heavy emphasis on pipeline tells you where the architecture is centered. That’s the right call.
この規模では、彼らがほぼ確実に3D並列処理（データ、テンソル、パイプラインの組み合わせ）を行っているはずだが、パイプラインへの強い重点の置き方は、そのアーキテクチャがどこに重心を置いているのかを示している。それは正しい判断だ。

The 10x claim over JAX is the number everyone’s focused on and it’s actually credible when you think it through.
JAXに対する10倍という主張は、誰もが注目している数字であり、よく考えてみると実際に十分あり得る話である。

JAX is fast — it uses XLA, Google’s Accelerated Linear Algebra compiler, which fuses ops, eliminates redundant memory transfers, and compiles graphs into efficient GPU programs. XLA is genuinely impressive.
JAXは高速である。GoogleのAccelerated Linear Algebra（XLA）コンパイラを使用しており、演算の融合、冗長なメモリ転送の排除、グラフの効率的なGPUプログラムへのコンパイルを行う。XLAは本当に印象的な技術だ。

But XLA compiles for general hardware. It makes assumptions that have to hold across many different GPUs, many topologies, many workloads. SpaceX’s stack makes exactly one assumption — this specific hardware, this specific topology, this specific workload.
しかし、XLAは汎用ハードウェア向けにコンパイルする。多くの異なるGPU、多くのトポロジー、多くのワークロード全体で成立しなければならない前提条件を置いている。それに対してSpaceXのスタックが置く前提は、この特定のハードウェア、この特定のトポロジー、この特定のワークロードという、たった1つだけである。

Every optimization is made with perfect knowledge. JAX does operator fusion at compile time through compiler heuristics.
すべての最適化が、完全な知識に基づいて行われている。JAXはコンパイル時にコンパイラの経験則を介して演算融合を行う。

SpaceXは、次にどの演算が実行されるかを完全に把握した上で手動カーネル融合を行う―経験則存在せず、行列積を書いたエンジニアがその後に何が続くかを把握しているため、それに応じて融合を行うのだ。XLAは動的形状を処理しなければならない。

SpaceX’s RL workload has fixed shapes — zero inference cost, zero recompilation. Custom AllReduce over the 800G fabric instead of NCCL’s generalized collective patterns — the communication is hardcoded to the physical wiring.
SpaceXの強化学習（RL）の作業負荷は固定形状であるため、推論コストはゼロであり、再コンパイルもゼロである。NCCLの汎用的な集合通信パターンの代わりに、800Gファブリック上でのカスタムAllReduceを使用しており、通信は物理配線に対してハードコードされている。

The analogy I keep coming back to: JAX is GCC -O2. SpaceX’s stack is hand-written assembly for one specific chip by an engineer who knows every pipeline stage by name. GCC is impressive. Hand-written assembly for a known target wins.
私が何度も立ち戻る比喩はこうだ：JAXは GCC -O2 のようなものであり、SpaceXのスタックは、すべてのパイプラインステージを名前で把握しているエンジニアが特定の1つのチップ向けに書いた手書きのアセンブリ言語である。GCCは素晴らしいが、既知のターゲット向けに手書きされたアセンブリが勝利するのだ。

機械学習に携わる人々にとって、次のツイートのほうこそが正直なところ、より興味深い発表である。

“Next will be writing the inference stack in C for simultaneous high-speed RL across a large block of GB300s.”
「次は、GB300の大規模なブロック全体で高速な強化学習を同時に行うための推論スタックをC言語で記述することだ。」

Simultaneous inference and training on the same cluster. This is online RL — the paradigm that’s currently at the frontier of LLM capability development. RLHF, GRPO, anything where the model learns from its own outputs in a continuous loop.
同じクラスター上での推論とトレーニングの同時実行。これはオンライン強化学習であり、現在LLMの能力開発の最前線にあるパラダイムである。RLHF、GRPO、その他モデルが自身の出力から継続的なループで学習するあらゆる手法がこれに該当する。

The hard part of online RL at scale is that your inference engine has to generate rollouts fast enough to keep your training engine fed constantly.
大規模なオンライン強化学習の難しいところは、トレーニングエンジンに絶えずデータを供給し続けられるだけの十分な速度で、推論エンジンがロールアウトを生成しなければならない点にある。

If inference lags, training GPUs sit idle. If batch sizes drop, gradient estimates get noisy. The whole system is bottlenecked by inference throughput.
推論が遅れれば、トレーニング用のGPUが遊休状態になってしまう。バッチサイズが低下すれば、勾配の推定値にノイズが多くなる。システム全体が推論のスループットによってボトルネックに陥るのだ。

vLLM and TGI are too slow and too inflexible for this at SpaceX’s scale — they’re built for serving, not for tight inference-training co-scheduling.
vLLMやTGIは、SpaceXの規模においては遅すぎ、柔軟性に欠けている。これらはサービス（配信）向けに構築されたものであり、緊密に結合された推論とトレーニングの協調スケジューリング向けではない。

Their memory management, batching logic, and abstractions weren’t designed to be coupled to a custom training loop running on 22k GPUs.
それらのメモリ管理、バッチ処理のロジック、抽象化は、2万2千基のGPUで実行されるカスタムトレーニングループと結合されるようには設計されていなかった。

So, SpaceX is building the inference stack from scratch too. In C. Tight-coupled to the training loop.
そのため、SpaceXは推論スタックもゼロから構築している。C言語で。しかもニングループと緊密に結合させてだ。

On the same hardware. Probably sharing memory pools across both.
同じハードウェア上で。おそらく両者間でメモリプールを共有しながらだ。

DeepMind and OpenAI do this internally — the difference is SpaceX is building it in C, from zero.
DeepMindやOpenAIはこれを内部で行っている――違いは、SpaceXがそれをC言語で、ゼロから構築しているという点だ。

The big picture is this: what Google did with TPUs and XLA was hardware-software co-design optimized for one workload. Google had to design a chip, a compiler, and a runtime to get that level of tight integration.
大局的な見方をすると、GoogleがTPUとXLAで行ったことは、1つの作業負荷に最適化されたハードウェアとソフトウェアの共同設計であった。Googleはそのレベルの緊密な統合を実現するために、チップ、コンパイラ、ランタイムを設計しなければならなかった。

SpaceX got to a comparable level of integration by simply refusing to use any abstraction layer they didn’t write themselves — on hardware that already existed.
SpaceXは、既存のハードウェア上で、自分たちが書く以外のいかなる抽象化レイヤーも使用することを頑なに拒否することによって、それに匹敵するレベルの統合に到達したのである。

They gave up portability and got back 10x performance. For an organization also running xAI and training Grok, that tradeoff pays for itself on the first training run.
彼らは汎用性を手放す代わりに、10倍のパフォーマンスを手に入れた。xAIの運営やGrokのトレーニングも行っている組織にとって、そのトレードオフは最初のトレーニングランだけで元が取れるものである。

The AI infrastructure arms race is no longer just about who has the most GPUs.
AIインフラの軍拡競争は、もはや「誰が一番多くのGPUを持っているか」だけではない。

It’s about who can extract the most from the GPUs they have.
AIインフラの軍拡競争は、「自分たちが持っているGPUから、誰が最大の性能を引き出せるか」である。

Most labs won’t go this deep — it requires kernel engineers and systems programmers, not ML researchers, and any topology change means rewriting large parts of the stack.
ほとんどの研究所はここまで踏み込まないだろう。なぜなら、機械学習の研究者ではなく、カーネルエンジニアやシステムプログラマーが必要とされるし、トポロジーが変更されればスタックの大規模な書き直しが必要になるからだ。

But SpaceX is running a fixed workload on a fixed cluster training the same class of models repeatedly. The investment is completely justified.
しかし、SpaceXは固定されたクラスタ上で固定された作業負荷を実行し、同じクラスのモデルを繰り返しトレーニングしている。この投資は完全に正当化されるものである。

They cooked. For real.
彼らは本気で、とてつもないものを成し遂げた。

I am Aaryan. 19, self-taught ML guy. I write from the perspective of the person who’s actually building in the AI and ML space for the last 2 years. You can find me at @aaryan_kakad.
私はアーリアン。19歳で、独学で機械学習を学んでいる者だ。この2年間、実際にAIやMLの空間でモノづくりをしている人間の視点から執筆している。私への連絡先は @aaryan_kakad。

AI
人工知能
Artificial Intelligence
人工知能
Spacex
スペースX
Technology
テクノロジー
Tech
テック

Written by Aaryan Kakad
執筆：アーリアン・カカド

19 | self taught ML guy | building ai agents | documenting the process | sharing what I learn X: @aaryan_kakad
19歳 | 独学のMLエンジニア | AIエージェントを構築中 | プロセスをドキュメント化中 | 学んだことを共有中 X: @aaryan_kakad

==============================

インターネット・コンピュータランキング

==============================

ネットサービスランキング

==============================