Panimula sa mga execution mode ng Quantum Compute

Nang ilunsad ang IBM Quantum Compute Service, ang mga user ay makakapagpatakbo lamang ng mga circuit bilang mga indibidwal na job. Habang lumabas ang iba't ibang uri ng quantum workload, naging malinaw ang pangangailangan para sa iba't ibang estratehiya sa scheduling. Tinutukoy ng mga execution mode kung paano ise-schedule ang iyong mga job, at ang pagpili ng tamang execution mode ay nagpapahintulot sa iyong workload na tumakbo nang mahusay sa loob ng iyong budget. May tatlong execution mode: job, session, at batch.

Job mode

Isang kahilingan para sa isang primitive na ginawa nang walang context manager. Ang mga Circuit at input ay nakabalot bilang mga primitive unified bloc (PUB) at isinumite bilang isang execution task sa quantum computer. Para tumakbo sa job mode, tukuyin ang mode=backend kapag nag-instantiate ng primitive. Tingnan ang Mga halimbawa ng Estimator at Mga halimbawa ng Sampler para sa paggamit.

Batch mode

Isang multi-job manager para sa mahusay na pagpapatakbo ng mga eksperimento na binubuo ng multi-job workload. Ang mga workload na ito ay binubuo ng mga job na maaaring isagawa nang nakapag-iisa at walang kondisyonal na relasyon sa isa't isa. Sa batch mode, isinusumite ng mga user ang lahat ng kanilang mga job nang sabay-sabay.

Ini-parallelize o tini-thread ng sistema ang pre-processing (classical computing) na hakbang ng bawat primitive job para mas mahigpit na maipakete ang quantum execution sa mga job, at pagkatapos ay patatakbuhin ang quantum execution ng bawat job nang mabilis at sunud-sunod para maihatid ang pinaka-mahusay na mga resulta. Para sa karagdagang detalye tungkol sa threading, tingnan ang pahina ng Execution mode FAQ.

Mga Tala

• Sa panahon ng batching, hindi garantisado na tatakbo ang mga job sa pagkakasunud-sunod na isinumite ang mga ito. Gayundin, habang ang iyong mga batch job ay tatakbo nang magkakalapit hangga't maaari, hindi sila makakakuha ng eksklusibong access sa backend. Kaya naman, ang iyong mga batch job ay maaaring tumakbo nang kahanay ng mga job ng ibang user kung may sapat na kapasidad sa pagproseso sa QPU. Bukod dito, ang mga QPU calibration job ay maaaring tumakbo sa pagitan ng mga batch job.
• Hindi bumababa ang oras ng paghihintay sa queue para sa unang job na isinumite sa loob ng isang batch. Kaya naman, ang mga batch ay hindi nagbibigay ng anumang benepisyo kapag nagpapatakbo ng isang job lamang.

Para tumakbo sa batch mode, tukuyin ang mode=batch kapag nag-instantiate ng primitive o patakbuhin ang job sa isang batch context manager. Tingnan ang Magpatakbo ng mga job sa batch para sa mga halimbawa.

Session mode

Isang nakalaan na window para sa pagpapatakbo ng multi-job workload. Sa panahon ng window na ito, ang user ay may eksklusibong access sa sistema at walang ibang job ang maaaring tumakbo — kasama na ang mga calibration job. Nagbibigay-daan ito sa mga user na mag-eksperimento sa mga variational algorithm sa mas predictable na paraan at maaari pang magpatakbo ng maraming eksperimento nang sabay-sabay, sinasamantala ang parallelism sa stack. Ang paggamit ng mga session ay tumutulong na maiwasan ang mga pagkaantala na dulot ng pag-queue ng bawat job nang hiwalay, na maaaring maging kapaki-pakinabang lalo na para sa mga iterative na gawain na nangangailangan ng madalas na komunikasyon sa pagitan ng mga classical at quantum na mapagkukunan. Ang cost function sa larawan ay kumakatawan sa quantum variational algorithm na tumatakbo sa lokal na makina ng user.

Para tumakbo sa session mode, tukuyin ang mode=session kapag nag-instantiate ng primitive, o patakbuhin ang job sa isang session context manager. Tingnan ang Magpatakbo ng mga job sa session para sa mga halimbawa.

Mga Tala

• Hindi bumababa ang oras ng paghihintay sa queue para sa unang job na isinumite sa loob ng isang session. Kaya naman, ang mga session ay hindi nagbibigay ng anumang benepisyo kapag nagpapatakbo ng isang job lamang.
• Hindi maaaring magsumite ng mga session job ang mga user ng Open Plan.

Pangunahing workflow

Ang pangunahing workflow para sa mga batch at session ay magkatulad:

1. Ang unang job sa isang batch o session ay pumapasok sa normal na queue. Para sa mga batch, ang buong hanay ng mga job ay naka-schedule nang magkasama.

2. Kapag nagsimulang tumakbo ang unang job, nagsisimula ang maximum time to live (TTL) timer, at hindi ito tumitigil o humihinto hanggang hindi naabot ang katapusan.

3. Nagsisimula ang interactive TTL timer pagkatapos makumpleto ang bawat job. Kung walang mga workload job na handa sa loob ng interactive TTL window, ang workload ay pansamantalang dina-deactivate at nire-resume ang normal na pagpili ng job. Maaaring i-reactivate ng isang job ang na-deactivate na workload kung hindi pa naabot ng batch o session ang maximum TTL value nito.

   tala

   Ang job ay kailangang dumaan sa normal na queue para i-reactivate ang workload.

4. Kung naabot ang maximum TTL value, nagtatapos ang workload at ang anumang natitirang job sa queue ay mabibigo. Ang anumang job na kasalukuyang tumatakbo ay hindi tatakbo hanggang sa katapusan kung ang paggawa nito ay lalampas sa cost limit ng instance.

Inilalarawan ng sumusunod na video ang pangunahing workflow, gamit ang mga session bilang halimbawa:

Para sa buong detalye tungkol sa mga TTL timer, tingnan ang gabay na Maximum execution time.

Mga susunod na hakbang

Mga Rekomendasyon

• Magpatakbo ng job sa batch mode.
• Magpatakbo ng job sa session mode.
• Pumili ng tamang execution mode.
• Suriin ang mga FAQ sa execution mode.