HPC-vQPU: Exporting Quantum Simulators from HPC Clusters as Virtual QPU Services

Forum topic · 小凯 · 2026-05-29

Summary

A forum post discusses the paper HPC-vQPU (arXiv:2605.28845), which addresses the 'connectivity inversion' problem: quantum simulators need GPU nodes inside security-sealed HPC systems, but quantum developers want interactive QPU-style APIs rather than batch job scripts. The proposed architecture separates a cloud-visible control plane (REST API, SSE event streams) from an execution plane inside HPC, connected only by outbound CLAIM/HEARTBEAT/REPORT protocol verbs from a non-privileged agent on the login node. A central abstraction is the immutable device snapshot — coupling graph, native gate set, T1/T2, and per-qubit/edge error rates — bound at CLAIM time. The system was validated in production on Pawsey's Setonix with AMD MI250X GPUs, Qiskit-Aer and cuQuantum, using IBM Fez calibration data (156-qubit virtual device). Experiments show service-layer overhead of about 3.7% at 32 qubits, noise-aware fidelity differences (TV = 0.03537), correct CLAIM-time binding, and conservative crash recovery. Limitations include exponential simulation cost, conservative fault recovery, and only Slurm/Dask integration.

This post reviews the paper HPC-vQPU: A Service-Export Architecture for Virtual QPUs on Batch-Scheduled HPC Systems (arXiv: 2605.28845, 29 pages, 5 figures), by Pawsey Supercomputing researchers, validated on the Setonix system with AMD MI250X GPUs and IBM Fez calibration data.

The problem: connectivity inversion

HPC centers have GPUs; quantum simulators need GPUs. But HPC interfaces are scheduler-oriented: users submit job scripts, queue, run, and exit. Quantum software instead wants a QPU — a device that can be queried via developer-friendly APIs like IBM Quantum or AWS Braket. Cloud quantum platforms are interactive but limited in scale; science gateways merely wrap job submission and ignore device calibration, topology semantics, and gate-set constraints.

A deeper obstacle is security: HPC compute nodes are internally addressed, scheduler-assigned, and ephemeral, with no inbound ports allowed. The paper names this the connectivity inversion problem — instead of pushing quantum jobs into HPC, export the internal quantum simulator outward.

Two-plane architecture

HPC-vQPU uses a deliberately asymmetric design: two planes, one boundary, all connections outbound.

Control plane (vqpu_server): cloud-visible, speaking in devices, tasks, lifecycle states, and results. REST API for task intake, SSE event streams for status. The authoritative source of truth.
Execution plane (vqpu_agent): an unprivileged process on the HPC login node. It polls the control plane, CLAIMs tasks, translates them into scheduler jobs (Slurm/Dask), parses result artifacts, and reports final states.

Between the planes there are only three verbs: CLAIM, HEARTBEAT, REPORT. No callbacks, no RPC. If an agent dies, heartbeat expiry triggers recovery — the server never calls in.

Core abstraction: device snapshots as immutable contracts

A snapshot Δ(𝒟, t) contains the directed coupling graph G = (Q, E), the native gate set, per-qubit T1/T2 coherence times, single-qubit gate errors, readout errors, per-edge two-qubit errors and gate types, and directional coupling (ε_ij ≠ ε_ji allowed).

The paper builds a 156-qubit virtual device ibm-fez-0309 from real IBM Fez calibration data, plus an ideal counterpart ibm-fez-ideal. Snapshots are bound at CLAIM time — not at submission (too early, device may drift during queueing) and not at node runtime (too late, would break sealing). An experiment confirmed this: 8 tasks submitted, then all noise parameters zeroed via the admin API 1.2 seconds later. All 8 tasks returned TV = 0, p(|00⟩) = 1.0 — proving CLAIM-time binding.

Nine design invariants (D1–D9)

D1 Outbound-only: all connections initiated by the agent.
D2 Terminal-state absorption: COMPLETED/FAILED/CANCELLED cannot transition.
D3 Exclusive CLAIM: atomic ownership; only one of competing agents wins.
D4 Asymmetric coordination: failure detection via heartbeat expiry; no auto-requeue.
D5 Snapshot immutability: bound at CLAIM, sealed at execution.
D6 Topology parameterization: acceptance checks via graph parameterization, not string matching.
D7 TTL caching of snapshots, invalidated on device mutation.
D8 Sealed execution: compute nodes have no network or control-plane access; input (c_i, δ_i), output ρ_i.
D9 Server-side observability via SSE for external dashboards.

Experiments on Pawsey Setonix

Production environment: Setonix, AMD Instinct MI250X, Qiskit-Aer + cuQuantum, IBM Fez calibration data from 2026-03-09.

Experiment A (bounded overhead): random native circuits, 28–32 qubits, 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) accounts for only 3.7% of end-to-end latency and stays constant-time as qubit count grows.
Experiment B (device-aware fidelity): amplified two-qubit identity circuits. The ideal device always yields |00⟩; the calibrated device gives TV = 0.03537 ± 0.00171, with probability mass concentrated on |10⟩, consistent with readout errors and the calibrated two-qubit channel on edge (0,1).
Experiment C (CLAIM-time binding): the noise-zeroing test — 8/8 clean outputs.
Experiment D (crash recovery): agent killed after CLAIM. The control plane keeps tasks in RUNNING without auto-failing or auto-requeuing; after explicit admin requeue and agent restart, 3/3 tasks complete. Auto-requeue would risk competing execution lineages; the system keeps ambiguity explicit.

Noise model derivation

The derivation from snapshot to simulator noise model uses three channels: single-qubit depolarization (excluding virtual Rz/identity/delay gates), symmetric readout matrix [[1−r, r], [r, 1−r]], and directional two-qubit depolarization. Critically, the control-plane simulator and the compute-node runner use identical derivation logic, preventing semantic divergence between validation and execution paths.

Relation to prior work

Cloud quantum platforms (IBM Quantum, AWS Braket): interactive but scale-limited; HPC-vQPU offers the same abstraction over HPC-scale simulators.
Qiskit Runtime: assumes a remotely reachable quantum backend; HPC-vQPU handles sealed HPC boundaries.
Quantum simulators (Qiskit-Aer, cuQuantum): performance without a device-oriented service abstraction.
Science gateways (JupyterHub, Open OnDemand): no calibration-as-contract concept.
vQPU time-sharing (Quantum Brilliance, Lagrange): virtualizes a physical QPU to many jobs — the opposite direction. The two are complementary.

Limitations

Exponential state-vector simulation cost is not hidden — only kept out of the service layer. Beyond ~32 qubits, simulation time itself dominates.
Fault recovery is deliberately conservative; automatic post-expiry recovery is future work.
Only Dask-backed Slurm integration so far; PBS, LSF, and Kubernetes need adapters.
Only quantum simulators validated; physical QPU integration remains open (though the architectural principles should hold).

Author's take

The paper's value is not a novel algorithm but a re-drawing of boundaries in the quantum–HPC fusion problem: HPC keeps doing what it is good at (scheduling, isolation, GPU compute), while exposing a device interface instead of job scripts. The architectural principles (dual-plane, outbound-only, snapshot contracts, sealed execution) generalize to any HPC resource needing interactive external service — deep learning inference, scientific visualization, data queries. The experiments are modest in scale, but they prove feasibility: on Pawsey's production system, an external user submitted circuits via REST, observed progress via SSE, and received calibration-aware simulation results — 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.