The OlmoEarth Platform: Geospatial inference at planetary scale

OlmoEarth 平台：行星规模的地理空间推理

返回文章列表

[0

[-1

企业

]

文章

发布于 2026 年 7 月 28 日

点赞

1

[

Kyle Wiggers

Ai2Comms

关注

allenai

🌍 了解更多关于 OlmoEarth 平台的信息：https://allenai.org/olmoearth

OlmoEarth 模型是我们开发的一系列地球观测基础模型，这些模型在约 10 太字节的多模态卫星数据上进行了预训练。目前，各国政府、非政府组织和其他以使命为导向的组织已开始将 OlmoEarth 应用于包括森林砍伐监测、粮食安全和野火风险评估在内的多个领域。

在 Ai2，我们深知如何训练和发布强大的开源模型。对于拥有强大工程团队的组织来说，一个开源模型就足以满足需求。但大多数环境领域的组织——这些最有可能应用这些模型的组织——往往缺乏能够管理完整生命周期（包括数据标注、模型微调和大规模推理）的基础设施和工程团队。我们在 Skylight 和 EarthRanger 等平台运营方面已有超过十年的经验，这些软件每天被全球用户依赖，因此必须确保其每天都能正常运行。这段经历让我们明白实现影响力所需的关键要素：在正确的时间和地点以成本效益的方式运行模型，监控性能，将原始输出转化为可操作的见解，并验证这些输出是否能推动合作伙伴期望的结果。

这就是我们构建 OlmoEarth 平台的原因：为将地理空间模型从微调和评估推进到大规模推理提供基础设施支持。

在如此规模上进行推理带来了独特的挑战。卫星图像需要从多个提供商处获取并访问，需要在不同投影和分辨率之间对齐，并且需要高效处理。随后，结果需要被拼接成地理一致的地图，同时基础设施要从分布式计算的常规故障中恢复。

目前，该平台可以在大约一天内完成跨大陆规模区域的推理，以每平方公里几分钱的成本处理数十太字节的图像数据。开发这个平台意味着要解决一系列工程挑战，这些问题很可能是其他从事大规模地理空间系统开发的团队也会遇到的。本文将逐步介绍这些挑战以及我们找到的解决方案。

在 OlmoEarth 平台上生成的最新野火风险地图及统计信息。

为什么卫星推理具有挑战性

大多数机器学习模型处理几兆字节的数据，并在不到一秒的时间内生成结果——例如大型语言模型处理一段文本或计算机视觉模型分析智能手机拍摄的照片。而地球观测推理则处于一个完全不同的规模——单个任务微调一个基础模型以实现最佳性能可能需要处理数太字节的数据并运行数小时。输入数据可能涵盖多个光谱波段、传感器类型和时间步长，覆盖大面积地理区域。这些数据可能来自多个提供商，每个提供商使用不同的投影和分辨率，还可能包含缺失或被云遮挡的观测数据。输出本身是一张地图，因此每个预测都必须与周围区域的相同投影和坐标网格精确对齐。

即使获取数据本身也可能是一个重大挑战。预测任务通常在下载和准备影像上花费的时间比运行模型本身还要多，这使得高效的数据流水线变得至关重要。这些流水线必须在处理高吞吐量I/O的同时，提供足够的计算能力来重新投影和重采样影像。

为不同任务选择合适的硬件

由于数据获取和预处理通常占用了推理任务的大部分运行时间，将这些任务分配给GPU会导致系统最昂贵的硬件执行更适合CPU的任务。因此，我们将每个任务划分为三个阶段，每个阶段都匹配特定的硬件配置：

• 数据获取和预处理（CPU，高吞吐量I/O）：获取、重新投影、对齐和归一化影像，然后以优化快速加载的格式进行存储。
• 推理（GPU）：运行模型的前向传播，并将最小处理后的输出直接写入存储。
• 后处理（CPU）：将每个窗口的输出拼接在一起，应用掩膜或重新缩放，并以用户友好的格式（如Zarr、GeoTIFF或GeoJSON）导出。

OlmoEarth平台将这些阶段分布在多台机器上，同时保持GPU的充分利用。多进程数据加载器持续向每个GPU提供数据，而完成的输出则直接流式传输到块存储。

一个请求，数百个工作者，数千个进程

OlmoEarth Run是平台用于大规模推理任务的执行层，它将每个任务覆盖的地理区域划分为适合单个计算实例（工作者）处理的分区，然后将这些分区进一步细分为更小的窗口，由OlmoEarth模型进行处理。由于每个窗口可以在独立的前向传播中处理，因此地图某部分的处理不需要等待其他部分完成。

实际上，一个州规模的区域可能被划分为约100个分区，而一个大陆规模的运行可能被划分为数千个分区。相邻的分区会有轻微重叠，我们在组装输出时会协调这些重叠，确保最终栅格中没有接缝。

由于分区是独立的，同一阶段可以同时在数千个计算实例上运行。我们最近使用这种方法生成了一张覆盖整个北美地区的野火风险地图。在运行高峰期，该任务同时使用了约19,600个CPU和994个GPU，网络吞吐量超过168 GB/s。这种程度的并行性将估计需要4,737小时的串行计算缩短到约30.5小时的墙钟时间——速度提升了155倍。

不过，这种并行扩展并非没有限制。更多的工作者会触及云服务配额限制，因此并行度是每个运行任务可调整的参数之一，我们还可以根据单个任务的需求调整其他参数。输出分辨率在数据量和计算需求与细节之间进行权衡；模型大小在GPU时间与准确性之间进行权衡；缓存原始影像则在存储空间与重复运行同一区域时的速度之间进行权衡。正确的设置取决于当前的任务——以及预算。

我们尽可能依赖公开的STAC目录和开放标准。但大规模推理任务可能同时生成数千个元数据查询——远超ESA或微软行星计算机STAC API等外部服务设计的并发处理能力。

为避免压垮这些服务，OlmoEarth平台维护着自己的元数据索引，该索引会在新影像发布时实时更新。对于通过AWS开放数据托管的数据集，我们会为每个新场景接收SNS通知。当供应商未提供变更流时，我们会每隔几分钟轮询其上游索引。因此，我们对外部服务的请求节奏会与新影像发布的稳定速度保持一致，而非被大规模推理任务产生的突发峰值所冲击。

每个索引条目都存储着场景元数据，并指向所有包含底层像素的存储位置。运行时，平台会选择最佳数据源，对云优化格式（如COG或Zarr）执行窗口读取，仅获取特定分区所需的字节数据，而非下载完整场景。

该索引还支持我们的标注工具。由于其维护着Sentinel-1、Sentinel-2、Landsat和NISAR影像的云优化格式指针，我们可以通过相同的窗口读取系统，从任意索引场景中提供瓦片，无需构建独立的摄入流水线。

使这一工作流程最便捷的供应商具有三个共同特征，我们建议将其作为发布地球观测数据的最佳实践：新影像可用时提供基于队列的通知、在主要云平台存储数据且不设置定制速率限制或可用性瓶颈、使用支持范围读取的云优化格式。

对OlmoEarth卫星影像索引的示例查询：搜索6月初旧金山地区云量最少的Sentinel-2影像。该服务会返回最佳可用影像，并指向Amazon S3存储桶中的GeoTIFF文件。

扩展规模下的故障处理

OlmoEarth平台设计为可自动从故障中恢复。对于每个阶段和地理分区中的任务，平台会动态分配运行我们runner Docker容器的虚拟机。runner获取任务参数，执行工作，返回结果后关闭。由于每个任务都具备可重入性和幂等性，间歇性故障可通过重新运行安全处理。

在如此规模下，故障是预期常态：供应商可能响应缓慢或暂时不可用；元数据可能显示影像存在，但所需波段或窗口缺失；云覆盖可能导致可用观测数据过少；或任务可能直接崩溃。平台通过任务追踪、自动重试、在可用时回退到备用供应商、明确区分可重试错误和致命错误来应对。独立的监控进程会检测到停滞或停止的runner，并重启其任务。

我们的未来方向

我们的路线图由合作伙伴识别的差距和他们最需要的能力所塑造。我们正在重点推进的领域包括：

• 自动化模型运行。提前安排推理任务，或在影像索引检测到感兴趣区域出现新场景时自动触发。

• 变化检测与告警。当用户监控的区域发生景观变化时通知用户，使森林砍伐或洪水等事件以告警形式呈现，而非需要人工查找和检查的栅格图像。

• 智能代理工具与接口。代理可以降低使用地理空间模型的门槛，从数据整理和特征工程到识别优化微调模型的方法。我们希望任何技术水平的用户都能完成过去需要经验丰富的机器学习研究员才能完成的工作。

• 更高效的模型。与我们的研究团队合作开发更高效的架构，减少每个窗口的GPU计算时间。

• 更多数据模态。向OlmoEarth模型和支撑它们的影像索引添加新的卫星传感器和数据源。我们目前的重点是整合气象数据（ERA-5）和提供更详细环境因素信息的卫星。

• 嵌入向量。开发专用的嵌入模型并在全球范围内预计算嵌入向量。对于许多任务，对这些嵌入向量进行推理可能可以替代对原始影像的完整前向传播，使工作负载显著更快且成本更低。对于具有挑战性的任务，微调和直接推理仍将是实现最佳性能的重要方式，但嵌入向量可能为更广泛的高效应用打开新的可能性。

• 任意环境运行。OlmoEarth Run仅需要能够运行Docker镜像的虚拟机和访问blob存储的权限。我们目前在Google Cloud上运行它，但架构设计支持多云部署，并可在合作伙伴自己的账户和计算环境中部署。

这仅仅是开始。地理空间基础模型，特别是将其投入实际应用，仍是一项新兴技术。许多最能利用这些技术的组织——那些从事环境保护、粮食安全、灾害响应和气候研究的机构——此前从未接触过此类基础设施。这些团队需要了解地球现状的需求与他们的预算和技术资源所能支持的范围之间仍然存在巨大差距。

我们正在构建OlmoEarth来帮助弥合这一差距。

更多该作者的文章

构建Shippy教会我们的代理构建经验

16

2026年7月15日

DiScoFormer：一种跨分布的密度和分数联合预测的Transformer

6

2026年6月29日

社区

编辑

预览

通过拖拽文本输入框、粘贴或

点击此处

上传图片、音频和视频。

点击此处上传图片

评论

· 注册或登录以发表评论