推荐这篇文章，Allen AI 的洲际级卫星推理基础设施。 一次覆盖北美的野火地图——用了一万多个 CPU、近千个 GPU 并行，加速超过一百倍。 Allen AI 在 7 月 28 日发布了 OlmoEarth Platform 的工程博客——一个能在一天内完成洲际规模卫星影像推理的基础设施。这篇博客的价值在于详细坦白了一系列工程挑战和解决方案。 为什么卫星推理这么难 卫星推理和普通 ML 推理的规模完全不同。一次对基础模型的微调可能移动数 TB 数据并运行数小时。输入可能跨越多个光谱波段、传感器类型和时间步长，来自多个供应商，使用不同投影和分辨率。输出本身就是一张地图——每个预测必须与周围区域的投影和坐标网格精确对齐。 即使只是获取数据也是一大挑战：预测作业花在下载和准备影像上的时间往往超过运行模型本身。 三层硬件分工 OlmoEarth 将每个作业分为三个阶段，各匹配不同硬件： • 数据获取和预处理（CPU，高 I/O）：获取、重投影、对齐、归一化影像 • 推理（GPU）：运行模型前向传播 • 后处理（CPU）：拼接各窗口输出、应用掩码、导出 GeoTIFF/GeoJSON/Zarr 分区并行策略 OlmoEarth Run 将每个作业覆盖的地理区域划分为机器大小的分区，再细分为模型可处理的窗口。每个窗口独立处理，互不等待。大陆级运行可产生数千个分区。相邻分区略微重叠，在组装时消除接缝。 一个实际案例：生成覆盖整个北美的野火风险地图。峰值时使用约 19600 个 CPU 和 994 个 GPU 并行，网络吞吐量超 168 GB/s。将预计的 4737 小时串行计算压缩到约 30.5 小时——155 倍加速。 避免压垮外部服务 大规模推理作业可产生数千个同步元数据查询，远超 ESA 或 Microsoft Planetary Computer 的 STAC API 设计承载。OlmoEarth 维护自己的元数据索引，通过 SNS 通知和定期轮询保持更新。对外部服务的请求遵循新发布数据的稳定节奏，而非推理作业的突发流量。 故障处理 每个任务动态配置 VM 运行 runner Docker 容器。因为每个任务是可重入和幂等的，间歇性故障可以安全地重试。平台处理：供应商缓慢或暂时不可用、元数据与实际影像不匹配、云层覆盖导致可用观测不足、任务崩溃。独立的监控进程检测停滞或停止的 runner 并重启其任务。 原文： #GeospatialAI# #SatelliteInference# #Infrastructure#