OlmoEarth Takes Remote Sensing Inference Global

Ai2 (the Allen Institute for AI) recently unveiled the infrastructure design for the OlmoEarth Platform. Its goal is straightforward: enable geospatial foundation models to do more than run demos on a handful of satellite images. Instead, they should be able to perform inference continuously at national, continental, and even global scales—and deliver the results as map products that can be updated, queried, and analyzed further.

As of July 28, 2026, OlmoEarth is no longer merely a collection of open weights. Ai2 is developing it into a complete Earth observation platform covering data acquisition, preprocessing, annotation, fine-tuning, distributed inference, and result publication. The recently released OlmoEarth v1.1 also reduces inference compute costs by up to two-thirds. Taken together, the intent is clear: the model answers “Can it recognize this?” while the platform answers “Can it do so repeatedly across the entire planet?”

The latter is actually more difficult—and more commercially valuable.

Planetary-Scale Inference Is Not Just Increasing the Batch Size

When developers first encounter remote sensing tasks, they may think of them as ordinary computer vision: load an image, run semantic segmentation once, and save the result. Real-world global mapping operates at an entirely different scale.

Satellite data comes from different sensors, potentially with different spatial resolutions, coordinate systems, band definitions, and revisit intervals. Optical imagery is also affected by clouds, shadows, smoke, and seasonal changes. Radar imagery can see through clouds but has its own noise characteristics and preprocessing requirements. Even after the model itself has been trained, a production system must still handle a long list of issues:

• Locate target regions and time windows within massive archives;
• Reproject, register, and align the resolutions of data from different sources;
• Divide the Earth’s surface into tiles that the model can process while handling boundary overlaps;
• Skip invalid, missing, or heavily cloud-covered data to avoid wasting GPU resources;
• Distribute millions of inference tasks across compute clusters;
• Retry failed tasks while ensuring that identical inputs produce reproducible results;
• Stitch local predictions back together into continuous maps and write them to queryable geospatial formats;
• Recompute only the regions that have changed when new satellite data arrives.

In other words, the basic unit of large language model inference is usually a request, whereas the basic unit of global remote sensing inference is a task with spatial coordinates, a time range, a sensor source, and a data-quality status. The former is concerned with tokens; the latter must account for pixels as well as where and when those pixels were captured on Earth.

“Global scale,” therefore, does not mean feeding a single world map into a model. A more accurate analogy is to divide the Earth into an enormous spatiotemporal table that can be processed in parallel. Each cell has its own data dependencies and task status. The platform sends those cells to suitable compute nodes and then stitches the results back together.

OlmoEarth Platform Fills the Engineering Middle Layer

OlmoEarth is a family of foundation models trained for Earth observation data. It extracts representations from multimodal, multitemporal remote sensing signals and then uses small amounts of labeled data to adapt to downstream tasks such as wildfire risk, land cover, vessel activity, agriculture, and ecological monitoring.

There are two common ways to use it.

The first is to export embeddings. Teams can compress complex remote sensing data for a region into feature vectors and then analyze them using kNN, a linear classifier, or their own time-series models. This approach is quick to deploy and well suited to projects with limited labels.

The second is to fine-tune OlmoEarth for a specific task and attach a classification, regression, or segmentation head. This requires more training work but generally delivers more refined task performance. In an earlier comparison with Google DeepMind’s AlphaEarth Foundations, Ai2 said that OlmoEarth embeddings performed comparably or better on several tasks using kNN; after fine-tuning, OlmoEarth’s advantage became more pronounced.

OlmoEarth Platform sits between the model and the map product. It standardizes the “glue layer” that remote sensing teams previously had to build repeatedly themselves: how data is defined, how samples are tiled, how model tasks are scheduled, how outputs are stored, and how the same processing pipeline can scale from tens to hundreds of thousands of square kilometers.

This may not sound as exciting as launching a new model, but it determines whether Earth observation AI is genuinely usable. A segmentation model that scores one percentage point higher on a test set may not change a business. But reducing the update cycle for a complete map from months to weeks—or cutting the cost of nationwide inference to one-third—can directly determine whether a project is viable.

v1.1’s Threefold Efficiency Gain Only Becomes Truly Meaningful at the Platform Level

Ai2 released OlmoEarth v1.1 in May 2026. The central change highlighted by the organization was not another increase in scale, but a reduction of up to roughly threefold in compute costs for models of the same size, while largely preserving the capabilities of the first generation. v1.1 is available in Base, Tiny, and Nano variants, making it easier to balance accuracy, throughput, and hardware budgets.

For ordinary image classification, making a single inference three times cheaper might only save a few dozen dollars. For large-area maps that must be refreshed every few weeks, however, the difference is multiplied across millions of geospatial tiles.

Suppose a monitoring project needs to cover 100,000 square kilometers:

1. Each region may include multiple points in time;
2. Each point in time may include multiple sensors or bands;
3. Adjacent tiles generally overlap to eliminate stitching seams;
4. Results may need to be recomputed monthly or even weekly.

Every forward pass saved by the model ultimately translates into lower compute requirements and shorter delivery times across the entire pipeline. This is why Ai2 emphasizes the “platform,” rather than focusing only on parameter counts. The efficiency gains of OlmoEarth v1.1 reveal their full value only when applied to planetary-scale tasks.

However, Ai2 has also explicitly cautioned that v1.1 is not strictly superior to the first generation on every task, and some scenarios may see regressions. Developers should not replace production models solely because the new version is “three times cheaper.” They still need to reevaluate it for local terrain, sensor combinations, and target classes. Remote sensing models are particularly vulnerable to geographic distribution shifts: a classifier that works well on North American farmland may not maintain the same accuracy when applied to smallholder plots in Southeast Asia.

Open Models Are One Card; Platform Control Is Another

OlmoEarth is differentiated not only by model performance but also by its degree of openness. Its pretraining code, model weights, and related tools have already been released publicly. A summary of the pretraining dataset indicates that it contains approximately 285,288 samples worldwide, each corresponding to an area of roughly 2.56 km × 2.56 km. The number of time steps and available modalities is not identical across all samples.

This irregularity accurately reflects the state of real-world Earth observation data: the data does not sit neatly organized in directories like ImageNet. One region may have optical imagery that is obscured by clouds, while another may have only radar data. Some locations have years of high-frequency observations, while others have only sparse records. Both the model and the data pipeline must treat incomplete inputs as the norm rather than the exception.

Compared with Google’s AlphaEarth Foundations, Ai2’s strategy is more oriented toward “downloadable models and an accessible platform.” Google primarily released annualized embeddings without opening the complete model. OlmoEarth, by contrast, allows research teams to download the weights, compute their own embeddings, and fine-tune the model for specific tasks. For teams that require auditing, private deployment, or research into a model’s internal behavior, this distinction matters more than leaderboard rankings.

The limits must also be recognized: open weights do not mean that all global inference infrastructure is available for free. The OlmoEarth models and training code can be self-hosted, but access to the full managed capabilities of OlmoEarth Platform currently requires contacting Ai2. Data egress, long-term storage, and large-scale GPU workloads also incur costs. The platform lowers the engineering barrier; it does not eliminate the cost of real-world data or compute.

The Real Challenge Is Keeping Maps Continuously Updated

Generating a global map once is not the finish line. Wildfires, floods, deforestation, crop growth, and maritime activity are all dynamic processes. Real users need continuously updated intelligence, not an attractive snapshot from a single day.

This creates three key requirements for the platform.

1. Incremental Computation

If the system has to rerun an entire country—or even the entire world—whenever new data arrives, the cost remains prohibitive. A sensible approach is to track input-data versions, update only the affected spatiotemporal tiles, and merge the results into the previous map.

2. Result Traceability

Ideally, every map pixel or vector object should be traceable to the model version, input imagery, preprocessing parameters, and inference time. Otherwise, when a false positive occurs, the team cannot determine whether the issue originated with the sensor, cloud mask, model drift, or postprocessing rules.

3. Uncertainty Management

Remote sensing predictions are not a database of facts. Clouds, surface obstructions, insufficient resolution, and biases in training samples all introduce uncertainty. If a platform outputs only a class without confidence scores, data-quality information, or timestamps, end users can easily mistake model predictions for real-time ground truth.

From this perspective, OlmoEarth Platform is more like an “inference operating system for Earth data” than a simple model-hosting interface. Its core value lies in bringing model outputs into maintainable, auditable production workflows.

Which Teams Will Actually Use It?

OlmoEarth is not a general-purpose vision model intended for every developer. It is better suited to organizations that work with large geographic areas, require frequent updates, and lack sufficient machine-learning engineering resources, including:

• Forestry and environmental teams continuously detecting deforestation, wetland changes, and habitat loss;
• Disaster-response teams analyzing wildfire risk, burn extent, and flood impacts;
• Agricultural organizations tracking crop types, planting cycles, and disaster damage;
• Maritime organizations identifying vessel activity, coastal changes, and potential violations;
• Governments and research institutions producing long-term land-cover and climate-adaptation maps.

Existing collaborations also point in these directions. OlmoEarth has been used in next-generation wildfire-risk systems and maritime intelligence platforms, indicating that Ai2 is targeting public governance and scientific infrastructure rather than consumer-grade image understanding. Such projects have long sales cycles, complex data, and demanding delivery requirements, but once they enter production workflows, their switching costs are also far higher than those of ordinary SaaS products.

For teams processing only one city, a one-off project, or a small collection of aerial images, building a simple tiling pipeline in-house may be more economical. The advantages of OlmoEarth Platform grow with the area covered, the number of sensors, and the refresh frequency. Without a planetary-scale problem, a planetary-scale platform may not be necessary.

Assessment: This Is an Infrastructure Release, Not a Model Showcase

Over the past two years, competition among geospatial foundation models has shifted from “Who can learn better embeddings?” to “Who can turn embeddings into continuously updated real-world products?” Google is building a moat through data and cloud infrastructure, commercial remote sensing companies control high-resolution imagery, and Ai2 is attempting to occupy the middle ground with open models, fine-tuning capabilities, and a managed platform.

OlmoEarth Platform deserves attention because it acknowledges a fact that model releases often overlook: the biggest bottleneck in global AI inference is often not the Transformer itself, but the geospatial data engineering that comes before and after it.

It cannot yet be described simply as a mature cloud service that anyone can sign up for immediately, upload a region to, and use to generate a global map. Access mechanisms, data coverage across regions, task pricing, update latency, and production SLAs will still determine how far the platform can ultimately go. But Ai2 is moving in the right direction: as model capabilities converge, whoever can deploy predictions across the globe more cheaply and reliably will truly control the gateway to Earth observation AI.

References

• The OlmoEarth Platform: Geospatial inference at planetary scale: Ai2’s introduction to the planetary-scale inference infrastructure behind OlmoEarth Platform.
• OlmoEarth v1.1: A more efficient family of Earth observation models: Efficiency improvements, model variants, and usage recommendations for OlmoEarth v1.1.
• allenai/olmoearth_pretrain: The OlmoEarth repository for pretraining, data processing, evaluation, and fine-tuning code.