How AI2s OlmoEarth Platform Achieves 155x Speedup on Planetary-Scale Geospatial Inference

Why Satellite Inference Is Hard

Most ML models ingest megabytes and return a result in milliseconds. Earth observation (EO) inference operates at a completely different scale: a single job fine-tuning a foundation model can move terabytes of data and run for hours. Inputs span multiple spectral bands, sensor types, and time steps across large geographic areas. They come from different providers with varying projections and resolutions, and often include missing or cloud-obscured observations. The output is itself a map—every prediction must remain precisely aligned with the same coordinate grid as its neighbors.

Even data acquisition can dominate runtime. Prediction jobs often spend more time downloading and preparing imagery than running the model itself. Efficient pipelines must handle high-volume I/O while providing compute for reprojection and resampling. This is the core challenge that the OlmoEarth Platform was built to solve.

Key insight: Treat data engineering as a first-class citizen, not an afterthought. The model is only one part of the pipeline.

The Three-Stage Architecture: Right Hardware for the Right Task

Because data acquisition and preparation often dominate runtime, assigning that work to GPUs would waste the most expensive hardware. The platform divides each job into three stages, each matched to a distinct hardware profile:

The platform distributes these stages across many machines while keeping GPUs fully utilized. Multiprocess data loaders continuously feed each GPU, and completed outputs stream directly to blob storage.

One Request, Hundreds of Workers, Thousands of Processes

OlmoEarth Run (the execution layer) divides the geographic region into partitions sized for individual compute instances, then subdivides those into smaller windows processed independently. Adjacent partitions overlap slightly; the overlap is reconciled during assembly so no seam appears in the final raster.

A state-sized area might become ~100 partitions; a continent-scale run can become thousands. Because partitions are independent, the same stage can run across thousands of instances simultaneously.

Real-world numbers: A wildfire-risk map covering all of North America used ~19,600 CPUs and 994 GPUs in parallel, with network throughput exceeding 168 GB/s. This reduced an estimated 4,737 hours of serial compute to about 30.5 hours of wall-clock time—a 155× speedup.

Fan-out is not unbounded. More workers push against cloud quotas, so parallelism is a per-run knob. Other tunable trade-offs include output resolution (data volume vs. detail), model size (GPU time vs. accuracy), and caching raw imagery (storage vs. speed across repeated runs).

# Example: conceptual partitioning logic (not actual OlmoEarth code)
def partition_region(bbox, max_workers):
    """Split a bounding box into roughly equal-area partitions."""
    # Simplified: assume square region for illustration
    side = int(max_workers ** 0.5)
    lat_step = (bbox['max_lat'] - bbox['min_lat']) / side
    lon_step = (bbox['max_lon'] - bbox['min_lon']) / side
    partitions = []
    for i in range(side):
        for j in range(side):
            partitions.append({
                'min_lat': bbox['min_lat'] + i * lat_step,
                'max_lat': bbox['min_lat'] + (i + 1) * lat_step,
                'min_lon': bbox['min_lon'] + j * lon_step,
                'max_lon': bbox['min_lon'] + (j + 1) * lon_step,
            })
    return partitions

Pro tip: When building large-scale geospatial pipelines, always design for idempotency and reentrancy. Failures are the norm, not the exception.

Finding and Fetching the Right Pixels (and Handling Failure)

Given a region and time range, the platform must determine which satellite scenes to use. That means identifying what was captured, where, and when across providers with different catalogs, formats, and publication delays. Selection criteria depend on the source: for optical imagery like Sentinel-2, least-cloudy scenes are preferred; for synthetic aperture radar, polarization channels may matter more.

The platform relies on public STAC catalogs and open standards where possible. But a large job can generate thousands of metadata queries at once—far more than external services like ESA's or Microsoft Planetary Computer's STAC APIs are designed to handle concurrently. To avoid overwhelming those services, OlmoEarth maintains its own metadata index, updated as new imagery is published. For AWS Open Data datasets, SNS notifications trigger updates; otherwise, polling occurs every few minutes. Each index entry stores scene metadata and pointers to every location where pixels are available. At runtime, the platform selects the best source and performs windowed reads against cloud-optimized formats (COG, Zarr), retrieving only the bytes needed for a given partition.

Handling Failure at Scale

The platform is designed to recover automatically. Each task dynamically provisions a VM running a Docker container that retrieves parameters, executes work, returns results, and shuts down. Because every task is reentrant and idempotent, intermittent failures are handled safely by rerunning. The system distinguishes retryable vs. fatal errors, falls back to alternate providers when available, and uses a separate monitoring process to detect and restart stalled runners.

Best practices for publishing EO data (derived from providers that made this workflow easiest):

• Queue-based notifications when new imagery becomes available
• Storage on major cloud platforms without bespoke rate limits
• Cloud-optimized formats supporting ranged reads

Critical caveat: This architecture assumes reliable cloud infrastructure and may not be feasible for organizations with limited budgets or on-premise constraints. The platform is currently operated on Google Cloud, though the design supports multi-cloud and on-prem deployments.

Conclusion & Next Steps

AI2's OlmoEarth Platform demonstrates that operationalizing geospatial foundation models requires as much engineering rigor as model development. The key takeaways:

• Separate concerns by hardware profile (CPU for I/O, GPU for inference) to maximize utilization.
• Partition aggressively and design every task to be idempotent and reentrant.
• Maintain your own metadata index to avoid overwhelming external APIs.
• Treat failures as expected and build automatic recovery from day one.

The platform currently runs continent-scale inference in ~1 day at fractions of a penny per km². The roadmap includes automated model runs, change detection alerts, agentic tools, faster architectures, more modalities (weather data, new sensors), global-scale embeddings, and multi-cloud/on-prem deployment.

For teams building similar systems, the biggest lesson is to invest in data pipelines early—they will dominate your runtime and your costs. Start with a small region, measure where time is spent, and optimize the bottleneck first.

Further reading:

• How the Python Official Blog Moved from Blogger to Git: A Case Study in Open Source Infrastructure
• How Meta Uses Bayesian Optimization to Design Concrete Mixes at Scale

Source: OlmoEarth Platform blog post