Workload-Nutzung

Nutzung steht für den Verbrauch des IBM Quantum Compute Service und wird durch die Zeit bestimmt, in der eine QPU für die Ausführung von Workloads gesperrt ist.

• Session-Nutzung wird als die verstrichene Zeit gemessen, während die Session aktiv bleibt, da QPU-Kapazität für die Dauer der Session reserviert ist – unabhängig davon, ob gerade Workloads aktiv ausgeführt werden. Weitere Informationen zu Session-Status-Übergängen findest du unter Session length.

• Batch-Nutzung wird als die kumulierte Zeit gemessen, in der die QPU gesperrt ist, um alle Jobs im Batch auszuführen.

• Einzeljob-Nutzung wird als die Zeit gemessen, in der die QPU gesperrt ist, um den Job auszuführen.

Beachte, dass fehlgeschlagene oder abgebrochene Jobs unter bestimmten Umständen zu deiner Nutzung zählen - siehe den Abschnitt Failed and canceled jobs für Details.

Für Nutzer des Pay-As-You-Go-Plans findest du unter Manage cost Details zum Festlegen eines Kostenlimits.

Nutzung für fehlgeschlagene und abgebrochene Jobs

Wenn ein Job fehlschlägt oder abgebrochen wird, wird die gemeldete Nutzung wie folgt berechnet:

• Job mode oder batch mode: Wenn der Fehler oder Abbruch aufgrund eines Systemfehlers aufgetreten ist, beträgt die gemeldete Nutzung null. Bei Jobs, die aufgrund eines Nutzerfehlers fehlgeschlagen sind oder die ein Nutzer abgebrochen hat, entspricht die gemeldete Nutzung dem bis zu diesem Zeitpunkt angefallenen Verbrauch, einschließlich des Overheads, der anfällt, um die QPU auf die Ausführung des Jobs vorzubereiten.

• Session mode: Die gemeldete Nutzung ist die Wanduhr-Zeit, in der die Session aktiv ist, unabhängig von der Anzahl der fehlgeschlagenen oder abgebrochenen Jobs.

Tatsächliche Nutzung einer Workload abfragen

Nachdem eine Workload abgeschlossen wurde, gibt es mehrere Möglichkeiten, ihre tatsächliche Nutzung anzuzeigen:

• Führe in qiskit-ibm-runtime v0.30 oder später job.usage() für einen einzelnen Job aus, oder batch.usage() bzw. session.usage(), wenn du batch mode oder session mode verwendest. Wenn du eine ältere Version von qiskit-ibm-runtime (>= 0.23 und < 0.30) verwendest, kann die Nutzung immer noch in session.details()["usage_time"] und batch.details()["usage_time"] gefunden werden.

• Verwende GET /sessions/{id}, um die Nutzung für einen bestimmten Batch oder eine Session anzuzeigen (der Endpunkt ist für beide Ausführungsmodi gleich).

• Verwende GET /jobs/{id}, um die Nutzung für einen einzelnen Job anzuzeigen.

Instanz-Nutzung anzeigen

Du kannst die Nutzung einer Instanz auf der Seite Instances oder für Personen mit entsprechender Berechtigung auf der Seite Analytics anzeigen. Beachte, dass die Seiten unterschiedliche Nutzungszahlen anzeigen können, da sie die Nutzung unterschiedlich berechnen.

Die Seite Instances zeigt die Echtzeit-Nutzung der letzten 28 Tage (rollierend) bis zur aktuellen Zeit am aktuellen Tag. Die Nutzung auf der Seite Analytics wird stündlich neu berechnet und umfasst die letzten 28 vollständigen Tage; das heißt, sie zeigt die Nutzung von 00:00 Uhr vor 28 Tagen bis heute zur vollen Stunde.

Nutzung vor dem Einreichen eines Jobs schätzen

Während eine genaue lokale Schätzung durch die zusätzlichen Operationen für Fehlerunterdrückung und -minderung erschwert wird, kannst du diese Basisformel verwenden, um eine Annäherung der geschätzten Nutzung zu erhalten:

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

• <per sub-job overhead> ist ein Overhead von etwa 2s pro Sub-Job. Dazu gehören Vorgänge wie das Laden der Payload in die Steuerelektronik. Dein Primitive-Job kann in mehrere Sub-Jobs aufgeteilt werden, wenn er zu groß ist, um von der Ausführungs-Engine auf einmal verarbeitet zu werden.

• rep_delay ist eine vom Benutzer anpassbare Option, und der Standardwert wird durch backend.default_rep_delay angegeben, das auf den meisten IBM Quantum-Backends 250 Mikrosekunden beträgt. Beachte, dass das Senken von rep_delay die Gesamt-QPU-Ausführungszeit verringert, jedoch auf Kosten einer erhöhten Zustandsvorbereitungsfehlerrate; siehe den Dynamic repetition rate execution-Guide für weitere Informationen.

• <circuit length> ist die Gesamtlänge der Anweisungen. Jede Anweisung benötigt unterschiedlich viel Zeit auf der QPU, daher variiert die Gesamtlänge von Schaltung zu Schaltung. Eine Messung kann beispielsweise 56 Mal länger dauern als ein x-Gate. backend.target[<instruction>][<qubit>].duration kann verwendet werden, um die genaue Dauer für jede Anweisung zu finden. Eine typische Schaltungslänge liegt wahrscheinlich zwischen 50-100 Mikrosekunden. Wenn du Fehlerunterdrückungs- oder -minderungs-Techniken mit den Primitiven verwendest, werden möglicherweise zusätzliche Anweisungen in deine Schaltung eingefügt, was die Gesamtschaltungslänge erhöht.

  hinweis

  Die experimentelle scheduler_timing-Option gibt die Gesamtschaltungszeit zurück, aber dies ist NICHT die für die Abrechnung verwendete Zeit.

• <num executions> ist die Gesamtzahl der Schaltungen mal die Anzahl der Shots, wobei die Schaltungen diejenigen sind, die nach dem Broadcasting der PUB-Elemente generiert werden.

  • Wenn du Fehlerminderungs-Techniken mit den Primitiven verwendest, werden möglicherweise zusätzliche Schaltungen als Teil des Minderungsprozesses ausgeführt, was die Gesamtzahl der Ausführungen erhöht. Darüber hinaus kommen fortgeschrittene Fehlerminderungs-Techniken wie PEA und PEC mit viel höherem Overhead, da sie Schaltungen für das Noise Learning ausführen müssen.
  • Estimator gruppiert qubit-weise kommutierende Observablen, was die Anzahl der Ausführungen reduziert.

Wenn du keine fortgeschrittenen Fehlerminderungs-Techniken oder benutzerdefinierte rep_delay verwendest, kannst du 2+0.00035*<num executions> als schnelle Formel verwenden.

Nutzung lokal mit Qiskit schätzen

Dieses Code-Beispiel zeigt, wie du mit Qiskit die Schaltungszeit berechnen kannst:

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

Nächste Schritte

Empfehlungen

• Überprüfe diese Tipps: Minimize job run time.
• Lege die Maximum execution time fest.
• Erfahre, wie du lokal transpilierst, im Abschnitt Transpile.
• Probiere den Guide Compare transpiler settings aus.