Introducere în modurile de execuție Qiskit Runtime
Când Qiskit Runtime a fost introdus, utilizatorii puteau executa circuite doar ca joburi individuale. Pe măsură ce au apărut diferite tipuri de sarcini de lucru cuantice, nevoia unor strategii diferite de planificare a devenit evidentă. Modurile de execuție determină modul în care joburile tale sunt planificate, iar alegerea modului de execuție potrivit permite sarcinii tale de lucru să ruleze eficient în limita bugetului tău. Există trei moduri de execuție: job, session și batch.
Modul job
O singură cerere primitivă a Estimator sau a Sampler efectuată fără un context manager. Circuitele și intrările sunt ambalate ca blocuri unificate primitive (PUBs) și trimise ca o sarcină de execuție pe calculatorul cuantic. Pentru a rula în modul job, specifică mode=backend la instanțierea unui primitiv. Vezi Exemple de primitive pentru utilizare.
Modul batch
Un manager multi-job pentru rularea eficientă a experimentelor compuse din sarcini de lucru cu mai multe joburi. Aceste sarcini de lucru sunt alcătuite din joburi executabile independent, care nu au o relație condiționată între ele. Cu modul batch, utilizatorii trimit toate joburile lor deodată.
Sistemul paralelizează sau înlănțuie etapa de pre-procesare (calcul clasic) a fiecărui job primitiv pentru a împacheta mai strâns execuția cuantică între joburi, apoi rulează execuția cuantică a fiecărui job în succesiune rapidă pentru a oferi cele mai eficiente rezultate. Pentru mai multe detalii despre înlănțuire, vezi pagina de întrebări frecvente despre modurile de execuție.
- Când folosești batch, nu este garantat că joburile vor rula în ordinea în care sunt trimise. De asemenea, deși joburile tale batch vor rula cât mai aproape posibil unele de altele, nu obțin acces exclusiv la Backend. Prin urmare, joburile tale batch ar putea rula în paralel cu joburile altor utilizatori dacă există suficientă capacitate de procesare pe QPU. În plus, joburile de calibrare a QPU-ului ar putea rula între joburile din batch.
- Timpul de așteptare în coadă nu scade pentru primul job trimis într-un batch. Prin urmare, batch-urile nu oferă niciun beneficiu atunci când rulezi un singur job.
Pentru a rula în modul batch, specifică mode=batch la instanțierea unui primitiv sau rulează jobul într-un context manager batch. Vezi Rulează joburi într-un batch pentru exemple.
Modul session
O fereastră dedicată pentru rularea unei sarcini de lucru cu mai multe joburi. În această fereastră, utilizatorul are acces exclusiv la sistem și niciun alt job nu poate rula – inclusiv joburi de calibrare. Acest lucru le permite utilizatorilor să experimenteze cu algoritmi variaționali într-un mod mai previzibil și chiar să ruleze mai multe experimente simultan, profitând de paralelismul din stivă. Utilizarea sesiunilor ajută la evitarea întârzierilor cauzate de punerea fiecărui job separat în coadă, ceea ce poate fi deosebit de util pentru sarcinile iterative care necesită comunicare frecventă între resursele clasice și cele cuantice.
Pentru a rula în modul session, specifică mode=session la instanțierea unui primitiv sau rulează jobul într-un context manager session. Vezi Rulează joburi într-o sesiune pentru exemple.
- Timpul de așteptare în coadă nu scade pentru primul job trimis într-o sesiune. Prin urmare, sesiunile nu oferă niciun beneficiu atunci când rulezi un singur job.
- Utilizatorii cu planul Open nu pot trimite joburi de sesiune.
Fluxul de lucru de bază
Fluxul de lucru de bază pentru batch-uri și sesiuni este similar:
- Primul job dintr-un batch sau sesiune intră în coada normală. Pentru batch-uri, întregul set de joburi este planificat împreună.
- Când primul job începe să ruleze, cronometrul pentru timpul maxim de viață (TTL) pornește și nu se oprește sau întrerupe până când se ajunge la final.
- Cronometrul TTL interactiv pornește după finalizarea fiecărui job. Dacă nu există joburi ale sarcinii de lucru pregătite în fereastra TTL interactivă, sarcina de lucru este dezactivată temporar și selecția normală a joburilor reia. Un job poate reactiva sarcina de lucru dezactivată dacă batch-ul sau sesiunea nu a atins valoarea maximă a TTL-ului.
notă
Jobul trebuie să treacă prin coada normală pentru a reactiva sarcina de lucru.
- Dacă se atinge valoarea maximă a TTL-ului, sarcina de lucru se încheie și orice joburi rămase în coadă eșuează. Orice job care rulează curent nu va fi dus la finalizare dacă acest lucru ar depăși limita de cost a instanței.
Următorul video ilustrează fluxul de lucru de bază, folosind sesiunile ca exemplu:
Pentru detalii complete despre cronometrele TTL, vezi ghidul Timpul maxim de execuție.