Перейти до основного вмісту
Цей проєкт у бета-версії. Знайшов(-ла) помилку? Відкрити issue на GitHub. Є запитання чи ідея? Запитати в Discussions — будемо раді твоєму відгуку!
Яка якість перекладу на цій сторінці?

Вступ до кермованих робочих процесів

Доступність за планом

Qiskit Functions і кероване виконання робочих процесів є бета-функціями, доступними лише користувачам планів Premium, Flex та On-Prem (через API IBM Quantum® Platform).

Керовані робочі процеси запускають твій власний код Python на класичних обчисленнях, якими для тебе керує IBM Quantum Platform. Використовуй керовані робочі процеси для запуску гібридних квантово-класичних робочих процесів, великомасштабної діагоналізації та тривалих паралельних задач без керування обчислювальною інфраструктурою чи сховищем.

Коли використовувати кероване виконання робочого процесу​

Використовуй кероване виконання робочого процесу, коли жодна готова Catalog Function не покриває твоє завдання або коли хочеш упакувати власний метод як функцію для повторного використання. Керовані робочі процеси добре підходять, коли ти хочеш зробити таке:

  • Запускати тривалі завдання в хмарі. Кероване виконання робочого процесу триває, коли ти закриваєш ноутбук, а до завдання можна повернутися пізніше.

  • Використовувати вузли з великим обсягом пам'яті та GPU. Обирай ресурси пам'яті, CPU і GPU, потрібні для навантаження.

  • Запускати задачі паралельно. Запускай багато однонодових завдань одночасно.

Ти надаєш код робочого процесу, його залежності та розміри обчислень, які він підтримує. Керовані робочі процеси запускають робочий процес на обчисленнях під керуванням IBM® у готовому середовищі з установленими твоїми пакетами й надають хмарне сховище для файлів, які робочий процес читає та записує.

Як працюють керовані робочі процеси​

Ти завантажуєш робочий процес один раз і запускаєш стільки завдань, скільки потрібно. Кожне завдання працює таким чином:

  • Завдання починається в новому середовищі з порожнім локальним диском. Керовані робочі процеси вимикають середовище після завершення завдання.

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

  • Завдання може читати й записувати файлове сховище робочого процесу. Файли у файловому сховищі залишаються після завершення завдання.

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

Життєвий цикл запуску​

Кожне завдання виконується асинхронно до 24 годин. Ти можеш мати до 50 активних завдань одночасно, якщо твій екземпляр має достатню квоту.

From your Python session, you call upload() one time to upload the workflow's code, packages, and compute profiles. No job exists yet. Each call to run(args) creates a job that moves through these stages: Queue, where it waits for allocation with status QUEUED; Start, where the managed workflow creates the environment with status INITIALIZING; Running, where your code can optionally set stages with update_status(): Mapping (RUNNING: MAPPING), Optimizing (RUNNING: OPTIMIZING_FOR_HARDWARE), Waiting for QPU (RUNNING: WAITING_FOR_QPU), Executing QPU (RUNNING: EXECUTING_QPU), and Post-processing (RUNNING: POST_PROCESSING); and Result, where the environment shuts down with status DONE, ERROR, or CANCELED. While running, the job reads and writes workflow file storage, which exists outside the job, is shared by all runs, and persists before and after each job. From your session, you can read status() from Queue onward, logs() from Running onward, and result() after the job reaches Result. All three remain available after the job ends.

У таблиці нижче описано кожен етап на діаграмі та статус завдання, який ти бачиш на цьому етапі:

ЕтапЩо відбуваєтьсяСтатус завдання
ЗавантаженняТи завантажуєш код робочого процесу, залежності та розміри. Робочий процес відхиляє недійсне завантаження до запуску будь-якого завдання.Немає (завдання ще немає)
ЧергаТи викликаєш run(). Робочий процес перевіряє, чи має твій екземпляр достатню квоту, і планує завдання, коли обчислення доступні.QUEUED
СтартРобочий процес створює середовище з вибраним тобою профілем обчислень.INITIALIZING
ВиконанняВиконується точка входу твого робочого процесу. Точка входу може повідомляти про свій прогрес за допомогою update_status(), а її логи ти можеш читати через logs() під час виконання.RUNNING або етап, який ти встановив, наприклад RUNNING: WAITING_FOR_QPU
РезультатЗавдання завершується, і робочий процес вимикає своє середовище, зберігаючи результат та логи.DONE, ERROR або CANCELED

До чого має доступ завдання, що виконується​

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

You call run() with arguments from your Python session and receive status, logs, and the result. Inside the managed workflow, each run executes in an isolated job environment with access to its compute (CPU, RAM, and optionally GPU), your code and packages, and its arguments. The job produces outputs with save_result(), logs, and update_status(), and submits QPU jobs that run on your instance. File storage and your instance, which provides access and cost management, are shared across all managed workflow jobs and persist after the job ends. The job has no internet access.

РесурсЩо може використовувати завдання
ОбчисленняCPU, пам'ять і GPU профілю обчислень, який ти вибрав для завдання.
Код і пакетиФайли, які ти завантажив разом із робочим процесом, та підтримувані пакети, установлені в середовищі.
АргументиАргументи, які ти передав у run(). Читай їх через get_arguments().
Доступ до QPUОблікові дані та екземпляр, які ти використав для виклику run(). Завдання QPU, які надсилає робочий процес, виконуються на твоєму екземплярі та зараховуються до твого використання.
Вихідні даніРезультат, який завдання зберігає через save_result(), логи, які завдання виводить, та оновлення статусу, які завдання встановлює через update_status().
Файлове сховищеФайли, спільні для всіх твоїх запусків робочого процесу. Файли залишаються у сховищі після завершення завдання.
ІнтернетДоступу немає. Завдання не може встановлювати вихідні з'єднання. Оголошуй пакети під час завантаження робочого процесу, а дані надавай як аргументи або файли.

Безпека та ізоляція​

Керовані робочі процеси ізолюють кожне завдання від інших завдань і обмежують привілеї коду, що в ньому виконується. Межі доступу в попередній таблиці є частиною цієї ізоляції. Керовані робочі процеси також застосовують такі захисти:

  • Ізоляція завдань. У середовищі твого завдання не виконується жодне інше завдання. Це стосується завдань інших користувачів і твоїх власних завдань, що виконуються одночасно.

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

  • Облікові дані. Керовані робочі процеси шифрують облікові дані, які використовує завдання, зокрема твій API-токен, під час їх зберігання. Код твого робочого процесу може читати ці облікові дані, поки виконується завдання.

  • Привілеї. Керовані робочі процеси знімають привілеї рівня адміністратора із середовища до запуску твоєї точки входу.

Порівняння з локальним HPC​

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

ЗадачаЛокальний HPC-кластерКеровані робочі процеси
Отримання обчислювального часуЗапит на виділення або резервування в адміністратора кластера.Використовуй квоту свого екземпляра IBM Quantum. Робочий процес ставить кожне завдання в чергу, коли ти викликаєш run().
Доступ до системиПідключення до вузла входу через SSH.Використовуй клієнт Python на локальному комп'ютері. Керовані робочі процеси не надають вузла входу.
Встановлення програмного забезпеченняЗбирання програмного забезпечення, завантаження модулів або прохання до адміністратора встановити пакети.Використовуй підтримувані пакети, установлені в кожному середовищі, або завантаж wheels для інших пакетів.
Надсилання завданняНаписання пакетного скрипту та надсилання його планувальнику.Виклик run() з аргументами завдання.
Запит ресурсівЗапит вузлів, CPU, пам'яті та GPU.Вибір одного з розмірів обчислень, визначених для робочого процесу. Кожне завдання виконується на одному вузлі.
Сканування параметрівНадсилання масиву завдань.Виклик run() один раз для кожного набору аргументів.
Зберігання спільних файлівЗапис у спільну scratch-файлову систему.Запис у файлове сховище робочого процесу.
Обмеження часу виконанняВстановлення ліміту реального часу.Робочий процес скасовує завдання через 24 години.
Контрольні точки для тривалих завданьЗапис контрольних точок у scratch-сховище.Збереження проміжних результатів у файлове сховище.
Повторний запуск невдалого завданняПовторне надсилання завдання.Повторний виклик run(). Робочий процес не повторює невдалі завдання автоматично.
Моніторинг завданьПеревірка черги та файлів логів із вузла входу.Перевірка статусу, логів і результату кожного завдання зі свого локального сеансу Python.

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

Рекомендації
Джерело: Документація IBM Quantum — оновлено 6 лист. 2026 р.
Англійська версія на doQumentation — оновлено 6 лист. 2026 р.
Проблема із сайтом чи перекладом?Проблема з вмістом? Редагувати в IBM Quantum docs