QM’s Orchestration Platform for
HPC Centers and Hubs
QUANTUM FOR HPC
HPC centers are becoming a natural home for quantum computing, where quantum processors can operate as specialized accelerators inside heterogeneous classical infrastructures. To make this practical, quantum systems must connect to familiar HPC workflows while still meeting the real-time requirements of quantum control, calibration, feedback, and error correction. This requires more than submitting circuits from a server: it requires a layered classical-quantum architecture where schedulers, compute nodes, accelerators, controllers, and QPUs work together without placing real-time quantum operations on the HPC critical path.
A layered classical-quantum architecture
QM delivers best-in-class platforms for integrating quantum processors into HPC environments, enabling seamless coupling of quantum systems into existing infrastructures. Our control stack is modality-agnostic, supporting Superconducting qubits, Semiconductor spins, Neutral Atoms, and Defect Centers, so HPC operators can standardize on a single platform across QPU technologies and vendors.
HPC nodes dispatch quantum workloads to a dedicated server connected to the OPX1000 via the Open Acceleration Stack, closing the real-time loop in microseconds. QEC decoding, calibration, and feedback run on dedicated classical accelerators next to the qubits, off the HPC’s critical path. From the HPC user side, the workflow is familiar. Allocate the resources through your scheduler and run.
IQCC: a working blueprint, in production today
The IQCC is our reference deployment for HPC-integrated quantum computing. Built and operated by us, IQCC runs the same architecture described on this page; HPC nodes dispatching workloads to an OPX1000-based control stack, with real-time QEC and calibration off the critical path.
IQCC isn’t a one-time demo or a lab prototype. It’s a live system, used by researchers and customers around the world every day, and it’s the blueprint we bring to every HPC center we integrate into. The reference design, the software stack, the operational playbook, all of it is proven in production, and all of it is portable to your environment.
A QPU-independent development platform
The QPU-independent development platform, built on QM’s Open Acceleration Stack, is a solution for HPC vendors who want to start integration work today without the overhead of running a QPU from day one. It pairs an OPX1000 with an accelerator via the OAS, together with reference programs that run on the user side.
From the HPC’s perspective, the OPX1000 and its dedicated accelerator server act as a functional quantum computer: you integrate them exactly as you will integrate a real QPU. The software framework injects simulated measurements (e.g. QEC syndrome data simulated via Stim), so the classical-quantum loop can run end-to-end without actual quantum hardware on site.
Use it to benchmark job latencies, develop the surrounding stack (scheduling, Slurm, hybrid jobs), and validate the integration before an actual QPU arrives. When one is connected, the stack you built runs unchanged. Other reference programs cover workloads like fault-tolerant quantum computing and ML-driven tasks including calibration and optimization.
FAQs
How do HPC users submit and schedule quantum jobs?
Through the same tools they already use — allocate the resource through your scheduler (Slurm, Kubernetes) and run. At the applications layer, HPC clusters schedule hybrid jobs in milliseconds, so QPU jobs enter the queue like any other computing accelerator. The classical accelerators then close the low-latency loop with the controller for the real-time work, keeping that complexity off the user-facing scheduling side.
What is QM’s Open Acceleration Stack, and what does it do for HPC centers?
The Open Acceleration Stack is QM’s modular framework for connecting hybrid controllers directly to classical accelerators — CPUs, GPUs, and FPGAs — so heavy classical computation runs inside the quantum runtime. It lets QEC decoding run on high-performance accelerators while the controller streams syndromes to the server and feed-forward closes the loop, and it’s built for the data center: HPC-QC integration from the quantum control layer up, scaling by adding OPX1000 controllers as the QPU grows and accelerator servers as compute demand grows.
What round-trip latency can the classical-quantum loop achieve, and why does it matter?
The OPNIC interconnect keeps the OPX1000-to-accelerator round-trip in the microsecond regime, with controller-accelerator round-trip latencies of 4 µs, while the control layer itself applies feedback in hundreds of nanoseconds. This matters because fault-tolerant QEC requires decoding faster than syndromes are extracted. Otherwise a backlog grows and the computation fails. So the loop has to stay within the roughly 1few µs budget (for superconducting qubits) for useful decoding. Keeping the full round-trip well under that bound is what makes real-time error correction possible.
Which classical accelerators and vendors does the platform support?
The stack is vendor-flexible by design, supporting CPUs, GPUs, and FPGAs across multiple vendors, including NVIDIA Grace Hopper and Grace Blackwell superchips, Intel and AMD x86 CPUs, and dedicated FPGA decoders such as Riverlane Deltaflow and the AMD FPGA Decoder. Centers aren’t locked into a single accelerator choice.
Can we develop and benchmark the integration before we have a QPU?
Yes. QM’s QPU-independent development platform pairs with an OPX1000 and an accelerator over OPNIC, with a software framework that can inject simulated QEC measurements (for example via Stim, a standard QEC simulator). This lets the full classical-quantum loop run end-to-end without quantum hardware on site, so teams can benchmark latency, build out the surrounding stack (scheduling, Slurm, hybrid jobs), and validate the integration in advance. When a QPU arrives, you connect it and the stack you built runs unchanged.
