NVIDIA: Tensor Core FP32 Tricks Speed Up Molecular AI Models Up to 2.5x

NVIDIA has published a technical blog post showing how to run precision-sensitive scientific AI models faster on Tensor Cores without giving up FP32-level accuracy. The test case is the Point Edge Transformer (PET), a machine learning interatomic potential (MLIP) developed by Lab COSMO at EPFL. It is a niche corner of AI, but the technique matters to anyone running simulations where small numerical errors compound, and it is a clean example of speed-versus-accuracy trade-offs we also covered in the RTX 4090 Tensor unlock and TensorRT 11.1's accuracy-aware tuner.

TL;DR: the numbers

Why do molecular models still run in FP32?

Atomistic simulation predicts how molecules and materials behave. Density functional theory is accurate but expensive; classical potentials are fast but inflexible. MLIPs use neural networks to predict energies and forces cheaply. Forces are the derivative of predicted energy and drive atom positions over many timesteps, so tiny errors accumulate into drifting energy or unstable trajectories. NVIDIA says that is why many MLIPs keep inference in FP32 even though Tensor Cores offer far more throughput at lower precision such as BF16 and TF32.

How do BF16x9 and TF32x3 work?

Both split each FP32 number into lower-precision pieces, multiply the pieces on Tensor Cores, and add the results back in FP32.

BF16x9 on Blackwell

Each FP32 operand becomes three scaled BF16 components, giving nine pairwise products accumulated in FP32 along five anti-diagonal bands. It works on Blackwell GPUs with compute capability 10.0 or 10.3, and no model code changes are needed for single-precision GEMMs. cuBLAS offers a "performant" strategy that uses it when it expects a gain, and an "eager" strategy that uses it whenever supported.

TF32x3 on Ampere

Each operand splits into a leading TF32 part and a residual. Three cross-products are computed and the tiny residual-by-residual term is dropped. NVIDIA replaced PET's nn.Linear layers with a custom TF32Linear calling a CUTLASS kernel; since forces come from differentiating energy, the same arithmetic is used for gradient propagation. The CUTLASS example targets Ampere and can compile for Hopper.

What were the results?

NVIDIA evaluated the 26M-parameter PET-MAD small checkpoint on a 192-atom water box and a 17,280-atom supercell, and the 255M-parameter large checkpoint on the 192-atom system.

• BF16x9: large GEMMs ran 2.2 to 2.5x faster for 17,280 atoms and 1.2 to 1.4x for 192 atoms. The full MD step was 1.2x (performant) or 1.1x (eager) on 192 atoms, and 1.7x or 1.4x on 17,280 atoms.
• TF32x3 on A100: GEMMs 1.7 to 1.9x faster; MD step 1.5x on the larger system. The large checkpoint on 192 atoms reached 1.4x with a force error of 3.9e-6 eV/Å, essentially unchanged from the small one.
• Smoothness: dragging a CO molecule off a Pt(111) slab, TF32x3 followed the smooth FP32 energy curve while one-pass TF32 showed point-to-point noise.
• Energy conservation: in a 30 ps NVE run of a water box, FP32 and TF32x3 had comparable bounded fluctuations; one-pass TF32 drifted systematically.
• Relaxation: relaxing a 539-atom Cantor-alloy slab with the FIRE2 optimizer in the NVIDIA ALCHEMI Toolkit, FP32 converged in 218 steps and TF32x3 in 218 to 222, each step 1.5x faster. One-pass TF32 was 2.0x faster per step but never reached the force tolerance, even after 1,000 steps.

The lesson is that the cheapest precision is not always the fastest path to an answer: a method that needs more steps, or never converges, loses.

A short primer on the number formats

FP32 stores a number in 32 bits with an 8-bit exponent and a 23-bit mantissa. TF32 keeps the same exponent range as FP32 but only 10 mantissa bits, so it is fast on Tensor Cores yet roughly three decimal digits precise. BF16 keeps the 8-bit exponent but only 7 mantissa bits, which is even coarser but cheap. Language-model inference tolerates this because errors average out across billions of weights and the output is a probability over words.

Physical simulation is different. A force error that is random and tiny at one step becomes a bias when integrated over millions of steps, and energy that should be conserved starts to creep. That is why the post tests drift and convergence rather than only comparing one prediction with a reference. The splitting trick recovers precision by carrying the rounding error forward: the leading part holds most of the value, the residual holds what was lost, and cross-products put them back together. It costs three or nine low-precision multiplies instead of one FP32 multiply, yet it still wins because Tensor Cores are so much faster at the low-precision operation.

How would you test this on your own workload?

NVIDIA's evaluation design is a reusable checklist, and none of it needs special tooling beyond your usual simulation stack.

1. Profile first. Measure what fraction of a step is matrix multiplication. If GEMMs are under half of runtime, the best case is modest, which is exactly why the 192-atom system gained less than the 17,280-atom one.
2. Check single-point error against FP32 and against a higher-precision reference, and compare it with the run-to-run noise of your own model. NVIDIA's claim for BF16x9 is that its error sits below the model's non-determinism, which is a useful yardstick.
3. Test smoothness. Scan an energy curve along a coordinate you care about and look for point-to-point jitter.
4. Test conservation. Run an NVE trajectory long enough to see drift, and compare with the FP32 baseline rather than with zero, since FP32 also fluctuates.
5. Test the optimizer. Run a relaxation to a fixed force tolerance and count steps. A 2x per-step speedup is worthless if the run never converges, as one-pass TF32 showed.
6. Compare cost to answer, not cost per step: time to a converged structure or a stable trajectory of useful length.

Where does this fit in the wider precision story?

The same tension shows up across AI hardware. Lower precision formats such as MXFP8 and NVFP4 are being pushed into training and inference for large language models, as in Meta's dist-MoE kernels, because those workloads tolerate it. Scientific models sit at the other end, where the hardware's low-precision speed is tempting and the physics punishes sloppiness. NVIDIA's approach here is a middle path: keep FP32 semantics but exploit Tensor Core throughput by emulation. It also hints at why vendors keep adding software paths rather than only new silicon: a library setting can change the economics of a GPU you already own, as long as someone validates the numerics.

For teams outside chemistry, the transferable idea is the validation mindset. When someone offers a faster numeric format, ask what downstream behavior it could break, design a test for that behavior, and measure it against a trustworthy baseline.

What are the limits?

NVIDIA states them plainly. End-to-end gains depend on system size and the share of runtime in matrix multiplication; small systems gain less because launch overhead, neighbor processing and graph operations dominate. TF32x3 speed depends on kernel tuning for the model's matrix shapes. BF16x9 matched or beat native FP32 accuracy against an FP64 reference in matrix tests, but TF32x3 has a slightly different profile and should be validated against your model's physical-stability needs. NVIDIA also did not measure combining the method with fused ops, custom kernels or CUDA graphs.

What is claimed and what is verified

Everything numeric above is NVIDIA's measurement: the speedups, the error figures and the convergence counts. The relaxation result rests on three replicates per method, and the energy-drift test on a single 30 ps water-box trajectory, so treat them as indicative rather than statistically broad. The checkpoints used are public PET-MAD models, and the post points to the UPET repository, the cuBLAS documentation and the ALCHEMI Toolkit so readers can reproduce the setup. What is not shown is any comparison against other MLIP architectures, other GPUs such as Hopper for BF16x9, or alloys and molecules beyond water, a Pt(111) slab and a Cantor alloy.

What this means for what you build

• If you run MLIP or similar physics models: try the environment variable on Blackwell, compare energy drift and convergence, not only single-point error.
• If you build other FP32-bound models: this is a template for testing emulated precision, but the evidence here covers one model family.
• If you buy GPUs for science: Blackwell's gain over Ampere here is partly a software path; check your workload's GEMM share first.
• Remember the source: this is NVIDIA benchmarking its own hardware and libraries. Independent replication has not been published that we found.

Related reading

• RTX 4090 Tensor unlock and FP16 throughput
• TensorRT 11.1 accuracy-aware tuning
• Meta dist-MoE kernels for Blackwell MXFP8 and NVFP4
• NVIDIA RTX Pro 4500 Blackwell review
• Anthropic AI for Science expansion
• Hugging Face Project ProtoStar
• Official: NVIDIA technical blog and CUTLASS

Figures are accurate as of October 29, 2026 and come from NVIDIA's post.