Earth2Studio: NVIDIA's unified Python pipeline for AI weather and climate models

What Earth2Studio actually does

Earth2Studio is not a model. It is an inference pipeline toolkit. The README states that it is designed to ride on top of different AI frameworks, model architectures, data sources, and SciML tooling while providing a unified API. Concretely, it gives you a consistent way to load a model, fetch initial conditions, run a forecast, and write results. The target user is someone who wants to compare or deploy AI weather models without writing a separate loader for each checkpoint format. The project calls itself an AI inference pipeline toolkit, which is an honest label. You will not find training loops here. The README points to the PhysicsNeMo repository for training recipes. That separation is useful: Earth2Studio focuses on the operational side, from data ingestion to output storage.

The core pipeline: model, data, IO, and run

The design is visible in the quick-start examples. Every workflow imports a model class, a data class, an IO backend, and a run function. For FourCastNet3, the code is: model = FCN3.load_model(FCN3.load_default_package()), data = GFS(), io = ZarrBackend("outputs/fcn3_forecast.zarr"), then run(["2025-01-01T00:00:00"], 10, model, data, io). The run function takes a list of start times, a lead time in days, and the three components. The same pattern repeats for AIFS and GraphCast, with only the model and data classes changing. That uniformity is the central value proposition. You can swap GFS for IFS or a Dynamical.org source without changing the rest of the pipeline. The IO layer supports Zarr in the examples, and the README mentions optimized data access to cloud data stores as a general feature. The run function is named deterministic, which implies there is also an ensemble variant, though the README does not show it explicitly.

Getting started: installation and agent-assisted setup

The README does not show a pip install command, but it links to an install guide. It does show a new setup path: agent-assisted configuration using NVIDIA skills. You can run npx skills add NVIDIA/skills --skill earth2studio-install and similar commands for discover, data-fetch, and deterministic-forecast. After adding the skills, you can ask an agent to recommend a model, set up an environment for FourCastNet3 inference, fetch ERA5 data, or create a deterministic forecast with GFS, FourCastNet3, and a Zarr output store. This is a notable departure from traditional README instructions. It assumes you have a coding agent and Node.js with npx available. For users who prefer manual setup, the install guide is the referenced path. The README also notes that as of version 0.14.0, the default TOML install targets CUDA 13. That is a concrete constraint: if your GPU driver does not support CUDA 13, you will need to adjust the install configuration.

Model zoo and data source breadth

The README claims the largest model zoo of weather and climate AI models. That is a strong claim, and you should verify it against the API docs. What is certain from the material is that the project wraps at least four major models: FourCastNet3, AIFS (ECMWF), GraphCast (Google), and Aurora v1.5 (Microsoft). The latest news also mentions StormCast CONUS for convective-scale forecasting and StormScope NSRDB for solar irradiance estimation. On the data side, the README lists Dynamical.org sources reading from anonymous Icechunk repositories (AIFS, GFS, GEFS, HRRR, MRMS, ICON-EU, IFS-ENS) and EarthMover ERA5 0.25-degree reanalysis plus IFS 0.1-degree forecast sources. This breadth is the main reason to adopt the framework. Without it, you would have to write separate downloaders and checkpoint loaders for each model. The cost is that you depend on Earth2Studio's wrappers staying current with upstream model releases.

The license trap: third-party assets are not Apache-2.0

Earth2Studio itself is Apache-2.0, which is permissive. But the README contains an important warning in a callout: Earth2Studio is an interface to third-party models, checkpoints, and datasets. Licenses for these assets are owned by their providers. You must ensure you have the rights to download, use, and redistribute each model and dataset. This is not a legal disclaimer buried in fine print. It is the first thing a user should check. For example, GraphCast weights come from Google, AIFS from ECMWF, and Aurora from Microsoft. Each has its own terms. If you are building a commercial product, you need to audit every model you wrap. The Apache-2.0 license on the code does not extend to the checkpoints. The README says links to the original license and source are often provided in the API docs, so that is where you should look before deploying.

Maintenance and upgrade cadence

The release history shows a monthly cadence: 0.15.0 in May 2026, 0.16.0 in June 2026, and 0.17.0 in July 2026. That is fast movement. It means new model wrappers and data sources appear regularly, but it also means API changes can land quickly. The README links to a changelog, which is the right place to check for breaking changes. The project uses mypy, ruff, and uv according to the badges, which suggests a disciplined codebase. The default install targeting CUDA 13 is a sign that the project tracks the latest NVIDIA stack. For a production deployment, you should pin the version you use and test upgrades in a staging environment. The monthly cadence is not a reason to avoid the project, but it is a reason to treat upgrades as a deliberate step, not an automatic one.

A real alternative: direct model repositories

The alternative to Earth2Studio is to use each model's native repository. For example, you can clone the GraphCast repository and run its inference script with its own data loader. The same applies to FourCastNet3 and AIFS. The difference in approach is that native repositories are model-specific: they give you the exact code the authors used, but you must learn a new API for each model. Earth2Studio trades that specificity for a uniform interface. If you only ever run one model, the native repository may be simpler and more up to date. If you run several models or want to swap data sources, Earth2Studio's unified API saves you from writing adapters. The trade-off is that you depend on Earth2Studio's wrappers, which may lag behind a model's latest release. The README does not state how quickly new model versions are wrapped, so you should check the changelog for the model you care about.

Where Earth2Studio is the wrong tool

The README is explicit that Earth2Studio is an inference toolkit. It is not for training. If your goal is to fine-tune a model or train a new architecture, you should look at PhysicsNeMo, which the README links to for training recipes. Another limitation is that the framework is Python-only and assumes a CUDA-capable GPU for most workflows. The CUDA 13 default target will exclude older GPUs unless you adjust the TOML. Also, the agent-assisted setup path requires a coding agent and npx, which may not fit every environment. If you need a fully offline, deterministic pipeline with no external model downloads, Earth2Studio is not suitable because it depends on third-party checkpoints and data sources. Finally, the README does not provide any performance benchmarks or latency numbers. You cannot judge from the material whether the framework adds meaningful overhead compared to native model code. That is a gap you would need to test yourself.

Editorial conclusion

Adopt Earth2Studio if you need a single Python API to run multiple AI weather models (FourCastNet3, AIFS, GraphCast, Aurora) against common data sources and write outputs to Zarr or other backends. It is a good fit for researchers and engineers who want to prototype or deploy inference pipelines without reimplementing model loaders. Do not adopt it if you need to train models, because the README points to PhysicsNeMo for training recipes and Earth2Studio is explicitly an inference toolkit. Also avoid it if you require a stable, long-term API, since the project releases new minor versions roughly monthly (0.15.0, 0.16.0, 0.17.0 between May and July 2026) and the documentation warns that model and data licenses belong to third parties. Before adopting, verify that your target model's checkpoint is accessible under your compute environment, check the install guide for model-specific dependencies, and confirm that the CUDA 13 default target in version 0.14.0 and later matches your GPU driver. The project is active and well-documented, but its value depends entirely on the third-party assets it wraps.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes