クラウドを借りるな、直接所有せよ

 (blog.comma.ai)
11 ポイント 投稿者 GN⁺ 2026-02-06 | 3件のコメント | WhatsAppで共有
  • CommaAI は、すべてのモデル学習とデータ処理を自社 データセンター で実行しており、約 500万ドル規模のインフラ を自ら運用中
  • クラウド依存は コスト増加とコントロール喪失 につながる可能性があり、自前でコンピュートを運用することで エンジニアリング品質の向上 と コスト削減 が可能
  • データセンターは約 450kW の電力、600基の GPU、4PB の SSD ストレージ、シンプルな冷却およびネットワーク構成 で構成
  • ソフトウェアスタックは Ubuntu + Salt、minikeyvalue(mkv) ストレージ、Slurm スケジューラ、PyTorch 分散学習、miniray 分散コンピュートで設計
  • comma.ai はこの構成により 自動運転モデル学習を完全自動化 し、クラウド比で約 5倍のコスト削減効果 を達成

自社データセンターを運営する理由

  • クラウドに依存すると コスト増加とベンダーロックイン が発生
    • クラウド企業はオンボーディングは簡単でも、オフボーディングは難しく設計されている
    • 継続利用では高コスト構造に閉じ込められやすい
  • 自前でコンピュートを運用することは 技術的自立性と効率的なエンジニアリング文化 を促進
    • クラウドは API や課金システム中心の管理が必要だが、データセンターでは 電力・演算・帯域幅 を中心とした実際の技術課題の解決が求められる
  • ML エンジニアリングの観点でも、リソース制約がコード最適化と根本的改善を促す
    • クラウドでは単に予算を増やして解決しがちだが、自社インフラでは 性能改善が必須
  • コスト面では comma.ai は約 500万ドルを投資 し、同じ作業をクラウドで実行した場合は 2,500万ドル超 が必要だったと試算

データセンターの構成要素

  • 電力

    • 最大 450kW を使用、2025年の電力費は 540,112ドル
    • サンディエゴの電力単価は 40セント/kWh で、世界平均の約3倍
    • 今後 自家発電計画 にも言及

  • 冷却

    • 外気冷却方式 を採用し、CRAC システムより電力効率が高い
      • 48インチの吸気・排気ファン を各2基使用して空気を循環
      • PID 制御ループ で温度・湿度を自動調整（45%未満 を維持）
      • 消費電力は数十 kW レベル

  • サーバーおよびストレージ

    • TinyBox Pro 75台（合計 600 GPU）で構成、自社製造
      • 各装置は 2 CPU + 8 GPU で、学習および汎用計算に使用
      • 自社製造により 保守が容易
    • ストレージは Dell R630/R730 ベースで、総容量 4PB SSD
      • 非冗長 (non-redundant) 構成で、ノードあたり 20Gbps の読み取り速度
    • ネットワークは 100Gbps Z9264F スイッチ 3台、Infiniband スイッチ 2台 で構成

ソフトウェアインフラ

  • 基本構成

    • すべてのサーバーは Ubuntu + PXE ブート、Salt で管理
    • 単一マスター構成で 99% の稼働率 を維持

  • 分散ストレージ — minikeyvalue (mkv)

    • 3PB の非冗長ストレージ に学習用の走行データを保存
      • 1TB/s の読み取り速度 で、キャッシュなしに直接学習可能
    • 300TB のキャッシュ用アレイ、冗長保存アレイ にはモデルおよびメトリクスを保存
    • 各アレイは 単一マスターサーバー で管理

  • ジョブ管理 — Slurm

    • PyTorch 学習ジョブ と miniray 分散ジョブ をスケジューリング

  • 分散学習 — PyTorch + FSDP

    • Infiniband ネットワーク で接続された2つの学習パーティションを運用
    • 独自の学習フレームワークで トレーニングループを自動化
    • モデル実験追跡サービス を提供

  • 分散コンピュート — miniray

    • 軽量オープンソースのタスクスケジューラ で、アイドル状態のマシンで Python コードを実行
      • Dask よりシンプル で、Redis 中央サーバー によりタスクを管理
      • GPU ワーカーは Triton Inference Server でモデル推論を実行
    • 数百台規模のマシンへ並列拡張 が可能
      • 例: Controls Challenge の記録 はデータセンターを1時間使用して達成

  • コード管理 — NFS ベースのモノレポ

    • コードベース全体は 3GB 以下 で、すべてのワークステーションに複製
    • ジョブ開始時に ローカルコードとパッケージを同期 し、2秒以内 に完了
    • すべての分散ジョブが 同一コード・同一環境 で実行されることを保証

統合学習パイプライン

  • comma で最も複雑な作業は オンポリシー (on-policy) 方式で走行モデルを学習 させること
  • この学習のためには、最新のモデル重み を適用したシミュレーション走行を実行し、学習データを生成 する必要がある
  • 以下のような単一コマンドでパイプライン全体を実行可能
    • ./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
  • この学習の実行には、上で説明したすべてのインフラが使われる
  • このシンプルなコマンドひとつだけだが、複数の構成要素を協調させる役割を担っている

結論

  • comma.ai は 自社データセンター運営によりコスト削減と技術的自立 を実現
  • 同じアプローチによって 企業や個人でも自前インフラを構築できる可能性がある

関連記事

3件のコメント

 
kaydash 2026-02-06

メモリが高いんだって！
 
harryhan2435 2026-02-12

wwwwwwwwwwwwwwww
 
GN⁺ 2026-02-06
Hacker Newsの意見

  • この業界では、所有 vs クラウドがスペクトラムの両極にある
    ① クラウドは初期投資（capex）と人員負担が小さい一方、運用費用（opex） が大きく変動性も高い
    ② Managed Private Cloud は私たちの事業で、オープンソースベースで運用を代行し、AWS比で約50%安い
    ③ Rented Bare Metal はハードウェアの資金調達を代行するモデルで、AWSより90%安い
    ④ 自前で購入してコロケーションする方式は、技術力と規模があれば最も安い
    Hetzner のような事業者は3年ROIを基準に運用しており、3〜4番の選択肢は規模が大きいかインフラが中核となる企業に向いている
    スタートアップには1番、中小企業には2番が現実的 (lithus.eu)

    • 問題は、クラウドのコスト構造が単にハードウェア価格によるものではなく、複雑なアーキテクチャへ誘導されることで非効率が大きくなる点にある
      AWS の「managed サービス」は、ユーザーがサーバー効率を高めるほど AWS の収益が減る構造になっている
      単純に EC2 上に Java サーバー4台とレプリケーションDBを置くような形のほうが、はるかに効率的だ
      結局、とんでもない AWS 請求額は多数のサービスを乱用したときに発生する

    • (Carolina Cloud の derek@) 私たちも (4) のモデルを好むが、技術力が不足しているユーザーは 1〜3 にとどまり、パブリッククラウドの高コスト構造に閉じ込められがちだ
      「従量課金」と言いつつ、実際には 基本料金と最低利用料 が付くため、ずっと高くつく (carolinacloud.io)

    • Hetzner は魅力的な選択肢だ
      Postgres や VPN のようなサービスを自分で管理しなければならない負担はあるが、月1万〜1.5万ドルを超えるなら AWS より有利だ
      リスクはあるが、引き受ける価値はある

    • 私は月500ドルのベアメタルサーバーを借りているが、管理にかかる時間は年に数時間だけだ
      要件が単純だからかもしれないが、過度に複雑なクラウドよりずっと良いと感じる

    • 2年前からコロケーションへ移行し、今では30%のコストでより大きな容量を確保している
      RAM/ストレージの価格下落の恩恵も後から受けられる
      ただし コンプライアンス管理 には少し余計に気を配る必要がある

  • 昔はこういうものを単にデータセンターと呼んでいた
    クラウド以前からあった概念で、結局は 所有 vs 賃借、集中化 vs 分散化 の繰り返しだ
    企業が極端に片側だけを選ぶと、また同じ問題に突き当たる

    • 興味深いのは、クラウドが財務部門に魅力的だった理由が節税効果にあったことだ
      しかし最近の法案(OBB)により CapEx を費用処理できるようになり、オンプレミス回帰の追い風が吹いている

    • ではなぜ、価格競争力のあるクラウド代替が出てこないのか?
      AWS と Azure が市場を支配していて値下げのインセンティブがなく、Google はサービス終了リスクが大きい

    • クラウド以前は社内インフラチームがボトルネックだった
      クラウドはこれを標準化し、単一の請求体系で単純化した
      また米国外の地域ではサーバー調達が遅く、クラウドのスピード面の優位が大きかった

    • オンプレミスのデータセンターは運用負担が大きく、エンジニアリングリソースを多く消費する
      だからこの議論は何度も繰り返される

    • クラウドの本当の革新は、「サービス単位でコストを明確にしたこと」だ
      昔のように「誰に頼めばいい?」ではなく、API でアクセスできるようになった
      関連する文脈は この記事 によくまとまっている

  • サンディエゴのように温度調整がしやすい地域でも、外気冷却は危険だ
    湿気や汚染物質がサーバーを急速に傷める
    その代わり、エンタルピーホイールクーラー(kyotocooling) のような方式は効率的で、冷却効率に対して消費電力が少ない
    外気冷却は機器寿命を縮めるリスクが大きいので注意が必要だ

    • フィルタリングと湿度45%以下の維持で、かなり良い結果を得た事例もある

    • こういうことまで気にしなければならないとは知らなかった
      だから私はただクラウドを使う — こうした「知らないリスク」を避けられる

  • オンプレミスとクラウドを併用するのが現実的だ
    中核インフラは信頼できるクラウドに任せ、Slurm ジョブなどは自前サーバーで回す
    コロケーションも依然として有効な選択肢であり、研究用 HPC も検討に値する
    ノルウェーでは民間企業でも研究用 HPC を有料で利用できる

    • 私はイタリアで2地域にサーバーファームを運用していたが、スタッフ5人で管理しながらほぼ100%の稼働率を維持していた
      年間80万ユーロで、700万〜800万ユーロのクラウド費用を節約できた

    • 多くの開発者は、自分はホスティングできないと勘違いしている
      実際には思ったより簡単で、技術的な問題を解決する面白さもある

    • Equinix や Global Switch のような場所でスペースを借りれば、電力・冷却・ケーブルなどはすべて管理してくれる
      自分たちで2地域にサーバールームを持つことも十分可能だ

    • 私たちは今でもユーザー向けサービスには Azure を使っている
      GPU を必要としない Web サービスはクラウドのほうが効率的だ
      GitHub も引き続き信頼できるサービスとして使っている

    • （冗談めかして）Slurm プール内で Postgres デーモンが絡まって Rust が暴走したことがあった
      最終的には安定化したが、ハードウェアエンジニアの立場からするとソフトウェアの世界は混沌としている

  • プロジェクト初期は AWS で月250ドルから始め、月3万ドル規模になったらコロケーションへ移る
    重要なのはコスト計算能力だ — 優れたエンジニアはそれを根拠に経営陣へ提案できるべきだ

    • 単純な計算を超えて、どんな人材を惹きつけ、どんなビジネスを作りたいのかも考慮すべきだ
      ML モデルを学習する会社なら、自前インフラのほうが適しているかもしれない

    • しかし大半の会社では、エンジニアはプラットフォーム選定に関与できない
      経営陣がすでに決めていて、あとから通知されるケースが 99.999999% だ

  • キャリア初期にはクラウドが当然の選択だったが、今ではオンプレミスが再び流行している
    10年後にはまた逆の流れが来るかもしれない

    • 私の経験では、オンプレミスを推していたチームはいつも保守の疲弊を過小評価していた
      スタートアップのように迅速な開発が必要な場所では、むしろ足かせになる
      一方で、保守モードに入った会社ではオンプレミスは効率的だった
      年齢を重ねるほど「早く、予算内で終わらせること」が重要になり、自前でインフラを運用する魅力は薄れていく

    • 今回の流れは単なる技術サイクルではなく、「所有できない社会」への反発だと見ている
      音楽、家、車まですべてがサブスクリプションモデルになる中で、企業もコンピューティング主権を取り戻そうとしている動きがある

    • こうした循環は昔からある
      メインフレーム → PC → サーバールーム → クラウド → エッジコンピューティングへと続く 集中化 ↔ 分散化の反復 だ
      結局、技術と優先順位が変わればまた揺り戻しが起こる
      「ネットワークこそコンピューターだ」という言葉がまた出てきたら、もう一周したということだ

    • （冗談）次はたぶん スペース（スカイネット） の段階かもしれない

  • 多くの企業がオンプレミスを避ける理由はリスク管理にある
    優れた企業はリスクを中核競争力に集中させる
    単なるコストではなく、リスク調整後コストで判断すべきだ

    • しかし最近は、企業がそのリスクを正確に評価する能力を本当に持っているのか疑わしい
      価格競争力も結局は差別化要素の一つだからだ

    • 要は本業に集中することだ
      売れない製品をもっと売れるようにしてくれるのでなければ、データセンターに時間を浪費すべきではない
      Google のようにインフラ自体が製品競争力である場合だけが例外だ

    • 結局のところ、Opex が Capex に勝つ戦いであることが多い

  • オンプレミスの本当の利点は自由、制御、プライバシーだ
    単なる金の問題ではなく、家を所有するか賃貸するかの問題に近い

    • ただし原文でもコストは最後の項目として扱われており、それ以外の利点こそが核心だ

  • 2010年代の MBA 的な教義は「すべてをクラウドに移せ」だった
    リスクとコストを第三者に移すのが正解だと見なされていた
    しかし実際には自社データセンターのほうがはるかに安く、ソフトウェアサブスクリプション料の値上がり率はハードウェアよりずっと高かった

    • もちろん AWS は世界中に冗長化されたデータセンターを持っており、信頼性は異なる
      しかしそのぶん人件費や管理費も考えれば、単純なコスト比較は無意味だ
      竜巻ひとつで会社が吹き飛ぶこともあり得るのだから、結局は リスクに対する価値 で判断すべきだ