[](https://huggingface.co/Ai2Comms)🌍 了解更多关于 OlmoEarth Platform：https://allenai.org/olmoearth
OlmoEarth 模型是我们的一系列地球观测基础模型，基于约 10TB 的多模态卫星数据进行预训练。政府、非政府组织以及其他以使命驱动的机构已经在将 OlmoEarth 应用于森林砍伐监测、粮食安全和野火风险等场景。
在 Ai2，我们深知如何训练并发布强大的开源模型；对于拥有强大工程团队的组织来说，一个开源模型就足够他们直接上手运行。但在环境领域的大多数组织——也正是最适合应用这些模型的组织——并不具备管理完整生命周期的基础设施或工程团队：数据标注、模型微调以及大规模推理。十多年来，我们一直在运营 Skylight 和 EarthRanger 这样的平台，这些软件被全球用户每天依赖，因此必须每天都能正常运行。这段经历让我们明白，要真正产生影响需要什么：在合适的时间和地点以高性价比运行模型、监控性能、将原始输出转化为可操作的洞察，并验证这些输出能够推动合作伙伴期望达成的结果。
这就是我们构建 OlmoEarth Platform 的原因：一套将地理空间模型从微调和评估推进到大规模推理的基础设施。
这种规模的推理会带来一系列独特挑战。必须跨多个数据提供方查找并访问卫星影像，对齐不同投影和分辨率，并高效处理。随后还要把结果拼接成地理上一致的地图，同时基础设施要能从分布式计算的常见故障中恢复。
如今，该平台可以在大约一天内对跨大陆范围进行推理，处理数十 TB 影像，且每平方公里成本仅为几美分的零头。开发过程中，我们不得不面对一系列工程难题，而这些难题很可能也是其他从事大规模地理空间系统开发的人会遇到的。本文将带你了解这些挑战以及我们最终采用的解决方案。
近期在 OlmoEarth Platform 上生成的一张野火风险地图及其统计信息。
为什么卫星推理具有挑战性
大多数机器学习模型只需输入几 MB 数据，并在一秒内给出结果——比如 LLM 处理一段文本，或计算机视觉模型分析一张手机照片。地球观测推理运行的规模则完全不同：一次为了获得最佳性能而微调基础模型的任务，可能要移动 TB 级数据并运行数小时。输入可能跨越多个光谱波段、传感器类型和时间步，覆盖大片地理区域。数据可能来自多个提供方，各自使用不同的投影和分辨率，还可能包含缺失观测或被云层遮挡的观测。输出本身就是一张地图，因此每个预测都必须与周围区域保持精确的投影和坐标网格对齐。
即便获取数据本身也可能是一项重大挑战。预测任务在下载和准备影像上花费的时间，往往比模型实际运行还多，因此高效的数据管道至关重要。这些管道必须在提供高吞吐 I/O 的同时，还要具备执行影像重投影和重采样所需的计算能力。
正确的任务配合正确的硬件
由于数据获取和准备常常主导推理任务的总运行时间，把这些工作交给 GPU 会让系统中最昂贵的硬件去做更适合 CPU 的任务。因此，我们将每个任务分成三个阶段，并分别匹配不同的硬件配置：
-
数据获取与预处理（CPU，高 I/O）： 获取、重投影、对齐并归一化影像，然后以适合推理阶段快速加载的格式写入。
-
推理（GPU）： 执行模型前向传播，并将经过最少处理的输出直接写入存储。
-
后处理（CPU）： 将各窗口输出拼接起来，应用掩膜或重缩放，并以用户友好的格式导出，如 Zarr、GeoTIFF 或 GeoJSON。
OlmoEarth Platform 将这些阶段分布到多台机器上，同时保持 GPU 的高利用率。多进程数据加载器持续为每块 GPU 提供数据，而完成的输出则直接流式写入 blob 存储。
一个请求、数百个 worker 和数千个进程
OlmoEarth Run 是该平台用于大规模推理任务的执行层。它会先将每个任务覆盖的地理区域划分为适合单个计算实例（worker）的分区，再把这些分区进一步细分为更小的窗口，由 OlmoEarth 模型处理。由于每个窗口都可以在独立的前向传播中单独处理，地图某一部分的工作不必等待另一部分完成。
在实际运行中，一个州大小的区域可能会被切分成一百个左右的分区，而一个跨大陆规模的运行则可能达到数千个分区。相邻分区之间会有轻微重叠，我们会在结果组装时对这些重叠进行协调，从而让最终栅格中不会出现拼接缝。
由于这些分区彼此独立，同一阶段可以同时在数千个计算实例上运行。我们最近就用这种方法生成了一张覆盖整个北美的野火风险地图。在峰值时，该运行并行使用了大约 19,600 个 CPU 和 994 个 GPU，网络吞吐量超过 168 GB/s。这种并行度把估算需要 4,737 小时的串行计算压缩到了约 30.5 小时的实际耗时，实现了 155 倍加速。
不过，fan-out 并不是无限的。Mo