llama.cpp vs Ollama nel 2026: quale runtime dovresti eseguire?

Ollama e llama.cpp vengono spesso confrontati come se fossero motori di inferenza rivali. La scelta reale è tra un servizio di modelli gestito e un toolkit che si opera direttamente.

Ollama avvolge una versione fissa e modificata di llama.cpp all’interno di uno scheduler, un archivio modelli e un’API, in modo che il modello denominato diventi l’unità con cui si opera. Il llama.cpp diretto inverte questo schema: il processo llama-server e i suoi flag sono l’unità di lavoro, e ogni scelta riguardante il contesto, la cache KV e la collocazione sulla GPU è una decisione che si prende e che si può mostrare in un comando.

Questa guida confronta i due strumenti nel modo in cui la decisione viene effettivamente presa: installazione e comandi quotidiani, gestione e ciclo di vita dei modelli, controllo runtime, API, prestazioni, modalità di errore e sicurezza. Si conclude con trigger concreti per mantenere Ollama, passare a llama-server e un percorso di migrazione a basso rischio tra i due. Se stai ancora decidendo tra approcci locali, self-hosted e cloud a un livello più alto, inizia con la panoramica sull’hosting LLM; per il panorama più ampio degli strumenti locali oltre a questa coppia, il confronto sull’hosting locale di LLM copre vLLM, LM Studio, LocalAI e molti altri.

llama.cpp vs Ollama: la risposta breve

Se hai bisogno solo di un backend affidabile per Open WebUI, un assistente per la programmazione o alcuni script locali, Ollama è solitamente la scelta che distrae meno. Se continui a chiederti cosa Ollama abbia selezionato, allocato, modificato o nascosto, probabilmente hai raggiunto il punto in cui llama-server è il sistema più pulito.

Cosa significa davvero il confronto nel 2026

llama.cpp è un progetto di inferenza in C e C++ con backend CPU e GPU, strumenti per modelli GGUF, programmi da riga di comando e un server HTTP. Il suo programma di serving diretto supporta Chat Completions, Responses, embed, richieste multimodali, function calling, output strutturato, continuous batching, decodifica speculativa, endpoint di monitoraggio e un’interfaccia web integrata.

Ollama è un servizio a livello più alto. Mantiene un archivio locale dei modelli, assegna nomi stabili ai modelli, scarica e importa artefatti, applica template e predefiniti, seleziona un backend disponibile, schedula i processi dei modelli e scarica i modelli inattivi. La sua API nativa segnala anche informazioni su tempi e caricamento, comode per le applicazioni locali.

L’affermazione spesso ripetuta che “Ollama è solo un wrapper attorno a llama.cpp” è utile in termini di direzione ma tecnicamente incompleta. Ollama fissa il sorgente di llama.cpp, applica patch di compatibilità e avvia un server attraverso il proprio scheduler, ma ha anche comportamenti di prodotto che llama.cpp non definisce; su Apple silicon, Ollama può utilizzare anche il suo motore MLX. Il percorso della richiesta rende concreta la differenza:

Questo porta al modello mentale più utile:

• Con Ollama, il modello denominato è l’unità con cui si opera.
• Con llama.cpp diretto, il processo server e i suoi flag sono l’unità con cui si opera.

Installazione e superficie dei comandi quotidiani

Ollama ottimizza i primi cinque minuti. Dopo l’installazione, il recupero e l’avvio di un modello sono intenzionalmente brevi:

ollama run qwen3:8b

Il nome del modello rappresenta più dei suoi pesi. Ollama può associare a quel nome un template, parametri, un prompt di sistema, una licenza, un adattatore e una versione minima di runtime. ollama list, ollama show, ollama ps e ollama stop forniscono una superficie di gestione coerente.

llama.cpp diretto parte più vicino all’hardware. Si può scaricare un binario di release, compilare una versione specifica per il backend, usare un container o usare il percorso di download più recente da Hugging Face, come dettagliato nella guida rapida di llama.cpp. Un server locale GGUF potrebbe avviarsi così:

llama-server \
  --model /srv/models/qwen3-8b-q4_k_m.gguf \
  --alias qwen3-8b \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 32768 \
  --n-gpu-layers all \
  --flash-attn on

La documentazione attuale di llama.cpp mostra anche il comando unificato llama serve nella sua guida rapida. I nomi degli eseguibili confezionati possono variare a seconda della distribuzione, quindi controlla la release o il pacchetto installato invece di copiare un file di servizio alla cieca.

Il comando più lungo non è automaticamente uno svantaggio. È un record eseguibile del runtime che si intendeva creare. Mettilo in un’unità systemd, un file Compose o uno script shell, e la configurazione diventa rivista invece di essere sparsa tra un manifesto del modello, variabili d’ambiente, opzioni API e predefiniti dello scheduler.

Il compromesso pratico nell’installazione

Ollama è più facile da installare in modo coerente su diverse macchine per sviluppatori. È anche più facile da spiegare a qualcuno che dovrebbe usare un modello ma non dovrebbe aver bisogno di capire l’offload dei tensori, i template di chat o la memoria KV.

llama.cpp è più facile da rendere esatto. Si sceglie la build, il backend, la versione, il file e i flag, il che è prezioso quando un nuovo kernel GPU corregge il proprio workload o quando un commit recente lo rompe. Quella libertà significa anche che si hanno a carico gli aggiornamenti, la supervisione del servizio e i test di regressione.

Gestione dei modelli: nomi della libreria o file comuni

Ollama tratta i modelli un po’ come le immagini dei container. Un nome familiare punta a un manifesto e a blob con indirizzamento per contenuto, e ollama pull risolve i layer richiesti. Questo è eccellente per configurazioni ripetibili delle workstation e per applicazioni che dovrebbero riferirsi a qwen3:8b piuttosto che a un lungo percorso del filesystem.

Un Modelfile rende la personalizzazione riproducibile:

FROM ./qwen3-8b-q4_k_m.gguf
PARAMETER num_ctx 32768
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM Sei un assistente tecnico preciso.

ollama create qwen3-8b-local -f Modelfile
ollama run qwen3-8b-local

Ollama può importare un GGUF locale, quindi scegliere Ollama non limita all’archivio pubblico di Ollama. Il passaggio di importazione, tuttavia, passa l’artefatto all’archivio modelli di Ollama. Se si conserva anche il GGUF originale per llama.cpp o LM Studio, bisogna tenere conto della copia gestita aggiuntiva, a meno che il layer di storage non dedupichi.

llama.cpp può semplicemente puntare al GGUF che si ha già. Può anche scaricare una quantizzazione selezionata da Hugging Face:

llama-server -hf ggml-org/Qwen3-8B-GGUF:Q4_K_M

Questo approccio orientato al file funziona particolarmente bene per testare nuove quantizzazioni. Scarica un file, cambia un percorso e avvialo; non c’è un passaggio di creazione e nessuna domanda su quale blob risolva un nome di modello.

I template fanno parte del modello, anche quando sembrano configurazione

I pesi non definiscono l’intero comportamento della chat. Il template di chat controlla come i messaggi di sistema, utente, assistente, thinking e tool diventano token. Le sequenze di stop e il comportamento del parser possono cambiare ulteriormente il risultato.

La libreria curata di Ollama riduce questo rischio perché i suoi modelli denominati trasportano metadati testati, e le release attuali (Ollama è passata da 0.30 a 0.33.3 tra giugno e settembre 2026) onorano sempre più direttamente i parametri predefiniti definiti in GGUF, anziché richiedere di riaffermarli in un Modelfile. Un GGUF importato a mano potrebbe ancora aver bisogno di un TEMPLATE, parser o renderer corretto, mentre llama.cpp legge normalmente il template di chat incorporato nel GGUF e permette di sovrascriverlo. Nessun runtime può riparare per magia metadati del modello errati o mancanti.

Se lo stesso modello quantizzato sembra sensibilmente peggio dopo un cambio di runtime, non concludere che un motore abbia danneggiato i pesi. Prima confronta il template, il limite del contesto, i valori di sampling, la modalità di thinking, il parser di tool e la revisione del runtime, una variabile alla volta, prima di toccare il modello stesso.

Ciclo di vita dei modelli e commutazione

Lo scheduler di Ollama è uno dei suoi motivi di esistenza più forti. Di default, un modello inattivo rimane caricato per cinque minuti; un valore keep_alive a livello di richiesta può mantenerlo residente indefinitamente, cambiare la durata o scaricarlo immediatamente. ollama ps mostra i modelli caricati, la collocazione dei processori, l’allocazione del contesto e la scadenza.

# Mantieni un modello caricato.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

# Scaricalo immediatamente.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": 0
}'

Un processo tradizionale llama-server --model ... carica un modello e lo mantiene finché il processo non termina. Questo comportamento è meravigliosamente prevedibile per un servizio dedicato: non c’è un caricamento a freddo inatteso dopo un timeout di inattività e nessun scheduler decide che un altro modello meriti la memoria.

llama.cpp ora ha anche una modalità router. Avviare llama-server senza un modello può esporre modelli cached, un directory GGUF o preset INI e caricare dinamicamente le istanze secondo il nome del modello richiesto. Chiude solo parzialmente il vecchio divario di ciclo di vita: solo un modello è residente per worker alla volta, una commutazione è un completo scaricamento e ricaricamento anziché istantaneo, e non c’è una politica di eviction o un warm pool — ogni richiesta alternata tra due modelli paga un ricaricamento completo. Questo restringe il divario rispetto all’assenza totale della modalità router, ma non rende i due prodotti identici; Ollama fornisce ancora un’esperienza di registro, warm-pool e amministrazione più fluida. Per la spiegazione completa della configurazione, le limitazioni attuali e un confronto onesto sia con Ollama che con llama-swap, vedi la guida alla modalità router di llama-server. Se serve un unico endpoint tra llama.cpp, vLLM, SGLang e altri motori, llama-swap è un’astrazione più appropriata che chiedere a uno dei due runtime di diventare un proxy universale dei modelli.

Controllo runtime: dove llama.cpp merita lo sforzo extra

Il vantaggio decisivo di llama.cpp non è che sia sempre più veloce. È che si può esprimere direttamente il piano di memoria ed esecuzione, ispezionarlo e cambiare una variabile alla volta.

Precisione di contesto e cache KV

Per llama.cpp diretto, la dimensione del contesto e i tipi di cache K/V possono essere impostati per ogni processo server:

llama-server \
  --model model.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 2 \
  --flash-attn on

K e V possono usare tipi diversi, e llama.cpp espone controlli aggiuntivi per l’allocazione KV unificata, limiti di contesto per slot, riuso della cache del prompt e persistenza della cache. Questi flag non sono decorativi su una GPU da 16 GB o 32 GB — determinano se le richieste con contesto lungo entrano e quanti slot possono restare utili, e il calcolo del budget di VRAM sottostante è lo stesso indipendentemente da quale runtime lo applichi; vedi KV Cache su GPU da 16 GB per la formula e le tabelle dei tipi di cache per motore.

Ollama espone il caso comune importante con OLLAMA_CONTEXT_LENGTH, l’opzione num_ctx e OLLAMA_KV_CACHE_TYPE. Il suo tipo di cache KV è però un’impostazione a livello di server, e non una scelta per modello denominato. Ollama scala anche la memoria con la parallelità configurata e la lunghezza del contesto, il che può far consumare molta più VRAM a un cambiamento di concorrenza che sembra innocuo.

Quel comportamento appartiene principalmente alla guida alle richieste parallele di Ollama. Per questo confronto, la decisione è più semplice: usa Ollama quando una politica di cache globale è accettabile; usa servizi llama.cpp separati quando modelli diversi hanno bisogno di precisione della cache, contesto o geometria degli slot diversi.

Selezione GPU e collocazione multi-GPU

Ollama mira a scegliere una collocazione sensata. Segnala se un modello è completamente sulla GPU, completamente sulla CPU o diviso, e il suo scheduler considera la memoria disponibile quando carica i modelli. Per una workstation normale con una sola GPU, la collocazione automatica è spesso esattamente ciò che si vuole.

llama.cpp espone il piano. Si possono selezionare i dispositivi, specificare i layer GPU, scegliere modalità di split tensoriale sperimentali a livello di layer, riga o tensore, impostare proporzioni dei tensori, selezionare la GPU principale e mantenere deliberatamente i pesi degli esperti MoE sulla CPU. Questo è sostanzialmente meglio per macchine multi-GPU asimmetriche e per spremere un modello troppo grande in un budget di memoria noto.

Se le note operative contengono frasi come “metti la cache KV su questi dispositivi” o “mantieni solo gli esperti nella RAM di sistema”, llama.cpp diretto è lo strumento naturale. Se il requisito è semplicemente “usa la GPU se entra”, Ollama fa risparmiare tempo senza cedere molto.

Nuove funzionalità e ritmo dei backend

llama.cpp diretto è dove appaiono per primi le nuove architetture di modello, i tipi di quantizzazione, i kernel GPU e le opzioni sperimentali del server. Questo è prezioso durante la settimana di rilascio di un modello, quando il supporto può dipendere da un numero di build specifico piuttosto che dall’ultimo pacchetto stabile.

Ollama fissa deliberatamente una revisione upstream e applica patch di compatibilità. Questo può ritardare una funzionalità upstream, ma può anche proteggere gli utenti dal turnover e integrarla con lo scheduler, i template e l’imballaggio multipiattaforma di Ollama. Un accesso più rapido non è la stessa cosa di una maggiore affidabilità.

Ollama 0.30 ha ridotto in modo significativo un divario precedente espandendo la compatibilità GGUF, migliorando le prestazioni NVIDIA e abilitando Vulkan di default per un supporto più ampio per AMD e Intel. Il ritmo delle release di Ollama da allora è rimasto rapido — 0.33.3 è uscito a inizio settembre 2026, circa tre mesi dopo, aggiungendo la segnalazione dei token del prompt cached e un altro aggiornamento del backend di llama.cpp — quindi tratta qualsiasi affermazione specifica sulla versione in questo articolo, o ovunque altro, come qualcosa da rivedere contro ollama --version piuttosto che come un fatto permanente. Qualsiasi confronto che dica che Ollama non può eseguire un GGUF locale arbitrario, o che Vulkan richiede sempre un’opzione sperimentale, è ora superata.

API, strumenti, visione e output strutturato

Entrambi i runtime sono server API locali credibili nel 2026. Entrambi possono gestire comuni richieste di chat in stile OpenAI, tool, modelli con capacità di visione, embed, streaming e output strutturato, quando il modello e il template li supportano.

La differenza è nella superficie circostante:

Non trattare “compatibile con OpenAI” come una certificazione binaria. Ollama dice di supportare parti dell’API OpenAI, mentre llama.cpp evita esplicitamente di fare una forte promessa di compatibilità. Prima di cambiare i runtime, testa i frame dello streaming, gli argomenti delle chiamate di tool, i campi di ragionamento, i contatori di utilizzo, i corpi degli errori e qualsiasi endpoint che il tuo client consuma effettivamente.

Ollama vince generalmente quando l’integrazione dell’applicazione è il lavoro. I suoi SDK e le integrazioni documentate rendono il percorso felice breve. llama.cpp vince quando il server stesso è l’oggetto dell’ingegneria: la sua vista degli slot, i tempi dei token, le metriche, gli schema, i template, gli adattatori e gli endpoint di basso livello sono insolutamente utili durante la diagnosi.

Prestazioni: benchmark del deployment, non del marchio

È tentante chiedere se llama.cpp o Ollama sia più veloce. Su un percorso GGUF, Ollama potrebbe eseguire sotto una versione fissa e modificata di llama.cpp, quindi una risposta universale a livello di marchio non è utile. I risultati cambiano con la revisione della build, il backend, il flash attention, l’allocazione del contesto, gli slot paralleli, le dimensioni del batch, il tipo di cache, la residenza del modello e se alcuni layer sono ricaduti sulla CPU.

Un confronto equo inizia con lo stesso GGUF e testa due domande diverse:

1. Avvio a freddo: includi il tempo di caricamento del modello e la latenza della prima risposta.
2. Servizio a caldo: precarica il modello, poi misura separatamente l’elaborazione del prompt e la generazione.

Usa prima una richiesta e uno slot. Allinea dimensione del contesto, tipo di cache K/V, temperatura, top-p, seed, output massimo e template di chat; conferma l’offload completo sulla GPU dai log o dall’output di stato. Solo allora aumenta la concorrenza, perché Ollama e llama.cpp allozano e schedulano il lavoro parallelo in modo diverso.

Per Ollama, la risposta finale dell’API nativa include i tempi di caricamento, valutazione del prompt e generazione, e le release attuali segnalano anche i token del prompt cached direttamente in quella risposta — utile per confermare se il riuso del prefisso è realmente successo prima di attribuire un vantaggio di velocità al runtime. Per llama.cpp, abilita la segnalazione delle prestazioni o le metriche Prometheus e ispeziona la configurazione di avvio. Un vantaggio di throughput del cinque percento è privo di significato se una esecuzione ha usato silenziosamente un contesto più corto, un tipo di cache diverso o un template diverso.

La mia aspettativa per lo stesso GGUF supportato su una GPU è generalmente la parità, non una vittoria garantita di llama.cpp. Il llama.cpp diretto può vincere dopo un tuning deliberato o adottando un’ottimizzazione più recente; Ollama può essere altrettanto veloce quando il suo motore selezionato e i predefiniti si allineano con il workload. Misura dopo la configurazione, non prima.

Modalità di errore che espongono la differenza reale

Il modello usa inaspettatamente la CPU

Con Ollama, esegui ollama ps e ispeziona PROCESSOR, CONTEXT e la dimensione caricata. Un contesto più grande, un altro modello residente o un percorso GPU non supportato possono spiegare lo split. Controlla i log del servizio invece di assumere che la GPU sia stata ignorata.

Con llama.cpp, inizia con llama-server --list-devices, poi leggi il log di avvio per la collocazione dei tensori e le dimensioni dei buffer. Se hai impostato un numero esatto di layer, un dispositivo o uno split, il comando stesso è evidenza della tua intenzione; questo è molto più facile da riprodurre in un report di bug.

Un contesto più lungo causa un errore di memoria esaurita

Ollama sceglie le lunghezze predefinite del contesto in base alla VRAM disponibile, e la documentazione attuale raccomanda almeno 64K per i carichi di lavoro di agenti e programmazione. Quella raccomandazione non è una promessa che il tuo modello, parallelità e cache entrino. Riduci num_ctx, riduci la parallelità, scegli una cache KV q8_0 dove appropriato, o usa una quantizzazione dei pesi più piccola. Conferma il quadro della memoria reale con nvidia-smi prima e dopo una richiesta lunga per sapere se il modello, la cache o entrambi sono il vincolo.

Con llama.cpp, riduci --ctx-size, cambia --cache-type-k e --cache-type-v, abbassa --parallel o regola l’offload. Poiché ogni scelta è esplicita, è più facile costruire profili separati per contesto lungo e alta concorrenza invece di forzare un unico compromesso su ogni modello.

L’API si connette, ma le risposte sono formattate male

Questo è spesso un problema di template o parser, specialmente con nuovi modelli di ragionamento e tool calling. Verifica che il GGUF contenga il template di chat atteso e che il runtime riconosca l’architettura. Confronta una richiesta di chat semplice prima di fare il debug del framework di agenti stratificato sopra di essa.

Su Ollama, ispeziona ollama show --modelfile <nome> e le capacità segnalate. Su llama.cpp, ispeziona i messaggi del template di avvio, usa --jinja e testa /v1/chat/completions direttamente. Fissa la versione del runtime che funziona prima di cambiare un’altra variabile.

Le richieste diventano lente dopo la commutazione dei modelli

Ollama potrebbe dover scaricare un modello e caricarne un altro, quindi separa il tempo di coda dal tempo di generazione. Pre-carica il modello importante con una richiesta vuota e imposta un valore keep_alive intenzionale invece di affidarsi al predefinito di cinque minuti.

Un processo llama.cpp dedicato evita la commutazione inaspettata perché il suo modello rimane residente. Se adottando la modalità router, il caricamento dei modelli diventa di nuovo dinamico — e ogni commutazione tra due modelli diversi è un completo scaricamento e ricaricamento senza warm pool — quindi monitora lo stato di caricamento e la latenza di avvio a freddo come faresti con Ollama.

La sicurezza non è un fattore di differenziazione a meno che tu non la configuri

Entrambi i server si legano a localhost di default, il che è il comportamento giusto per la workstation. Cambiare l’host in 0.0.0.0 trasforma un servizio di inferenza locale privato in un servizio di rete, e nessun prodotto dovrebbe essere esposto a Internet pubblico solo perché una regola del firewall lo ha accidentalmente permesso.

llama.cpp può applicare chiavi API e terminare TLS, sebbene un proxy inverso sia ancora utile per policy, limiti di frequenza e log. L’API locale di Ollama non richiede una chiave API; mettila dietro un proxy autenticato o un confine di rete privato se i client remoti hanno bisogno di accesso. Se hai bisogno di accesso remoto a Ollama, la [guida a Ollama dietro un proxy inverso](https://www.glukhov.org/it/llm-hosting/ollama/ollama-behind-reverse-proxy/ “Esponi Ollama in sicurezza dietro Caddy o Nginx con HTTPS automatizzato, gate frontali opzionali Basic Auth o SSO, e proxying corretto di streaming e WebSocket.”}) copre la configurazione di Caddy e Nginx con controlli di streaming e timeout. I modelli con capacità di tool aumentano la conseguenza di esporre l’applicazione circostante, anche quando il server di inferenza stesso non esegue i tool.

Quando mantenere Ollama

Mantieni Ollama quando la sua automazione rimuove più lavoro di quanto nasconde. È particolarmente forte per workstation condivise degli sviluppatori, applicazioni desktop locali, dimostrazioni, strumenti di programmazione e piccoli servizi che ruotano tra diversi modelli popolari.

Ollama è anche il predefinito migliore quando si vuole che i colleghi riproducano una configurazione denominata senza imparare i flag di llama.cpp. Un Modelfile, un tag del modello e due comandi sono un contratto operativo utile. La [scheda rapida di Ollama](https://www.glukhov.org/it/llm-hosting/ollama/ollama-cheatsheet/ “Scheda rapida CLI di Ollama: comando ollama serve, esempi di comando ollama run, ollama ps e gestione dei modelli.”}) copre quel flusso di lavoro quotidiano in maggior dettaglio.

Non migrare solo perché il llama.cpp diretto sembra più tecnico. Se il tuo modello entra, l’API si comporta correttamente, la latenza è stabile e non hai bisogno di un controllo mancante, sostituire Ollama crea manutenzione senza creare capacità.

Un avvertimento da tenere sotto osservazione nel tempo: la direzione del prodotto di Ollama stessa ha iniziato a spostarsi verso l’infrastruttura centralizzata. Ollama Turbo è un servizio di accelerazione cloud con accesso riservato agli utenti registrati, stratificato sopra uno strumento originariamente local-first e privacy-first, e non è l’unico cambiamento recente che scambia il controllo locale per uno strato di comodità ospitato. Se la ragione per cui hai scelto Ollama per la prima volta era evitare di inviare prompt ai server di qualcun altro, quel ragionamento merita una riconsiderazione periodica anziché una decisione una tantum — vedi [L’inquinamento di Ollama: i primi segni](https://www.glukhov.org/it/llm-hosting/ollama/ollama-enshittification/ “Panoramica dei primi segni di inquinamento di Ollama: monetizzazione cloud di Turbo, telemetria, comportamento di avvio automatico e regressioni delle prestazioni.”}) per i cambiamenti specifici e cosa osservare. Il llama.cpp diretto non ha un equivalente di upsell ospitato verso cui spostarsi, il che è di per sé un punto dati quando si pesano il controllo a lungo termine contro la comodità a breve termine.

Quando passare a llama-server

Passa al diretto llama-server quando una o più di queste affermazioni sono vere:

• Hai bisogno di una nuova funzionalità di llama.cpp o di una correzione del modello prima che raggiunga Ollama.
• Devi fissare un commit esatto di llama.cpp e una build del backend.
• Modelli diversi hanno bisogno di tipi di cache K e V o layout di slot diversi.
• Hai bisogno di una collocazione multi-GPU deliberata anziché di una selezione automatica.
• Stai testando la decodifica speculativa, MTP, scale LoRA, cache del prompt o sampler insoliti.
• Le metriche native, lo stato degli slot o gli interni del server sono necessari per la diagnosi.
• Vuoi che i file GGUF originali rimangano il catalogo dei modelli autorevole.
• Un modello dovrebbe rimanere residente per la durata di un processo supervisionato.

Il trigger di migrazione più pulito è l’ispezione ripetuta. Se ogni incidente inizia con scoprire cosa Ollama ha scelto prima di poter diagnosticare il modello, rendi quelle scelte esplicite in una definizione di servizio di llama.cpp.

Una migrazione a basso rischio da Ollama a llama.cpp

Non iniziare riproducendo ogni funzionalità di Ollama. Migra un modello e un client, conserva l’endpoint attuale finché il confronto non è completo e mantieni lo stesso GGUF se possibile.

1. Registra ollama --version, ollama show <model>, ollama show --modelfile <model> e ollama ps.
2. Individua o scarica il GGUF equivalente e qualsiasi proiettore multimodale.
3. Avvia un llama-server con un alias esplicito, contesto, offload GPU, tipi di cache e numero di slot.
4. Invia una richiesta di chat semplice, una richiesta di output strutturato e una chiamata di tool direttamente a ciascuna API.
5. Testa il client reale, incluso lo streaming e la gestione degli errori.
6. Confronta la latenza di caricamento a freddo, la velocità del prompt a caldo, la velocità di generazione, la VRAM e il formato della risposta.
7. Solo allora sostituisci l’URL del servizio o aggiungi un proxy davanti a entrambi i backend.

Per un semplice test di fumo in stile OpenAI:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3-8b",
    "messages": [
      {"role": "user", "content": "Rispondi esattamente: runtime-ok"}
    ],
    "temperature": 0,
    "max_tokens": 16
  }'

Poi verifica il servizio stesso:

# llama.cpp
llama-server --version
llama-server --list-devices
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/models

# Ollama
ollama --version
ollama ps
curl http://127.0.0.1:11434/api/ps
curl http://127.0.0.1:11434/v1/models

Se l’applicazione dipende dalla forma della risposta /api/chat nativa di Ollama, cambiare l’URL di base non basta. O migrare prima il client a una rotta compatibile con OpenAI o aggiungere un adattatore. La più ampia [guida alla migrazione da Ollama a vLLM](https://www.glukhov.org/it/llm-hosting/comparisons/ollama-to-vllm-migration/ “Impara quando migrare da Ollama a vLLM. Segnali di migrazione, passaggi di pianificazione, configurazione Docker Compose e un elenco pratico per spostare il tuo server LLM locale.”}) discute lo stesso principio contrattuale prima per un salto di runtime più grande.

Verdetto finale

Ollama è il migliore elettrodomestico per modelli locali. Fornisce un catalogo di modelli, ricette riproducibili, una collocazione automatica sensata, API comode e gestione del ciclo di vita senza chiedere a ogni utente di diventare un operatore di inferenza.

llama.cpp è il migliore strumento di precisione. llama-server espone abbastanza del piano di esecuzione da rendere comprensibili anziché misteriosi la VRAM vincolata, il contesto lungo, l’hardware insolito, il supporto per nuovi modelli e gli esperimenti controllati.

Per la maggior parte delle persone, la sequenza giusta non è Ollama o llama.cpp per sempre. Inizia con Ollama, impara quali vincoli contano realmente e sposta il workload interessato a llama.cpp diretto quando si può nominare il controllo di cui si ha bisogno. Questa è una ragione molto più forte che rincorrere un benchmark misurato sotto i predefiniti di qualcun altro.

Riferimenti

• Progetto llama.cpp e backend supportati
• Funzionalità, flag, endpoint e modalità router di llama-server
• FAQ di Ollama: contesto, keep-alive, concorrenza e cache KV
• Riferimento Modelfile di Ollama
• Importazione di modelli GGUF e Safetensors in Ollama
• Compatibilità API OpenAI di Ollama
• Cambiamenti GGUF, NVIDIA e Vulkan di Ollama 0.30
• Come Ollama fissa e modifica llama.cpp
• Supporto hardware di Ollama
• Lunghezze predefinite del contesto di Ollama
• Release di Ollama (GitHub)