Skip to main content
IBM Quantum Platform

Modalità di esecuzione FAQ

  • La modalità di test locale supporta la sintassi per le diverse modalità di esecuzione, ma poiché il test locale non prevede una programmazione, le modalità vengono ignorate.

  • Il numero di lavori in esecuzione in parallelo si basa sul grado di parallelismo configurato per il backend, che oggi è pari a cinque per la maggior parte dei backend.

  • Vedere la sezione Lavori falliti e annullati nella pagina Modalità di esecuzione.


Sessioni

  • Se si utilizza la classe Session in qiskit-ibm-runtime:

    • Session.close() significa che la sessione non accetta più nuovi lavori, ma quelli esistenti vengono eseguiti fino al completamento.
    • Session.cancel() annulla tutti i lavori di sessione in corso.

    Se si utilizza direttamente l'API REST:

    • PATCH /sessions/{id} con accepting_jobs=False significa che la sessione non accetta più nuovi lavori, ma quelli esistenti vengono eseguiti fino al completamento.
    • DELETE /sessions/{id}/close annulla tutti i lavori di sessione in corso.
  • Num. La calibrazione su richiesta non è disponibile.

  • Sì. In questo modo si riducono i costi indesiderati se un utente dimentica di chiudere la sessione.

  • Non è possibile modificare il valore TTL interattivo. È possibile modificare il valore TTL massimo di una sessione (vedere Specificare la lunghezza della sessione ), ma deve essere inferiore al massimo definito dal sistema. Chiedere all'amministratore di contattare il supporto di IBM se è necessario un TTL interattivo o un TTL massimo di sistema diverso.

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

  • Sì. Se si inviano più lavori contemporaneamente in una sessione, questi lavori verranno eseguiti in parallelo.

  • Num. 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 del software.

  • Sì. In modalità sessione, l'utilizzo è l'ora dell'orologio a muro in cui la QPU è impegnata nella sessione. Inizia quando viene avviato il primo lavoro di sessione e termina quando la sessione diventa inattiva, viene chiusa o quando viene completato l'ultimo lavoro, a seconda di quale sia l' ultimo. Pertanto, l'utilizzo continua ad accumularsi dopo la fine di una sessione se la QPU sta ancora eseguendo un lavoro. Inoltre, il tempo trascorso dopo il completamento di un lavoro mentre la QPU attende un altro lavoro di sessione (il TTL interattivo) conta come utilizzo. Per questo motivo è necessario assicurarsi che la sessione venga chiusa non appena si è terminato di inviarle i lavori.


Batch

  • Il numero di lavori in esecuzione in parallelo si basa sul grado di parallelismo configurato per il backend, che è cinque per la maggior parte dei backend. Tuttavia, il numero di lavori contemporanei in un batch attivo potrebbe essere inferiore perché potrebbero esserci altri lavori già in esecuzione quando il batch diventa attivo.

  • La differenza principale è il compromesso tra tempo e costi:

    Modalità batch:

    • Il tempo di esecuzione totale è inferiore perché l'elaborazione classica può essere eseguita in parallelo.
    • L'esecuzione di ogni singolo processo comporta un leggero sovraccarico, quindi i processi in batch risultano leggermente più costosi rispetto all'esecuzione di tutti i circuiti in un unico processo.
    • Poiché la modalità batch non dà accesso esclusivo a un backend, i lavori all'interno di un batch potrebbero essere eseguiti insieme a lavori di altri utenti o a lavori di calibrazione.
    • Se alcuni lavori falliscono, si ottengono comunque i risultati dei lavori completati.
    • È possibile intervenire nel mezzo di un carico di lavoro batch in base ai risultati dei lavori completati. Ad esempio, è possibile annullare il resto dei lavori se i risultati iniziali non sembrano corretti.

    Modalità di lavoro:

    • Il tempo di esecuzione totale sarà probabilmente più alto perché non c'è parallelismo.
    • Non si paga l'overhead extra per lavoro associato ai carichi di lavoro batch.
    • Tutti i circuiti funzioneranno insieme.
    • Se questo singolo lavoro fallisce, non si ottengono risultati parziali.
    • Il lavoro potrebbe raggiungere il limite se contiene troppi circuiti o se i circuiti sono troppo grandi.

    In generale, se ogni lavoro consuma meno di un minuto di tempo della QPU, si consiglia di combinarli in un lavoro più grande (questo vale per tutte le modalità di esecuzione).

  • Sebbene non vi siano limiti al numero di lavori che si possono inviare in un batch, esiste un tempo massimo associato a un batch. Cioè, quando il tempo dell'orologio a muro di un batch (che inizia quando il primo lavoro del batch viene eseguito) supera il tempo massimo definito dal sistema, il batch non accetta nuovi lavori e tutti i lavori in coda ma non in esecuzione vengono annullati. Inoltre, in base al vostro piano, ci sono dei limiti di utilizzo per i vostri lavori. Per determinare il tempo massimo associato a un batch, utilizzare il metodo batch.details() e cercare il valore max_time .

  • Il grado di parallelismo configurato per un backend è chiamato anche "corsie di esecuzione". Se sono disponibili una o più corsie di esecuzione e i lavori batch sono i prossimi ad essere eseguiti, lo scheduler avvia un numero di lavori sufficiente a riempire le corsie. Allo stesso modo, se il batch non ha abbastanza lavori per riempire le corsie, lo scheduler avvia i lavori di altri utenti.

    Esempio: Il backend scelto ha cinque corsie di esecuzione e due di esse sono attualmente occupate da lavori di altri utenti. Il vostro batch di sei lavori è il prossimo ad essere eseguito.

    Poiché ci sono tre corsie disponibili, lo scheduler avvia tre dei sei lavori batch. Continua ad avviare i lavori del batch man mano che i lavori vengono terminati e le corsie di esecuzione si rendono disponibili. Se si libera una corsia e non ci sono altri lavori nel batch, lo scheduler avvia il lavoro successivo.

  • Poiché le QPU sono risorse limitate e condivise, tutti i lavori devono attendere in coda. Tuttavia, quando il primo lavoro del batch inizia a essere eseguito, tutti gli altri lavori di quel batch passano essenzialmente in testa alla coda e sono prioritari per lo scheduler.

  • Sì. Tuttavia, c'è un leggero sovraccarico associato a questo rilevamento automatico, quindi si dovrebbe sempre chiudere il batch e la sessione.

  • Sì. I carichi di lavoro batch potrebbero essere interrotti da calibrazioni o aggiornamenti del software.

  • Num. In modalità batch, solo il tempo trascorso sull'hardware quantistico conta come utilizzo.

Questa pagina è stata utile?
Segnala un bug, un errore di battitura o richiedi contenuti su GitHub.