Google Project Suncatcherの打ち上げ、AIコンピューティングは軌道上で生き残れるかを検証

Googleは10月1日、4基のTPUチップを軌道上へ送る。これによりGoogle Project Suncatcherの打ち上げは、研究提案から実機を用いた実験へと移行する。冷蔵庫ほどの大きさのMVP衛星は、SpaceXのライドシェアミッション「Transporter-18」に搭載される。見慣れたAIハードウェアが、打ち上げ時の衝撃、放射線、そして空気のない環境での冷却に耐えられるかを検証する。

このミッションを過大評価するのは簡単だ。MVPは稼働中の軌道上データセンターではなく、4基のプロセッサで地上のAIクラスターを再現することもできない。Googleの実験はより限定的で、同時により重要な問いを扱う。商用AIアクセラレータは、本来設計された環境の外でも信頼性を保って動作できるのか、という問いだ。

この違いこそが中心的な緊張関係を生む。宇宙には豊富な太陽エネルギーがあり、地上特有の制約も少ない一方で、現代のアクセラレータを稼働させ続けるインフラが存在しない。Googleは、利用しやすい電力と引き換えに、困難な熱管理、高額な展開コスト、限られた修理手段、打ち上げ事業者への依存を受け入れなければならない。

SpaceX、Starcloud、Aetherfluxなどの事業者も、関連する構想を模索している。Googleには、カスタムチップ、分散コンピューティングの専門性、そして巨大な地上システムを直接運用してきた経験という異なる強みがある。一方で弱点も明白だ。軌道上コンピューティングを経済的に成立させるためのロケットを、同社は管理していない。

Google Project Suncatcherの打ち上げはハードウェアの生存試験

10月1日のミッションが検証するのは、GoogleのAIチップが軌道上で生き残れるかであり、軌道上データセンターがすでに機能するかではない。

Googleは9月24日、Project Suncatcher初のプロトタイプをSpaceXのTransporter-18ミッションで打ち上げると発表した。打ち上げはカリフォルニア州のヴァンデンバーグ宇宙軍基地から予定されており、宇宙機は低軌道へ投入される。

MVPと呼ばれるこのプロトタイプには、Planetが提供する衛星プラットフォームが使われている。Googleは、機械学習計算向けに設計された専用プロセッサであるTensor Processing Units、すなわちTPUを4基統合した。公開されたMVP specificationsによると、太陽光パネルの出力は約1キロワットだという。

この電力予算には厳しい制限がある。報道によれば、衛星は蓄積した熱を放出するために停止するまで、AIハードウェアを約15分間稼働できる。地上のサーバーはファン、液冷、冷水、安定した電力供給を利用できるが、MVPにはこうした補助設備がない。

その代わり、この実験ではチップが3つの過酷な段階にどう反応するかを測定する。まず打ち上げ時の振動と加速度にさらされる。次にプロセッサは放射線を受けながら動作しなければならない。最後に、冷却システムは真空中で高密度に集積された電子機器から熱を逃がす必要がある。

Googleによれば、ロケットでの飛行は約10分間続き、宇宙機には地球重力の10倍に達する持続的な荷重がかかる。個々の部品には重力の50倍から100倍の力が加わる可能性がある。エンジニアは飛行前に衛星を3軸方向に振動させ、こうした条件を再現した。

同社はまた、カリフォルニア大学デービス校の陽子ビーム施設でTrillium TPUを試験した。陽子への曝露は、蓄積放射線量や、保存データを変化させるビット反転を含むシングルイベント効果を研究するのに役立つ。

Googleは、最高線量の試験中に、蓄積放射線に起因する恒久的な故障は確認されなかったと報告した。ただし、地上試験ではすべての軌道上条件を再現できない。放射線は異なる発生源から到来し、部品温度も変化し、故障は予想外の形でソフトウェアと相互作用する可能性がある。

したがって、最初のGoogle Project Suncatcher打ち上げがもたらすのは、決定的な結論ではなく運用上の証拠となるはずだ。チップが動作することは最初の節目にすぎない。将来のコンピューティングサービスにとっては、信頼できるワークロード、予測可能な障害復旧、再現性のある熱サイクルの方がはるかに重要である。

MVPはGoogleの当初スケジュールも変える。Project Suncatcherは当初、2027年に2基のプロトタイプ衛星を打ち上げる計画だった。Googleは、既存のPlanet宇宙機に自社プロセッサを搭載することで最初のハードウェア試験を前倒しし、ペア衛星によるミッションは後のネットワーク実験用に維持している。

このアプローチは10月のミッションを限定する一方、Googleに早期の回答をもたらす。MVPが熱、放射線、電力の問題を明らかにすれば、エンジニアは大型プロトタイプの打ち上げ前に設計を見直せる。良好な性能を示せば、標準的なアクセラレータ設計に必要な改修は懐疑論者が予想したより少ないという証拠をGoogleは得ることになる。

Googleが送電網の上にAIインフラを求める理由

Project Suncatcherは最終的に、地上でのAI拡張を取り巻く物理的制約への対応策である。

現代のAIシステムには、長時間にわたって稼働する大規模なアクセラレータクラスターが必要だ。こうしたクラスターには、電力、冷却設備、ネットワーク容量、土地、変圧器、送電インフラへの接続が求められる。どれか一つでも、新しいデータセンターへの最初のサーバー搬入を遅らせる可能性がある。

宇宙が魅力的に映るのは、気象や大気による損失なしに、太陽光が軌道上の太陽電池アレイに届くためだ。適切な太陽同期軌道では、衛星は長時間の日照を得られる経路を進む。Googleは、軌道上のパネルは地上の同じパネルと比べて最大8倍のエネルギーを生み出せると見積もっている。

この比較が、宇宙を自動的に効率的な選択肢にするわけではない。衛星は、プロセッサ、ラジエーター、太陽光パネル、光通信端末、構造材、遮蔽部品のすべてを打ち上げで運ばなければならない。いったん展開されれば、故障した機器に従来型データセンターのような日常的な修理を施すことはできない。

それでも太陽エネルギーの優位性が、Googleがこの構想を検証する価値があると考える理由を説明している。地上のAI施設建設は、送電網容量、水消費、バックアップ発電、土地利用を懸念する電力会社、規制当局、地域社会から圧力を受けている。軌道上システムは、こうした対立の一部を移転することになる。

ただし、環境コストをなくすわけではない。衛星の製造と打ち上げにはエネルギーと資材が消費される。大規模コンステレーションは混雑、衝突リスク、大気圏再突入に関する懸念を増やす。利用者とデータソースの大半は地球上に残るため、地上局と地上ネットワークも引き続き必要となる。

遅延もまた、どのワークロードを軌道上で扱うべきかを左右する。対話型サービスでは、プロンプトと応答を利用者、地上局、衛星の間で移動させる必要がある。学習ジョブには、計算開始前に膨大なデータ転送が必要となる。衛星画像の処理のように宇宙で発生するタスクは、より直接的に適合する。

衛星は、結果を地球へ送る前にセンサーデータを解析できる。これにより、帯域に制約のあるダウンリンク経由で、すべての生画像や測定値を送る必要が減る。また、航行、監視、科学観測に関するより迅速なローカル判断を宇宙機に与えることにもなる。

Project Suncatcherは、こうしたエッジコンピューティングの用途を超えることを目指している。Googleが掲げる目標は、接続されたデータセンターのように振る舞う衛星クラスターによる、スケーラブルな機械学習システムだ。その実現には、異なる宇宙機に搭載されたプロセッサが、地上インフラに匹敵する速度でデータを交換する必要がある。

この構想が野心的なのは、現在のAIクラスターが緊密に統合されたネットワークに依存しているためだ。アクセラレータはモデルパラメータや中間結果を繰り返し交換する。接続が遅ければ、高価なプロセッサが待機状態となり、クラスター全体で得られる有効な作業量が減少する。

Googleが検証しているのは、単にサーバーの新たな設置場所ではない。太陽光、軌道運動、レーザーリンク、放射冷却を軸に、AIデータセンターを支える物理的前提を再構築できるかを探っている。

10月の飛行が扱うのは、この仮説のうちハードウェア生存性だけである。たとえ結果が完璧でも、ネットワーク、打ち上げ経済性、保守、大規模な軌道制御については結論を出せない。より大きなアーキテクチャが技術的に妥当であり続けることを示すにとどまる。

軌道上AIはレーザーと編隊飛行に依存する

決定的な要素はTPU単体ではなく、移動する宇宙機をまたいで多数のプロセッサを接続するネットワークである。

Googleが公開したtechnical paperは、自由空間光通信で接続された太陽光発電衛星群について説明している。こうしたレーザー接続は、すべての交換を地球経由で中継するのではなく、宇宙機間で直接データを送ることになる。

自由空間光通信は、物理的な光ファイバーを使わず、指向性のある光で情報を伝送する。高帯域幅を実現できる可能性があるが、両端が軌道速度で移動する間も端末は位置合わせを維持しなければならない。わずかな照準誤差でも接続は切断されうる。

Googleは、分散AIワークロードには毎秒数十テラビットを伝送するリンクが必要になると見積もっている。同社の実験室デモ機は、1対のトランシーバーを通じて各方向に毎秒800ギガビットを伝送した。これは双方向合計で毎秒1.6テラビットの容量に相当する。

実験室での結果には意味があるが、軌道上での移動を再現するものではない。試験ベンチでは距離を制御でき、位置合わせも安定している。衛星は振動、熱による歪み、放射線、空気抵抗、軌道のわずかな差異にさらされる。

Googleが提案する解決策は、コンパクトな編隊である。研究者らは、高度650キロメートルで半径1キロメートル以内に81基の衛星を配置する例示的なクラスターをモデル化した。隣接する宇宙機間の距離は、わずか数百メートルにとどまる。

距離が短いほど、分離距離の増加に伴って受信信号が急速に弱くなるため、高帯域幅の光リンクを実現しやすい。近接編隊は運用の複雑さも増す。各衛星は自身の位置を把握し、複数の近隣衛星と安全な距離を維持しなければならない。

システムには継続的な航法、故障検出、衝突回避が必要となる。スラスターの故障や位置推定の誤りは、隣接する機体を危険にさらしかねない。クラスターが数十基の密集した衛星で構成される場合、このリスクは高まる。

2027年のミッションは、このネットワーク問題をより直接的に検証するために設計されている。GoogleとPlanetは、宇宙機間の光通信を実証できる2基のプロトタイプを展開する予定だ。将来の衛星には、MVPの4基ではなく数十基のTPUが搭載される。

Planetは、Project Suncatcherが次世代Owl衛星プラットフォームに関連する技術を利用していると明らかにした。同社のpartnership disclosureによると、この協業は、そのプラットフォームに関連する開発を支援するとともに、宇宙でのスケール可能なAIコンピューティングを探るものだという。

この提携により、Googleは確立された宇宙機エンジニアリングを利用できる。Planetは衛星群の運用、地上通信の管理、地球観測データの処理に関する経験を持つ。Googleはアクセラレータ、機械学習ソフトウェア、分散システム研究を提供する。

しかしこの提携は、軌道上データセンターにどれほど多くの組織が必要となるかも浮き彫りにする。Googleはコンピューティングハードウェアを提供する。Planetは宇宙機プラットフォームを提供する。SpaceXは最初の軌道投入手段を提供する。さらに光学、熱、電力、地上システムを支える追加のサプライヤーも必要となる。

地上のデータセンターもサプライチェーンに依存しているが、技術者は故障したスイッチ、ドライブ、ポンプ、電力設備を交換できる。軌道上では、冗長性を打ち上げ前に設計しておかなければならない。物理的なアクセスが不可能なため、ソフトウェアによる復旧が不可欠となる。

これは、信頼性の定義を変える。衛星では、すべての部品が永遠に動作し続ける必要はない。損傷したノードを隔離し、エラーを訂正し、障害を迂回してワークロードを再配置しながら、コンステレーション全体として有用な計算を継続できなければならない。

この設計は、個々のマシンが定期的に故障する大規模クラウドシステムに似ている。違いは交換までにかかる時間だ。クラウド事業者は既存施設内に別のサーバーを設置できる。一方、軌道上の事業者は、別の宇宙機を製造し、スケジュールし、打ち上げ、運用を開始しなければならない。

Project Suncatcherは、分散ソフトウェアがその遅延を吸収できることを証明しなければならない。さもなければ、打ち上げで回復するまで、障害が発生するたびにコンステレーションの容量は徐々に低下していく。

SpaceXが経済的な圧力点を握る

Googleはコンピューティングシステムを設計できるが、そのアーキテクチャを実験段階から前進させられるかは打ち上げへのアクセスで決まる。

MVPはライドシェア・ペイロードとして飛行する。つまり、複数の顧客が1機のロケットを共有する。このモデルにより、ロケット全体を購入せずに小規模な実証を行える。しかし、大規模なコンピューティング・コンステレーションを配備するための経済的な道筋を確立するものではない。

将来のクラスターには、プロセッサ、ラジエーター、光通信端末、広い太陽電池アレイが搭載される。各コンポーネントは質量を増やす。質量が増えれば、より大きな打ち上げ能力が必要になり、専用配備はロケットの利用可能性と軌道投入精度への依存を高める。

SpaceXはこの方程式で特異な立場にある。自ら宇宙ベースのインフラを開発しながら、軌道上コンピューティングを目指す企業に打ち上げを販売できる。Starlinkはすでに、衛星を大規模に製造、打ち上げ、ネットワーク化、交換する経験をSpaceXにもたらしている。

この垂直統合はGoogleに圧力をかける。GoogleはTPUの設計を保有し、大規模なAIサービスを運営しているが、社内の打ち上げシステムを持たない。SpaceXは衛星設計をロケット能力と連携させ、両事業にまたがって知見を再利用できる。

競争構図は2社だけにとどまらない。Starcloudはすでに軌道上でコンピューティング・ハードウェアを飛行させている。Aetherfluxは宇宙ベースの処理に関する計画を公表している。Blue Originなどの打ち上げ事業者も、データ集約型の軌道上インフラをめぐる需要の出現を見込んでいる。

こうした活動は、軌道上AIが商業的に成立することを証明するものではない。複数の企業が、エネルギーおよびインフラ上の制約を実験に資金を投じるほど重大だと考えていることを示すものだ。各社のアプローチは、規模、ワークロード、打ち上げアクセス、想定顧客の面で異なる。

この違いをめぐっては、すでに業界内の競争が形成されている。打ち上げ事業者は配備コストを内部化し、系列プロジェクト向けに能力を確保できる。ロケットを持たない企業は、潜在的な競合相手とアクセスを交渉しなければならない。

Googleの最も強力な対応策は専門化だ。TPUは機械学習専用に設計されており、Googleはそれを取り巻くソフトウェアスタックを管理している。汎用システムを適応させるのではなく、モデル、コンパイラ、ネットワーク、障害復旧を一体で最適化できる。

この優位性が意味を持つのは、打ち上げと宇宙機のコストが十分に下がった場合だけだ。Googleの研究は、将来の配備について積極的な前提を置けば、軌道上コンピューティングが地上のエネルギー経済性に近づけると主張している。そうした前提は、実際に観測された運用結果ではなく、依然として予測にすぎない。

比較は、何をコストに含めるかにも左右される。地上のデータセンターには、送電網への接続、冷却、建物、保守が必要だ。軌道上のクラスターには、打ち上げ、宇宙機製造、交換ミッション、地上局、衝突回避、廃棄が必要になる。

稼働率もまた決定的な変数となる。データセンターは、高価なプロセッサを稼働させ続けることで価値を生み出す。熱的制約によって長時間の冷却停止が必要になれば、軌道上アクセラレーターの実際の仕事量は、公称能力から想定されるより少なくなる。

MVPで報告された15分間の稼働ウィンドウは、この問題を示している。このミッションは意図的に小規模な実験であり、そのデューティサイクルは商用システムを予測するものではない。それでも、投資家とエンジニアが注視すべき指標、すなわち1軌道あたりの有用な計算量を明らかにしている。

Googleは、打ち上げ時の振動がハードウェア寿命を縮めないことも実証しなければならない。チップは打ち上げには耐えても、数か月後に故障を起こす可能性がある。配備直後の起動成功よりも、長期間のテレメトリーの方が重要になる。

したがってSpaceXは、Project Suncatcherに二つの方向から圧力をかけている。同社のロケットはGoogleの実験を可能にする一方、統合された衛星能力はGoogleに欠けているものを示している。軌道上コンピューティングが成熟するなら、輸送の支配はコンピューティングスタックの一部となる。

冷却は豊富な太陽光をトレードオフに変える

宇宙には豊富なエネルギーがあるが、真空ではプロセッサの熱をはるかに取り除きにくい。

軌道上データセンターの説明では、宇宙は冷たいという点が強調されることが多い。この表現は誤解を招く。温度は粒子の運動を測る一方、チップを冷却するには熱をチップから移動させる必要がある。真空には、その熱を運ぶ物質がほとんど存在しない。

地上の施設では、空気、水、冷媒、配管、冷却塔、熱交換器を通じて熱を移動させる。宇宙機では、プロセッサからラジエーターへ熱を伝導させ、ラジエーターが赤外線放射としてエネルギーを放出する必要がある。

Googleによれば、MVPはヒートパイプとラジエーターを組み合わせている。ヒートパイプは、密閉構造内で作動流体を循環させることで、高温のコンポーネントから熱エネルギーを移動させる。ラジエーターがそのエネルギーを宇宙へ放出する。

ラジエーターに必要な面積は熱負荷に応じて大きくなる。現代のAIアクセラレーターは、小型パッケージ内に大きな電力を集中させるため、熱密度が中心的な設計制約となる。大型ラジエーターは、質量、表面積、構造の複雑さ、脆弱性を増大させる。

太陽電池パネルも同様の幾何学的な問題を生む。より多くの計算にはより多くのエネルギーが必要であり、より多くのエネルギーにはより大きな集光面が必要だ。こうした面は正しく展開され、デブリに耐え、太陽に対して有効な向きを維持しなければならない。

密集した編隊は、熱設計をさらに複雑にする。衛星同士が互いの太陽光照射を遮ったり、隣接する宇宙機に向けて熱を放射したりしないようにする必要がある。その姿勢は、レーザーのアライメントと地球との通信も支えなければならない。

Googleは熱真空チャンバーで冷却設計を試験した。このチャンバーは空気を除去し、温度を変動させて軌道上の条件を近似する。しかし、日光、影、放射、姿勢、部品の経年劣化の間に生じるあらゆる相互作用を再現することはできない。

MVPは、欠けている運用上の証拠を提供する。エンジニアは予測温度と実際のセンサー読み取り値を比較できる。プロセッサがどの程度の速さで発熱するか、ラジエーターがどれほど効率的に冷却するか、繰り返しのサイクルが接続部やメモリーを損傷するかを観測できる。

放射線は、さらなる不確実性をもたらす。Googleの試験では、高帯域幅メモリーがTPUコアよりも高感度であることがわかった。主プロセッサが機能し続けていても、メモリー障害はモデルの重みや中間計算を破損させる可能性がある。

ソフトウェアは、チェックサム、冗長実行、ノード間の比較を通じて一部のエラーを検出できる。こうした保護機構は、計算能力、メモリー、エネルギーを消費する。軌道上クラスターの有用な容量を見積もる際には、そのオーバーヘッドを含めなければならない。

修理可能性は、依然として地上側の最も明確な利点だ。Microsoftによる以前の海中実験は、密閉されたコンピューティングシステムが長期間にわたって遠隔運用できることを示した。しかし、海底は依然として軌道より到達しやすい。

Project Natickは、周囲の水が熱を運び去るという利点も得ていた。Project Suncatcherが直面するのはその逆の環境だ。宇宙は太陽エネルギーの収集を改善する一方、従来の冷却システムが依存する流体媒体を取り除く。

したがってGoogleのトレードオフは、「宇宙対地球」よりも精密だ。それは、ほぼ連続的な太陽光発電と、打ち上げ質量、放射冷却、ネットワークのアライメント、限定的な保守との間の比較である。それぞれの利点には、それに対応する技術的な負担が伴う。

このため、10月1日の起動が成功しても議論は決着しない。意味のある成果は、多くのサイクルにわたる持続的かつ予測可能な運用だ。エンジニアは、性能が温度、放射線被曝、時間によってどう変化するかを把握する必要がある。

Googleは最終的に、ワークロード水準の結果を公表しなければならない。チップ温度だけでは、システムが価値ある計算を実行したかを示せない。より強い証拠には、完了した推論ジョブ、エラー率、デューティサイクル、エネルギー使用量、障害からの復旧が含まれる。

これらの数値が示されるまで、軌道上データセンターの効率性に関する主張は条件付きのままだ。MVPは個々のコンポーネントを検証できるが、商用アーキテクチャは太陽光から有用なAI出力に至るチェーン全体を検証しなければならない。

Project Suncatcherの行方を決める3つのシグナル

次のマイルストーンは、信頼性、ネットワーク、拡張性の順に証明しなければならない。

第1のシグナルは、MVPの打ち上げ後テレメトリーだ。Googleは、衛星が意図した軌道に到達し、通信を確立し、TPUに電力を供給し、計画されたAIワークロードを完了することを確認する必要がある。安定したコンピューティングを伴わない打ち上げ成功は、中心的な主張を弱めることになる。

最初の実証よりも重要なのは、信頼できる運用の継続時間だ。エンジニアは、放射線が訂正可能なエラーを生むか、メモリーが安定性を保つか、冷却システムが繰り返しの処理ウィンドウを支えられるかを注視すべきだ。

Googleは、MVPをどの程度の頻度で稼働できるかも開示すべきである。15分間のセッションの後に短い冷却間隔が続く場合と、長い回復期間が必要な場合では、意味合いが異なる。デューティサイクルは、実験室での能力を実用的な軌道上容量へと変換する。

第2のシグナルは、2027年に予定されている2衛星ミッションだ。この試験では、Project Suncatcherを孤立した計算から接続されたシステムへ移行させなければならない。その決定的な成果は、移動する宇宙機間の安定した高帯域幅の光リンクとなる。

レーザー通信の成功は、Googleのアーキテクチャ上の主張を強める。衛星は、アライメント、位置、熱制御を維持しながらデータを交換する必要がある。帯域幅を落とした限定的な実証では、データセンターとの比較は未解決のまま残る。

第3のシグナルは、この設計がカスタム試作機を超えて拡張できるという証拠だ。Googleは、1基の衛星に搭載した4基のTPUから、多数の衛星にまたがる数十個のチップへ至る信頼できる道筋を示さなければならない。その道筋には、製造、打ち上げ能力、ネットワーク、交換計画が必要になる。

その拡張計画の一部として、ワークロードの選定にも注目すべきだ。軌道上コンピューティングが初期段階で最も強い根拠を持つのは、データが宇宙で発生する場合、または応答の遅延を許容できる場合だ。地上のユーザーとの絶え間ないやり取りを必要とするサービスには、根拠が弱い。

したがって実用的な配備は、衛星画像、気象解析、科学センサー、自律宇宙機の運用から始まる可能性がある。こうした用途はダウンリンク需要を抑え、ローカルコンピューティングに即時の目的を与える。

大規模モデルのトレーニングは、より難しい目標となる。トレーニングには、アクセラレーター間の集中的な通信と、膨大なデータセットへのアクセスが必要だ。データのアップロード、ノードの同期、中断されたジョブの復旧は、アーキテクチャのあらゆる弱点を試すことになる。

一部のモデルはより少ない協調で実行できるため、推論はより早く実現する可能性がある。それでも推論は、モデル更新、入力の配信、結果の送信、破損した出力への安全策に依存する。設置場所だけでソフトウェアスタックが単純になるわけではない。

Googleの9月のミッション更新は、10月の飛行を学習のための取り組みとして位置づけている。この説明は正確だ。同社は、より大規模な設計に踏み切る前に、障害点に関する証拠を集めている。

読者は、Google Project Suncatcherの打ち上げを商用の軌道上クラウドの幕開けではなく、工学プログラムの始まりとして捉えるべきだ。このミッションが重要なのは、仮定を実際の環境下での測定値へと変えるからである。

MVPが信頼性高く稼働すれば、課題の重心はレーザー、編隊制御、スケーリングへ移る。難航した場合でも、Googleは2027年のより大規模な実験に先立ち、貴重な情報を得られる。どちらの結果であっても研究は前進するが、より広範なデータセンター構想を支えられるのは、持続的な成功だけである。

直近の問いは単純だ。4基の既存AIチップは、軌道上で従来の支援システムを失っても、正しい結果を出し続けられるのか。テレメトリー、熱サイクル、そして2027年の光リンク試験に注目したい。これらの結果が、Project Suncatcherがインフラへと発展しつつあるのか、それとも示唆に富む実験にとどまるのかを明らかにする。