記事のサマリー（TL;DR）
- Ai2（Allen AI）がOlmoEarth Platformを公開。衛星画像10テラバイトで事前学習したEarth観測基盤モデルを、エンジニアチームを持たない環境系NGO・政府機関でも運用できるインフラに仕立てた
- 北米全土の山火事リスクマップ生成では、CPUを最大19,600コア・GPU 994基を並列稼働させ、推定4,737時間のシリアル計算を30.5時間に短縮（155倍高速化）
- 処理コストは1平方キロメートルあたり数銭未満。データ取得・前処理（CPU）→推論（GPU）→後処理（CPU）の3段階ハードウェア分割で、GPUを高稼働に保ちつつコストを圧縮
国内の環境データ活用・SaaS事業者が注目すべき分散推論アーキテクチャの要点
衛星データを使った農業・防災・インフラ管理の需要は国内でも拡大しており、国土地理院や農研機構のオープンデータ整備と並行して、民間のスタートアップがSentinel-2やLandsatを活用するケースが増えている。OlmoEarth Platformが示す「CPU高I/O層→GPU推論層→CPU後処理層」の3段階分割は、ジオスペーシャルに限らず大規模バッチ推論全般に応用できる設計原則だ。
特に注目すべきは、外部STACカタログへの大量リクエストを回避するために自前のメタデータインデックスを持ち、SNS通知やポーリングで差分更新する仕組み。国内でも衛星データプロバイダーのAPIレート制限は現実的な壁であり、同様のキャッシュ戦略はGCP・AWS上でのデータ基盤設計に直接転用できる。Google Cloud上で稼働しつつマルチクラウド・パートナー環境での自己ホスティングも視野に入れた設計は、国内の情報セキュリティ要件が厳しい公共機関・研究機関との協業でも参考になる。
詳細
なぜ衛星推論は難しいのか
一般的なMLモデルはメガバイト単位のデータを1秒以内に処理する。LLMがテキストの段落を処理したり、スマートフォンの写真をコンピュータービジョンモデルが解析したりする場合がその典型だ。
Earth観測（EO）推論はまったく異なるスケールで動く。基盤モデルをファインチューニングする1ジョブだけでテラバイト単位のデータを転送し、数時間かかることも珍しくない。入力データは複数のスペクトルバンド・センサー種別・タイムステップにまたがり、複数プロバイダーから取得される。各プロバイダーは異なる投影法と解像度を採用しており、雲に遮られた欠損観測データも含まれる。
出力はそれ自体が地図であるため、すべての予測結果は周囲の領域と同じ投影法・座標グリッドに正確に整合していなければならない。さらに、予測ジョブでは画像のダウンロードと前処理にモデル実行そのものより長い時間がかかることが多く、効率的なデータパイプラインが不可欠になる。
タスクに最適なハードウェアを選ぶ
データ取得と前処理がジョブのランタイムを支配することが多いため、その処理をGPUに割り当てると、最もコストの高いハードウェアをCPU向きのタスクに浪費することになる。そこで各ジョブを3つのステージに分割し、それぞれ異なるハードウェアプロファイルに対応させている。
1. データ取得・前処理（CPU、高I/O）
衛星画像を取得・再投影・整合・正規化し、推論時の高速ロードに最適化したフォーマットで書き出す。
2. 推論（GPU）
モデルのフォワードパスを実行し、最小限の処理のみ施したアウトプットをストレージに直接書き出す。
3. 後処理（CPU）
ウィンドウ単位の出力をつなぎ合わせ、マスクやスケーリングを適用し、Zarr・GeoTIFF・GeoJSONなどのユーザーフレンドリーなフォーマットでエクスポートする。
OlmoEarth Platformは、マルチプロセスのデータローダーが各GPUにデータを継続的に供給しながら、完了した出力をBlobストレージに直接ストリーミングすることで、GPUの稼働率を高く保ちつつ全ステージを多数のマシンに分散させる。
1リクエスト、数百ワーカー、数千プロセス
大規模推論ジョブの実行レイヤーである「OlmoEarth Run」は、ジョブがカバーする地理領域を個々のコンピュートインスタンス（ワーカー）向けのパーティションに分割し、さらにOlmoEarthモデルが処理する小さなウィンドウへと細分化する。各ウィンドウは独立したフォワードパスで処理できるため、ある地域の処理が別の地域を待つ必要はない。
実際には、州規模のエリアが100前後のパーティション、大陸規模では数千のパーティションになる。隣接パーティションはわずかに重複しており、出力を組み立てる際にその重複部分を調整することで、最終的なラスターにシームが生じないようにしている。
パーティションが独立しているため、同一ステージを数千のコンピュートインスタンスで同時実行できる。最近、この手法を使って北米全土の山火事リスクマップを生成した際、ピーク時に約19,600 CPUと994 GPUを並列稼働させ、ネットワークスループットは168 GB/sを超えた。この並列化により、直列計算では推定4,737時間かかる処理を約30.5時間（155倍の高速化）で完了した。
ただし並列化に上限はある。ワーカー数を増やすとクラウドクォータに当たるため、並列度はジョブごとに調整できるパラメーターの一つだ。出力解像度・モデルサイズ・生画像のキャッシュポリシーなど、最適な設定はタスクと予算によって異なる。
適切なピクセルを探して取得する
地理的な領域と時間範囲が与えられると、プラットフォームはまずどの衛星シーンをモデルに入力すべきかを決定する。これは、異なるカタログ・フォーマット・公開遅延を持つプロバイダーをまたいで「何が・どこで・いつ撮影されたか」を特定することを意味する。
選択基準はデータソースによっても異なる。Sentinel-2などの光学画像では雲の少ないシーンを優先するが、合成開口レーダー（SAR）では利用可能な偏波チャンネルが重要になる場合もある。
公開STACカタログとオープン標準を可能な限り活用しているが、大規模な推論ジョブでは何千ものメタデータクエリが同時発生し、ESAやMicrosoft Planetary ComputerのSTAC APIが想定する同時接続数をはるかに超えてしまう。
これを回避するため、OlmoEarth Platformは新しい画像が公開されるたびに更新される独自のメタデータインデックスを管理する。AWS Open Data経由でホストされているデータセットについては、新シーン追加のたびにSNS通知を受け取る。変更ストリームを提供しないプロバイダーについては、数分おきに上流インデックスをポーリングする。その結果、外部サービスへのリクエストは大規模推論ジョブ開始時の急増ではなく、新規公開に合わせた定常的なペースに保たれる。
各インデックスエントリはシーンのメタデータとともに、ピクセルデータが利用可能な全ロケーションへのポインタを保持する。実行時にはプラットフォームが最適なソースを選択し、COGやZarrなどのクラウド最適化フォーマットに対してウィンドウ単位の読み取りを行い、シーン全体をダウンロードせずに特定のパーティションに必要なバイトだけを取得する。
このインデックスはアノテーションツールもサポートする。Sentinel-1・Sentinel-2・Landsat・NISARの各画像へのポインタをクラウド最適化フォーマットで管理しているため、別個のインジェストパイプラインを構築することなく同一のウィンドウ読み取りシステムを通じてタイルを配信できる。
Ai2がEarth観測データの公開ベストプラクティスとして推奨するプロバイダーの特徴は、（1）新画像が利用可能になった際のキューベース通知、（2）独自のレート制限や可用性ボトルネックのない主要クラウドプラットフォーム上のストレージ、（3）範囲読み取りに対応したクラウド最適化フォーマット、の3点だ。
大規模障害への対応
OlmoEarth Platformは障害から自動的に復旧するよう設計されている。各ステージ・地理パーティション内の各タスクについて、プラットフォームはrunnerコンテナを実行する仮想マシンを動的にプロビジョニングする。runnerはタスクパラメーターを取得し、処理を実行し、結果を返してシャットダウンする。
すべてのタスクが再入可能かつ冪等（idempotent）であるため、断続的な障害は安全に再実行で対処できる。このスケールでは障害は想定内だ。プロバイダーが低速または一時的に利用不能になることも、メタデータが示す画像の必要バンドやウィンドウが欠損していることも、雲被覆で利用可能な観測が足りなくなることも、タスクがクラッシュすることも起こり得る。
プラットフォームはタスク追跡・自動リトライ・代替プロバイダーへのフォールバック・リトライ可能エラーと致命的エラーの明確な区別によってこれらに対応する。また、停止したrunnerを検出して再起動する独立したモニタリングプロセスも常時稼働している。
今後のロードマップ
Ai2がパートナーから寄せられたギャップと要望をもとに取り組んでいる主要領域は以下の通り。
推論の自動化
推論ジョブを事前スケジューリング、またはイメージリーダーが関心領域の新シーンを登録したタイミングでトリガーする機能。
変化検出とアラート
森林減少や洪水といったイベントを、誰かが手動でラスターを確認するのではなくアラートとして通知する仕組み。
エージェントツールとインターフェース
データキュレーションや特徴エンジニアリングからファインチューニングモデルの改善方法の特定まで、経験豊富なMLリサーチャーが必要だった作業を技術レベルを問わずユーザーが行えるようにする。
高速モデル
より効率的なアーキテクチャでGPU処理時間をウィンドウあたり削減する研究チームとの協働。
モデリティの拡充
気象データ（ERA-5）や環境因子をより詳細に捉える衛星データを追加。
埋め込み（Embeddings）
グローバルスケールで埋め込みを事前計算する専用モデルの開発。多くのタスクで生画像への完全なフォワードパスを埋め込みへの推論に置き換え、処理を大幅に高速・低コスト化できる見込み。
どこでも動かせる設計（Run Anywhere）
OlmoEarth Runが必要とするのはDockerイメージを実行できる仮想マシンとBlobストレージアクセスのみ。現在はGoogle Cloud上で稼働しているが、アーキテクチャはマルチクラウドやパートナー自身のアカウント・コンピュート環境への展開をサポートするよう設計されている。
ジオスペーシャル基盤モデル、とりわけその運用は依然として新興技術であり、自然保護・食料安全保障・災害対応・気候変動に取り組む多くの組織はこれまでこのようなインフラにアクセスできなかった。こうした組織が「地球について理解する必要があること」と「予算と技術リソースで実現できること」の間のギャップは依然として大きい。OlmoEarth Platformはそのギャップを縮めるために構築されている。