Skip to main content
IBM Quantum Platform

量子コンピュータの実行モード入門

IBM Quantum Compute Service が導入された当初、ユーザーはサーキットを個別のジョブとしてのみ実行することができました。 さまざまな種類の量子ワークロードが登場するにつれ、それぞれに適したスケジューリング戦略の必要性が明らかになってきた。 実行モードによってジョブのスケジューリング方法が決定され、適切な実行モードを選択することで、予算の範囲内でワークロードを効率的に実行することができます。 実行モードには、「ジョブ」、「セッション」、「バッチ」の3つがあります。


ジョブ・モード (Job Mode)

コンテキストマネージャーを使用せずに発行された単一のプリミティブリクエスト。 回路と入力は、プリミティブ統合ブロック(PUB)としてパッケージ化され、量子コンピュータ上で実行タスクとして送信される。 ジョブモードで実行するには、プリミティブをインスタンス化する際に mode=backend 指定してください。 使用方法については、「Estimator」の例および 「Sampler」の例を参照してください。


バッチ・モード

マルチジョブワークロードから構成される実験を効率的に実行するためのマルチジョブマネージャー。 これらのワークロードは、互いに条件付きの関係を持たない独立して実行可能なジョブで構成されています。 バッチモードでは、ユーザーはジョブをまとめて一度に提出します。

システムは各プリミティブジョブの事前処理(従来型計算)ステップを並列化またはスレッド化し、ジョブ間で量子実行をより密にパッケージ化します。その後、各ジョブの量子実行を迅速に連続して実行し、最も効率的な結果を提供します。 スレッドに関する詳細については、 実行モードに関するよくある質問ページを参照してください。

バッチモードで実行されるジョブのセット。  各ジョブの古典的な計算部分は同時に行われ、その後すべてのジョブがQPUに送られる。  QPUは、最初のジョブがQPUに到達してから最後のジョブがQPUで処理されるまで、お客様の使用のためにロックされます。  QPUがアイドル状態であるジョブ間のギャップはない。
バッチの仕組み
ノート
  • バッチ処理では、ジョブが送信された順番に実行されることは保証されません。 また、バッチジョブは可能な限り緊密に連携して実行されますが、バックエンドへの排他的なアクセスはできません。 そのため、QPUに十分な処理能力があれば、バッチジョブは他のユーザーのジョブと並行して実行される可能性があります。 さらに、QPU較正ジョブは、バッチジョブの合間に実行することができる。
  • バッチ内で最初に投入されたジョブのキューイング時間は減少しない。 したがって、バッチは単一のジョブを実行する際には何のメリットももたらさない。

バッチモードで実行するには、プリミティブをインスタンス化するときに mode=batch を指定するか、バッチコンテキストマネージャでジョブを実行します。 例については、 ジョブのバッチ実行を参照してください。


セッションモード

マルチジョブのワークロードを実行するための専用ウィンドウ。 このウィンドウの間、ユーザーはシステムの排他的なアクセス権を持ち、校正ジョブを含む他のジョブは実行できません。 これにより、ユーザーはより予測可能な方法で変分アルゴリズムを実験することができ、スタックの並列性を利用して複数の実験を同時に実行することもできる。 セッションを使用することで、各ジョブを個別にキューイングすることによる遅延を回避することができ、古典的リソースと量子リソースの間で頻繁な通信を必要とする反復タスクに特に有効です。

セッションモードで実行されているジョブのセットと、バッチモードで実行されているジョブのセット。  各ジョブの間には、インタラクティブTTL(インタラクティブ・タイム・トゥ・ライブ)がある。  アクティブ・ウィンドウは、最初のジョブが開始されたときに開始され、最後のジョブが完了した後に終了する。 最初のジョブセットの最後のジョブが完了すると、アクティブウィンドウは終了し、セッションは一時停止される(クローズされない)。  その後、別の仕事が開始され、同じように仕事が続けられる。
セッションの仕組み

セッションモードで実行するには、プリミティブをインスタンス化するときに mode=session を指定するか、セッション・コンテキスト・マネージャでジョブを実行する。 例については、 セッション内でのジョブの実行を参照してください。

ノート
  • セッション内で最初に投入されたジョブのキューイング時間は短縮されない。 したがって、セッションは単一のジョブを実行する際には何のメリットももたらさない。
  • オープンプランのユーザーはセッションジョブを送信できません。

基本ワークフロー

バッチとセッションの基本的なワークフローは似ている:

  1. バッチまたはセッションの最初のジョブは、通常のキューに入る。 バッチの場合、ジョブのバッチ全体が一緒にスケジューリングされる。
  2. 最初のジョブが実行を開始すると、最大生存時間(TTL)タイマーが開始され、終了に達するまで停止または一時停止しない。
  3. インタラクティブTTLタイマーは、各ジョブが完了した後に開始する。 対話型TTLウィンドウ内にワークロードのジョブが準備できていない場合、ワークロードは一時的に非アクティブになり、通常のジョブ選択が再開される。 バッチまたはセッションが最大TTL値に達していない場合、ジョブは非アクティブ化されたワークロードを再アクティブ化できる。
    Note

    ジョブは、ワークロードを再アクティブ化するために、通常のキューを通過しなければならない。

  4. 最大TTL値に達した場合、作業負荷は終了し、キューに残っているジョブはすべて失敗する。 現在実行中のジョブは、それを実行するとインスタンスのコスト上限を超える場合は、完了まで実行されません。

次のビデオは、セッションを例に、基本的なワークフローを説明しています:

TTLタイマーの詳細については、 最大実行時間ガイドを参照のこと。


次のステップ

このページは役に立ちましたか?
バグや誤字の報告、またはコンテンツの要求はGitHubで行ってください。