Authors: Aleksander Wennersteen, Lucia Garbini
QPUs are no longer limited to the lab and are now entering the operating environment of HPC centers and supercomputing workflows.
For many years, the central question was whether quantum processors could be built, controlled, and programmed at all. The field has moved beyond that question and today is in a significantly different position. Over the past year, Pasqal and its partners have published, deployed, and demonstrated several pieces of the architecture required to bring quantum processing units (QPUs) into the high-performance computing and supercomputer environments where they have the potential to make scientific breakthroughs.
Pasqal is already deploying neutral-atom QPUs into major computing environments. Under the European HPCQS project, Pasqal QPUs have been integrated with NVIDIA accelerated computing at CEA in France and Forschungszentrum Jülich in Germany. Pasqal has also inaugurated Italy’s first neutral-atom quantum computer at CINECA, where the system is being installed at one of Europe’s major supercomputing centers.
This makes quantum integration an operational question, not just a hardware one.
A user-centric approach to HPC-QC integration
A user-centric HPC-QC environment starts with the way users already interact with HPC centers. Users submit jobs through familiar schedulers, share resources, and move between testing and production without changing the whole workflow. System administrators maintain the system and design policies so that the resources are used as intended. As described in the overview on a user-centric HPC-QC environment, quantum has to fit into that model rather than sit outside it, and this requires more than just connecting a QPU to the network.
QPUs don’t behave exactly like CPUs or GPUs. QPUs are scarce and often need device-specific handling around calibration and availability that standard HPC schedulers were not built to manage. The right architecture separates these concerns: the scheduler handles allocation and policy, while a quantum-aware layer manages the detailed interaction with the QPU. Pasqal is developing part of this layer as open-source software, called Warden, to enhance the integration. A hybrid job gets submitted like any other HPC workload, so that users keep a single end-to-end workflow without having to operate two separate systems.
Building the integration across the stack, together
Several organisations contribute to this infrastructure. The Quantum Resource Management Interface (QRMI) work is the clearest example: Pasqal contributed to the specification, which originated from an initiative established by IBM, with collaborative development from Pasqal, STFC Hartree Centre (STFC), and Rensselaer Polytechnic Institute (RPI). QRMI defines a vendor-neutral way for resource managers and applications to interact with quantum resources, in practice, making it possible to treat a QPU as a schedulable resource in the same environment used for CPUs and GPUs. It is also designed to work across scheduler environments. Early quantum-classical scheduling integration work by IBM, Pasqal, STFC, and RPI used Slurm-based plugins and workflows, and Slurm by SchedMD was the first scheduler environment integrated with QRMI. Through joint work with HPC-Gridware GmbH, Pasqal has extended QRMI support to Open Cluster Scheduler (a Grid Engine compatible scheduler), showing the model can move across different HPC environments without changing the user workflow.
The collaboration with IBM goes further than QRMI. Pasqal, which is part of the IBM Quantum Network, has been working with IBM on a shared software stack that includes the Qiskit-Pasqal provider, which allows researchers already working with Qiskit to run those workflows on Pasqal QPUs without switching tools. The goal is the same as with QRMI: quantum should fit into the environments people already use, not demand a separate one. This work also connects to the broader quantum advantage framework developed jointly with IBM, which defines quantum progress in measurable terms across hardware, jobs execution, and supercomputing infrastructure, treating them as parts of the same system rather than separate concerns.
With NVIDIA, the collaboration operates at several levels. Pasqal, a member of NVIDIA Inception, is integrating its QPUs with NVIDIA’s accelerated computing to create hybrid quantum-classical architectures capable of running useful applications. At the application code layer, Pasqal integrated its devices with NVIDIA CUDA-Q. At the workflow level, CUDA-Q is integrated with QRMI so hybrid workloads can run through standard HPC pipelines. Finally, at the hardware level, Pasqal is supporting NVIDIA NVQLink, NVIDIA’s open architecture for low-latency, high-throughput coupling between quantum processors and accelerated compute. Where NVIDIA CUDA-Q and QRMI make quantum easier to schedule and use, NVIDIA NVQLink points toward the next step: tighter integration between GPU and QPU control, enabling more demanding applications in calibration, real-time feedback, and eventually error correction.
These collaborations are not parallel tracks. They address different layers of the same integration problem: shared interfaces, common software tooling, and the hardware coupling that will matter as systems scale.
It takes an ecosystem
All of these integration efforts point in the same direction: quantum is moving from isolated systems toward something the wider HPC and data center ecosystem can actually support.
Pasqal’s work on quantum-HPC integration is about the practical parts of making QPUs usable in production environments: scheduling and access, observability and operations, and the infrastructure needed to run them reliably. We also work on sharing what we build and learn with the overall community. Two recent projects we have contributed to are the Open Quantum-HPC Software Ecosystem (openQSE), which surveyed existing solutions and proposed a shared reference architecture for quantum-HPC software stacks, and the Open Compute Project white paper, which looks at the deployment constraints of running QPUs inside data center environments. Additionally, Pasqal actively contributes to European Quantum Systems and Software Summit (EQS3) series.
The point of these integration efforts is simple: making quantum computing useful requires more than the QPU itself. It must be integrated with accelerated supercomputers and their operational workflows. That depends on more than the QPU itself. Schedulers, resource interfaces, deployment models, and the underlying infrastructure all have to line up. The work at Jülich, CEA, and CINECA shows what that looks like in practice.
That is also why the ecosystem matters. Open interfaces and shared architectures make it possible to move quantum resources across different environments without rebuilding the whole stack each time. If quantum is going to fit into HPC, that work has to happen across the stack.
The next phase of quantum computing will be judged not only by the QPU characteristics, but by whether those QPUs can be operated and used inside real computing environments.
