Following a Hybrid Job Through a Quantum-HPC Stack

A quantum processor in a room next to a supercomputer is a demonstration. A quantum processor inside the job queue is a resource. The Leibniz Supercomputing Centre in Munich crossed that gap with a 20-qubit superconducting system running in the SuperMUC-NG environment, and IQM and the centre later published operational telemetry covering roughly 250 days of running it. That record is a scheduling, monitoring, network-design and latency-engineering problem rather than a physics one, and all of it applies to hardware that loses its state in microseconds.

A hybrid job is the normal shape of useful quantum work. Classical code prepares the problem, a quantum circuit performs the part classical hardware can’t do, and classical code interprets what comes back. Every layer described below exists to make that round trip routine instead of manual. This article follows one such job from submission to result and names the layer responsible at each step.

Getting into the queue

Your users already know how to ask for GPUs. They write a Slurm batch script, request a resource, and wait. Before a standard interface existed, every centre that installed a QPU wrote its own submission path around that habit: a separate queue, its own authentication flow, its own monitoring hooks. None of that work moved to the next site.

The Quantum Resource Management Interface, or QRMI, closes the gap by presenting a QPU to Slurm as a schedulable resource alongside CPU and GPU partitions. IBM started the interface, with contributions from Pasqal, Rensselaer Polytechnic Institute and the STFC Hartree Centre. The reference case is CINECA in Bologna, where a Pasqal neutral-atom machine is scheduled against the Leonardo supercomputer through the same submission path researchers already use for classical work.

QRMI is deliberately indifferent to hardware. Superconducting, trapped-ion or neutral-atom, the plugin handles authentication, allocation, job lifecycle and monitoring through interfaces your operations team already runs. We put this layer first in our systems-integration teaching, and the reason is practical. Teams that design the physical link before the scheduling interface end up with a fast machine nobody can book.

Choosing a backend at runtime

The job is now allocated. Something has to turn the user’s program into instructions a specific device will accept.

CUDA-Q is NVIDIA’s open-source platform for writing the whole hybrid job as one program in C++ or Python. Classical kernels and quantum kernels live in the same source file, and the compiler emits code for a physical QPU or for a GPU-based simulator. The backend is chosen at runtime, so the same quantum subroutine can target a trapped-ion system, a neutral-atom system or a simulator during development.

That portability is genuine at the circuit level and thin below it. Pulse-level control, calibration-sensitive tuning and topology-aware compilation still require backend-specific code. Plan for a translation layer between framework-level circuits and the pulse instructions your control electronics execute. OpenQASM 3 is the usual interchange format at the boundary, generally with vendor extensions attached.

The microsecond loop

Useful circuits measure some qubits partway through and then act on the answer. A measured value has to reach a classical processor, get processed, and come back as an instruction before the remaining qubits decohere. On superconducting hardware that budget is microseconds. A round trip taking a millisecond is a round trip the qubits do not survive.

NVQLink is NVIDIA’s interconnect for that loop. NVIDIA announced it at GTC in October 2025. The published specification is 400 Gb/s of GPU-QPU throughput and a measured round trip under four microseconds, carried over RDMA over Converged Ethernet, the same RoCE fabric large AI training clusters already run on standard 400 GbE hardware. Dell has validated several of its server platforms as real-time hosts and reproduced the sub-four-microsecond figure.

This is not exotic networking, and a centre already running GPU workloads owns most of the physical infrastructure it needs.

Two constraints follow. The GPU node must sit within Ethernet distance of the control rack, which in practice means the same room or the one next door. And the control electronics have to speak the protocol, so NVQLink compatibility belongs in the control-system specification rather than in a later upgrade plan. The three major Western control vendors, Qblox, Quantum Machines and Zurich Instruments, all support it.

Decoding faster than errors arrive

The vocabulary gets dense here, and only two ideas underneath it do real work: the syndrome and the backlog.

An error-corrected logical qubit is built from many physical qubits. The machine repeatedly measures parity checks across them, and each round produces a syndrome, a set of measurement outcomes indicating where an error probably occurred. A decoder is the classical computation that reads those syndromes and infers which correction to apply. It runs on the classical side of the link, which is why it belongs in an integration article rather than a hardware one.

The backlog condition is the whole engineering constraint. Syndromes arrive at a fixed rate set by the hardware. If the decoder consumes them more slowly than they arrive, unprocessed syndromes accumulate without bound, the correction falls behind physical reality, and the logical qubit fails. Throughput, not peak speed, is the number to specify.

The budget therefore follows the modality. A surface-code cycle on superconducting hardware runs near one microsecond, leaving the decoder roughly ten microseconds of headroom before the backlog grows. Trapped-ion gates are far slower and the budget is correspondingly generous: Quantinuum reported a 67-microsecond reaction time for a qLDPC decoder over NVQLink, against a requirement in its own system measured in milliseconds.

Three paths are available to an integrator in 2026.

• Dedicated FPGA decoders. Riverlane’s Deltaflow 2 runs on its own hardware and connects to control electronics over QECi, an open control-to-decoder interface. It has been deployed at OQC and at Oak Ridge. No GPU node is required, which makes it the shortest path for a team that does not want to build decoding infrastructure.
• GPU-hosted matching decoders. PyMatching is the open-source reference implementation and is production-grade for offline batch decoding. Real-time use means a dedicated GH200 or GB200-class node connected over NVQLink and running continuously.
• Learned decoders. Google’s AlphaQubit, published in Nature, reached the highest reported accuracy on Willow data using a recurrent neural network. Inference cost keeps it out of real-time deployment for now. Treat it as a research direction rather than a procurement option.

Whichever path you take, decide it before the control electronics are ordered. Offline decoding is a data-analysis capability. Real-time decoding is an architecture.

Decisions that precede the hardware

Network path. A dedicated VLAN from the cryostat control rack to the GPU node, on private fiber into the HPC network. For cloud-attached operation instead of real-time coupling, plan for gigabit-class egress with TLS-terminated REST or gRPC endpoints. Classified workloads need a dedicated VPN or an air gap, and that decision changes the physical layout.

Identity and roles. Integrate with your existing identity provider over OIDC (OpenID Connect) or SAML (Security Assertion Markup Language) rather than standing up a quantum-specific account system. Three roles cover most deployments: administrators with full system access, quantum developers who can submit circuits and read calibration data, and end users who can submit circuits only. Per-tenant isolation of jobs and results is a requirement from the first external user onward.

The API’s own cryptography. The service you are building is a classical web service, and its authentication flows and data in transit are exposed to harvest-now-decrypt-later collection like any other. Migrate the API surface to post-quantum algorithms at build time: ML-KEM, standardized as FIPS 203, for key establishment, and ML-DSA, standardized as FIPS 204, for signatures. Doing this at deployment costs a sprint. Retrofitting it once external tenants are connected costs a migration project. The methodology is documented at pqcframework.org.

Two teams and one interface

The engineer who commissions a dilution refrigerator is not the engineer who debugs a VLAN. Both are essential, and they come from different career paths.

The integration side needs one or two HPC and DevOps engineers for NVQLink configuration, the Slurm plugin, network management, GPU node setup and monitoring. No quantum physics background is required. Slurm administration, RDMA networking and GPU cluster operations are the actual prerequisites. Add one software engineer for the API surface, authentication and tenant isolation, and one quantum software engineer to own the framework-to-pulse translation layer. A system running real-time error correction needs a fourth person who owns decoder configuration and watches decoder throughput against the syndrome rate.

The control electronics are the interface between this team and the hardware operations team. Both groups should be able to name who owns that boundary before the first crate arrives.

Procurement consequences

1. Write NVQLink compatibility into the control electronics specification. Retrofitting the interconnect means replacing the controllers.
2. Budget the GPU node as part of the quantum system, not as a later addition. It hosts decoders, accelerates calibration and runs the classical half of hybrid algorithms from day one.
3. Scope QRMI deployment inside the HPC integration workstream. The alternative is a custom scheduler that only works at your site.
4. Include the post-quantum migration of the service API in the initial build, with FIPS 203 and FIPS 204 named in the requirements.

None of these is expensive on the first pass. All four are expensive as retrofits, and that asymmetry is the strongest argument for treating integration as a design activity rather than a commissioning one.

Quantum Academy’s systems-integration teaching covers this stack in depth, including the control-electronics boundary, decoder selection and the facility work that surrounds both. Current programs are listed at quantumacademy.com/.