This article is part of the How to Build a Quantum Computer Deep Dive series, which covers the practical engineering of assembling quantum computers from modular components across every major qubit modality. The capstone article introduces the series and the Quantum Open Architecture model that makes it possible.
This article draws extensively on Applied Quantum‘s Systems Integration Playbook (v2.0, May 2026), the primary source for signal chain specifications, calibration sequences, integration timelines, and troubleshooting data throughout the series. Where other sources supplement the playbook, they are cited inline. Cost figures are list-price estimates from vendor disclosures and Applied Quantum’s field experience; negotiated prices vary 20–40%.
A quantum computer that is not connected to classical compute resources is a physics experiment, not a computational tool. Every algorithm of practical interest requires hybrid execution: classical pre-processing to prepare the problem, quantum circuits to perform the computation that classical hardware cannot, and classical post-processing to interpret the results. Error correction decoding, the operation that makes fault-tolerant quantum computing possible, is itself a classical computation that must execute in real time while the quantum processor runs. Without tight integration between QPUs, GPUs, and CPUs, a quantum computer sits idle between shots while a researcher manually shuttles data between systems.
This article covers the integration stack that connects a quantum computer to classical HPC infrastructure: the NVQLink interconnect, the QRMI scheduling interface, the CUDA-Q programming model, the Western software stack and its fragmentation, the QEC decoder path, and the competitive intelligence question raised by China’s Origin Pilot. For the physical hardware being integrated, see the modality-specific build guides for superconducting, trapped-ion, neutral-atom, photonic, and silicon-spin systems. For the control electronics that sit between the HPC network and the QPU, see my earlier deep dive.
NVIDIA introduced NVQLink at GTC Washington DC on 28 October 2025 with 17 quantum hardware builders, 5 control system providers, and 9 U.S. national laboratories (Brookhaven, Fermilab, LBNL, LANL, MIT Lincoln Lab, ORNL, PNNL, Sandia, plus NIST). At GTC 2026, NVQLink became publicly available through the release of the cudaq-realtime API in the CUDA-Q platform.
The architecture provides 400 Gb/s GPU-QPU throughput and measured round-trip latency of 3.96 µs maximum (Caldwell et al.) using RDMA over Converged Ethernet (RoCE) on commercially available 400 Gb/s Ethernet hardware. Dell has validated the XE7745, XE9680, R7715, and R770 server platforms as Real-time Host systems, reproducing NVQLink latencies under 4 µs.
What this means in practice: a quantum control system (Qblox Cluster, Quantum Machines OPX+, or Zurich Instruments QCCS) sends qubit measurement data to a GPU node over a standard Ethernet link at microsecond-scale latency. The GPU processes that data (decoding error syndromes, computing conditional operations, running classical subroutines of hybrid algorithms) and returns instructions to the controller before the next quantum operation must begin. The round trip is fast enough for real-time quantum error correction on superconducting hardware, where a surface-code cycle takes approximately 1 µs and the decoder must respond within roughly 10 cycles.
The ecosystem adoption since the October 2025 launch has been rapid. Qblox adopted cudaq-realtime for OQC’s full-stack quantum systems, enabling microsecond-level hybrid feedback loops. Quantum Machines integrated cudaq-realtime with their Open Acceleration Stack. Q-CTRL reports a 50x reduction in classical overhead and 5x speedup in overall wall-clock time by integrating NVQLink with their calibration software at the Q-PAC deployment, with enhanced NVQLink support planned throughout 2026. SDT deployed the first tightly-coupled hybrid quantum-classical data center in Korea using their controller with NVQLink connecting an Anyon Computing QPU to NVIDIA GPUs. Diraq is using NVQLink to connect silicon-spin quantum processors with accelerated computing for calibration, autotuning, and benchmarking. HPE has incorporated NVQLink into its vision for quantum supercomputing.
No credible Western competitor to NVQLink exists as of May 2026. Any integrator planning an HPC-connected quantum deployment should specify NVQLink compatibility in the control electronics procurement.
The Quantum Resource Management Interface (QRMI) is the abstraction layer that formally exposes QPUs as Slurm-native schedulable compute resources. A researcher submitting a hybrid quantum-classical job to an HPC cluster sees the QPU as another accelerator alongside CPU and GPU nodes. Standard Slurm job submission, scheduling, and monitoring workflows apply. No quantum-specific scheduler is needed.
QRMI originated from an initiative established by IBM with collaborative development from Pasqal, Rensselaer Polytechnic Institute, and the STFC Hartree Centre. Pasqal demonstrated QRMI integration with NVIDIA CUDA-Q in March 2026, with the on-premises stack first deployed at CINECA to integrate with Leonardo, the EuroHPC pre-exascale supercomputer. The integration is also available on Pasqal’s cloud platform and in CUDA-Q 0.14 as a backend option.
QRMI is designed to be hardware-agnostic, modality-agnostic, and vendor-agnostic. A properly implemented QRMI layer means the HPC center does not need to know whether the QPU behind the scheduler is superconducting, trapped-ion, or neutral-atom. The abstraction handles authentication, resource allocation, job lifecycle management, and monitoring through standard interfaces that HPC operations teams already understand.
For an integrator, QRMI eliminates the need to build custom quantum-aware schedulers. The HPC/DevOps engineer configures QRMI as a Slurm plugin, registers the QPU as a schedulable resource, and standard HPC workflows apply from that point. This is a significant reduction in integration complexity compared to the pre-QRMI model where each quantum hardware vendor provided its own job submission API with its own authentication, scheduling, and monitoring semantics.
CUDA-Q is NVIDIA’s open-source platform for hybrid quantum-classical programming. It provides a unified framework combining CPUs, GPUs, and QPUs under a single programming model, with support for C++ and Python. CUDA-Q compiles quantum circuits to target-specific backends (physical QPUs or simulators) and manages the interleaving of classical and quantum kernels within a single program.
For integrators, CUDA-Q matters because it is hardware-agnostic by design. A program written in CUDA-Q can target a Pasqal neutral-atom QPU, a Quantinuum trapped-ion system, an IQM superconducting processor, or a GPU-based quantum simulator without rewriting the quantum subroutines. The backend is selected at runtime. This portability is not complete in practice (pulse-level control and hardware-specific optimizations still require backend-specific code), but at the circuit level, CUDA-Q provides the closest thing the Western stack has to a universal quantum programming model.
CUDA-Q adoption is accelerating. TII integrated its Qibo framework for hybrid workload validation. memQ demonstrated its Extensible Distributed Quantum Compiler (xDQC) built on CUDA-Q, simulating hundreds of qubits across eight QPUs. Hiverge integrated CUDA-Q with an AI platform that uses LLM agents to translate natural-language problem descriptions into executable quantum circuits.
This is where honest assessment is needed. The Western quantum software stack is fragmented across vendor-specific layers, and no single download integrates them into a coherent operating system. The contrast with China’s Origin Pilot (see below) is instructive.
The stack has stratified into five functional layers:
Pulse and firmware. Direct waveform programming with sub-nanosecond timing. QUA (Quantum Machines), Q1ASM (Qblox), LabOne Q (Zurich Instruments), Pulser (Pasqal), Qiskit Pulse (IBM heritage). Q-CTRL Boulder Opal generates error-suppressing pulses on top of these vendor-specific layers.
Calibration. Automated tuning of qubit parameters. Q-CTRL Boulder Opal Scale-Up, QuantrolOx Quantum EDGE, QM QUAlibrate. Each integrates with specific control vendors.
Framework. High-level circuit and algorithm development. Qiskit (IBM, largest user base), Cirq (Google), CUDA-Q (NVIDIA, hardware-agnostic, hybrid-first), PennyLane (Xanadu, quantum ML focus), OpenQL (QuTech), QPanda (Origin Quantum, Chinese ecosystem). OpenQASM 3 is the converging intermediate representation.
Middleware and orchestration. Job scheduling, queue management, multi-user quotas, hybrid workflow lifecycles. Most Western integrators assemble this from Kubernetes/Slurm plus custom REST/gRPC APIs. QRMI is the emerging standard for the Slurm-facing interface. The Quantum Utility Block (QUB) reference architecture from QuantWare + Q-CTRL + Qblox provides a pre-validated orchestration pattern.
Operating system. This is the gap. No Western vendor offers a single-download quantum OS that integrates driver management, resource scheduling, multi-user quotas, automatic calibration, and hybrid workflow orchestration into one installable package.
The fragmentation is manageable. Competent integration teams build working stacks from these components every day. Q-PAC runs on a stack assembled from Qblox + Q-CTRL + custom orchestration. IQM/LRZ runs on the Munich Quantum Software Stack. Every EuroHPC quantum site has assembled its own integration layer. But “manageable” is not “solved.” Each integration is a custom project. There is no apt-get install quantum-os.
On 26 February 2026, Origin Quantum made Origin Pilot V4 available for public download. This is the first publicly downloadable quantum operating system. It supports superconducting, trapped-ion, and neutral-atom hardware with unified driver management, resource scheduling, multi-user quotas, automatic qubit calibration, parallel quantum task execution, and hybrid quantum-classical-AI workflow orchestration. It is deployed on Origin’s Wukong series of quantum computers.
Guo Guoping, Origin Quantum’s chief scientist, described it as the “soft heart” of the quantum computing ecosystem. The release aligns with China’s 15th Five-Year Plan (2026-2030), which identifies quantum technology as one of six strategic “industries of the future.”
The important nuance: Origin Pilot is publicly downloadable but not open-source in the OSI sense. It is a proprietary system made available for download. Origin Quantum has been on the U.S. Entity List since May 2024. Western enterprise customers, government agencies, and regulated-sector organizations should not deploy Origin Pilot. It is competitive intelligence, not a deployment option.
But as competitive intelligence, it is significant. Origin Pilot demonstrates what a unified quantum OS looks like: a single software layer that manages the full lifecycle from hardware initialization through calibration to multi-user job scheduling. No Western company offers this. The QUB reference architecture comes closest, but it is a reference design, not a downloadable installation. Whether the Western market converges on a single OS or continues with integrator-assembled middleware stacks is an open question. What is not open is whether the capability gap exists. It does. I covered this in detail in my quantum operating system analysis.
Real-time quantum error correction is the capability that transforms a quantum computer from a NISQ-era research tool into a fault-tolerant computational resource. The decoder is the classical computation that processes error syndrome measurements (produced every surface-code cycle, roughly every microsecond on superconducting hardware) and determines which corrections to apply to the logical qubit.
The decoder must run fast enough to keep up with the syndrome data rate. For a distance-7 surface code on superconducting hardware with a 1 µs cycle time, the decoder must respond within roughly 10 µs. NVQLink’s 3.96 µs round-trip latency fits within this budget, making GPU-hosted decoders practical.
Riverlane Deltaflow 2. FPGA-based decoder with an ASIC roadmap. Deployed at OQC CentreSquare (July 2025) and Oak Ridge National Laboratory (September 2025). Integrated with Qblox control electronics via NVQLink (March 2026). The only commercially available, vendor-supported, real-time decoder path for integrators who do not want to build their own. Riverlane’s target: MegaQuOp (10⁶ error-corrected operations) as a milestone for production-grade fault tolerance.
Google AlphaQubit. ML-based decoder (recurrent neural network) that achieved the highest accuracy on Google Willow data, published in Nature. Not yet real-time. Requires significant GPU resources for inference. Research-grade, not commercially deployed.
NVIDIA NVQLink decoder hosting. GPU-hosted decoders running on Grace Hopper or GB200 class hardware, connected via NVQLink to control electronics. Quantinuum’s NVQLink demonstration achieved a 67 µs reaction time for a qLDPC decoder, approximately 32x faster than Helios’ 2 ms requirement. This validates GPU-hosted decoding even for trapped-ion systems with slower gate times.
IBM FPGA/ASIC decoder. Custom FPGA implementation targeting sub-microsecond latency. Internal to IBM, not commercially available.
PyMatching. Open-source Union-Find decoder (Oscar Higgott). Production-ready for offline batch decoding. Real-time use requires integration with NVQLink or custom FPGA hosting.
For a 2026 deployment that needs real-time QEC capability, the recommendation is Riverlane Deltaflow 2 integrated with Qblox or QM control electronics via NVQLink. This is the path of least resistance for an integrator. It requires a dedicated GPU node (NVIDIA GH200 or GB200 class) connected via 400 Gb/s Ethernet to the control rack, running the decoder continuously. This GPU node is not optional for QEC-ready systems; without it, error correction is offline-only.
Five deployments demonstrate production-grade HPC-quantum integration as of May 2026:
IQM/LRZ Euro-Q-Exa (Munich): IQM Radiance 54-qubit QPU integrated into the SuperMUC-NG HPC environment via the Munich Quantum Software Stack. Zurich Instruments control. 250 days of calibration telemetry published in arXiv:2509.12949. A 150-qubit upgrade is planned by end of 2026. Four IQM quantum computers now installed at LRZ.
Pasqal/CINECA (Bologna): 140-qubit neutral-atom QPU integrated with Leonardo pre-exascale supercomputer via QRMI/Slurm. First European supercomputer supporting hybrid HPC-QPU workloads in a standard Slurm environment.
Jülich Supercomputing Centre (Germany): First European DGX Quantum deployment, with Quantum Machines and Arque Systems.
Israel IQCC (Israel Quantum Computing Center): QuantWare Contralto QPU + ORCA photonic system + NVIDIA DGX classical compute + Quantum Machines OPX+ controller. Multi-modality hybrid deployment.
Q-PAC (Denver): QuantWare QPU + Qblox control + Maybell cryostat + Q-CTRL calibration. NVQLink-based GPU cluster integration on the roadmap for 2026, with Q-CTRL reporting 50x classical overhead reduction and 5x wall-clock speedup in early NVQLink demonstrations.
For the HPC/DevOps engineer responsible for the classical infrastructure connecting the quantum computer to the HPC environment:
Network topology. Dedicated 10/25/100 GbE VLAN from the cryostat control rack to the NVQLink GPU node. Private fiber to the HPC network. For NVQLink real-time operation, the GPU node must be within the Ethernet distance limit of the control electronics (practically, in the same room or adjacent rooms). For cloud-attached operation: 1+ Gbps egress with TLS-terminated REST/gRPC APIs. For classified workloads: dedicated VPN or air-gap.
API design. OpenQASM 3 circuits plus provider-specific extensions. REST/Python SDK following the patterns established by Qiskit Runtime, AWS Braket, and Azure Quantum. Required capabilities: synchronous and asynchronous circuit submission, pulse-level access (gated by user role), calibration data retrieval, job and queue introspection, per-tenant quotas and quality metrics.
Authentication. OIDC or SAML integration with the organization’s identity provider. Per-tenant isolation of jobs and data. Role-based access control separating administrators (full system access), quantum developers (circuit submission, calibration data read), and end users (circuit submission only).
PQC migration of the API surface. This connection to the broader quantum security picture is easy to miss but matters for any quantum service exposed to external users. The classical API surface of a quantum computing service (the REST endpoints, the authentication flows, the data in transit) should be migrated to post-quantum cryptography from day one. ML-KEM (FIPS 203) for key exchange. ML-DSA (FIPS 204) for authentication. HNDL risk assessment for any data transiting between the quantum service and its users. An organization that operates quantum computers while leaving its own API surface vulnerable to quantum attack invites scrutiny. The deadlines are set by regulators and clients, not by Q-Day predictions. The PQC Migration Framework at pqcframework.com provides the structured methodology for this migration.
HPC-quantum integration requires a different skill set from QPU hardware operation:
One to two HPC/DevOps engineers for NVQLink configuration, QRMI/Slurm plugin deployment, network VLAN management, GPU node setup, and monitoring integration (Grafana, Prometheus). These engineers come from classical HPC backgrounds and do not need quantum physics expertise. They need Slurm administration experience, RDMA/Ethernet networking skills, and familiarity with GPU cluster management.
One software engineer for API development: REST/gRPC endpoint design, OIDC/SAML authentication integration, per-tenant isolation, and the Qiskit/CUDA-Q/Pulser portability layer. This role bridges the gap between the quantum hardware team (who speak in pulses and qubits) and the end users (who submit circuits through a web API).
One quantum software engineer for framework integration: translating algorithms from framework-level code (Qiskit, CUDA-Q, PennyLane) to the pulse-level instructions that the control electronics execute, and optimizing circuit compilation for the specific QPU topology.
For organizations running real-time QEC, one engineer with decoder integration experience: configuring Riverlane Deltaflow or GPU-hosted PyMatching, tuning decoder parameters, and monitoring decoder latency against the syndrome data rate.
These roles are distinct from the cryogenic engineers, laser specialists, and quantum device physicists described in the modality-specific build guides. In a production deployment, the HPC integration team and the hardware operations team work in parallel, with the control electronics as the interface between them.
Specify NVQLink compatibility in the control electronics procurement. This is non-negotiable for any system designed for 2027+ operation. All three major Western control vendors (Qblox, Quantum Machines, Zurich Instruments) support NVQLink.
Budget for a dedicated GPU node (NVIDIA GH200 or GB200 class) as part of the quantum computer procurement. This is not a “nice to have” for future QEC. It is required infrastructure for real-time error correction, and it accelerates calibration and hybrid algorithms today. Q-CTRL’s 50x classical overhead reduction via NVQLink at Q-PAC demonstrates the immediate value.
Plan QRMI deployment as part of the HPC integration, not as an afterthought. If your HPC center runs Slurm (most do), QRMI makes the QPU schedulable through existing workflows. The alternative is building a custom scheduler integration, which is more expensive and less portable.
Address the PQC migration of your quantum service’s API surface during the initial deployment, not after external users are connected. Practical Steps to Quantum Readiness covers the methodology.
For the physical infrastructure that the HPC stack connects to, see the facility preparation guide and the cryogenic infrastructure article. For the full cost picture including GPU nodes and HPC integration costs, see the cost and procurement article.
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。