適切な実行モードの選択

ユーティリティスケールのワークロードは完了までに何時間もかかる場合があるため、クラシカルリソースと量子リソースの両方を効率よくスケジュールして実行を合理化することが重要です。実行モードを使用することで、ワークロードに対してリソースを最適に活用するためのコストと時間のトレードオフを柔軟に調整できます。どの実行モードを選択するかを検討する際には、全体的な実行時間（最大生存時間、TTL）やジョブ間の時間（インタラクティブTTL）など、いくつかの側面を考慮する必要があります。

各モードのメリットを以下にまとめます：

• バッチ
  • バッチ全体のジョブがまとめてスケジュールされるため、各ジョブに追加のキュー待ち時間が発生しません。
  • コンパイルなどのジョブのクラシカル計算が並列で実行されます。そのため、複数のジョブをバッチで実行すると、逐次実行と比べて大幅に高速になります。
  • 通常、ジョブ間の遅延が最小限に抑えられ、ドリフトの回避に役立ちます。
  • ワークロードを複数のジョブに分割してバッチモードで実行すると、各ジョブの結果を個別に取得できるため、柔軟に扱えます。たとえば、あるジョブの結果が期待を満たさない場合は残りのジョブをキャンセルでき、1つのジョブが失敗した場合はワークロード全体を再実行する代わりにそのジョブだけを再送信できます。
  • 一般的にセッションよりもコストが低くなります。
• セッション
  • バッチモードのすべての機能（ただし使用量が増加します。使用量の計算方法の詳細はワークロード使用量を参照してください）。
  • セッションのアクティブウィンドウ中はQPUへの専用かつ排他的なアクセスが提供されます。
  • すべての入力が最初から揃っていないワークロード、次の実行前にクラシカルな後処理が必要な反復的ワークロード、および可能な限り連続して実行する必要がある実験に適しています。
• ジョブ
  • 小規模な実験を実行する際に最も使いやすいモードです。
  • バッチモードよりも早く実行される場合があります。

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

最初からすべての入力が揃っていないワークロードでない限り、一般的にはバッチモードを使用してください。

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

• セッションモードは、反復的なワークロードや、QPUへの専用アクセスが必要な場合に使用します。

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

• セッションは一般的にコストが高い ため、セッションの追加メリットが不要な場合はバッチを使用することを推奨します。

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

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

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

• 各ジョブのQPU時間が1分を超える場合、またはジョブをまとめることが現実的でない場合でも、複数のジョブを並列で実行できます。すべてのジョブはクラシカル処理と量子処理の両方を経ます。QPUは一度に1つのジョブしか処理できませんが、クラシカルジョブは最大5つまで並列で処理できます。バッチまたはセッション実行モードで複数のジョブを送信することで、この並列処理を活用できます。

上記はあくまで一般的なガイドラインであり、特にセッションを使用する場合は、最適な比率を見つけるためにワークロードを調整してください。たとえば、セッションを使用してバックエンドへの排他的アクセスを取得している場合は、大きなジョブを小さなジョブに分割して並列実行することを検討してください。これにより、ウォールクロック時間を短縮でき、コスト効率が向上する可能性があります。

例

量子変分アルゴリズムの実行

量子変分アルゴリズムの実行は、通常以下のフローに従います：

1. アンザッツを準備します。
2. QPU上でコスト関数を評価します。
3. 前のステップの結果を取得し、クラシカルオプティマイザーで処理します。
4. (3) の出力に従ってパラメーターを調整し、ステップ (2) に戻ります。

この場合、ジョブモードまたはバッチモードを使用すると、ステップ (2) で生成された各ジョブがキューに再び送られる必要があります。これにより、キュー待ち時間のために実験時間（ウォールクロック時間）が大幅に増加します。また、デバイスドリフトにより収束に時間がかかる場合もあります。つまり、各反復でより良い結果が得られるはずですが、デバイスドリフトによって後続の結果が悪化する可能性があります。

さらに、PEAまたはPECを使用する場合、専用セッションで実行する際にノイズモデルを一度学習して後続のジョブに適用できます。次のジョブがキューから出てくるまでにノイズモデルが古くなる可能性があるため、これは通常バッチモードやジョブモードでは機能しません。

エラー軽減設定の比較

利用可能なエラー軽減手法の効果を比較するには、以下のフローに従います：

1. Circuit とオブザーバブルを構成します。
2. 異なるエラー軽減設定の組み合わせを使用するプリミティブジョブを送信します。
3. 結果をプロットして、各設定の効果を確認します。

この場合、すべてのジョブ（関連しているが独立している）は最初から利用可能です。バッチモードを使用すると、ジョブがまとめてスケジュールされるため、キューを通過するのを一度待つだけで済みます。また、目標がさまざまなエラー軽減手法の効果を比較することであるため、できるだけ近いタイミングで実行することが有益です。そのため、バッチが適切な選択肢となります。これらのジョブをセッションで実行することも できます が、セッションは一般的にコストが高いため、セッションが提供する追加機能が不要な場合はバッチを使用することを推奨します。

次のステップ

推奨事項

• バッチモードでジョブを実行する。
• セッションモードでジョブを実行する。
• ワークロード使用量。