AMD ha scelto una strada poco visibile ma strutturale: rendere il calcolo GPU virtualizzato un elemento di primo piano nella pila ROCm, partendo da QEMU. Non si tratta di un nuovo silicio né di un modello, ma di un backend pensato per far funzionare meglio i carichi di calcolo GPU dentro macchine virtuali. La notizia, ancora in forma di lavoro in corso da parte degli ingegneri AMD, tocca un punto dolente dell'infrastruttura open source: la distanza tra l'efficienza del bare metal e la flessibilità delle VM quando si parla di GPU.

Il nodo non è la velocità, ma l'isolamento. Tradizionalmente, chi vuole usare una GPU in una macchina virtuale ha due strade. La prima è il passthrough PCIe: si assegna l'intera GPU a una singola VM, con prestazioni vicine al bare metal ma con isolamento rigido e zero condivisione. La seconda passa da meccanismi di virtualizzazione del dispositivo che consentono di dividere la GPU tra più sistemi guest, ma che storicamente hanno richiesto driver, licenze o stack software specifici. Il lavoro di AMD su ROCm e QEMU si inserisce in questo secondo binario, con l'obiettivo di rendere il runtime di calcolo più consapevole dell'ambiente virtualizzato.

Per chi gestisce infrastrutture on-premise o private cloud, la questione è prima di tutto economica. Una GPU di fascia alta lasciata in passthrough a una sola VM può restare inattiva per lunghi tratti, mentre altri team aspettano risorse. Se il backend ROCm sotto QEMU matura, diventa possibile immaginare pool di GPU AMD allocate dinamicamente tra macchine virtuali, con confini di memoria e isolamento dei processi più puliti. Questo non è un dettaglio da sistemisti: cambia il modo in cui si calcola il TCO. Il costo di acquisto resta, ma l'utilizzo effettivo sale, e con esso la capacità di servire più carichi di inference o di training leggero senza moltiplicare l'hardware.

C'è anche un risvolto strategico. NVIDIA ha costruito negli anni un ecosistema di virtualizzazione GPU che passa in parte da strumenti commerciali e da un'integrazione molto stretta con CUDA. AMD sta provando a rispondere dal lato open source, lavorando su ROCm e su QEMU piuttosto che spingere solo su soluzioni proprietarie. È una mossa che parla alle organizzazioni più sensibili alla sovranità dei dati: ambienti air-gapped, laboratori governativi, cliniche o istituti finanziari che vogliono tenere i carichi dentro i propri confini e al tempo stesso non legarsi a un unico fornitore. In questi contesti, la possibilità di usare GPU AMD in macchine virtuali gestite con stack aperti riduce un collo di bottiglia che oggi spinge molti verso il cloud o verso licenze aggiuntive.

Non è una transizione indolore. Il supporto ROCm per la virtualizzazione è storicamente arrivato con ritardo rispetto alle esigenze dei data center, e la stabilità dei driver in ambienti QEMU/KVM è spesso più importante delle prestazioni di picco. Inoltre, ogni livello di astrazione aggiunto tra runtime e GPU introduce potenziali penalità di latenza e complessità di debugging. Chi valuta deployment on-premise deve quindi pesare benefici di consolidamento e costi di gestione: AI-RADAR offre framework analitici su /llm-onpremise per confrontare questi trade-off, ma la decisione resta legata al profilo dei carichi.

Il segnale di fondo è che la partita delle GPU per l'AI non si gioca più solo su teraflop e VRAM. Si gioca sulla capacità di trasformare un parco GPU in una risorsa fluida, multi-tenant e governabile. AMD, lavorando su un backend ROCm per QEMU, sta dicendo che anche la virtualizzazione open source merita di uscire dalla nicchia del passthrough e diventare un'infrastruttura di calcolo di prima classe.