Papers for

high performance computing teams

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

SeqMoE improves memory offloading for faster AI model use

SeqMoE: Toward Full-Load Performance via Predictive and Graph-Compatible MoE Offloading

Abstract: Mixture-of-Experts (MoE) creates a structural advantage for offloading: only a small fraction of activated experts need to reside in device memory, and if they can be loaded in time for computation, offloading can in principle approach full-load performance, where all model weights reside in device memory. Yet translating MoE's structural advantage into practical offloading gains remains challenging. We propose SeqMoE to bridge this gap. To maximize expert hits, we build predictive memory management: (i) Sequence-to-sequence prediction. We are the first to recast expert activation prediction as sequence modeling, enabling accurate multi-step, multi-layer forecasts that provide a long and reliable window for downstream decisions. (ii) Joint prefetch scheduling. We formulate prefetch scheduling as Job Sequencing with Deadlines to maximize expected expert hits and improve bandwidth efficiency. (iii) Forecast-driven caching. Leveraging the recursive nature of sequence modeling, we introduce a probabilistic Belady policy for future-aware eviction. To eliminate execution bottleneck, we develop (iv) Graph-compatible offloading runtime. We derive general runtime principles encompassing compute-transparent expert placement and synchronization-free orchestration disciplines for end-to-end graph capture. With 45% expert residency, SeqMoE averages a 96.97% hit rate and 80.22% of full-load performance, advancing the state of the art in MoE offloading.

Fri 11 SeptOperating SystemsArtificial Intelligence
The gist
Large AI models often need to save parts of their memory to slower storage, which slows down how fast they work. The authors created SeqMoE, a system that predicts which parts of the model will be needed soon and loads them early to avoid delays. It also uses clever scheduling and caching strategies to keep the right data ready, improving speed without having to keep everything in fast memory. This makes large AI models run much closer to their maximum speed even with limited fast memory.
Open 2609.12978v1

TinyTC and PyTorch/Triton boost stencil computing on GPUs

Stencil Computation at the Intersection of AI and HPC

Abstract: Tensor compilers such as TinyTC and OpenAI Triton were originally developed for AI workloads, but the same tiling and memory abstractions can be applied to implement efficient high-order stencils for scientific and industrial applications. We demonstrate this for an 8th-order, 25-point acoustic stencil with boundary conditions over an a demanding-sized grid, targeting GPGPUs, where we compare the hardware-specialized TinyTC implementation with a portable PyTorch/Triton implementation. The target platforms for evaluation include Intel B70, B580, GPU MAX 1550, NVIDIA A100/RTX6000 Blackwell/H100, and AMD MI325x. For instance, on Battlemage B580 TinyTC reaches 15.6 Gpts/s versus 13.5 Gpts/s for PT/Triton under random initialization, while zero-initialized runs reach up to 35.8 Gpts/s due to hardware memory compression. Using roofline and memory-hierarchy profiling, we show that -as expected- performance is predominantly bandwidth-limited and that compiler-managed L1/LSC caching can effectively replace programmer-managed shared-memory staging for this stencil class. Overall, the results position TinyTC as the performance-oriented path on Intel hardware and PyTorch/Triton as a strong portability/productivity baseline for cross-vendor HPC stencil development.

Wed 9 SeptDistributed, Parallel, and Cluster Computing
The gist
Stencil computations are a type of calculation important for science and engineering, often running on powerful GPUs. The authors show that tools originally made for AI, like TinyTC and PyTorch/Triton, can also speed up these stencil calculations. They tested these tools on many different hardware setups, finding that TinyTC is fastest on some Intel chips, while PyTorch/Triton works well across many types of GPUs. They also found that the main limit on speed is how fast data can move in memory, not the calculation speed itself. This helps people choose the best tools for running complex simulations efficiently.
Open 2609.10368v1

Scheduling quantum tasks on multiple devices to reduce errors

Fidelity-Aware Scheduling of Quantum Circuits on Multi-QPU Systems

Abstract: High Performance Computing-Quantum Computing (HPCQC) platforms expose multiple Quantum Processing Units (QPUs) that may differ in size, topology, native gates, and noise characteristics. For current noisy devices, errors compound along the compiled circuits quickly, and minimizing them, that is, maximizing the circuits' execution fidelity, is essential for reliable results. Fidelity depends on the compilation to a specific target device: the same high-level circuit may produce different executables and, therefore, different expected fidelities across QPUs. We present a low-overhead fidelity-aware scheduling framework for multi-QPU systems based on a Graph Neural Network (GNN) that estimates, before compilation, the expected fidelity of each circuit on each available QPU. Then, a tunable scheduler uses these estimates to control the trade-off between execution fidelity and parallelism. Results show that this framework allows for approximating an exhaustive fidelity-based assignment, saving computational resources compared to a brute-force approach that compiles each circuit on every device.

Wed 9 SeptArtificial IntelligenceEmerging Technologies
The gist
Quantum computers are very sensitive to errors that build up when running programs, especially on noisy current devices. The authors developed a method to predict how likely a quantum program will run accurately on each available quantum processor before actually running it. Using these predictions, their scheduler assigns tasks to different quantum processors to balance speed and accuracy. This approach helps save time and computing resources compared to testing every possibility.
Open 2609.09980v1

Fp64 emulation gains speed on Nvidia Rubin GPUs with fp8 tensor cores

Ozaki 2.5: Engineering the Deconstruction Path of fp64-Emulated Dense Matrix Multiplication on FP8 Tensor Cores

Abstract: FP8 Ozaki II emulates FP64 matrix multiplication by tensor-core products over a CRT residue system; converting the operands into residue planes (the deconstruction term in the Tensor-Memory Equilibrium model of the companion paper "FP8 is All You Need, Part 1") costs integer-pipe and memory resources before tensor instructions issue. This paper engineers that path; every result is a model projection pending measurement. First, a deconstruction-aware model: on the NVIDIA Rubin GPU the emulated rate reaches the arithmetic roof $P_{\rm FP8}/(3r+1)$ ($\approx 473$ TFLOPS at $r=12$) only within one thread-block cluster; larger outputs are re-split on the fly and held at a floor of $\approx 235$ TFLOPS (half the roof, a ratio of three design integers, not a fit), while real solvers' tall/skinny shapes stay near the crossover, $1.6$-$1.9\times$ over simple deconstruction today. Second, the method: convert-once residue workspaces, an exact two-limb constant-reduction GEMM on integer tensor pipes (or pure-SIMT dp4a), and conversion pipelined behind the MMAs, moving the crossover from $\approx 1211$ to $\approx 480$-$730$. Third, modulus co-design: all-byte and hybrid sets, two supply bounds and a carry-corrected E4M3 split of tail moduli. Fourth and central, the closed-form floor names its hardware escape, and the prize is Rubin's: a stream-side residue-conversion mode on the asynchronous copy path (Option C), a narrow fixed-function block sized as a bill of materials, takes plane formation off the arithmetic pipes and lifts the floor from 235 TFLOPS to the full 473-TFLOPS roof at unchanged cluster reach, about doubling HPL-class FP64 per Rubin GPU, and unbinds conversion-bound sparse kernels. The NVIDIA GB300 GPU, whose 135-TFLOPS roof sits at its own floor, gains little; floor and remedy are Rubin-scale. Application traces ground the analysis; constants are script-checked.

Tue 8 SeptMathematical SoftwareHardware ArchitectureDistributed, Parallel, and Cluster Computing
The gist
Performing precise FP64 (double-precision) matrix multiplication on GPUs is slow and costly. The authors show a way to speed this up by breaking down FP64 operations into many simpler FP8 operations using the CRT (Chinese Remainder Theorem) system and careful engineering on NVIDIA Rubin GPUs. They modeled and improved the conversion steps to greatly increase computation speed, almost doubling performance for some large matrix problems. This method exploits special hardware and memory pathways to avoid bottlenecks seen on other GPUs like the NVIDIA GB300.
Open 2609.09095v1

Genesis platform speeds plant research across labs and supercomputers

Exploring the Genesis Platform Capabilities to Accelerate Scientific Discovery in OPAL

Abstract: Autonomous, cross-facility science requires capabilities that no individual project should have to build for itself: managed execution for long-lived services, versioned distribution of models to remote compute systems, governed access to large language models, a shared substrate for experimental data, and end-to-end provenance. The U.S. Department of Energy Genesis Mission platform, delivered through the American Science Cloud, provides these as reusable services. This paper reports how the Genesis platform enables cross-facility experiments and accelerates scientific discovery. We explore the plant phenotyping workflow of the Orchestrated Platform for Autonomous Laboratories as the exemplar: it couples Oak Ridge National Laboratory's Advanced Plant Phenotyping Laboratory with the Frontier supercomputer. In a 40-day nickel-treatment campaign, the resulting workflow replaced roughly twelve hours of manual analysis with interactive queries returning in seconds to minutes.

Tue 8 SeptDistributed, Parallel, and Cluster Computing
The gist
Scientific experiments that involve multiple labs and high-powered computers often need complicated tools to manage data and models, which can be hard to build from scratch. The authors show how the Genesis platform provides ready-made services to handle these tasks, making it easier to run experiments across different facilities. They tested the platform with a plant study that treated plants with nickel and connected a research lab with a supercomputer. Thanks to Genesis, tasks that used to take about twelve hours of manual work can now be done interactively in seconds or minutes.
Open 2609.08844v1

Kan training scales efficiently on multi gpu high performance computers

Scalability Analysis of Distributed Kolmogorov-Arnold Network Training on High-Performance Computing Systems

Abstract: Kolmogorov-Arnold Networks (KANs) replace the fixed activation functions and linear weights of Multi-Layer Perceptrons (MLPs) with learnable univariate functions on network edges, offering improved interpretability and, in some settings, competitive parameter efficiency. While the approximation properties of KANs have received considerable attention, their behavior under distributed, multi-GPU training has not been systematically characterized. This paper presents an empirical scalability study of data-parallel KAN training on multi-node, multi-GPU high-performance computing (HPC) infrastructure, evaluated along four dimensions: strong scaling, weak scaling, communication overhead, and model-size scaling. Experiments were conducted on the FinisTerrae III supercomputer using up to 8 NVIDIA A100 GPUs across 4 nodes with PyTorch Distributed Data Parallel (DDP). KAN training reaches 74.7% parallel efficiency at 8 GPUs with a 5.97x speedup, consistent with conventional deep learning workloads. Weak scaling shows an initial single-to-multi-GPU throughput drop followed by strong stability. Communication overhead follows a non-monotonic pattern (1.3%-6.1%), driven primarily by All-Reduce algorithm selection and inter-node latency rather than KAN's edge-wise gradient structure. The parameter-to-memory ratio improves with model size even as training time scales unfavorably. These results indicate that operator-level and data-parallel optimizations for KAN are complementary. We provide deployment guidelines for GPU topology and model-size selection, and discuss the limitations of a synthetic-regression evaluation.

Mon 7 SeptDistributed, Parallel, and Cluster ComputingMachine LearningPerformance
The gist
Kolmogorov-Arnold Networks (KANs) are a special type of neural network that use learnable functions instead of fixed math rules to make decisions. The authors studied how well KANs train when the work is split across many GPUs in a supercomputer. They found that KAN training gets faster almost as expected when adding more GPUs, with some small delays due to communication between machines. Their experiments help show how to best set up hardware and model size for training KANs efficiently.
Open 2609.07740v1