Întrebări frecvente despre modurile de execuție Qiskit Runtime

Modul de testare locală Qiskit Runtime acceptă diferite moduri de execuție?

Modul de testare locală acceptă sintaxa pentru diferitele moduri de execuție, dar deoarece nu există nicio planificare implicată la testarea locală, modurile sunt ignorate.

Câte joburi pot rula în paralel pentru un Backend specific?

Numărul de joburi care rulează în paralel se bazează pe gradul de paralelism configurat pentru Backend, care este cinci pentru majoritatea Backend-urilor în prezent.

Cum este raportată utilizarea pentru joburile eșuate sau anulate?

Consultă secțiunea Joburi eșuate și anulate de pe pagina Moduri de execuție.

Sessions

Ce se întâmplă cu joburile mele dacă o Session este închisă?

Dacă folosești clasa Session din qiskit-ibm-runtime:

• Session.close() înseamnă că Session nu mai acceptă joburi noi, dar joburile existente rulează până la finalizare.
• Session.cancel() anulează toate joburile Session în așteptare.

Dacă folosești REST API direct:

• PATCH /sessions/{id} cu accepting_jobs=False înseamnă că Session nu mai acceptă joburi noi, dar joburile existente rulează până la finalizare.
• DELETE /sessions/{id}/close anulează toate joburile Session în așteptare.

Dacă folosesc modul Session și mă aștept ca experimentul meu să dureze multe ore, există o modalitate de a solicita efectuarea calibrărilor?

Nu. Calibrarea la cerere nu este disponibilă.

Există un timeout interactiv (TTL interactiv) cu modul Session?

Da. Acesta reduce costurile nedorite dacă un utilizator uită să închidă Session-ul.

Pot schimba TTL-ul interactiv sau TTL-ul maxim al unei Session?

Nu poți modifica valoarea TTL-ului interactiv. Poți modifica valoarea TTL-ului maxim al unei Session (vezi Specifică durata Session-ului), dar trebuie să fie mai mică decât maximul definit de sistem. Cere administratorului tău să contacteze suportul IBM dacă ai nevoie de un TTL interactiv diferit sau de un TTL maxim de sistem diferit.

Cum afectează utilizarea Session membrii IBM Quantum Network care nu sunt facturați în funcție de utilizare?

Membrii IBM Quantum Network câștigă capacitate rezervată pe QPU-urile IBM Quantum®. Utilizarea este dedusă din această capacitate, iar instanțele cu capacitate mai mică au timpi de așteptare în coadă mai lungi.

Obțin același paralelism în modul Session pe care îl obțin cu modul batch?

Da. Dacă trimiți mai multe joburi simultan într-o Session, aceste joburi vor rula în paralel.

Pot fi Session-urile întrerupte de actualizări ale QPU sau calibrări?

Nu. Session-urile rulează în mod dedicat, ceea ce înseamnă că utilizatorul are acces total la Backend. Session-urile nu sunt niciodată întrerupte de calibrări sau actualizări de software.

Timpul de compilare este contorizat ca utilizare în modul Session?

Da. În modul Session, utilizarea reprezintă timpul de ceas al QPU angajat față de Session. Aceasta începe când primul job al Session-ului pornește și se termină când Session-ul devine inactiv, este închis sau când ultimul job se finalizează, oricare dintre acestea se întâmplă ultima. Astfel, utilizarea continuă să se acumuleze după ce o Session se termină dacă QPU-ul încă rulează un job. În plus, timpul după finalizarea unui job în timp ce QPU-ul așteaptă un alt job al Session-ului (TTL-ul interactiv) contează ca utilizare. De aceea ar trebui să te asiguri că Session-ul este închis imediat ce ai terminat de trimis joburi la acesta.

Batch

Câte joburi rulează în paralel în modul batch?

Numărul de joburi care rulează în paralel se bazează pe gradul de paralelism configurat pentru Backend, care este cinci pentru majoritatea Backend-urilor. Cu toate acestea, numărul de joburi concurente dintr-un batch activ ar putea fi mai mic, deoarece ar putea exista alte joburi deja în rulare când batch-ul devine activ.

Cum diferă rularea a N PUB-uri în modul job față de rularea a N joburi cu un singur PUB în modul batch?

Principala diferență constă în compromisul dintre timp și cost:

Modul batch:

• Timpul total de rulare este mai mic deoarece procesarea clasică ar putea rula în paralel.
• Există un mic overhead pentru rularea fiecărui job, deci vei plăti puțin mai mult pentru joburile în batch. Acest overhead corelează cu dimensiunea jobului. De exemplu, utilizarea totală a două joburi, fiecare conținând 40 de circuite de 100x100, este cu șase secunde mai mare decât a unui singur job care conține 80 de circuite.
• Deoarece modul batch nu îți oferă acces exclusiv la un Backend, joburile dintr-un batch ar putea rula împreună cu joburile altor utilizatori sau cu joburi de calibrare.
• Dacă unele joburi eșuează, vei obține totuși rezultate de la joburile finalizate.
• Poți lua măsuri în mijlocul unui workload batch pe baza rezultatelor joburilor finalizate. De exemplu, poți anula restul joburilor dacă rezultatele inițiale par incorecte.

Modul job:

• Timpul total de rulare este probabil mai mare deoarece nu există paralelism.
• Nu plătești pentru overhead-ul suplimentar per job asociat cu workload-urile batch.
• Toate circuitele tale vor rula împreună.
• Dacă acest job unic eșuează, nu vei obține rezultate parțiale.
• Jobul tău ar putea atinge limita dacă conține prea multe circuite sau dacă circuitele sunt prea mari.

În general, dacă fiecare dintre joburile tale consumă mai puțin de un minut de timp QPU, ia în considerare combinarea lor într-un job mai mare (aceasta se aplică tuturor modurilor de execuție).

Câte joburi pot trimite într-un batch?

Deși nu există limite pentru numărul de joburi pe care le poți trimite într-un batch, există un timp maxim asociat unui batch. Adică, atunci când timpul de ceas al unui batch (care începe când primul job din batch începe să ruleze) depășește timpul maxim definit de sistem, batch-ul nu va mai accepta joburi noi, iar orice joburi din coadă care nu rulează sunt anulate. În plus, există limite privind cât de multă utilizare pot consuma joburile tale în funcție de planul tău. Pentru a determina timpul maxim asociat unui batch, folosește metoda batch.details() și caută valoarea max_time.

Când ar rula joburile mele în modul batch în paralel cu joburile altor utilizatori?

Gradul de paralelism configurat pentru un Backend se numește și „execution lanes". Dacă există unul sau mai multe execution lane-uri disponibile și joburile tale batch sunt următoarele la rând, planificatorul pornește suficiente joburi pentru a umple lane-urile. În mod similar, dacă batch-ul tău nu are suficiente joburi pentru a umple lane-urile, planificatorul pornește joburile altor utilizatori.

Exemplu: Backend-ul ales are cinci execution lane-uri, dintre care două sunt ocupate în prezent de joburile altor utilizatori. Batch-ul tău de șase joburi este următorul la rând.

Deoarece există trei lane-uri disponibile, planificatorul pornește trei din cele șase joburi ale batch-ului tău. Continuă să pornească joburi din batch-ul tău pe măsură ce joburile se finalizează și execution lane-urile devin disponibile. Dacă un lane devine disponibil și nu mai există joburi în batch-ul tău, planificatorul pornește următorul job din coadă.

Toate joburile mele din batch trebuie să aștepte în coadă?

Deoarece QPU-urile sunt resurse limitate și partajate, toate joburile trebuie să aștepte în coadă. Cu toate acestea, atunci când primul job din batch-ul tău începe să ruleze, toate celelalte joburi din acel batch sar practic în fața cozii și sunt prioritizate de planificator.

Un batch se termină automat când se termină ultimul job asociat?

Da. Cu toate acestea, există un mic overhead asociat cu această detectare automată, deci ar trebui să închizi întotdeauna batch-ul și Session-ul.

Pot fi batch-urile întrerupte de calibrări sau actualizări de software

Da. Workload-urile batch ar putea fi întrerupte de calibrări sau actualizări de software.

Timpul de compilare este contorizat ca utilizare în modul batch?

Nu. În modul batch, doar timpul petrecut pe hardware-ul cuantic contează ca utilizare.