Zum Hauptinhalt springen

Einführung in Qiskit Runtime Ausführungsmodi

Als Qiskit Runtime eingeführt wurde, konnten Benutzer Schaltkreise nur als einzelne Jobs ausführen. Mit dem Aufkommen verschiedener Arten von Quanten-Workloads wurde der Bedarf an unterschiedlichen Scheduling-Strategien deutlich. Die Ausführungsmodi bestimmen, wie deine Jobs geplant werden, und die Wahl des richtigen Ausführungsmodus ermöglicht es deinem Workload, effizient innerhalb deines Budgets zu laufen. Es gibt drei Ausführungsmodi: Job, Session und Batch.

Job-Modus​

Eine einzelne Primitive-Anfrage des Estimators oder Samplers, die ohne Context Manager ausgeführt wird. Schaltkreise und Eingaben werden als Primitive Unified Blocs (PUBs) verpackt und als Ausführungsaufgabe auf dem Quantencomputer eingereicht. Um im Job-Modus zu laufen, gib mode=backend an, wenn du ein Primitive instanziierst. Siehe Primitives-Beispiele für die Verwendung.

Batch-Modus​

Ein Multi-Job-Manager für die effiziente Ausführung von Experimenten, die aus Multi-Job-Workloads bestehen. Diese Workloads bestehen aus unabhängig ausführbaren Jobs, die keine bedingte Beziehung zueinander haben. Im Batch-Modus reichen Benutzer alle ihre Jobs auf einmal ein.

Das System parallelisiert oder verarbeitet die Vorverarbeitungsphase (klassisches Computing) jedes Primitive-Jobs gleichzeitig, um die Quantenausführung über Jobs hinweg enger zu packen, und führt dann die Quantenausführung jedes Jobs in schneller Folge aus, um die effizientesten Ergebnisse zu liefern. Weitere Details zum Threading findest du auf der FAQ-Seite zu Ausführungsmodi.

Eine Reihe von Jobs, die im Batch-Modus ausgeführt werden. Der klassische Berechnungsteil jedes Jobs erfolgt gleichzeitig, dann werden alle Jobs an die QPU gesendet. Die QPU ist von dem Zeitpunkt an für deine Nutzung gesperrt, an dem der erste Job die QPU erreicht, bis der letzte Job auf der QPU verarbeitet wurde. Es gibt keine Lücke zwischen den Jobs, in der die QPU inaktiv ist.

Hinweise
  • Beim Batching ist nicht garantiert, dass Jobs in der Reihenfolge ausgeführt werden, in der sie eingereicht wurden. Obwohl deine Batch-Jobs so eng wie möglich zusammen ausgeführt werden, erhalten sie keinen exklusiven Zugriff auf das Backend. Daher können deine Batch-Jobs parallel zu den Jobs anderer Benutzer laufen, wenn auf der QPU ausreichend Verarbeitungskapazität vorhanden ist. Zusätzlich können QPU-Kalibrierungsjobs zwischen den Batch-Jobs ausgeführt werden.
  • Die Wartezeit verringert sich nicht für den ersten Job, der innerhalb eines Batches eingereicht wird. Daher bieten Batches keine Vorteile beim Ausführen eines einzelnen Jobs.

Um im Batch-Modus zu laufen, gib mode=batch an, wenn du ein Primitive instanziierst, oder führe den Job in einem Batch-Context-Manager aus. Siehe Jobs im Batch ausführen für Beispiele.

Session-Modus​

Ein dediziertes Zeitfenster für die Ausführung eines Multi-Job-Workloads. Während dieses Zeitfensters hat der Benutzer exklusiven Zugriff auf das System und keine anderen Jobs können laufen - einschließlich Kalibrierungsjobs. Dies ermöglicht es Benutzern, mit variationalen Algorithmen auf vorhersehbarere Weise zu experimentieren und sogar mehrere Experimente gleichzeitig auszuführen, wobei die Parallelität im Stack genutzt wird. Die Verwendung von Sessions hilft, Verzögerungen zu vermeiden, die durch das separate Einreihen jedes Jobs verursacht werden, was besonders nützlich für iterative Aufgaben sein kann, die häufige Kommunikation zwischen klassischen und Quantenressourcen erfordern.

Eine Reihe von Jobs wird im Session-Modus ausgeführt und die andere wird im Batch-Modus ausgeführt. Zwischen jedem Job befindet sich die Interactive TTL (Interactive Time to Live). Das aktive Fenster beginnt, wenn der erste Job startet, und endet, nachdem der letzte Job abgeschlossen ist. Nachdem der letzte Job der ersten Gruppe von Jobs abgeschlossen ist, endet das aktive Fenster und die Session wird pausiert (aber nicht geschlossen). Eine weitere Gruppe von Jobs beginnt dann und Jobs werden auf ähnliche Weise fortgesetzt. Die QPU ist während der gesamten Session für deine Nutzung reserviert.

Um im Session-Modus zu laufen, gib mode=session an, wenn du ein Primitive instanziierst, oder führe den Job in einem Session-Context-Manager aus. Siehe Jobs in einer Session ausführen für Beispiele.

Hinweise
  • Die Wartezeit verringert sich nicht für den ersten Job, der innerhalb einer Session eingereicht wird. Daher bieten Sessions keine Vorteile beim Ausführen eines einzelnen Jobs.
  • Benutzer des Open Plans können keine Session-Jobs einreichen.

Grundlegender Workflow​

Der grundlegende Workflow für Batches und Sessions ist ähnlich:

  1. Der erste Job in einem Batch oder einer Session tritt in die normale Warteschlange ein. Bei Batches wird der gesamte Batch von Jobs zusammen geplant.
  2. Wenn der erste Job mit der Ausführung beginnt, startet der Timer für die maximale Time to Live (TTL) und stoppt oder pausiert nicht bis zum Ende.
  3. Der Interactive-TTL-Timer startet nach Abschluss jedes Jobs. Wenn innerhalb des Interactive-TTL-Fensters keine Workload-Jobs bereit sind, wird der Workload vorübergehend deaktiviert und die normale Job-Auswahl wird fortgesetzt. Ein Job kann den deaktivierten Workload reaktivieren, wenn der Batch oder die Session seinen maximalen TTL-Wert noch nicht erreicht hat.
    hinweis

    Der Job muss die normale Warteschlange durchlaufen, um den Workload zu reaktivieren.

  4. Wenn der maximale TTL-Wert erreicht ist, endet der Workload und alle verbleibenden Jobs in der Warteschlange schlagen fehl. Ein aktuell laufender Job wird nicht bis zum Abschluss ausgeführt, wenn dies die Kostengrenze der Instanz überschreiten würde.

Das folgende Video veranschaulicht den grundlegenden Workflow am Beispiel von Sessions:

Vollständige Details zu den TTL-Timern findest du im Leitfaden Maximale Ausführungszeit.

Nächste Schritte​

Empfehlungen