Deploy Aurora 1.8.0: Atmospheric Foundation Model Setup

Most Aurora coverage treats the model like a paper to admire from a distance. That’s a waste. It’s on PyPI, the weights are on HuggingFace, and you can run a global weather forecast on a single GPU before lunch – if you know which version to grab and where the docs quietly skip a step.

This guide covers deploying Microsoft’s Aurora (package microsoft-aurora, latest v1.8.0 as of June 2026) end-to-end. Marketing skipped. Focus: what breaks.

Why run it yourself

91% of forecasting targets beaten at 0.25° resolution – that number comes from the Nature paper (Bodnar et al., May 2025), not the blog. Aurora is a 1.3 billion-parameter 3D Swin Transformer with Perceiver encoders and decoders, trained on more than a million hours of geophysical data.

The case for local deployment isn’t speed – it’s fine-tuning. The pretrained checkpoint can be adapted on small custom datasets: regional air quality, wave heights for a specific basin, hyperlocal energy forecasting. You can’t fine-tune somebody else’s API.

Hardware reality: the full VRAM ladder

The official docs give one number – ~40 GB for the regular 0.25° model. Accurate but incomplete. Cross-referencing those docs with the arXiv paper reveals the actual hardware ladder:

Beyond VRAM: Python 3.10, PyTorch with CUDA, ~50 GB disk if you pull more than one checkpoint, fast HuggingFace connection. CPU-only works for the small debug model in principle – but a single inference pass on CPU takes long enough to question your life choices.

The license split nobody flags

The microsoft-aurora Python package is MIT-licensed. The model weights on HuggingFace are CC-BY-NC-SA 4.0 – non-commercial. Per the ECMWF plugin docs and the main repo, commercial use requires emailing [email protected] first. Most tutorials skip this. Now you have it.

Install

One command:

pip install microsoft-aurora

Clean environment (recommended – Aurora pins a specific HuggingFace Hub version):

python3.10 -m venv aurora-env
source aurora-env/bin/activate
pip install --upgrade pip
pip install microsoft-aurora
python -c "import aurora; from aurora import Aurora; print('ok')"

Prefer conda:

mamba install microsoft-aurora -c conda-forge

Source build (for hacking on the model or picking up unreleased fixes):

git clone https://github.com/microsoft/aurora.git
cd aurora
virtualenv venv -p python3.10
source venv/bin/activate
make install

First run: load a checkpoint

Before downloading real ERA5 data, sanity-check the install with the small model on random tensors. A CUDA mismatch surfaces in seconds this way instead of after a 6 GB checkpoint download.

from datetime import datetime
import torch
from aurora import AuroraSmallPretrained, Batch, Metadata

model = AuroraSmallPretrained()
model.load_checkpoint("microsoft/aurora", "aurora-0.25-small-pretrained.ckpt")
model.eval()
model = model.to("cuda")
print("Checkpoint loaded, model on GPU")

That runs clean? Swap in the real model:

from aurora import Aurora
model = Aurora()
model.load_checkpoint()
model.eval().to("cuda")

The checkpoint-data mismatch trap:Aurora() is fine-tuned specifically for IFS HRES T0 – not IFS HRES analysis, not ERA5. The docs warn this but it’s the most common cause of “why are my forecasts garbage” reports. ERA5 data? Use AuroraPretrained(). IFS HRES analysis at 0.1°? You need the 0.1° fine-tuned variant. These are not interchangeable.

Think of it like film cameras and film stock – the camera body (model class) and the film (checkpoint) have to match. Drop the wrong checkpoint into Aurora() and it won’t crash immediately; it’ll just produce quietly wrong forecasts.

Feeding it data: the Batch object

Aurora doesn’t take a NetCDF file directly. A aurora.Batch needs four things: surface variables (2-meter temperature, 10-meter winds, mean sea level pressure), static variables (land-sea mask, soil type, orography – all from ERA5 regardless of which checkpoint you use), atmospheric variables across pressure levels, and metadata (lat/lon grids, timestamp, level list).

The full ERA5 example is in the official usage docs. Every variable name and download link lives in Section C of the supplementary material in the arXiv paper. Read both before writing your data loader – the variable naming is not obvious.

Multi-step forecasts without OOMing

Turns out the docs bury the most important snippet for long rollouts:

from aurora import rollout

with torch.inference_mode():
 preds = [pred.to("cpu") for pred in rollout(model, batch, steps=10)]

The .to("cpu") inside the comprehension isn’t cosmetic. Skip it and every prediction tensor parks on the GPU. Step 4 or 5: CUDA OOM, even on an A100. Aurora rollouts are autoregressive – each step’s output feeds the next – so GPU memory accumulates fast. The docs state explicitly: “we move the prediction after every step immediately to the CPU to prevent GPU memory buildup.” They just don’t explain what happens if you don’t.

Errors and what they mean

• CUDA OOM at step 1: Running AuroraHighRes on less than 80 GB. Per the paper, a single 0.1° rollout step is near the A100 80 GB ceiling. Drop to 0.25° or shard across GPUs.
• Forecasts look plausible but error is huge: Wrong checkpoint for your data type – see the IFS HRES T0 vs. ERA5 distinction above.
• HuggingFace 401 on load_checkpoint: Run huggingface-cli login first. The repo is public but unauthenticated requests get rate-limited.
• Static variables missing / shape mismatch (721, 1440): The ERA5 static variables (land-sea mask, soil type, orography) are required even for IFS-tuned checkpoints. They’re not optional.

What does that add up to? Almost every reported Aurora setup failure traces back to one of two things: checkpoint-data mismatch, or the autoregressive memory trap. The hardware error is usually obvious. The silent forecast degradation from mismatched inputs is the one that wastes days.

Upgrading and removing

Checkpoints are versioned on HuggingFace independently of the package – upgrades are straightforward:

pip install --upgrade microsoft-aurora
# Force checkpoint re-download if a model class changed:
rm -rf ~/.cache/huggingface/hub/models--microsoft--aurora

Model classes like AuroraAirPollution, AuroraWave, and Aurora12hPretrained were added in later releases (as of June 2026, check the changelog for your version). On older installs, those imports simply won’t exist.

Full removal:

pip uninstall microsoft-aurora
rm -rf ~/.cache/huggingface/hub/models--microsoft--aurora

FAQ

Can I run Aurora on a consumer GPU like an RTX 4090?

For real forecasts – no. 24 GB doesn’t cover the ~40 GB the regular 0.25° model needs. Use AuroraSmallPretrained to test your pipeline, then rent an A100 when you need actual output.

What’s the difference between the 0.25° and 0.1° checkpoints?

More than resolution. The 0.25° regular model runs on ~40 GB VRAM; dimensions are (721, 1440) globally. The 0.1° variant is fine-tuned on IFS HRES analysis – not T0 – which means different input expectations, different preprocessing, and roughly double the VRAM requirement (near 80 GB for a single step per the paper). Swap them without adjusting your inputs and you’ll get silently degraded output, not an error.

Does Aurora work offline once installed?

The Python package, yes. Checkpoints download from HuggingFace on first use, then cache locally – subsequent runs don’t need the internet. The catch: you still need weather data. ERA5 from Copernicus, IFS from ECMWF, GFS from NOAA – all require API access or bulk downloads. “Offline” means no model downloads, not no data.

Next: spin up the official ERA5 notebook from the Aurora docs on a single A100 instance, run a 24-hour rollout, and compare against your local meteorological service. That’s the only benchmark that tells you whether Aurora fits your specific use case.