OlmoEarth Platform is the infrastructure that makes it possible to run Earth-observation models at continental and planetary scale. Does that sound far away? It isn’t: governments and NGOs are already adapting these models to monitor deforestation, food security, and fire risk.
What OlmoEarth is and why it matters
OlmoEarth are foundational models trained on roughly 10 terabytes of multimodal satellite data. But Ai2 didn’t stop at publishing models: they built a full platform to take those models from fine-tuning to large-scale inference, designed for organizations that don’t have big engineering teams.
Why should you care? Because the gap between open models and the operational capacity of the people who steward the planet is real. OlmoEarth narrows that gap by offering pipelines, distributed execution, and verification tools to turn predictions into decisions.
Why satellite inference is a different problem
Most ML models work with megabytes and return results in seconds. Earth-observation inference runs on terabytes and can take hours. Multiple spectral bands, different sensors, time series, and clouds that hide data all coexist here.
Also, the output is a map. That demands precise alignment in projection and the same coordinate grid so you don’t get geospatial glitches when stitching results together.
In many projects, you spend more time downloading and preparing images than running the model. That’s why data pipelines are so critical.
Architecture: the right hardware for each task
To spend your budget wisely, we split each job into three stages and assign the right hardware to each:
- Acquisition and preprocessing (CPU, high I/O): search, reproject, align, and normalize images; write them in formats optimized for inference.
- Inference (GPU): model forward pass; write minimally processed outputs to storage.
- Postprocessing (CPU): stitch windows, apply masks, scale results and export to
Zarr,GeoTIFForGeoJSON.
Multiprocess loaders keep GPUs fed while results stream directly to blob storage. That avoids letting your GPU do work that CPUs are better at.
OlmoEarth Run: controlled fan-out to thousands of workers
The execution layer, OlmoEarth Run, splits a region into partitions suitable for each instance and then into windows the model processes independently. That lets a large map be processed in parallel without one window blocking another.
A concrete example: to generate a fire-risk map for all of North America, they used about 19,600 CPUs and 994 GPUs simultaneously, with network throughput exceeding 168 GB/s. What would have been 4,737 hours of serial compute was reduced to 30.5 hours of wall time — a 155× speedup.
But fan-out isn’t infinite. Practical limits include cloud quotas, costs, and the relationship between resolution and data volume. The platform exposes those parameters so you can tune parallelism, resolution, model size, and caching according to your budget and goals.
How they find and read the right pixels
Given an area and time range, the platform needs to know which satellite scenes exist, where and when, and pick the best ones per source. For optical images like Sentinel-2 you usually pick the scene with the fewest clouds; for radar, polarization matters.
To avoid peaky queries against external catalogs, OlmoEarth maintains its own metadata index. It receives notifications (for example SNS for datasets in AWS Open Data) or polls when there are no change streams. Each index entry stores metadata and pointers to all locations where the pixels live.
At runtime it uses windowed reads against cloud-optimized formats like COG or Zarr, retrieving only the bytes needed for a partition instead of downloading whole scenes.
Practical recommendation for data providers: push queue notifications when a new image arrives, store in public cloud buckets without access limits, and use formats that allow range reads.
Fault tolerance: design for the inevitable
At planetary scale, failures are the norm. Slow providers, inconsistent metadata, missing bands, clouds, or task failures are expected. The platform runs tasks on ephemeral VMs with a Docker runner. Each task is reentrant and idempotent to allow safe retries.
Mechanisms in place:
- Task tracking and automatic retries.
- Fallback to alternate providers when possible.
- A monitor that detects stuck runners and restarts tasks.
- Clear distinction between retryable errors and fatal errors.
This turns a fragile mesh of components into a robust system that can finish large runs without constant human intervention.
Where they are headed: technical roadmap
Ai2 outlines several workstreams with direct technical impact:
- Automatic runs: scheduled jobs or triggers when a new scene enters the index.
- Change detection and alerts: so a relevant event arrives as a notification instead of as a raster nobody checks.
- Agentic tools: agents to help with data curation, feature engineering, and suggestions to improve fine-tuning.
- Faster models: architectures that reduce GPU time per window.
- More modalities: integrate ERA-5 and other sensors to enrich inputs.
- Global embeddings: precompute embeddings at global scale for fast queries that avoid running the full model every time.
- Run anywhere:
OlmoEarth Runruns wherever there are VMs and blob storage; today on Google Cloud, but designed for multicloud or partner-account deployments.
What this means for organizations on the ground
It means conservation teams, disaster responders, or food-security programs can access powerful models without rebuilding the whole machinery behind them. It means affordable inference — fractions of a cent per square kilometer in some runs — and the ability to turn data into alerts and actions.
It also raises questions: how do you audit results at scale? how do you balance cost and resolution? OlmoEarth appeals to collaboration and transparency to iterate on those questions with partners.
OlmoEarth is not just a model; it’s an infrastructure proposal so geospatial intelligence stops being esoteric and becomes operational in the hands of those who make decisions on the land.