Einführung in verwaltete Workflows

Verfügbarkeit des Tarifs

Qiskit Functions und verwaltete Workflows sind Beta-Funktionen, die nur Nutzern der Tarife Premium, Flex und On-Prem (über die IBM Quantum® Platform API) zur Verfügung stehen.

Verwaltete Workflows führen deinen eigenen Python-Code auf klassischer Rechenleistung aus, die IBM Quantum Platform für dich verwaltet. Verwende verwaltete Workflows, um hybride Quanten-klassische Workflows, groß angelegte Diagonalisierung und lang laufende parallele Aufgaben auszuführen, ohne Recheninfrastruktur oder Speicher verwalten zu müssen.

Wann du einen verwalteten Workflow verwenden solltest

Verwende einen verwalteten Workflow, wenn keine vorgefertigte Catalog Function deine Aufgabe abdeckt oder wenn du deine eigene Methode als wiederverwendbare Funktion paketieren möchtest. Verwaltete Workflows eignen sich gut, wenn du Folgendes tun möchtest:

• Lange Jobs in der Cloud ausführen. Ein verwalteter Workflow läuft weiter, wenn du deinen Laptop schließt, und du kannst dich später wieder mit dem Job verbinden.

• Knoten mit viel Speicher und GPUs nutzen. Wähle die Speicher-, CPU- und GPU-Ressourcen, die die Arbeitslast benötigt.

• Aufgaben parallel ausführen. Starte viele Single-Node-Jobs gleichzeitig.

Du stellst den Workflow-Code, seine Abhängigkeiten und die unterstützten Compute-Größen bereit. Verwaltete Workflows führen den Workflow auf von IBM® verwalteter Rechenleistung in einer vorgefertigten Umgebung aus, in der deine Pakete installiert sind, und stellen Cloud-Speicher für die Dateien bereit, die der Workflow liest und schreibt.

So funktionieren verwaltete Workflows

Du lädst einen Workflow einmal hoch und führst so viele Jobs aus, wie du brauchst. Jeder Job funktioniert auf folgende Weise:

• Der Job startet in einer neuen Umgebung mit einer leeren lokalen Festplatte. Verwaltete Workflows fahren die Umgebung herunter, nachdem der Job beendet ist.

• Der Job läuft auf einer der Compute-Größen, die du beim Hochladen des Workflows definierst. Du kannst für jeden Lauf eine andere Größe wählen.

• Der Job kann den Dateispeicher des Workflows lesen und beschreiben. Dateien im Dateispeicher bleiben erhalten, nachdem der Job beendet ist.

Weil jeder Job mit einer leeren lokalen Festplatte startet, findet ein späterer Job nur die Dateien, die ein früherer Job im Dateispeicher gespeichert hat.

Lebenszyklus eines Laufs

Jeder Job läuft asynchron bis zu 24 Stunden. Du kannst bis zu 50 aktive Jobs gleichzeitig haben, wenn deine Instanz über genügend Kontingent verfügt.

Die folgende Tabelle beschreibt jede Phase im Diagramm und den Job-Status, den du während dieser Phase siehst:

Phase	Was passiert	Job-Status
Upload	Du lädst den Code, die Abhängigkeiten und die Größen des Workflows hoch. Der Workflow lehnt einen ungültigen Upload ab, bevor ein Job läuft.	Keiner (noch kein Job)
Warteschlange	Du rufst run() auf. Der Workflow prüft, ob deine Instanz über genügend Kontingent verfügt, und plant den Job ein, sobald Rechenleistung verfügbar ist.	QUEUED
Start	Der Workflow erstellt eine Umgebung mit dem Compute-Profil, das du ausgewählt hast.	INITIALIZING
Ausführung	Der Entrypoint deines Workflows läuft. Der Entrypoint kann seinen Fortschritt mit update_status() melden, und du kannst seine Logs während der Ausführung mit logs() lesen.	RUNNING oder eine von dir gesetzte Phase, zum Beispiel RUNNING: WAITING_FOR_QPU
Ergebnis	Der Job endet, und der Workflow fährt seine Umgebung herunter, behält aber das Ergebnis und die Logs.	DONE, ERROR oder CANCELED

Worauf ein laufender Job zugreifen kann

Jeder Job läuft in einer isolierten Umgebung. Das folgende Diagramm und die Tabelle zeigen die Ressourcen, die ein laufender Job verwenden kann.

Ressource	Was der Job verwenden kann
Compute	Die CPU, der Speicher und die GPUs des Compute-Profils, das du für den Job ausgewählt hast.
Code und Pakete	Die Dateien, die du mit dem Workflow hochgeladen hast, und die unterstützten Pakete, die in der Umgebung installiert sind.
Argumente	Die Argumente, die du an run() übergeben hast. Lies sie mit get_arguments().
QPU-Zugriff	Die Anmeldedaten und die Instanz, mit denen du run() aufgerufen hast. QPU-Jobs, die der Workflow einreicht, laufen auf deiner Instanz und zählen zu deiner Nutzung.
Ausgaben	Ein Ergebnis, das der Job mit save_result() speichert, Logs, die der Job ausgibt, und Statusaktualisierungen, die der Job mit update_status() setzt.
Dateispeicher	Dateien, die alle deine Läufe des Workflows gemeinsam nutzen. Dateien bleiben im Speicher, nachdem der Job beendet ist.
Internet	Kein Zugriff. Ein Job kann keine ausgehenden Verbindungen aufbauen. Deklariere Pakete beim Hochladen des Workflows und stelle Daten als Argumente oder Dateien bereit.

Sicherheit und Isolation

Verwaltete Workflows isolieren jeden Job von anderen Jobs und beschränken die Rechte des Codes, der darin läuft. Die Zugriffsgrenzen in der vorangehenden Tabelle sind Teil dieser Isolation. Verwaltete Workflows wenden außerdem die folgenden Schutzmaßnahmen an:

• Job-Isolation. In der Umgebung deines Jobs läuft kein anderer Job. Das schließt Jobs anderer Nutzer und deine eigenen gleichzeitig laufenden Jobs ein.

• Ergebnisse, Logs und Speicher. Nur der Nutzer, der einen Job ausgeführt hat, kann seine Ergebnisse und Logs lesen.

• Anmeldedaten. Verwaltete Workflows verschlüsseln die Anmeldedaten, die ein Job verwendet, einschließlich deines API-Tokens, wenn sie diese speichern. Dein Workflow-Code kann diese Anmeldedaten lesen, während der Job läuft.

• Rechte. Verwaltete Workflows entfernen Rechte auf Administratorebene aus der Umgebung, bevor dein Entrypoint startet.

Vergleich mit lokalem HPC

Verwaltete Workflows unterscheiden sich von einem lokalen HPC-Cluster darin, wie du Rechenzeit erhältst, Software einrichtest und Jobs einreichst. Die folgende Tabelle vergleicht gängige Aufgaben.

Aufgabe	Lokaler HPC-Cluster	Verwaltete Workflows
Rechenzeit erhalten	Beantrage eine Zuteilung oder eine Reservierung beim Cluster-Administrator.	Verwende das Kontingent deiner IBM Quantum-Instanz. Der Workflow stellt jeden Job in die Warteschlange, wenn du run() aufrufst.
Auf das System zugreifen	Verbinde dich per SSH mit einem Login-Knoten.	Verwende den Python-Client auf deinem lokalen Computer. Verwaltete Workflows bieten keinen Login-Knoten.
Software installieren	Software bauen, Module laden oder einen Administrator bitten, Pakete zu installieren.	Verwende die unterstützten Pakete, die in jeder Umgebung installiert sind, oder lade Wheels für andere Pakete hoch.
Einen Job einreichen	Schreibe ein Batch-Skript und reiche es beim Scheduler ein.	Rufe run() mit den Job-Argumenten auf.
Ressourcen anfordern	Fordere Knoten, CPUs, Speicher und GPUs an.	Wähle eine der Compute-Größen, die für den Workflow definiert sind. Jeder Job läuft auf einem einzelnen Knoten.
Einen Parameter-Sweep ausführen	Reiche ein Job-Array ein.	Rufe run() einmal für jeden Satz von Argumenten auf.
Gemeinsame Dateien speichern	Schreibe in ein gemeinsames Scratch-Dateisystem.	Schreibe in den Dateispeicher des Workflows.
Laufzeit begrenzen	Lege ein Wall-Time-Limit fest.	Der Workflow bricht einen Job nach 24 Stunden ab.
Lange Jobs mit Checkpoints sichern	Schreibe Checkpoints in den Scratch-Speicher.	Speichere Zwischenergebnisse im Dateispeicher.
Einen fehlgeschlagenen Job erneut ausführen	Reiche den Job erneut ein.	Rufe run() erneut auf. Der Workflow wiederholt fehlgeschlagene Jobs nicht automatisch.
Jobs überwachen	Prüfe die Warteschlange und die Logdateien vom Login-Knoten aus.	Prüfe den Status, die Logs und das Ergebnis jedes Jobs aus deiner lokalen Python-Sitzung.

Nächste Schritte

Empfehlungen

• Installiere die Client-Pakete und authentifiziere dich.
• Stelle deinen ersten verwalteten Workflow bereit, um einen Workflow hochzuladen, auszuführen und sein Ergebnis abzurufen.