Session とは、ユーザーとQiskit Runtimeサービスとの間のコントラクトであり、ジョブの集まりをグループ化し、量子コンピューターのジョブスケジューラーによって共同で優先順位をつけることができるようにするものです。これにより、session 時間中に同じ量子デバイス上で実行される他のユーザーのジョブによって引き起こされる人為的な遅延を排除することができます。
簡単に言うと、session がアクティブになると、session 内で投入されたジョブは、他のユーザーのジョブに邪魔されなくなります。
fair-share scheduler を使用するジョブに比べ、session は、古典リソースと量子リソースの間の反復的な呼び出しを必要とし、多数のジョブが連続して投入されるプログラムの実行時に特に有益です。例えば、VQEやQAOAのような変分アルゴリズムの学習や、デバイスの特性評価実験がこれにあたります。
Runtime session は、Qiskit Runtime primitive と組み合わせて使用することができます。Primitiveは、量子コンピューター上でどのような処理を行い、その結果をどのようなデータとして返すかによって使い分けられます。プログラムに適したprimitiveを特定した後、Qiskitを使用して、回路、観測値（Estimator用）、ジョブを最適化するためのカスタマイズ可能なオプションなどの入力を準備することができます。詳細については、 Primitives のトピックを参照してください。
Jobs that belong to a single algorithm run are run together without interruption, increasing efficiency if your program submits multiple sequential jobs.
The queuing time does not decrease for the first job submitted within a session. Therefore, a session does not provide any benefits if you only need to run a single job.
Since data from the first session job is cached and used by subsequent jobs, if the first job is cancelled, subsequent session jobs will all fail.
When using sessions, the uncertainty around queuing time is significantly reduced. This allows better estimation of a workload’s total runtime and better resource management.
In a device characterization context, being able to run experiments closely together helps prevent device drifts and provide more accurate results.
While the session is active, you can submit different jobs, inspect job results, and re-submit new jobs without opening a new session.
You maintain the flexibility to deploy your programs either remotely (cloud / on-premises) or locally (your laptop).
The mechanics of sessions (queuing)¶
For each backend, the first job in the session waits its turn in the queue normally, but while the session is active, subsequent jobs within the same session take priority over any other queued jobs. If no jobs that are part of the active session are ready, the session is deactivated (paused), and the next job from the regular fair-share queue is run. See Interactive timeout value for more information.
A quantum processor still executes one job at a time. Therefore, jobs that belong to a session still need to wait for their turn if one is already running.
Internal systems jobs such as calibration have priority over session jobs.
Iterations and batching¶
Sessions can be used for iterative or batch execution.
Any session job submitted within the five-minute interactive timeout, also known as Time to live (TTL), is processed immediately. This allows some time for variational algorithms, such as VQE, to perform classical post-processing.
The quantum device is locked to the session user unless the TTL is reached.
Post-processing could be done anywhere, such as a personal computer, cloud service, or an HPC environment.
Ideal for running experiments closely together to avoid device drifts, that is, to maintain device characterization.
Suitable for batching many jobs together.
Jobs that fit within the maximum session time run back-to-back on hardware.
When batching, jobs are not guaranteed to run in the order they are submitted.
How long a session stays active¶
The length of time a session is active is controlled by the maximum session timeout (
max_time) value and the interactive timeout value (TTL). The
max_time timer starts when the session becomes active. That is, when the first job runs, not when it is queued. It does not stop if a session becomes inactive. The TTL timer starts each time a session job finishes.
Maximum session timeout¶
When a session is started, it is assigned a maximum session timeout value. You can set this value by using the
max_time parameter, which can be greater than the program’s
max_execution_time. For instructions, see Run a primitive in a session.
If you do not specify a timeout value, it is the smaller of these values:
The system limit
max_execution_timedefined by the program
See What is the maximum execution time for a Qiskit Runtime job? to determine the system limit and the
max_execution_time for primitive programs.
Interactive timeout value¶
Every session has an interactive timeout value, or time to live (TTL), of five minutes, which cannot be changed. If there are no session jobs queued within the TTL window, the session is temporarily deactivated and normal job selection resumes. A deactivated session can be resumed if it has not reached its maximum timeout value. The session is resumed when a subsequent session job starts. Once a session is deactivated, its next job waits in the queue like other jobs.
After a session is deactivated, the next job in the queue is selected to run. This newly selected job (which can belong to a different user) can run as a singleton, but it can also start a different session. In other words, a deactivated session does not block the creation of other sessions. Jobs from this new session would then take priority until it is deactivated or closed, at which point normal job selection resumes.
What happens when a session ends¶
A session ends by reaching its maximum timeout value or when it is manually closed by the user. Do not close a session until all jobs complete. See Close a session for details. After a session is closed, the following occurs:
Any queued jobs remaining in the session (whether they are queued or not) are put into a failed state.
No further jobs can be submitted to the session.
The session cannot be reopened.
Sessions and reservations¶
IBM Quantum Premium users can access both reservations and sessions on specific backends. Such users should plan ahead and decide whether to use a session or a reservation. You can use a session within a reservation. However, if you use a session within a reservation and some session jobs don’t finish during the reservation window, the remaining pending jobs might fail. If you use session inside a reservation, we suggest you set a realistic