クラウドを借りるのではなく、自分で所有してください。

Summary

Comma.aiは、完全に社内で自動運転研究を実施するオンプレミスデータセンターを構築し、同等のクラウド容量に対して2500万ドル以上の資本支出を約500万ドルに削減しました。施設は約450kW（サンディエゴの電力単価40¢/kWhで年間約540kドル）を消費し、外気冷却と48インチの吸入／排気ファン、および湿度を45％以下に保つ再循環ファンを使用しています。

コンピューティングは75台の社内TinyBox Proマシン（各2CPU＋8GPU）に分散された600GPUで構成され、Dell R630/R730ストレージサーバーが約4PBのSSDを保持します。ネットワークは3つの100Gbps Z9264Fスイッチと2つのInfiniBandスイッチによって処理され、TinyBoxグループ間でAll‑Reduceトレーニングを可能にしています。

ストレージアーキテクチャには、原始的な運転データ用の3PB非冗長「mkv」アレイ（約1TB/s読み取り速度）、約300TBのキャッシュアレイ、およびモデルとメトリック用の冗長mkvアレイが含まれます。ジョブオーケストレーションはSlurmで行われ、分散トレーニングはPyTorchのtorch.distributed FSDPをInfiniBand上で使用します。カスタム実験追跡サービス（「reporter」）はモデル重み（UUID）とメトリックをmkvストレージに保存し、軽量スケジューラ「miniray」はRedisでサポートされるアイドルマシン上で任意のPythonコードを実行し、Tritonサーバーによる推論を支援します。

全コードベースは3GB未満のモノレポとして存在し、NFSキャッシュ経由ですべてのワーカーにクローンされます。UVはジョブごとに約2秒でパッケージを同期します。オンポリシー運転モデルトレーニングは実際の走行中にデータを生成し、単一のシェルスクリプトがフルパイプラインをトリガーすることでオーケストレーションされます。このインフラは数名のエンジニアと技術者だけで維持されており、Comma.aiがクラウド依存よりも自己完結性に重きを置いていることを示しています。

最近では、自分のデータセンターを持つために十兆ドル相当の偽造通貨や政治家とのランチが必要になっているようです。助けになるかもしれませんが、必須ではありません。コマ（comma.ai）では数年前から自社でデータセンターを運用しています。モデル学習・メトリクス・データはすべて自社オフィスにある独自の施設内にあります。自分だけのデータセンターを持つことはかっこいいものですし、この記事では私たちがどのように運用しているかをご紹介しますので、皆さんもぜひ参考にしてください。

私たちのデータセンター ― なぜクラウドを使わないのか？

ビジネスがコンピューティングに依存し、その計算をクラウドで行う場合、プロバイダーへの信頼は大きくなります。クラウド会社はオンボーディングをとても簡単にしますが、オフボーディングは非常に難しいです。注意深くないと、高コストへスリープウォークで入り込んでしまい、抜け出せなくなる恐れがあります。
自分の運命をコントロールしたいなら、自前で計算を行う必要があります。

自己依存は素晴らしいことですが、他にもメリットがあります：

エンジニアリングへのインスピレーション – データセンターを維持することで、会社のAPIや請求システムをマスターするだけでなく、実際の問題（ワット数・ビット数・FLOPs）に対処しなければならなくなります。
エンジニアへのインセンティブ – クラウドでは改善は単純に予算を増やせば済みますが、オンプレミスの計算ではコードを高速化したり根本的な問題を解決することで最速で成果が得られます。
コスト優位性 – データセンターを所有する方がレンタルよりもはるかに安くなることがあります。コマのケースでは、独自データセンターに約 5 百万ドル（$5 M）投資しましたが、同じ規模でクラウドを利用すれば推定 25 百万ドル以上になると見積もられています。

必要なものは何か？

私たちのデータセンターはシンプルで、数名のエンジニアと技術者だけで構築されました。以下の実装例は参考情報として役立つはずですが、ご自身のニーズに合わせて調整してください。

電源

容量：最大約 450 kW
費用：サンディエゴでは電気代が $0.40/kWh（世界平均の3倍）を超えます。2025年に電力コストで $540,112 を支払いました。
将来計画：自家発電を行う予定です（詳細は別記事で）。

冷却

戦略：サンディエゴの穏やかな気候を活かし、純粋な外部空気冷却。
機器：ダブル48インチインテークファンとダブル48インチ排気ファン。
湿度管理：リサーキュレーティングファンが熱い排気を取り込み、再混合します。1台のサーバーはPIDループで温度と湿度（RH < 45%）を最適化しています。

サーバー

計算：600 GPU を 75 台の TinyBox Pro に搭載（各台 2 CPU + 8 GPU）。社内開発でコスト効果が高く、修理も容易です。
ストレージ：Dell R630/R730 ラックに SSD を装備し、合計約 4 PB。冗長性はありません。各ノードはネットワーク帯域幅を飽和させます（80 TB チャンクで最大 20 Gbps）。
その他サービス：ルーター、気候制御装置、データ取り込みマシン、ストレージマスターサーバー、メトリクスサーバー、Redis サーバーなど。

ネットワーク

メインイーサネットには 3 台の 100 Gbps Z9264F スイッチを使用。
2 台の Infiniband スイッチで TinyBox Pro グループ間を相互接続し、全削減（all‑reduce）トレーニングを実現します。

ソフトウェアスタック

この規模ではサービスが 99 % の稼働時間を達成するために冗長性は必要ありません。すべてのサービスで単一マスターを使用し、管理を簡素化しています。

設定

すべてのサーバーは PXE ブートで Ubuntu を取得し、Salt で管理します。
分散ストレージ：
```
mkv
```
（minikeyvalue）を採用。
- メインアレイ：3 PB の非冗長 – 約 1 TB/s の読み取り速度。
- キャッシュアレイ：約 300 TB の非冗長で中間結果を保持。
- 冗長アレイは学習済みモデルとメトリクスを格納し、各アレイには独自のマスターサーバーがあります。

ワークロード管理

Slurm が計算ノードとジョブを管理し、PyTorch トレーニングや Miniray ワーカーをスケジューリングします。
分散トレーニング（PyTorch）：
```
torch.distributed
```
+ FSDP を使用。2 つの独立したトレーニングパーティションが Infiniband 経由で接続されます。
実験追跡：WandB/TensorBoard に似たカスタムサービスを構築。ダッシュボードでメトリクスとレポートを表示します。モデル重みは mkv アレイに UUID 付きで保存し、簡単にダウンロードできます。

分散計算（Miniray）

軽量オープンソーススケジューラが任意の Python コードをアイドルマシン上で実行し、並列タスク実行を簡素化。
Slurm がアイドルマシンを Miniray ワーカーとしてスケジュールし、タスクは中央 Redis サーバー経由で調整されます。
Miniray ワーカーは Triton 推論サーバーを起動してモデル推論のダイナミックバッチングを行います。

コードリポジトリ

すべてのコードは 3 GB 未満のモノレポにあり、ワークステーションでクローンされます。
トレーニングや Miniray ジョブが開始するとき、ローカルモノレポは共有 NFS にキャッシュされ、すべてのワーカー間でコードと Python パッケージを揃えます。同期には約 2 秒かかります。

全体像

最も複雑な操作は「オンポリシー」ドライビングモデルのトレーニングです。この運用では、最新のモデル重みでシミュレーション走行を実行しながらトレーニングデータを生成します。単一コマンドでインフラ全体をオーケストレーションできます。

./training/train.sh \
  N=4 \
  partition=tbox2 \
  trainer=mlsimdriving \
  dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt \
  vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 \
  data.shuffle_size=125k \
  optim.scheduler=COSINE \
  bs=4

これにより、上記で説明したコンピューティング・ストレージ・ネットワーク・ソフトウェアスタックを活用したフルトレーニングパイプラインが起動します。

こんなことに興味がありますか？
もしこの内容が刺激的に感じられたら、ぜひ自分や会社のためにデータセンターを構築してみてください！また、一緒に働くことも可能です。

Harald Schäfer – CTO @ comma.ai