Направленное выполнение: та же производительность, больше контроля

Основные выводы:

• Модель направленного выполнения (directed execution) в IBM Quantum запускает ваши схемы именно так, как вы указали, предоставляя явный клиентский контроль над стеком коррекции ошибок — от минимизации до исправления — без ущерба для производительности на системах с 100+ кубитами.
• Процедуры минимизации ошибок, которые раньше выполнялись скрыто на серверах IBM, теперь работают на стороне клиента, поэтому вы можете изучать, настраивать и расширять их.
• Это та же инфраструктура, которая лежит в основе демонстраций квантового превосходства IBM, и фундамент для исследований по коррекции ошибок, уже ведущихся на оборудовании IBM — от постселекции QEC до distance-5 surface codes методов, которые снижают логическую частоту ошибок на раунд до 2,8 раз.
• Новый примитив Executor обеспечивает работу модели, масштабируясь до тысяч вариантов схем и позволяя вручную создавать пользовательские конвейеры минимизации и коррекции ошибок.
• Уже используете примитивы Sampler и Estimator в Qiskit? Обновление не вызовет затруднений: обновите провайдер, и ваш существующий код продолжит работать.

Самые требовательные современные квантовые эксперименты редко начинаются и заканчиваются выполнением одной схемы. Как правило, рабочие нагрузки включают большие семейства тесно связанных вариантов схем, построенных на многоэтапных процессах для борьбы с шумом, рандомизации и постобработки — и ручная сборка таких процессов требует значительного времени и усилий.

С появлением модели направленного выполнения в IBM Quantum Compute Service ситуация меняется. Направленное выполнение — это новая, более низкоуровневая модель, которая, оправдывая свое название, запускает ваши схемы именно так, как вы указали, предоставляя явный и компонуемый способ управления запуском схем и прозрачное представление о том, что на самом деле происходит на оборудовании IBM Quantum. Важно отметить, что вы получаете такую прозрачность и контроль, не жертвуя производительностью, которую вы ожидаете от систем с 100+ кубитами.

Давайте вспомним, как мы к этому пришли. Выполнение на оборудовании IBM Quantum начиналось с backend.run, прямого метода для запуска списка схем. Это было приемлемо, когда рабочие нагрузки состояли из небольшого количества схем, но передовые эксперименты все чаще стали опираться на большие семейства вариантов схем для твирлинга (twirling), рандомизации и изучения шума, каждый из которых приходилось создавать на стороне клиента и передавать по сети. Примитивы Sampler и Estimator изменили это, генерируя варианты на стороне сервера в среде near-time, ранее известной как Qiskit Runtime, а теперь — IBM Quantum Compute Service. Это повысило производительность при масштабировании, но превратило выполнение в «черный ящик».

Направленное выполнение — это следующий шаг. Оно возвращает нас к единой точке входа, но это не просто возврат к backend.run. Механизм, лежащий в его основе, был переработан, чтобы дать вам уровень контроля и производительности, который ранее был невозможен. Теперь вы можете создавать алгоритмические примитивы, такие как Sampler и Estimator, на стороне клиента, адаптированные под ваши задачи, а затем отправлять их для обработки в Executor в среде near-time сервиса IBM Quantum Compute Service.

Эволюция модели программирования: от backend.run (2016–2022) к серверным Sampler и Estimator (2022–настоящее время) и к примитиву Executor (с 2026 года).

Это важно по двум причинам. Во-первых, это та же инфраструктура, которую IBM и ее партнеры использовали для недавних демонстраций квантового превосходства с помощью доверенных вычислений. Во-вторых, это превращает IBM Quantum Compute Service в платформу для исследования всего спектра методов борьбы с ошибками — от продвинутой минимизации ошибок до кодов коррекции ошибок, которые исследователи уже запускают на квантовом оборудовании IBM.

Мы знаем, что работающий инструментарий имеет решающее значение, поэтому модель направленного выполнения нацелена на достижение прогресса без сбоев. Если вы в настоящее время используете примитивы Sampler и Estimator, ваш код продолжит работать. Обновление спроектировано так, чтобы быть максимально простым, поэтому в большинстве случаев единственное, что изменится, — это ваши операторы импорта, а не тело кода. Вам никогда не потребуется обращаться к низкоуровневым инструментам, если только вы сами не поставите перед собой такую задачу.

В этой статье рассматриваются строительные блоки модели направленного выполнения и ресурсы, которые показывают, как эти части работают вместе. Чтобы получить предварительное представление о работе направленного выполнения, попробуйте новое руководство PEC с моделями логического шума на платформе IBM Quantum Platform.

Что такое модель направленного выполнения?

По своей сути, направленное выполнение — это инфраструктура, которая позволяет вам описывать, как схема должна быть преобразована и рандомизирована перед запуском, без необходимости генерировать варианты схем самостоятельно. Вы определяете преобразования и рандомизацию, а IBM Quantum Compute Service эффективно подготавливает и запускает схемы.

Основой модели направленного выполнения является новый примитив Executor. Все новые клиентские инструменты и примитивы построены на его базе, что позволяет нам консолидировать серверную поддержку, не нарушая работу вашего кода.

Модель направленного выполнения: клиентские пакеты и Samplomatic создают шаблон схемы и samplex, которые примитив Executor запускает в IBM Quantum Compute Service.

Работа напрямую с Executor полезна, когда ваше исследование зависит от точного контроля того, как выполняются ваши схемы. Например, если ваша работа включает разработку новых протоколов минимизации ошибок, изучение распространения шума через определенную область схемы или бенчмаркинг поведения оборудования на тысячах вариантов схем, Executor станет для вас бесценным инструментом.

В то же время не все исследования требуют такого уровня контроля. Чтобы сохранить удобство, к которому вы привыкли, примитивы Sampler и Estimator теперь также работают поверх Executor. Мы адаптировали их так, чтобы они беспрепятственно использовали Executor в фоновом режиме, поэтому их входные и выходные данные остаются прежними. Для большинства пользователей это означает, что единственным необходимым шагом будет обновление провайдера.

Разница заключается в том, что минимизация ошибок, которую они выполняют, больше не является «черным ящиком». Эта логика теперь работает на клиенте, поэтому вы можете видеть, как она реализована, корректировать ее или писать свои собственные методы непосредственно для Executor. Во многом это является основной целью и организующим принципом направленного выполнения: удобство, когда вы этого хотите, и контроль, когда он вам нужен.

Модель направленного выполнения состоит из нескольких ключевых компонентов. Давайте рассмотрим их в том порядке, в котором вы, скорее всего, будете их использовать.

Блоки (boxes) и аннотации: выражение намерений

Направленное выполнение опирается на две возможности, впервые представленные в Qiskit SDK v2.0 и v2.1: блоки (инструкция BoxOp) и аннотации. Блоки группируют инструкции в вашей схеме для последующей обработки; аннотации помечают эти блоки директивами для транспайлера или последующих этапов стека выполнения.

Некоторые общие аннотации, предопределенные в Samplomatic, включают:

• Twirl: применяет твирлинг Паули или Клиффорда для минимизации шума
• InjectNoise: вводит шум контролируемым, настраиваемым способом для исследований по минимизации ошибок
• ChangeBasis: управляет поворотом кубитов в определенные базисные состояния и обратно во время выполнения

Вы используете блоки для определения значимых областей вашей схемы, а затем добавляете аннотации, которые определяют, как должны преобразовываться операции внутри каждого блока. Практическое руководство см. в руководстве по транспайлеру Samplomatic, в котором рассматриваются как группировка операций в блоки, так и работа с аннотациями.

Samplomatic: построение плана выполнения

Библиотека с открытым исходным кодом Samplomatic интерпретирует вашу схему с блоками и аннотациями и превращает ее в конкретный план выполнения с двумя выходными данными:

• Шаблонная схема: стандартная параметрическая схема Qiskit, которая выступает в качестве проверяемого чертежа для каждого варианта схемы с настраиваемыми параметрами, которые среда выполнения заполняет во время выполнения.
• Samplex: структурированный, проверяемый рецепт того, как должны происходить рандомизация и классическая постобработка, а не набор предварительно вычисленных вариантов. Она следует модели тензорного ввода/вывода: тензоры входных параметров на входе, тензоры рандомизированных значений на выходе.

Поскольку оба компонента генерируются локально, вы можете точно проверить, как твирлы, инъекции шума и другие преобразования распространяются по вашей схеме, прежде чем отправлять что-либо на оборудование. Чтобы узнать, как это сделать, ознакомьтесь с руководством Входные и выходные данные Samplex, в котором показано, как настроить и прочитать samplex, а также с руководством Отладка и трассировка, в котором показано, как проверять макеты и отслеживать преобразования перед запуском.

Примитив Executor

После того как вы создали свой план, его запускает примитив Executor. Это низкоуровневый движок, на котором построены остальные инструменты направленного выполнения.

Executor рассматривает каждую шаблонную схему как манипулятор тензоров, потребляющий тензоры значений параметров и создающий тензоры результатов. Это означает, что он может масштабироваться до больших семейств вариантов без ручной сборки.

Вместо списка PUB (Primitive Unified Blocs), которые Sampler и Estimator принимают в качестве входных данных, Executor принимает QuantumProgram, которая может содержать несколько элементов. Если вы не знакомы с этим, PUB — это фундаментальная единица работы, которую выполняют примитивы, по сути, схема, объединенная с данными, необходимыми для ее выполнения. QuantumProgram расширяет эту модель. Она содержит несколько элементов, и каждый элемент объединяет схему, значения ее параметров и манипуляции, которые будут применены во время выполнения.

После того как ваша программа определена, Executor запускает ее через циклы шотов (shot loops). Он создан для масштабирования и работает в той же высокопроизводительной среде выполнения, которую мы создали для первого поколения Sampler и Estimator, поэтому он может обрабатывать рабочие нагрузки из 5000 рандомизаций и более без ущерба для производительности.

Executor также поддерживает широковещательную рассылку. Вы можете выполнять развертку по шкалам шума, изменениям базиса или наборам параметров с использованием привычных правил в стиле NumPy, и все это в рамках одного задания.

Инструменты, построенные на направленном выполнении

Блоки, Samplomatic и Executor составляют саму модель направленного выполнения. Вокруг них растет экосистема инструментов с открытым исходным кодом, которые опираются на эту модель, превращая низкоуровневое управление в готовые к использованию возможности, поэтому вам не нужно реализовывать изучение шума или смягчение ошибок с нуля. К ним относятся клиентская реализация примитивов Sampler и Estimator, а также несколько дополнительных пакетов:

Типичный рабочий процесс смягчения ошибок из четырех шагов и пакет направленного выполнения, который обрабатывает каждый из них: Samplomatic, Qiskit Noise Learning, Qiskit Mitigation и примитив Executor.

Новые Sampler и Estimator: локальный режим с реальным смягчением ошибок

Новые клиентские Sampler и Estimator, выпущенные на прошлой неделе в составе qiskit-ibm-runtime 0.50.0, не просто заменяют функциональность исходных примитивов, они также улучшают ее. Прозрачность модели направленного выполнения означает, что смягчение ошибок, которое они выполняют, теперь можно проверять и настраивать, вместо того чтобы скрывать его на стороне сервера. Это также делает локальный режим гораздо более функциональным.

Запуск смягчения ошибок на клиенте означает, что вы можете опробовать его локально, прежде чем отправлять что-либо на QPU. В серверном Estimator запуск на локальном симуляторе полностью игнорирует ваши параметры устойчивости. Смягчение ошибок — это «черный ящик», поэтому воспроизвести его невозможно. Благодаря новой клиентской реализации локальный режим qiskit-ibm-runtime применяет то же смягчение ошибок, которое вы получили бы на оборудовании. Например:

# В ближайшем будущем это будет стандартный Estimator. from qiskit_ibm_runtime.executor_estimator import Estimator from qiskit_ibm_runtime.fake_provider import FakeKingston estimator = Estimator(FakeKingston()) estimator.options.resilience_level = 1 estimator.run(pubs)

Здесь resilience_level = 1 фактически применяет смягчение ошибок 1-го уровня (TREX) к вашим схемам на симуляторе, тогда как серверный Estimator просто проигнорировал бы его. Это изменение дает вам возможность создавать прототипы и сравнивать стратегии смягчения ошибок локально, прежде чем тратить время QPU.

Имейте в виду, что FakeKingston моделирует 156-кубитное устройство, которое слишком велико для воспроизведения на локальном симуляторе вектора состояния. Поскольку все доступные вам QPU имеют более 100 кубитов, мы рекомендуем запускать симуляции Клиффорда (стабилизатора) для быстрой приблизительной проверки ваших схем со смягченными ошибками.

Qiskit Noise Learning — клиентская характеризация шума

Многие методы смягчения квантовых ошибок зависят от точного знания того, где именно возникает шум в ваших схемах. Qiskit Noise Learning — это клиентский пакет с открытым исходным кодом для изучения шума Паули-Линдблада, который работает непосредственно с блоками и аннотациями.

В исходной версии Estimator изучение и инъекция шума выполнялись на стороне сервера; вы не могли видеть или настраивать карту шума. Теперь эта характеризация выполняется на клиенте, что дает вам возможность видеть шум в каждой области, полную возможность настройки и поддержку протоколов как Паули-Линдблада, так и TREX.

Qiskit Noise Learning относится к NoiseLearner так же, как Executor к примитивам — это та же базовая возможность, открытая для того, чтобы вы могли изучить ее, настроить и расширить. Как и в случае с примитивами, мы продолжим поддерживать удобный интерфейс в стиле NoiseLearner для тех, кому не требуются эти возможности: удобство, когда вы этого хотите, и контроль, когда он вам нужен.

Чтобы увидеть полный API и несколько полезных примеров, обязательно ознакомьтесь с документацией Qiskit Noise Learning.

Qiskit Mitigation

Qiskit Mitigation — это пакет с открытым исходным кодом, содержащий методы смягчения квантовых ошибок для построения конвейеров смягчения ошибок непосредственно с помощью Samplomatic. Он включает реализации таких методов, как вероятностная отмена ошибок (PEC), вероятностное усиление ошибок (PEA), твирлированное устранение ошибок считывания (TREX) и экстраполяция нулевого шума со сверткой гейтов (ZNE).

Помимо этих основных методов, Qiskit Mitigation также содержит продвинутые строительные блоки, которые делают сложные рабочие процессы практичными, и предоставляет их напрямую, готовыми к вызову. Вы можете вычислять постселектированные каналы шума на основе симметрий схемы или проверок пространства-времени, чтобы сократить накладные расходы на выборку PEC, добавлять постселекцию проверки битовых переворотов для фильтрации немарковского шума, вычислять ожидаемые значения с расширенным смягчением ошибок и многое другое.

Тем не менее, вам не обязательно создавать всё это вручную, чтобы воспользоваться преимуществами. Новые клиентские Sampler и Estimator построены на тех же реализациях, поэтому, хотите ли вы вызвать высокоуровневый примитив или собрать собственный конвейер вручную, Qiskit Mitigation позволяет работать на том уровне, который лучше всего соответствует вашим потребностям. А поскольку система спроектирована с учетом модульности, вы можете изменить одну часть — например, заменить экстраполятор на пользовательский для рабочего процесса ZNE — без необходимости переписывать весь протокол целиком.

Для кого предназначено направленное выполнение (directed execution)

Поскольку пакеты, библиотеки и возможности, обеспечивающие направленное выполнение, являются модульными, эта новая модель способна адаптироваться к любым условиям и методам вашей работы:

• Прикладные исследователи могут продолжать использовать готовые Sampler и Estimator с привычными параметрами, такими как resilience_level — никаких изменений не требуется. Узнайте больше в руководствах по Sampler и Estimator или ознакомьтесь с примечаниями к выпуску 0.50.0 для получения подробной информации о новой клиентской реализации.
• Разработчики алгоритмов могут изучать и настраивать методы в Qiskit Mitigation — как показано в руководстве по PEC с логическими моделями шума.
• Эксперты по аппаратному обеспечению могут составлять полный рабочий процесс вручную, применяя PEC к одной части схемы, а PEA — к другой. Подробный пример этого можно найти в недавней демонстрации оператора эха Лошмидта от Algorithmiq и IBM — результате квантового превосходства, который строит весь конвейер подавления ошибок и верификации непосредственно на стеке направленного выполнения.

Получение большего контроля над выполнением схем требует лишь немного дополнительного кода. А если вам это не нужно, вам не о чем беспокоиться.

Более пристальный взгляд: PEC с затененными световыми конусами

В качестве примера направленного выполнения в действии давайте посмотрим, как оно справляется с рабочим процессом, который был невозможен с оригинальными Sampler и Estimator: объединение вероятностного подавления ошибок (PEC), затененных световых конусов (SLC), TREX и постселекции в едином конвейере.

Приведенный здесь пример — лишь высокоуровневый обзор. Полный рабочий код можно найти в руководстве по PEC с затененными световыми конусами.

1. Отобразите задачу. Определите наблюдаемую величину и базисы измерений, которые вам понадобятся.

observable = SparsePauliOp.from_sparse_list(target_obs_sparse, num_qubits=num_qubits) bases_virt, reverser_virt = get_measurement_bases(observable)

2. Оптимизируйте. Транспилируйте схему и сгруппируйте её инструкции в аннотированные блоки с помощью Samplomatic. Затем вычислите границы затененных световых конусов, которые определяют, какие ошибки можно безопасно оставить без подавления.

from samplomatic.transpiler import generate_boxing_pass_manager from qiskit_addon_slc.bounds import compute_forward_bounds, merge_bounds boxed_circuit = generate_boxing_pass_manager( twirling_strategy="active", inject_noise_strategy="individual_modification", measure_annotations="all", ).run(isa_circuit) forward_bounds = compute_forward_bounds(boxed_circuit, noise_model_paulis, isa_observable, ...) merged_bounds = merge_bounds(boxed_circuit, forward_bounds, backward_bounds, noise_model_rates)

3. Выполните. Изучите шум на каждом уникальном слое, преобразуйте границы в коэффициенты масштабирования для каждой ошибки, затем создайте шаблонную схему, samplex и запустите всю программу через Executor в рамках одного задания.

# Изучение шума на каждом уникальном слое noise_learner = NoiseLearnerV3(backend, noise_learner_options) refs_2_plm = noise_learner.run(unique_2q_instructions).result().to_dict(unique_2q_instructions) # Преобразование границ SLC в коэффициенты масштабирования для каждой ошибки local_scales, sampling_cost, _ = compute_local_scales(boxed_circuit, merged_bounds, refs_2_plm, ...) # Создание шаблонной схемы + samplex, затем выполнение template_circuit, samplex = samplomatic.build(boxed_circuit) program = QuantumProgram(shots=shots_per_randomization, noise_maps=refs_2_plm) program.append_samplex_item( circuit=final_template_circuit, samplex=samplex, samplex_arguments=samplex_arguments, shape=(num_randomizations,), ) results = Executor(backend).run(program).result()

4. Постпроцессинг. Примените TREX и постселекцию к необработанным результатам, чтобы восстановить скорректированные ожидаемые значения.

mask = post_selector.compute_mask(datum, strategy=post_selection_strategy) res = executor_expectation_values( meas, reverser_virt, ..., postselect_mask=mask, rescale_factors=trex_scale_factors, gamma_factor=gamma, )

Результат: SLC сократил накладные расходы на выборку PEC примерно в 3,4 раза при сохранении сопоставимой точности. Полную информацию о настройке модели шума, всех параметрах и анализе можно найти в руководстве.

Экспериментируйте с кодами коррекции ошибок уже сегодня

Направленное выполнение предназначено не только для подавления ошибок — оно уже является фундаментом для практических исследований в области коррекции ошибок. Тот же клиентский контроль, который позволяет преобразовывать аппаратный шум в шум Паули для подавления, также позволяет создавать и изучать коды коррекции ошибок на современном оборудовании.

Например, недавняя работа IBM по пространственно-временному подавлению логических ошибок накладывает PEC поверх постселектированного QEC для резкого сокращения накладных расходов на выборку, а Qiskit Paulice уже сегодня предоставляет платформе возможности постселектированной квантовой коррекции ошибок. Исследователи также запускают полноценные коды коррекции ошибок: в одном недавнем исследовании были реализованы поверхностные коды расстояния 5 на IBM Quantum Nighthawk, что позволило улучшить коэффициент логических ошибок на раунд до 2,8 раз за счет идентификации и обхода нескольких неэффективных компонентов.

Этот контроль распространяется даже ниже уровня схем. Благодаря доступу на уровне импульсов вы можете управлять таймингом вентилей, выполнять быстрый сброс кубитов и считывать «мягкую» (предварительную классификацию) информацию измерений — рычаги, которые можно использовать для настройки производительности ваших QEC-схем. Вместе эти возможности делают IBM Quantum Compute Service местом для исследования всего континуума: от квантового подавления ошибок до квантовой коррекции ошибок.

Что дальше: одна платформа, от подавления до коррекции

Executor — это начальная реализация модели направленного выполнения. Со временем вы можете ожидать появления в ней дополнительных возможностей.

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

И поскольку это самая гибкая платформа из имеющихся у нас, новые исследования в области подавления и коррекции ошибок в первую очередь внедряются в Executor. Это платформа, созданная для долгосрочного развития.

Миграция с помощью ИИ

Если вы переносите существующий код на клиентские примитивы, вам не обязательно делать это вручную.

Вместе с этим выпуском мы публикуем наш первый официальный навык Qiskit AI: migrate-qiskit-ibm-runtime, помощник по миграции, который переносит ваш код qiskit-ibm-runtime на новые клиентские Sampler и Estimator, отмечая критические изменения в процессе. Он поддерживает миграцию как с V1, так и с устаревших серверных примитивов V2. Этот первоначальный выпуск (0.1.0) охватывает все действия по миграции из qiskit-ibm-runtime 0.1.0 вплоть до последней версии 0.50.0, включая изменения в API IBM Quantum Compute Service за прошедшие годы.

Это проект с открытым исходным кодом, который находится в Qiskit/skills GitHub repository. Добавьте его в свой ИИ-помощник по программированию, укажите путь к коду, и пусть он возьмет на себя рутинную работу. Это также самый простой способ начать: сначала выполните миграцию, а затем изучайте инструменты, описанные в этой статье, в удобном для вас темпе.

Начало работы с направленным выполнением

Самый быстрый способ понять модель направленного выполнения — это начать ее использовать.

• Обновите свою среду. Убедитесь, что у вас установлена последняя версия qiskit-ibm-runtime, чтобы получить доступ к Executor, а также к новым клиентским Sampler и Estimator. Это единственный шаг, который переводит ваши рабочие нагрузки на модель направленного выполнения, независимо от того, будете ли вы вызывать Executor напрямую.

Обновите свою среду. Убедитесь, что у вас установлена последняя версия qiskit-ibm-runtime, чтобы получить доступ к Executor, а также к новым клиентским Sampler и Estimator. Это единственный шаг, который переводит ваши рабочие нагрузки на модель направленного выполнения, независимо от того, будете ли вы вызывать Executor напрямую.

• Углубитесь в детали. Изучите документацию по модели направленного выполнения, чтобы узнать больше о Samplomatic, Executor, Qiskit Noise Learning и Qiskit Mitigation.

Углубитесь в детали. Изучите документацию по модели направленного выполнения, чтобы узнать больше о Samplomatic, Executor, Qiskit Noise Learning и Qiskit Mitigation.

• Попробуйте сами. Пройдите руководство по PEC с использованием shaded lightcones. Оно использует направленное выполнение от начала до конца, объединяя PEC, SLC, TREX и постселекцию на примитиве Executor.

Попробуйте сами. Пройдите руководство по PEC с использованием shaded lightcones. Оно использует направленное выполнение от начала до конца, объединяя PEC, SLC, TREX и постселекцию на примитиве Executor.

Уже используете Sampler и Estimator? Ничего не сломается — ваш код продолжит работать, а расширенные возможности, предоставляемые направленным выполнением, будут доступны, когда вы будете готовы их изучить.