Imagine a researcher attempting to generate a high-resolution wildfire risk map for the entirety of North America. In a traditional serial processing environment, this task is a logistical nightmare, requiring 4,737 hours of continuous computation. For most teams, this means a project that takes months to complete, rendering the resulting data nearly obsolete by the time it is produced. The bottleneck is not just the complexity of the AI model, but the sheer physical scale of the geospatial data involved. This week, the industry is looking at a fundamental shift in how we handle continental-scale inference, moving away from the slow crawl of serial processing toward a massively parallelized infrastructure that treats the earth as a series of computable partitions.

The Architecture of Continental Scale Inference

OlmoEarth has fundamentally rewritten the timeline for geospatial AI by compressing those 4,737 hours of computation into just 30.5 hours. This 155x speedup transforms a multi-month ordeal into a task that can be completed in roughly a day. To achieve this, the OlmoEarth platform does not simply rely on a larger model, but on a sophisticated infrastructure designed for massive parallelization. During peak operation, the system deploys a staggering array of hardware, utilizing 19,600 CPUs and 994 GPUs working in concert. This hardware orchestration allows the platform to maintain a network throughput exceeding 168GB per second, effectively eliminating the data starvation that typically plagues large-scale AI workloads.

The platform operates by breaking the target geographic area into independent partitions. By executing the same processing steps across thousands of computing instances simultaneously, OlmoEarth bypasses the limitations of serial execution. This approach allows for the processing of tens of terabytes of satellite imagery while keeping the operational cost remarkably low, suppressing the expense to less than one penny per square kilometer. The system is designed to be autonomous in its data selection, automatically determining which satellite scenes to feed into the model based on the user's specified geographic region and time window. It analyzes catalogs from various providers, accounting for different data formats and publishing latencies to extract the most relevant imagery.

Data selection is not a one-size-fits-all process. For Sentinel-2 imagery, the system prioritizes scenes with the lowest cloud cover to ensure visual clarity. For Synthetic Aperture Radar (SAR) data, the selection is based on the availability of specific polarization channels. Once the data is curated, the platform enters the parallel inference phase. To ensure the system does not collapse under its own scale, OlmoEarth employs an automated recovery mechanism. It dynamically assigns virtual machines running Runner Docker instances to each task and geographic partition. If a specific instance fails, the system does not halt the entire pipeline; instead, it automatically restarts the failed unit, ensuring the integrity and completion of the overall computation.

Solving the GPU Idle Crisis and the I/O Bottleneck

While the raw numbers of CPUs and GPUs are impressive, the real innovation lies in how OlmoEarth manages the relationship between these resources. In most AI pipelines, GPUs are often wasted because they spend a significant portion of their time waiting for data to be read from a disk or transferred over a network. Because GPUs are expensive to rent and operate, any idle time is a direct financial loss. OlmoEarth solves this by implementing a strict three-stage hardware profile that separates data preparation, model inference, and result merging.

In this architecture, the CPU handles the heavy lifting of data acquisition and preparation. Loading massive satellite files from the cloud and preprocessing them is an I/O-intensive task, not a compute-intensive one. By assigning these tasks to the CPU, OlmoEarth ensures that the GPU is never waiting for a file to load. The platform utilizes multi-process data loaders that read data into a queue on the CPU side, allowing the GPU to consume that data instantly for tensor operations. Once the inference is complete, the output is handed back to the CPU for the merging phase. To further eliminate bottlenecks, the system skips local disk temporary storage and streams results directly to Blob Storage. This memory-to-storage pipeline ensures that the GPU can immediately pivot to the next data window without waiting for a disk write to finish.

Beyond hardware allocation, OlmoEarth addresses a critical software bottleneck: the metadata query limit. Most large-scale inference tasks rely on the SpatioTemporal Asset Catalog (STAC) standard. However, relying solely on external STAC APIs from providers like the ESA or Microsoft Planetary Computer leads to inevitable rate-limiting and pipeline crashes when thousands of parallel windows are being processed. To circumvent this, OlmoEarth maintains its own internal metadata index. For AWS Open Data datasets, the system uses Simple Notification Service (SNS) to update its index the moment a new scene is published. For other providers, it polls the top-level index every few minutes.

This internal indexing allows the platform to perform windowed reads using Cloud Optimized GeoTIFF (COG) and Zarr formats. Instead of downloading an entire multi-gigabyte satellite image, the system uses HTTP range requests to extract only the specific bytes needed for a particular model window. This drastically reduces network I/O load and accelerates loading speeds, as the model only receives the precise pixels required for its current forward pass.

Geographic Partitioning and the Logic of the Run

The execution of an OlmoEarth Run is a study in spatial decomposition. The system divides the entire target geographic area into partitions sized according to the memory and compute capacity of the individual worker instances. These partitions are further subdivided into smaller windows that the model can process in a single pass. Because each window is independent, thousands of these operations occur simultaneously across the cluster. The scale of this partitioning is fluid; a task covering a single US state might require 100 partitions, while a continental-scale project expands to thousands.

To prevent the final map from looking like a patchwork quilt, OlmoEarth implements overlapping boundaries between adjacent partitions. This ensures data continuity across the edges of the compute units. During the final assembly of the pixel-based grid image, the system adjusts these overlaps to eliminate seams or discontinuities, resulting in a geographically consistent map. Operators can fine-tune this process using three primary control knobs: output resolution, model size, and original image caching. Higher resolution increases detail but extends computation time, while model size allows for a trade-off between inference speed and accuracy. Caching settings balance the use of storage space against read speeds.

This infrastructure was built to support foundation models trained on approximately 10 terabytes of multimodal satellite data. Such models are essential for critical applications like deforestation monitoring, food security analysis, and wildfire risk assessment. Because the output is a map, every prediction must be precisely aligned with the surrounding area's projection and coordinate grid. Minimizing the overhead of coordinate transformation is vital, as the precision of integrating multi-sensor data into a single coordinate system determines the ultimate accuracy of the analysis.

Ultimately, the success of the OlmoEarth platform demonstrates that the ceiling for geospatial AI is not defined by raw GPU TFLOPS. Instead, the true limit is the efficiency of the data distribution architecture. By adopting cloud-optimized formats like COG and Zarr and eliminating unnecessary data movement, OlmoEarth proves that the path to continental-scale intelligence lies in the optimization of the I/O pipeline rather than the sheer size of the compute cluster.