AI2 在一篇工程博客中详细介绍了 OlmoEarth 平台——一个为地理空间基础模型大规模推理构建的基础设施。核心思想是：对于环境监测、灾害响应等领域的组织来说，开放模型远远不够，他们缺乏从数据标注、微调到大规模推理的全套工程能力。OlmoEarth 平台试图填补这个空白，它允许用户将微调后的模型以每天处理大陆级区域、每平方公里成本不到一美分的规模投入推理。

文章开篇指出卫星推理面临的独特挑战：输入数据可达数十TB，涉及多光谱波段、不同传感器、不同投影和分辨率，且经常被云遮挡。输出必须是地理一致的地图，每个像素都要对齐。数据获取和预处理往往比模型推理本身更耗时。为此，平台将每个推理作业分为三个阶段，分别分配不同硬件：数据获取和预处理（CPU，高I/O），推理（GPU），后处理（CPU）。这种分工避免了将昂贵的GPU浪费在I/O密集任务上。

并行执行方面，平台采用分区机制：将地理区域划分为适合单个计算实例的“分区”，每个分区再细分为模型处理窗口。分区间独立运行，相邻分区有重叠，最终合成时消除接缝。实用案例：生成一张覆盖整个北美的野火风险地图，峰值时并行使用了约 19,600 个CPU和 994 个GPU，网络吞吐量超过 168 GB/s。这种并行度将估算的 4,737 小时串行计算压缩为 30.5 小时墙钟时间——实现 155 倍加速。并行度可调整，受云配额限制；其他可调参数包括输出分辨率、模型大小和缓存策略。

数据获取的挑战在于跨多个提供商的卫星目录找到正确的像素。平台维护自己的元数据索引，通过 SNS 通知或定时轮询更新，避免大规模推理作业突然冲击外部 STAC API。索引存储每个场景的元数据和指向云优化格式（COG、Zarr）的指针，运行时只做范围读取，只下载需要的字节，无需下载整张场景。该索引还支持标注工具，无需单独构建摄取管道。文章总结了发布地球观测数据的最佳实践：基于队列的新场景通知、存储在主要云平台上（无自定义速率限制）、以及支持范围读取的云优化格式。

故障处理方面，每个任务都是可重入且幂等的，平台自动重试失败任务，区分可重试和致命错误，并监控停滞的 runner 自动重启。这种设计使得大规模推理中的供应商超时、影像缺失、云覆盖不足等常见故障都能被自动恢复。

未来路线图包括：自动调度推理作业（新场景触发）；变化检测和警报（主动推送而非人工查找）；Agent 工具和界面降低使用门槛；更高效的模型架构；增加新模态（ERA-5 气象数据、更多环境卫星）；开发专用嵌入模型并在全球预计算，用嵌入推理替代完整前向传播以大幅降低成本；以及支持多云和在合作伙伴账户内部署。文章最后强调，地理空间基础模型的运营化仍是新兴技术，生态保护、粮食安全、灾害响应等最需要这些工具的组织缺乏基础设施，OlmoEarth 旨在缩小这一差距。