microsoft / microsoft/aurora

Questions about finetuning Aurora on 9 new variables (~3 days / epoch on an H100 95 GB)

Open
#130 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1k
Forks
174
PR merge metrics
No merged PRs in 30d

Description

Hello, thank you for the amazing work! I’m trying to finetune Aurora on nine additional surface variables and training is extremely slow:
≈ 8 min per step ⇒ ~3 days per epoch on an NVIDIA H100 (95 GB), despite batch_size=1 and gradient accumulation over 8 steps.


Training setup
Item Details
Data window 1 year of historical data (2024)
Daily samples 4 timesteps — 00 UTC, 06 UTC, 12 UTC, 18 UTC
Input → Target [t, t + 1] → predict t + 2; then slide window ([t + 1, t + 2]t + 3, etc.)
Model variant aurora-base; also tried aurora-small (similar runtime)
Hardware NVIDIA H100 95 GB

Questions
  1. Aurora‑Small “not recommended”
    Docs say to avoid the Small model.

    • What is the underlying reason? Is it the Architecture, stability, or just accuracy?
    • Can it still converge with more epochs?
  2. Loss on denormalised values
    Predictions are denormalised before loss computation.

    • Would computing loss in normalised space (and perhaps dropping per‑variable weighting) improve gradient stability?
    • Any best‑practice guidance?
  3. Variable scale imbalance
    New variables span orders of magnitude (MAE/MSE from ~10⁶ to < 0.01).

    • I used the paper’s two‑stage weighting: all weights = 1 (initial run, on a sub-set of the data for 10 epochs) → Calculate the weight (1/MAE) for the new variables.
    • Should I also recompute weights for the original variables?
    • Are other approaches (e.g. log‑scaling) better suited for Aurora?
  4. Regional fine‑tuning
    Has anyone successfully trained on a geographic subset (e.g. Europe only)?

    • The model accepts any input shape divisible by patch_size (default = 4), so in theory this should work.
    • Are there caveats or recommended settings for regional training?
  5. Memory usage seemingly independent of variable count
    GPU memory stays roughly constant no matter how many variables I finetune on.
    • Even when I removed the original surface + atmospheric variables and trained only on my 9 new variables, memory usage was unchanged. Is this expected?
    • Is it recommended to finetune exclusively on new variables, or must the original set always be included? *(The atmospheric variables for 2024 at 4 timesteps/day already occupy ~300 GB as a single NetCDF!)
    • Any tips for reducing memory footprint?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Aurora fine-tuning documentation and the paper, then reproduce the reported setup: aurora-base and aurora-small, batch size 1, gradient accumulation, and nine added variables. Trace the training, loss, regional-input, and memory behavior described in the issue; done means documenting confirmed causes, supported settings, and recommended fine-tuning guidance.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data, machine-learning, performance
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.