How does backend.run differ from Qiskit Runtime primitives?

The existing Qiskit backend interface (backend.run()) was originally designed to accept a list of circuits and return shot counts for every job. As our users’ needs changed, we realized that we would need a new, more flexible tool to address those needs, and Qiskit Runtime was born.

Using Qiskit alone

Qiskit was originally designed to drive circuit execution directly. Qiskit users submit circuits and receive results from the jobs that are run on a quantum system. Often, these jobs are part of a larger algorithm that includes an iterative (variational) approach to optimize circuit parameters. In this sequence, queuing up each job results in longer processing times.

Using Qiskit Runtime

Qiskit Runtime offers advantages in workload performance. Variational algorithms can run on classical compute resources that are colocated with the QPUs through the Estimator primitive. This allows users to run iterative algorithm circuits back to back. In addition, sessions can drive a sequence of jobs without having to re-queue each job, avoiding latencies of queue wait times after the session is actively running. As a result, Qiskit Runtime is much more efficient than its predecessors.

Function	backend.run	Qiskit Runtime Primitives
Primitive interface as abstraction for circuits and variational workload	No	Yes
Sessions to improve performance for a sequence of jobs	No	Yes
Abstracted interface that allows for automated error suppression and mitigation	No	Yes
Increased performance for variational algorithms	No	Yes
Working examples of code developed by Qiskit community	Yes	Yes
OpenPulse	Yes	No
Pulse Gates	Yes	Yes
Dynamic circuits	Yes	No