メインコンテンツへスキップ

Qiskit Runtime実行モードに関するよくある質問

Qiskit Runtimeのローカルテストモードは、異なる実行モードをサポートしていますか？

ローカルテストモードは異なる実行モードの構文をサポートしていますが、ローカルでテストする際にはスケジューリングが行われないため、モードは無視されます。

特定のBackendで並列実行できるジョブ数はいくつですか？

並列実行されるジョブ数は、Backendに設定されている並列度に基づいており、現在ほとんどのBackendでは5です。

失敗またはキャンセルされたジョブの使用量はどのように報告されますか？

実行モードのページにある失敗およびキャンセルされたジョブのセクションをご覧ください。

セッション​

セッションが閉じられた場合、ジョブはどうなりますか？

qiskit-ibm-runtimeのSessionクラスを使用している場合：

  • Session.close() はセッションが新しいジョブを受け付けなくなりますが、既存のジョブは完了まで実行されます。
  • Session.cancel() は保留中のすべてのセッションジョブをキャンセルします。

REST APIを直接使用している場合：

  • accepting_jobs=Falseを指定したPATCH /sessions/{id} はセッションが新しいジョブを受け付けなくなりますが、既存のジョブは完了まで実行されます。
  • DELETE /sessions/{id}/close は保留中のすべてのセッションジョブをキャンセルします。

セッションモードを使用していて、実験に何時間もかかる場合、キャリブレーションを要求する方法はありますか？

いいえ。オンデマンドのキャリブレーションは利用できません。

セッションモードにはインタラクティブタイムアウト（インタラクティブTTL）がありますか？

はい。これにより、ユーザーがセッションを閉じ忘れた場合の不要なコストを削減できます。

セッションのインタラクティブTTLや最大TTLを変更できますか？

インタラクティブTTL値は変更できません。セッションの最大TTL値は変更できます（セッション長の指定を参照）が、システムで定義された最大値未満である必要があります。異なるインタラクティブTTLやシステム最大TTLが必要な場合は、管理者からIBMサポートへ連絡してください。

セッションの使用量は、使用量による課金がないIBM Quantum Networkメンバーにどのような影響を与えますか？

IBM Quantum NetworkメンバーはIBM Quantum® QPUの予約済み容量を取得します。使用量はこの容量から差し引かれ、容量が少ないインスタンスはキューイング時間が長くなります。

セッションモードでバッチモードと同じ並列性が得られますか？

はい。セッション内に複数のジョブを同時に送信すると、これらのジョブは並列で実行されます。

セッションはQPUのアップグレードやキャリブレーションによって中断されることがありますか？

いいえ。セッションは専用モードで実行されるため、ユーザーはBackendへの完全なアクセス権を持ちます。セッションはキャリブレーションやソフトウェアアップグレードによって中断されることはありません。

セッションモードではコンパイル時間は使用量としてカウントされますか？

はい。セッションモードでは、使用量はQPUがセッションにコミットされている実際の経過時間です。最初のセッションジョブが開始されたときに計測が始まり、セッションが非アクティブになった時点、セッションが閉じられた時点、または最後のジョブが完了した時点のうち、最後に発生したものを終了時点とします。そのため、セッションが終了した後もQPUがジョブを実行している場合、使用量は引き続き累積されます。さらに、ジョブが完了した後、QPUが次のセッションジョブを待っている時間（インタラクティブTTL）も使用量としてカウントされます。これが、ジョブの送信が完了したらすぐにセッションを閉じるべき理由です。

バッチ​

バッチモードでは何件のジョブが並列で実行されますか？

並列実行されるジョブ数は、Backendに設定されている並列度に基づいており、ほとんどのBackendでは5です。ただし、バッチがアクティブになったときにすでに他のジョブが実行されている場合があるため、アクティブなバッチ内の同時ジョブ数はこれより少なくなる場合があります。

ジョブモードで_N_個のPUBを実行することと、バッチモードで_N_個の単一PUBジョブを実行することはどう違いますか？

主な違いは時間とコストのトレードオフです：

バッチモード：

  • クラシカル処理が並列で実行される可能性があるため、合計実行時間が短くなります。
  • 各ジョブの実行にわずかなオーバーヘッドがあるため、バッチジョブでは少し多くの費用がかかります。このオーバーヘッドはジョブのサイズに相関します。例えば、それぞれ100x100の回路を40個含む2つのジョブの合計使用量は、80個の回路を含む1つのジョブより6秒多くなります。
  • バッチモードはBackendへの排他的アクセスを提供しないため、バッチ内のジョブは他のユーザーのジョブやキャリブレーションジョブと同時に実行される場合があります。
  • 一部のジョブが失敗しても、完了したジョブの結果は取得できます。
  • バッチワークロードの途中で、完了したジョブの結果に基づいて対応を取ることができます。例えば、初期結果が正しくない場合に残りのジョブをキャンセルできます。

ジョブモード：

  • 並列性がないため、合計実行時間が長くなる可能性があります。
  • バッチワークロードに関連するジョブごとの余分なオーバーヘッドを支払う必要がありません。
  • すべての回路が一緒に実行されます。
  • この単一のジョブが失敗した場合、部分的な結果は得られません。
  • 回路が多すぎる場合や回路が大きすぎる場合、ジョブが制限に達する可能性があります。

一般的に、各ジョブのQPU時間が1分未満の場合は、それらをより大きなジョブにまとめることを検討してください（これはすべての実行モードに適用されます）。

バッチで送信できるジョブ数はいくつですか？

バッチで送信できるジョブ数に制限はありませんが、バッチには最大時間が設定されています。つまり、バッチの実際の経過時間（最初のバッチジョブの実行開始時から計測）がシステムで定義された最大時間を超えると、バッチは新しいジョブを受け付けなくなり、キューに入っているが実行されていないジョブはキャンセルされます。また、プランに基づいてジョブが消費できる使用量にも制限があります。バッチに関連する最大時間を確認するには、batch.details()メソッドを使用してmax_timeの値を確認してください。

バッチモードのジョブはいつ他のユーザーのジョブと並列で実行されますか？

Backendに設定されている並列度は「実行レーン」とも呼ばれます。1つ以上の実行レーンが利用可能で、バッチジョブが次に実行される順番になると、スケジューラはレーンを埋めるのに十分なジョブを開始します。同様に、バッチにレーンを埋めるのに十分なジョブがない場合、スケジューラは他のユーザーのジョブを開始します。

例：選択したBackendに5つの実行レーンがあり、そのうち2つが現在他のユーザーのジョブで占有されています。6つのジョブのバッチが次に実行される順番になっています。

利用可能なレーンが3つあるため、スケジューラは6つのバッチジョブのうち3つを開始します。ジョブが完了して実行レーンが空くにつれて、バッチ内のジョブを引き続き開始します。レーンが空いてもバッチ内にジョブがなくなった場合、スケジューラは次のジョブを開始します。

バッチジョブはすべてキューで待機する必要がありますか？

QPUは限られた共有リソースであるため、すべてのジョブはキューで待機する必要があります。ただし、バッチ内の最初のジョブが実行を開始すると、そのバッチ内の他のすべてのジョブは実質的にキューの先頭に移動し、スケジューラによって優先されます。

バッチは最後の関連ジョブが終了すると自動的に終了しますか？

はい。ただし、この自動検出にはわずかなオーバーヘッドが伴うため、常にバッチとセッションを明示的に閉じるようにしてください。

バッチはキャリブレーションやソフトウェアアップグレードによって中断されることがありますか？

はい。バッチワークロードはキャリブレーションやソフトウェアアップグレードによって中断される場合があります。

バッチモードではコンパイル時間は使用量としてカウントされますか？

いいえ。バッチモードでは、量子ハードウェアで費やされた時間のみが使用量としてカウントされます。