LLM in locale: scegliere tra Ollama e llama.cpp

LLM in locale: meglio Ollama o llama.cpp?

Ollama è la scelta più pratica per gestire le postazioni degli sviluppatori o un piccolo servizio interno di modelli. I comandi di gestione, le configurazioni con un nome e l'API per le applicazioni riducono il lavoro necessario per passare dal download di un modello al suo utilizzo. Restano da dimensionare la memoria e controllare gli accessi, ma le istruzioni di configurazione per ogni utente devono coprire meno aspetti del servizio di inferenza.

llama.cpp è più adatto a chi ha la responsabilità della configurazione dell'inferenza. Offre maggiori vantaggi quando occorre scegliere un file GGUF preciso, esaminare una nuova quantizzazione, regolare la distribuzione del modello sulla GPU oppure ottimizzare le richieste simultanee e l'allocazione del contesto. Il risultato è un deployment descrivibile nei dettagli; in cambio, bisogna mantenerne personalmente la configurazione.

Se il runtime attuale soddisfa gli obiettivi di risposta e qualità del carico di lavoro, conviene tenerlo. Passare da Ollama a llama.cpp soltanto perché qualcuno ha pubblicato un benchmark più veloce sul proprio portatile è una motivazione debole. Il passaggio ha senso quando è chiaro quale controllo manca o quale problema misurato si vuole risolvere.

Confronto verificato sulla documentazione online di entrambi i progetti il 16 ottobre 2026. I criteri sono installazione, controllo dei file dei modelli, comportamento delle API, concorrenza e supporto hardware. Non si tratta di una prova diretta delle prestazioni.

Le funzionalità della tabella sono descritte nella guida alla CLI di Ollama, nella sua guida all'importazione dei GGUF e nella documentazione del server di llama.cpp. Entrambi i progetti software locali sono gratuiti e vanno distinti dalle offerte in hosting di Ollama; le licenze dei modelli restano separate. Repository di Ollama, repository di llama.cpp.

Radici comuni, responsabilità diverse

Ollama aggiunge all'inferenza un livello di gestione dei modelli e di servizio; llama.cpp dà accesso diretto agli strumenti di inferenza. L'inferenza è il processo che trasforma i pesi del modello e l'input dell'utente in token di output. Gestire questo processo significa anche trovare i modelli, dare un nome alle configurazioni, caricarli, accettare richieste e dismettere le vecchie versioni dei file.

Ollama cita llama.cpp nei riconoscimenti del proprio repository. Definirlo però «solo un wrapper» è troppo categorico: il codice attuale comprende anche altri backend, inclusi componenti MLX. Le radici comuni non implicano che ogni modello usi lo stesso backend, la stessa revisione o lo stesso percorso di esecuzione. Codice sorgente e riconoscimenti di Ollama.

La scelta dipende da quanti dettagli del funzionamento devono entrare nelle istruzioni di deployment. Se a uno sviluppatore bastano il nome documentato di un modello e un endpoint, il pacchetto offerto da Ollama semplifica il lavoro. Se chi gestisce l'infrastruttura deve documentare insieme checksum del file, build del backend e impostazioni di memoria, la configurazione diretta di llama.cpp rende questi elementi più espliciti.

Installazione e gestione dei modelli: Ollama semplifica il lavoro quotidiano

Ollama: una configurazione pronta da replicare

Ollama esegue modelli in locale e offre una libreria gestita e un'API di servizio. È disponibile per macOS, Windows e Linux. La CLI include le operazioni quotidiane che servono a chi gestisce l'IT: pull, run, ls, rm, ps e stop. Un Modelfile, cioè un file di testo che descrive la configurazione di un modello, permette di riunire modello di base e istruzioni sotto un unico nome. Guida introduttiva a Ollama, documentazione della CLI.

Per un progetto pilota condiviso di assistenza alla programmazione, basta documentare una volta il modello approvato, la sua configurazione e l'endpoint. Uno sviluppatore non dovrebbe dover studiare l'allocazione sulla GPU soltanto per collegare un'applicazione. È questo il motivo più convincente per preferire Ollama a llama.cpp.

Il limite emerge quando il flusso di lavoro predisposto non permette di ottenere il comportamento richiesto al servizio. Non bisogna presumere che un'opzione disponibile in llama.cpp possa essere passata a Ollama senza modifiche. Prima di basare il deployment su una determinata impostazione, va verificato che sia disponibile nella versione installata.

llama.cpp: accesso diretto, senza obbligo di compilare

llama.cpp è un insieme di strumenti per l'inferenza che comprende una riga di comando, un server HTTP e un'interfaccia web. Il README attuale propone un installer, versioni precompilate, Docker e compilazione dai sorgenti. Documenta inoltre llama cli -hf e llama serve -hf per caricare modelli direttamente da Hugging Face, la piattaforma che li ospita. Compilare dai sorgenti è un'opzione, non un requisito per iniziare. Installazione e guida introduttiva a llama.cpp.

È altrettanto sbagliato pensare che usare direttamente llama.cpp significhi dover avviare per sempre, a mano, un processo indipendente per ogni modello. La documentazione del server descrive un router con directory dei modelli e preset di configurazione. La differenza sta in quanta parte dell'organizzazione del servizio si sceglie e si mantiene in proprio. Documentazione del router del server.

Vince Ollama per l'installazione e la gestione ordinaria dei modelli. In questo ambito llama.cpp conviene soltanto quando la configurazione esplicita porta valore al proprio flusso di lavoro. Se serve soprattutto un ambiente desktop per lavorare con i modelli, il confronto più pertinente è Ollama vs LM Studio.

GGUF e quantizzazione: llama.cpp offre più controllo sui file

Entrambi eseguono modelli GGUF; llama.cpp offre un percorso più diretto per prepararli e selezionarli. GGUF è un formato di file che contiene pesi e metadati del modello. La quantizzazione memorizza i pesi con una precisione inferiore per ridurne l'ingombro, con un compromesso sulla qualità che dipende dal modello e dal compito.

Lo strumento di quantizzazione di llama.cpp documenta formati come Q4_K_M, Q5_K_M e Q8_0, oltre ai controlli basati su matrice di importanza e su singoli tensori. Una matrice di importanza aiuta a individuare le parti del modello che richiedono più precisione; i controlli per tensore consentono di trattare in modo diverso i vari array di pesi. Sono opzioni utili quando un file scaricato già pronto non soddisfa gli obiettivi di memoria o qualità. Guida alla quantizzazione di llama.cpp.

Ollama può importare un GGUF già preparato tramite una riga FROM in un Modelfile. La documentazione attuale precisa che l'importazione di un GGUF non quantizza il modello e invita a usare prima strumenti come llama-quantize. È una suddivisione del lavoro utile: preparare il file con llama.cpp, poi distribuire tramite Ollama una configurazione identificata da un nome. Documentazione sull'importazione in Ollama.

Per esempio, dopo aver salvato un modello testuale compatibile composto da un unico file in ./team-model.gguf, questi comandi creano una configurazione Ollama con un'allocazione del contesto scelta esplicitamente:

cat > Modelfile <<'MODEL'
FROM ./team-model.gguf
PARAMETER num_ctx 8192
MODEL
ollama create team-local -f Modelfile
ollama run team-local

Il nome del file e quello del modello sono a scelta dell'utente; il valore del contesto è un esempio, non una raccomandazione valida per ogni carico di lavoro. La sintassi è tratta dalla documentazione del Modelfile.

L'estensione .gguf non certifica la compatibilità. Servono comunque il supporto per l'architettura del modello e per il suo template di conversazione, cioè le regole che trasformano i messaggi nell'input atteso. I modelli multimodali possono richiedere anche componenti separati per immagini o audio. La guida alla quantizzazione di llama.cpp spiega i file aggiuntivi del proiettore. Ottenere una risposta testuale corretta, da solo, non convalida l'input visivo né l'uso di strumenti.

Vince llama.cpp per la quantizzazione personalizzata e la scelta precisa dei file del modello. Ollama resta adatto quando il modello preparato funziona e si preferisce il suo flusso operativo. Per scegliere i pesi indipendentemente dal runtime, si può partire dai migliori LLM locali del 2026.

Server e compatibilità API: Ollama facilita le integrazioni standard

Ollama è la scelta iniziale più semplice per un'applicazione che usa un'API locale documentata; llama.cpp prevale quando occorre ottimizzare la configurazione del server. Ollama offre un'API nativa ed endpoint compatibili con OpenAI. Anche llama.cpp fornisce chat completions, responses ed embeddings compatibili con OpenAI. In questo caso compatibilità significa un'interfaccia di richiesta familiare, non un comportamento identico per ogni funzionalità. Documentazione delle API di Ollama, documentazione del server di llama.cpp.

Un limite concreto può determinare la fattibilità di una migrazione: l'API Responses di Ollama è senza stato. Non supporta previous_response_id né conversation. Se l'applicazione si affida a questi campi perché il server ricordi una conversazione, cambiare soltanto l'URL di base non basta. Occorre verificare il comportamento documentato del server di destinazione e decidere dove conservare la cronologia.

Un altro punto da considerare è la configurazione del contesto. La guida alla compatibilità OpenAI di Ollama rimanda al Modelfile per modificare la dimensione del contesto di un modello locale. Questa impostazione è diversa dal limite ai token di output: consentire una risposta più lunga non permette automaticamente di accettare un input più lungo.

In un deployment diretto di llama.cpp, il server mette a disposizione alias dei modelli, impostazioni dei template di chat, chiavi API e metriche opzionali. Questi controlli sono utili quando un assistente interno deve mantenere un nome stabile nell'API mentre si sostituisce il file del modello sottostante. Aumentano però anche le configurazioni da controllare e preservare durante gli aggiornamenti.

Richieste simultanee: llama.cpp rende espliciti i controlli del servizio

Ollama può gestire richieste sovrapposte; llama.cpp espone più direttamente la configurazione della pianificazione e della memoria. Caricare più modelli contemporaneamente e gestire richieste simultanee sono attività diverse. Tenere un modello per la programmazione accanto a uno per gli embedding consuma memoria in modo diverso rispetto a più conversazioni che condividono un unico modello già caricato.

Ollama documenta OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS e OLLAMA_MAX_QUEUE. Il valore predefinito delle richieste parallele per modello è 1, e l'elaborazione parallela dipende dalla memoria disponibile. Aumentare il limite della coda permette di lasciare più lavoro in attesa; non crea capacità di inferenza. Documentazione di Ollama sulla concorrenza.

llama.cpp documenta decodifica parallela, continuous batching e slot del server. Il continuous batching permette al server di accogliere nuovo lavoro man mano che le richieste in corso terminano. Uno slot è lo spazio assegnato a una richiesta in elaborazione. Tra i controlli disponibili figurano --parallel e --kv-unified-per-slot, oltre alle impostazioni per la distribuzione sulla GPU e la cache. Controlli del server di llama.cpp.

Dimensionare il contesto prima di aumentare il parallelismo

In un progetto pilota esemplificativo, 4 richieste simultanee × 8,192 token di contesto = 32,768 posizioni per i token. È una capacità di contesto, non una misura della RAM. La cache KV, che conserva lo stato di attenzione del modello, occupa memoria insieme ai pesi e alle altre allocazioni di lavoro. Il suo ingombro in byte dipende dall'architettura e dalla precisione della cache.

Con il file compatibile team-model.gguf dell'esempio precedente, un'installazione attuale di llama.cpp può esprimere direttamente questa configurazione:

llama serve -m ./team-model.gguf \
  --alias team-local \
  --host 127.0.0.1 --port 8080 \
  --parallel 4 \
  --kv-unified-per-slot 8192

Sono impostazioni scelte per il progetto pilota, non risultati di benchmark né valori predefiniti del progetto. La documentazione del server indica che, in assenza di un --ctx-size esplicito, il pool KV condiviso viene dimensionato moltiplicando il numero di slot per il limite di ciascuno. Il progetto pilota va mantenuto sull'interfaccia di loopback finché i controlli di accesso non sono pronti.

Con Ollama, parallelismo e contesto si configurano nell'ambiente del servizio; poi si verificano il contesto effettivo e la distribuzione tra CPU e GPU con ollama ps. La pagina dedicata al contesto descrive valori predefiniti che dipendono dall'hardware: è quindi necessario annotare l'allocazione realmente utilizzata. Configurazione del contesto in Ollama.

Le prestazioni vanno misurate sul carico di lavoro

Il nome del progetto non basta a decretare un vincitore in ogni test di latenza o throughput. Prima del confronto bisogna allineare pesi, quantizzazione, template, contesto, backend e hardware. Vanno poi distinti il tempo di attesa, il tempo al primo token, la velocità di generazione e le richieste completate sotto carico.

Per un assistente di supporto interno, una risposta isolata veloce non dimostra che tutto il personale possa usarlo contemporaneamente. Occorre riprodurre domande brevi e richieste su documenti lunghi che rappresentino l'uso reale, misurare separatamente gli avvii a freddo e annotare versioni dei runtime e data. Una differenza di velocità dichiarata è utile solo se sono indicati autore del test, data, hardware, modello e carico di lavoro.

Vince llama.cpp quando serve un'ottimizzazione mirata della concorrenza. Conviene restare con Ollama se le sue impostazioni soddisfano gli obiettivi del servizio e la semplicità di gestione vale più dei controlli aggiuntivi.

Apple Silicon e GPU: scegliere il backend in base alla macchina

Ollama è più pratico per i deployment ordinari sulle postazioni di lavoro; llama.cpp offre più controllo sui backend per esigenze specifiche. Entrambi supportano l'accelerazione tramite GPU Apple. Ollama documenta il supporto Metal, mentre llama.cpp considera Apple Silicon una piattaforma di riferimento e usa Metal, Accelerate e ottimizzazioni ARM. Supporto hardware di Ollama, hardware supportato da llama.cpp.

Su Mac conviene partire dall'applicazione nativa o dai binari nativi. La documentazione di Ollama indica che Docker Desktop su macOS non offre accelerazione GPU. Trasferire in un container una configurazione nativa funzionante può quindi cambiare il percorso di esecuzione che si pensava di confrontare. Limite dell'accelerazione GPU con Docker per Ollama.

Per le altre postazioni, Ollama documenta il supporto NVIDIA, AMD tramite ROCm e Vulkan quando il relativo backend è installato. llama.cpp espone CUDA per NVIDIA, HIP per AMD, Vulkan e SYCL, con istruzioni di compilazione per selezionare i backend. Occorre verificare la combinazione precisa di sistema operativo, GPU e driver: il solo nome del produttore non garantisce il supporto. Guida alle GPU di Ollama, guida alla compilazione di llama.cpp.

Il primo controllo pratico riguarda la distribuzione dei pesi: sono sulla GPU, sulla CPU o su entrambe? Avere più impostazioni non risolve il problema di una combinazione di modello e contesto che supera la memoria allocata. Prima si sceglie una configurazione che rientri nei limiti, poi si valuta se la qualità delle risposte è accettabile.

Che cosa cambia con Muse Spark Open?

Il fatto che Meta citi llama.cpp offre una strada documentata da esplorare, non un motivo automatico per sostituire Ollama. Nell'annuncio di Muse Spark Open del 15 ottobre 2026, Meta include llama.cpp tra i motori di inferenza supportati. Questo rende pertinente una prova diretta con llama.cpp per valutare il modello appena rilasciato, senza presumere che un altro runtime abbia già integrato un supporto equivalente. Annuncio di Meta.

Il contesto hardware conta. Meta descrive 816B di parametri totali e 42B di parametri attivi, e l'esempio desktop utilizza due Mac Studio Apple M5 Ultra con MLX. Quell'esempio non è un benchmark di llama.cpp; inoltre, il numero di parametri attivi non sostituisce la verifica della memoria necessaria per l'intero modello. Descrizione del modello e dell'hardware di Meta.

Per il proprio deployment bisogna verificare insieme build esatta, file del modello, quantizzazione, template e tipi di input richiesti. Il supporto di un motore citato in un annuncio di lancio non dimostra che il modello sia supportato dalla versione di Ollama installata, né che possa essere eseguito su un normale portatile da sviluppatore. La conseguenza utile è una nuova possibilità di valutazione per chi gestisce l'infrastruttura; la distribuzione sulle postazioni richiede comunque verifiche proprie.

Passare da Ollama a llama.cpp: migrare anche la configurazione

Il lavoro di migrazione consiste nel preservare il comportamento, non solo nel copiare i pesi. La cronologia dell'applicazione, l'indice di recupero delle informazioni e la gestione delle richieste possono trovarsi al di fuori di entrambi i runtime. Quando si sostituisce il servizio del modello, questi confini devono restare chiari.

Non conviene cambiare se il servizio attuale funziona e nessuno ha bisogno dei controlli aggiuntivi. È anche possibile preparare un GGUF con llama.cpp e continuare a servirlo tramite Ollama. I due progetti possono svolgere ruoli diversi nello stesso flusso di lavoro.

Ollama vs llama.cpp vs vLLM: quando andare oltre la singola postazione

vLLM va valutato quando il requisito principale diventa sostenere un traffico condiviso continuativo o distribuire l'inferenza. È un motore per l'erogazione dell'inferenza la cui documentazione mette in risalto continuous batching, gestione della cache e opzioni di esecuzione distribuita. Queste capacità meritano una valutazione quando il servizio dispone di capacità dedicata su acceleratori. Documentazione di vLLM.

Il continuous batching, da solo, non è il criterio che separa le opzioni, perché anche llama.cpp lo supporta. Non esiste neppure un numero universale di dipendenti che imponga la migrazione. Un servizio con richieste brevi occasionali ha un carico diverso da quello di un gruppo più piccolo che invia senza interruzione lunghi compiti di programmazione.

Il criterio di scelta è misurabile: se la configurazione attuale non raggiunge l'obiettivo di risposta sotto un picco di domanda rappresentativo, e vLLM offre il controllo o la capacità di deployment che manca, vale la pena provarlo. Se invece l'obiettivo viene raggiunto, conviene mantenere il servizio attuale. Il confronto tra Ollama e vLLM approfondisce questa scelta.

Il prossimo passo concreto è scegliere un flusso di lavoro locale, fissare modello e contesto, definire il volume previsto di richieste simultanee e riprodurre quel carico prima di allargare l'accesso. Il risultato permette di capire se serve un runtime diverso o una configurazione migliore.

Domande frequenti

La checklist per valutare i flussi di lavoro aziendali con l'AI aiuta a scegliere il primo flusso di lavoro privato che vale la pena servire in locale. La newsletter permette poi di seguire i cambiamenti degli strumenti.