Far girare un modello linguistico sul proprio computer è ormai una pratica diffusa, ma il modo in cui ci si arriva resta spesso poco pulito. Chi è passato per l’installazione manuale lo sa bene: driver CUDA o ROCm da allineare alla versione giusta di PyTorch, ambienti Python che entrano in conflitto tra loro, librerie compilate a mano.
Strumenti come Ollama o LMstudio hanno semplificato di molto questo percorso, e non a caso sono diventati il punto di riferimento per chi inizia. Restano però un runtime che vive sopra il sistema operativo, con i propri file, i propri servizi e le proprie versioni da mantenere.
RamaLama parte da un’idea diversa, ovvero trattare un modello AI esattamente come si tratta un’immagine container. È un progetto open source nato all’interno dell’ecosistema containers, lo stesso di Podman e Buildah.
Quando lanci un modello, RamaLama ispeziona la tua GPU, scarica l’immagine OCI già ottimizzata per quell’hardware e avvia l’inferenza dentro un container isolato. Il sistema host resta intatto, perché tutto ciò che serve vive nel contenitore e sparisce quando chiudi. In questa guida vediamo come installarlo sui tre sistemi operativi, come far girare un modello recente come Gemma 4 o Qwen3.6, come esporlo via API e come impacchettare un modello in un’immagine pronta da distribuire.
RamaLama: perché un modello dentro un container
Il problema che RamaLama prova a risolvere non è far girare il modello, perché quello lo fanno già in molti. Il problema è come ci si arriva e cosa resta sul sistema una volta finito. Ogni acceleratore hardware ha il suo stack software: una scheda NVIDIA vuole CUDA, una AMD vuole ROCm o Vulkan, una Intel Arc ha le sue librerie, e i Mac con Apple Silicon usano Metal o MLX.
RamaLama sposta questa complessità dentro un’immagine container. Al primo avvio ispeziona la macchina, riconosce il tipo di GPU presente e scarica un’immagine OCI accelerata, cioè costruita appositamente con tutte le librerie necessarie per quell’hardware. Se non trova nessuna GPU supportata, ripiega sulla CPU senza che tu debba cambiare nulla. Dentro quel container gira il vero motore di inferenza, che a seconda dei casi è llama.cpp oppure vLLM: è lì che il modello viene effettivamente eseguito, mentre sul tuo sistema non finisce nessuna libreria.
Da qui derivano due conseguenze pratiche che, secondo me, sono il vero motivo per provarlo. La prima è la riproducibilità: l’immagine è legata alla versione minor di RamaLama, quindi due macchine con la stessa versione eseguono il modello nello stesso ambiente, senza il classico “da me funziona“. La seconda è la pulizia. I modelli che scarichi restano salvati in una cartella dedicata, di norma ~/.local/share/ramalama, quindi non li riscarichi a ogni avvio.
Il container che li esegue, invece, è temporaneo, viene creato al momento del comando e cancellato appena chiudi. Sul sistema non resta alcun file sparso in giro.
Installazione su Linux, macOS e Windows
RamaLama ha un solo prerequisito: per sfruttare l’isolamento serve un container engine. Quando trova sia Podman sia Docker, RamaLama sceglie Podman per impostazione predefinita, perché permette container rootless e si integra meglio con la sua filosofia. Se preferisci Docker, basta impostare la variabile d’ambiente RAMALAMA_CONTAINER_ENGINE=docker. Se non c’è nessuno dei due, lo strumento prova comunque a eseguire il modello con il software presente sul sistema, ma in quel caso perdi proprio la parte di isolamento che lo rende interessante.
Su Linux il modo più pulito, se sei su Fedora o derivate, è il pacchetto ufficiale.
sudo dnf install ramalama
Su qualsiasi altra distribuzione, o se vuoi l’ultima versione disponibile, lo script di installazione ufficiale funziona sia su Linux sia su macOS.
curl -fsSL https://ramalama.ai/install.sh | bash
In alternativa, trattandosi di un progetto Python, puoi installarlo via PyPI in un ambiente isolato. È la strada che preferisco quando voglio tenere separato lo strumento dal resto del sistema.
pip install ramalama
Su Windows il supporto passa per WSL2. Serve Docker Desktop oppure Podman Desktop configurati con il backend WSL2 e una versione di Python pari o superiore alla 3.9; l’installazione vera e propria avviene poi con pip install ramalama. Per usare la GPU NVIDIA dentro WSL2 occorre la configurazione dedicata descritta nella documentazione del progetto. Non è la procedura più immediata tra le tre, ma funziona: anche su Windows i modelli girano dentro container, non direttamente sul sistema.
Una volta installato, conviene verificare che tutto sia a posto prima di scaricare gigabyte di modelli. Il comando info mostra la configurazione rilevata, incluso il container engine in uso e il supporto GPU.
ramalama version
ramalama info
Se ramalama info riporta correttamente la tua scheda video, sei pronto. In caso contrario, nella maggior parte dei casi il problema è a monte, cioè nei driver o nel toolkit container del produttore, non in RamaLama.
Prima esecuzione con ramalama
Il comando con cui inizierai è ramalama run, che scarica il modello, prepara il container e ti lascia in una chat interattiva nel terminale. La prima esecuzione è sempre la più lenta, perché oltre al modello deve scaricare l’immagine accelerata adatta al tuo hardware; dalla seconda in poi parte in pochi secondi.
ramalama run hf://unsloth/Qwen3.6-27B-GGUF
Il prefisso hf:// indica che il modello va preso da Hugging Face, che è il transport su cui conviene puntare oggi. RamaLama ne supporta diversi, da ModelScope ai registri OCI veri e propri, fino a Ollama; quest’ultimo però è in via di dismissione, perché i suoi modelli non sono più compatibili con llama.cpp, quindi è bene abituarsi a indicare i modelli con hf://.
Nel momento in cui scrivo, il panorama dei modelli “aperti” da far girare in locale ruota attorno a famiglie come Gemma 4 di Google, uscita ad aprile 2026 con varianti che vanno dalle più leggere (pensate per girare anche solo su CPU) ai modelli densi più capaci, e Qwen3.6 di Alibaba, disponibile in versione densa e in versione MoE (Mixture of Experts) con licenza Apache 2.0. Sono questi i pesi su cui ha senso ragionare adesso.
Mentre la chat è attiva, in un altro terminale puoi vedere coi tuoi occhi che non c’è alcuna magia: il modello è semplicemente un container in esecuzione.
podman ps
Vedrai un container basato sull’immagine quay.io/ramalama/ramalama che ospita il processo di inferenza. Per la scelta del peso, tieni a mente che la quantizzazione determina quanta memoria serve. Un modello da 27 miliardi di parametri quantizzato a Q4_K_M richiede grosso modo 16-17 GB e gira bene su una scheda da 24 GB di VRAM, mentre se hai meno memoria conviene scendere di taglia o di quantizzazione. Puoi indicare il repository e lasciare a RamaLama la scelta del file, oppure puntare direttamente a una specifica variante .gguf quando vuoi il pieno controllo su quale quantizzazione caricare.
RamaLama: dal chatbot al server
La chat interattiva è comoda per le prove, ma il vero valore arriva quando esponi il modello come servizio. È il compito di ramalama serve, che avvia un endpoint REST e, se vuoi, una web UI raggiungibile dal browser.
ramalama serve hf://unsloth/Qwen3.6-27B-GGUF
Per impostazione predefinita il servizio si mette in ascolto sulla porta 8080, oppure su una porta libera tra la 8081 e la 8090 se la prima è occupata; con -p puoi forzarne una a tua scelta. L’endpoint esposto è compatibile con l’API di OpenAI, e questo è il punto che lo rende davvero utile: qualsiasi applicazione, libreria o script già scritto per chat/completions può puntare al tuo server locale cambiando solo l’URL di base. In pratica, una volta avviato il server, puoi interrogarlo con una normale chiamata HTTP.
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"messages": [
{"role": "user", "content": "Spiegami cosa sono i container OCI in due righe"}
]
}'
Se preferisci un’interazione visiva, l’interfaccia web è attiva di default; quando non ti serve, la disattivi con --webui off per ridurre la superficie esposta. Un aspetto che apprezzo è la possibilità di far girare più modelli contemporaneamente come servizi in background, ciascuno nel suo container e sulla sua porta, semplicemente aggiungendo -d per il detach e un nome.
ramalama serve -d -p 8080 --name assistente hf://unsloth/Qwen3.6-27B-GGUF
ramalama serve -d -p 8081 --name piccolo hf://unsloth/Qwen3.6-4B-GGUF
ramalama stop --all
In questo modo puoi tenere, per esempio, un modello grande per i compiti complessi e uno piccolo e veloce per le risposte rapide, instradando le richieste verso l’uno o l’altro a seconda del bisogno. Quando hai finito, ramalama stop chiude i container e libera la memoria, senza lasciare processi orfani sul sistema.
convert, push e RAG
Dato che un modello è trattato come un’immagine, puoi impacchettarlo in un artefatto OCI vero e proprio e distribuirlo con la stessa infrastruttura che usi già per i container. Il comando convert prende un modello da Hugging Face, lo trasforma con la quantizzazione che indichi e lo salva come immagine locale.
ramalama convert --gguf Q4_K_M hf://ibm-granite/granite-3.2-2b-instruct \
oci://quay.io/tuonome/granite-3.2-q4-k-m:latest
Da quel momento il modello è un’immagine a tutti gli effetti, che puoi eseguire come tale.
ramalama run oci://quay.io/tuonome/granite-3.2-q4-k-m:latest
E, soprattutto, puoi caricarla su qualunque registry compatibile, da Quay a Docker Hub fino a un Artifactory aziendale, con ramalama push. Il vantaggio pratico è notevole: in un’azienda o in un homelab puoi pubblicare una versione esatta e versionata di un modello, e tutti gli altri la scaricano con un comando, certi di eseguire i medesimi pesi e la medesima quantizzazione.
Sulla stessa logica si appoggia anche il RAG (Retrieval Augmented Generation), cioè la tecnica con cui un modello risponde basandosi su documenti che gli fornisci tu. Il comando rag prende i tuoi file, in formato PDF, DOCX, PPTX, Markdown e altri, li elabora con la libreria Docling dentro un container dedicato e ne ricava un database vettoriale, impacchettandolo a sua volta come immagine OCI.
ramalama rag ./documenti oci://quay.io/tuonome/mia-knowledge-base
ramalama run --rag oci://quay.io/tuonome/mia-knowledge-base hf://unsloth/Qwen3.6-27B-GGUF
Il risultato è un assistente che ragiona sui tuoi documenti, costruito senza inviare nulla a servizi esterni. L’intera knowledge base diventa un’immagine che puoi archiviare, versionare e condividere come faresti con qualsiasi altro container.
Finalmente in un container
RamaLama non cerca di vincere sul terreno della semplicità assoluta, e fa bene a non provarci, perché su quel fronte strumenti più snelli come Ollama restano imbattibili per chi vuole solo una chat in due minuti. La sua scommessa è un’altra, ovvero portare nel mondo dell’AI locale le buone pratiche che il mondo dei container ha già consolidato in anni di uso in produzione.
Isolamento, riproducibilità, distribuzione tramite registry e gestione tramite systemd o Kubernetes sono il cuore stesso del progetto, e la sua coerenza con l’ecosistema Podman non è un caso, vista la provenienza di chi lo sviluppa.
Se sei uno sviluppatore, un sysadmin o un appassionato che ha già Podman o Docker installati e che considera normale ragionare per immagini e container, RamaLama si incastra nel tuo flusso di lavoro quasi senza attrito, e ti restituisce un controllo sui modelli che gli strumenti più “consumer” non offrono.
Se invece ti interessa soltanto provare l’ultimo modello uscito senza pensare all’infrastruttura sotto, la curva di ingresso rischia di sembrare un passaggio in più rispetto al beneficio percepito. Installalo, lancia un ramalama run con Gemma 4 o Qwen3.6 e apri podman ps in un altro terminale. Se vedere il tuo modello comparire come un container ti fa pensare “ecco, finalmente”, hai trovato lo strumento giusto per te.
