Panimula sa mga execution mode ng Qiskit Runtime
Nang ilunsad ang Qiskit Runtime, ang mga user ay makakagawa 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 β ang estimator o ang sampler β 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 Primitives 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 sunud-sunod para maihatid ang pinaka-mahusay na mga resulta. Para sa karagdagang detalye tungkol sa threading, tingnan ang pahina ng Execution mode FAQ.
- 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 magkakasabay 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.
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.
- 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:
- 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.
- 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.
- 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.
- 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.
Ilinalarawan 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.