Job-Limits
Wenn du einen Job an eine IBM® QPU sendest, wird er zunächst an den Job-Validierungsdienst weitergeleitet. Dieser Dienst stellt sicher, dass der Job auf der QPU ausgeführt werden kann, damit du nicht warten musst, bis er die Warteschlange durchläuft und dann fehlschlägt. Zu diesen Prüfungen gehört die Durchsetzung der folgend beschriebenen Limits. Werden diese Limits überschritten, kann der Workload nicht vom Quantum-Software-Stack verarbeitet werden und schlägt in der Regel fehl.
- Bestimmte Primitive-Optionen vergrößern den Circuit. Die beschriebenen Limits werden nach der erwarteten Vergrößerung des Circuits geprüft. Im Einzelnen vergrößern folgende Optionen den Circuit:
- Dynamical Decoupling und Gate-Folding ZNE fügen zusätzliche Gates ein, die bei den Anweisungen für das Limit Maximale Anzahl von Low-Level-Anweisungen pro Qubit berücksichtigt werden.
- Gate-Folding ZNE fügt zusätzliche Zwei-Qubit-Gates ein, die für das Limit Maximale Anzahl von Zwei-Qubit-Gates pro Job relevant sind. Die Anzahl der Zwei-Qubit-Gates wird mit der Summe der im Gate-Folding ZNE angeforderten Rauschfaktoren multipliziert.
- Die von den
backend.configuration()-Feldernmax_shotsundmax_experimentsgemeldeten Limits sind nicht mehr relevant oder werden nicht mehr durchgesetzt. Diese Felder werden in naher Zukunft entfernt. - Diese Limits gelten pro Job, nicht pro Primitive Unified Bloc (PUB).
Maximale Ausführungen
Für Sampler-Jobs sind maximal 10 Millionen Ausführungen zulässig (Estimator-Jobs können in kleinere Teiljobs aufgeteilt werden, weshalb dieses Limit dort nicht gilt). Die Anzahl der Ausführungen ergibt sich aus der Anzahl der Circuits multipliziert mit der Anzahl der Shots, wobei es sich um die nach dem Broadcasting der PUB-Elemente generierten Circuits handelt.
Wenn du beispielsweise ein PUB mit einem Circuit und Parametern mit der Form (4, 1) hast, ergeben sich daraus 4 Circuits. Bei 2.000 angeforderten Shots beträgt die Gesamtzahl der Ausführungen .
Beachte: Wenn du Pauli-Twirling in deinem Sampler-Job aktivierst, basiert die Gesamtzahl der Shots auf den Werten num_randomizations und shots_per_randomization. Weitere Details findest du unter TwirlingOptions.
Maximale Anzahl von Low-Level-Anweisungen pro Qubit
Der Dienst erlaubt bis zu 26,8 Millionen Control-System-Anweisungen pro Qubit. Dadurch wird sichergestellt, dass die Benutzer-Circuits in den Anweisungsspeicher des Control Systems passen. Das folgende Beispiel zeigt, wie ein Circuit transpiliert wird und wie die Anzahl der einzelnen Anweisungen gezählt werden kann.
Die folgende Tabelle beschreibt, wie das System Instruction Set Architecture (ISA)-Circuit-Anweisungen bei der Berechnung dieses Limits in Control-System-Anweisungen übersetzt.
| Anweisung | Anzahl |
|---|---|
rz | 1 |
delay | 1 |
sx | 2 |
x | 2 |
cx | 5 |
cz | 5 |
ecr | 5 |
measure | 10 |
reset | 17 |
init | 50 |
Diese Tabelle gibt die bei der Validierung verwendete Heuristik wieder und spiegelt nicht die genaue Anzahl der zur Implementierung einer Operation verwendeten Anweisungen wider.
Beispiel
Definiere Circuits, transpiliere sie und ermittle, wie viele Gates ausgeführt werden.
from qiskit import QuantumCircuit
from qiskit.transpiler import generate_preset_pass_manager
from qiskit_ibm_runtime import QiskitRuntimeService
num_qubits = 50
ghz = QuantumCircuit(num_qubits)
ghz.h(range(num_qubits))
ghz.cx(0, range(1, num_qubits))
op_counts = ghz.count_ops()
# Choose the least busy backend
service = QiskitRuntimeService()
backend = service.least_busy(operational=True, simulator=False)
pm = generate_preset_pass_manager(optimization_level=3, backend=backend)
transpiled_ghz = pm.run(ghz)
op_counts = transpiled_ghz.count_ops()
print(f"Post-Transpilation gates: {op_counts}")
Vollständige Details findest du unter Transpilieren gegen benutzerdefinierte Backends.
Maximale Anzahl von Ein- und Zwei-Qubit-Gates pro Circuit
Die maximale Anzahl von Einqubit-Gates ist wie folgt:
- 30 Millionen RZ-Gates
- 20 Millionen SX-Gates
Die maximale Anzahl von Zwei-Qubit-Gates pro Circuit beträgt fünf Millionen. Dadurch wird sichergestellt, dass der Job innerhalb der Speichergrenzen des Low-Level-Software-Stacks verarbeitet werden kann.