Il kernel Linux 7.2 ha silenziosamente agganciato il supporto per UltraRISC nella build predefinita per architettura RISC-V, replicando il percorso già seguito per i System-on-Chip Eswin. Da fuori potrebbe sembrare la solita voce di changelog per addetti ai lavori, ma in realtà racconta molto della direzione che sta prendendo il silicio aperto – e di quali conseguenze può avere per chi progetta deployment di LLM senza passare dal cloud.
La novità tecnica è netta: con il defconfig RISC-V di Linux 7.2, il kernel abilita nativamente i driver e il codice necessario per far funzionare i processori UltraRISC, senza bisogno di patch o kernel custom. È il genere di dettaglio che sposta l’asticella della praticabilità: quando una piattaforma viene integrata nella configurazione standard, smette di essere un progetto per pionieri e diventa un’opzione realmente valutabile per gli integratori di sistema. Eswin aveva aperto la strada e UltraRISC conferma che non si tratta di un caso isolato, ma di un movimento strutturale.
Per chi segue l’AI e, in particolare, il deployment on-premise, l’importanza di questi mattoncini è alta. RISC-V è un Instruction Set Architecture aperto, libero da royalty, che sta costruendo pezzo dopo pezzo un ecosistema alternativo a x86 e ARM. In uno scenario in cui l’inference di modelli LLM richiede potenza di calcolo a costi prevedibili, la disponibilità di silicio con architettura aperta cambia le carte in tavola: significa che i carichi di lavoro AI possono teoricamente atterrare su hardware progettato senza i vincoli di licenza dei soliti incumbent, abbattendo il Total Cost of Ownership e, non di meno, aumentando il controllo sui dati e sullo stack software.
Non stiamo parlando di chip per il training massiccio dei modelli fondazionali, almeno per ora. Il punto è l’inference – il momento in cui un modello già addestrato deve rispondere a prompt, processare documenti o fare RAG in un ambiente self-hosted. Qui la partita si gioca su consumi, latenza e costo per token, e un processore RISC-V ottimizzato per edge computing o per server compatti può diventare un’alternativa concreta ai chip GPU classici, specie se affiancato da acceleratori dedicati. UltraRISC ed Eswin rappresentano due esempi di progettisti che stanno portando design RISC-V a uno stadio di produzione sufficiente per meritare l’attenzione dei manutentori del kernel.
La dinamica di secondo ordine è la più interessante. L’abilitazione di default sui kernel mainstream non accelera solo l’adozione: abbassa la soglia per i costruttori di schede e appliance. Un vendor che voglia offrire un nodo di inference local-first può prendere un SoC UltraRISC, avviare un sistema Linux non modificato e costruirci sopra la propria soluzione, risparmiando mesi di ingegnerizzazione. Ciò favorisce un mercato di hardware per AI più frammentato ma anche più resiliente, perché non dipende da un solo fornitore di GPU o di licenze. In un’ottica di sovranità dei dati, avere sotto controllo il silicio e il software che lo gestisce è un argomento pesante, specie per settori regolati o per pubbliche amministrazioni che valutano l’on-premise estremo.
Certo, una patch nel defconfig non è una rivoluzione compiuta. Le sfide rimangono: la maturità del compilatore, il supporto alle librerie ottimizzate per l’AI, la disponibilità commerciale su larga scala. Ma il segnale è inequivocabile: l’ecosistema RISC-V sta uscendo dalla fase sperimentale e si sta incardinando nelle pipeline di integrazione continue del kernel Linux. Per chi architetta il futuro del machine learning in azienda, tenere d’occhio questi movimenti significa poter anticipare quando il costo di un hardware aperto diventerà minore del costo delle licenze nascoste nelle architetture tradizionali.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!