Ai2 把 19,600 个 CPU + 994 张 GPU 拼成 OlmoEarth：单次推理覆盖整个北美只需 30.5 小时——为什么 Agentic tools 才是地球观测的下一个重点

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

Ai2（Allen Institute for AI）在 Hugging Face 官方博客发布 OlmoEarth Platform——一个把地球观测基础模型从”训练”推到”全球尺度推理”的运行平台。最近一次北美范围 wildfire 风险图推理任务中，他们同时使用约 19,600 个 CPU 核 + 994 张 GPU，网络吞吐 168 GB/s，把原本 4,737 小时 的串行计算压到 30.5 小时（约 155× speedup），单位面积成本”fractions of a penny per km²”。

这不是又一个”更大模型”的新闻。平台把执行层切分成”数据预处理 = CPU + 高 I/O”、”推理 = GPU”、”后处理 = CPU” 三段，每段用合适硬件做合适的事；任务被切成”无依赖的窗口”，每个窗口在独立前向里跑，整个北美级别任务用并行度摊薄到几小时。

对 Agent / 工程团队来说，这件事最值得关注的不是数字本身，而是 Ai2 把 Agentic tools and interfaces 明确写进了下阶段路线图——他们要让任何技术水平的用户都能做”以前需要 ML 研究员”的事。地球观测这条原本”重工程”的赛道，正被重写成”重 Agent”。

官方事实和我的判断要分开：19,600 CPUs / 994 GPUs / 168 GB/s / 4,737h → 30.5h / 155× / 每平方公里几分之一美分，全部来自 Ai2 官方博客；”地球观测重 Agent” 是我从 Roadmap 段读出来的方向，不是官方承诺。

发生了什么

官方文章的标题是 **”The OlmoEarth Platform: Geospatial inference at planetary scale”**，作者是 Ai2 的 Kyle Wiggers，发布于 2026 年 7 月 28 日，原始链接：

Hugging Face 官方博客：The OlmoEarth Platform: Geospatial inference at planetary scale

文章不是只讲模型，而是讲一个平台：OlmoEarth 模型本身已经在 Ai2 内部开源，10 TB 多模态卫星数据预训练，应用于森林砍伐监测、粮食安全和野火风险；这篇文章解决的是”模型怎么被非 AI 团队用起来”。

平台有三个组件：

1
2
3

OlmoEarth models       地球观测基础模型家族（已开源）
OlmoEarth Run          执行层：把大尺度推理任务拆成 worker / window 调度
imagery index          数据索引：给定地理范围 + 时间窗，确定该喂哪些卫星场景

数据规模方面，官方给出的最近一次参考任务是”全北美 wildfire 风险图”——

1
2
3
4
5
6
7

并行 CPU 核         ~19,600
并行 GPU            ~994
网络吞吐            >168 GB/s
串行计算估计        4,737 小时
实际 wall-clock     ~30.5 小时
加速比              约 155x
每平方公里成本      fractions of a penny

这几个数字是官方明确写出的”事实层”；我读到的”工程含义”在后面技术细节那段。

技术细节

1. 三段硬件分工：GPU 不该干 I/O 活

Ai2 把一个推理任务切成三段，每段在不同硬件上跑：

1
2
3
4
5
6
7
8

数据获取与预处理（CPU + 高 I/O）
  -> 抓取、重投影、对齐、归一化卫星影像
  -> 写入推理友好的格式
推理（GPU）
  -> 模型前向，写最小后处理的输出
后处理（CPU）
  -> 拼接、按窗口对齐、遮罩、重采样
  -> 输出 Zarr / GeoTIFF / GeoJSON

关键观察：数据预处理往往占任务运行时间大头——很多任务下载和准备数据的时间比模型推理本身长。如果把 I/O 活也交给 GPU，等于把最贵的硬件用来做 CPU 更擅长的事。OlmoEarth 的解法是：多进程数据加载器持续喂 GPU，输出边算边流到 blob 存储，CPU worker 负责前后处理。

这和 LFM2.5-Encoder 把分类搬回 CPU 是同一种思路的镜像——让合适的硬件干合适的活，不是把活都堆到 GPU 上。

2. Worker / Window 二级切分 + 任务幂等

执行层 OlmoEarth Run 把地理区域切成”partition”，再切成”window”：

1
2
3

地理区域（state → continent）
  -> partition：单个 compute instance 能装下的块
  -> window：单次模型前向能处理的最小块

北美级别的任务会有上千个 partition，每个 partition 内有大量独立 window。因为 window 之间无依赖，每个都能独立前向——

Adjacent partitions overlap slightly, and we reconcile that overlap when the outputs are assembled so no seam appears in the final raster.

也就是说，相邻 partition 留少量重叠，最终拼接时把重叠部分对账，保证地图上不会出现”接缝”。这个细节比看上去重要——任何做”地图级推理”的人都遇到过”两条带状输出拼起来中间有一条空隙”的问题，OlmoEarth 的处理方式是提前重叠、后处理消缝，而不是”事后修补”。

每个任务被包进 Docker runner，由平台动态调度：

For each task within a stage and geographic partition, it dynamically provisions a virtual machine running our runner Docker container. The runner retrieves the task parameters, executes the work, returns the result, and shuts down. Because every task is reentrant and idempotent, intermittent failures can be handled safely by rerunning it.

这意味着：失败是默认假设。Provider 慢、metadata 显示有影像但实际缺波段、云覆盖让可用观测不够、runner 崩溃——任何一种都可以单独重跑，不会污染最终结果。系统还会区分”可重试错误”和”致命错误”，并用一个独立监控进程发现卡死的 runner 后重启任务。

3. 并行度不是越大越好，是 per-run knob

官方明说 fan-out 不是无限制的：

Fan-out is not unbounded, though. More workers push against cloud quotas, so parallelism is a per-run knob, one of several that we can adjust on individual jobs.

也就是说，并行度是每个任务可调的旋钮，不是全局配置。同一平台在不同任务里可能用 19,600 CPUs + 994 GPUs，也可能只用几百 CPU——取决于预算、所需输出分辨率、模型大小、是否要复用缓存影像等。

这给我一个直接的工程含义：把”并行”理解成”每任务配置项”，而不是”基础设施的固定属性”。一旦把它当成”按购买配置”，平台就退化成”又一个数据中心抽象”。

4. 数据索引：把”哪些卫星场景该喂模型”这一步做成平台能力

给定地理区域 + 时间范围，平台要先决定”该调取哪些卫星场景”。这步本身是大问题：不同 provider 的投影、分辨率、波段、云覆盖都不一样。官方给出的处理方式是：

• 多 provider 选择 + 缺数据 fallback
• 处理缺失波段 / 缺失窗口的元数据问题
• 处理云覆盖导致观测不足
• 选择策略在 worker 端根据 imagery index 做决策

这一步不显眼，但是把”非 ML 团队也能用”这件事从口号变成现实的工程基础。

5. Roadmap 写得很坦白：Agentic tools 是下一阶段

官方 Roadmap 直接列出五件事：

1
2
3
4
5

1. Automated model runs            任务可调度、自动触发
2. Change detection and alerts     监测地表变化，主动告警
3. Agentic tools and interfaces    Agent 降低使用门槛
4. Faster models                   减少每窗口 GPU 时间
5. More modalities                 接入 ERA-5 等新数据源

第 3 条是 Agent / 工程团队最该关注的——

Agents can lower the barrier to using geospatial models, from data curation and feature engineering to identifying ways to improve a fine-tuned model. We want users at any technical level to do work that previously required an experienced ML researcher.

翻译一下：Ai2 想让”以前需要 ML 研究员”的工作变成”任何技术水平的人都能做”——通过 Agent。

这和 7-28 Google 发布的 Gemini API Managed Agents 是同一股潮流的两个落点：

• Google 把 Agent 推进 Gemini API，提供 environment hooks（block / lint / audit tool calls）、budget controls、scheduled triggers、free tier access。3.6 Flash 成为 managed agent 的默认模型。
• Ai2 把 Agent 推进地球观测平台，让非 ML 团队用对话或工具编排就能跑大尺度推理。

两个厂商同时把”Agent”和”应用层”绑定到一起，说明 2026 Q3 这个方向已经从概念变成产品节奏。

对 Agent / 工程的影响

第一，”大尺度推理”和”Agent”在 2026 Q3 撞到一起

过去两年 Agent 框架主要解决”怎么让模型用工具”——这是单机问题。但 OlmoEarth 这种平台说明：**Agent 的下一步是”调度大尺度算力”**。一个 Agent 不只是”调一次模型”，而是”调度几千个 worker 跑一次地球级任务，结果聚合回地图”。

这意味着做 Agent 平台的团队需要重新想几件事：

• 任务编排器不能假设”一次调用 = 一次前向”——它要能编排”几千次并行前向 + 聚合 + 异常处理”
• 失败模型要从”调用失败”扩到”worker 崩溃、Provider 缺失、云覆盖、数据延迟”
• 成本模型要从”按 token 计”扩到”按 GPU 小时 + CPU 小时 + 数据下载量计”

第二，”轻工程门槛”将由 Agent 接管

过去地球观测这类应用几乎离不开 ML 研究员做数据清洗、特征工程、微调。Ai2 的 Roadmap 明确说”任何技术水平的人都能做”——靠 Agent。

对工程团队的含义是：自家有”专家依赖型”流程的，应该在 2026 Q4 之前评审一遍哪些步骤可以用 Agent 替代。不是为了让 AI 看起来酷，而是因为如果平台方把这条路走通了，你的内部流程会比外部平台慢一截。

第三，CPU / GPU / I/O 的三段式分工值得复制

把”数据 I/O”和”GPU 推理”放在同一台机器上是一种浪费——GPU 等 I/O，CPU 没事干。OlmoEarth 的解法（多进程数据加载器持续喂 GPU + 输出流到 blob）是工业界早就知道的做法，但官方背书意味着它不再是”我们的特殊优化”，而是”这个领域的事实标准”。

如果你的系统里有”GPU 偶尔卡住等数据”的迹象，可以参考这种 worker / loader 分离的模式。

第四，”几十小时覆盖一个大陆”是一个新基准

30.5 小时覆盖北美、155× speedup、每平方公里几分之一美分——这几个数字构成了一个新基准。即使你做的是完全不同的地理空间任务（不一定是 wildfire 风险），它们定义了一个”什么算大尺度”的参照系。

短期不要碰的情况：

• 你没有几千核的预算。OlmoEarth 这种规模本质上是云上跑，单次任务几千美元起
• 你的任务无法拆成”无依赖窗口”。比如实时追踪移动目标、依赖前一秒输出的预测
• 你需要绝对精度到像素级。155× 加速来自”独立窗口 + 重叠对账”，不是”每个窗口都精确”

我的判断

1. 2026 Q3 是”Agent + 大尺度推理”产品节奏的起点。 Google 把 Agent 推进 API，Ai2 把 Agent 推进地理空间，两件事一起发生不是巧合——Agent 不再只是”工具调用框架”，正在变成”算力调度入口”。
2. 3 段硬件分工 + 任务幂等 + 失败可重试，是这个领域的新范式。 谁把它做成”自家平台默认能力”谁就领先；还停留在”GPU 一次性前向”的团队会在大尺度任务上被甩开。
3. “几十小时覆盖一个大陆”是新的可读基准。 把它记在心里，以后看到 “X 模型对全球卫星影像一次推理” 之类的新闻，先问三个字：”多少核”。

Q&A

Q1：来源和发布日期是什么？

A：来源是 Ai2 在 Hugging Face 发布的官方博客：The OlmoEarth Platform: Geospatial inference at planetary scale，发布日期为 2026 年 7 月 28 日。本文中的 19,600 CPUs、994 GPUs、168 GB/s、4,737h → 30.5h、155× speedup、fractions of a penny per km² 均以官方文章为出处。辅以 7-28 Google 官方博客 Gemini API Managed Agents: 3.6 Flash, hooks, and more。

Q2：怎么验证数字？

A：完整数字以官方文章为唯一出处。如要本地验证架构思路，可用一个小规模对照实验：把”数据加载 + 模型前向 + 后处理”放在同一进程跑，记录三段分别耗时；再把它们拆到不同进程、用共享队列串联，记录总吞吐。对一个有几 GB 输入的小数据集，三段拆分未必明显加速；但只要输入上到几十 GB，就能看到 I/O 与计算重叠带来的加速比。

Q3：适用边界是什么？

A：适用——任务能切成无依赖窗口（地图推理、图像分类切片、卫星影像标注）；失败可被局部重试；有”大尺度但慢”的需求（覆盖大陆级、月度更新）。不适用——强时延敏感（必须毫秒级返回）、强依赖前一窗口结果的递归推理、不可重试的破坏性写入、预算不允许上千核并行的场景。

Q4：和现有方案对比呢？

A：传统”单机 + 单 GPU 推理”是基线，几十 GB 输入往往要跑几天。Kubernetes + 自定义 worker 是常见替代，但要自己处理”任务切分 + 失败重试 + 数据对账”——而 OlmoEarth 把这些都打包成平台能力。Google Earth Engine 是另一个相邻工具，但偏静态分析和已有数据集，不直接跑大模型推理。OlmoEarth 的差异点是把”地理空间基础模型”和”分布式运行平台”绑在一起交付。

Q5：实施时容易踩的雷？

A：1) 把”并行度”当成全局配置而不是 per-run 配置，会被云配额卡死；2) 不做任务幂等就直接重跑，会出现”一半数据双写”；3) 不做”重叠对账”就直接拼接地图，会留下可见接缝；4) 假设 worker 永远健康，不做监控和重启，最终任务会卡死某个 stage。

字数自检：≥1500 个中文字符（不含 frontmatter）
隐私自检：未写入内网 IP、公司名、内部服务名、用户信息
封面 seed：2026-08-01-ai2-olmoearth-19600-cpu-agentic-tools（唯一，不与 AI Diary 共用）
coverWidth/Height：1600 / 900
categories：ai_tech