ZKSF logo, a neon quantum brainZKSF
← All articles

Quantum Emulator vs Simulator

Last updated · 11 min read · ZKSF team

The short version

  • A simulator answers what the circuit means. An emulator answers what a particular machine would return, and the distinction decides what the number is worth
  • Four different engines all get called the simulator. Exact statevector, stabilizer, tensor network and density matrix, working in completely different ways
  • Approximate results carry a measured bound. A 40-qubit tensor-network job reports a discarded weight of 1.887e-14 and an error bound of 1.943e-07
  • Real hardware is the third thing. A 3-qubit GHZ at 50 shots returned 45 in the two ideal outcomes on a Rigetti Cepheus processor

Everything here is runnable on your own circuit. Try it in the console

Most vendors use the words emulator and simulator interchangeably, which is why the question keeps getting asked. Underneath the loose usage there is a real distinction, and it decides which one you should be running.

The short answer

A simulator computes what the mathematics says should happen. An emulator reproduces what a particular machine would actually do, noise included.

That is the whole difference. One answers the question "what does this algorithm output", the other answers "what would this device return if I sent it this circuit". Those are different questions, they have different answers on purpose, and confusing them is the most expensive mistake available in this field.

If you are debugging an algorithm, you want the ideal answer, because you need to know whether the algorithm is correct before you find out whether the hardware can run it. If you are estimating whether a real device will give you anything usable, the ideal answer is no help at all and you want the noise.

What a simulator actually computes

An exact simulator stores one complex amplitude per basis state. An n-qubit circuit therefore costs 16 x 2^n bytes, and that exponent is the whole story: ten qubits is 16 KiB, thirty is 16 GiB, forty is 16 TiB, fifty is 16 PiB. Each qubit doubles the bill, so the distance between comfortable and impossible is about four qubits.

Nothing is approximated below that ceiling. The result is exact to floating-point precision, and the only scatter you see is shot noise from sampling the distribution, which is real sampling noise rather than an artefact of the method.

Four different things all called "the simulator"

The word covers at least four engines that work in completely different ways, and the differences matter more than the label. Every row below was produced on one consumer laptop, an Intel i7-12700H with 32 GB of RAM, with the GPU switched off:

Circuit                  Qubits   Engine        Wall time   Accuracy
GHZ (Clifford)            5,000   clifford      0.56 s      exact
QAOA MaxCut, p=3            100   mps.quimb.cpu 5.9 s       converged (dev 0.0)
Layered ansatz               80   mps.quimb.cpu 4.3 s       converged (dev 0.0)
Exact statevector            26   exact.cpu     2.7 s       exact

Five thousand qubits in half a second looks like a mistake until you notice the circuit is Clifford, which the Gottesman-Knill theorem says is classically tractable at any width. That is not a breakthrough, it is a category. The stabilizer engine is exact there and refuses anything outside the category rather than guessing.

The tensor-network rows are the interesting ones, because those results are approximate. A 100-qubit QAOA instance does not fit in any exact representation, so the engine truncates, and the honest question becomes how far the answer sits from the truth.

A stabilizer run says something different, because there is nothing to bound. A 1001-qubit error-correcting code circuit returns an exact result and says so on the certificate at api.zksf.org/certify/86125198363b4d02. No approximation, only shot noise.

Where the word emulator earns its place

None of the above models a device. They compute the mathematics, cleanly, as though the hardware were perfect. Emulation is what you get when you add the machine back in.

An emulator applies a noise model: depolarizing channels, readout error, gate infidelity, sometimes crosstalk and drift. The circuit is the same, the arithmetic is the same, and then the errors a particular processor is known to make are injected on top. The output looks like hardware output rather than like textbook output.

That is genuinely useful for asking whether an algorithm survives contact with a real device, and how much its output degrades at a given error rate. It is what a noise-modelling engine is for, and it costs a fraction of a hardware run.

It also has a limitation that is worth stating plainly, because it is the reason emulation does not replace hardware. A depolarizing model is an approximation of a device's actual error process.

Real machines exhibit crosstalk, leakage, drift and correlated errors that no simple channel captures. An emulator tells you how your circuit behaves under the noise you modelled, which is not the same as how it behaves under the noise the device has.

The ZKSF engine picker, where the distinction in this article is a line in a dropdown: exact.cpu beside noisy.cpu, the device-noise preview
The ZKSF engine picker, where the distinction in this article is a line in a dropdown: exact.cpu beside noisy.cpu, the device-noise preview. Try it yourself in the console

And then there is the machine itself

Real hardware is neither a simulator nor an emulator. It is a physical apparatus whose measured behaviour is the result, and at every size a classical machine can reach, the classical machine gives the better answer, because it gives the noise-free one.

Two runs make the point concrete. On a Rigetti Cepheus superconducting processor, a 3-qubit GHZ at 50 shots returned 45 shots in the two ideal GHZ states and 5 in bit-flipped states, after roughly 53 minutes in the scheduled queue.

On an IonQ Forte-1 trapped-ion processor, a 2-qubit Bell state at 100 shots returned 98 shots in the ideal outcomes and 2 in error, after about 5 hours queued. That second run carries a measured hardware fidelity of 0.9774 against the exact ideal distribution, at api.zksf.org/certify/df1d4c698a954051.

Neither run was faster or cheaper than the simulator, and neither was meant to be. What they provide is the measured behaviour of two qubit technologies, reported as raw counts with no error mitigation, post-selection or readout correction applied.

The clearest version of the distinction is one problem put through all three. Below is the H2 molecule at equilibrium on the exact simulators, on the neural engines, and on real quantum processors, with what each run cost.

Run on our engines

The H2 molecule at its equilibrium bond length, whose exact electronic ground state is -1.857275 Ha. Two qubits, so it fits every device we offer. Submitted to each kind of compute we offer, on 16 September 2026. Every figure below is a real job on the service, priced as any customer would be priced.

DeviceEngineKindQubitsResultCost
CPUexact.cpuCPU2ZZ = -1.0000, the ideal value certificate$0.0001
NVIDIAexact.gpuGPU2ZZ = -1.0000, the ideal value certificate$0.0001
IQMqpu.iqm.garnetQPU2ZZ = -0.9326, superconducting, 4,096 shots certificate$6.239
Rigettiqpu.rigettiQPU2ZZ = -0.5420, superconducting, 4,096 shots * certificate$2.041
Rigettiqpu.rigettiQPU2ZZ = -0.5107, the same circuit re-run * certificate$2.041
AQTqpu.aqt.ibexQPU2ZZ = -0.9200, trapped ion, 100 shots certificate$2.650
CPUneural.cpuCPU2-1.116981 Ha total, 0.0203 Ha above exact certificate$0.0001
Google Cloud TPUneural.tpuTPU2-1.116981 Ha total, 0.0203 Ha above exact certificate$0.074

* The two Rigetti rows are one circuit run twice, an internal reproduction of the published benchmark notebook. A depolarizing noise model puts both versions at about -0.99, so the shortfall is not the circuit shape, but the identical program has not yet run on both devices. The steps are in the docs.

A note on the hardware certificates: they state Hellinger fidelity against the exact distribution. For an optimisation circuit that distribution is spread across many outcomes rather than concentrated on one, so the figure is low by construction and is not a measure of whether the device found a good answer. The result column above is.

The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.

Read the first two rows against the rest. The exact engines return -1.0000 because they are computing the answer rather than measuring it, for a hundredth of a cent and with no queue. The hardware rows are the apparatus answering, and they fall short by an amount that is physical error plus shot noise. That is the whole distinction this article draws, priced, and the full benchmark is on chemicals and pharma.

That table is gate-based, where the word simulator is the usual one. The sharper case is analog, where the classical engine is genuinely an emulator. It integrates the same Hamiltonian the atoms obey, rather than modelling a circuit. Below, the identical nine-atom register on the emulator and on the neutral-atom device itself.

Run on our engines

Nine atoms on a 3x3 grid at 6 um spacing, whose blockade graph is the king's graph: 9 vertices, 20 edges, and a maximum independent set of 4 that can be checked by hand. On 25 September the identical sequence ran on analog.pulser.gpu, an NVIDIA GPU, returning the same set with all 500 shots valid. Submitted to each kind of compute we offer, on 18 and 25 September 2026. Every figure below is a real job on the service, priced as any customer would be priced.

DeviceEngineKindQubitsResultCost
CPUanalog.pulser.cpuCPU9found [0, 2, 6, 8], size 4; 500 of 500 shots valid$0.0001
NVIDIAanalog.pulser.gpuGPU9found [0, 2, 6, 8], size 4; 500 of 500 shots valid certificate$0.0017
QuEraqpu.quera.aquilaQPU9found [0, 2, 6, 8], size 4; 883 of 947 shots valid, 574 optimalbest outcome$10.3000
Pasqalqpu.pasqal.fresnelQPU—takes the identical Pulser sequence, but is billed as machine time at one shot per four seconds, so a run at this shot count is not comparable in cost—

The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.

Both found the same four atoms, so the emulator predicted the machine's answer correctly. What it could not reproduce is the failure rate. Every shot obeyed the constraint on the emulator and 883 of 947 did on hardware. That is the general shape of it. An emulator tells you what the device should do, and only the device tells you how often it does. More on the method in neutral atom quantum computing.

Which one do you want

Three questions settle it.

Is the question about the algorithm or about the device? About the algorithm means a simulator, and the ideal answer is the one you want. About the device means either an emulator, if you are exploring how noise affects the outcome, or the device itself, if the specific physical error process is the object of study.

Does the result need to be defensible? Exact and stabilizer results carry no approximation error by construction. Tensor-network and Pauli-propagation results are approximate and should arrive with a computed bound, or they are an assertion rather than a measurement.

Is the circuit within reach of an exact method? Under about 32 qubits, or Clifford at any width, or structured with bounded entanglement. If yes, approximation is unnecessary and the accuracy question does not arise.

The distinction that actually costs money

The reason this is not a vocabulary argument is that an approximate simulator does not fail loudly. Run one with insufficient bond dimension and it returns a normalised, plausible distribution and no warning. You get a confident wrong answer, and there is usually no way to tell it from a confident right one.

That is why every approximate result here carries a measured accuracy statement rather than a reassurance, and why exact and stabilizer results say so explicitly instead of leaving it implied. An emulator that models noise, a simulator that truncates, and a processor that is genuinely noisy all produce output that looks similar and means three different things.

Try it without any of this mattering

The fastest way to understand the distinction is to run something. There is a browser-based circuit simulator on this site that needs no account and no install. It runs exactly, in your tab, up to the point where exactness stops being possible, and then it tells you so.

Past that ceiling the same circuit runs on the hosted engines, on tensor-network and stabilizer methods past 1,000 qubits, and on real quantum processors from four vendors, through one API and without being rewritten.

Every approximate result comes back with a bound you can cite, and every job can be exported as a certificate anyone can check. The same engines are available from the Android app if you want to run one from a phone.

If you would rather see what the difference looks like on a real industrial problem, the applications benchmarks run each one on our engines and on the best classical solver available, and publish both, including the runs where classical computing wins.

Common questions

What is a quantum emulator?

In common usage a quantum emulator is software that reproduces the behaviour of a specific quantum device, noise included, while a simulator computes the ideal mathematics of the circuit. The distinction matters commercially. An emulator answers what this machine would return, and a simulator answers what the circuit means. Most cloud offerings labelled emulators are doing the second thing.

Is there a quantum emulator service you can use online?

Yes. Emulation and simulation are both available as a paid cloud service, priced per circuit rather than per hour, starting at $0.0001. The practical difference from renting hardware is that a simulator returns the exact distribution with a computed error bound, where hardware returns measured counts with device noise and no bound unless one is derived for you.

Run your own 100-qubit circuit, with an error bar.

Share this articleLink copied