93 lines
7.3 KiB
Plaintext
93 lines
7.3 KiB
Plaintext
---
|
|
title: Introduction to execution modes
|
|
description: An overview of the available execution modes in Qiskit Runtime; sessions, batch, and single jobs.
|
|
|
|
---
|
|
# Introduction to Qiskit Runtime execution modes
|
|
|
|
<LegacyContent>
|
|
<Admonition type="note">
|
|
This documentation is relevant to IBM Quantum® Platform Classic. If you need the newer version, go to the new [IBM Quantum Platform documentation.](https://quantum.cloud.ibm.com/docs/guides/execution-modes)
|
|
</Admonition>
|
|
</LegacyContent>
|
|
<CloudContent>
|
|
<Admonition type="note">
|
|
This documentation is relevant to the new IBM Quantum® Platform. If you need the previous version, return to the [IBM Quantum Platform Classic documentation.](https://docs.quantum.ibm.com/guides/execution-modes)
|
|
</Admonition>
|
|
</CloudContent>
|
|
|
|
When Qiskit Runtime was introduced, users could only execute circuits as individual jobs. As different types of quantum workloads emerged, the need for different scheduling strategies became evident. The execution modes determine how your jobs are scheduled, and choosing the right execution mode allows your workload to run efficiently within your budget. There are three execution modes: job, session, and batch.
|
|
|
|
## Job mode
|
|
|
|
A single primitive request of the estimator or the sampler made without a context manager. Circuits and inputs are packaged as primitive unified blocs (PUBs) and submitted as an execution task on the quantum computer. To run in job mode, specify `mode=backend` when instantiating a primitive. See [Primitives examples](/docs/guides/primitives-examples) for usage.
|
|
|
|
<span id="batch-mode"></span>
|
|
## Batch mode
|
|
|
|
A multi-job manager for efficiently running experiments comprising multi-job workloads. These workloads are made up of independently executable jobs that have no conditional relationship with each other. With batch mode, users submit their jobs all at once. The system parallelizes or threads the pre-processing step of each primitive job to more tightly package quantum execution across jobs, and then runs the quantum execution of each job in quick succession to deliver the most efficient results.
|
|
|
|
|
|
|
|
|
|
<Admonition type="note" title="Notes">
|
|
- When batching, jobs are not guaranteed to run in the order they are submitted. Also, while your batch jobs will run as closely together as possible, they don't get exclusive access to the backend. Therefore, your batch jobs might run in parallel with other users' jobs if there is enough processing capacity on the QPU. Additionally, QPU calibration jobs could run between the batched jobs.
|
|
- The queuing time does not decrease for the first job submitted within a batch. Therefore, batches do not provide any benefits when running a single job.
|
|
- Batches do not work on simulators because simulators do not have a queue.
|
|
</Admonition>
|
|
|
|
To run in batch mode, specify `mode=batch` when instantiating a primitive or run the job in a batch context manager. See [Run jobs in a batch](/docs/guides/run-jobs-batch) for examples.
|
|
|
|
<span id="session-mode"></span>
|
|
## Session mode
|
|
|
|
A dedicated window for running a multi-job workload. During this window, the user has exclusive access of the system and no other jobs can run - including calibration jobs. This allows users to experiment with variational algorithms in a more predictable way and even run multiple experiments simultaneously, taking advantage of parallelism in the stack. Using sessions helps avoid delays caused by queuing each job separately, which can be particularly useful for iterative tasks that require frequent communication between classical and quantum resources.
|
|
|
|
|
|
|
|
|
|
To run in session mode, specify `mode=session` when instantiating a primitive, or run the job in a session context manager. See [Run jobs in a session](/docs/guides/run-jobs-session) for examples.
|
|
|
|
<Admonition type="note" title="Notes">
|
|
- The queuing time does not decrease for the first job submitted within a session. Therefore, sessions do not provide any benefits when running a single job.
|
|
- Sessions do not work on simulators because simulators do not have a queue.
|
|
<LegacyContent>
|
|
- Session execution mode is not supported in the Open Plan. Jobs will run in job mode instead.
|
|
</LegacyContent>
|
|
<CloudContent>
|
|
- Open Plan users cannot submit session jobs.
|
|
</CloudContent>
|
|
</Admonition>
|
|
|
|
## Basic workflow
|
|
|
|
The basic workflow for batches and sessions is similar:
|
|
|
|
1. The first job in a batch or session enters the normal queue. For batches, the entire batch of jobs is scheduled together.
|
|
2. When the first job starts running, the maximum time to live (TTL) timer starts, and does not stop or pause until the end is reached.
|
|
3. The interactive TTL timer starts after each job is completed. If there are no workload jobs ready within the interactive TTL window, the workload is temporarily deactivated and normal job selection resumes. A job can reactivate the deactivated workload if the batch or session has not reached its maximum TTL value.
|
|
<Admonition type="note">
|
|
The job must go through the normal queue to reactivate the workload.
|
|
</Admonition>
|
|
<LegacyContent>
|
|
4. If the maximum TTL value is reached, the workload ends and any remaining queued jobs fail. In IBM Quantum® Platform, any jobs already running will run to completion. However, if you are using Qiskit Runtime on IBM Cloud®, jobs won't run to completion if doing so would exceed the instance's cost limit.
|
|
</LegacyContent>
|
|
<CloudContent>
|
|
4. If the maximum TTL value is reached, the workload ends and any remaining queued jobs fail. Any job currently running won't run to completion if doing so would exceed the instance's cost limit.
|
|
</CloudContent>
|
|
|
|
The following video illustrates the basic workflow, using sessions as an example:
|
|
|
|
<video title="A user starts a session job and becomes the priority user. They submit jobs to the QPU while other users wait. After the prioritized user's session finishes, the next person's jobs can begin processing." className="max-w-auto h-auto" controls>
|
|
<source src="/docs/videos/guides/sessions/demo.mp4" type="video/mp4"></source>
|
|
</video>
|
|
|
|
For full details about the TTL timers, see the [Maximum execution time](/docs/guides/max-execution-time) guide.
|
|
|
|
## Next steps
|
|
|
|
<Admonition type="tip" title="Recommendations">
|
|
- [Run a job in batch mode.](/docs/guides/run-jobs-batch/)
|
|
- [Run a job in session mode.](/docs/guides/run-jobs-session)
|
|
- [Choose the right execution mode.](/docs/guides/choose-execution-mode)
|
|
</Admonition> |