La comunità che sperimenta modelli linguistici in locale si è posta una domanda tanto semplice quanto scomoda: se gli LLM sono così bravi a scrivere codice, perché interi stack software come ROCm di AMD o le soluzioni Intel non riescono a colmare il distacco da CUDA? La risposta, al di là dei titoli, svela le dinamiche di un mercato in cui l’intelligenza artificiale stenta ad accelerare la propria indipendenza hardware.

Il vero fossato: oltre la generazione di codice

La programmazione assistita da LLM è un potente acceleratore per micro-task, refactoring e stesura di snippet, ma uno stack per il calcolo accelerato non è semplicemente una raccolta di funzioni ben scritte. CUDA si porta dietro decenni di ottimizzazioni che partono dal silicio, passano per librerie come cuBLAS e cuDNN fino agli strumenti di profiling, e culminano in un ecosistema di terze parti che ha plasmato l’intero settore del deep learning. Generare porzioni di kernel o wrapper di libreria è utile, ma ricreare l’integrazione profonda fra driver, compiler e hardware richiede un lavoro di sistema che trascende la capacità attuale dei modelli linguistici.

AMD con ROCm ha fatto passi avanti significativi, specie sulle GPU di fascia server come le Instinct, ma il supporto consumer rimane frammentario e la compatibilità software è spesso inseguita con wrapper che emulano l’API CUDA, aggiungendo latenza e complessità. Intel ha intrapreso la strada di oneAPI, un framework aperto che punta all’unificazione, ma la maturità delle ottimizzazioni per i workload LLM è ancora in fase sperimentale. In entrambi i casi, manca quel “funziona senza pensarci” che NVIDIA vende a caro prezzo.

Il peso dell’eredità nel silicio

Un altro fattore spesso trascurato è l’hardware stesso. Le GPU NVIDIA sono state progettate con feature di calcolo general-purpose che si sono evolute parallelamente a CUDA; le scelte architetturali sono diventate interdipendenti con le astrazioni software. Trasportare le stesse ottimizzazioni su un’altra architettura, come le CDNA di AMD o le Xe di Intel, richiede un ripensamento radicale dei kernel, che non si improvvisa con la generazione automatica di codice. Anche con fine-tuning specifico o pipeline di quantization, la differenza di prestazioni in inference su hardware non NVIDIA non è solo una questione di righe di codice, ma di progettazione congiunta software-hardware.

Implicazioni per il mondo on-premise

Chi valuta deployment self-hosted o on-premise si scontra con questo squilibrio ogni volta che guarda al Total Cost of Ownership. Il premio pagato per schede come le A100 o le H100 non deriva solo dalla scarsità di silicio, ma dalla certezza che pipeline di training e inference funzionino fin dal primo giorno, con community, guide e tooling consolidati. In contesti dove la sovranità dei dati impone nodi locali e air-gapped, la tentazione di ridurre la dipendenza da un singolo fornitore esiste, ma resta bloccata dal costo della migrazione e del debugging. Piattaforme come vLLM o Ollama semplificano l’inference, ma il grosso del valore è ancora nel livello più basso, dove l’ecosistema CUDA detta legge.

Una partita aperta, ma lenta

L’arrivo di soluzioni come Triton, che punta a separare la logica di alto livello dai kernel specifici, e l’investimento crescente di hyperscaler su silicon custom, stanno lentamente spostando i termini della competizione. Tuttavia, la velocità con cui i LLM progrediscono non si traduce automaticamente in una maturazione istantanea degli stack alternativi. La community che oggi si affida a NVIDIA per i propri “adventures” AI sogna prezzi più accessibili, ma la strada verso una vera concorrenza passa attraverso anni di sviluppo di sistema, non attraverso prompt ben congegnati. Per chi governa architetture on-premise, il tempo del lock-in NVIDIA è ancora lontano dalla scadenza, ed è un dato da inserire obbligatoriamente nei calcoli di TCO di lungo periodo.