Emulazione quantistica, perché la priorità è il backend

Nel quantum computing accessibile l’attenzione mediatica si concentra spesso sulle interfacce — SDK, linguaggi di programmazione, ambienti di sviluppo (Qiskit, Cirq, e framework proprietari) che permettono a chiunque di “scrivere” un circuito quantistico. Ma la vera differenza sta a monte: nel motore che quel circuito lo esegue davvero.

Un frontend elegante appoggiato a un backend che non scala, non emula fedelmente il comportamento fisico, o richiede risorse computazionali proibitive, produce solo un’illusione di accesso al quantum computing. Importante approfondire il rapporto tra layer applicativo e motore di emulazione sottostante, chiarendo perché la capacità reale di un sistema — numero di qubit emulabili, fedeltà del rumore quantistico, tempi di esecuzione — dipende interamente dall’architettura del backend, e perché la scelta del motore di calcolo dovrebbe precedere, non seguire, quella dell’interfaccia.

Frontend e backend nell’emulazione quantistica

Chi si avvicina al quantum computing incontra per primi i nomi degli SDK: Qiskit di IBM, Cirq di Google, framework proprietari di vari vendor. Sono strumenti importanti — definiscono come si scrive un circuito, come lo si compone, come se ne leggono i risultati — ma sono, appunto, un’interfaccia. Il termine tecnico corretto è “frontend”: il layer con cui lo sviluppatore interagisce. La domanda che l’interfaccia non risponde da sola è: quel circuito, una volta scritto, chi lo esegue e come?

La risposta sta nel “backend”: il motore di calcolo che riceve la rappresentazione del circuito e produce un risultato — che si tratti di un processore quantistico fisico o, nel caso dell’emulazione, di un motore software che gira su hardware classico.

Backend di emulazione quantistica nell’ecosistema Qiskit e Cirq

Questa separazione non è una semplificazione editoriale: è come è costruito l’ecosistema quantum software oggi dominante. Qiskit Aer — il simulatore di riferimento dell’ecosistema IBM — supporta più metodi di simulazione (state-vector, density matrix, stabilizer/Clifford, tensor network) e sceglie automaticamente il metodo più adatto al circuito; supporta inoltre l’accelerazione GPU tramite CUDA. Google, dal canto suo, separa esplicitamente il frontend Cirq dal motore di simulazione qsim.

Il caso più chiaro è quello di NVIDIA cuQuantum: la documentazione ufficiale descrive esplicitamente due frontend — Qiskit Aer e Cirq — collegati a backend distinti e sostituibili: cusvaer (state vector distribuito multi-GPU) per Qiskit, qsim per Cirq, con le librerie cuStateVec (state vector) e cuTensorNet (tensor network) come motori di accelerazione sottostanti. Un paper tecnico NVIDIA del 2023 sul cuQuantum SDK conferma che uno stesso frontend (Cirq o Qiskit Aer) può appoggiarsi a backend intercambiabili con caratteristiche di scaling molto diverse — inclusi backend multi-GPU e multinodo per simulazioni distribuite su larga scala.

La conseguenza pratica: due sistemi che espongono la stessa interfaccia di programmazione (stesso frontend Qiskit, ad esempio) possono avere capacità radicalmente diverse — numero massimo di qubit, tempo di esecuzione, gestione del rumore — a seconda del backend a cui sono collegati. Scrivere un circuito in Qiskit non garantisce nulla sulla scala del problema che si potrà effettivamente eseguire: quella è una proprietà del motore, non del linguaggio.

Capacità del backend: State Vector e Tensor Network

Un motore di emulazione classico può seguire, in sostanza, due strategie architetturali:

Le strategie di emulazione

• State Vector – rappresenta esplicitamente e con precisione esatta ogni ampiezza dello stato quantistico. La memoria richiesta raddoppia a ogni qubit aggiuntivo (crescita O(2ⁿ)): è il metodo più fedele, ma con un tetto pratico di poche decine di qubit su hardware anche molto potente.
• Tensor Network – comprime le correlazioni tra qubit sfruttando la struttura del circuito, riducendo drasticamente la memoria necessaria per circuiti a basso entanglement. Permette di lavorare su un numero di qubit molto più alto, ma le prestazioni dipendono dalla topologia del problema, non sono garantite in generale.

Nessuna delle due strategie è “migliore” in assoluto: sono adatte a classi di problemi diverse. Un backend ben progettato – e questo vale sia per soluzioni proprietarie sia per l’ecosistema Qiskit/cuQuantum descritto sopra – offre entrambe le modalità e lascia che sia la struttura del problema a determinare quale usare.

Emulatore quantistico: un motore proprietario dietro l’interfaccia

La piattaforma di emulazione applica questa distinzione nella propria architettura: il layer di orchestrazione è compatibile con CUDA, cuQuantum e Qiskit — cioè con lo stesso standard di frontend appena descritto — mentre il motore di calcolo sottostante è hardware e software proprietari.

Le diverse configurazioni disponibili sul mercato dichiarano capacità che vanno, in modalità State Vector, da 20-22 qubit a 32-36 qubit e oltre; in modalità Tensor Network, da 30-40 qubit a 60-80 qubit e oltre su topologie favorevoli.

Fedeltà del backend quantistico e criteri di confronto

I dati disponibili riportano una “fedeltà rispetto ai sistemi fisici NISQ” superiore al 99,2% nelle configurazioni desktop/workstation e al 99,7% nelle configurazioni rack, misurata su circuiti standard (Grover, Quantum Fourier Transform, Variational Quantum Eigensolver) con benchmark documentati in un certificato di collaudo per unità.

Va segnalata una precisazione metodologica necessaria: un emulatore State Vector, per costruzione, calcola l’evoluzione esatta e senza rumore del circuito — non ha quindi un proprio “errore” da confrontare a una fedeltà assoluta, ma può essere confrontato con l’output di un dispositivo fisico NISQ (che è invece soggetto a rumore e decoerenza) solo specificando: (a) quale dispositivo fisico di riferimento è stato usato per il confronto, (b) quale metrica di fedeltà è stata applicata (ad es. fedeltà di stato, fedeltà di processo, cross-entropy benchmarking), e (c) su quali dimensioni di circuito il confronto è stato condotto.

Come scegliere il backend per l’emulazione quantistica

Ne discende un criterio pratico per chi valuta una piattaforma di emulazione quantistica: la domanda corretta non è “che SDK usa?” — la risposta sarà quasi sempre la stessa, perché Qiskit e Cirq sono ormai standard di fatto a cui qualunque backend serio si allinea — ma “quale motore c’è dietro, quanti qubit regge in ciascuna modalità, e su quale hardware gira?”. Un fornitore che comunica solo la compatibilità con Qiskit, senza specificare backend, numero di qubit e architettura, sta comunicando l’equivalente di un’automobile descritta solo dal volante.