OlmoEarth 平台：行星規模的地理空間推斷

OlmoEarth 平台：行星規模的地理空間推斷

OlmoEarth 平台是一種基礎設施，旨在將地理空間基礎模型從微調和評估過渡到大規模推斷。它使組織能夠在約一天內處理跨洲規模區域的數十 TB 影像，達成每平方公里成本低至幾分钱的水平。

克服衛星推斷中的挑戰

地理空間推斷因資料規模龐大和輸入複雜而與標準 ML 任務不同。單次微調作業可能涉及 TB 級資料並運行數小時，使用多個光譜帶、傳感器類型和時間步。

Key technical hurdles include:

  • 資料異質性： 影像來自各種提供者，其投影、解析度和雲層遮蔽程度各不相同。
  • 對齊需求： 由於輸出是地圖，每個預測必須保持與周圍區域座標網格的精確對齊。
  • I/O 瓶頸： 預測作業經常花費更多時間下載和準備影像，而非執行模型，因而需要高效率的資料管道。

優化硬體分配

為防止昂貴的 GPU 在資料準備上被浪費，OlmoEarth 平台將每個推斷作業劃分為三個不同的階段，每個階段映射到最具成本效益的硬體：

  1. 資料取得與預處理（CPU，高 I/O）： 此階段會獲取、重新投影、對齊並正規化影像，並將其儲存為針對快速載入優化的格式。
  2. 推斷（GPU）： 平台執行模型的前向傳遞，並將最小處理的輸出直接寫入儲存。
  3. 後處理（CPU）： 將每個窗口的輸出拼接起來，應用遮罩或重新縮放，並將結果匯出為 GeoJSON、GeoTIFF 或 Zarr 等格式。

透過 OlmoEarth Run 實現可擴展執行

OlmoEarth Run，作為平台的執行層，透過將地理區域劃分為適合單個計算實例（工作節點）大小的分區來管理大規模作業。這些分區會再細分為較小的視窗以供模型處理。由於每個視窗都是獨立的，平台可以並行執行數千次前向傳遞。

在最近一次北美洲野火風險圖生成中，平台展示了以下規模：

  • 平行ism： 在峰值時使用了約 19,600 個 CPU 和 994 個 GPU。
  • 吞吐量： 網路吞吐量超過 168 GB/s。
  • 效率： 將估計的 4,737 小時序列計算減少到 30.5 小時的牆鐘時間，相當於 155× 的加速。

智慧資料索引與檢索

為了避免數千個併發查詢壓垮外部 STAC API（如 ESA 或 Microsoft Planetary Computer 提供的 API），OlmoEarth 平台維護自己的內部中繼資料索引。

中繼資料管理

  • 更新機制： 索引透過 AWS Open Data 的 SNS 通知進行更新，或對其他提供者的上游索引每隔幾分鐘進行輪詢。
  • 高效檢索： 索引儲存場景中繼資料與像素指標。執行時，平台會針對雲端優化格式（COG 或 Zarr）進行視窗讀取，僅擷取分區所需的位元組，而非下載整個場景。

資料提供者的最佳實踐

基於平台的開發經驗，團隊建議發布地球觀測資料的三項最佳實踐：基於佇列的新影像通知、在主要雲端平台上儲存且不設定客製化速率限制，以及使用支援範圍讀取的雲端優化格式。

容錯與恢復

平台旨在自動從分散式運算的常見故障中恢復。每項任務都在動態佈建的 runner Docker 容器內執行。

由於每項任務都是可重新進入且具等冪性的，平台透過任務追蹤、自動重試以及切換到備用提供者來處理間歇性故障——例如提供者不可用、遺失影像頻帶或容器崩潰。另一個監控進程會識別停滯的 runner 並重新啟動其任務。

未來路線圖

Ai2 正在擴充 OlmoEarth 平台以包含以下新功能：

  • 自動化工作流程： 根據新影像註冊排程推斷作業或觸發它們。
  • 警報系統： 實施變更偵測以通知使用者發生洪水或森林砍伐等事件。
  • 代理介面： 開發工具以降低資料策展與特徵工程的技術門檻。
  • 效率提升： 研究更快的模型架構，並開發專用嵌入模型以替代許多任務的完整前向傳遞。
  • 擴充模態： 融入天氣資料（ERA-5）及額外的衛星傳感器。
  • 雲端中立部署： 雖然目前部署在 Google Cloud，但架構設計支援多雲端以及合作夥伴自有運算環境的部署。

SUMMARY: Hugging Face 與 Ai2 推出了 OlmoEarth 平台，這是一種基礎設施，旨在將地理空間基礎模型從微調擴展到洲際規模的推斷，成本僅為每平方公里幾分钱。

TITLE: OlmoEarth 平台：行星規模的地理空間推斷

Sources