Vai al contenuto principale

Introduzione alle modalità di esecuzione di Qiskit Runtime

Quando Qiskit Runtime è stato introdotto, gli utenti potevano eseguire i circuiti soltanto come job individuali. Con l'emergere di diversi tipi di workload quantistici, è diventata evidente la necessità di strategie di scheduling differenti. Le modalità di esecuzione determinano come vengono pianificati i tuoi job, e scegliere quella giusta consente al tuo workload di funzionare in modo efficiente nel rispetto del tuo budget. Esistono tre modalità di esecuzione: job, sessione e batch.

Modalità job​

Una singola richiesta primitiva dell'estimator o del sampler effettuata senza un context manager. I circuiti e gli input vengono impacchettati come primitive unified blocs (PUB) e inviati come task di esecuzione al computer quantistico. Per eseguire in modalità job, specifica mode=backend quando istanzi una primitiva. Consulta Esempi di primitive per l'utilizzo.

Modalità batch​

Un gestore multi-job per eseguire in modo efficiente esperimenti composti da workload multi-job. Questi workload sono costituiti da job eseguibili in modo indipendente, senza relazioni condizionali tra loro. Con la modalità batch, gli utenti inviano tutti i job in una volta sola.

Il sistema parallelizza o divide in thread la fase di pre-elaborazione (calcolo classico) di ciascun job primitivo per impacchettare più strettamente l'esecuzione quantistica tra i job, quindi esegue l'esecuzione quantistica di ciascun job in rapida successione per fornire i risultati più efficienti. Per ulteriori dettagli sul threading, consulta la pagina FAQ sulla modalità di esecuzione.

Un insieme di job eseguiti in modalità batch. La parte di calcolo classico di ciascun job avviene simultaneamente, poi tutti i job vengono inviati alla QPU. La QPU è bloccata per il tuo utilizzo dal momento in cui il primo job raggiunge la QPU fino al termine dell'elaborazione dell'ultimo job sulla QPU. Non c'è nessun intervallo tra i job in cui la QPU è inattiva.

Note
  • Durante il batching, non è garantito che i job vengano eseguiti nell'ordine in cui sono stati inviati. Inoltre, anche se i tuoi job batch vengono eseguiti il più vicino possibile tra loro, non hanno accesso esclusivo al backend. Pertanto, i tuoi job batch potrebbero essere eseguiti in parallelo con i job di altri utenti se c'è sufficiente capacità di elaborazione sulla QPU. Inoltre, tra i job in batch potrebbero essere eseguiti job di calibrazione della QPU.
  • Il tempo di accodamento non diminuisce per il primo job inviato all'interno di un batch. Pertanto, i batch non offrono alcun vantaggio quando si esegue un singolo job.

Per eseguire in modalità batch, specifica mode=batch quando istanzi una primitiva oppure esegui il job in un batch context manager. Consulta Eseguire job in un batch per esempi.

Modalità sessione​

Una finestra dedicata per eseguire un workload multi-job. Durante questa finestra, l'utente ha accesso esclusivo al sistema e nessun altro job può essere eseguito, inclusi i job di calibrazione. Ciò consente agli utenti di sperimentare algoritmi variazionali in modo più prevedibile e persino di eseguire più esperimenti contemporaneamente, sfruttando il parallelismo nello stack. L'utilizzo delle sessioni aiuta a evitare i ritardi causati dall'accodamento di ciascun job separatamente, il che può essere particolarmente utile per task iterativi che richiedono frequenti comunicazioni tra risorse classiche e quantistiche.

Un insieme di job eseguiti in modalità sessione e un altro eseguito in modalità batch. Tra ogni job c'è il TTL interattivo (interactive time to live). La finestra attiva inizia quando il primo job parte e termina dopo il completamento dell'ultimo job. Dopo il completamento dell'ultimo job del primo insieme di job, la finestra attiva termina e la sessione viene messa in pausa (ma non chiusa). Un altro insieme di job si avvia poi e i job continuano in modo simile. La QPU è riservata per il tuo utilizzo durante l'intera sessione.

Per eseguire in modalità sessione, specifica mode=session quando istanzi una primitiva, oppure esegui il job in un session context manager. Consulta Eseguire job in una sessione per esempi.

Note
  • Il tempo di accodamento non diminuisce per il primo job inviato all'interno di una sessione. Pertanto, le sessioni non offrono alcun vantaggio quando si esegue un singolo job.
  • Gli utenti del piano Open non possono inviare job di sessione.

Flusso di lavoro di base​

Il flusso di lavoro di base per batch e sessioni è simile:

  1. Il primo job in un batch o in una sessione entra nella coda normale. Per i batch, l'intero insieme di job viene pianificato insieme.
  2. Quando il primo job inizia a essere eseguito, il timer del tempo di vita massimo (TTL) si avvia e non si ferma né si mette in pausa fino al raggiungimento del termine.
  3. Il timer del TTL interattivo si avvia dopo il completamento di ciascun job. Se non ci sono job del workload pronti entro la finestra del TTL interattivo, il workload viene temporaneamente disattivato e la selezione normale dei job riprende. Un job può riattivare il workload disattivato se il batch o la sessione non ha raggiunto il proprio valore TTL massimo.
    nota

    Il job deve passare attraverso la coda normale per riattivare il workload.

  4. Se viene raggiunto il valore TTL massimo, il workload termina e tutti i job in coda rimanenti falliscono. Qualsiasi job attualmente in esecuzione non verrà portato a termine se ciò comportasse il superamento del limite di costo dell'istanza.

Il video seguente illustra il flusso di lavoro di base, usando le sessioni come esempio:

Per tutti i dettagli sui timer TTL, consulta la guida Tempo di esecuzione massimo.

Passi successivi​

Raccomandazioni