Source-linked AI summary
Is Your AI Fast Enough to Run a Fusion Reactor?
Nathaniel Chen, Andrew Rothstein, Ricardo Shousha, Hiro Farre-Kaga, Peter Steiner, Azarakhsh Jalalvand, Egemen Kolemen
TL;DR
Real-time fusion control has tight, task-dependent inference timescales, and the deployment backend must fit the model and control cycle. The paper benchmarks four backends across fusion workloads and finds that no configuration wins for every model, with GPU inference especially advantageous for larger models.
Problem
Method
The paper summarizes DIII-D controller latency rules and benchmarks Keras2c, OpenVINO, TensorRT FP16, and TensorRT FP32 across ten fusion networks and model components.
Source: §1 · p. 1, §3 · p. 3, §3.1 · p. 3Results
No backend is fastest for every model; for TokEye, TensorRT FP16 is about 201× faster than the best CPU result.
Source: §3.2 · p. 3Takeaways & Limitations
Consider GPU inference for models greater than five million parameters, while retaining Keras2c when compact models and predictable timing matter more than peak speed.
Source: §4 · p. 5, §5 · p. 5The benchmark does not cover control-oriented edge GPUs or stateful reservoir and recurrent models, which require a separate protocol.
Source: §4 · p. 5
Abstract
from arXiv · showhide
Machine learning models are increasingly used in feedback control loops for nuclear fusion, where inference speed and predictable timing are critical. We summarize lessons from models deployed for control on the DIII-D tokamak and develop a benchmark to compare inference backends across ten neural networks and model components from fusion control and diagnostic pipelines. For models greater than five million parameters, the CPU backends take tens to thousands of milliseconds, while GPU inference is substantially faster, suggesting an upper limit on CPU-oriented development for control. These results show why the deployment backend must be selected together with the model and its control-cycle budget.
1 Introduction
Real-time ML control at DIII-D must reconcile diagnostic sampling from 1 Hz to 2 MHz with actuator updates every 2–50 ms. This paper summarizes controller latency rules and compares deployment backends for fusion models.
1 Introduction
- DIII-D diagnostics range from 1 Hz to 2 MHz, while actuator commands update on 2–50 ms control cycles [Chen et al., 2026a, Rothstein et al., 2026b].Machine learning has previously been used for feedback control.Source: §1 · p. 1
- FPGA inference can be microsecond and cycle-accurate but requires specialized hardware work; Python runtimes are easier to modify, yet hard timing guarantees are difficult [Dave et al., 2026, Conlin et al., 2021].Source: §1 · p. 1
- Keras2c converts trained Keras networks to portable, inspectable standalone C with static memory allocation, but lacks optimized kernels available in OpenVINO and TensorRT [Conlin et al., 2021, Ope, 2026, NVI, 2026].Source: §1 · p. 1
- The paper summarizes latency-allowance rules for DIII-D ML controllers and compares Keras2c, OpenVINO, and TensorRT on fusion neural networks and model components.Source: §1 · p. 1
2 Fusion Timescales Needed for Inference
Fusion control tasks operate on different timescales, from millisecond-scale events to slower plasma profiles. In each cycle, diagnostics are processed into model inputs and outputs become actuator commands, while prediction, safety, and communication needs constrain available time.
2 Fusion Timescales Needed for Inference
- Vertical displacement events can evolve on millisecond timescales, while temperature and density profiles evolve over more than 100 ms, so DIII-D control tasks run at different rates.Source: §2 · p. 1
- Diagnostics are signal-processed into quantities such as real-time magnetic equilibrium; ML outputs pass through control logic to actuator commands, alongside preprocessing, safety checks, and communication.Source: §2 · p. 2, Figure 1 · p. 2
- A tearing-mode event could be forecast about 200 ms before onset, while its controller still updates in less than 10 ms to respond to new measurements.Source: §2 · p. 2
- Robust control checks model inputs and error flags before issuing commands; asynchronous inference can leave the last completed output available while a slow call catches up.Separating checks from the learned model makes components easier to test and limits the effect of model failure.Source: §2 · p. 2
- Controllers use scalar signals, time-series windows, and camera frames, with MLP, recurrent, reservoir, and survival models; larger sequence models must meet timing and onboard-memory limits.Source: §2 · p. 2
3 Benchmarking deployment latency
The benchmark compares four inference configurations across ten fusion-control and diagnostic networks and components, using batch-one measurements on separate CPU and GPU nodes. No backend is fastest for every model, while TensorRT offers the largest reductions for models beyond one million parameters; timing variation and model support also differ.
3 Benchmarking deployment latency
- MILF-BENCH compares Keras2c, OpenVINO, TensorRT FP16, and TensorRT FP32, treating OpenVINO as the lowest allowable CPU latency and testing the benefit of reduced precision.Source: §3 · p. 3
3.1 Benchmark design
- The benchmark covers ten trained networks and model components from fusion control and diagnostic pipelines, including larger architectures TokaMind and TokEye not yet used for control.Source: §3.1 · p. 3
- Keras2c and OpenVINO ran on an Intel Xeon Platinum 8268 CPU; TensorRT 8 FP16 and FP32 ran on an NVIDIA Tesla V100S GPU, with separate nodes and batch size one.Runs lasted about 10 seconds with inputs requested at 1 kHz; serial calls meant slower configurations completed fewer calls, including four TokEye calls for Keras2c.Source: §3.1 · p. 3
3.2 Results
- No backend is fastest for every model: Keras2c has the lowest mean latency for one model, OpenVINO for five, TensorRT FP16 for two, and TensorRT FP32 for two.Source: §3.2 · p. 3
- For INPA-Net, mean latency was 2.28 ms with Keras2c, 0.311 ms with OpenVINO, 0.0693 ms with TensorRT FP16, and 0.0700 ms with TensorRT FP32; FP16 was 4.5× faster than the best CPU result.For TokaMind, OpenVINO on the CPU took 76.9 ms and TensorRT FP32 on the V100S took 2.20 ms, a 35× difference; for TokEye, Keras2c took 3.20 s, OpenVINO took 203 ms, and TensorRT FP16 took 1.01 ms, about 201× faster than the best CPU result. Figure 2 plots mean inference latency versus trained-parameter count; Keras2c and OpenVINO run on an Intel Xeon Platinum 8268, while both TensorRT configurations use TensorRT 8 on an NVIDIA V100S.Source: §3.2 · p. 3, Figure 2 · p. 4
- TensorRT gives the largest latency reductions beyond one million parameters, while Keras2c cannot convert TokaMind and TensorRT FP16 was not measured for it.Keras2c lacks the transformer modules TokaMind requires; TensorRT FP16 would require additional quantization.Source: §3.2 · pp. 3, 5
- Figure 3 compares per-call latency traces for the TM predictor, RTCAKENN, and INPA-Net across Keras2c, OpenVINO, and TensorRT; some OpenVINO and TensorRT traces show isolated slow calls, while Keras2c traces are steadier.The cited TensorRT panels use TensorRT 8 in FP32 on the V100S.Source: §3.2 · p. 4, Figure 3 · p. 4
4 Discussion and outlook
Standalone C remains useful for small models when predictable timing matters more than peak speed, while larger models may justify GPU inference. The discussion also emphasizes inference jitter and identifies benchmark areas left for future work.
4 Discussion and outlook
- After five million parameters, low-end CPU latency surpasses many physics phenomena, so GPU inference should be considered for larger models.Keras2C is most advantageous up to 10k parameters; the passage also says quantization appears to have less effect on latency, so FP32 may be preferred over FP16.Source: §4 · p. 5
- Although Keras2C is consistently slower, its latency determinism can make it valuable for stable control systems.Inference jitter matters because lag spikes can coincide with critical physics phenomena.Source: §4 · p. 5
- Reservoir-computing and recurrent models remain outside this benchmark because their stateful execution requires a separate protocol.Future work could also repeat the benchmark on control-oriented edge GPUs and the plasma control system during experiments.Source: §4 · p. 5
5 Conclusion
Across the tested fusion workloads, no inference configuration is best for every model. TensorRT configurations give the largest latency reductions for several million-plus-parameter models, and the conclusion recommends considering GPU inference above five million parameters.
5 Conclusion
- For models greater than five million parameters, the paper recommends considering GPU inference for deployment on fusion reactors.The TensorRT configurations give the largest reductions for million-plus-parameter models such as INPA-Net, TokaMind, and TokEye.Source: §5 · p. 5
- Keras2c, OpenVINO, TensorRT FP16, and TensorRT FP32 each achieve the lowest mean latency for at least one model.No configuration is best for every workload.Source: §5 · p. 5
- TensorRT configurations give the largest latency reductions for million-plus-parameter models including INPA-Net, TokaMind, and TokEye.The conclusion frames real-time fusion control as requiring inference that fits the relevant timescales.Source: §5 · p. 5