Un annuncio che scompagina i piani di chi gestisce carichi di AI su GPU AMD in produzione. Nelle scorse ore il Kernel Team di Ubuntu ha rotto gli indugi e pubblicato un avviso tecnico: la prossima point release del kernel Linux 7.0, destinata a Ubuntu 26.04 e agli utenti di Ubuntu 24.04 LTS con Hardware Enablement (HWE) attivo, introdurrà una regressione di prestazioni tale da rallentare i calcoli su GPU AMD fino a 42 volte nei carichi più intensivi.

Non si tratta di un timido calo percentuale, ma di un crollo che trasforma l'hardware in un collo di bottiglia ingestibile per ambienti che fanno un uso massiccio della potenza di calcolo parallelo. La buona notizia è duplice: la regressione è un incidente di percorso upstream, già riconosciuto e con una patch in fase di distribuzione; e proprio la natura open del kernel fa sì che le distribuzioni che hanno già imbarcato il codice difettoso stiano coordinando il rilascio della correzione.

Un terremoto selettivo per carichi compute

L'impatto non è uniforme. La regressione colpisce in modo specifico i carichi "compute-heavy", categoria in cui rientrano a pieno titolo l'inference e il training di Large Language Models, le simulazioni scientifiche, il rendering non real-time e l'elaborazione video professionale. Chi utilizza GPU AMD per fare serving di LLM via ROCm, per esempio, potrebbe vedere la latenza esplodere e il throughput collassare, vanificando i benefici di un'architettura altrimenti competitiva sul piano del Total Cost of Ownership.

La dinamica è significativa perché arriva da una distribuzione, Ubuntu, che rimane la scelta più diffusa per i server on-premise, anche in contesti aziendali o di laboratorio che puntano su self-hosted AI. L'HWE, pensato per offrire kernel più freschi su LTS, diventa qui un canale attraverso cui una modifica non sufficientemente testata può raggiungere ambienti di produzione. Non è la prima volta che l'intersezione tra sviluppo rapido del kernel e stabilità LTS genera attriti, ma la magnitudo della perdita prestazionale rende questo episodio emblematico.

Chi vince e chi perde, tra open source e agilità

Il contraccolpo immediato premia, almeno nella percezione, chi ha stack più conservativi. Le organizzazioni che eseguono LLM on-premise su AMD potrebbero trovarsi a dover congelare gli aggiornamenti o pianificare rollback d'emergenza. Sul fronte opposto, la velocità con cui la comunità Linux ha reagito – identificando l'errore, scrivendo la fix e coordinandone il backport – dimostra che non esiste contrapposizione netta tra innovazione e affidabilità: il modello open source, se sostenuto da manutentori attenti, può assorbire questi shock.

Più in profondità, l'episodio mette in luce una tensione strutturale. L'ecosistema AMD per l'AI, pur compiendo passi avanti con ROCm, resta esposto a scossoni del kernel in misura maggiore rispetto all'ecosistema NVIDIA, dove il driver proprietario e i container CUDA offrono un cuscinetto tra le modifiche di sistema e le performance applicative. Non è una questione di bontà del codice, ma di architettura di distribuzione: quando la piena funzionalità di una GPU dipende da moduli kernel mainline, ogni regressione nel mainline diventa un rischio operativo per chi fa inference in produzione.

Dal punto di vista del deployment on-premise, il segnale è chiaro: chi gestisce cluster di GPU AMD per LLM deve integrare nei propri workflow di CI/CD la validazione automatica delle prestazioni su ogni aggiornamento del kernel. Strumenti di benchmarking specifici per i carichi AI – misurazione di token al secondo, varianza della latenza, stabilità della VRAM sotto carico – non sono più accessori, ma presidi indispensabili. La notizia, infine, rilancia il dibattito sull'opportunità di adottare kernel immutabili o sistemi operativi con aggiornamenti atomici proprio per ridurre la superficie di questi incidenti.

La correzione è in arrivo, ma il punto non è la singola patch. È il promemoria che, nell'AI self-hosted, la sovranità dei dati e il controllo dell'infrastruttura portano con sé la responsabilità di governare l'intero stack, dal modello fino al kernel.