OlmoEarth平台：实现行星级地理空间推理
评分
83详细介绍新兴行星级地理空间AI平台，填补行业空白。
内容结构清晰，但技术细节偏高层未深入核心算法。
开源API和预训练模型可直接用于研究部署，实用性强。
平台刚发布，符合当前地理空间AI热点的时效需求。
来自知名AI研究机构Ai2，经Hugging Face官方博客发布，可信度高。
基础分 83 × T1 信源权重 ×1 = 83
精选线 60已入选精选
精选理由
技术架构新颖，开源策略提升可信度，但缺乏具体性能基准对比。
AI 点评
「这篇博客值得关注，尤其对地理信息科学和遥感团队而言，OlmoEarth提供了从数据到推理的一站式方案。开源生态使其可能成为社区新基准。」
速览
Ai2在Hugging Face博客发布OlmoEarth平台，旨在实现行星级地理空间推理。该平台整合高分辨率卫星影像、地形数据和AI模型，支持大规模环境监测与城市规划，为研究人员提供开源工具与API。
- OlmoEarth支持处理PB级地理空间数据
- 平台包含预训练视觉模型和推理管道
- 开放API便于开发者集成自定义工作流
正文
OlmoEarth平台：行星规模的地理空间推断
Enterprise Article Published July 28, 2026 Upvote -
Kyle Wiggers Ai2Comms Follow 
allenai
🌍 Learn more about OlmoEarth Platform: https://allenai.org/olmoearth
OlmoEarth模型是我们的一系列地球观测基础模型，基于约10TB的多模态卫星数据进行了预训练。政府、非政府组织及其他使命驱动型组织已经在采用OlmoEarth进行包括森林砍伐监测、粮食安全和野火风险等应用。
在Ai2，我们知道如何训练和发布强大的开放模型，对于拥有强大工程团队的组织来说，开放模型就是他们需要的一切。但环境领域的大多数组织——那些最适合应用这些模型的组织——缺乏能够管理完整生命周期的基础设施或工程团队：标注数据、微调模型以及运行大规模推断。我们花了十多年时间运营像Skylight和EarthRanger这样的平台，这些软件是全球用户每天依赖的，因此必须每天正常工作。这段经验教会我们实现影响需要什么：在正确的时间和地点成本有效地运行模型，监控性能，将原始输出转化为可操作的见解，并验证这些输出能推动合作伙伴想要的结果。
这就是我们构建OlmoEarth平台的原因：用于将地理空间模型从微调和评估推进到大规模推断的基础设施。
这种规模的推断带来了自身的一系列挑战。必须跨多个提供商查找和访问卫星图像，对齐不同投影和分辨率，并高效处理。然后，结果必须拼接成地理上一致的图，同时基础设施要从分布式计算的常规故障中恢复。
如今，该平台可以在大约一天内跨大陆规模区域运行推断，处理数十TB的影像，成本仅为每平方公里几美分。开发它意味着要面对一系列工程挑战，其他从事大规模地理空间系统工作的人也可能遇到。这篇文章将逐一介绍这些挑战以及我们得出的解决方案。
最近在OlmoEarth平台上生成的一张野火风险图，附有统计数据。
为何卫星推断具有挑战性
大多数机器学习模型接收几兆字节的数据并在不到一秒内产生结果——想想处理一段文本的LLM或分析手机照片的计算机视觉模型。地球观测推断的规模则截然不同——一个用于最大化性能的微调基础模型的任务可以移动数太字节的数据并运行数小时。输入可能跨越多个光谱波段、传感器类型和时间步长，覆盖一个大地理区域。它们可能来自多个提供商，每个使用不同的投影和分辨率，并且可能包含缺失或被云层遮挡的观测数据。输出本身就是一张图，因此每个预测必须与周围区域保持相同的投影和坐标网格精确对齐。
即使是数据获取也可能是一个重大挑战。预测任务通常花费更多时间下载和准备影像，而不是运行模型本身，这使得高效的数据管道至关重要。这些管道必须处理大容量I/O，同时提供重新投影和重采样影像所需的计算能力。
合适的硬件为合适的任务
由于数据获取和准备通常占据推理任务的大部分运行时间，将这些工作分配给GPU会使系统中最昂贵的硬件去做更适合CPU的任务。因此，我们将每个任务分为三个阶段，每个阶段对应不同的硬件配置：
- 数据获取与预处理（CPU，高I/O）： 获取、重投影、对齐和归一化影像，然后以针对推理期间快速加载进行优化的格式写入。
- 推理（GPU）： 运行模型的前向传播，并将最低限度处理的输出直接写入存储。
- 后处理（CPU）： 将每个窗口的输出拼接在一起，应用掩码或缩放，并以用户友好的格式（如Zarr、GeoTIFF或GeoJSON）导出。
OlmoEarth平台将这些阶段分配到多台机器上，同时保持GPU的充分利用。多进程数据加载器持续为每个GPU提供数据，而完成的输出则直接流式传输到blob存储。
一个请求，数百个工作节点，数千个进程
OlmoEarth Run, 该平台的大规模推理任务执行层，将每个任务覆盖的地理区域划分为适合单个计算实例（工作节点）大小的分区，然后将这些分区进一步细分为OlmoEarth模型处理的更小窗口。由于每个窗口可以在单独的前向传播中独立处理，地图上某部分的工作无需等待另一部分。
在实践中，一个州大小的区域可能会变成一百个左右的分区，而大陆规模的运行则可能变成数千个。相邻分区有轻微重叠，我们在合并输出时消除这种重叠，以便最终栅格中没有接缝。
由于分区是独立的，同一阶段可以同时在数千个计算实例上运行。我们最近使用这种方法生成了覆盖整个北美的野火风险地图。在高峰期，该运行并行使用了约19,600个CPU和994个GPU，网络吞吐量超过168 GB/s。这种并行性将预估的4,737小时串行计算减少到约30.5小时的实际时间——加速比达155倍。
然而，扇出并非无限制。更多的工作节点会受到云配额限制，因此并行度是一个每次运行可调节的旋钮，是我们在单个任务中可以调整的多个参数之一。输出分辨率用数据量和计算换取细节；模型大小用GPU时间换取精度；缓存原始影像则用存储换取同一区域重复运行的速度。正确的设置取决于手头的任务——和预算。
寻找和获取正确的像素
给定地理区域和时间范围，平台首先需要确定哪些卫星场景应输入模型。这意味着要识别不同提供商（具有不同的目录、格式和发布延迟）所捕获的内容、地点和时间。选择标准还取决于数据源：对于光学影像（如Sentinel-2），我们通常希望获得云量最少的场景；而对于合成孔径雷达，可用的极化通道可能更为重要。
我们尽可能依赖公共STAC目录和开放标准。但一个大型推理任务可能同时产生数千个元数据查询——远超ESA或Microsoft Planetary Computer的STAC API等外部服务设计的并发处理能力。
为了避免压垮这些服务，OlmoEarth平台维护自己的元数据索引，并随着新影像的发布而更新。对于通过AWS Open Data托管的数据集，我们会收到每个新场景的SNS通知。如果提供商不提供变更流，我们每隔几分钟轮询其上游索引。结果，我们对外部服务的请求遵循新发布的稳定节奏，而不是大型推理任务产生的突发性冲击。
每个索引条目存储场景元数据以及指向基础像素可用位置的指针。运行时，平台选择最佳源，并针对COG或Zarr等云端优化格式执行窗口化读取，仅检索给定分区所需的字节，而非下载整个场景。
该索引还支持我们的标注工具。由于它以云端优化格式维护指向 Sentinel-1、Sentinel-2、Landsat 和 NISAR 影像的指针，我们可以通过同一窗口化读取系统提供任何已索引场景的切片，而无需构建单独的摄取管道。
使此工作流程最简便的数据提供商具备三个共同特征，我们建议将其作为发布地球观测数据的最佳实践：新影像可用时基于队列的通知、在主流云平台上存储且无定制速率限制或可用性瓶颈，以及支持范围读取的云端优化格式。
大规模故障处理
OlmoEarth Platform 旨在自动从故障中恢复。对于每个阶段和地理分区内的任务，它动态配置一台运行我们 runner Docker 容器的虚拟机。runner 检索任务参数、执行工作、返回结果并关闭。由于每个任务都是可重入且幂等的，间歇性故障可以通过重新运行来安全处理。
在此规模下，故障是预期内的：提供商可能响应缓慢或短暂不可用；元数据可能指示影像存在，但所需波段或窗口缺失；云覆盖可能导致可用观测样本过少；或者任务可能直接崩溃。平台通过任务跟踪、自动重试、在可用时回退到备用提供商、以及明确区分可重试错误与致命错误来应对。一个独立的监控进程检测到已停滞或停止的runner，并重新启动其任务。
未来方向
我们的路线图由合作伙伴识别出的缺口及其最需要的能力所塑造。我们正在努力的领域包括：
- Automated model runs. 提前安排推理作业，或每当影像索引在感兴趣区域注册新场景时触发推理作业。
- Change detection and alerts. 当用户监测的地表景观发生变化时通知用户，使得诸如森林砍伐或洪水等事件以警报形式呈现，而不是需要有人手动查找和检查的栅格数据。
- Agentic tools and interfaces. 智能体可以降低使用地理空间模型的门槛，从数据管理和特征工程到识别改进微调模型的方法。我们希望任何技术水平的用户都能完成以前需要经验丰富的机器学习研究员才能做的工作。
- Faster models. 与我们的研究团队合作，开发更高效的架构，减少每个窗口的GPU时间。
- More modalities. 为OlmoEarth模型及其支持的影像索引添加新的卫星传感器和数据源。我们目前专注于整合天气数据（ERA-5）以及提供环境因素更详细信息的卫星。
- Embeddings. 开发专用的嵌入模型，并在全球范围内预计算嵌入。对于许多任务，针对这些嵌入运行推理可以替代对原始影像的完整前向传递，从而使工作负载大幅加快并降低成本。微调和直接推理对于具有挑战性的任务实现最佳性能仍将重要，但嵌入可以打开更广泛的效率应用。
- Run anywhere. OlmoEarth Run 仅需要能够运行 Docker 镜像的虚拟机以及访问 blob 存储的权限。我们目前在 Google Cloud 上运行，但架构设计支持多云以及在合作伙伴自己的账户和计算环境内部署。
这仅仅是个开始。地理空间基础模型，特别是使其投入运营，仍是一项新兴技术，许多最有可能使用它们的组织——那些从事自然保护、粮食安全、灾害应对和气候工作的组织——从未获得过这样的基础设施。这些团队需要了解地球的知识与其预算和技术资源所能达到的水平之间仍存在巨大差距。
我们正在构建 OlmoEarth 以帮助缩小这一差距。
该作者的更多内容
构建 Shippy 教会了我们关于构建智能体的哪些经验
DiScoFormer：用于密度和分数的统一Transformer，跨分布
社区
EditPreview Upload images, audio, and videos by dragging in the text input, pasting, or clicking here. Tap or paste here to upload images Comment Upvote -相关条目
91
精选LFM2.5-Encoder：面向CPU快速长上下文推理的新模型
这篇博文让我眼前一亮，因为它直接解决了大模型在CPU上跑长上下文的痛点。对于没有高端GPU的团队或个人开发者，LFM2.5-Encoder系列提供了可立即使用的开源方案。尤其推荐给做RAG、文档搜索或代码分析的朋友——现在用普通服务器就能处理百万级token的文档了。
91
精选vLLM推出原生速度Transformers建模后端，大幅提升推理性能
这项更新对于AI工程团队非常关键：无需格式转换意味着能更快地迭代模型，而2-5倍的速度提升直接降低GPU成本。如果你正在做LLM在线服务或者批量推理，这几乎是必读的技术更新。
90
精选前沿实验室代理入侵事件技术时间线：2026年7月事件剖析
这篇技术时间线值得所有AI安全研究员和代理开发者细读——它不只是描述一次攻击，而是为整个行业敲响了代理系统防御体系薄弱的警钟。对正在部署自主代理的团队来说，这是必读的灾难预防手册。
90
精选Nunchaku 4 位扩散推理集成到 Diffusers
这篇博客对正在寻找将扩散模型部署到边缘设备方案的开发者来说，是一个极其重要的参考。Nunchaku的低内存占用和易用性可能会成为未来几周社区讨论的热点。强烈建议所有使用Stable Diffusion做产品或研究的团队仔细阅读集成指南。
90
精选NVIDIA 携手 Hugging Face：使用 NeMo Automodel 大规模微调视频与图像模型
这篇博文最值得看的是它给出了一个开箱即用的分布式微调方案，把NVIDIA的底层工程能力与Diffusers生态无缝衔接。对正在犹豫如何规模化微调视频扩散模型的团队来说，这几乎是目前最直接的参考——不用自己拼装分布式框架，也不用纠结多卡配置，NeMo Automodel替你搞定了。
90
精选模型路由看似简单，实则不然——IBM Research深度解析
这篇文章值得所有关注大模型落地的工程师一读。它没有停留在理论层面，而是给出了可落地的智能路由框架，尤其适合那些正在做多模型推理加速和成本控制的朋友。
89
精选OpenAI研究：AI正在重新定义工作边界
如果你关心AI对实际工作的影响，这篇研究不容错过。它不讨论理论，而是用数据展示ChatGPT用户如何使用AI扩展自己的任务范围，这对HR、管理者以及每个希望提升技能的职场人都有直接启发。
89
精选NVIDIA Nemotron-3 Embed在RTEB基准测试中排名第一，推进智能检索
NVIDIA这次在嵌入模型上的突破非常及时。对于从事RAG和AI Agent开发的团队来说，Nemotron-3 Embed的开源直接提供了目前最强的检索底座，尤其适合需要精准长文本检索的场景。建议开发者尽快在Hugging Face上尝试并评估其在自身数据上的表现。