Skip to main content
IBM Quantum Platform

正しい実行モードを選択する

ユーティリティスケールのワークロードは、完了までに何時間もかかることがあるため、古典的リソースと量子リソースの両方を効率的にスケジューリングし、実行を効率化することが重要です。 実行モードは、コストと時間のトレードオフのバランスを柔軟に調整し、ワークロードに最適なリソースを使用します。 どの実行モードを使用するかを選択する際には、全体的な実行時間（最大稼働時間、TTL）やジョブ間の時間（インタラクティブTTL）など、考慮すべき点がいくつかある。

それぞれの利点は以下の通り：

  • バッチ
    • ジョブのバッチ全体が一緒にスケジューリングされるため、それぞれのジョブにキューイング時間が追加されることはない。
    • コンパイルなどの古典的な計算は並列に実行される。 従って、複数のジョブをバッチで実行する方が、シリアルで実行するよりも圧倒的に速い。
    • 通常、ジョブ間の遅延は最小限に抑えられ、ドリフトを回避するのに役立つ。
    • ワークロードを複数のジョブに分割してバッチモードで実行すれば、個々のジョブから結果を得ることができ、作業の柔軟性が高まります。 例えば、仕事の結果が期待にそぐわない場合、残りの仕事をキャンセルすることができる。 また、1つのジョブが失敗しても、ワークロード全体を再実行する代わりに、そのジョブを再サブミットすることができる。
    • 一般的にセッションよりも安価である。
  • セッション
    • バッチモードの全機能（ただし使用量の増加が必要。使用量の計算方法の詳細についてはワークロード使用量を参照）。
    • セッションがアクティブなウィンドウの間、QPUに専用でアクセスできる。
    • 最初にすべての入力を準備できない作業負荷や、次の入力を実行する前に古典的な後処理を必要とする反復作業負荷、可能な限り緊密に連携して実行する必要がある実験に有用である。
  • ジョブ
    • 小規模な実験を行う場合に最も使いやすい。
    • バッチモードよりも早く実行されるかもしれない。

推奨事項とベストプラクティス

通常、すべての入力を最初に準備できないようなワークロードでない限り、バッチモードを使用する。

  • バッチモードを使用して複数のプリミティブジョブを同時に送信し、処理時間を短縮します。

  • 反復作業負荷や、QPUへの専用アクセスが必要な場合は、 セッションモードを使用する。

  • 単一のプリミティブリクエストを送信するには、常にジョブモードを使用する。

  • セッションは一般的に割高であるため、セッションを利用することによる付加的なメリットを必要としない場合は、バッチを利用することをお勧めします。

  • オープンプランのユーザーはセッションジョブを送信できません。

実行モードを最も効率的に使用するために、以下のプラクティスを推奨する：

  • ジョブの実行には固定的なオーバーヘッドがかかる。 一般的に、各ジョブの QPU 使用時間が1分未満の場合は、複数のジョブを1つの大きなジョブにまとめることを検討してください（これはすべての実行モードに当てはまります）。 「QPU時間」とは、あなたのジョブを処理するためにQPUコンプレックスが費やした時間のことです。

  • 各ジョブがQPU時間を1分以上消費する場合や、ジョブを組み合わせることが現実的でない場合でも、複数のジョブを並行して実行することができます。 すべての仕事は、古典的処理と量子的処理の両方を経る。 QPUは一度に1つのジョブしか処理できないが、古典的なジョブは最大5つまで並列処理できる。 バッチまたはセッション実行モードで複数のジョブを投入することで、この利点を活用できます。

上記は一般的なガイドラインであり、特にセッションを使用する場合は、ワークロードを調整して最適な比率を見つける必要がある。 例えば、セッションを使ってバックエンドに独占的にアクセスする場合、大きなジョブを小さなジョブに分割し、並行して実行することを検討する。 この方が壁掛け時間を短縮できるので、費用対効果は高いかもしれない。

例

量子変分アルゴリズムを実行する

量子変分アルゴリズムの実行は、通常この流れに従う：

  1. ansatzを準備する。
  2. QPUでコスト関数を評価する。
  3. 前のステップで得られた結果を、古典的なオプティマイザにかける。
  4. (3)の出力に従ってパラメーターを調整し、(2)のステップに戻る。

この場合、ジョブ・モードやバッチ・モードを使用していたのであれば、ステップ(2)で生成された各ジョブはキューに戻る必要がある。 このため、キューイング時間のために実験時間（壁時計時間）が大幅に長くなる。 また、デバイスのドリフトにより、収束に時間がかかる可能性もある。 つまり、反復するたびに良い結果が得られるはずだが、デバイスのドリフトによってその後の結果が悪くなる可能性がある。

さらに、 PEA または PEC を使用すると、専用セッションで実行するときにノイズモデルを一度学習して、後続のジョブに適用することができます。 次のジョブがキューから出るまでにノイズモデルが古くなってしまう可能性があるからだ。

エラー軽減設定の比較

利用可能なエラー軽減法の効果を比較するには、次のような流れに従うとよい：

  1. 回路を構成し、観測可能
  2. 異なるエラー緩和設定の組み合わせを使用するプリミティブ・ジョブを送信する。
  3. 結果をプロットして、さまざまな設定の効果を観察する。

この場合、（関連はあるが独立した）すべての仕事が最初から利用可能である。 バッチモードを使えば、まとめてスケジュールされるので、キューを通過するのを待つのは1回で済む。 さらに、さまざまなエラー軽減法の効果を比較することが目的であるため、可能な限り密に実行することが有益である。 従って、バッチは良い選択だろう。 セッションでこれらのジョブを実行することもできるが、セッションは一般にコストが高いので、セッションが提供する追加機能が不要な場合は、バッチを使用することを推奨する。

次のステップ

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