Dry-run завдання

Dry-run завдання виконує твоє навантаження через IBM Quantum® Compute Service без використання часу QPU. Використовуй dry-run завдання, щоб перед реальним запуском зробити таке:

• **Отримати використання, яке завдання потребувало б на реальному QPU.

• Перевірити завдання. Quantum Compute перевіряє параметри завдання так само, як і для реального завдання.

• Отримати розклад часу виконання схеми, якщо ти його запитаєш, щоб налагодити завдання до реального запуску.

На відміну від dry-run завдань, локальне тестування (фейкові бекенди та Qiskit Aer) виконується на твоєму власному комп'ютері, тому не може надати дані про використання, серверну валідацію чи інформацію про часові параметри сервісу. Щоб порівняти ці два підходи, див. Mock-пристрої та фейкові бекенди: порівняння.

примітка

• Для dry-run завдань потрібна qiskit-ibm-runtime версії v0.51.0 або новіша.
• Dry-run завдання доступні в усіх регіонах і лише в тарифних планах Flex, Premium і On-Prem. Вони недоступні в планах Open і Pay-As-You-Go.

Як це працює

Щоб запустити dry-run завдання, передай dry_run=True у метод run() примітива:

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 — це аргумент методу run() (за замовчуванням False), а не опція виконання. Він доступний для всіх примітивів.

Dry-run завдання має такі характеристики:

• Воно виконується в IBM Quantum Compute Service у хмарі, а не на твоєму комп'ютері.

• Воно використовує калібрувальні дані реального QPU, а не лише знімок.

• Його результати зберігають очікувану схему та відповідають очікуваній формі результатів реального QPU, але містять рандомізовані мок-дані. Це не фактичні й не змодельовані результати вимірювань, тому не використовуй їх для перевірки фізичної коректності.

• Обробка відбувається на сервері, тому завдання може завершитися не одразу.

Розмір схеми, кількість shots та інші обмеження такі самі, як і для будь-якого завдання цієї програми.

dry_run=True також працює, коли бекенд уже є mock-пристроєм.

Прочитай використання

Використання завершеного dry-run завдання — це використання, якого те саме завдання потребувало б на реальному QPU, окрім рідкісних випадків, коли калібрувальні дані суттєво змінюються після dry-run завдання й до завдання на реальному QPU.

• job.usage() повертає використання в секундах.

• job.metrics()["usage"] повертає ті самі дані разом зі статусом використання.

Використання dry-run не тарифікується, не споживає виділений ліміт твого плану і не враховується в жодних обмеженнях.

Не використовуй job.usage_estimation з dry-run завданнями

Не використовуй job.usage_estimation для dry-run завдання. Використовуй job.usage().

job.usage() повертає 0, доки обчислення використання не завершено, тому дочекайся завершення завдання, перш ніж його читати.

Розклад часу виконання схеми

Щоб запросити розклад часу виконання схеми, використовуй ту саму опцію, що й для реального завдання. Докладніше див. Візуалізація часу виконання схеми.

Обмеження

• Лише режими job і batch. Dry-run завдання можна виконувати лише в job mode і batch mode.

• Лише плани Flex, Premium і On-Prem. Dry-run завдання недоступні в планах Open і Pay-As-You-Go.

Mock-пристрої

Mock-пристрої — це реалізація, що стоїть за dry-run завданнями. Dry-run завдання за замовчуванням приховують mock-пристрої, але ти зустрінеш їх у таких випадках:

• Екземпляри, налаштовані на доступ лише до mock-пристроїв. Приклад: якщо ти використовуєш service.backend("ibm_phoenix"), щоб надіслати dry-run завдання на ibm_phoenix, але твій екземпляр не має доступу до ibm_phoenix, ти отримаєш QiskitBackendNotFoundError. Натомість обери mock-пристрій напряму через service.backend("mock_phoenix").

• Обчислювальні ресурси. Mock-пристрої за замовчуванням приховані на сторінці Compute resources. Таблиця на сторінці має опцію фільтра, щоб їх включити, але доступ до mock-пристроїв мають лише плани Flex, Premium і On-Prem.

• Таблиця Workloads. Завдання з mock-пристроїв за замовчуванням приховані на сторінці Workloads. Таблиця має опцію фільтра (піктограма воронки), щоб їх показати.

• Python API. service.backends() і service.jobs() виключають mock-пристрої, якщо не викликати їх з include_mocks=True. IBMBackend.is_mock вказує, чи є бекенд mock-пристроєм. service.least_busy() ніколи не повертає mock-пристрій.

Mock-пристрої та фейкові бекенди: порівняння

Назви схожі, але mock-пристрій і фейковий бекенд — це різні речі. Фейковий бекенд — це локальний об'єкт у твоєму середовищі Python. Mock-пристрій — це хмарний ресурс в IBM Quantum Compute Service.

	Mock-пристрій (наприклад, mock_phoenix)	Фейковий бекенд (наприклад, FakeManilaV2)
Що це	Пристрій в IBM Quantum Compute Service	Клас Python у qiskit_ibm_runtime.fake_provider
Де виконується	У хмарі, в сервісі	Локально, на твоєму комп'ютері
Як його отримати	service.backend("mock_phoenix") або автоматично через run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Обліковий запис та екземпляр	Лише певні плани (Flex, Premium або On-Prem)	Усі екземпляри та плани
Калібрування	Актуальне, у будь-який момент відповідає реальному пристрою	Фіксований знімок, що постачається з встановленим пакетом
Результати	Рандомізовані дані з очікуваною схемою. Не симуляція	Шумна симуляція з моделлю шуму зі знімка
Фізично змістовні результати	Ні. Ніколи не використовуй їх для перевірки коректності	Приблизно, в межах моделі шуму
Повідомляється використання	Так	Ні
Тарифікується або враховується в ліміті плану чи обмеженнях	Ні	Ні
Валідація завдання	Виконується сервісом, як для реального завдання	Обмежується тим, що перевіряє клієнт
Розклад часу виконання	Доступний на запит	Недоступний
Режими виконання	Лише режими job і batch. Сесії заблоковано	Синтаксис сесій приймається, але ігнорується (локальний режим не має справжніх сесій чи batch)
Завершення	Асинхронне, на сервері	Виконується локально і повертається після завершення
Відображення в інтерфейсі платформи та списках API	За замовчуванням приховано (Compute resources, таблиця Workloads, backends(), jobs()). Показ вмикається за бажанням	Ніколи, адже нічого не надсилається до сервісу

Як обрати

• Щоб дізнатися, скільки використання споживе завдання або чи прийме його сервіс, використовуй dry-run завдання.

• Щоб дізнатися, як може виглядати результат, або щоб працювати офлайн, використовуй фейковий бекенд або Aer.

• Щоб зробити і те, і те, ітеруй схеми та результати з фейковим бекендом, а потім зроби dry-run як останню перевірку перед реальним QPU.

Типові джерела плутанини

• Mock-пристрій — не симулятор. Його вивід випадковий, тому семплінг схеми Белла на mock_phoenix не повертає розподіл Белла. Якщо потрібен реалістичний шумний вивід, використовуй фейковий бекенд.

• Фейковий бекенд — не живий пристрій. Його калібрування — це знімок, який може бути застарілим. Mock-пристрій відстежує реальне калібрування, тому транспільовані схеми та часові параметри відповідають тому, що QPU бачить сьогодні.

• Жоден із них не виконується на реальному обладнанні. Жоден не споживає час QPU, але лише dry-run завдання проходить через сервіс.

• usage_estimation — не оцінка dry-run. Для dry-run завдання job.usage() повертає секунди використання, які було б стягнуто за твоє завдання на реальному QPU.

Сценарії використання

Студенти та курси

Адміністратор обмежує екземпляр лише mock-пристроями за допомогою перемикача кастомізації QPU під час створення або редагування екземпляра. Тоді студенти можуть наскрізно перевіряти свої payload-и, не витрачаючи реальний час QPU чи RU. Оскільки екземпляр має доступ лише до mock-пристроїв, студенти обирають бекенд за його mock-назвою:

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

Планування проєкту

Команда, що збирається розпочати проєкт, виконує dry-run репрезентативних завдань, щоб побачити, скільки RU потребує проєкт, перш ніж обрати план чи виділений ліміт:

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

Остаточна перевірка перед запуском на реальному QPU

Перевір параметри та проаналізуй розклад часу виконання за допомогою dry_run=True, потім прибери аргумент і запусти на реальному QPU. Більше нічого в коді не змінюється:

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])

Наступні кроки

Рекомендації

• Тестуй програми на власному комп'ютері за допомогою Local testing mode.
• Дізнайся, як вимірюється використання робочого навантаження.
• Візуалізуй розклад часу виконання схеми.
• Ознайомся з одиницями ресурсів і доступними планами.