Dry-run 작업

Dry-run 작업은 QPU 시간을 사용하지 않고 IBM Quantum® Compute Service를 통해 워크로드를 실행합니다. 실제 실행을 진행하기 전에 dry-run 작업을 사용하여 다음을 수행할 수 있습니다.

• **실제 QPU에서 작업이 발생시킬 사용량을 확인합니다.

• 작업을 검증합니다. Quantum Compute가 실제 작업과 동일한 방식으로 작업의 매개변수를 확인합니다.

• 요청하는 경우 **Circuit 타이밍 스케줄**을 확인하여, 실제로 실행하기 전에 작업을 디버그할 수 있습니다.

dry-run 작업과 달리, 로컬 테스트(fake backend 및 Qiskit Aer)는 사용자의 컴퓨터에서 실행되므로 사용량 수치, 서비스 측 검증, 서비스 타이밍 정보를 제공할 수 없습니다. 두 방식을 비교하려면 Mock 장치와 fake backend 비교를 참조하세요.

참고

• dry-run 작업을 사용하려면 qiskit-ibm-runtime v0.51.0 이상이 필요합니다.
• Dry-run 작업은 모든 리전에서 사용할 수 있으며, Flex, Premium, On-Prem 플랜에서만 사용할 수 있습니다. Open 또는 Pay-As-You-Go 플랜에서는 사용할 수 없습니다.

작동 방식

dry-run 작업을 실행하려면 Primitive의 run() 메서드에 dry_run=True를 전달하세요.

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). 모든 Primitive에서 사용할 수 있습니다.

dry-run 작업에는 다음과 같은 특징이 있습니다.

• 사용자의 컴퓨터가 아니라 클라우드의 IBM Quantum Compute Service에서 실행됩니다.

• 단순한 스냅샷이 아니라 실제 QPU의 보정 데이터를 사용합니다.

• 결과는 예상 스키마를 유지하고 실제 QPU 결과의 예상 형태를 따르지만, 무작위로 생성된 mock 데이터를 포함합니다. 실제 측정 결과도 시뮬레이션된 측정 결과도 아니므로, 물리적 정확성을 확인하는 데 사용하지 마세요.

• 처리는 서버에서 이루어지므로 작업이 즉시 끝나지 않을 수 있습니다.

Circuit 크기, shot 수 및 기타 제한은 해당 프로그램의 일반 작업과 동일합니다.

백엔드가 이미 mock 장치인 경우에도 dry_run=True는 동작합니다.

사용량 확인

완료된 dry-run 작업의 사용량은 동일한 작업이 실제 QPU에서 발생시킬 사용량과 같습니다. 단, dry-run 작업 이후 실제 QPU에서 작업을 실행하기 전에 보정 데이터가 크게 변경되는 드문 경우는 예외입니다.

• job.usage()는 사용량을 초 단위로 반환합니다.

• job.metrics()["usage"]는 동일한 데이터를 사용량 상태와 함께 반환합니다.

Dry-run 사용량에는 요금이 부과되지 않고, 플랜 할당량을 소비하지 않으며, 어떤 제한에도 포함되지 않습니다.

dry-run 작업에는 job.usage_estimation을 사용하지 마세요

dry-run 작업에는 job.usage_estimation을 사용하지 마세요. job.usage()를 사용하세요.

job.usage()는 사용량 계산이 확정될 때까지 0을 반환하므로, 값을 읽기 전에 작업이 끝날 때까지 기다리세요.

Circuit 타이밍 스케줄

Circuit 타이밍 스케줄을 요청하려면 실제 작업과 동일한 옵션을 사용하세요. 자세한 내용은 Circuit 타이밍 시각화를 참조하세요.

제한 사항

• job mode와 batch mode만 지원합니다. 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 장치를 접하게 됩니다.

• mock 장치에만 접근하도록 구성된 인스턴스. 예: service.backend("ibm_phoenix")를 사용하여 ibm_phoenix에서 dry-run 작업을 제출하려는데 인스턴스에 ibm_phoenix에 대한 접근 권한이 없으면 QiskitBackendNotFoundError가 발생합니다. 이 경우 service.backend("mock_phoenix")로 mock 장치를 직접 선택하세요.

• Compute resources. Mock 장치는 Compute resources 페이지에서 기본적으로 숨겨져 있습니다. 해당 페이지의 표에는 mock 장치를 포함하는 필터 옵션이 있지만, mock 장치에 접근할 수 있는 것은 Flex, Premium, On-Prem 플랜뿐입니다.

• Workloads 표. Mock 장치에서 실행된 작업은 Workloads 페이지에서 기본적으로 숨겨져 있습니다. 표에는 이를 표시하는 필터 옵션(깔때기 아이콘)이 있습니다.

• Python API. service.backends()와 service.jobs()는 include_mocks=True로 호출하지 않는 한 mock 장치를 제외합니다. IBMBackend.is_mock은 백엔드가 mock 장치인지 여부를 나타냅니다. service.least_busy()는 mock 장치를 반환하지 않습니다.

Mock 장치와 fake backend 비교

이름은 비슷하지만 mock 장치와 fake backend는 서로 다른 것입니다. fake backend는 Python 환경 안의 로컬 객체이고, mock 장치는 IBM Quantum Compute Service의 클라우드 리소스입니다.

	Mock 장치(예: mock_phoenix)	Fake backend(예: FakeManilaV2)
정의	IBM Quantum Compute Service의 장치	qiskit_ibm_runtime.fake_provider의 Python 클래스
실행 위치	클라우드(서비스 내부)	로컬(사용자의 컴퓨터)
얻는 방법	service.backend("mock_phoenix"), 또는 run(..., dry_run=True)로 자동 적용	from qiskit_ibm_runtime.fake_provider import ...
계정 및 인스턴스	특정 플랜만(Flex, Premium 또는 On-Prem)	모든 인스턴스와 플랜
보정	실시간이며 언제나 실제 장치와 일치	설치된 패키지에 포함된 고정 스냅샷
결과	예상 스키마를 갖춘 무작위 데이터. 시뮬레이션이 아님	스냅샷의 노이즈 모델을 사용하는 노이즈 시뮬레이션
물리적으로 의미 있는 결과	아니요. 정확성 확인에는 절대 사용하지 마세요	노이즈 모델의 한계 내에서 근사적으로 의미 있음
사용량 보고	예	없음
플랜 할당량 또는 제한에 대한 과금 또는 집계	아니요	아니요
작업 검증	실제 작업과 동일하게 서비스에서 수행	클라이언트가 확인하는 범위로 제한됨
타이밍 스케줄	요청 시 사용 가능	사용할 수 없음
실행 모드	job mode와 batch mode만 지원. Session은 차단됨	Session 구문은 허용되지만 무시됨(로컬 모드에는 실제 Session이나 batch가 없음)
완료	서버에서 비동기적으로	로컬에서 실행되고 끝나면 반환
플랫폼 인터페이스 및 API 목록에 표시 여부	기본적으로 숨김(Compute resources, Workloads 표, backends(), jobs()). 선택하면 표시됨	표시되지 않음. 서비스로 아무것도 전송되지 않기 때문

선택 방법

• 작업이 얼마나 많은 사용량을 소비할지, 또는 서비스가 작업을 수락할지를 알아보려면 dry-run 작업을 사용하세요.

• 출력이 어떤 모습일지 알아보거나 오프라인으로 작업하려면 fake backend나 Aer를 사용하세요.

• 둘 다 필요하다면 fake backend로 Circuit과 결과를 반복 개선한 다음, 실제 QPU에서 실행하기 전 마지막 점검으로 dry-run을 실행하세요.

흔히 혼동하는 점

• Mock 장치는 시뮬레이터가 아닙니다. 출력이 무작위이므로 mock_phoenix에서 Bell Circuit을 샘플링해도 Bell 분포가 반환되지 않습니다. 현실적인 노이즈 출력을 원한다면 fake backend를 사용하세요.

• Fake backend는 실시간 장치가 아닙니다. 보정 데이터는 스냅샷이며 최신이 아닐 수 있습니다. Mock 장치는 실제 보정 데이터를 추적하므로, 트랜스파일된 Circuit과 타이밍이 오늘 QPU가 보는 것과 일치합니다.

• 둘 다 실제 하드웨어에서 실행되지 않습니다. 둘 다 QPU 시간을 소비하지 않지만, 서비스를 거치는 것은 dry-run 작업뿐입니다.

• usage_estimation은 dry-run 추정치가 아닙니다. dry-run 작업에서 job.usage()는 실제 QPU에서 작업에 부과될 사용량(초)을 반환합니다.

사용 사례

학생과 강의

관리자가 인스턴스를 만들거나 편집할 때 QPU 사용자 지정 토글을 사용하여 인스턴스를 mock 장치로만 제한합니다. 그러면 학생들은 실제 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])

다음 단계

권장 사항

• 로컬 테스트 모드로 자신의 컴퓨터에서 프로그램을 테스트하세요.
• 워크로드 사용량이 어떻게 측정되는지 알아보세요.
• Circuit 타이밍 스케줄을 시각화하세요.
• 리소스 단위와 사용 가능한 플랜을 이해하세요.