ワークロード使用量

使用量は、 IBM Quantum Compute Serviceの利用量を表し、ワークロードを実行するためにQPUがロックされている時間によって決定されます。

• セッションの使用時間は、セッションがアクティブな状態にある間の経過時間として測定されます。これは、ワークロードが実際に実行されているかどうかに関わらず、セッションの期間中はQPUの容量が確保されるためです。 セッションの状態遷移に関する詳細については、「セッションの継続時間」を参照してください。
• バッチの使用時間は、バッチ内のすべてのジョブを実行するためにQPUが占有された累積時間として測定されます。
• 単一ジョブの使用時間は、そのジョブを実行するためにQPUが占有されている時間として測定されます。

失敗またはキャンセルされたジョブは、特定の状況下では使用量にカウントされることにご注意ください。詳細は 「失敗およびキャンセルされたジョブ 」セクションを参照してください。

従量課金プランをご利用のお客様は、費用上限の設定方法の詳細について、 「費用の管理」 をご覧ください。

失敗したジョブおよびキャンセルされたジョブの使用方法

ジョブが失敗またはキャンセルされた場合、報告される使用量は以下のようになる：

• ジョブモードまたはバッチモード：システムエラーが原因で失敗またはキャンセルが発生した場合、報告される使用量はゼロとなります。 ユーザー側のミスによりジョブが失敗した場合、またはユーザーがジョブをキャンセルした場合、報告される使用量は、その時点までに発生したすべての消費量となります。これには、ジョブを実行するためにQPUを準備する際に発生したオーバーヘッドも含まれます。

• セッションモード: 報告される使用時間は、セッションがアクティブである実時間であり、失敗またはキャンセルされたジョブの数には依存しません。

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

ワークロードが完了した後、その実際の使用量を見るにはいくつかの方法がある：

• 実行する batch.usage() または session.usage() in qiskit-ibm-runtime 0.30 or later. 古いバージョンの qiskit-ibm-runtime (>= 0.23 and < 0.30 ) を使用している場合は、 session.details()["usage_time"] と batch.details()["usage_time"] に使い方が記載されています。
• 使用 GET /sessions/{id} を使用すると、特定のバッチまたはセッションの使用量を確認できます。
• 使用方法 GET /jobs/{id} を使用すると、1つのジョブの使用量を見ることができます。

インスタンスの使用状況を表示

インスタンスの使用状況は、 インスタンス・ ページ、または適切な権限を持つ人のためのアナリティクス・ページで見ることができます。 それぞれのページでは、使用量の計算方法が異なるため、異なる使用量が表示される可能性があることに注意してください。

インスタンス」ページには、過去28日間（ローリング）のリアルタイム使用量が表示されます。 アナリティクスのページ使用量は1時間ごとに再計算され、過去28日分が含まれます。つまり、28日前の00:00から今日の1時間前までの使用量が表示されます。

ジョブを送信する前に使用量を推定する

正確なローカル推定値を得ることは、エラー抑制と緩和のために行われる余分な演算のために複雑であるが、推定使用量の近似値を得るためにこの基本式を使用することができる：

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

• <per sub-job overhead> は、サブジョブあたり約 2s のオーバーヘッドである。 これには、ペイロードを制御電子機器にロードする作業などが含まれる。 プリミティブ・ジョブは、実行エンジンが一度に処理するには大きすぎる場合、複数のサブジョブに分割されることがあります。
• rep_delay はユーザーがカスタマイズ可能なオプションであり、デフォルトは backend.default_rep_delay で指定されている。これは、ほとんどの IBM Quantum バックエンドで250マイクロ秒である。 rep_delay を下げるとQPUの総実行時間が短くなりますが、その代償として状態準備エラー率が高くなることに注意してください。詳細については、 動的繰り返し率実行ガイドを参照してください。
• <circuit length> は総命令長である。 各命令はQPU上で異なる時間を要するため、回路によって総延長は異なる。 たとえば、測定には x ゲートの56倍の時間がかかる。 backend.target[<instruction>][<qubit>].duration を使えば、各命令の正確な継続時間を見つけることができる。 典型的な回路の長さは50-100マイクロ秒の間だろう。 プリミティブでエラー抑制やエラー軽減のテクニックを使用する場合、回路に余分な命令が挿入される可能性があり、回路総長が長くなる。
  Note

  experimental scheduler_timing オプションは、回路の合計時間を返すが、これは課金に使用される時間ではない。

• <num executions> 回路の総数にショット数を掛けた値であり、ここで回路とは PUB 個の要素がブロードキャストされた後に生成される回路を指す。
  • プリミティブでエラー軽減技術を使用している場合、軽減プロセスの一環として追加回路が実行される可能性があり、これにより総実行回数が増加する。 さらに、PEAやPECといった高度なエラー軽減技術は、ノイズ学習のために回路を稼働させる必要があるため、はるかに高いオーバーヘッドを伴う。
  • 推定器は量子ビット単位で可換な観測量をグループ化し、実行回数を削減する。

高度なエラー軽減技術やカスタム処理を使用していない rep_delay場合、簡易的な計算式として 2+0.00035*<num executions> 以下を利用できます。

Qiskit を使用してローカルで消費電力を推定する

このコード例は、Qiskit を使用して回路時間を計算する方法を示しています：

# 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")

次のステップ