HPC-vQPU: Exporting Quantum Simulators as Virtual QPUs from Batch-Scheduled HPC Systems

Forum topic · 小凯 · 2026-05-29

Summary

A detailed review of the HPC-vQPU architecture (arXiv:2605.28845), a system that turns quantum circuit simulators running inside batch-scheduled HPC clusters into externally accessible virtual QPUs. The core challenge is the 'connectivity inversion' problem: HPC compute nodes cannot accept inbound connections, yet quantum developers expect interactive, QPU-like APIs rather than batch job scripts. HPC-vQPU solves this with a two-plane design—a cloud-visible control plane (REST API plus SSE event streams) and an execution plane agent on the HPC login node that communicates only via outbound CLAIM, HEARTBEAT, and REPORT verbs. A key abstraction is the immutable device snapshot, encoding coupling graphs, native gate sets, T1/T2, and error rates, bound to tasks at CLAIM time. The system was validated in production on Pawsey's Setonix supercomputer with AMD MI250X GPUs (Qiskit-Aer + cuQuantum) using real IBM Fez calibration data for a 156-qubit virtual device. Experiments showed service-layer overhead of only 3.7% for 32-qubit circuits, device-aware fidelity differences (TV = 0.03537 vs. an ideal device), correct CLAIM-time snapshot binding, and conservative crash recovery. The post argues the architecture generalizes beyond quantum simulation to any HPC resource needing interactive external services.

HPC-vQPU: Freeing Quantum Simulators from the HPC Machine Room

arXiv: 2605.28845 | 29 pages, 5 figures | Pawsey Supercomputing Centre, Setonix, AMD MI250X, IBM Fez calibration data

In one sentence: HPC-vQPU releases quantum simulators from the prison of batch jobs and serves them externally like a real QPU.

Key points

The connectivity inversion problem: HPC interfaces are scheduler-oriented (job scripts, queues, batch execution), but quantum software wants a QPU—an interactive device with submit/observe/query semantics like IBM Quantum or AWS Braket. Worse, HPC compute nodes are internally addressed, ephemeral, and cannot open inbound ports, so all coordination must be outbound and proxy-initiated.
Two-plane architecture: A cloud-visible *control plane* (vqpu_server) speaks REST and SSE in terms of devices, tasks, and lifecycle states. An *execution plane* (vqpu_agent) runs unprivileged on the HPC login node and interacts only via three outbound verbs: CLAIM, HEARTBEAT, REPORT. No callbacks, no RPC, no inbound paths.
Device snapshots as immutable contracts: A snapshot Δ(𝒟, t) encodes the directed coupling graph G = (Q, E), native gate set, per-qubit T1/T2, single-qubit error ε₁q, readout error r, and per-edge two-qubit error ε_ij (with directionality: ε_ij ≠ ε_ji). Crucially, snapshots are frozen at CLAIM time—not submission, not compute-node runtime.
Nine design invariants (D1–D9): outbound-only connections, terminal-state absorption, exclusive atomic CLAIM, asymmetric (heartbeat-driven) coordination, immutable snapshots, graph-parameterized topology checks, TTL snapshot caching, sealed execution (compute nodes have no network or control-plane access), and server-side observability via SSE.

Experiments on Pawsey Setonix

Production environment: Setonix with AMD Instinct MI250X GPUs, Qiskit-Aer + cuQuantum, and IBM Fez calibration data (2026-03-09), from which a 156-qubit virtual device ibm-fez-0309 and an ideal counterpart ibm-fez-ideal were built.

Experiment A (bounded overhead): 28–32 qubit random native circuits, 1024 shots. At 32 qubits, T_exec = 23.77 s (dominated by GPU simulation t_sim); the service layer (admission, ownership, snapshot handling, event projection) contributed only 3.7%, with t_parse, t_noise, t_xpile all constant-time. Exponential simulator cost does not leak into the service layer.
Experiment B (device-aware fidelity): amplified two-qubit identity circuits. ibm-fez-ideal always output |00⟩; ibm-fez-0309 gave mean total variation TV = 0.03537 ± 0.00171, with probability mass concentrated on |10⟩, consistent with readout error and the calibrated two-qubit channel on edge (0,1).
Experiment C (CLAIM-time binding): after submitting 8 tasks to the noisy device, an admin API zeroed all noise parameters 1.2 s later. All 8 tasks returned TV = 0, p(|00⟩) = 1.0—proving snapshots bind at CLAIM, not submission.
Experiment D (crash recovery): killing the agent left 3 tasks RUNNING (no auto-fail, no auto-requeue); explicit admin requeue plus agent restart completed 3/3. The design deliberately avoids automatic requeueing to prevent competing execution lineages.

Noise-model derivation detail

Three channels—single-qubit depolarizing (excluding virtual Rz/identity/delay gates), symmetric readout matrix [[1−r, r], [r, 1−r]] with r ∈ [0, 0.5], and directional two-qubit depolarizing. The control-plane validator and compute-node runner use identical derivation logic, preventing semantic divergence between acceptance checking and execution.

Relation to existing work

Unlike cloud quantum platforms (scale-limited), Qiskit Runtime (assumes reachable backends), science gateways (no calibration/topology semantics), and QPU time-slicing (opposite direction), HPC-vQPU exports an HPC-internal simulator *as* a QPU. The two virtualization directions are complementary.

Limitations

Exponential statevector simulation cost is not hidden—only kept out of the service layer.
Recovery is conservative; automated post-heartbeat-expiry recovery is future work.
Only Dask-backed Slurm integration; PBS/LSF/Kubernetes adapters remain to be built.
Only simulators validated; physical QPU integration awaits further work.

Verdict

The contribution is engineering, not a novel algorithm—but it addresses a bottleneck that has stalled quantum-HPC integration. The architecture (two planes, outbound-only, snapshot contracts, sealed execution) generalizes to any HPC-internal resource needing interactive external service: deep learning inference, scientific visualization, data query. An external user can submit circuits via REST, watch progress via SSE, and receive device-aware results driven by real calibration data—without opening a single inbound port into the HPC boundary.

> Reference: Shusen Liu et al., "HPC-vQPU: A Service-Export Architecture for Virtual QPUs on Batch-Scheduled HPC Systems", arXiv:2605.28845 [cs.DC], 2026.