Skip to main content
IBM Quantum Platform

実行モードに関するFAQ

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

  • 並列に実行されるジョブの数は、バックエンドに設定された並列度に基づいている。

  • 実行モードのページの失敗したジョブとキャンセルされたジョブのセクションを参照してください。

セッション

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

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

    REST APIを直接使用する場合：

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

  • いいえ オンデマンド校正は利用できません。

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

  • インタラクティブTTL値は変更できない。 セッションの最大TTL値は変更できますが（ セッション長の指定参照）、システム定義の最大値以下でなければなりません。 別のインタラクティブTTLまたはシステム最大TTLが必要な場合は、管理者に IBM サポートに問い合わせてください。

  • IBM Quantum Network メンバーは、 IBM Quantum® QPUの予約容量を獲得する。 使用量はこのキャパシティから差し引かれ、キャパシティの低いインスタンスはキューイング時間が長くなる。

  • はい。 セッション内で複数のジョブを同時に投入した場合、これらのジョブは並行して実行されます。

  • いいえ セッションは専用モードで実行され、ユーザーはバックエンドに完全にアクセスできる。 校正やソフトウェアのアップグレードによってセッションが中断されることはない。

  • はい。 セッション・モードでは、使用量はQPUがセッションにコミットされるウォールクロック時間である。 最初のセッションのジョブが開始されたときに開始され、セッションが非アクティブになるか、終了されるか、最後のジョブが完了したときに終了する。 したがって、QPUがまだジョブを実行している場合、セッション終了後も使用量は蓄積され続ける。 さらに、ジョブの完了後、QPUが別のセッション・ジョブを待機している間の時間（インタラクティブTTL）も、使用量としてカウントされます。 そのため、ジョブの投入が終わったらすぐにセッションを閉じるようにしてください。

バッチ

  • 並列に実行されるジョブの数は、バックエンドに設定された並列度に基づいており、ほとんどのバックエンドでは5である。 しかし、バッチがアクティブになったときに、すでに他のジョブが実行されている可能性があるため、アクティブなバッチの同時実行ジョブ数は少なくなる可能性がある。

  • 主な違いは、時間とコストのトレードオフである：

    バッチモード：

    • 古典的な処理が並行して実行される可能性があるため、総実行時間は短くなる。
    • 各ジョブを実行するにはわずかなオーバーヘッドが生じるため、すべての回路を単一のジョブで実行する場合に比べ、バッチ処理のジョブではコストが若干高くなります。
    • バッチモードではバックエンドへの排他的なアクセスができないため、バッチ内のジョブは他のユーザーのジョブやキャリブレーションジョブと一緒に実行される可能性があります。
    • いくつかのジョブが失敗しても、完了したジョブの結果は得られる。
    • 完了したジョブの結果に基づいて、バッチ作業負荷の途中でアクションを起こすことができる。 例えば、最初の結果が不正確な場合、残りのジョブをキャンセルすることができる。

    仕事モード：

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

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

  • バッチで送信できるジョブ数に制限はありませんが、バッチには最長時間があります。 つまり、バッチのウォールクロック時間（最初のバッチジョブが実行を開始した時点から始まる）がシステムで定義された最大時間を超えると、バッチは新しいジョブを受け付けなくなり、キューに入れられたが実行されていないジョブはキャンセルされる。 さらに、ご利用のプランによって、ジョブが消費できる使用量に制限があります。 バッチに関連する最大時間を決定するには、 batch.details() メソッドを使用し、 max_time 値を探す。

  • バックエンドに設定された並列性の度合いは、「実行レーン」とも呼ばれる。 実行可能なレーンが1つ以上あり、バッチジョブが次に実行される場合、スケジューラはレーンを埋めるのに十分な数のジョブを開始します。 同様に、自分のバッチにレーンを埋めるだけのジョブがない場合、スケジューラーは他のユーザーのジョブを開始する。

    例あなたが選んだバックエンドには5つの実行レーンがあり、そのうちの2つは現在他のユーザーのジョブによって占有されています。 あなたの6つのジョブのバッチが次に実行される。

    利用可能なレーンが3つあるので、スケジューラは6つのバッチジョブのうち3つを開始する。 ジョブが終了し、実行レーンが利用可能になると、バッチ内のジョブを開始し続ける。 レーンが使用可能になり、バッチ内にジョブがなくなると、スケジューラは次のジョブを開始する。

  • QPUは限られた共有リソースなので、すべてのジョブはキューで待つ必要がある。 しかし、バッチ内の最初のジョブが実行を開始すると、そのバッチ内の他のすべてのジョブは基本的にキューの先頭にジャンプし、スケジューラによって優先順位が付けられる。

  • はい。 しかし、この自動検出には若干のオーバーヘッドがあるため、必ずバッチとセッションを閉じる必要がある。

  • はい。 バッチ作業負荷は、校正やソフトウェアのアップグレードによって中断される可能性がある。

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

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