Zum Hauptinhalt springen

Workload-Nutzung

Nutzung ist ein Maß für die Zeitspanne, in der die QPU für deine Workload gesperrt ist, und sie wird unterschiedlich berechnet, je nachdem, welchen Ausführungsmodus du verwendest.

  • Session-Nutzung ist die Wanduhr-Zeit, in der die Session aktiv ist. Weitere Informationen zum Session-Status-Übergang findest du unter Session length.
  • Batch-Nutzung ist die Summe der Quantenzeit (Zeit, die der QPU-Komplex zur Verarbeitung deines Jobs benötigt) aller Jobs im Batch.
  • Einzeljob-Nutzung ist die Quantenzeit, die der Job bei der Verarbeitung verwendet.

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 mit kostenpflichtigem Plan bestimmt die Nutzung, wie viel die Workload kostet. Weitere Details findest du unter Manage cost.

Nutzung für fehlgeschlagene und abgebrochene Jobs​

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

  • Job- oder Batch-Modus: Die gemeldete Nutzung ist die Zeit, in der die QPU für die Ausführung deiner Workload gesperrt war, bis zu dem Zeitpunkt, an dem sie fehlschlug oder abgebrochen wurde. Wenn der Fehler oder Abbruch vor der Sperrung auftrat, beträgt die gemeldete Nutzung daher null. Andernfalls ist die gemeldete Nutzung der Workload die Nutzungsmenge vor dem Fehlschlagen oder Abbrechen der Workload. Daher erscheinen einige fehlgeschlagene Jobs nicht in deiner gemeldeten Nutzung und andere schon.

  • Session-Modus: 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 batch.usage() oder session.usage() in qiskit-ibm-runtime 0.30 oder später aus. 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.
  • 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 -korrektur 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 ungefähr 2s pro Sub-Job. Dies umfasst Operationen wie das Laden der Payload in die Kontrollelektronik. Dein Primitiv-Job kann in mehrere Sub-Jobs aufgeteilt werden, wenn er zu groß ist, damit die Ausführungs-Engine ihn auf einmal verarbeiten kann.
  • 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 -korrektur-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 Fehlerkorrektur-Techniken mit den Primitiven verwendest, werden möglicherweise zusätzliche Schaltungen als Teil des Korrekturprozesses ausgeführt, was die Gesamtzahl der Ausführungen erhöht. Darüber hinaus kommen fortgeschrittene Fehlerkorrektur-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 Fehlerkorrektur-Techniken oder benutzerdefinierte rep_delay verwendest, kannst du 2+0.00035*<num executions> als schnelle Formel verwenden.

Nächste Schritte​

Empfehlungen