CERN Runs Neural Networks in 75 Nanoseconds on Raw Silicon

What happened

CERN's particle physicists have a filtering problem that makes your Kafka backlog look quaint. The Large Hadron Collider smashes proton bunches together every 25 nanoseconds — 40 million crossings per second — generating roughly 1 petabyte of raw sensor data per second. Storing all of it is physically impossible. The Level-1 (L1) trigger system must decide, in under 4 microseconds, which events might contain interesting physics (a Higgs boson decay, a supersymmetric particle, something never seen before) and which are background noise. It keeps about 1 in 400.

Traditionally, this filtering used hand-coded logic on FPGAs: threshold cuts on energy deposits, particle counts, and geometric patterns designed by physicists who knew exactly what signatures to look for. It worked, but it left a blind spot: if you only trigger on physics you already predict, you'll never discover physics you don't.

The solution CERN's Fast Machine Learning collaboration landed on is conceptually simple and technically extreme: train small neural networks in standard frameworks (Keras, PyTorch), then compile them directly into FPGA gate-level hardware using an open-source tool called hls4ml. The result is inference that completes in 75-200 nanoseconds — not milliseconds, not microseconds, nanoseconds — running as dedicated silicon logic rather than software on a processor.

Why it matters

### The anti-scaling-laws playbook

While the commercial AI world races toward trillion-parameter models requiring megawatts of power, CERN's trigger models have 100-1,000 parameters with 6-bit fixed-point weights. Some experiments use ternary quantization: each weight is -1, 0, or +1. These models are quantized so aggressively that each neuron becomes a handful of FPGA lookup tables, and the entire network runs in a single clock cycle with zero time-multiplexing.

The architectures are correspondingly minimal: 3-5 layer fully-connected networks with 64-16-8 node topologies for jet classification, boosted decision trees compiled via the companion Conifer library, and — most intriguingly — autoencoders trained for anomaly detection. The autoencoders learn to reconstruct known Standard Model physics; when reconstruction error spikes, that event gets flagged as potentially novel. Published in *Nature Machine Intelligence* in 2022, this approach by Govorkova et al. demonstrated that an unsupervised model running on an FPGA at 40 MHz can flag anomalous collision events without being told what new physics looks like — a genuine model-agnostic discovery trigger.

### The hls4ml pipeline

The technical chain from trained model to running silicon goes: Keras/PyTorch → QKeras quantization-aware training → hls4ml Python API → HLS C++ → Xilinx Vivado/Vitis synthesis → FPGA bitstream. The hls4ml library (GitHub: `fastmachinelearning/hls4ml`, ~1,100+ stars) supports multiple HLS backends including Vivado, Vitis, Intel HLS, and Catapult.

What makes this different from typical FPGA ML accelerators is the "fully unrolled" approach. Commercial FPGA inference engines time-multiplex operations across limited hardware resources — good for throughput, bad for latency. hls4ml instead instantiates every multiply-accumulate operation as dedicated hardware. This means a 3-layer network with 64 neurons in the first layer literally has 64 parallel multiplier blocks in silicon. The tradeoff is area (you use more FPGA resources per model) but you get deterministic, single-digit clock-cycle latency — exactly what a trigger system running at 40 MHz demands.

The key researchers driving this work span institutions: Javier Duarte (UC San Diego) and Nhan Tran (Fermilab) co-created hls4ml. Vladimir Loncar and Sioni Summers at CERN focus on optimizing implementations for the CMS experiment's trigger. Philip Harris (MIT) and Jennifer Ngadiuba (Fermilab) pushed the anomaly detection angle. Thea Aarrestad (ETH Zurich/CERN) demonstrated autoencoder-based triggers. The foundational paper — Duarte et al., "Fast inference of deep neural networks in FPGAs for particle physics" (JINST, 2018) — has become one of the most cited papers at the intersection of ML and experimental physics.

### Why not GPUs?

The obvious question: GPU inference is fast and flexible, so why FPGAs? Two reasons. First, the L1 trigger operates in the detector's front-end electronics with a fixed latency budget. A GPU-based system adds microseconds of communication overhead just for PCIe data transfer — that's the entire L1 budget consumed before inference starts. Second, the L1 trigger must process every single collision at 40 MHz with zero downtime. FPGAs run as pipeline hardware; they process one event per clock cycle with deterministic latency and no operating system, no driver stack, no garbage collection pauses.

LHCb's Allen project took the alternative GPU approach for its trigger — but LHCb made the radical architectural decision to eliminate its hardware L1 trigger entirely and send all data to a GPU farm. This works for LHCb's lower data rate but isn't feasible for CMS or ATLAS, which handle far higher luminosities.

What this means for your stack

If you work in edge inference, real-time systems, or FPGA development, the techniques here are directly applicable and the tooling is open source.

Quantization as a first-class design constraint. The CERN work, particularly the integration with Google's QKeras library, demonstrates that quantization-aware training from the start (not post-training quantization as an afterthought) lets you hit extreme bit widths without meaningful accuracy loss for classification tasks. If your deployment target has fixed-point hardware — FPGAs, DSPs, or even integer-only MCUs — training with target precision from epoch one is worth the setup cost.

hls4ml beyond physics. The library has already found adoption in satellite on-board processing, autonomous vehicle sensor fusion, and high-frequency trading — anywhere sub-microsecond inference on FPGAs matters. If you've been hand-writing HLS for ML inference, this tool can generate synthesizable C++ from your existing Keras or PyTorch models with configurable parallelism (the `reuse_factor` parameter trades latency for area).

The TinyML resonance. CERN's approach — make the model fit the hardware, not the other way around — is the same philosophy driving the TinyML community targeting microcontrollers and embedded sensors. The difference is degree: TinyML operates in milliseconds on ARM Cortex-M; CERN operates in nanoseconds on Xilinx Virtex UltraScale+. But the quantization techniques, pruning strategies, and architecture search methods transfer directly.

Looking ahead

The High-Luminosity LHC upgrade, expected around 2029, will increase collision pileup from ~60 to 140-200 simultaneous collisions per beam crossing. The CMS Phase-2 trigger upgrade, detailed in its Technical Design Report, relies heavily on ML-based triggers to maintain physics reach despite this data explosion. The collaboration is already exploring attention mechanisms and lightweight transformers within the trigger latency budget — an engineering challenge that would have seemed absurd five years ago. For the broader ML infrastructure community, CERN's trigger system is a proof-of-existence that useful neural networks can run in under 100 nanoseconds if you're willing to co-design the model and the hardware from the start. The 1,000-parameter model that catches new particles might be the most important neural network that nobody in Silicon Valley is paying attention to.