Hugging Face、地球規模の地理空間推論プラットフォーム「OlmoEarth」を発表

Back to Articles

• Why satellite inference is challenging
• The right hardware for the right task
• One request, hundreds of workers, and thousands of processes
• Finding and fetching the right pixels
• Handling failure at scale
• Where we're headed

🌍 Learn more about OlmoEarth Platform: https://allenai.org/olmoearth

The OlmoEarth models are our family of Earth observation foundation models, pretrained on roughly 10 terabytes of multimodal satellite data. Governments, NGOs, and other mission-driven organizations are already adapting OlmoEarth for applications including deforestation monitoring, food security, and wildfire risk.

At Ai2, we know how to train and release powerful open models, and for organizations with strong engineering teams, an open model is all they need to run with. But most organizations in the environmental space – the ones best placed to apply these models – don't have the infrastructure or engineering teams that can manage the full lifecycle: labeling data, fine-tuning models, and running large-scale inference. We’ve spent more than a decade operating platforms like Skylight and EarthRanger, software that users around the world rely on every day, so it has to work every day. That experience taught us what delivering impact takes: running models cost-effectively at the right time and place, monitoring performance, turning raw outputs into actionable insights, and verifying those outputs drive the outcomes partners want.

That’s why we built the OlmoEarth Platform: infrastructure for taking geospatial models from fine-tuning and evaluation to large-scale inference.

Inference at this scale presents its own set of challenges. Satellite imagery must be found and accessed across multiple providers, aligned across projections and resolutions, and processed efficiently. Results then have to be stitched into geographically consistent maps while the infrastructure recovers from the routine failures of distributed computing.

Today, the platform can run inference across continent-scale areas in roughly a day, processing dozens of terabytes of imagery at a cost of fractions of a penny per square kilometer. Developing it meant confronting a series of engineering challenges that others working on large-scale geospatial systems are likely to encounter as well. This post walks through those challenges and the solutions we arrived at.

*A recent wildfire risk map generated on the OlmoEarth Platform, with statistics.*

Why satellite inference is challenging

Most ML models take in a few megabytes of data and produce a result in under a second—think LLMs processing a paragraph of text or computer vision models analyzing a photo from a smartphone. Earth observation inference operates at a very different scale—a single job fine-tuning a foundation model for maximum performance can move terabytes of data and run for hours. The inputs may span multiple spectral bands, sensor types, and time steps across a large geographic area. They can come from several providers, each using different projections and resolutions, and may include observations that are missing or obscured by clouds. The output is itself a map, so every prediction must remain precisely aligned with the same projection and coordinate grid as the areas around it.

Even acquiring the data can be a major challenge. Prediction jobs often spend more time downloading and preparing imagery than running the model itself, making efficient data pipelines critical. Those pipelines must handle high-volume I/O while providing the compute needed to reproject and resample imagery.

The right hardware for the right task

Because data acquisition and preparation often dominate an inference job’s runtime, assigning that work to GPUs would leave the system’s most expensive hardware doing tasks better suited to CPUs. We therefore divide each job into three stages, each matched to a distinct hardware profile:

• Data acquisition and preprocessing (CPU, high I/O): Fetch, reproject, align, and normalize imagery, then write it in a format optimized for fast loading during inference.

• Inference (GPU): Run the model’s forward pass and write minimally processed outputs directly to storage.

• Postprocessing (CPU): Stitch the per-window outputs together, apply masks or rescaling, and export them in user-friendly formats such as Zarr, GeoTIFF, or GeoJSON.

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

One request, hundreds of workers, and thousands of processes

OlmoEarth Run, the platform’s execution layer for large-scale inference jobs, divides the geographic region covered by each job into partitions sized for individual compute instances (workers), then subdivides those partitions into smaller windows that the OlmoEarth models process. Because each window can be handled independently in a separate forward pass, work on one part of the map does not need to wait for another.

In practice, a state-sized area might become a hundred or so partitions, while a continent-scale run can become thousands. Adjacent partitions overlap slightly, and we reconcile that overlap when the outputs are assembled so no seam appears in the final raster.

Because the partitions are independent, the same stage can run across thousands of compute instances at once. We recently used this approach to generate 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 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, though. More workers push against cloud quotas, so parallelism is a per-run knob, one of several that we can adjust on individual jobs. Output resolution trades data volume and compute for detail; model size trades GPU time for accuracy; caching raw imagery trades storage for speed across repeated runs over the same area. The right setting depends on the task – and budget – at hand.

Finding and fetching the right pixels

Given a geographic region and time range, the platform first has to determine which satellite scenes should feed the model. That means identifying what was captured, where, and when across providers with different catalogs, formats, and publication delays. The selection criteria also depend on the source: for optical imagery such as Sentinel-2, we generally want the least-cloudy scenes available, while for synthetic aperture radar, the available polarization channels may matter more.

We rely on public STAC catalogs and open standards wherever possible. But a large inference job can generate thousands of metadata queries at once—far more than external services such as ESA’s or Microsoft Planetary Computer’s STAC APIs are designed to handle concurrently.

To avoid overwhelming those services, the OlmoEarth Platform maintains its own metadata index, updated as new imagery is published. For datasets hosted through AWS Open Data, we receive an SNS notification for each new scene. When a provider does not offer a change stream, we poll its upstream index every few minutes. As a result, our requests to external services follow the steady pace of new publications rather than the sudden burst generated by a large inference job.

Each index entry stores scene metadata along with pointers to every location where the underlying pixels are available. At runtime, the platform selects the best source and performs windowed reads against cloud-optimized formats such as COG or Zarr, retrieving only the bytes needed for a given partition rather than downloading entire scenes.

The index also supports our annotation tools. Because it maintains pointers to Sentinel-1, Sentinel-2, Landsat, and NISAR imagery in cloud-optimized formats, we can serve tiles from any indexed scene through the same windowed-read system, without building a separate ingestion pipeline.

The providers that made this workflow easiest shared three characteristics that we would recommend as best practices for publishing Earth observation data: queue-based notifications when new imagery becomes available, storage on major cloud platforms without bespoke rate limits or availability bottlenecks, and cloud-optimized formats that support ranged reads.

*A sample query against the OlmoEarth satellite imagery index, searching for the least-cloudy Sentinel-2 image over San Francisco during the first week of June. The service returns the best available image along with a pointer to the GeoTIFF file in an Amazon S3 bucket.*

Handling failure at scale

The OlmoEarth Platform is designed to recover from failures automatically. 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.

At this scale, failures are expected: a provider may be slow or briefly unavailable; metadata may indicate that imagery exists even when a required band or window is 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 when available, and clear distinctions between retryable and fatal errors. A separate monitoring process detects runners that have stalled or stopped and restarts their tasks.

Where we're headed

Our roadmap is shaped by the gaps our partners have identified and the capabilities they need most. Among the areas we are working on:

• Automated model runs. Schedule inference jobs in advance or trigger them whenever the imagery index registers a new scene over an area of interest.

• Change detection and alerts. Notify users when the landscapes they monitor change, so events such as deforestation or flooding surface as alerts rather than rasters someone has to find and inspect manually.

• Agentic tools and interfaces. 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.

• Faster models. Work with our research team on more efficient architectures that reduce GPU time per window.

• More modalities. Add new satellite sensors and data sources to both the OlmoEarth models and the imagery index that supports them. We’re currently focused on incorporating weather data (ERA-5) and satellites that provide more detail on environmental factors.

• Embeddings. Develop a dedicated embedding model and precompute embeddings at global scale. For many tasks, running inference against those embeddings could replace a full forward pass over raw imagery, making workloads substantially faster and less expensive. Fine-tuning and direct inference will remain important for maximum performance on challenging tasks, but embeddings could open up a much broader range of efficient applications.

• Run anywhere. OlmoEarth Run requires only virtual machines capable of running a Docker image and access to blob storage. We currently operate it on Google Cloud, but the architecture is designed to support multiple clouds and deployments within a partner’s own account and compute environment.

This is only the beginning. Geospatial foundation models, and especially operationalizing them, are still an emerging technology, and many of the organizations best positioned to use them – those working in conservation, food security, disaster response, and climate – have never had access to infrastructure like this. The gap between what these teams need to understand about the planet and what their budgets and technical resources allow them to do remains wide.

We are building OlmoEarth to help close it.