Einführung in die Ausführungsmodi von Quantum Compute

Als der IBM Quantum Compute Service 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 mode

Eine einzelne Primitive-Anfrage, 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 in job mode zu laufen, gib mode=backend an, wenn du ein Primitive instanziierst. Siehe Estimator-Beispiele und Sampler-Beispiele für die Verwendung.

Batch mode

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. Mit batch mode 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.

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 in batch mode 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 mode

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. Die Kostenfunktion im Bild gehört zu einem variationalen Quantenalgorithmus, der auf dem lokalen Rechner des Benutzers läuft.

Um in session mode 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 bzw. die Session den 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

• Führe einen Job im batch mode aus.
• Führe einen Job im session mode aus.
• Wähle den richtigen Ausführungsmodus.
• Lies die FAQs zu Ausführungsmodi.