Puntata 228 — Ollama, LM Studio, vLLM: runtime locali

Livello: 🧙 Maestro Yoda · Capitolo 21 · Open source e HuggingFace

Hai il modello quantizzato. Adesso ti serve qualcosa che lo faccia girare, gestisca la memoria, risponda via API e non ti faccia tenere aperto un terminale con i log. Tre tool fanno il 95% del lavoro nel 2026. Sono molto diversi tra loro: scegli quello giusto.

tre veicoli allineati — una bicicletta elettrica (Ollama, ti porta in giro facile), uno scooter (LM Studio, ti porta con stile e GUI), un furgone da consegne (vLLM, porta 100 colli alla volta). Sotto: “stesso modello, mezzi diversi”

La famiglia in 30 secondi

Tool	Target	UI	API	Quantization	Sweet spot
Ollama	Dev locale	CLI	REST + OpenAI-compatible	GGUF	”ho il portatile, fammi provare un modello in 60 secondi”
LM Studio	Power user	GUI desktop	REST + OpenAI-compatible	GGUF, MLX	”voglio cliccare, non scrivere comandi”
vLLM	Server / prod	CLI	OpenAI-compatible REST	FP16, AWQ, GPTQ, FP8	”devo servire 1000 utenti in azienda”

Esistono altri: llama.cpp (il motore sotto Ollama/LM Studio), text-generation-inference (TGI di HuggingFace, alternativa a vLLM), Jan, koboldcpp, mlc-llm, llamafile, Modular MAX. Restano di nicchia rispetto ai tre top.

Ollama

Lo strumento che ha fatto il momento “open LLM mainstream” tra il 2023 e il 2024. Fondato da ex-Docker, eredita la filosofia: comando singolo, immagini scaricabili, runtime gestito.

Cosa fa

Wrappa llama.cpp (più llama-vision, llava, mistral.rs, ecc.) con un demone in Go.
Modelli scaricabili dal registry pubblico Ollama o da HuggingFace (con ollama pull hf.co/...).
API REST OpenAI-compatible su localhost:11434.

Workflow tipico

# Installa: curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2:3b
ollama run llama3.2:3b "Spiegami la differenza tra RAG e fine-tuning"

Per integrazione codice:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role":"user","content":"Ciao"}]
)

Hot-swap dei modelli automatico (carica a richiesta, scarica dopo idle).

Punti forti

Zero friction. Installazione → primo prompt: 2 minuti.
Cross-platform (Mac, Linux, Windows).
Modelfile per creare varianti custom (FROM llama3 + SYSTEM "...").
Ecosistema enorme: integrazioni con LangChain, LlamaIndex, Continue.dev, Cline, ecc.

Limiti

Throughput single-user oriented (un request alla volta in pratica, anche se ha qualche batching).
Non ideale per produzione enterprise con 1000 utenti.
Quantization limitata a GGUF.
“Versioning” non sempre chiaro (llama3.2:3b può variare nel tempo).

LM Studio

L’app desktop con GUI completa per chi vuole cliccare invece di scrivere comandi.

Cosa fa

GUI nativa Electron-based per Mac/Windows/Linux.
Browser integrato di HuggingFace (cerchi un modello, vedi le quantizzazioni, scarichi con un click).
Chat UI con visualizzazione token/sec, VRAM/RAM usage, temperatura, prompt template.
Server locale OpenAI-compatible.
Supporta GGUF (sempre) e MLX (Apple Silicon native, più veloce su Mac).

Workflow tipico

Apri l’app.
Cerca “Llama 3.2 3B Q4_K_M” nel browser modelli.
Click “Download”.
Carica nel chat.
Per integrazione: tab “Local Server” → click Start. API localhost:1234.

Punti forti

GUI realmente buona, mostra metriche in tempo reale.
Performance MLX su Mac Apple Silicon: spesso 30-50% più veloce di llama.cpp.
Selezione GPU/CPU/Metal facile.
Salva configurazioni di chat + system prompt come “preset”.

Limiti

Closed source. La community ha attriti su questo.
License d’uso commerciale ambigua per piccoli team (controlla i termini correnti).
Più pesante di Ollama (richiede UI sempre aperta o lms CLI separato).
Non scriptable come Ollama in workflow CI/CD.

vLLM

L’inference engine ad alte prestazioni che ha cambiato l’economia del serving open. UC Berkeley, 2023 (Kwon et al., paper “Efficient Memory Management for LLM Serving with PagedAttention”).

Cosa fa

Server di inferenza GPU production-grade.
PagedAttention: gestione KV-cache a “pagine” stile OS, riduce frammentazione e raddoppia/triplica il throughput.
Continuous batching: aggrega richieste in arrivo dinamicamente (non aspetta che un batch finisca per accettare nuove richieste).
Supporta tutti i formati moderni: FP16, BF16, INT8, AWQ, GPTQ, FP8, FP6, marlin.
API OpenAI-compatible su default port.

Workflow tipico

pip install vllm
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 2 \
  --quantization awq \
  --port 8000

Sotto il cofano: scarica il modello da HF, lo carica su 2 GPU in tensor parallelism, espone API REST.

Punti forti

Throughput: 5-20× più alto di Ollama/llama.cpp su GPU server. Per servire 100+ utenti concorrenti è obbligato.
Production-ready: logging, Prometheus metrics, OpenAI-compatible.
Scaling: multi-GPU (tensor / pipeline parallelism) e multi-node.
Aggiornamenti veloci: supporto modelli nuovi entro giorni dal rilascio.

Limiti

GPU required. Su Mac/CPU non gira (o malissimo).
Setup non banale (CUDA, driver, paged memory tuning).
Memoria: richiede dimensionamento accurato di --gpu-memory-utilization.
Niente GUI: solo CLI e API.

Quando usare cosa: 5 scenari

1. “Voglio provare un modello sul mio laptop oggi”

→ Ollama. Veloce, zero config.

2. “Sono designer / non-developer e voglio chattare con un modello locale”

→ LM Studio. GUI, browser modelli, metriche visuali.

3. “Sto costruendo un’app desktop AI con backend locale”

→ Ollama + openai SDK. Stabile, gestione modelli automatica.

4. “Devo servire un modello a 50-500 utenti interni in azienda”

→ vLLM su 1-2 GPU server. È esattamente per quello.

5. “Voglio integrare un modello quantizzato in un’app C++/mobile”

→ llama.cpp direttamente (senza wrapper). Su Android: mlc-llm o llama.cpp con Vulkan.

Throughput a confronto (ordine di grandezza, 2026)

Su Llama-3.1-8B-Instruct, hardware tipico:

Setup	Token/sec single user	Concurrent users sostenibili
Ollama su MacBook M3 Max Q4_K_M	40-70	1-2
Ollama su 4090 Q4_K_M	120-180	2-4
LM Studio su M3 Max MLX	60-90	1-2
vLLM su A100 AWQ	100-150	30-50
vLLM su 2×H100 BF16	200-300	80-150
vLLM + prefix caching, speculative decoding	+30-50%	1.5-2×

(I numeri sono approssimazioni indicative; dipendono da prompt length, context, generation length, batch size, hardware specifico.)

Pattern di integrazione comune

Tutti e tre espongono OpenAI-compatible API. Significa che il tuo codice client può essere indipendente dal backend:

from openai import OpenAI

# Sviluppo locale
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

# Produzione su vLLM
# client = OpenAI(base_url="https://internal.company.com/v1", api_key=os.environ["KEY"])

# Fallback su OpenAI vera
# client = OpenAI()  # usa env var OPENAI_API_KEY

resp = client.chat.completions.create(...)

È il vero motivo per cui questi tre tool hanno vinto: parlano tutti lo stesso linguaggio di API.

Glossario lampo

PagedAttention — gestione KV-cache stile OS virtual memory: pagine fisse, no frammentazione, sharing tra request. Innovazione vLLM.
Continuous batching — invece di batch statici, vLLM aggrega richieste arrivate in finestra mobile.
MLX — framework Apple per ML su Apple Silicon, sfrutta unified memory e Metal. LM Studio lo supporta nativamente.
OpenAI-compatible — endpoint che parla lo stesso protocollo di api.openai.com/v1/chat/completions. Standard de facto.
Modelfile — file di configurazione Ollama (FROM, SYSTEM, PARAMETER, ecc.). Ispirato a Dockerfile.

Take-away

Ollama, LM Studio, vLLM coprono tre target distinti — sviluppatore singolo, power user GUI, server production. La cosa magica è che parlano tutti lo stesso protocollo OpenAI, quindi il tuo codice non cambia quando passi dal portatile alla VM con 4 H100. È il livello di astrazione che mancava nel 2022 e che oggi rende l’open LLM operativamente competitivo con i provider closed.

➡️ Prossima puntata: inference — latenza, throughput, batching, e come si misurano.