Обмеження завдань
Коли ти надсилаєш завдання на IBM® QPU, воно спочатку потрапляє до служби валідації завдань. Ця служба намагається переконатися, що завдання зможе виконатися на QPU, щоб тобі не довелося чекат и в черзі, а потім отримати помилку. Ці перевірки включають дотримання описаних нижче обмежень. Якщо ці обмеження перевищено, навантаження не може бути оброблено квантовим програмним стеком і, як правило, завершиться помилкою.
- Певні параметри примітивів збільшують розмір схеми. Описані обмеження перевіряються після очікуваного збільшення розміру схеми. Зокрема, ці параметри збільшують розмір схеми:
- Динамічне роз'єднання (dynamical decoupling) і ZNE зі складанням гейтів (gate-folding ZNE) додають додаткові гейти, які враховуються в інструкціях для обмеження Максимальна кількість низькорівневих інструкцій на кубіт.
- Gate-folding ZNE додає додаткові двокубітні гейти, що стосуються обмеження Максимальна кількість двокубітних гейтів на завдання. Кількість двокубітних гейтів множиться на суму коефіцієнтів шуму, запитаних у gate-folding ZNE.
- Обмеження, що повідомляються полями
max_shotsіmax_experimentsметодуbackend.configuration(), більше не актуальні й не застосовуються. Ці поля будуть видалені найближчим часом. - Ці обмеження стосуються завдання в цілому, а не окремого Primitive Unified Bloc (PUB).
Максимальна кількість виконань
Для завдань Sampler дозволено не більше 10 мільйонів виконань (завдання Estimator можуть бути розбиті на менші підзавдання, тому це обмеження на них не поширюється). Кількість виконань — це кількість схем, помножена на кількість знімків (shots), де схеми — це ті, що генеруються після широкомовної передачі (broadcasting) елементів PUB.
Наприклад, якщо у тебе є PUB з однією схемою та параметрами з формою (4, 1), це дасть 4 схеми. Якщо ти запросив(ла) 2 000 знімків, то загальна кількість виконань становить .
Зверни увагу, що якщо ти увімкнеш Pauli-twirling у своєму завданні Sampler, загальна кількість знімків визначається значеннями num_randomizations і shots_per_randomization. Детальніше дивися в TwirlingOptions.
Максимальна кількість низькорівневих інструкцій на кубіт
Служба дозволяє до 26,8 мільйона інструкцій керуючої системи на кубіт. Це гарантує, що користувацькі схеми вміщуються в пам'ять інструкцій керуючої системи. Приклад нижче показує, як транспілювати схему та підрахувати кількість кожної інструкції.
У наступній таблиці описано, як система перетворює інструкції схеми в архітектурі набору інструкцій (ISA) на інструкції керуючої системи під час обчислення цього обмеження.
| Інструкція | Кількість |
|---|---|
rz | 1 |
delay | 1 |
sx | 2 |
x | 2 |
cx | 5 |
cz | 5 |
ecr | 5 |
measure | 10 |
reset | 17 |
init | 50 |
Ця таблиця відображає евристику, що використовується під час валідації, і не відображає точну кількість інструкцій, необхідних для реалізації операції.
Приклад
Визнач схеми, транспілюй їх і отримай кількість гейтів, які будуть виконані.
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}")
Повні деталі дивися в розділі Транспіляція під нестандартні Backend.
Максимальна кількість однокубітних і двокубітних гейтів на схему
Максимальна кількість однокубітних гейтів:
- 30 мільйонів RZ-гейтів
- 20 мільйонів SX-гейтів
Максимальна кількість двокубітних гейтів на схему — п'ять мільйонів. Це гарантує, що завдання можна обробити в межах пам'яті низькорівневого програмного стеку.