Job dry-run

Un job dry-run esegue il tuo carico di lavoro tramite IBM Quantum® Compute Service senza usare alcun tempo QPU. Usa un job dry-run per fare quanto segue prima di impegnarti in un'esecuzione reale:

• **Ottenere il consumo che il job comporterebbe sulla QPU reale.

• Convalidare il job. Quantum Compute controlla i parametri del job, nello stesso modo in cui lo fa per un job reale.

• Ottenere la pianificazione temporale del circuito, se la richiedi, per fare il debug del job prima di eseguirlo davvero.

A differenza dei job dry-run, il test locale (backend fake e Qiskit Aer) viene eseguito sul tuo computer e quindi non può fornire dati di consumo, convalida lato servizio o informazioni sulle tempistiche del servizio. Per confrontare i due approcci, consulta Dispositivi mock a confronto con i backend fake.

nota

• Per i job dry-run è richiesto qiskit-ibm-runtime v0.51.0 o successivo.
• I job dry-run sono disponibili in tutte le regioni e solo con i piani Flex, Premium e On-Prem. Non sono disponibili con i piani Open o Pay-As-You-Go.

Come funziona

Per eseguire un job dry-run, passa dry_run=True al metodo run() della primitiva:

backend = service.backend("ibm_phoenix")
isa_circuit = pm.run(circuit)  # transpiled for ibm_phoenix
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()  # wait for completion
print(job.usage())

dry_run è un argomento del metodo run() (il valore predefinito è False), non un'opzione di runtime. È disponibile per tutte le primitive.

Un job dry-run ha le seguenti caratteristiche:

• Viene eseguito in IBM Quantum Compute Service nel cloud, non sul tuo computer.

• Usa i dati di calibrazione della QPU reale, non solo un'istantanea.

• I suoi risultati mantengono lo schema atteso e seguono la forma attesa dei risultati della QPU reale, ma contengono dati mock casuali. Non sono risultati di misura effettivi o simulati, quindi non usarli per verificare la correttezza fisica.

• L'elaborazione avviene sul server, quindi il job potrebbe non terminare immediatamente.

Le dimensioni del circuito, gli shot e gli altri limiti sono gli stessi di qualsiasi job di quel programma.

dry_run=True funziona anche quando il backend è già un dispositivo mock.

Leggere il consumo

Il consumo di un job dry-run completato è il consumo che lo stesso job comporterebbe sulla QPU reale, tranne nei rari casi in cui i dati di calibrazione cambiano in modo significativo dopo il job dry-run e prima del job su una QPU reale.

• job.usage() restituisce il consumo in secondi.

• job.metrics()["usage"] restituisce gli stessi dati insieme allo stato del consumo.

Il consumo dei job dry-run non viene addebitato, non utilizza l'allocazione del tuo piano e non viene conteggiato rispetto ad alcun limite.

Non usare job.usage_estimation con i job dry-run

Non usare job.usage_estimation su un job dry-run. Usa job.usage().

job.usage() restituisce 0 finché il calcolo del consumo non è definitivo, quindi attendi che il job termini prima di leggerlo.

Pianificazione temporale del circuito

Per richiedere la pianificazione temporale del circuito, usa la stessa opzione di un job reale. Per i dettagli completi, consulta Visualizzare le tempistiche del circuito.

Limitazioni

• Solo job mode e batch mode. I job dry-run possono essere eseguiti solo in job mode e batch mode.

• Solo piani Flex, Premium e On-Prem. I job dry-run non sono disponibili con i piani Open o Pay-As-You-Go.

Dispositivi mock

I dispositivi mock sono l'implementazione alla base dei job dry-run. I job dry-run nascondono i dispositivi mock per impostazione predefinita, ma li incontri in questi casi:

• Istanze configurate per accedere solo ai dispositivi mock. Esempio: se usi service.backend("ibm_phoenix") per inviare un job dry-run su ibm_phoenix, ma la tua istanza non ha accesso a ibm_phoenix, otterrai un QiskitBackendNotFoundError. Seleziona invece direttamente il dispositivo mock con service.backend("mock_phoenix").

• Risorse di calcolo. I dispositivi mock sono nascosti per impostazione predefinita nella pagina Compute resources. La tabella nella pagina ha un'opzione di filtro per includerli, ma solo i piani Flex, Premium e On-Prem hanno accesso ai dispositivi mock.

• Tabella dei carichi di lavoro. I job dei dispositivi mock sono nascosti per impostazione predefinita nella pagina Workloads. La tabella ha un'opzione di filtro (l'icona a imbuto) per mostrarli.

• API Python. service.backends() e service.jobs() escludono i dispositivi mock a meno che tu non li chiami con include_mocks=True. IBMBackend.is_mock indica se un backend è un dispositivo mock. service.least_busy() non restituisce mai un dispositivo mock.

Dispositivi mock a confronto con i backend fake

I nomi sono simili, ma un dispositivo mock e un backend fake sono cose diverse. Un backend fake è un oggetto locale nel tuo ambiente Python. Un dispositivo mock è una risorsa cloud in IBM Quantum Compute Service.

	Dispositivo mock (ad esempio mock_phoenix)	Backend fake (ad esempio FakeManilaV2)
Cos'è	Un dispositivo in IBM Quantum Compute Service	Una classe Python in qiskit_ibm_runtime.fake_provider
Dove viene eseguito	Nel cloud, nel servizio	In locale, sul tuo computer
Come ottenerlo	service.backend("mock_phoenix"), oppure automaticamente con run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Account e istanza	Solo piani specifici (Flex, Premium o On-Prem)	Tutte le istanze e tutti i piani
Calibrazione	In tempo reale, corrisponde in ogni momento al dispositivo reale	Istantanea fissa fornita con il pacchetto installato
Risultati	Dati casuali con lo schema atteso. Non è una simulazione	Simulazione rumorosa che usa il modello di rumore dell'istantanea
Risultati fisicamente significativi	No. Non usarli mai per verificare la correttezza	Approssimativamente, entro i limiti del modello di rumore
Consumo riportato	Sì	Nessuno
Addebitato o conteggiato rispetto all'allocazione del piano o ai limiti	No	No
Convalida del job	Eseguita dal servizio, come per un job reale	Limitata a ciò che controlla il client
Pianificazione temporale	Disponibile su richiesta	Non disponibile
Modalità di esecuzione	Solo job mode e batch mode. Le sessioni sono bloccate	Sintassi di sessione accettata ma ignorata (la modalità locale non ha vere sessioni o batch)
Completamento	Asincrono, sul server	Viene eseguito in locale e restituisce il risultato al termine
Mostrato nell'interfaccia della piattaforma e negli elenchi API	Nascosto per impostazione predefinita (Compute resources, tabella Workloads, backends(), jobs()). Attivabile su richiesta	Mai, perché nulla viene inviato al servizio

Come scegliere

• Per scoprire quanto consumo userà il job, o se il servizio lo accetterà, usa un job dry-run.

• Per scoprire che aspetto potrebbe avere l'output, o per lavorare offline, usa un backend fake o Aer.

• Per fare entrambe le cose, itera su circuiti e risultati con un backend fake, poi usa il dry-run come ultimo controllo prima della QPU reale.

Punti di confusione comuni

• Un dispositivo mock non è un simulatore. Il suo output è casuale, quindi campionare un circuito di Bell su mock_phoenix non restituisce una distribuzione di Bell. Se vuoi un output rumoroso realistico, usa un backend fake.

• Un backend fake non è il dispositivo reale. La sua calibrazione è un'istantanea e potrebbe essere obsoleta. Un dispositivo mock segue la calibrazione reale, quindi i circuiti transpilati e le tempistiche corrispondono a ciò che la QPU vede oggi.

• Nessuno dei due viene eseguito su hardware reale. Nessuno dei due consuma tempo QPU, ma solo un job dry-run passa attraverso il servizio.

• usage_estimation non è la stima del dry-run. Per un job dry-run, job.usage() restituisce i secondi di consumo che ti verrebbero addebitati su una QPU reale.

Casi d'uso

Studenti e corsi

Un amministratore limita un'istanza ai soli dispositivi mock, usando l'interruttore di personalizzazione della QPU quando crea o modifica l'istanza. Gli studenti possono così convalidare i loro payload end-to-end senza consumare tempo QPU reale o RU. Poiché l'istanza ha accesso solo ai dispositivi mock, gli studenti selezionano il backend tramite il suo nome mock:

backend = service.backend("mock_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)

Pianificazione del progetto

Un team che sta per iniziare un progetto esegue in dry-run job rappresentativi per vedere le RU di cui il progetto ha bisogno, prima di scegliere un piano o un'allocazione:

backend = service.backend("ibm_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()
print(job.usage()) 

Controllo finale prima dell'esecuzione su una QPU reale

Convalida i parametri e ispeziona la pianificazione temporale con dry_run=True, poi rimuovi l'argomento ed esegui sulla QPU reale. Nient'altro nel tuo codice cambia:

sampler = Sampler(mode=backend)

# Pre-flight check
job = sampler.run([isa_circuit], dry_run=True)
job.result()

# Real run - same code, without dry_run
job = sampler.run([isa_circuit])

Passi successivi

Consigli

• Testa i programmi sul tuo computer con la modalità di test locale.
• Scopri come viene misurato il consumo del carico di lavoro.
• Visualizza la pianificazione temporale del circuito.
• Comprendi le unità di risorse e i piani disponibili.