Guide
La tua prima esecuzione su un vero computer quantistico con Qiskit
Una guida passo passo all’Open Plan gratuito di IBM: account e limiti, installazione di Qiskit, un circuito con uno stato di Bell, esecuzioni sul simulatore e sul simulatore con rumore, poi l’esecuzione sull’hardware e come leggere i conteg
Gabriele Masetti ·
Cosa serve prima di usare un computer quantistico
Una prima esecuzione su un vero computer quantistico richiede circa un’ora e non costa nulla. L’Open Plan di IBM offre a chiunque abbia un account la possibilità di usare i suoi processori superconduttori, mentre Qiskit, il toolkit Python open source di IBM, si occupa del resto. La lezione più utile è vedere perché lo stesso circuito di quattro righe produce conteggi senza errori su un portatile e conteggi leggermente alterati dal rumore su un chip.
Servono un terminale, un’installazione funzionante di Python e un indirizzo email. Non occorrono conoscenze di fisica, oltre a sapere che la misura di un qubit può dare 0 o 1. Il codice è stato eseguito in un ambiente virtuale appena creato, con Qiskit 2.6.0, qiskit-aer 0.18.0 e qiskit-ibm-runtime 0.50.0; i numeri riportati provengono da quelle esecuzioni.
Una precisazione vale per tutta la guida. I passaggi locali (costruzione del circuito, simulazione, transpilazione e modello di rumore) sono stati eseguiti, e gli output riportati provengono da quelle esecuzioni. Il passaggio sull’hardware usa esattamente le chiamate documentate da IBM. I tuoi conteggi saranno diversi da quelli di qualsiasi esempio, perché ogni esecuzione su un chip reale è un nuovo campionamento di un processo fisico soggetto a rumore.
Cosa offre l’Open Plan, e cosa no
IBM enuncia la condizione principale nella documentazione dei suoi piani: gli utenti possono «eseguire gratuitamente i propri circuiti quantistici sulle migliori QPU al mondo (fino a 10 minuti in una finestra mobile di 28 giorni)». La parola importante è «mobile»: i minuti consumati tornano disponibili 28 giorni dopo che li hai usati.
Le istanze dell’Open Plan possono essere create solo nella regione us-east: per questo, quando crei l’istanza, devi fare attenzione al menu delle regioni nella dashboard. Puoi controllare il consumo nella dashboard della Platform e nella pagina Workloads. IBM descrive il piano come destinato a «chi sta imparando la computazione quantistica ed esplorando la tecnologia quantistica di IBM».
Una promozione offre più margine. Secondo la documentazione di IBM, dal 16 marzo 2026 gli utenti attivi dell’Open Plan possono scegliere di ottenere altri 180 minuti nei successivi 12 mesi. Il post con cui IBM ha annunciato la promozione, pubblicato lo stesso giorno, ne precisa le condizioni: può aderire chi ha un account non di prova e ha usato 20 minuti di tempo di esecuzione in un qualsiasi periodo di 12 mesi; trascorsi i 12 mesi, il piano torna a 10 minuti.
Quantum Computing Report, una testata di settore indipendente, ha descritto l’offerta il 20 marzo 2026 come una promozione una tantum per gli utenti che avevano usato almeno 20 minuti in un periodo di 12 mesi, con minuti concessi su base annuale anziché mensile. Le due fonti concordano sui numeri. Poiché IBM modifica di tanto in tanto le condizioni dei piani, il giorno in cui ti iscrivi fai riferimento alla pagina dei piani.
Dieci minuti sembrano pochi, finché non vedi quanto consuma un piccolo job. Le pagine di IBM descrivono la quota come tempo di utilizzo del processore quantistico, e un circuito a due qubit con circa mille shots è tra i job più piccoli che puoi inviare. Dopo la prima esecuzione, controlla nella pagina Workloads quanto tempo ha effettivamente consumato.
Creare l’account e salvare la chiave
Registrati su quantum.cloud.ibm.com con un account IBM. Quando la piattaforma presenta i suoi piani, scegli l’Open Plan e assicurati di avere un’istanza associata a quel piano. Un’istanza è l’oggetto a cui sono associati il tuo piano e il tuo utilizzo; ogni job che invii è collegato a un’istanza.
Servono due credenziali. La prima è una chiave API lunga 44 caratteri, che crei dalla dashboard. IBM avverte che «il token non sarà più visibile», quindi copialo subito in un posto sicuro. La seconda è il CRN dell’istanza, un lungo identificativo che puoi copiare dalla pagina Instances. Il CRN è facoltativo, ma elimina ogni ambiguità se in seguito avrai più di un’istanza.
Salva le credenziali una volta sola: tutte le sessioni successive potranno riutilizzarle. La chiamata è nella forma documentata da IBM nella guida al salvataggio delle credenziali, e la sua firma corrisponde a quella della libreria installata.
from qiskit_ibm_runtime import QiskitRuntimeService
QiskitRuntimeService.save_account(
token="<your-44-character-api-key>",
instance="<your-instance-CRN>", # optional
set_as_default=True,
overwrite=True,
)
Secondo la guida di IBM, le credenziali vengono salvate in $HOME/.qiskit/qiskit-ibm.json. Tratta quel file come una password: non incollarlo nei notebook che condividi e non includerlo nei commit. Su una macchina pubblica o condivisa, IBM indica invece una procedura distinta di autenticazione manuale, che non salva la chiave sul disco.
Installare Qiskit in un ambiente pulito
Usa un ambiente virtuale, così i pacchetti non entreranno in conflitto con altro software sulla tua macchina. Per questa guida bastano tre pacchetti. Qiskit costruisce e compila i circuiti, qiskit-aer li simula sulla CPU e qiskit-ibm-runtime comunica con il cloud di IBM.
python3 -m venv qenv
source qenv/bin/activate
pip install qiskit qiskit-ibm-runtime qiskit-aer
Controlla le versioni installate: Qiskit evolve rapidamente e le differenze tra versioni spiegano la maggior parte degli errori di chi comincia.
import qiskit, qiskit_aer, qiskit_ibm_runtime
print(qiskit.__version__, qiskit_aer.__version__, qiskit_ibm_runtime.__version__)
Il giorno in cui è stata scritta questa guida, l’output era 2.6.0, 0.18.0 e 0.50.0. La pagina Hello World di IBM indica qiskit[all]~=2.5.2 e qiskit-ibm-runtime~=0.47.0 come intervalli di versioni compatibili e afferma che funzionano anche versioni più recenti, benché le versioni di Qiskit e Runtime installate qui siano fuori da quegli intervalli. Se le tue versioni sono ancora più recenti, il codice dovrebbe comunque funzionare, perché usa soltanto l’interfaccia delle primitive.
Costruire uno stato di Bell
Uno stato di Bell è il circuito più piccolo capace di fare qualcosa che nessuna coppia di bit classici può fare. Un gate Hadamard pone il qubit 0 in una sovrapposizione equiprobabile di 0 e 1. Un gate controlled-NOT inverte poi il qubit 1 ogni volta che il qubit 0 è 1, legando i due qubit in modo che misurarne uno riveli il valore dell’altro.
from qiskit import QuantumCircuit
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()
print(qc.draw(output="text"))
Lo schema mostra un gate H sul filo superiore, un CNOT che collega i due fili e una misura su ciascuno. measure_all() aggiunge un registro classico chiamato meas e una barriera prima delle misure. Il nome del registro sarà importante più avanti, perché è sotto quel nome che l’oggetto restituito conserva i conteggi.
In condizioni ideali, il risultato è «00» nella metà dei casi e «11» nell’altra metà, mai «01» o «10». Questa previsione è il benchmark con cui confronterai l’hardware. Ogni ripetizione del circuito si chiama shot e produce una sola stringa di bit: servono quindi molti shot prima che emerga una distribuzione.
Eseguirlo su un simulatore locale
Esegui prima il circuito su un simulatore ideale. Qiskit include StatevectorSampler, che calcola lo stato quantistico esatto e campiona le misure a partire da esso, senza rumore e senza bisogno di un account.
from qiskit.primitives import StatevectorSampler
result = StatevectorSampler(seed=1).run([qc], shots=1024).result()
print(result[0].data.meas.get_counts())
La mia esecuzione ha stampato {'11': 506, '00': 518}. La ripartizione non è esattamente 512 e 512 perché il campionamento è casuale, proprio come 1.024 lanci di una moneta raramente danno esattamente 512 teste. La cosa importante è ciò che manca: nessun «01» e nessun «10». Nel simulatore non ci sono imperfezioni fisiche che possano causare errori.
La modalità di chiamata è quella che riutilizzerai sull’hardware. Un sampler riceve un elenco di circuiti (IBM chiama ogni elemento primitive unified bloc, o PUB) e un numero di shot, e restituisce un risultato il cui primo elemento contiene un oggetto data. L’attributo meas è il nome del registro creato da measure_all(), mentre get_counts() trasforma i bit grezzi in un dizionario di stringhe di bit e relativi conteggi.
Adattare il circuito a un chip specifico
Un processore reale non comprende h o cx. Ogni chip supporta un breve elenco di operazioni native e i suoi qubit sono collegati secondo uno schema fisso. Qiskit deve quindi riscrivere il circuito usando quelle operazioni e disponendolo secondo quello schema. IBM chiama il risultato circuito ISA, da instruction set architecture, e le primitive hardware accettano solo circuiti in questa forma.
Puoi osservare il processo senza un account, usando uno dei backend simulati inclusi in qiskit-ibm-runtime. Sono istantanee immutabili di veri dispositivi IBM, comprensive dei dati di calibrazione.
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime.fake_provider import FakeSherbrooke
fake = FakeSherbrooke()
pm = generate_preset_pass_manager(backend=fake, optimization_level=1)
isa = pm.run(qc)
print(isa.count_ops(), isa.depth())
L’output è stato OrderedDict({'rz': 7, 'sx': 4, 'measure': 2, 'ecr': 1, 'barrier': 1}), con una profondità di 8. I tuoi due gate sono diventati dodici operazioni native: sette rotazioni Z, quattro impulsi di radice quadrata di X e un gate di risonanza incrociata con echo, ecr, che è il gate a due qubit di quel dispositivo. È da quell’unico ecr che deriverà la maggior parte degli errori.
Simulare il rumore di un dispositivo reale
Ora aggiungi le imperfezioni. Il simulatore Aer può caricare i tassi di errore registrati di un backend simulato e applicarli a ogni gate e misura, offrendo un’anteprima di ciò che farà l’hardware.
from qiskit_aer.primitives import SamplerV2 as AerSampler
noisy = AerSampler.from_backend(fake, seed=7)
r = noisy.run([isa], shots=1024).result()
print(r[0].data.meas.get_counts())
La mia esecuzione ha prodotto {'00': 503, '11': 474, '01': 27, '10': 20}. Quarantasette shot su 1.024, circa il 4,6%, hanno dato risultati che il circuito ideale esclude. È una simulazione del rumore registrato di Sherbrooke, non una misura effettuata sulla macchina fisica: considerala quindi un’indicazione dell’ordine di grandezza.
Tre effetti producono questi conteggi errati. I gate sono imperfetti, e quelli a due qubit lo sono più di quelli a un solo qubit. I qubit perdono il proprio stato nel tempo per effetto della decoerenza. Anche la lettura è imperfetta: un qubit che ha terminato in 1 viene talvolta riportato come 0. La mitigazione degli errori, che il runtime offre tra le sue opzioni, può ridurre questi effetti, ma non eliminarli.
Inviare il job all’hardware reale
Il percorso sull’hardware riprende gli stessi tre passaggi: scegliere un backend, eseguire la transpilazione per quel backend e avviare un sampler. Il codice segue le chiamate documentate da IBM nella guida Hello World e nella documentazione di riferimento di SamplerV2, dove il costruttore è SamplerV2(mode=None, options=None) e run accetta pubs e, facoltativamente, shots. Non ho potuto eseguirlo, perché serve un account attivo.
from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
service = QiskitRuntimeService() # reads the saved credentials
backend = service.least_busy(simulator=False, operational=True)
print(backend.name)
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa = pm.run(qc)
sampler = SamplerV2(mode=backend)
job = sampler.run([isa], shots=1024)
print(job.job_id())
counts = job.result()[0].data.meas.get_counts()
print(counts)
Passare il backend come mode esegue il circuito come un unico job. La chiamata least_busy sceglie il dispositivo operativo con la coda più breve, il che è utile con un piano in cui i minuti a disposizione sono limitati. Tieni basso il valore di shots: 1.024 bastano ampiamente per vedere lo schema, e la quota disponibile si misura in tempo di processore.
IBM dice chiaramente che l’attesa fa parte dell’esperienza. La sua guida Hello World enuncia la regola senza giri di parole:
Quando esegui il tuo programma quantistico su un dispositivo reale, il carico di lavoro deve attendere in coda prima di essere eseguito. — IBM Quantum Documentation, guida Hello World, IBM
La chiamata a job.result() resta in attesa finché il job non termina. Se la coda è lunga, stampa l’ID del job, chiudi il notebook e recuperalo più tardi con service.job(job_id). La pagina Workloads mostra lo stato e il tempo di processore addebitato.
Leggere i conteggi reali
Quando arrivano i conteggi restituiti dall’hardware sotto forma di dizionario, aspettati la distribuzione che hai visto nella simulazione con rumore. «00» e «11» dovrebbero prevalere, ciascuno con una frequenza vicina alla metà dei tuoi shot, mentre «01» e «10» dovrebbero comparire con conteggi bassi. La coppia prevalente mostra una correlazione, ma da sola non conferma l’entanglement: una coppia di monete indipendenti darebbe frequenze distribuite uniformemente fra tutti e quattro gli esiti.
Non aspettarti una ripartizione perfetta tra «00» e «11». Sulla maggior parte dei dispositivi superconduttivi, un qubit nello stato 1 decade verso 0 un po’ più facilmente di quanto avvenga il contrario, perciò «00» spesso prevale di poco. Esegui due volte lo stesso job e vedrai due dizionari diversi, entrambi validi.
È utile trasformare il dizionario in un numero che puoi confrontare tra un’esecuzione e l’altra: la frazione di shot che produce esiti proibiti.
total = sum(counts.values())
bad = counts.get("01", 0) + counts.get("10", 0)
print(f"forbidden outcomes: {bad / total:.1%}")
Quella percentuale è un indicatore approssimativo dello stato dell’intero processo: riassume l’errore dei gate, la decoerenza e l’errore di lettura. Ripeti la prova su un altro backend o in un altro giorno e cambierà, quindi una sola esecuzione dimostra poco.
Usare bene i tuoi dieci minuti
Sviluppa sul simulatore e usa il tempo sull’hardware solo per circuiti che comprendi. Un backend fittizio insieme ad Aer ti permette di correggere il codice, controllare la profondità del circuito dopo la transpilazione e provare la gestione dei risultati senza attendere in coda. L’hardware conferma poi il comportamento.
Raggruppa le tue domande. Un job può contenere diversi circuiti come PUB separati, così una sola attesa in coda permette di rispondere a più domande contemporaneamente. Per esempio, puoi inviare insieme il circuito di Bell e una variante GHZ a tre qubit e confrontare le rispettive frazioni di esiti proibiti con la stessa calibrazione del dispositivo.
Controlla la dashboard dopo il primo job. La pagina Workloads mostra il tempo di processore consumato da quel job, e questo ti dice quante ripetizioni puoi fare nella finestra disponibile. Con una finestra mobile di 28 giorni, dopo una serie ravvicinata di esperimenti dovrai aspettare che scadano i primi minuti utilizzati: distribuiscili quindi nel tempo, oppure informati sull’opzione da 180 minuti, se hai i requisiti per aderire.
Il piano gratuito ha limiti concreti. L’accesso riguarda la flotta di dispositivi pubblicata da IBM, nei limiti consentiti dall’Open Plan; un post di IBM del marzo 2026 afferma che il processore Heron r2 ibm_kingston è stato aperto a tutti gli utenti dell’Open Plan. Le note di rilascio di qiskit-ibm-runtime descrivono un limite al numero di job in attesa sull’Open Plan, quindi consulta la documentazione aggiornata di IBM prima di metterne diversi in coda contemporaneamente.
Dopo lo stato di Bell
Una volta ottenuto lo stato di Bell, cambia una cosa alla volta. Aggiungi un terzo qubit e costruisci uno stato GHZ, poi confronta come cresce la frazione di esiti proibiti all’aumentare del numero di gate a due qubit. Cambia optimization_level da 0 a 3 e confronta il numero di gate dopo la transpilazione. Prova la primitiva estimator, che restituisce i valori di aspettazione degli osservabili anziché i conteggi grezzi e che IBM usa nel proprio esempio della guida Hello World.
Incontrerai anche opzioni di mitigazione degli errori, che eseguono circuiti aggiuntivi per stimare e sottrarre il rumore. Moltiplicano il tempo di processore per job, quindi incidono direttamente sulla quota a tua disposizione. Impara prima a conoscere il comportamento senza mitigazione: così saprai che cosa viene corretto.
La macchina che hai davanti è imperfetta per sua natura, e gli strumenti sono costruiti tenendo conto di questo fatto. Un circuito corretto sulla carta diventa sull’hardware un esperimento statistico soggetto a rumore, e la capacità da acquisire è leggere la distribuzione, perché nessuna singola esecuzione dà la risposta. Esegui il tuo stato di Bell, salva i conteggi e conserva il primo dizionario che ottieni: è una testimonianza di ciò che l’hardware superconduttivo attuale fa con i tuoi due qubit.