LLM in locale su Linux: Llama, Gemma, Nvidia e la nuova AI open source

Far girare un LLM in locale su Linux non è più un esperimento da laboratorio, ma una scelta architetturale. Significa riportare inferenza, prompt, documenti, codice e dati sensibili dentro la macchina, fuori dal ciclo continuo delle API cloud. Il punto non è soltanto risparmiare sui costi o lavorare offline. Il punto è riprendere controllo sulla catena tecnica: modello, runtime, memoria, GPU, driver, file system, rete e policy di sicurezza. Linux diventa il terreno naturale di questa transizione perché unisce tre elementi che l’AI locale richiede: controllo del sistema, trasparenza dell’ambiente e accesso diretto all’hardware. Una workstation Linux con GPU Nvidia, un server aziendale con acceleratori dedicati o anche un laptop moderno con modello quantizzato possono diventare infrastrutture AI locali, capaci di eseguire Llama, Gemma o modelli compatibili senza inviare ogni richiesta a un servizio remoto. Il nome Gemini va trattato con precisione. Gemini, nella sua forma principale, resta un modello e un servizio Google; l’alternativa eseguibile localmente nel perimetro open-weight è Gemma, famiglia di modelli Google DeepMind ispirata alla ricerca Gemini. La documentazione ufficiale di Google Gemma consente di scaricare, testare e integrare modelli aperti in ambienti locali, mentre la pagina Run Gemma with Ollama chiarisce che Gemma può essere eseguito su laptop o piccoli dispositivi anche senza GPU, usando runtime come Ollama e llama.cpp.

Il cuore tecnico: Linux come piattaforma per l’inferenza locale

Linux non ospita semplicemente l’LLM. Lo governa. Il sistema operativo decide come vengono allocati RAM, VRAM, processi, thread, librerie, driver, container, permessi e servizi di rete. Un modello locale vive dentro questa architettura: viene caricato da disco, occupa memoria, usa CPU o GPU, espone una porta API locale, interagisce con file e documenti, riceve prompt e restituisce output che possono contenere dati sensibili. Per questo l’esecuzione locale non è una funzione, ma una superficie. Un’installazione minimale con Ollama, ad esempio, può trasformare una macchina Linux in un endpoint AI raggiungibile via API. La pagina ufficiale di Ollama per Linux mostra l’installazione diretta via terminale, mentre la documentazione hardware di Ollama GPU support evidenzia il ruolo delle GPU Nvidia, AMD ROCm e Vulkan nell’accelerazione dei modelli. Matrice Digitale ha già raccontato questa trasformazione nel caso di Kali Linux con LLM locali tramite Ollama e 5ire, dove l’AI offline entra direttamente nell’ambiente di penetration testing. La storia è rilevante perché mostra il passaggio da AI come servizio remoto ad AI come strumento operativo locale: il modello non vive più nel browser, ma nella macchina dell’analista, accanto a tool, script, log, report e ambienti di test. Questo cambio di posizione cambia anche il profilo di rischio. Un LLM locale può proteggere i dati dal cloud, ma può anche diventare un nuovo servizio da difendere. Se l’interfaccia HTTP resta esposta sulla rete, se la directory dei modelli viene condivisa male, se i prompt contengono credenziali o se un’interfaccia Web viene pubblicata senza autenticazione, la promessa di privacy si trasforma in una nuova vulnerabilità.

Llama e Gemma: due strade per l’AI locale

Llama rappresenta la linea più riconoscibile dell’AI locale open-weight. Meta distribuisce i modelli attraverso il portale ufficiale Llama downloads e documenta l’esecuzione su Linux nella guida Running Meta Llama on Linux, dove viene indicato che un sistema Linux con GPU e almeno 16 GB di VRAM può caricare localmente modelli Llama 8B in fp16. Questo dettaglio hardware è decisivo. Un modello piccolo può girare anche su CPU, soprattutto se quantizzato, ma la differenza tra “funziona” e “lavora davvero” passa quasi sempre dalla memoria video. La VRAM determina quanti parametri possono essere caricati, quale contesto può essere mantenuto, quanta parte del modello può essere offloadata sulla GPU e quanta latenza l’utente deve accettare. Gemma segue una traiettoria diversa. Google la presenta come famiglia di modelli open-weight capace di girare da cloud server a laptop e telefoni, come si legge nella pagina ufficiale Gemma di Google DeepMind. Il repository google-deepmind/gemma descrive Gemma come famiglia di LLM open-weight basata su ricerca e tecnologia Gemini, mentre l’integrazione con Ollama semplifica l’uso locale per sviluppatori che non vogliono costruire da zero l’intera pipeline di inferenza. La distinzione è importante perché evita un equivoco frequente. Non si installa “Gemini completo” su una workstation Linux come si installa un pacchetto. Si possono invece usare modelli Gemma, tecnologie on-device e runtime locali che portano parte della logica generativa fuori dal cloud. Per l’utente tecnico, questo significa scegliere tra capacità, licenza, memoria richiesta, formato del modello, strumenti di serving e livello di isolamento.

Nvidia, driver Linux e open source: il collo di bottiglia dell’AI locale

Il vero confine dell’AI locale non è il prompt, ma il driver. Una GPU potente senza stack Linux stabile diventa un acceleratore dimezzato. CUDA, moduli kernel, librerie utente, compatibilità con il kernel Linux, gestione della VRAM e supporto alle architetture più recenti decidono se l’inferenza resta fluida o precipita su CPU. Nvidia ha aperto una fase nuova con i propri moduli kernel open source. La guida ufficiale Kernel Modules — NVIDIA Driver Installation Guide spiega che il driver Linux Nvidia include moduli come nvidia.ko, nvidia-modeset.ko, nvidia-uvm.ko e nvidia-drm.ko, e che dalla serie 515 esistono due varianti dei kernel modules, una proprietaria e una open source. La stessa documentazione indica che dalla serie 560 la variante open diventa quella predefinita e consigliata per architetture Turing e successive.

Il repository ufficiale NVIDIA open-gpu-kernel-modules conferma il passaggio a una base pubblicata con licenza duale MIT/GPLv2 per i moduli kernel, mentre il blog Nvidia NVIDIA transitions fully towards open-source GPU kernel modules racconta la strategia di transizione verso moduli kernel aperti su Linux. Matrice Digitale ha seguito il tema nella lettura di Mesa 25.1 e della transizione Nouveau verso Zink+NVK, dove il mondo open source prova a rafforzare stabilità e compatibilità sulle GPU Nvidia. Il punto tecnico è che l’AI locale non dipende solo da CUDA e dai driver ufficiali: dipende anche dall’evoluzione dell’intero stack grafico e compute di Linux, dalla convivenza tra driver proprietari, moduli kernel aperti, Nouveau, NVK, Vulkan e supporto delle distribuzioni. Anche gli aggiornamenti dei driver incidono direttamente sui carichi AI. Matrice Digitale lo ha raccontato in Aggiornamenti Linux: Firefox 147 XDG, Thunderbird e NVIDIA 580 e in Wine 11: Ntsync, Vulkan video e prestazioni Windows su Linux, dove la stabilità Nvidia su kernel recenti, Wayland e backend Vulkan diventa parte della maturità complessiva del desktop Linux tecnico.

Le sfide hardware: VRAM, banda memoria e quantizzazione

Il sogno dell’LLM locale si infrange spesso su un numero: la memoria disponibile. La RAM di sistema aiuta, ma per prestazioni reali la VRAM resta il collo di bottiglia. Un modello grande può anche essere caricato parzialmente su CPU, ma ogni spostamento tra memoria di sistema e GPU introduce latenza. La qualità dell’esperienza dipende da quanto modello entra in VRAM, dal formato di quantizzazione e dalla lunghezza del contesto. La quantizzazione riduce il peso del modello, ma non è gratuita. Abbassare precisione e dimensioni consente di far girare modelli più grandi su hardware più modesto, ma può incidere su accuratezza, stabilità delle risposte e capacità di ragionamento. In una macchina Linux usata per sviluppo, analisi documentale o cybersecurity, questa differenza non è marginale: un modello troppo compresso può sembrare veloce, ma produrre output meno affidabili proprio nei passaggi tecnici più delicati. Le GPU Nvidia restano centrali perché CUDA domina molte pipeline AI, ma l’ecosistema Linux sta diventando più plurale. AMD spinge ROCm, Vulkan apre scenari di compatibilità più ampia, llama.cpp consente inferenza efficiente anche su CPU e GPU non tradizionali, mentre framework come Ollama mascherano parte della complessità. Il risultato è una stratificazione simile a quella del mondo server: kernel, driver, runtime, modello e interfaccia devono lavorare insieme. La parte meno visibile è il consumo. Un LLM locale non è solo software: è calore, alimentazione, raffreddamento, rumore, usura e costo energetico. Una workstation con GPU di fascia alta può sostituire molte chiamate API, ma introduce un nuovo bilancio tra autonomia, prestazioni e manutenzione. Per le aziende, questo significa ragionare non solo su “cloud o locale”, ma su quali dati restano interni, quali modelli servono davvero e quali workload meritano hardware dedicato.

Sicurezza: l’LLM locale non è automaticamente sicuro

L’AI locale viene spesso raccontata come risposta alla dipendenza dal cloud. In parte è vero. Se documenti, prompt, codice sorgente e dati aziendali restano su una macchina controllata, il rischio di esposizione verso servizi esterni diminuisce. Ma questo non rende il sistema automaticamente sicuro. Matrice Digitale ha mostrato il lato oscuro dell’entusiasmo per tool AI locali nel caso Abusi AI su Hugging Face e Ollama, dove piattaforme e strumenti legati all’ecosistema dei modelli vengono sfruttati come infrastruttura o esca. Lo stesso tema emerge nell’articolo Hacker abusano Google Ads e Hugging Face per malware Mac, che mostra come l’interesse verso Ollama, modelli open source e automazione possa diventare leva per campagne malevole. Il problema non è Ollama in sé, né Hugging Face in sé, né Llama o Gemma. Il problema è la fiducia automatica nel pacchetto, nel modello, nel notebook, nello script di installazione o nell’interfaccia scaricata da una pagina sponsorizzata. Nel mondo dell’AI locale, la supply chain non riguarda solo librerie e container: riguarda anche pesi del modello, adapter, LoRA, tokenizer, prompt template e interfacce Web. Una macchina Linux che esegue LLM locali deve quindi essere trattata come un server applicativo. Bisogna controllare quali porte espone, quali directory monta, quali utenti possono accedere ai modelli, quali log vengono salvati, quali documenti entrano nella pipeline RAG e quali plugin o agenti hanno permessi di esecuzione. Se un agente locale può leggere file, aprire shell o interrogare repository aziendali, l’LLM non è più solo un assistente. È un componente operativo con privilegi.

La nuova infrastruttura AI passa da Linux

L’esecuzione locale degli LLM su Linux segna una frattura rispetto al modello dominante delle API centralizzate. Non elimina il cloud, ma gli toglie l’esclusiva. L’azienda può scegliere di tenere in locale prompt sensibili, codice proprietario, documenti legali, log di sicurezza o dataset interni, usando il cloud solo dove servono modelli più grandi, training o capacità multimodali avanzate. Questa ibridazione diventa la forma più realistica dell’AI professionale. Llama e Gemma portano modelli open-weight dentro workstation e server. Ollama, llama.cpp e runtime simili abbassano la soglia d’ingresso. Nvidia apre una parte del proprio stack kernel e rende meno ostile il rapporto con Linux. Le distribuzioni integrano driver, container, Wayland, Vulkan e librerie AI in ambienti sempre più coerenti. Il punto tecnico resta però invariato: un LLM locale è affidabile solo quanto l’architettura che lo ospita. Se Linux è aggiornato, i driver sono coerenti, la GPU è supportata, la rete è chiusa, i modelli sono verificati e i dati sono classificati, l’AI locale diventa uno strumento di autonomia. Se invece l’ambiente è improvvisato, con script scaricati a caso, interfacce esposte e modelli non verificati, la promessa di indipendenza diventa una nuova superficie d’attacco. Linux torna quindi al centro dell’AI non come nostalgia open source, ma come infrastruttura. È il sistema che permette di controllare macchina, modello, permessi e hardware. È il punto in cui l’intelligenza artificiale smette di essere solo un servizio remoto e diventa una capacità installata, misurabile, auditabile e difendibile.