Cloud HPC vs Bare-Metal Compute

When Kronos runs on elastic cloud HPC and when it runs on owned bare-metal, and why the choice is about reproducibility and data gravity.

Two regimes, one workload catalogue

L0 workloads land in one of two regimes. Elastic cloud HPC absorbs wide, bursty, independent work: TBR sweeps across the breeder blanket lever set 1.1, 1.5, 1.8; burner plug-density scans; hyperparameter searches. Owned bare-metal carries work that is latency-bound, numerically sensitive, or bound to the petabyte archive by data gravity.

Why bare-metal for the sensitive core

Reproducibility is easier to guarantee on hardware Kronos controls. Bare-metal fixes the CPU microarchitecture, the interconnect topology, and the numerical libraries, so a coupled MHD-thermomechanics solve produces the same trajectory today and after FOAK. Shared virtualized fabrics introduce jitter that is harmless for training but corrosive for bitwise-reproducible physics runs.

Why cloud for the wide frontier

Parameter sweeps are the opposite case. A negative-triangularity shape scan launches thousands of independent Grad-Shafranov solves; a neutronics campaign launches thousands of independent Monte Carlo batches. These have no cross-talk, tolerate heterogeneous nodes, and benefit from scaling out fast and releasing capacity when the campaign ends.

The two regimes are not walled off. A campaign frequently begins as a broad cloud sweep to find interesting regions of the breeder or burner operating space, then re-runs the survivors on bare-metal under strict reproducibility controls before their results are allowed to update a twin surrogate. Cloud explores; bare-metal certifies.

Both regimes present identically through the hardware abstraction layer, so a workload does not know or care where it runs. Placement is a policy decision keyed to the job profile, the sensitivity tier, and current archive proximity, never something a physicist hand-codes.