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

来源：https://huggingface.co/blog/allenai/olmoearth-infrastructure 返回文章列表 (https://huggingface.co/blog)

https://huggingface.co/login?next=%2Fblog%2Fallenai%2Folmoearth-infrastructure-

Kyle Wiggers的头像 (https://huggingface.co/Ai2Comms)

• 为什么卫星推理具有挑战性
• 为任务选择正确的硬件
• 一个请求、数百个工作进程和数千个进程
• 寻找并获取正确的像素
• 大规模下的故障处理
• 未来规划

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

基于卫星底图的北美洲野火风险地图（蓝色到红色热力图），由OlmoEarth平台生成 (https://www.datocms-assets.com/64837/1784901152-olmoearth-engineering-blog-inference-google-docs-image-1.png)

OlmoEarth模型 (https://allenai.org/blog/olmoearth-v1-1) 是我们系列的地球观测基础模型，基于约10TB多模态卫星数据预训练而成。政府、非政府组织和其他使命驱动型组织已在使用OlmoEarth进行森林砍伐监测、粮食安全和野火风险等应用。

在Ai2，我们深知如何训练并发布强大的开放模型。对于拥有强大工程团队的组织而言，一个开放模型就足以让他们自主运行。但大多数环境领域的组织——那些最有可能应用这些模型的组织——并不具备管理完整生命周期的基础设施或工程团队：数据标注、模型微调以及大规模推理。我们运营Skylight (https://allenai.org/skylight) 和EarthRanger (https://allenai.org/earthranger) 等平台已超过十年，全球用户每天依赖这些软件，因此它们必须每天正常运转。这段经验让我们明白，产生影响力需要什么：在正确的时间和地点以高性价比运行模型、监控性能、将原始输出转化为可操作的洞察，并验证这些产出是否带来了合作伙伴期望的结果。

正因如此，我们构建了OlmoEarth平台 (https://allenai.org/olmoearth)：一个将地理空间模型从微调和评估推向大规模推理的基础设施。

如此规模的推理带来了自身的一系列挑战。卫星影像必须在多个数据提供商间查找和接入，跨投影和分辨率进行对齐，并高效处理。随后，输出结果需要拼接成地理上一致的地图，同时基础设施还要从分布式计算常见的故障中恢复。

如今，该平台可以在大约一天内完成整个大陆尺度的推理，处理数十TB影像，每平方公里成本不到一分钱。开发这个平台意味着要面对一系列工程挑战，其他从事大规模地理空间系统的人很可能也会遇到这些挑战。本文将逐一介绍这些挑战以及我们最终采用的解决方案。

大陆尺度推理运行数据概览——总结北美洲野火风险运行的统计网格 (https://www.datocms-assets.com/64837/1784901325-olmoearth-engineering-blog-inference-google-docs-image-2.png)

最近在OlmoEarth平台上生成的野火风险地图及统计数据。

野火风险热力图在地形上的特写，从蓝色（低风险）到红色（高风险） (https://www.datocms-assets.com/64837/1784901426-ai2-engineering-blog-thumbnail-development-v2.png)

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

大多数机器学习模型接收几MB数据，并在不到一秒内产生结果——想想处理一段文本的LLM，或分析智能手机照片的计算机视觉模型。地球观测推理的运行规模完全不同——一个为追求最佳性能而微调基础模型的作业可能要移动TB级数据并运行数小时。输入数据可能涵盖多个光谱波段、传感器类型和跨大地理区域的时间步长。这些数据可能来自多个提供商，每个使用不同的投影和分辨率，并且可能包含缺失或被云遮挡的观测。输出本身是一张地图，因此每个预测必须与周围区域保持精确对齐，使用相同的投影和坐标网格。

即使只是获取数据也可能是一项重大挑战。预测作业通常花在下载和准备影像上的时间比运行模型本身还多，这使得高效的数据管道至关重要。这些管道必须处理高吞吐量的I/O，同时提供重投影和重采样影像所需的计算能力。

为任务选择正确的硬件

由于数据获取和准备往往占据推理作业的大部分运行时间，将这项工作分配给GPU会导致系统最昂贵的硬件去做更适合CPU的任务。因此，我们将每个作业分为三个阶段，每个阶段匹配不同的硬件配置：

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

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

三阶段推理流程卡片：01 数据获取（CPU，高度I/O密集型），02 运行推理（GPU，高度GPU密集型），03 后处理（CPU） (https://www.datocms-assets.com/64837/1784901476-olmoearth-engineering-blog-inference-google-docs-image-4.png)

一个请求、数百个工作进程和数千个进程

OlmoEarth Run 是该平台用于大规模推理作业的执行层。它将每个作业覆盖的地理区域划分为可供单个计算实例（工作进程）处理的分区，然后将这些分区进一步细分为OlmoEarth模型处理的更小窗口。由于每个窗口可以在独立的前向传播中单独处理，地图某一部分的工作无需等待另一部分。

实践中，一个州级面积可能产生大约一百个分区，而大陆尺度的运行可能达到数千个。相邻分区会有少量重叠，在输出组装时我们会对重叠部分进行协调，确保最终栅格中不出现接缝。

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

然而，扇出并非无限制。更多的计算实例会触及云配额，因此并行度是每个运行的可调参数，也是我们可根据单个作业调整的多个参数之一。输出分辨率在数据量和计算细节间权衡；模型大小在GPU时间与准确性间权衡；缓存原始影像在存储空间与相同区域重复运行的速度间权衡。正确的设置取决于当前任务——以及预算。

OlmoEarth两级分区：阶段1将一次预测请求拆分为机器大小的分区，扇出至最多约1,000个工作节点；阶段2将每个工作单元的单元格重新划分为模型大小的窗口，每个节点一个GPU并行处理 (https://www.datocms-assets.com/64837/1784901521-olmoearth-engineering-blog-inference-google-docs-image-5.png)

寻找并获取正确的像素

给定一个地理区域和时间范围，平台首先需要确定哪些卫星场景应输入模型。这意味着要识别出哪些影像被捕获、在何处、何时，以及来自哪些提供商——这些提供商有不同的目录、格式和发布延迟。选择标准也取决于数据源：对于Sentinel-2等光学影像，我们通常希望找到云量最少的场景；而对于合成孔径雷达，可用的极化通道可能更为重要。

我们尽可能依赖公开的STAC目录和开放标准。但一个大型推理作业一次可能产生数千个元数据查询——远高于ESA或微软行星计算机的STAC API等外部服务设计的同时处理能力。

为了避免压垮这些服务，OlmoEarth平台维护自己的元数据索引，并在新影像发布时更新。对于通过AWS开放数据托管的数集，我们会在每个新场景发布时收到SNS通知。如果提供商不提供变更流，我们会每隔几分钟轮询其上游索引。因此，我们对外部服务的请求保持与新发布的稳定节奏一致，而不是大型推理作业生成的突发流量。

OlmoEarth数据集架构：一个元数据索引覆盖多个卫星提供商（AWS开放数据、Google Cloud、USGS、哥白尼计划、NASA/ASF、微软行星计算机），通过摄取队列、工作Pod和Elasticsearch索引为搜索和切片API提供服务 (https://www.datocms-assets.com/64837/1784901625-olmoearth-engineering-blog-inference-google-docs-image-6.png)

每个索引条目存储场景元数据以及指向底层像素可用位置的指针。运行时，平台选择最佳数据源，并针对COG或Zarr等云优化格式执行窗口化读取，仅检索给定分区所需的字节，而非下载整个场景。

该索引还支持我们的标注工具。由于它维护了指向 Sentinel-1、Sentinel-2、Landsat 和 NISAR 影像（以云优化格式存储）的指针，我们可以通过同一窗口化读取系统为任何已索引场景提供切片服务，无需构建独立的数据摄取管道。

使得这种工作流最简便的数据提供商具有三个共同特点，我们建议将其作为发布地球观测数据的最佳实践：当新影像可用时提供基于队列的通知、存储于主流云平台且无特殊速率限制或可用性瓶颈、以及支持范围读取的云优化格式。

示例 items-search API 调用：向 /api/v1/items/search 发送 POST 请求，查询日期范围和多边形内的 Sentinel-2 L2A 数据集，按云量排序，返回 JSON 响应记录及云优化资产指针 (https://www.datocms-assets.com/64837/1784902461-precision-capture-2026-07-24t14-13-41-request-post-api-v1-items-search-collection-eq-sentinel-2-l2a-collected-at-gte-2026-06-01t00-00-00z-lt-2026-06-08t00-00-00z-intersects-geometry-type-polygon-coordinates-122-5155-37-7079-122-3554-37-7079.png)

针对 OlmoEarth 卫星影像索引的示例查询，搜索六月份第一周旧金山上空云量最少的 Sentinel-2 影像。该服务返回最佳可用影像以及指向 Amazon S3 存储桶中 GeoTIFF 文件的指针。

大规模下的故障处理

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

在此规模下，故障是预料之中的：某个提供商可能速度缓慢或暂时不可用；元数据可能表明影像存在，但所需波段或窗口缺失；云量可能使可用观测过少；或者任务可能直接崩溃。平台的应对措施包括：任务跟踪、自动重试、在可用时回退到其他提供商，以及明确区分可重试错误和致命错误。一个独立的监控进程会检测到已停滞或停止的 runner 并重启它们的任务。

未来规划

我们的路线图由合作伙伴发现的需求盲区和他们最需要的能力塑造。我们正在致力于以下领域：

• 自动化模型运行。预计划推理作业，或每当影像索引在感兴趣区域上注册新场景时触发推理。
• 变化检测与警报。当用户监测的景观发生变化时通知他们，使森林砍伐或洪水等事件以警报形式呈现，而不是需要人工查找和检查的栅格。
• 智能体工具与界面。智能体可以降低使用地理空间模型的门槛，从数据整理和特征工程到识别改进微调模型的方法。我们希望任何技术水平的用户都能完成以前需要经验丰富的机器学习研究员才能做的工作。
• 更快的模型。与研究团队合作开发更高效的架构，减少每个窗口的GPU时间。
• 更多模态。为OlmoEarth模型及其支持的影像索引添加新的卫星传感器和数据源。我们目前专注于整合气象数据（ERA-5）以及提供更多环境因素细节的卫星。
• 嵌入向量。开发专用的嵌入模型，并在全球范围内预计算嵌入向量。对于许多任务，针对这些嵌入向量进行推理可以替代对原始影像的完整前向传播，从而大幅降低工作负载的速度和成本。对于具有挑战性的任务，微调和直接推理仍将保持最佳性能，但嵌入向量可能开启更广泛的高效应用。
• 随处运行。OlmoEarth Run仅需要能够运行Docker镜像的虚拟机以及对块存储的访问。我们目前将其部署在Google Cloud上，但架构设计支持多云环境以及在合作伙伴自己的账户和计算环境内部署。

这仅仅是个开始。地理空间基础模型，特别是将其投入实际应用，仍属新兴技术。而许多最有条件使用这些模型的组织——那些从事保护、粮食安全、灾害响应和气候工作的组织——从未拥有过像这样的基础设施。