NVIDIA: Building a Low-Latency Earth-2 Nowcasting Pipeline with Earthmover

TL;DR: NVIDIA and Earthmover partnered up to build a low-latency nowcasting workflow that turns Meteosat satellite observations into a two-hour nowcast using Earth-2 StormScope-EU. By fetching only the data the model needs, overlapping GPU inference with cloud storage data streaming, and serving forecasts directly from versioned data through map tiles and SQL, the workflow reduces delays in delivering forecasts. The demo shows that low-latency forecasting depends on optimizing the whole pipeline, not just model inference.

In operational forecasting, data movement and end-to-end latency are often major bottlenecks between the arrival of new observations and the delivery of usable forecast products. AI weather prediction models (AIWPs) have significantly reduced the computational cost and time required to generate forecasts compared with traditional numerical weather prediction (NWP) models. However, faster inference addresses only one part of the end-to-end forecasting workflow. Downloading and preprocessing large observational datasets, transferring data to GPU resources, storing forecast outputs, and disseminating results to downstream applications can introduce substantial latency for delivering forecast products.

To address this challenge, NVIDIA and Earthmover developed a real-time AI nowcasting demo for GTC Berlin 2026, demonstrating how GPU-accelerated inference and cloud-native data infrastructure can enable low-latency, end-to-end nowcasting workflows and fast forecast delivery to end users.

This demo connects Meteosat Third Generation (MTG) satellite observations from EUMETSAT to NVIDIA Earth-2 inference via Earth2Studio, running on Earthmover’s cloud-native data infrastructure. The StormScope-EU model generates nowcasts for the coming two hours at 10-minute resolution. These are written directly to Earthmover’s Arraylake platform using Icechunk and served on demand through Earthmover Map Tiles and SQL queries (Zax).

In this joint blog post, we explore the end-to-end architecture, implementation, and lessons learned to build such applications for delivering fast forecast products.

Why are we writing this blog post?

Open-source AI weather models and frameworks such as NVIDIA Earth2Studio have made it easier to run inference with pretrained models. But turning weather predictions into operational forecasting applications introduces challenges beyond model execution.

An operational weather forecasting workflow typically runs as a cycling system, which involves:

1. Downloading model initialization files, including observations, initial conditions, and boundary conditions fields, to on-prem or cloud-based GPU systems as they become available.
2. Decoding and preprocessing inputs, including quality control, regridding, and other transformations required by the model.
3. Running the forecasting system and saving predictions to local or shared filesystems.
4. Transferring forecast outputs to cloud storage, remote systems, or other infrastructure where downstream applications can read or access them.
5. Postprocessing and converting outputs into application-ready products, such as derived weather variables, maps/dashboards and other forecast products.

Each stage introduces I/O, network transfers, and other data processing overhead. In a cycling forecasting system the next forecasting cycle begins as soon as the initial conditions become available and the workflow repeats. For delivering fast real-time forecasts, improving model inference time alone is not enough to achieve a low-latency end-to-end dashboard. The entire workflow, from data acquisition and preprocessing to forecast storage, distribution, and application delivery, must be optimized.

For this demo, the MTG Flexible Combined Imager (FCI) provides full-disc imagery of the Earth from geostationary orbit at a 10-minute cadence across 16 spectral channels. The model we used for this demo is Earth-2 StormScope-EU, which uses six consecutive FCI observations to generate forecasts extending two hours into the future.

Our goal was to run this as a single continuous workflow rather than a sequence of independent batch jobs, guided by three design requirements:

• Low-latency inference: Find the newest complete observation window, fetch only the satellite data the model needs, and reuse a persistent GPU worker.
• Cloud-native publication: Write outputs as they are generated, overlapping storage with inference, and publish each forecast atomically to a bucket co-located with the computing resources.
• Direct application access: Serve forecast products from the same cloud-native data repository through map tiles and SQL, without building separate copies for visualization and analysis.

The broader goal of this demo is to demonstrate a reusable architecture for operational cloud-native and GPU-native real-time applications. This same architecture supports many other operational Earth-system modeling applications requiring low latency and high reliability, such as energy trading, wildfire monitoring, and emergency warning systems.

Figure 1. End-to-end Earth-2 × Earthmover workflow. EUMETSAT MTG/FCI satellite observations initialize StormScope-EU through NVIDIA Earth2Studio. GPU-generated nowcasts are written to Arraylake using Icechunk and made available to downstream applications through on-demand map tiles and SQL queries.

Under the hood of the GTC Berlin demo

The GTC Berlin demo connects four components to build a low-latency, end-to-end AI weather nowcasting workflow:

• EUMETSAT MTG/FCI: Provides satellite observations at a 10-minute cadence.
• NVIDIA Earth2Studio: Handles satellite data access, input preparation, and StormScope-EU inference.
• Icechunk + Arraylake: Stores versioned, cloud-native forecast outputs.
• Earthmover Compute: Serves on-demand map tiles and SQL queries from the published repository.

In each cycle, the pipeline starts by polling the EUMETSAT Data Store and initializing a new forecast when a complete six-frame input window becomes downloadable, which is every 10 minutes.

As StormScope-EU advances through its forecast, each predicted step is converted into RGB composites and handed to background writers. Once all of the forecast steps are written, a single Icechunk commit publishes the completed forecast.

The map viewer and SQL service then read the same versioned data cube.

StormScope-EU: generative AI for satellite nowcasting

NVIDIA’s StormScope-EU is a generative diffusion nowcasting model available through Earth2Studio. Unlike weather prediction models that initialize from atmospheric analyses, StormScope-EU predicts future satellite imagery directly from recent FCI observations. This means that it does not require numerical weather prediction fields as conditioning inputs and is thus much closer to real time.

The model uses six consecutive 10-minute observations across all 16 FCI Level-1C spectral channels, including visible, near-infrared, water-vapor, and infrared bands. It employs an ensemble-of-experts denoising strategy, in which the diffusion sampler uses different model weights across specified noise ranges to generate the next satellite frame. The initial observations are not downloaded again for every prediction.

Figure 2. Six observations initialize StormScope-EU. Subsequent predictions enter the context window, producing a two-hour autoregressive forecast.

What does the attendee see at GTC Berlin?

Attendees can open the StormScope-EU application on their phone, laptop, or the booth display and explore the latest AI-generated satellite nowcast over Europe. The interactive map allows users to pan and zoom, switch between True Color and Air Mass satellite composites, and animate forecast predictions at 10-minute intervals up to two hours ahead.

As new satellite observations become available and a new forecast is published, the application can display the latest initialization without downloading the full forecast dataset. Users retrieve only the geographic tiles needed for their current view.

Figure 3. The booth demo dashboard, here showing a +20 minute Air Mass nowcast over Europe. Explore the real-time dashboard.

Building the workflow: a step-by-step tutorial

Interested in building a similar application? The following examples are condensed from the GTC Berlin StormScope-EU implementation, but you can apply the same principles to any AI weather prediction (AIWP) workflow.

1. Find the newest complete FCI observation window

In the GTC Berlin demo, StormScope-EU initializes directly from EUMETSAT Meteosat Third Generation (MTG) Flexible Combined Imager (FCI) observations. The model requires six consecutive satellite images at 10-minute intervals. Selecting only the latest product listed in the EUMETSAT catalog is therefore insufficient, particularly because products may appear in the catalog before they become accessible under the account’s data license.

We query the EUMETSAT MTG FCI Full Disc High Spectral Resolution Imagery (FDHSI) collection and identify the newest complete, eligible six-frame observation window before starting inference (check out the details of fetching the most recent eligible data).

Please note that the freely accessible FCI feed from the EUMETSAT Data Store has a one-hour embargo, resulting in StormScope forecasts being available 68 minutes after satellite data acquisition. A commercial licence, which NVIDIA purchased for this demo, brings that latency down to 20 minutes.

2. Fetch only the model-required data

Once the latest initialization is identified, the next step is to retrieve and prepare the model inputs. For AI weather prediction workflows, downloading and preprocessing large datasets can introduce significant I/O and memory overhead.

To minimize unnecessary data movement, we use Earth2Studio’s MeteosatFCI data source to select only the spatial region, variables, and observation times required by StormScope-EU, rather than processing the entire MTG full disc (see details).

3. Overlap inference and output writes

A common source of latency is waiting until inference finishes before transferring its outputs to persistent storage.

Earth2Studio’s create_iterator provides each autoregressive forecast step as it becomes available. We use this to overlap GPU computation with cloud publication.

For our demonstration, StormScope-EU predicts all 16 FCI spectral channels, but we store only the two RGB composites required by the visualization application:

• true_color: An RGB composite combining visible spectral channels to approximate how Earth appears to the human eye. It provides a natural-looking view of clouds, land, and oceans, making it useful for tracking cloud development and movement during daylight hours.
• airmass: An RGB composite combining water-vapor and infrared spectral channels to visualize atmospheric moisture, temperature differences, and air-mass characteristics. It helps identify weather features such as dry-air intrusions, frontal boundaries, and evolving storm systems, including during nighttime.

Since this demo is only used for visualization, both variables are converted to 8-bit (uint8) arrays to reduce storage and data transfer overhead.

We use Icechunk to store the generated forecasts. Icechunk is an open-source cloud-native file format for storing n-dimensional array (tensor) data. Icechunk extends the popular Zarr format with database-style features such as ACID transactions, which are critical for operational data pipelines such as these. Arraylake is Earthmover’s cloud platform for managing Icechunk data. Arraylake provides the data catalog and data governance capabilities that teams need to build production-grade systems around Icechunk data. An analogy: Icechunk is like Git for tensor data; Arraylake is like GitHub.

We use Earth2Studio’s IceChunkBackend, connected to an Icechunk repository backed by an AWS S3 bucket managed by Earthmover Arraylake, to write forecast outputs as they are generated. See the example below:

from earth2studio.io import IceChunkBackend

IceChunkBackend.commit(message)

Non-blocking background writes let storage operations overlap subsequent GPU inference, but downstream applications must also be protected from partially published forecasts.

Icechunk provides atomic publication through immutable, versioned snapshots. Once all 12 forecast steps are written, a single commit ensures downstream applications access only fully committed forecasts and no partial data. Therefore one initialization produces one Icechunk commit.

This is an important distinction: writing a step asynchronously does not make that step publicly visible immediately. The workflow streams writes into an Icechunk session, then publishes the complete run atomically. That means downstream applications never see incomplete or inconsistent data.

4. Serve map tiles directly with Earthmover Map Tiles

The next step is making the forecast accessible to downstream applications without additional data movement or preprocessing pipelines.

Forecast data users typically want to look at their data on a map. For our GTC Berlin demonstration, we use Earthmover Compute’s Tiles API to serve interactive maps directly from the Icechunk repository on Arraylake. Rather than moving forecast data into a separate visualization system, Earthmover brings compute to the data, dynamically rendering map tiles on demand. See tiles in our interactive data viewer (free sign-in required).

5. Query the same data through Zax SQL

Maps are great for visual exploration, but operational applications typically need to integrate the data into a downstream system for automated decision making (like whether to close an airport or sell off a market position). Earthmover’s Zax SQL service provides SQL access to the same Arraylake repository through a PostgreSQL-compatible interface.

For the booth, we use a city-centered query to calculate brightness across forecast lead times:

SELECT
    lead_time,
    AVG(true_color) AS brightness
FROM "stormscope-eu_gtc_berlin_2026_EU_region"."root"
WHERE time = TIMESTAMP '{init}'
  AND lat BETWEEN {lat} - 0.05 AND {lat} + 0.05
  AND lon BETWEEN {lon} - 0.05 AND {lon} + 0.05
GROUP BY lead_time
ORDER BY lead_time;

The application substitutes the initialization time and selected city coordinates.

The important architectural point is that the tile service and SQL service operate on the same versioned data cube. We do not need to export the forecast into another database to make it queryable.

End-to-end latency

Bringing all components together, we reach a delay of 10 minutes between forecast initialization time and forecasts on your phone. Let’s break down the largest levers:

• Cloud location: We co-located all services in Europe for this demo targeting GTC in Berlin. Initial conditions from EUMETSAT are served from Darmstadt, Germany, and compute inference, storage, and tile serving all run in EU cloud regions, avoiding transatlantic round-trips for users at GTC in Berlin.
• Non-blocking writes: Continuous GPU inference while the CPU ingests to the cloud bucket brought GPU inference latency down from 6 minutes to under 4 minutes.
• Tile optimizations: Internal optimizations in Earthmover’s tile server for reprojection, polygon/RGB styling, and concurrent requests brought the latency between commits and animated tiles down from ~3 minutes to 10 seconds.

What’s next?

The GTC Berlin demo shows a working end-to-end AI nowcasting workflow, with opportunities to further improve performance, scalability, and support for broader Earth-system applications.

Future directions include:

• Tile-serving granularity: Optimize on-demand rendering of high-resolution satellite imagery using multiscale data representations to reduce I/O.
• GPU-native workflows: Extend cloud-native data pipelines with GPU-accelerated I/O, nvCOMP decompression, and GPU-native Zarr integration to reduce CPU overhead and data movement between CPU and GPU.

The broader lesson is that low-latency forecasting requires optimizing the entire observation-to-application workflow, not just inference time. By combining NVIDIA Earth2Studio with Icechunk, Arraylake, and Earthmover Compute, we minimize unnecessary data movement, overlap computation with storage, and deliver versioned forecasts directly to downstream applications. We achieve low latency through a cloud-native pipeline with co-location across all components.

More importantly, this architecture provides a reusable foundation for other cloud-native, GPU-accelerated Earth-system applications, connecting scientific models, data infrastructure, and interactive services without building separate pipelines for every use case.

If you’re building AI weather or Earth-system applications, we’d love to hear how you’re approaching continuous inference, cloud-native data publication, and building downstream applications on top of it. Join the Earthmover community Slack to connect, share ideas, and continue the conversation.

Links and acknowledgements

This workflow was developed jointly by Earthmover and NVIDIA for GTC Berlin 2026, using satellite observations from EUMETSAT.

• NVIDIA Earth2Studio
• StormScope Meteosat checkpoint on Hugging Face
• NVIDIA Earth2Studio StormScope example
• EUMETSAT Data Store
• EUMETSAT FCI Level-1C documentation
• Icechunk
• Demo code
• Explore the demo dataset on Earthmover Arraylake (free sign-in required)
• Mobile data viewer
• Real-time dashboard

We thank the NVIDIA Earth-2 and Earthmover teams, EUMETSAT, and the open-source communities behind Icechunk, Zarr, Xarray, Earth2Studio, and the broader scientific Python ecosystem.