GPU Hardware for Weather & Climate Modelling 2026 — Sizing NWP, Ensemble & Climate Simulation Clusters

Weather and climate modelling is the rare HPC workload where the GPU you buy can be 10× the wrong tool for the job — because the deciding column in the spec sheet is not INT8 TOPS or FP16 throughput, but the barely-marketed FP64 ratio. A card tuned for AI inference can deliver one-thirty-second of the double-precision rate of a card that costs the same, and numerical weather prediction (NWP) codes still spend the majority of their runtime in FP64 physics and solver kernels. This guide sizes the platform from the workload up: what each modelling regime actually needs, which NVIDIA tiers fit, and how interconnect and ensemble arithmetic reshape the cluster design.

The Workload Decides the Hardware, Not the Other Way Around

Four regimes dominate the sector, and they pull the spec in different directions. Operational global NWP runs a fixed domain on a hard wall-clock deadline — the 00Z run must complete before the 06Z cycle. Regional limited-area models trade domain size for finer resolution and are usually run as nested ensembles. Climate simulation runs months of wall-clock against a fixed calendar and cares about sustained efficiency, not latency. And a fast-growing fourth regime — machine-learned emulators and nowcasting — is genuinely tensor-shaped and behaves like standard deep learning.

FP64 Is the Gate Most Buyers Miss

The FP64 ratio — double-precision throughput divided by FP32 — is what separates a modelling accelerator from an inference accelerator. Data-centre cards such as the H100 and H200 carry a 1:2 FP64:FP32 ratio and a dedicated FP64 tensor path; workstation-class Blackwell cards sit near 1:32 to 1:64. On a purely FP64-bound dynamical core, that difference is not a benchmark footnote: it is the difference between a 3-hour cycle and a 24-hour cycle. Before selecting anything, pull the FP64 column for your exact part number — marketing pages that lead with AI TOPS routinely omit it, and two cards in the same family can differ by an order of magnitude.

Platform Tiers — What Each Class Buys You

The rule of thumb: use the strong-FP64 cards for the dynamical core and the weak-FP64 cards for everything tensor-shaped. A cluster built entirely from inference-class cards will idle some nodes while bottlenecking others, because the ensemble members that are pure physics cannot run on them at operational speed.

Interconnect and Storage I/O — the Second Purchase

NWP codes decompose the globe into tiles and exchange halo columns at every timestep, so interconnect bandwidth directly caps how far a run can scale before communication dominates. For climate simulation, the bottleneck shifts to checkpoint I/O: a multi-petabyte run that writes a restart file every few wall-clock hours will stall the whole job if the filesystem cannot sustain the write without stalling the solver.

Ensemble arithmetic changes the sizing conversation entirely. A 50-member ensemble is not 50× the cost of a single deterministic run, because the members are independent and embarrassingly parallel — but it is 50× the aggregate throughput, which favours a wider rack of mid-tier nodes over a single highest-end node. Size the ensemble for aggregate throughput and the deterministic core for single-run latency; they are different purchases.

Edge Nowcasting Is a Different Machine

Not every weather workload belongs in a data centre. Site-level nowcasting — short-horizon prediction from local radar, lidar and camera feeds — is latency-sensitive, privacy-sensitive and often connectivity-constrained, which makes it an edge inference job, not an HPC job. A fanless box that runs a machine-learned emulator at the observation point can deliver a 30-second nowcast where a round trip to central HPC cannot. Treat the central cluster and the edge node as two tiers of one pipeline: heavy training and global simulation centrally, low-latency inference locally.

Data Assimilation Is Where the Clock Goes

Most first-time buyers budget for the forecast model and forget the step that prepares its starting point. Data assimilation fuses millions of satellite, radiosonde and surface observations into the model's initial state, and it is frequently the single most expensive part of an operational cycle — sometimes exceeding the forecast itself. It is also FP64-heavy and memory-bandwidth-bound, which means it belongs on the same strong-double-precision cards as the dynamical core, not on a separate inference tier. When you size a cluster, measure the assimilation step first: it sets the floor for the whole cycle, and a design that scales the forecast but bottlenecks assimilation will miss its operational deadline no matter how many GPUs are added.

Sizing Rules

• Pull the FP64 ratio for your exact part number before anything else — it is the gating column, and it is deliberately de-emphasised on AI-focused marketing pages.
• Separate the FP64 dynamical core from the tensor-shaped post-processing; do not buy one card class for both.
• Budget interconnect and a parallel filesystem as part of the purchase, not as a later upgrade — halo exchange and checkpoint I/O cap real throughput.
• Size ensembles for aggregate throughput and the operational core for per-cycle latency; they are different optimisation targets.
• Keep enough VRAM that the full 3D domain plus halos never spills to host — a spill is an order-of-magnitude slowdown with no error message.
• Put a low-latency edge node at the observation point for nowcasting; do not route every inference through the central cluster.