Skip to main content
IBM Quantum Platform

Auslastung

Die Nutzung entspricht dem Verbrauch des „ IBM Quantum “-Compute-Dienstes und richtet sich nach der Zeit, in der eine QPU für die Ausführung von Workloads reserviert ist.

  • Die Sitzungsnutzung wird als die Zeit gemessen, die verstreicht, während die Sitzung aktiv ist, da die QPU-Kapazität für die Dauer der Sitzung reserviert bleibt, unabhängig davon, ob Workloads aktiv ausgeführt werden. Weitere Informationen zu den Statusübergängen einer Sitzung finden Sie unter „Sitzungsdauer “.
  • Die Batch-Auslastung wird als die Gesamtzeit gemessen, in der die QPU für die Ausführung aller Jobs im Batch gesperrt ist.
  • Die Auslastung durch einen einzelnen Job wird als die Zeit gemessen, in der die QPU für die Ausführung des Jobs reserviert ist.

Beachten Sie, dass fehlgeschlagene oder abgebrochene Aufträge unter bestimmten Umständen zu Ihrer Nutzung zählen – weitere Informationen finden Sie im Abschnitt „Fehlgeschlagene und abgebrochene Aufträge “.

Nutzer des Pay-As-You-Go-Tarifs finden unter „Kosten verwalten “ weitere Informationen zum Festlegen eines Kostenlimits.


Verwendung für fehlgeschlagene und abgebrochene Aufträge

Wenn ein Auftrag fehlschlägt oder abgebrochen wird, wird die Verwendung wie folgt gemeldet:

  • Einzel- oder Stapelmodus: Wenn der Fehler oder die Abbruch aufgrund eines Systemfehlers aufgetreten ist, wird die Nutzung mit Null angegeben. Bei Aufträgen, die aufgrund eines Benutzerfehlers fehlgeschlagen sind oder von einem Benutzer abgebrochen wurden, umfasst die gemeldete Nutzung den bis zu diesem Zeitpunkt angefallenen Verbrauch, einschließlich des Aufwands, der für die Vorbereitung der QPU zur Ausführung des Auftrags entstanden ist.

  • Sitzungsmodus: Die gemeldete Nutzung ist die tatsächliche Zeit, in der die Sitzung aktiv ist, unabhängig von der Anzahl der fehlgeschlagenen oder abgebrochenen Aufträge.


Die tatsächliche Nutzung einer Arbeitslast abfragen

Nach Beendigung eines Workloads gibt es mehrere Möglichkeiten, die tatsächliche Nutzung anzuzeigen:

  • Führen Sie in v0.30qiskit-ibm-runtime oder höher den Befehl für job.usage() einen einzelnen Job aus oder die Befehle bzw batch.usage() ., session.usage() wenn Sie den Batch- oder Sitzungsmodus verwenden. Bei Verwendung einer älteren Version von qiskit-ibm-runtime (>= 0.23 und < 0.30 ) finden Sie die Anleitung weiterhin unter session.details()["usage_time"] und batch.details()["usage_time"].
  • Verwenden Sie, um GET /sessions/{id} die Nutzung für einen bestimmten Durchlauf oder eine bestimmte Sitzung anzuzeigen (der Endpunkt ist für beide Ausführungsmodi identisch).
  • Verwenden Sie, GET /jobs/{id} um die Nutzung eines einzelnen Auftrags anzuzeigen.

Instanznutzung anzeigen

Sie können die Nutzung einer Instanz auf der Seite Instanzen oder, für diejenigen mit der entsprechenden Berechtigung, auf der Seite Analysen einsehen. Beachten Sie, dass die Seiten möglicherweise unterschiedliche Nutzungszahlen anzeigen, da sie die Nutzung unterschiedlich berechnen.

Die Seite Instanzen zeigt die Echtzeitnutzung der letzten 28 Tage (rollierend) bis zur aktuellen Uhrzeit des aktuellen Tages. Die Nutzung der Analytics-Seite wird stündlich neu berechnet und umfasst die letzten 28 vollen Tage, d. h. sie zeigt die Nutzung von vor 28 Tagen um 00:00 Uhr bis heute zu jeder vollen Stunde.


Schätzen Sie die Nutzung, bevor Sie einen Auftrag einreichen

Eine genaue lokale Schätzung wird zwar durch die zusätzlichen Operationen zur Fehlerunterdrückung und -minderung erschwert, aber Sie können diese Grundformel verwenden, um einen Näherungswert für die geschätzte Nutzung zu erhalten:

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

  • <per sub-job overhead> ist ein Overhead von etwa 2s pro Teilauftrag. Dazu gehören Vorgänge wie das Laden der Nutzlast in die Steuerelektronik. Ihr primitiver Auftrag kann in mehrere Teilaufträge aufgeteilt werden, wenn er für die Ausführungsmaschine zu groß ist, um alle auf einmal zu verarbeiten.
  • rep_delay ist eine vom Benutzer anpassbare Option, deren Standardwert durch festgelegt ist backend.default_rep_delay, der bei den meisten „ IBM Quantum “-Backends 250 Mikrosekunden beträgt. Beachten Sie, dass eine Verringerung der die gesamte QPU-Ausführungszeit verkürzt rep_delay , jedoch auf Kosten einer erhöhten Fehlerrate bei der Zustandsvorbereitung; weitere Informationen finden Sie im Leitfaden zur Ausführung mit dynamischer Wiederholungsrate.
  • <circuit length> ist die Gesamtlänge der Anweisungen. Jede Anweisung benötigt auf der QPU unterschiedlich viel Zeit, so dass die Gesamtlänge von Schaltung zu Schaltung variiert. Eine Messung kann zum Beispiel 56 Mal länger dauern als ein x Tor. backend.target[<instruction>][<qubit>].duration kann verwendet werden, um die genaue Dauer für jede Anweisung zu ermitteln. Eine typische Schaltungslänge liegt wahrscheinlich zwischen 50-100 Mikrosekunden. Wenn Sie mit den Primitiven Fehlerunterdrückungs- oder -minderungstechniken verwenden, werden möglicherweise zusätzliche Anweisungen in Ihre Schaltung eingefügt, was die Gesamtlänge der Schaltung erhöhen würde.
    Note

    Die experimentelle Option scheduler_timing gibt die Gesamtzeit des Stromkreises zurück, aber dies ist NICHT die Zeit, die für die Abrechnung verwendet wird.

  • <num executions> ist die Gesamtzahl der Schaltkreise multipliziert mit der Anzahl der Schüsse, wobei die Schaltkreise diejenigen sind, die nach der Übertragung von „ PUB “-Elementen erzeugt werden.
    • Wenn Sie Fehlerbehebungsmethoden mit den Primitiven verwenden, können im Rahmen des Behebungsprozesses zusätzliche Schaltkreise ausgeführt werden, wodurch sich die Gesamtzahl der Ausführungen erhöht. Darüber hinaus sind fortschrittliche Fehlerminderungstechniken wie PEA und PEC mit einem viel höheren Overhead verbunden, da sie für das Noise Learning laufende Schaltungen erfordern.
    • Der Schätzer gruppiert qubitweise kommutierende Observablen, wodurch sich die Anzahl der Ausführungen reduziert.

Wenn Sie keine erweiterten Fehlerbehebungstechniken oder benutzerdefinierten rep_delayFunktionen verwenden, können Sie als 2+0.00035*<num executions> schnelle Formel verwenden.

Schätzung der Nutzung vor Ort mit Qiskit

Dieses Code-Beispiel zeigt, wie man mit Qiskit die Schaltungszeit berechnet:


# 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
War diese Seite hilfreich?
Melden Sie auf GitHub einen Fehler, einen Tippfehler oder fordern Sie Inhalte an.