Dry-Run-Jobs

Ein Dry-Run-Job führt deine Arbeitslast über den IBM Quantum® Compute Service aus, ohne QPU-Zeit zu verbrauchen. Verwende einen Dry-Run-Job, um vor einem echten Lauf Folgendes zu tun:

• **Ermittle die Nutzung, die der Job auf der echten QPU verursachen würde.

• Validiere den Job. Quantum Compute prüft die Parameter des Jobs auf dieselbe Weise wie bei einem echten Job.

• Erhalte den Circuit-Timing-Plan, wenn du ihn anforderst, um den Job zu debuggen, bevor du ihn tatsächlich ausführst.

Anders als Dry-Run-Jobs läuft lokales Testen (Fake-Backends und Qiskit Aer) auf deinem eigenen Rechner und kann daher keine Nutzungswerte, keine serverseitige Validierung und keine Timing-Informationen des Dienstes liefern. Einen Vergleich der beiden Ansätze findest du unter Mock-Geräte im Vergleich zu Fake-Backends.

hinweis

• Für Dry-Run-Jobs ist qiskit-ibm-runtime v0.51.0 oder höher erforderlich.
• Dry-Run-Jobs sind in allen Regionen verfügbar und nur in den Plänen Flex, Premium und On-Prem nutzbar. In den Plänen Open und Pay-As-You-Go sind sie nicht verfügbar.

So funktioniert es

Um einen Dry-Run-Job auszuführen, übergib dry_run=True an die Methode run() des Primitives:

backend = service.backend("ibm_phoenix")
isa_circuit = pm.run(circuit)  # transpiled for ibm_phoenix
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()  # wait for completion
print(job.usage())

dry_run ist ein Argument der Methode run() (der Standardwert ist False), keine Laufzeitoption. Es steht allen Primitives zur Verfügung.

Ein Dry-Run-Job hat folgende Merkmale:

• Er läuft im IBM Quantum Compute Service in der Cloud, nicht auf deinem Rechner.

• Er verwendet die Kalibrierungsdaten der echten QPU, nicht nur einen Schnappschuss.

• Seine Ergebnisse behalten das erwartete Schema und folgen der erwarteten Form von Ergebnissen der echten QPU, enthalten aber zufällig erzeugte Mock-Daten. Es sind weder tatsächliche noch simulierte Messergebnisse, verwende sie also nicht, um die physikalische Korrektheit zu prüfen.

• Die Verarbeitung findet auf dem Server statt, daher wird der Job möglicherweise nicht sofort abgeschlossen.

Circuit-Größe, Shots und andere Limits sind dieselben wie bei jedem Job dieses Programms.

dry_run=True funktioniert auch, wenn das Backend bereits ein Mock-Gerät ist.

Die Nutzung auslesen

Die Nutzung eines abgeschlossenen Dry-Run-Jobs entspricht der Nutzung, die derselbe Job auf der echten QPU verursachen würde, außer in seltenen Fällen, in denen sich die Kalibrierungsdaten nach dem Dry-Run-Job und vor dem Job auf einer echten QPU erheblich ändern.

• job.usage() gibt die Nutzung in Sekunden zurück.

• job.metrics()["usage"] gibt dieselben Daten zusammen mit dem Nutzungsstatus zurück.

Die Nutzung durch Dry-Runs wird nicht berechnet, verbraucht nicht das Kontingent deines Plans und zählt nicht gegen Limits.

job.usage_estimation nicht mit Dry-Run-Jobs verwenden

Verwende job.usage_estimation nicht bei einem Dry-Run-Job. Verwende job.usage().

job.usage() gibt 0 zurück, bis die Nutzungsberechnung abgeschlossen ist. Warte daher, bis der Job beendet ist, bevor du den Wert ausliest.

Circuit-Timing-Plan

Um den Circuit-Timing-Plan anzufordern, verwende dieselbe Option wie bei einem echten Job. Alle Details findest du unter Circuit-Timing visualisieren.

Einschränkungen

• Nur Job- und Batch-Modus. Dry-Run-Jobs können nur im job mode und im batch mode ausgeführt werden.

• Nur Flex-, Premium- und On-Prem-Pläne. Dry-Run-Jobs sind in den Plänen Open und Pay-As-You-Go nicht verfügbar.

Mock-Geräte

Mock-Geräte sind die Implementierung hinter Dry-Run-Jobs. Dry-Run-Jobs blenden Mock-Geräte standardmäßig aus, du begegnest ihnen aber in diesen Fällen:

• Instanzen, die nur für den Zugriff auf Mock-Geräte konfiguriert sind. Beispiel: Wenn du service.backend("ibm_phoenix") verwendest, um einen Dry-Run-Job auf ibm_phoenix zu übermitteln, deine Instanz aber keinen Zugriff auf ibm_phoenix hat, erhältst du einen QiskitBackendNotFoundError. Wähle stattdessen das Mock-Gerät direkt mit service.backend("mock_phoenix") aus.

• Compute resources. Mock-Geräte sind auf der Seite Compute resources standardmäßig ausgeblendet. Die Tabelle auf der Seite hat eine Filteroption, um sie einzublenden, aber nur die Pläne Flex, Premium und On-Prem haben Zugriff auf Mock-Geräte.

• Workloads-Tabelle. Jobs von Mock-Geräten sind auf der Seite Workloads standardmäßig ausgeblendet. Die Tabelle hat eine Filteroption (das Trichter-Symbol), um sie anzuzeigen.

• Python-API. service.backends() und service.jobs() schließen Mock-Geräte aus, außer du rufst sie mit include_mocks=True auf. IBMBackend.is_mock zeigt an, ob ein Backend ein Mock-Gerät ist. service.least_busy() gibt nie ein Mock-Gerät zurück.

Mock-Geräte im Vergleich zu Fake-Backends

Die Namen ähneln sich, aber ein Mock-Gerät und ein Fake-Backend sind unterschiedliche Dinge. Ein Fake-Backend ist ein lokales Objekt in deiner Python-Umgebung. Ein Mock-Gerät ist eine Cloud-Ressource im IBM Quantum Compute Service.

	Mock-Gerät (zum Beispiel mock_phoenix)	Fake-Backend (zum Beispiel FakeManilaV2)
Was es ist	Ein Gerät im IBM Quantum Compute Service	Eine Python-Klasse in qiskit_ibm_runtime.fake_provider
Wo es läuft	In der Cloud, im Dienst	Lokal, auf deinem Rechner
Wie du es erhältst	service.backend("mock_phoenix") oder automatisch mit run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Konto und Instanz	Nur bestimmte Pläne (Flex, Premium oder On-Prem)	Alle Instanzen und Pläne
Kalibrierung	Live, entspricht jederzeit dem echten Gerät	Fester Schnappschuss, der mit dem installierten Paket ausgeliefert wird
Ergebnisse	Zufällige Daten mit dem erwarteten Schema. Keine Simulation	Verrauschte Simulation mit dem Rauschmodell des Schnappschusses
Physikalisch aussagekräftige Ergebnisse	Nein. Nie zur Prüfung der Korrektheit verwenden	Näherungsweise, im Rahmen des Rauschmodells
Nutzung wird gemeldet	Ja	Keine
Berechnet oder auf Plankontingent bzw. Limits angerechnet	Nein	Nein
Job-Validierung	Durch den Dienst, wie bei einem echten Job	Beschränkt auf das, was der Client prüft
Timing-Plan	Auf Anfrage verfügbar	Nicht verfügbar
Ausführungsmodi	Nur job mode und batch mode. Sessions sind blockiert	Session-Syntax wird akzeptiert, aber ignoriert (der lokale Modus kennt keine echten Sessions oder Batches)
Abschluss	Asynchron, auf dem Server	Läuft lokal und kehrt nach Abschluss zurück
Anzeige in der Plattform-Oberfläche und in API-Listen	Standardmäßig ausgeblendet (Compute resources, Workloads-Tabelle, backends(), jobs()). Zum Anzeigen aktivieren	Nie, weil nichts an den Dienst gesendet wird

So wählst du aus

• Um herauszufinden, wie viel Nutzung der Job verbrauchen wird oder ob der Dienst ihn akzeptiert, verwende einen Dry-Run-Job.

• Um herauszufinden, wie die Ausgabe aussehen könnte, oder um offline zu arbeiten, verwende ein Fake-Backend oder Aer.

• Um beides zu tun, iteriere mit einem Fake-Backend über Circuits und Ergebnisse und führe dann als letzte Prüfung vor der echten QPU einen Dry-Run aus.

Häufige Missverständnisse

• Ein Mock-Gerät ist kein Simulator. Seine Ausgabe ist zufällig, daher liefert das Sampling eines Bell-Circuits auf mock_phoenix keine Bell-Verteilung. Wenn du realistische verrauschte Ausgaben möchtest, verwende ein Fake-Backend.

• Ein Fake-Backend ist nicht das Live-Gerät. Seine Kalibrierung ist ein Schnappschuss und möglicherweise veraltet. Ein Mock-Gerät folgt der echten Kalibrierung, sodass transpilierte Circuits und das Timing dem entsprechen, was die QPU heute sieht.

• Keines von beiden läuft auf echter Hardware. Beide verbrauchen keine QPU-Zeit, aber nur ein Dry-Run-Job läuft über den Dienst.

• usage_estimation ist nicht die Dry-Run-Schätzung. Bei einem Dry-Run-Job gibt job.usage() die Sekunden an Nutzung zurück, die dir dein Job auf einer echten QPU berechnet würden.

Anwendungsfälle

Studierende und Kurse

Ein Administrator beschränkt eine Instanz über den QPU-Anpassungsschalter beim Erstellen oder Bearbeiten der Instanz ausschließlich auf Mock-Geräte. Studierende validieren dann ihre Payloads durchgängig, ohne echte QPU-Zeit oder RUs zu verbrauchen. Da die Instanz nur Zugriff auf Mock-Geräte hat, wählen Studierende das Backend über seinen Mock-Namen aus:

backend = service.backend("mock_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)

Projektplanung

Ein Team, das kurz vor dem Start eines Projekts steht, führt repräsentative Jobs als Dry-Run aus, um die vom Projekt benötigten RUs zu sehen, bevor es einen Plan oder ein Kontingent auswählt:

backend = service.backend("ibm_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()
print(job.usage()) 

Abschließende Prüfung vor dem Lauf auf einer echten QPU

Validiere die Parameter und prüfe den Timing-Plan mit dry_run=True, entferne dann das Argument und führe den Job auf der echten QPU aus. Sonst ändert sich nichts in deinem Code:

sampler = Sampler(mode=backend)

# Pre-flight check
job = sampler.run([isa_circuit], dry_run=True)
job.result()

# Real run - same code, without dry_run
job = sampler.run([isa_circuit])

Nächste Schritte

Empfehlungen

• Teste Programme auf deinem eigenen Rechner mit dem lokalen Testmodus.
• Erfahre, wie die Workload-Nutzung gemessen wird.
• Visualisiere den Circuit-Timing-Plan.
• Lerne Ressourceneinheiten und die verfügbaren Pläne kennen.