Mga dry-run job

Pinapatakbo ng isang dry-run job ang iyong workload sa IBM Quantum® Compute Service nang hindi gumagamit ng anumang QPU time. Gumamit ng dry-run job para gawin ang mga sumusunod bago ka mag-commit sa totoong run:

• **Kunin ang usage na maaaring maranasan ng job sa totoong QPU.

• I-validate ang job. Sinusuri ng Quantum Compute ang mga parameter ng job, gaya ng ginagawa nito sa totoong job.

• Kunin ang circuit timing schedule, kung hihilingin mo ito, para i-debug ang job bago mo ito patakbuhin nang totoo.

Hindi tulad ng mga dry-run job, ang local testing (mga fake backend at Qiskit Aer) ay tumatakbo sa sarili mong makina kaya hindi ito makapagbibigay ng mga numero ng usage, service-side validation, o impormasyon sa service timing. Para ihambing ang dalawang paraan, tingnan ang Mock devices kumpara sa mga fake backend.

tala

• Kinakailangan ang qiskit-ibm-runtime v0.51.0 o mas bago para sa mga dry-run job.
• Available ang mga dry-run job sa lahat ng rehiyon, at available lang sa mga plan na Flex, Premium, at On-Prem. Hindi sila available sa mga plan na Open o Pay-As-You-Go.

Paano ito gumagana

Para magpatakbo ng dry-run job, ipasa ang dry_run=True sa run() method ng primitive:

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

Ang dry_run ay isang argument ng run() method (ang default ay False), hindi isang runtime option. Available ito sa lahat ng primitive.

Ang isang dry-run job ay may mga sumusunod na katangian:

• Tumatakbo ito sa IBM Quantum Compute Service sa cloud, hindi sa iyong makina.

• Ginagamit nito ang calibration data mula sa totoong QPU, hindi lang isang snapshot.

• Pinananatili ng mga resulta nito ang inaasahang schema at sinusunod ang inaasahang hugis ng mga resulta mula sa totoong QPU, pero naglalaman ng randomized na mock data. Hindi ito totoo o simulated na mga resulta ng pagsukat, kaya huwag itong gamitin para suriin ang pisikal na kawastuhan.

• Nangyayari ang pagpoproseso sa server, kaya maaaring hindi agad matapos ang job.

Ang laki ng circuit, mga shot, at iba pang limitasyon ay kapareho ng sa anumang job ng programang iyon.

Gumagana rin ang dry_run=True kapag mock device na ang backend.

Basahin ang usage

Ang usage ng isang natapos na dry-run job ay ang usage na maaaring maranasan ng parehong job sa totoong QPU, maliban sa mga bihirang sitwasyon kung saan malaki ang pagbabago ng calibration data pagkatapos ng dry-run job at bago ang job sa totoong QPU.

• Ibinabalik ng job.usage() ang usage sa segundo.

• Ibinabalik ng job.metrics()["usage"] ang parehong data kasama ang usage status.

Hindi sinisingil ang dry-run usage, hindi ito kumokonsumo ng allocation ng iyong plan, at hindi ito binibilang sa anumang limitasyon.

Huwag gamitin ang job.usage_estimation sa mga dry-run job

Huwag gamitin ang job.usage_estimation sa isang dry-run job. Gamitin ang job.usage().

Ibinabalik ng job.usage() ang 0 hanggang sa maging pinal ang pagkalkula ng usage, kaya hintayin munang matapos ang job bago mo ito basahin.

Iskedyul ng timing ng circuit

Para hilingin ang circuit timing schedule, gamitin ang parehong option tulad ng sa totoong job. Para sa buong detalye, tingnan ang Visualize circuit timing.

Mga limitasyon

• Job at batch mode lang. Tumatakbo lang ang mga dry-run job sa job mode at batch mode.

• Mga plan na Flex, Premium, at On-Prem lang. Hindi available ang mga dry-run job sa mga plan na Open o Pay-As-You-Go.

Mga mock device

Ang mga mock device ang implementasyon sa likod ng mga dry-run job. Itinatago ng mga dry-run job ang mga mock device bilang default, pero makakaharap mo sila sa mga sumusunod na kaso:

• Mga instance na naka-configure para ma-access lang ang mga mock device. Halimbawa: kung gagamitin mo ang service.backend("ibm_phoenix") para magsumite ng dry-run job sa ibm_phoenix, pero walang access ang iyong instance sa ibm_phoenix, makakakuha ka ng QiskitBackendNotFoundError. Sa halip, piliin nang direkta ang mock device gamit ang service.backend("mock_phoenix").

• Compute resources. Nakatago bilang default ang mga mock device sa pahina ng Compute resources. May filter option ang talahanayan sa pahina para isama sila, pero ang mga plan lang na Flex, Premium, at On-Prem ang may access sa mga mock device.

• Talahanayan ng Workloads. Nakatago bilang default ang mga job mula sa mga mock device sa pahina ng Workloads. May filter option ang talahanayan (ang icon na funnel) para ipakita sila.

• Python API. Hindi isinasama ng service.backends() at service.jobs() ang mga mock device maliban kung tatawagin mo sila gamit ang include_mocks=True. Ipinapahiwatig ng IBMBackend.is_mock kung mock device ang isang backend. Hindi kailanman nagbabalik ng mock device ang service.least_busy().

Mga mock device kumpara sa mga fake backend

Magkahawig ang mga pangalan, pero magkaiba ang mock device at fake backend. Ang fake backend ay isang lokal na object sa iyong Python environment. Ang mock device ay isang cloud resource sa IBM Quantum Compute Service.

	Mock device (halimbawa mock_phoenix)	Fake backend (halimbawa FakeManilaV2)
Ano ito	Isang device sa IBM Quantum Compute Service	Isang Python class sa qiskit_ibm_runtime.fake_provider
Saan tumatakbo	Cloud, sa service	Lokal, sa iyong makina
Paano ito makukuha	service.backend("mock_phoenix"), o awtomatiko gamit ang run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Account at instance	Mga partikular na plan lang (Flex, Premium, o On-Prem)	Lahat ng instance at plan
Calibration	Live, tugma sa totoong device anumang oras	Nakapirming snapshot na kasama sa naka-install na package
Mga resulta	Randomized na data na may inaasahang schema. Hindi simulation	Noisy simulation na gumagamit ng noise model ng snapshot
Mga resultang may pisikal na kahulugan	Wala. Huwag kailanman gamitin para suriin ang kawastuhan	Humigit-kumulang, sa loob ng limitasyon ng noise model
May iniuulat na usage	Oo	Wala
Sinisingil o binibilang sa plan allocation o mga limitasyon	Hindi	Hindi
Job validation	Ginagawa ng service, kapareho ng totoong job	Limitado sa sinusuri ng client
Timing schedule	Available kapag hiniling	Hindi available
Mga execution mode	Job at batch mode lang. Naka-block ang mga Session	Tinatanggap ang Session syntax pero binabalewala (walang totoong session o batch ang local mode)
Pagtatapos	Asynchronous, sa server	Lokal na tumatakbo at nagbabalik kapag tapos na
Ipinapakita sa platform interface at mga listahan ng API	Nakatago bilang default (Compute resources, talahanayan ng Workloads, backends(), jobs()). Mag-opt in para ipakita	Hindi kailanman, dahil walang ipinapadala sa service

Paano pumili

• Para malaman kung gaano karaming usage ang kokonsumohin ng job, o kung tatanggapin ito ng service, gumamit ng dry-run job.

• Para malaman kung ano ang maaaring hitsura ng output, o para magtrabaho offline, gumamit ng fake backend o Aer.

• Para magawa ang dalawa, mag-iterate sa mga circuit at resulta gamit ang fake backend, pagkatapos mag-dry-run bilang huling pagsusuri bago ang totoong QPU.

Mga karaniwang kalituhan

• Ang mock device ay hindi simulator. Random ang output nito, kaya ang pag-sample ng Bell circuit sa mock_phoenix ay hindi nagbabalik ng Bell distribution. Kung gusto mo ng makatotohanang noisy na output, gumamit ng fake backend.

• Ang fake backend ay hindi ang live na device. Snapshot ang calibration nito at maaaring luma na. Sinusubaybayan ng mock device ang totoong calibration, kaya tugma ang mga transpiled na circuit at timing sa nakikita ng QPU ngayon.

• Wala sa dalawa ang tumatakbo sa totoong hardware. Wala sa dalawa ang kumokonsumo ng QPU time, pero dry-run job lang ang dumadaan sa service.

• Ang usage_estimation ay hindi ang dry-run estimate. Para sa dry-run job, ibinabalik ng job.usage() ang mga segundo ng usage na sisingilin sa iyong job sa totoong QPU.

Mga use case

Mga estudyante at kurso

Nililimitahan ng isang administrator ang isang instance sa mga mock device lang, gamit ang QPU customization toggle kapag gumagawa o nag-e-edit ng instance. Pagkatapos ay maaaring i-validate ng mga estudyante ang kanilang mga payload nang end-to-end nang hindi kumokonsumo ng totoong QPU time o RU. Dahil mock device lang ang may access ang instance, pinipili ng mga estudyante ang backend gamit ang mock name nito:

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

Pagpaplano ng proyekto

Ang isang team na malapit nang magsimula ng proyekto ay nagdadry-run ng mga kinatawang job para makita ang mga RU na kailangan ng proyekto, bago pumili ng plan o allocation:

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

Huling pagsusuri bago tumakbo sa totoong QPU

I-validate ang mga parameter at suriin ang timing schedule gamit ang dry_run=True, pagkatapos alisin ang argument at patakbuhin sa totoong QPU. Walang ibang magbabago sa iyong code:

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

Mga susunod na hakbang

Mga rekomendasyon

• Subukan ang mga programa sa sarili mong makina gamit ang Local testing mode.
• Alamin kung paano sinusukat ang workload usage.
• I-visualize ang circuit timing schedule.
• Unawain ang resource units at ang mga available na plan.