Non capita spesso che un ciclo di sviluppo del kernel Linux mostri in modo così netto l'attrito tra due velocità: quella delle patch legate ad AI e LLM e quella della manutenzione di un'architettura come ARM64. Nel ciclo Linux 7.2, quell'attrito ha prodotto un risultato secco: nessuna funzionalità reale è approdata su AArch64. Per chi considera ARM64 come piattaforma per server self-hosted dedicati all'inference di modelli, non è un dettaglio da manutentori, ma un indicatore di rischio.

La reazione arriva con Linux 7.3. Gli sviluppatori ARM Linux si presentano più preparati e portano nuove funzionalità per ARM64, tra cui BBML3 e workaround per NVIDIA Olympus. È un cambiamento di passo che va letto in controluce: non si tratta soltanto di recuperare il tempo perso, ma di mostrare che l'architettura può assorbire il contributo dell'ecosistema AI senza finire sommersa dal rumore delle patch. Il set di funzionalità BBML3 segnala che il lavoro di abilitazione è stato incanalato in un percorso di revisione più selettivo, mentre i workaround per NVIDIA Olympus ricordano che il supporto nel kernel non riguarda solo la potenza di calcolo.

Per chi progetta infrastrutture on-premise per LLM, la lezione strutturale è che il ramo stabile del kernel non è un dettaglio secondario. Un ciclo vuoto come Linux 7.2 significa ritardi nell'abilitazione di nuove istruzioni, nel supporto alle periferiche e nelle correzioni di errori hardware. Su piattaforme ARM64, dove il controllo del software è spesso uno dei motivi per preferire il self-hosted al cloud, questi ritardi si traducono in costi di gestione e vincoli di aggiornamento. Non basta attendere una feature: bisogna verificare se il kernel su cui si basa un deployment riceverà le mitigazioni necessarie senza costringere a fork o backport.

A guadagnarci sono i fornitori di hardware ARM64 che puntano su server e appliance per l'inference locale: un kernel che torna a integrare funzionalità riduce il costo di supporto e accorcia i tempi di messa in produzione. A perderci, almeno nel breve periodo, sono i team che avevano pianificato aggiornamenti su Linux 7.2 e si sono trovati di fronte a un ramo senza le novità attese. La pressione delle patch AI/LLM, se non governata, può spiazzare la manutenzione di architetture che non sono al centro dell'hype ma diventano essenziali quando si passa dall'addestramento in cloud all'operatività locale.

Il caso dei workaround per NVIDIA Olympus aggiunge un elemento concreto: un acceleratore può avere specifiche elevate, ma se il supporto nel sistema operativo richiede correzioni che arrivano con ritardo, il costo reale si sposta sul team che deve mantenere il parco macchine. In un contesto on-premise, dove non c'è un provider che applica i fix al posto tuo, quel costo resta interamente all'organizzazione. Per chi valuta deployment on-premise, esistono trade-off da analizzare con attenzione: AI-RADAR offre framework analitici su /llm-onpremise, ma la decisione finale dipende da TCO, data sovereignty e maturità del supporto hardware.