Speaker
Description
Quantum processors - which are incresingly being installed in supercomputing centres across Europe - are commonly built with their own vendor-specific toolchain: workable for one machine, not a basis for a centre operating several, and even less for a network of centres. The Quantum Device Management Interface (QDMI), the device-facing layer of the Munich Quantum Software Stack (MQSS), addresses this with a narrow C API through which compilers, schedulers and benchmarking tools query a device's properties (topology, native gates, calibration data) in an agnostic way. QDMI comprises both the device layer, the driver layer, and the session layer.
QEX, the Quantum Excellence Centre funded by the EuroHPC JU, brings together European HPC centres operating heterogeneous quantum hardware, requiring common interfaces rather than one vendor-specific integration per machine. Running a benchmark, a scheduler, or any application written only once, in any QPU in that network, is posible through a standard device layer that bears the load of translating it.
We report the integration of QMIO, CESGA's 32-qubit superconducting QPU, which users reach as a Slurm partition of the centre's HPC system, as a QDMI device. The device is a C layer with an embedded CPython bridge to QMIO's native control software. It is contributed to the shared MQSS device suite and exercised through three paths: continuous integration against a calibration-derived noise model, batch execution on the production QPU partition through Slurm, and end-to-end operation behind the QDMI reference driver. Controlled experiments on hardware, running the same workload on different physical qubit layouts, show that the layer transports results faithfully: outcomes follow the device's calibration data, including qubits flagged as uncalibrated, rather than being smoothed over by the abstraction.
This contribution also surfaces four illustrative constraints that belong to the driver and session layers of the architecture rather than to any single device, and will recur at any centre doing the same. We are contributing these to the open QDMI 2.0 specification, while it is still being defined. We close with the operational questions they raise for a centre hosting devices from several vendors: incompatible runtimes in one driver process, and scheduling against a federated QDMI network.
This work is funded by the EuroHPC JU under grant agreement 101194491 (QEX).