Ai2 launches OlmoEarth Platform for planetary-scale satellite inference

Ai2 has released the OlmoEarth Platform, infrastructure for taking its OlmoEarth family of Earth observation foundation models from fine-tuning and evaluation through to large-scale inference. The OlmoEarth models are pretrained on roughly 10 terabytes of multimodal satellite data, and governments, NGOs, and other mission-driven organizations are already adapting them for deforestation monitoring, food security, and wildfire risk. Ai2 built the platform because most organizations in the environmental space, the ones best placed to apply these models, do not have the infrastructure or engineering teams to manage the full lifecycle of labeling data, fine-tuning models, and running inference at scale. The company draws on more than a decade running platforms such as Skylight and EarthRanger. As of the post, the platform can run inference across a continent-scale area in roughly a day, processing dozens of terabytes of imagery at a cost of fractions of a penny per square kilometer.

Each inference job is split into three stages matched to different hardware. Data acquisition and preprocessing, which fetches, reprojects, aligns, and normalizes imagery, runs on CPUs because it is dominated by high-volume input and output rather than computation. Inference, the model's forward pass, runs on GPUs, which write minimally processed outputs directly to storage. Postprocessing, which stitches per-window outputs together, applies masks or rescaling, and exports results as Zarr, GeoTIFF, or GeoJSON, again runs on CPUs. Multiprocess data loaders keep GPUs continuously fed. The execution layer, called OlmoEarth Run, divides the geographic region of a job into partitions sized for individual compute instances, then subdivides each partition into smaller windows that the model processes independently in separate forward passes, so no window has to wait on another. A state-sized area typically becomes about a hundred partitions, while a continent-scale run can become thousands; adjacent partitions overlap slightly, and that overlap is reconciled when outputs are assembled so no seam appears in the final map.

Ai2 gives one concrete example: a wildfire-risk map covering all of North America. At peak, the run used roughly 19,600 CPUs and 994 GPUs in parallel, with network throughput exceeding 168 GB/s. That level of parallelism cut an estimated 4,737 hours of serial compute to about 30.5 hours of wall-clock time, a 155x speedup. Parallelism itself is capped by cloud quotas, so it is one of several settings a job can tune; others include output resolution, which trades data volume and compute for detail, model size, which trades GPU time for accuracy, and caching of raw imagery, which trades storage for speed on repeated runs over the same area.

Finding the right imagery is its own problem. Given a region and time range, the platform has to identify which satellite scenes to use across providers with different catalogs, formats, and publication delays; for optical imagery such as Sentinel-2 it generally wants the least-cloudy scenes, while for synthetic aperture radar the available polarization channels matter more. Public STAC catalogs and open standards are the default, but a single large inference job can generate thousands of metadata queries at once, more than external services such as ESA's or Microsoft Planetary Computer's STAC APIs are built to handle concurrently. To avoid overwhelming those services, the OlmoEarth Platform keeps its own metadata index: it gets an SNS notification for each new scene from providers hosted through AWS Open Data, and polls other providers' indexes every few minutes when no change stream is offered. At runtime, the platform performs windowed reads against cloud-optimized formats such as COG or Zarr, pulling only the bytes a given partition needs rather than downloading whole scenes. The same index serves Sentinel-1, Sentinel-2, Landsat, and NISAR imagery to the platform's annotation tools. Ai2 recommends three practices to Earth observation data publishers based on what made this workflow easiest: queue-based notifications for new imagery, storage on major cloud platforms without bespoke rate limits, and cloud-optimized formats that support ranged reads.

The platform is built to recover from failure automatically. Each task within a stage and geographic partition runs in a dynamically provisioned virtual machine running a runner Docker container that fetches its parameters, does the work, returns the result, and shuts down; because tasks are reentrant and idempotent, intermittent failures can be handled simply by rerunning them. At this scale, failures are expected: a provider may be slow or briefly unavailable, metadata may claim imagery exists when a required band or window is actually missing, cloud cover may leave too few usable observations, or a task may crash outright. The platform responds with task tracking, automatic retries, fallback to alternate providers where available, and a distinction between retryable and fatal errors, while a separate monitoring process detects stalled or stopped runners and restarts their tasks.

Ai2 lists several items on its roadmap: scheduling inference jobs in advance or triggering them automatically when new imagery arrives; change detection that turns events such as deforestation or flooding into alerts instead of rasters someone has to inspect manually; agentic tools meant to let users without ML research experience curate data and improve fine-tuned models; faster model architectures that cut GPU time per window; more satellite sensors and data sources, including ERA-5 weather data; a dedicated embedding model precomputed at global scale, which could let many tasks run against embeddings instead of a full forward pass over raw imagery; and support for running the platform on clouds other than its current one. The platform currently runs on Google Cloud, though Ai2 says the architecture is designed to support multiple clouds and deployment inside a partner's own account.

Key facts

The OlmoEarth models are pretrained on roughly 10 terabytes of multimodal satellite data and are already used by governments, NGOs, and other mission-driven organizations for deforestation monitoring, food security, and wildfire risk.
The OlmoEarth Platform can run inference across a continent-scale area in about a day, processing dozens of terabytes of imagery at a cost of fractions of a penny per square kilometer.
A North America wildfire-risk map run peaked at about 19,600 CPUs and 994 GPUs with over 168 GB/s of network throughput, cutting an estimated 4,737 hours of serial compute to about 30.5 hours, a 155x speedup.
Each job splits into a CPU stage for data acquisition and preprocessing, a GPU stage for inference, and a CPU stage for postprocessing, so the most expensive hardware only runs the model's forward pass.
The platform runs on Google Cloud today; Ai2's roadmap includes scheduled and triggered runs, change-detection alerts, agentic tools, more satellite sensors, a global embedding model, and multi-cloud support.

Why it matters

Open Earth observation models exist, but Ai2 argues that only organizations with strong engineering teams can put them to work end to end: labeling data, fine-tuning, and running inference at scale. Most organizations best placed to apply these models, in conservation, food security, disaster response, and climate work, do not have that infrastructure. The OlmoEarth Platform is Ai2's attempt to close that gap between what these teams need to know about the planet and what their budgets and technical resources let them do.

Who it affects

Governments, NGOs, and other mission-driven organizations that are already adapting OlmoEarth for deforestation monitoring, food security, and wildfire risk are the direct users. Earth observation data providers are affected too: Ai2 names the practices that made its own data pipeline work best, queue-based notifications for new imagery, storage on major cloud platforms without bespoke rate limits, and cloud-optimized formats that support ranged reads, as a template for how such data should be published.

How to use it

The platform's execution layer, OlmoEarth Run, splits each job into partitions and smaller windows that can run independently across many machines, with a three-stage CPU-GPU-CPU pipeline and outputs exported as Zarr, GeoTIFF, or GeoJSON. Users can tune parallelism, output resolution, model size, and imagery caching to trade cost against speed and detail. It runs on Google Cloud today; Ai2 says the architecture is designed to support other clouds and deployment inside a partner's own account. The source gives a processing cost, fractions of a penny per square kilometer, but no platform pricing or subscription terms.

How solid is it

The post is a first-party account from Ai2 with specific, checkable figures: about 10 terabytes of pretraining data, continent-scale inference in about a day, and a North America wildfire-risk run that used roughly 19,600 CPUs and 994 GPUs at over 168 GB/s, cutting 4,737 hours of serial compute to about 30.5 hours. These numbers come from Ai2 itself rather than an independent benchmark, but they are concrete and specific rather than vague marketing claims.

Risks and caveats

This is a vendor blog post announcing Ai2's own product, so the performance and cost figures are self-reported rather than independently verified. Several of the platform's stated capabilities, such as automated triggered runs, change-detection alerts, agentic tools, and the planned embedding model, are roadmap items Ai2 is still working on, not features available today.

“Geospatial foundation models, and especially operationalizing them, are still an emerging technology, and many of the organizations best positioned to use them have never had access to infrastructure like this.”

— Ai2, OlmoEarth Platform blog post