Nella puntata 1 abbiamo chiuso la domanda cloud vs locale. Qui si sceglie come far girare il modello: Ollama, LM Studio, llama.cpp o vLLM.
Questa puntata vive nell’hub AI Engineering (e nel percorso descritto in cos’è AI Engineering). Non è un ranking di stelle GitHub. È un confronto sui vincoli: VRAM, ops, compatibilità API, chat vs batch.
In breve: Per un solo sviluppatore sul laptop, parti da Ollama (o LM Studio se vuoi la GUI). Passa a llama.cpp diretto quando ti serve controllo su offload, edge o build custom. Scegli vLLM quando hai utenti concorrenti su GPU Linux/accelerator supportati e accetti ops più VRAM prenotata. La domanda non è “qual è il più veloce”: è un utente o molti, chat o throughput, quanto tempo umano per l’ops.
La domanda che taglia la scelta
Non “quale runtime è migliore?”. È: quanti utenti, che workload, che hardware, quanto ops.
Un runtime LLM locale è il programma che carica i pesi del modello e produce token sulla tua macchina (o sul tuo piccolo cluster), senza noleggiare solo token da un provider chiuso. Runtime, GGUF e KV cache, spiegati in poche righe, sono anche nel glossario.
Quattro assi bastano quasi sempre:
- Workload — chat interattiva a bassa concorrenza, oppure throughput/batch con code.
- Hardware — laptop CPU/Apple Silicon, consumer GPU, server NVIDIA/AMD supportato.
- Concorrenza — un loop tuo, oppure N richieste sovrapposte sullo stesso modello.
- Tempo umano — installare e dimenticare, oppure schedulare, metriche, aggiornamenti frequenti.
C’è anche un distinguo che i roundup mischiano: Ollama e LM Studio sono soprattutto layer di esperienza (download, default, API comoda). llama.cpp è spesso il motore sotto i file GGUF. vLLM è un serving system pensato per concorrenza (documentazione vLLM). Confrontare “esperienza” e “serving” come se fossero lo stesso prodotto porta a conclusioni sbagliate.
Tabella rapida
Sintesi operativa (valori tipici, non “sempre”; verifica sulla doc del pezzo che installi):
Ollama — best for: loop singolo, prototipi, harness. Setup molto basso. Hardware: qualsiasi OS. Concorrenza default spesso 1 req/modello. Formato: GGUF (+ MLX). Ruolo: esperienza + API.
LM Studio — best for: GUI, shopping modelli, chat desktop. Setup app. Hardware: Mac/Windows (Linux ok). Predizioni parallele configurabili. Formato: GGUF (+ MLX). Ruolo: esperienza GUI + server locale.
llama.cpp — best for: controllo, edge, CPU/GPU offload. Setup medio. Hardware ampio (CPU, Metal, CUDA, Vulkan, ROCm…). Slot/`--parallel`, cont-batching sul server. Formato: GGUF. Ruolo: motore/libreria.
vLLM — best for: multi-utente su GPU server. Setup alto. Linux + accelerator supportato. Continuous batching + KV paged. Formato: HF e quant serving (AWQ/GPTQ/FP8…). Ruolo: serving produzione.
Per un confronto serving vs CPU-first vedi anche Red Hat Developer su llama.cpp vs vLLM.
Ollama — default a basso rimpianto
Ollama è un runtime con CLI e API locale pensato per far partire un modello in pochi minuti. Vince quando vuoi un endpoint da chiamare dal tuo codice senza costruire tu lo stack.
Ti dà gestione modelli (`pull`) e un’API in stile OpenAI abbastanza comoda da collegare a un harness o a un tool interno (documentazione Ollama). Per un solo sviluppatore che itera su prompt e tool, il costo ops è basso. Una nota sul formato: con la 0.40.2 Ollama converte in background i modelli scaricati con le versioni precedenti e tiene la copia vecchia come backup, quindi per un po' ogni modello occupa circa il doppio su disco. Cosa controllare prima di aggiornare è in Ollama 0.40.
Il vincolo da non ignorare è la concorrenza. Nella FAQ ufficiale, `OLLAMA_NUM_PARALLEL` controlla quante richieste parallele per modello sono ammesse; il default tipico è orientato a un uso a bassa concorrenza, con coda dietro (FAQ Ollama). Va benissimo per il tuo editor o un agent personale. Diventa un problema se tre colleghi e due job batch colpiscono lo stesso host “come fosse un’API cloud”.
Esempio concreto: un harness che chiama tool sul repo locale 20 volte al giorno su un 7B/14B quantizzato. Ollama tiene il loop economico. Lo stesso host con dieci chat aperte in parallelo senza alzare il parallelismo fa crescere la coda, non i tok/s miracolosi.
Dove regge: prototipi, tool interni a basso traffico, sperimentazione di harness senza bruciare credito cloud a ogni tentativo (tema della puntata 1).
Dove no: SLA di latenza p95 con utenti sovrapposti, senza tuning e senza accettare che la coda sia parte del prodotto.
LM Studio — GUI, shopping modelli, server locale
LM Studio è un’app desktop per scaricare, chat-tare e servire modelli locali. Vince se vuoi vedere i modelli: confrontare chat e contesto senza vivere nella shell.
Da lì puoi esporre anche un server OpenAI-compatible (documentazione LM Studio). Utile per demo, per far provare un modello a chi non vuole la CLI, per esplorare quantizzazioni diverse con meno frizione.
Non è, di per sé, un pezzo di serving multi-utente serio. Puoi alzare le predizioni concorrenti e usare il server senza GUI, ma l’architettura resta quella di un’esperienza desktop: comoda, non “scheduler di produzione”.
Sceglilo quando il collo di bottiglia è umano (capire quale modello ti basta), non quando il collo di bottiglia è throughput sotto carico.
llama.cpp — controllo, GGUF, edge
llama.cpp è un motore di inferenza C/C++ centrato sul formato GGUF e sull’efficienza CPU/GPU mista. Vince quando ti serve il motore nudo: offload fine, CPU-first, hardware strano, embed in un binario, flag che i wrapper non espongono (repository llama.cpp).
GGUF è il formato che ha reso l’AI locale praticabile su macchine normali. Molti layer esperienza (Ollama, LM Studio) si appoggiano a motori di questa famiglia per una fetta ampia dei modelli. Usarlo diretto ha senso quando i default del wrapper non bastano: spezzare layer tra GPU e RAM, target edge, build custom, server HTTP che configuri tu (`llama-server` con continuous batching opzionale).
Il costo è ops e superficie: aggiornamenti, compilazione/backend, e — se serve un’API — la tua colla HTTP, auth, metriche. In produzione “con lavoro” funziona; non è gratis in tempo umano.
Tempo umano è costo. Se non ti serve il controllo, paga il wrapper.
vLLM — concorrenza e prenotazione VRAM
vLLM è un motore di serving per LLM pensato per throughput multi-richiesta su accelerator. Vince quando “locale” significa servire più richieste insieme su GPU Linux supportate (docs vLLM — serving).
Qui il punto non è il tok/s di una chat sola. È lo scheduler: continuous batching e gestione della KV cache (PagedAttention e evoluzioni, come descritto nel paper vLLM) per tenere alto l’uso del calcolo quando le richieste si sovrappongono. Sotto carico multi-utente il gap rispetto a un runtime desktop può essere grande. Su un solo flusso interattivo spesso non giustifica l’ops.
Il vincolo vero sulla consumer GPU è la prenotazione memoria. vLLM tipicamente prende una quota alta della VRAM all’avvio tramite `--gpu-memory-utilization` (default nell’ordine del ~0,9 a seconda della versione; vedi engine args) e usa il resto per il pool KV. Su una 24 GB, dopo i pesi, può restare poco spazio per altri processi GPU. Non è un bug: è il design del serving. Se la scheda deve anche fare altro, abbassa l’utilizzo o resta su Ollama/llama.cpp.
Esempio concreto: tre sviluppatori e un job di classificazione batch sullo stesso 8B. Con Ollama in default la coda cresce. Con vLLM sullo stesso host NVIDIA il batch continuo tiene meglio il throughput aggregato — a patto di accettare ops e VRAM prenotata.
Scegli vLLM quando hai utenti concorrenti (o batch denso), hardware supportato, e qualcuno che tiene driver, release e metriche. Non sceglierlo “perché è quello da produzione” se la produzione è tu e un laptop.
Stessa API, scheduler diversi
API OpenAI-compatible significa che il client parla un contratto simile a quello di OpenAI (`/v1/chat/completions`), anche se il backend è locale.
Ollama, LM Studio, llama.cpp server e vLLM espongono spesso questa superficie. Il codice del client si sposta con poco sforzo. Bene. Quali parametri cambiare e cosa si rompe davvero (nomi dei modelli, tool calling, streaming, default su contesto e sampling) lo trovi in API OpenAI-compatible in locale.
Non confondere superficie API e comportamento sotto carico. La stessa chiamata può significare: “esegui ora”, “metti in coda”, o “inserisci nel batch continuo”. La latenza p95 e il throughput aggregato seguono lo scheduler, non il JSON.
Misura quello che ti interessa davvero: utenti sovrapposti, lunghezza contesto, coda, errori OOM — non solo un tok/s single-stream preso da un thread. Un confronto onesto tra serving e desktop lo dice esplicitamente Red Hat: i bench ad alta concorrenza raccontano vLLM, non il caso “un utente sulla laptop” (llama.cpp vs vLLM).
Cosa conviene fare adesso
Albero decisionale breve:
- Un utente, laptop, vuoi partire oggi → Ollama. Se preferisci GUI → LM Studio.
- Ti servono flag, edge, offload, embed → llama.cpp diretto.
- Più utenti sulla stessa GPU Linux → vLLM (o famiglia serving), con budget VRAM e ops dichiarati.
- Non sai ancora se il locale regge il tuo caso → resta sulla puntata 1 e misura un loop reale prima di cambiare runtime.
Domande rapide
Ollama basta “in produzione”? Sì se produzione = tool interno o singolo utente e accetti la coda. No se produzione = N utenti concorrenti con p95 stretto senza un serving dedicato.
vLLM sul Mac? Non è il percorso tipico. Su Apple Silicon resta più onesto Ollama, LM Studio o llama.cpp/MLX.
Devo imparare llama.cpp se uso Ollama? Solo quando i default non bastano. Prima misura il vincolo (VRAM, concorrenza, latenza); poi scendi di astrazione.
Prossimo episodio della serie, ora online: Guida AI locale 3: modelli, quantizzazione e VRAM — quanto modello ti basta, e cosa perdi scendendo di bit. Il percorso completo resta sull’hub AI Engineering.
