Satellite inference on geospatial data is limited by I/O, heterogeneous sources, and scale. We analyze how the OlmoEarth Platform addresses this at the architectural and execution levels.
The problem begins where classic ML pipelines stop scaling. In satellite inference, the input data is not megabytes, but terabytes. A single run can include different sensors, spectral channels, and time slices. The sources are heterogeneous: different projections, resolutions, and incomplete observations due to cloud cover. Meanwhile, the output is a map where each point must be precisely aligned to a coordinate grid. In practice, degradation starts not in the model, but in the data pipeline: downloading and preparing data takes longer than the inference itself. This turns I/O into the main bottleneck and makes GPU usage inefficient.
In the OlmoEarth Platform, a pragmatic choice was made: the pipeline was divided into stages and matched with different hardware. The CPU handles loading, reprojection, and resampling. The GPU is only occupied with inference. This decomposition removes the conflict between expensive computations and heavy I/O. It is a compromise between the complexity of orchestration and the efficiency of resource utilization. Additionally, parameterization is introduced: the degree of parallelism, output resolution, and model size can be adjusted. This allows for balancing cost, latency, and accuracy for specific tasks.
The implementation relies on aggressive parallelism and task isolation. The geographical area is divided into partitions, each processed by a separate worker. The partitions are then broken down into windows, which the model processes independently. This eliminates inter-task dependencies and allows scaling to thousands of instances. Overlapping neighboring partitions removes artifacts at the boundaries when assembling the final raster. In one run, tens of thousands of CPUs and nearly a thousand GPUs were used with a network throughput of over 168 GB/s. Such fan-out significantly reduces wall-clock time but is constrained by cloud quotas, making the level of parallelism a manageable parameter.
A separate class of problems is data discovery and delivery. Satellite inference requires precise scene selection: where, when, and with what quality. For example, minimal cloud cover is important for optical data, while polarization is crucial for SAR. Public STAC catalogs provide a standard interface but cannot handle burst loads from thousands of parallel requests. This was circumvented in the platform through a custom metadata index, which is updated via events (SNS) or polling. This transforms the load on external services from bursts into a steady stream. At runtime, windowed reads from formats like COG and Zarr are used, which eliminates the need to download entire scenes. Only the necessary bytes for a specific window are read. This is critical for reducing latency and network load.
Fault tolerance is built into the execution model. Each task is idempotent and reentrant. If a source is unavailable, data is incomplete, or a task fails, the system retries or switches to an alternative provider. The runner is launched in a separate VM, executes the task, and terminates. Separate monitoring tracks hung processes and restarts them. At this scale, failures are not exceptions but the normal state of the system, and the architecture accounts for this.
Results show that this approach allows for continent-scale satellite inference in about a day, processing tens of terabytes of data at a low cost per square kilometer. Exact quality metrics of the models are not disclosed, but the focus is clearly on execution efficiency and accessibility for organizations without strong engineering teams.
In a broader context, this reflects a trend: geospatial ML is shifting from experimentation to operational systems. The main challenge is no longer in training models but in their operationalization—data delivery, scaling inference, and ensuring reliability. The OlmoEarth Platform is an example of an evolutionary approach where architecture is subordinate to the physics of data, not just the model.