Quantum Option Pricing on OCI A100s: 28 to 32 Qubit Benchmarks with Classiq and CUDA-Q

By Sanjay Basu, PhD  |  Senior Director, GPU and Generative AI Solutions, Oracle Cloud Infrastructure

For the statevector simulation workload tested here, GPU memory capacity and bandwidth were important factors in performance. We evaluated a financial option-pricing circuit ranging from 28 to 32 qubits using Classiq’s quantum software platform for circuit synthesis, NVIDIA CUDA-Q for execution, and an NVIDIA A100 80GB Tensor Core GPU in Oracle Cloud Infrastructure (OCI).

In the tested configuration, execution times scaled broadly with the growth of the statevector and remained short enough to support repeated development and testing. This article describes the benchmark, the observed results, and the limitations teams should consider when evaluating GPU resources for quantum simulation.

This benchmark is a technical demonstration. It is not intended for production valuation, trading, investment advice, or investment decision-making.

The benchmark

The workload estimates the price of a European call option using Iterative Quantum Amplitude Estimation. The circuit includes quantum state preparation, an oracle encoding the payoff condition, and Grover-style amplitude amplification.

Classiq’s software generated the circuit from a higher-level functional description and emitted OpenQASM 3.0. NVIDIA CUDA-Q compiled and executed the resulting quantum kernel using the cuStateVec backend.

We tested circuit sizes from 28 to 32 qubits. Because the state space doubles with each additional qubit, increasing the circuit from 28 to 32 qubits increases the statevector size by a factor of 16. A 28-qubit statevector contains approximately 268 million complex amplitudes, while a 32-qubit statevector contains approximately 4.3 billion.

Using single-precision complex amplitudes, the raw statevector requires approximately 2 GiB at 28 qubits and 32 GiB at 32 qubits, before accounting for simulator workspace and other overhead. These cases fit within the memory capacity of the tested NVIDIA A100 80GB GPU.

What the runs showed

Figure 1. Execution time by qubit count on one NVIDIA A100 GPU. The execution-only series uses previously synthesized circuits; the second series includes Classiq synthesis and compilation as well as execution.

At 28 qubits, execution completed in 2.2 seconds. At 32 qubits, it completed in 22.1 seconds. This represents an approximately tenfold increase in execution time for a sixteenfold increase in statevector size in the tested configuration. The difference between the two series in Figure 1 illustrates the effect of including synthesis and compilation in each run. Reusing a previously synthesized circuit reduced the end-to-end time for repeated executions.

Figure 2. Execution-time comparison between the tested NVIDIA A100 GPU configuration and the specified CPU simulation configuration running the same circuits.

In the tested configurations, GPU execution was approximately 120 times as fast as the CPU configuration at 28 qubits and 77 times as fast at 29 qubits. These figures are specific to the hardware, software, precision, and benchmark settings described in the methodology note and should not be generalized to other CPU or GPU systems. The relative speedup narrowed as the qubit count increased. Additional profiling would be required to isolate all contributing factors, but available memory bandwidth is one likely influence on the behavior of statevector workloads.

Across the tested range, execution time increased approximately linearly with relative statevector size. This result is consistent with a workload dominated by operations over the statevector. Detailed profiler data would be needed to quantify the effects of memory contention, kernel-launch overhead, and other implementation factors.

Figure 3. Execution time plotted against relative statevector size, with 28 qubits represented as 1.

Why memory characteristics matter

Statevector simulation is commonly constrained by memory capacity and data movement. Once data movement becomes the dominant bottleneck, adding compute resources alone may provide limited benefit. Relevant considerations include GPU memory capacity, memory bandwidth, and whether the statevector and simulator workspace can remain in device memory.

At 32 qubits, the tested workload remained within the memory capacity of one NVIDIA A100 80GB GPU. At 33 qubits, the raw single-precision statevector would require approximately 64 GiB, leaving less capacity for simulator workspace and other overhead. The practical limit depends on the simulator implementation and circuit characteristics.

Larger simulations may require distributed multi-GPU execution or different numerical representations. Those choices can affect performance, numerical precision, and how results should be interpreted.

The Classiq to A100 workflow

The workflow had three main layers. Classiq generated and optimized the circuit from a higher-level functional description. NVIDIA CUDA-Q compiled the OpenQASM representation into a quantum kernel and executed it on the GPU. OCI provided the compute infrastructure used for the tests.

Avoiding repeated synthesis and compilation was important for iterative testing. At 28 qubits, a run that included synthesis and compilation took 6.2 seconds, compared with 2.2 seconds for execution of a previously synthesized circuit.

This difference illustrates why end-to-end workflow design matters. For repeated development runs, reusing appropriate intermediate artifacts can help reduce latency beyond improvements obtained from kernel execution alone.

Honest uncertainty

These results do not say anything about fault-tolerant quantum hardware. A 32-qubit noiseless simulation is a development tool, not a hardware substitute. The relevance is to teams writing and validating quantum algorithms before there is large-scale physical hardware to run them on. That is a real and growing user base, but it is not the same as production quantum advantage.

The IQAE-based option pricing circuit is also a well-behaved benchmark. It has clean structure, deep but regular oracle blocks, and a known classical answer to compare against. Circuits with denser entanglement patterns will scale worse on the same hardware. Circuits with shallow but very wide layouts will scale differently again. I would not generalize from this one workload to all quantum simulation, and I would not pick a GPU shape for an unknown workload based on these numbers alone. The right question to ask before any quantum workload of this kind is what its memory access pattern actually looks like, gate by gate.

We also did not run the cross-architecture comparison I would want before recommending shape selection for a customer. The same benchmark on B200 and the Vera Rubin generation would give a better picture of where the curves diverge, especially past 32 qubits where HBM capacity becomes the binding constraint. That work is on the list, and the early indications from Hopper-to-Blackwell HBM3e bandwidth gains suggest the cliff moves by at least one qubit, possibly two, before single-precision becomes the issue.

What is next

The immediate extension is a 36-qubit QAOA portfolio optimization workload we have been running on a DGX A100 node on OCI. That run takes about five hours of wall time because it is a hybrid QAOA loop with 15 outer iterations of COBYLA and 16,384 shots per sampling call. It uses the NVIDIA cuQuantum Appliance distributed across eight A100s. Different circuit family, different cost structure, and a different answer to the question of which shape fits best. I will write that one up separately once the results are stable.

The longer thread I want to pull on is how these scaling curves move on B300 and the Vera Rubin NVL platforms. The HBM-per-GPU and NVLink fabric changes between Hopper, Blackwell, and Rubin are exactly the kinds of changes that shift where the cliff sits for statevector simulation. We have access to some of that hardware and I expect the curves to shift meaningfully for the 33 to 40 qubit range that is currently the hardest to do well on cloud GPUs.

For teams building quantum applications today, the practical takeaway is this. Noiseless simulation of a 28 to 32 qubit IQAE-class circuit on a single A100 is fast enough to use as a development loop, not just as a one-time validation. Two seconds at 28 qubits means you can iterate on circuit design choices in real time. Twenty-two seconds at 32 qubits means you can iterate at the upper end of what fits on one GPU. That is the regime where Classiq’s synthesis stops being a write-once tool and starts being a real development surface, and where OCI cloud GPUs stop being a batch resource and start being an interactive one.