OlmoEarth 平台：行星尺度的地理空间推理

OlmoEarth 平台是一种基础设施，旨在将地理空间基础模型从微调和评估过渡到大规模推理。它使组织能够在大约一天内处理跨大陆规模区域的数十 TB 影像，实现每平方公里仅几分钱的成本。

克服卫星推理中的挑战

由于数据规模巨大和输入复杂，地理空间推理与标准 ML 任务不同。单次微调作业可能涉及 TB 级数据并运行数小时，使用多个光谱波段、传感器类型和时间步骤。

主要技术挑战包括：

• 数据异质性： 影像来自各种提供商，具有不同的投影、分辨率和云遮蔽程度。
• 对齐要求： 由于输出是一张地图，每个预测必须保持与周围区域坐标网格的精确对齐。
• I/O 瓶颈： 预测作业经常在下载和准备影像上花费的时间多于执行模型的时间，因而需要高效的数据管道。

优化的硬件分配

为了防止昂贵的 GPU 在数据准备上被浪费，OlmoEarth 平台将每个推理作业划分为三个不同的阶段，每个阶段映射到最具成本效益的硬件：

1. 数据获取和预处理（CPU，高 I/O）： 此阶段获取、重新投影、对齐并归一化影像，并将其保存为经过快速加载优化的格式。
2. 推理（GPU）： 平台运行模型的前向传递，并将最小处理的输出直接写入存储。
3. 后处理（CPU）： 将每个窗口的输出拼接在一起，应用掩码或重新缩放，并将结果导出为 GeoJSON、GeoTIFF 或 Zarr 等格式。

通过 OlmoEarth Run 实现可扩展执行

OlmoEarth Run，作为平台的执行层，通过将地理区域划分为适用于单个计算实例（工作器）大小的分区来管理大规模作业。这些分区进一步细分为用于模型处理的更小窗口。由于每个窗口都是独立的，平台可以并行执行数千次前向传递。

在最近一次北美洲野火风险图生成中，平台展示了以下规模：

• 并行性： 峰值时使用了约 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 容器中执行。

由于每个任务都是可重入且幂等的，平台通过任务跟踪、自动重试以及切换到替代提供商来处理间歇性故障——例如提供商不可用、缺少影像波段或容器崩溃。单独的监控进程会识别停滞的 runners 并重启其任务。

未来路线图

Ai2 正在扩展 OlmoEarth 平台，以包含几项新功能：

• 自动化工作流： 基于新影像注册安排推理作业或触发它们。
• 警报系统： 实施变化检测以通知用户发生洪水或森林砍伐等事件。
• 代理接口： 开发工具以降低数据策划和特征工程的技术门槛。
• 效率提升： 研究更快的模型架构，并开发专用嵌入模型以替代许多任务的完整前向传递。
• 扩展模态： 融入天气数据（ERA-5）和额外的卫星传感器。
• 云无关部署： 虽然目前在 Google Cloud 上，但架构设计为支持多云以及在合作伙伴自身计算环境中的部署。 }