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

ワークロードの使用量

使用量(Usage)は Qiskit Runtime サービスの消費量を表し、ワークロードを実行するために QPU がロックされている時間によって決まります。

  • セッション使用量は、QPU キャパシティがセッション期間中予約されているため、セッションがアクティブな状態の経過時間として計測されます(ワークロードが実際に実行中かどうかに関わらず)。セッションのステータス遷移については、セッションの長さを参照してください。
  • バッチ使用量は、バッチ内のすべてのジョブを実行するために QPU がロックされていた累積時間として計測されます。
  • 単一ジョブ使用量は、そのジョブを実行するために QPU がロックされていた時間として計測されます。

なお、失敗またはキャンセルされたジョブは、特定の状況下で使用量にカウントされます。詳細は失敗・キャンセルされたジョブのセクションを参照してください。

従量課金プランのユーザーの場合、コスト上限の設定について詳しくはコストの管理を参照してください。

失敗・キャンセルされたジョブの使用量

ジョブが失敗またはキャンセルされた場合、報告される使用量は次のとおりです:

  • ジョブまたはバッチモード:システムエラーにより失敗またはキャンセルされた場合、報告される使用量はゼロです。ユーザーエラーにより失敗したジョブやユーザーがキャンセルしたジョブの場合、報告される使用量はその時点までに発生した消費量となります。

  • セッションモード:報告される使用量は、失敗またはキャンセルされたジョブ数に関わらず、セッションがアクティブなウォールクロック時間です。

ワークロードの実際の使用量を照会する

ワークロードが完了した後、実際の使用量を確認するいくつかの方法があります:

  • qiskit-ibm-runtime 0.30 以降で batch.usage() または session.usage() を実行します。古いバージョンの qiskit-ibm-runtime(>= 0.23 かつ < 0.30)を使用している場合も、session.details()["usage_time"] および batch.details()["usage_time"] で使用量を確認できます。
  • GET /sessions/{id} を使用して、特定のバッチまたはセッションの使用量を確認します。
  • GET /jobs/{id} を使用して、単一ジョブの使用量を確認します。

インスタンスの使用量を表示する

インスタンスの使用量は、インスタンスページ、または適切な権限を持つユーザーの場合はアナリティクスページで確認できます。なお、これらのページは使用量の計算方法が異なるため、表示される使用量の数値が異なる場合があります。

インスタンスページは、現在の日の現在時刻まで、過去28日間(ローリング)のリアルタイム使用量を表示します。アナリティクスページの使用量は1時間ごとに再計算され、直近28日分の完全なデータを含みます。つまり、28日前の00:00から本日の正時までの使用量が表示されます。

ジョブ送信前の使用量の見積もり

エラー抑制やエラー緩和のために行われる追加操作により、正確なローカル見積もりは複雑になりますが、次のベースとなる式を使って推定使用量の近似値を求めることができます:

<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>

  • <per sub-job overhead> は、サブジョブごとに約2秒のオーバーヘッドです。これには、制御エレクトロニクスへのペイロードの読み込みなどの操作が含まれます。プリミティブジョブは、実行エンジンが一度に処理するには大きすぎる場合、複数のサブジョブに分割されることがあります。
  • rep_delayユーザーがカスタマイズ可能なオプションであり、デフォルト値は backend.default_rep_delay で与えられ、ほとんどの IBM Quantum バックエンドでは250マイクロ秒です。rep_delay を下げると QPU の総実行時間は短縮されますが、状態準備のエラー率が増加することに注意してください。詳細は動的繰り返しレート実行ガイドを参照してください。
  • <circuit length> は命令の総長さです。QPU 上での各命令の実行時間は異なるため、総長はCircuitによって異なります。例えば、測定は x ゲートの56倍の時間を要することがあります。backend.target[<instruction>][<qubit>].duration を使用して、各命令の正確な継続時間を調べることができます。典型的なCircuitの長さは、50〜100マイクロ秒程度です。プリミティブでエラー抑制またはエラー緩和技術を使用している場合、Circuitに追加の命令が挿入され、回路全体の長さが増加することがあります。
    備考

    実験的な scheduler_timing オプションは回路の総時間を返しますが、これは課金に使用される時間ではありません。

  • <num executions> は、PUB要素がブロードキャストされた後に生成されたCircuit数にショット数を掛けた総実行数です。
    • プリミティブでエラー緩和技術を使用している場合、緩和プロセスの一部として追加のCircuitが実行され、総実行数が増加することがあります。さらに、PEAやPECなどの高度なエラー緩和技術は、ノイズ学習のためにCircuitを実行する必要があるため、はるかに高いオーバーヘッドが発生します。
    • Estimatorはクビット単位で可換な観測量をグループ化するため、実行数を削減できます。

高度なエラー緩和技術やカスタム rep_delay を使用していない場合は、2+0.00035*<num executions> を簡易計算式として使用できます。

Qiskit を使用してローカルで使用量を見積もる

以下のコード例は、Qiskit を使用して Circuit の時間を計算する方法を示しています:


# Schedule the circuit to get more accurate timing
pm = generate_preset_pass_manager(
target=backend.target,
optimization_level=0,
scheduling_method="alap"
)

scheduled_circuits = pm.run(isa_circuits)

init_duration = backend.target["reset"][(0,)].duration
rep_delay = sampler.options.execution.rep_delay or backend.default_rep_delay

circuit_duration = 0

for circuit in scheduled_circuits:
# Estimate circuit length
circuit_duration += circuit.estimate_duration(backend.target)

# Add INIT time
if sampler.options.execution.init_qubits:
circuit_duration += init_duration

# Add rep_delay
circuit_duration += rep_delay

total_time = 2 + (circuit_duration*shots)
print(f"Total estimated usage is {math.ceil(total_time)} seconds")

次のステップ

推奨事項