Mga FAQ sa Qiskit Runtime execution modes

Sinusuportahan ba ng Qiskit Runtime local testing mode ang iba't ibang execution mode?

Sinusuportahan ng local testing mode ang syntax para sa iba't ibang execution mode, pero dahil walang scheduling kapag nagtatest nang lokal, hindi pinapansin ang mga mode.

Ilang job ang maaaring tumakbo nang sabay-sabay para sa isang partikular na backend?

Ang bilang ng mga job na tumatakbo nang sabay-sabay ay nakabatay sa degree of parallelism na naka-configure para sa backend, na limang (5) para sa karamihan ng mga backend ngayon.

Paano inirerepresenta ang usage para sa mga nabigo o kinansela na job?

Tingnan ang seksyong Failed and canceled jobs sa pahina ng Execution modes.

Mga Session

Ano ang mangyayari sa aking mga job kung isasara ang isang session?

Kung ginagamit mo ang Session class sa qiskit-ibm-runtime:

• Ang Session.close() ay nangangahulugang hindi na tatanggap ng mga bagong job ang session, pero ang mga kasalukuyang job ay tatakbo hanggang matapos.
• Ang Session.cancel() ay nagkakansela ng lahat ng mga nakabinbing session job.

Kung direkta kang gumagamit ng REST API:

• Ang PATCH /sessions/{id} na may accepting_jobs=False ay nangangahulugang hindi na tatanggap ng mga bagong job ang session, pero ang mga kasalukuyang job ay tatakbo hanggang matapos.
• Ang DELETE /sessions/{id}/close ay nagkakansela ng lahat ng mga nakabinbing session job.

Kung gumagamit ako ng session mode at inaasahan kong maraming oras ang aabutin ng aking eksperimento, may paraan ba para humiling ng calibration?

Wala. Hindi available ang on-demand calibration.

May interactive timeout (interactive TTL) ba sa session mode?

Oo. Nababawasan nito ang hindi gustong gastos kung nakalimutan ng isang user na isara ang kanilang session.

Maaari ko bang baguhin ang interactive TTL o ang maximum TTL ng isang session?

Hindi mo maaaring baguhin ang interactive TTL value. Maaari mong baguhin ang maximum TTL value ng isang session (tingnan ang Specify the session length), pero kailangan itong mas mababa sa system-defined maximum. Makipag-ugnayan sa iyong administrator para makipag-ugnayan sa IBM support kung kailangan mo ng ibang interactive TTL o system maximum TTL.

Paano nakakaapekto ang session usage sa mga miyembro ng IBM Quantum Network na hindi sisingilin ayon sa usage?

Ang mga miyembro ng IBM Quantum Network ay nakakakuha ng nakalaan na kapasidad sa mga IBM Quantum® QPU. Ang usage ay ibinabawas mula sa kapasyagang ito at ang mga instance na may mas mababang kapasidad ay may mas matagal na oras sa pila.

Makukuha ko ba ang parehong parallelism sa session mode na nakukuha ko sa batch mode?

Oo. Kung mag-susumit ka ng maraming job nang sabay-sabay sa isang session, ang mga job na ito ay tatakbo nang sabay-sabay.

Maaari bang maantala ang mga session ng mga pag-upgrade ng QPU o calibration?

Hindi. Tumatakbo ang mga session sa dedicated mode, na nangangahulugang may ganap na access ang user sa backend. Hindi kailanman naaantala ang mga session ng mga calibration o software upgrade.

Binibilang ba ang oras ng compilation bilang usage sa session mode?

Oo. Sa session mode, ang usage ay ang wall clock time na nakalaan ang QPU para sa session. Nagsisimula ito kapag nagsimula ang unang session job at nagtatapos kapag naging inactive ang session, nasara, o kapag natapos ang huling job, alinman ang mangyari huli. Kaya naman, patuloy na naiiipon ang usage pagkatapos matapos ang isang session kung tumatakbo pa rin ang isang job ang QPU. Bukod dito, ang oras pagkatapos matapos ang isang job habang naghihintay ang QPU para sa isa pang session job (ang interactive TTL) ay binibilang bilang usage. Kaya naman dapat mo itong tiyakin na ang session ay nasara kaagad pagkatapos mong matapos sa pagsusumit ng mga job dito.

Batch

Ilang job ang tumatakbo nang sabay-sabay sa batch mode?

Ang bilang ng mga job na tumatakbo nang sabay-sabay ay nakabatay sa degree of parallelism na naka-configure para sa backend, na limang (5) para sa karamihan ng mga backend. Gayunpaman, ang bilang ng mga sabay-sabay na job sa isang aktibong batch ay maaaring mas mababa dahil maaaring may iba pang mga job na tumatakbo na kapag naging aktibo ang batch.

Ano ang pagkakaiba ng pagpapatakbo ng N na PUB sa job mode kumpara sa pagpapatakbo ng N na single-PUB na job sa batch mode?

Ang pangunahing pagkakaiba ay ang tradeoff ng oras at gastos:

Batch mode:

• Mas mababa ang kabuuang run time dahil maaaring tumakbo nang sabay-sabay ang classical processing.
• May kaunting overhead para sa bawat job na pinapatakbo, kaya medyo mas magastos ang mga batched na job. Ang overhead na ito ay may kaugnayan sa laki ng job. Halimbawa, ang kabuuang usage ng dalawang job, bawat isa ay naglalaman ng 40 100x100 na circuit, ay anim na segundo na mas matagal kaysa sa isang job na naglalaman ng 80 na circuit.
• Dahil hindi nagbibigay ng eksklusibong access sa isang backend ang batch mode, maaaring tumakbo ang mga job sa loob ng isang batch kasabay ng mga job ng ibang user o calibration job.
• Kung nabigo ang ilang job, makukuha mo pa rin ang mga resulta mula sa mga nakumpletong job.
• Maaari kang kumilos sa gitna ng isang batch workload batay sa mga resulta ng mga nakumpletong job. Halimbawa, maaari mong i-cancel ang natitirang mga job kung ang mga paunang resulta ay mukhang mali.

Job mode:

• Malamang na mas mataas ang kabuuang run time dahil walang parallelism.
• Hindi ka nagbabayad para sa karagdagang per-job overhead na kaugnay ng mga batch workload.
• Lahat ng iyong circuit ay tatakbo nang magkasama.
• Kung nabigo ang iisang job na ito, hindi ka makakakuha ng mga partial na resulta.
• Maaaring maabot ng iyong job ang limit kung naglalaman ito ng napakaraming circuit o kung masyadong malaki ang mga circuit.

Sa pangkalahatan, kung ang bawat isa sa iyong mga job ay kumokonsumo ng mas mababa sa isang minuto ng QPU time, isaalang-alang ang pagsasama ng mga ito sa isang mas malaking job (naaangkop ito sa lahat ng execution mode).

Ilang job ang maaari kong isumit sa isang batch?

Habang walang limitasyon sa bilang ng mga job na maaari mong isumit sa isang batch, may maximum na oras na kaugnay ng isang batch. Ibig sabihin, kapag lumampas ang wall clock time ng isang batch (na nagsisimula kapag nagsimula ang unang batch job na tumakbo) sa system-defined maximum na oras, hindi na tatanggap ng mga bagong job ang batch, at ang anumang job na nakapila ngunit hindi pa tumatakbo ay ika-cancel. Bukod dito, may mga limitasyon sa dami ng usage na maaaring konsumahin ng iyong mga job batay sa iyong plano. Para malaman ang maximum na oras na kaugnay ng isang batch, gamitin ang batch.details() method at hanapin ang max_time na value.

Kailan magsasabay ang aking mga batch mode job sa mga job ng ibang user?

Ang degree of parallelism na naka-configure para sa isang backend ay tinatawag din na "execution lanes". Kung may isa o higit pang execution lane na available, at ang iyong mga batch job ay susunod na sa pila para patakbuhin, nagsisimula ang scheduler ng sapat na mga job para mapuno ang mga lane. Gayundin, kung hindi sapat ang mga job ng iyong batch para mapuno ang mga lane, nagsisimula ang scheduler ng mga job ng ibang user.

Halimbawa: Ang backend na pinili mo ay may limang execution lane, at dalawa sa mga ito ay kasalukuyang ginagamit ng mga job ng ibang user. Ang iyong batch na may anim na job ay susunod sa pila.

Dahil may tatlong available na lane, nagsisimula ang scheduler ng tatlo sa iyong anim na batch job. Patuloy itong nagpapaandar ng mga job sa iyong batch habang nagtatapos ang mga job at nagiging available ang mga execution lane. Kung may magiging available na lane at wala nang job sa iyong batch, sisimulan ng scheduler ang susunod na job sa pila.

Kailangan bang pumila ang lahat ng aking batch job?

Dahil limitado at shared na resource ang mga QPU, lahat ng job ay kailangang pumila. Gayunpaman, kapag nagsimulang tumakbo ang unang job sa iyong batch, ang lahat ng iba pang job sa batch na iyon ay halos lumalaktaw sa harap ng pila at pinipili ng scheduler.

Awtomatiko bang nagtatapos ang isang batch kapag natapos na ang huling kaugnay na job?

Oo. Gayunpaman, may kaunting overhead na kaugnay ng auto-detection na ito, kaya dapat mong laging isara ang iyong batch at session.

Maaari bang maantala ang mga batch ng mga calibration o software upgrade?

Oo. Maaaring maantala ang mga batch workload ng mga calibration o software upgrade.

Binibilang ba ang oras ng compilation bilang usage sa batch mode?

Hindi. Sa batch mode, ang oras lamang na ginugugol sa quantum hardware ang binibilang bilang usage.