Перейти до основного вмісту

Використання робочого навантаження

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

  • Використання сесії — це астрономічний час активності сесії. Дивись Тривалість сесії для отримання додаткової інформації про переходи між станами сесії.
  • Використання пакету — це сума квантового часу (часу, витраченого комплексом QPU на обробку твоїх завдань) усіх завдань у пакеті.
  • Використання одиночного завдання — це квантовий час, витрачений на обробку цього завдання.

Зверни увагу, що провалені або скасовані завдання за певних обставин зараховуються до твого використання — дивись розділ Провалені та скасовані завдання для деталей.

Для користувачів платного плану використання визначає вартість робочого навантаження. Дивись Управління витратами для деталей.

Використання для провалених та скасованих завдань​

Коли завдання провалене або скасоване, зафіксоване використання визначається таким чином:

  • Режим завдання або пакету: зафіксоване використання — це час блокування QPU для виконання твого робочого навантаження до моменту провалу або скасування. Тому, якщо провал або скасування стались до блокування, зафіксоване використання дорівнює нулю. В іншому випадку зафіксоване використання робочого навантаження відповідає обсягу використання до того, як воно було провалене або скасоване. Отже, деякі провалені завдання не відображаються у твоєму зафіксованому використанні, а інші — відображаються.

  • Режим сесії: зафіксоване використання — це астрономічний час активності сесії, незалежно від кількості завдань, що провалились або були скасовані.

Запит фактичного використання робочого навантаження​

Після завершення робочого навантаження є кілька способів переглянути його фактичне використання:

  • Запусти batch.usage() або session.usage() у qiskit-ibm-runtime версії 0.30 або новішої. Якщо використовується старіша версія qiskit-ibm-runtime (>= 0.23 та < 0.30), використання можна знайти в session.details()["usage_time"] та batch.details()["usage_time"].
  • Використай GET /sessions/{id}, щоб переглянути використання для конкретного пакету або сесії.
  • Використай GET /jobs/{id}, щоб переглянути використання для одного завдання.

Перегляд використання екземпляра​

Ти можеш переглянути використання екземпляра на сторінці Instances або, для тих, хто має відповідні повноваження, на сторінці Analytics. Зверни увагу, що сторінки можуть показувати різні показники використання, оскільки вони обчислюють його по-різному.

Сторінка Instances показує використання в реальному часі за останні 28 днів (ковзне вікно), до поточного часу поточного дня. Використання на сторінці Analytics перераховується щогодини та включає останні 28 повних днів; тобто показує використання від 00:00 28 днів тому до сьогодні, на початку поточної години.

Оцінка використання перед відправкою завдання​

Хоча отримати точну локальну оцінку складно через додаткові операції для придушення та пом'якшення помилок, ти можеш скористатись цією базовою формулою для наближеної оцінки використання:

<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>

  • <per sub-job overhead> — це накладні витрати приблизно 2 секунди на підзавдання. Включає такі операції, як завантаження корисного навантаження в керуючу електроніку. Твоє завдання з примітивом може бути розбите на кілька підзавдань, якщо воно надто велике для одночасної обробки рушієм виконання.
  • rep_delay — це налаштовувана користувачем опція; її стандартне значення задається через backend.default_rep_delay, що на більшості Backend-ів IBM Quantum становить 250 мікросекунд. Зверни увагу, що зменшення rep_delay скорочує загальний час виконання на QPU, але ціною збільшення рівня помилок підготовки стану; дивись посібник Виконання з динамічною частотою повторень для отримання додаткової інформації.
  • <circuit length> — це загальна довжина інструкцій. Кожна інструкція займає різну кількість часу на QPU, тому загальна довжина варіюється від Circuit до Circuit. Наприклад, вимірювання може займати в 56 разів більше часу, ніж Gate x. Для визначення точної тривалості кожної інструкції можна використовувати backend.target[<instruction>][<qubit>].duration. Типова довжина Circuit, ймовірно, становить від 50 до 100 мікросекунд. Якщо ти використовуєш техніки придушення або пом'якшення помилок з примітивами, до твого Circuit можуть бути додані додаткові інструкції, що збільшить загальну довжину Circuit.
    примітка

    Експериментальна опція scheduler_timing повертає загальний час Circuit, але це НЕ є часом, що використовується для виставлення рахунків.

  • <num executions> — це загальна кількість Circuit, помножена на кількість вимірювань (shots), де Circuit — це ті, що генеруються після трансляції елементів PUB.
    • Якщо ти використовуєш техніки пом'якшення помилок з примітивами, у процесі пом'якшення можуть запускатись додаткові Circuit, що збільшить загальну кількість виконань. Крім того, просунуті техніки пом'якшення помилок, такі як PEA і PEC, мають значно вищі накладні витрати, оскільки вимагають запуску Circuit для навчання на шумі.
    • Estimator групує квантово-побітово комутуючі спостережувані, що зменшує кількість виконань.

Якщо ти не використовуєш жодних просунутих технік пом'якшення помилок або власного rep_delay, для швидкої оцінки можна скористатись формулою 2+0.00035*<num executions>.

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

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