FAQ sulle modalità di esecuzione di Qiskit Runtime

La modalità di test locale di Qiskit Runtime supporta le diverse modalità di esecuzione?

La modalità di test locale supporta la sintassi delle diverse modalità di esecuzione, ma poiché non è prevista alcuna pianificazione durante i test in locale, le modalità vengono ignorate.

Quanti job possono essere eseguiti in parallelo per un backend specifico?

Il numero di job eseguiti in parallelo dipende dal grado di parallelismo configurato per il backend, che è cinque per la maggior parte dei backend attualmente disponibili.

Come viene riportato l'utilizzo per i job falliti o annullati?

Consulta la sezione Job falliti e annullati nella pagina delle modalità di esecuzione.

Sessioni

Cosa succede ai miei job se una sessione viene chiusa?

Se stai usando la classe Session in qiskit-ibm-runtime:

• Session.close() significa che la sessione non accetta più nuovi job, ma quelli esistenti vengono portati a termine.
• Session.cancel() annulla tutti i job della sessione in attesa.

Se stai usando direttamente la REST API:

• PATCH /sessions/{id} con accepting_jobs=False significa che la sessione non accetta più nuovi job, ma quelli esistenti vengono portati a termine.
• DELETE /sessions/{id}/close annulla tutti i job della sessione in attesa.

Se sto usando la modalità sessione e mi aspetto che il mio esperimento richieda molte ore, è possibile richiedere l'esecuzione di calibrazioni?

No. La calibrazione su richiesta non è disponibile.

È previsto un timeout interattivo (interactive TTL) con la modalità sessione?

Sì. Questo riduce i costi indesiderati nel caso in cui un utente dimentichi di chiudere la propria sessione.

Posso modificare l'interactive TTL o il TTL massimo di una sessione?

Non è possibile modificare il valore dell'interactive TTL. Puoi modificare il valore del TTL massimo di una sessione (vedi Specificare la durata della sessione), ma deve essere inferiore al massimo definito dal sistema. Chiedi al tuo amministratore di contattare il supporto IBM se hai bisogno di un interactive TTL o di un TTL massimo di sistema diverso.

In che modo l'utilizzo delle sessioni influisce sui membri di IBM Quantum Network che non vengono addebitati in base all'utilizzo?

I membri di IBM Quantum Network ottengono capacità riservata sulle QPU di IBM Quantum®. L'utilizzo viene dedotto da questa capacità e le istanze con capacità inferiore hanno tempi di attesa in coda più lunghi.

Ottengo lo stesso parallelismo in modalità sessione che ottengo con la modalità batch?

Sì. Se invii più job contemporaneamente in una sessione, questi job verranno eseguiti in parallelo.

Le sessioni possono essere interrotte da aggiornamenti o calibrazioni della QPU?

No. Le sessioni vengono eseguite in modalità dedicata, il che significa che l'utente ha accesso totale al backend. Le sessioni non vengono mai interrotte da calibrazioni o aggiornamenti software.

Il tempo di compilazione viene conteggiato come utilizzo in modalità sessione?

Sì. In modalità sessione, l'utilizzo corrisponde al tempo effettivo in cui la QPU è impegnata nella sessione. Inizia quando parte il primo job della sessione e termina quando la sessione diventa inattiva, viene chiusa, o quando l'ultimo job viene completato, a seconda di quale evento avviene per ultimo. Di conseguenza, l'utilizzo continua ad accumularsi dopo la fine di una sessione se la QPU sta ancora eseguendo un job. Inoltre, il tempo successivo al completamento di un job durante l'attesa di un altro job nella sessione (l'interactive TTL) viene conteggiato come utilizzo. Per questo motivo dovresti assicurarti che la sessione venga chiusa non appena hai finito di inviarle job.

Batch

Quanti job vengono eseguiti in parallelo in modalità batch?

Il numero di job eseguiti in parallelo dipende dal grado di parallelismo configurato per il backend, che è cinque per la maggior parte dei backend. Tuttavia, il numero di job concorrenti in un batch attivo potrebbe essere inferiore perché potrebbero esserci altri job già in esecuzione quando il batch diventa attivo.

Qual è la differenza tra eseguire N PUB in modalità job e N job con un singolo PUB in modalità batch?

La differenza principale riguarda il compromesso tra tempo e costo:

Modalità batch:

• Il tempo di esecuzione totale è inferiore perché l'elaborazione classica può avvenire in parallelo.
• C'è un leggero overhead per l'esecuzione di ciascun job, quindi finisci per pagare un po' di più per i job in batch. Questo overhead è correlato alla dimensione del job. Ad esempio, l'utilizzo totale di due job, ciascuno contenente 40 circuiti 100x100, è di sei secondi in più rispetto a un singolo job contenente 80 circuiti.
• Poiché la modalità batch non ti garantisce accesso esclusivo a un backend, i job all'interno di un batch potrebbero essere eseguiti insieme ai job di altri utenti o a job di calibrazione.
• Se alcuni job falliscono, ottieni comunque i risultati dei job completati.
• Puoi intervenire nel mezzo di un workload batch in base ai risultati dei job completati. Ad esempio, puoi annullare il resto dei job se i risultati iniziali sembrano incorretti.

Modalità job:

• Il tempo di esecuzione totale è probabilmente più alto perché non c'è parallelismo.
• Non paghi l'overhead per-job aggiuntivo associato ai workload in batch.
• Tutti i tuoi circuiti verranno eseguiti insieme.
• Se questo singolo job fallisce, non ottieni risultati parziali.
• Il tuo job potrebbe raggiungere il limite se contiene troppi circuiti o se i circuiti sono troppo grandi.

In generale, se ciascuno dei tuoi job consuma meno di un minuto di tempo QPU, considera di combinarli in un job più grande (questo vale per tutte le modalità di esecuzione).

Quanti job posso inviare in un batch?

Pur non essendo previsti limiti al numero di job che puoi inviare in un batch, esiste un tempo massimo associato a un batch. Ovvero, quando il tempo effettivo di un batch (che inizia quando il primo job del batch comincia a essere eseguito) supera il tempo massimo definito dal sistema, il batch non accetterà nuovi job e tutti i job in coda ma non ancora in esecuzione verranno annullati. Inoltre, esistono limiti alla quantità di utilizzo che i tuoi job possono consumare in base al tuo piano. Per determinare il tempo massimo associato a un batch, usa il metodo batch.details() e cerca il valore max_time.

In quali casi i miei job in modalità batch vengono eseguiti in parallelo con i job di altri utenti?

Il grado di parallelismo configurato per un backend è anche chiamato "corsie di esecuzione" (execution lanes). Se sono disponibili una o più corsie di esecuzione e i tuoi job in batch sono i prossimi in fila, lo scheduler avvia abbastanza job da riempire le corsie. Analogamente, se il tuo batch non ha abbastanza job per riempire le corsie, lo scheduler avvia i job di altri utenti.

Esempio: il backend scelto dispone di cinque corsie di esecuzione, due delle quali sono attualmente occupate da job di altri utenti. Il tuo batch di sei job è il prossimo in fila.

Poiché ci sono tre corsie disponibili, lo scheduler avvia tre dei tuoi sei job in batch. Continua ad avviare job del tuo batch man mano che i job terminano e le corsie di esecuzione si liberano. Se una corsia si libera e non ci sono più job nel tuo batch, lo scheduler avvia il job successivo in fila.

Tutti i miei job in batch devono attendere in coda?

Poiché le QPU sono risorse limitate e condivise, tutti i job devono attendere in coda. Tuttavia, quando il primo job del tuo batch inizia a essere eseguito, tutti gli altri job di quel batch passano essenzialmente in cima alla coda e vengono prioritizzati dallo scheduler.

Un batch termina automaticamente quando termina l'ultimo job associato?

Sì. Tuttavia, c'è un leggero overhead associato a questo rilevamento automatico, quindi dovresti sempre chiudere esplicitamente il tuo batch e la tua sessione.

I batch possono essere interrotti da calibrazioni o aggiornamenti software?

Sì. I workload in batch potrebbero essere interrotti da calibrazioni o aggiornamenti software.

Il tempo di compilazione viene conteggiato come utilizzo in modalità batch?

No. In modalità batch, viene conteggiato come utilizzo solo il tempo trascorso sull'hardware quantistico.