Da Ollama a vLLM: quando migrare il proprio server LLM locale

Ollama è uno dei modi più semplici per eseguire un modello linguistico locale, ma la praticità può nascondere il momento in cui un esperimento locale diventa un servizio di inferenza condiviso che richiede una migliore pianificazione e osservabilità.

Qui entra in gioco vLLM. Migraare da Ollama a vLLM non è un aggiornamento automatico, tuttavia. È un compromesso: si scambia parte della semplicità di Ollama per un maggiore controllo su batching, gestione della memoria, concorrenza, inferenza distribuita e operazioni di produzione.

Questa guida copre i segnali pratici che indicano che la migrazione è giustificata, i rischi di un passaggio troppo precoce e un approccio graduale che mantiene entrambi i server in esecuzione affiancati durante la convalida. L’obiettivo è aiutarti a decidere basandoti su misurazioni e non su elenchi di funzionalità. Per il panorama più ampio delle opzioni locali, auto-ospitate e cloud oltre a questi due runtime, consulta Hosting LLM nel 2026: Infrastruttura Locale, Self-Hosted e Cloud a Confronto.

Ollama e vLLM Risolvono Problemi Diversi

Ollama è ottimizzato principalmente per il consumo comodo dei modelli. Offre agli sviluppatori un conciso interfaccia a riga di comando, un’API locale, una libreria di modelli, Modelfiles e un supporto straightforward per configurazioni comuni di desktop e workstation.

vLLM è un motore di inferenza e una piattaforma di servizio. Le sue preoccupazioni centrali sono la pianificazione delle ad alte prestazioni, l’efficiente gestione della KV cache, il batching continuo, il parallelismo del modello e la compatibilità con le applicazioni costruite per API in stile OpenAI.

La distinzione è importante perché i due server possono sembrare simili dall’esterno. Entrambi possono esporre un’API di chat, trasmettere token in streaming, eseguire modelli quantizzati e servire applicazioni locali. I loro modelli operativi diventano visibilmente diversi solo quando il server è sottoposto a un carico sostenuto o concorrente.

Un riepilogo utile:

La domanda non è quale server sia universalmente migliore. È se il tuo carico di lavoro corrisponda ancora al modello operativo che rende Ollama attraente. Se vuoi la visione più completa oltre a questi due runtime, il nostro confronto tra Ollama, vLLM, LocalAI, Jan, LM Studio e altri strumenti LLM locali copre il campo più ampio.

Segnali che Hai Superato le Capacità di Ollama

Una risposta lenta non giustifica di per sé una migrazione. La velocità di generazione è spesso limitata dalla dimensione del modello, quantizzazione, larghezza di banda della memoria, lunghezza del prompt o capacità GPU piuttosto che dal motore di servizio, e i segnali di migrazione più forti emergono solo quando la forma del carico di lavoro inizia a contare.

Multipli Utenti Causano Latenza Instabile

Un server LLM locale può sembrare veloce durante un test isolato e poi peggiorare nettamente quando più client si connettono. Le richieste iniziano ad attendere dietro generazioni lunghe, il tempo al primo token diventa inconsistente e un singolo prompt grande può influenzare tutti coloro che condividono il modello.

Ollama può elaborare richieste parallele, e OLLAMA_NUM_PARALLEL controlla quante richieste un modello caricato può gestire in parallelo — vedi come Ollama gestisce le richieste parallele per la meccanica di code e memoria dietro quella configurazione. Quel parallelismo non è gratuito: i requisiti di memoria crescono sia con il numero di richieste parallele configurato che con la lunghezza del contesto.

Questa è spesso la prima avvertenza pratica. Una configurazione che funziona per una conversazione da 8K può diventare impossibile quando quattro clienti riservano ciascuno un contesto molto più grande.

vLLM è progettato per combinare il lavoro delle richieste attive tramite batching continuo. Invece di trattare ogni richiesta come un lavoro di inferenza isolato, aggiorna continuamente il batch man mano che le sequenze arrivano, generano token e finiscono — un modello di pianificazione che generalmente diventa più prezioso all’aumentare della concorrenza.

Utilizzo GPU Basso mentre le Richieste Sono in Coda

Una coda non significa necessariamente che la GPU sia pienamente utilizzata. In un’arrangement di servizio semplice, il lavoro può essere serializzato anche se ulteriori richieste avrebbero potuto contribuire a un calcolo utile all’attuale passo di decodifica.

Il scheduler di vLLM è progettato per mantenere più lavoro utile in volo. PagedAttention gestisce la memoria della KV cache in blocchi, mentre il batching continuo consente alle sequenze attive di entrare e uscire dinamicamente dal batch di esecuzione.

Il risultato non è garantito una latenza inferiore per ogni singola richiesta. Tuttavia, sotto carico, può produrre un throughput aggregato sostanzialmente migliore e un utilizzo delle risorse più prevedibile.

Prompt Lunghi Dominano il Tempo al Primo Token

Assistenti di coding a lungo contesto, pipeline RAG e sessioni di agenti possono inviare ripetutamente grandi system prompt o prefissi di documenti condivisi. L’elaborazione di quei token di input è la fase di prefill, e può dominare il tempo al primo token.

vLLM supporta chunked prefill e caching automatico dei prefissi. Il caching dei prefissi consente alle richieste successive di riutilizzare i blocchi della KV cache quando la loro sequenza iniziale di token corrisponde a un prefisso già elaborato.

Questo è particolarmente utile quando le richieste condividono:

• Un lungo system prompt
• Le stesse definizioni di tool
• Un riepilogo stabile del repository
• Esempi few-shot ripetuti
• Un prefisso comune di documento RAG
• Una cronologia di conversazione condivisa

Il caching dei prefissi non rende la generazione dell’output più veloce. Riduce il calcolo ripetuto del prompt, quindi il suo beneficio dipende da se le richieste contengono effettivamente prefissi riutilizzabili identici.

Hai Bisogno di Più di una GPU

Un modello che non si adatta su una singola GPU è una ragione forte per considerare vLLM. Supporta il parallelismo tensoriale tra GPU e il parallelismo pipeline tra più nodi o dispositivi.

Questo non rende l’inferenza multi-GPU senza sforzi. Larghezza di banda dell’interconnessione GPU, topologia PCIe, architettura del modello, memoria condivisa del container e sovraccarico di comunicazione influenzano ancora le prestazioni.

Tuttavia, vLLM fornisce un percorso deliberato per l’inferenza distribuita. Ollama è solitamente una scelta migliore per un singolo desktop o workstation dove il modello scelto si adatta già comodamente.

Hai Bisogno di Osservabilità di Livello Produzione

Le risposte dell’API di Ollama espongono utili campi di timing come durata del caricamento del modello, durata della valutazione del prompt, conteggio dei token generati e durata della generazione. Questi valori sono sufficienti per benchmarking locale e logging a livello applicativo.

vLLM espone metriche compatibili con Prometheus tramite il suo endpoint /metrics. Questo rende più facile tracciare volume delle richieste, code, tempo al primo token, latenza tra token, utilizzo della cache, preemption, throughput e risultati delle richieste nel tempo.

Una volta che gli utenti dipendono dal servizio, l’osservabilità smette di essere opzionale. Senza metriche di coda, cache e latenza, è difficile distinguere una GPU dimensionata insufficiente da un limite di contesto eccessivo, una pianificazione scadente, il caricamento freddo del modello o semplicemente troppe richieste simultanee.

Dove vLLM Vince Veramente

Il vantaggio più importante di vLLM non è che possa produrre una risposta più veloce di Ollama su ogni macchina. Il vantaggio significativo è che dà all’operatore più meccanismi per utilizzare in modo efficiente la memoria e il calcolo costosi degli acceleratori su molte richieste.

Batching Continuo

Il batching statico tradizionale funziona meglio quando le richieste hanno lunghezze di input e output simili. Il traffico LLM interattivo raramente si comporta così: un utente chiede una breve classificazione, un altro invia un prompt da 20K token e un terzo genera migliaia di token di codice.

Il batching continuo modifica il batch attivo man mano che le richieste progressano. Le sequenze completate lasciano, nuove sequenze entrano e il motore cerca di evitare di sprecare la capacità del batch su richieste che hanno già finito.

Questo migliora il throughput quando il traffico è concorrente e disuguale. Offre poco beneficio quando un singolo utente invia una richiesta alla volta.

Gestione della Cache KV Paged

Durante la generazione, il server memorizza le chiavi e i valori di attenzione per i token precedentemente elaborati. Questa KV cache può consumare una grande quantità di memoria GPU, specialmente con contesti lunghi e più sequenze attive.

vLLM gestisce questa cache in blocchi invece di richiedere che ogni sequenza riservi un’unica allocazione contigua grande. L’approccio riduce la frammentazione della memoria e consente di utilizzare la capacità di cache disponibile in modo più flessibile.

Il valore pratico è una concorrenza più alta entro lo stesso budget di memoria. Non elimina il costo sottostante del contesto lungo, ma riduce gli sprechi evitabili attorno a quel costo. Per l’aritmetica dietro quel costo sottostante — quanti byte una data lunghezza di contesto richiede effettivamente e come la precisione della cache (FP8, Q8_0, Q4_0) si bilancia su una scheda da 16 GB — vedi KV Cache su GPU da 16 GB.

Caching dei Prefissi

Molte richieste di produzione condividono un’inizio sostanziale. Gli agenti abilitati a tool possono inviare schemi di funzione identici, i bot di supporto possono usare gli stessi documenti di policy e gli assistenti di coding possono includere ripetutamente le stesse istruzioni del repository.

Il caching automatico dei prefissi può riutilizzare la cache calcolata per i prefissi corrispondenti. È particolarmente utile quando un prefisso stabile e grande è seguito da un suffisso relativamente piccolo specifico della richiesta.

È meno utile quando template, timestamp, ordine dei documenti o metadati generati dinamicamente cambiano vicino all’inizio di ogni prompt. Piccole differenze nella tokenizzazione possono impedire la corrispondenza del prefisso.

Inferenza Parallela e Distribuita

vLLM supporta diverse forme di parallelismo, inclusi parallelismo tensoriale, pipeline, dati, esperto e di contesto. Non ogni deployment richiede queste modalità, ma la loro disponibilità conta quando un servizio cresce oltre una singola GPU.

Per una workstation con due GPU adatte, il parallelismo tensoriale può consentire a un modello più grande di funzionare su entrambi i dispositivi. Per un servizio replicato, il parallelismo dati può creare più repliche del motore per throughput aggiuntivo.

Queste funzionalità introducono complessità operativa. Dovrebbero essere adottate perché le misurazioni dimostrano un problema di capacità, non perché l’inferenza distribuita sembra più sofisticata.

Controlli di Produzione più Ampii

vLLM espone controlli per utilizzo della memoria GPU, lunghezza massima del modello, sequenze attive massime, quantizzazione, tipi di dati della cache, decodifica speculativa, tool calling, output strutturato, alias dei modelli, chiavi di autenticazione ed esecuzione distribuita.

Quella flessibilità rende il server più facile da tarare per un particolare carico di lavoro, ma crea anche più opportunità per una configurazione invalida o inefficiente. Migrare a vLLM significa assumere la responsabilità per quelle decisioni.

Dove Ollama Vince Ancora

Una guida alla migrazione non dovrebbe trattare Ollama come uno strumento preliminare inferiore. Per molti deployment locali, rimane il server migliore.

Workstation Personali

Per uno sviluppatore che usa un’interfaccia di chat, un assistente di codice o una API locale occasionale, i vantaggi operativi di vLLM potrebbero mai compensare il suo setup aggiuntivo.

Ollama si installa rapidamente, scarica i modelli tramite un semplice registro e nasconde molti dettagli specifici del modello. È ben adatto alla sperimentazione e all’uso desktop privato.

Collezioni di Modelli GGUF

Ollama ha un workflow naturale attorno ai modelli GGUF e ai Modelfiles. Gli utenti esistenti potrebbero avere quantizzazioni, adapter, template, system prompt e parametri curati che funzionano affidabilmente con il loro hardware.

vLLM supporta GGUF, ma il suo percorso più forte è generalmente attraverso repository di modelli Hugging Face supportati e formati di quantizzazione come AWQ, GPTQ, BitsAndBytes, FP8 o formati specifici del vendor. Spostare un deployment GGUF esistente su vLLM senza valutare un formato di checkpoint più nativo può preservare l’inconveniente della migrazione mancando alcuni dei vantaggi prestazionali.

Offloading Misto CPU e GPU

L’inferenza desktop a volte si basa su un offloading parziale sulla GPU perché l’intero modello non si adatta nella VRAM. Questo può essere pratico per un uso occasionale, specialmente quando la latenza non è critica.

vLLM è generalmente più convincente quando il modello e la capacità di KV cache richiesta possono essere serviti efficacemente dalla configurazione di acceleratore disponibile. Un carico di lavoro che dipende fortemente dalla RAM di sistema e dall’offloading CPU potrebbe essere più adatto a Ollama o llama.cpp.

Cambio Rapido di Modelli

Ollama rende facile scaricare, eseguire, fermare e passare tra molti modelli locali. Questo è utile per valutazione, scrittura, coding, embedding, visione e sperimentazione ad hoc.

Un deployment vLLM è più comunemente costruito attorno a un modello selezionato deliberatamente che rimane caricato come servizio. Il deployment multi-modello è possibile, ma richiede una pianificazione delle risorse più esplicita.

Amministrazione Minima

Ollama è intenzionalmente opinato. Questo può essere un limite sotto carico, ma è un vantaggio quando nessuno vuole mantenere una piattaforma di inferenza, e se il server locale ha un utente, una latenza accettabile e nessuna coda significativa, la migrazione è probabile che crei lavoro piuttosto che rimuoverlo.

Non Migrare Basandoti Solo sui Token per Secondo

La velocità di generazione dei token per singola richiesta è un benchmark incompleto. Due server possono produrre un throughput di decodifica simile per una sequenza mentre si comportano molto diversamente con otto client concorrenti.

Una valutazione utile dovrebbe misurare almeno:

• Tempo al primo token
• Latenza tra token
• Latenza della richiesta end-to-end
• Throughput di elaborazione del prompt
• Throughput dei token di output
• Richieste completate al minuto
• Tempo di attesa in coda
• Consumo di memoria GPU
• Utilizzo GPU
• Tasso di fallimento e timeout

Esegui la stessa famiglia di modelli, precisione, lunghezza del contesto, set di prompt, limite di output e livello di concorrenza su entrambi i server. Altrimenti, il test è più probabile che confronti il packaging del modello e la configurazione piuttosto che i motori di servizio.

Il confronto più utile è un piccolo load test che rappresenta il tuo traffico reale. Per un assistente di coding condiviso, questo potrebbe includere lunghi system prompt, prefissi ripetuti, risposte in streaming e due a otto sessioni simultanee.

Pianifica Prima la Migrazione del Modello

I nomi dei modelli Ollama non mappano automaticamente a identificatori di modello vLLM equivalenti. Un pacchetto Ollama può contenere una specifica quantizzazione GGUF, un template di prompt, una configurazione dei token di stop e parametri predefiniti.

Prima di cambiare il server, identifica:

1. La famiglia e la versione del modello originale
2. Se è un modello base o instruction-tuned
3. La quantizzazione attuale e la precisione effettiva
4. Il template di prompt o chat
5. La lunghezza del contesto configurata
6. Token di stop e default di generazione
7. Requisiti di tool-calling o output strutturato
8. Adattatori LoRA o system prompt personalizzati

Poi scegli un checkpoint supportato da vLLM che corrisponda al comportamento intended. Non dare per scontato che un checkpoint AWQ o FP8 si comporterà identicamente alla build GGUF usata previously in Ollama — la migrazione del modello è spesso più significativa della migrazione dell’API.

Controlla la VRAM Prima di Avviare vLLM

Un modello che si adatta nella memoria GPU non significa che possa servire il carico di lavoro richiesto. La VRAM deve coprire più dei pesi del modello.

Il budget di memoria pratico include:

pesi del modello
+ KV cache
+ grafici CUDA e allocazioni runtime
+ workspace temporaneo
+ cache dei processori multimodali, se usato
+ margine di sicurezza

I contesti lunghi e le sequenze concorrenti espandono principalmente il requisito di KV cache. Aumentare la lunghezza massima del contesto riduce quindi il numero di richieste simultanee che possono adattarsi, anche se la maggior parte delle richieste non usa mai il limite pieno.

Inizia con un --max-model-len realistico piuttosto che con il valore massimo pubblicizzato dal modello, e evita di impostare l’utilizzo della memoria GPU così aggressivamente che una minore variazione del carico causi fallimenti out-of-memory. Un servizio stabile con una capacità teorica leggermente inferiore è più utile di uno che fallisce al suo primo picco di traffico.

Un Deployment Minimale di vLLM con Docker Compose

Il seguente esempio avvia un server vLLM compatibile con OpenAI sulla porta 8000:

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    restart: unless-stopped
    ports:
      - "8000:8000"
    ipc: host
    gpus: all
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    environment:
      HF_TOKEN: ${HF_TOKEN:-}
    command:
      - --model
      - Qwen/Qwen3-8B
      - --served-model-name
      - local-model
      - --max-model-len
      - "16384"
      - --gpu-memory-utilization
      - "0.90"
      - --api-key
      - ${VLLM_API_KEY:-change-me}

Crea un file di ambiente:

cat > .env <<'EOF'
HF_TOKEN=
VLLM_API_KEY=replace-with-a-long-random-value
EOF

Avvia il server:

docker compose up -d

Controlla i log:

docker compose logs -f vllm

Testa l’endpoint dei modelli:

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer replace-with-a-long-random-value"

Invia una richiesta di chat:

curl http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer replace-with-a-long-random-value" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-model",
    "messages": [
      {
        "role": "user",
        "content": "Explain continuous batching in two paragraphs."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300,
    "stream": false
  }'

Per un deployment mantenuto, fissa l’immagine a una release vLLM testata invece di lasciarla su latest. Rivedi le note di rilascio prima di aggiornare perché opzioni a riga di comando, implementazioni di modelli, metriche e comportamento del motore possono evolvere. Questo file Compose è intenzionalmente minimale; per la guida di setup più completa — compatibilità API OpenAI, tuning di PagedAttention e un confronto più approfondito vLLM-vs-Ollama — consulta la vLLM Quickstart.

La Compatibilità con l’API OpenAI Non è Interscambiabilità Completa

Sia Ollama che vLLM forniscono endpoint compatibili con OpenAI, il che può rendere la migrazione dell’applicativamente relativamente piccola. In molti client, cambiare l’URL base, la chiave API e il nome del modello è sufficiente per stabilire una connessione.

Ad esempio:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="replace-with-a-long-random-value",
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
        {
            "role": "user",
            "content": "What should I monitor on an LLM server?",
        }
    ],
    temperature=0.2,
)

print(response.choices[0].message.content)

La compatibilità dovrebbe comunque essere testata a livello di funzionalità. Esamina:

• Comportamento degli eventi di streaming
• Parametri di richiesta supportati
• Selezione del template di chat
• Parsing dei tool-call
• Gestione dell’output di ragionamento
• Output vincolato da JSON o schema
• Endpoint di embedding
• Input multimodali
• Reporting dell’utilizzo dei token
• Formati di risposta di errore
• Scoperta del nome del modello
• Applicazione della lunghezza del contesto

Un client che invia solo chat completioni ordinarie sarà generalmente più facile da migrare di un framework di agenti che dipende da un particolare parser di tool-call o da un’estensione non standard.

I Template di Chat sono un Fallimento Comune della Migrazione

I modelli instruction-tuned si aspettano che le conversazioni siano serializzate usando un template di chat specifico. Il template inserisce marcatori di ruolo, separatori, token di controllo e prompt di generazione nel formato usato durante l’addestramento.

Ollama pacchettizza gran parte di questo comportamento dentro la sua definizione di modello. Con vLLM, il template viene normalmente ottenuto dalla configurazione del tokenizer del modello, anche se un operatore può fornirlo esplicitamente.

Un server può avviarsi con successo anche quando il template selezionato è sbagliato. I sintomi appaiono nel comportamento del modello:

• Il modello ripete etichette di ruolo
• Le risposte contengono token speciali
• Le istruzioni di sistema sono ignorate
• I tool call sono malformati
• Il modello continua il messaggio dell’utente
• La qualità dell’output è molto peggiore del previsto

Prima di incolpare il motore di inferenza, confronta il prompt completamente reso usato da ogni deployment.

Usa una Migrazione Graduale

Sostituire un server locale funzionante in un solo passo crea rischi inutili. Ollama e vLLM possono funzionare affiancati su porte diverse mentre convalidi il nuovo deployment.

Fase 1: Riproduci un Modello

Scegli il modello responsabile della maggior parte del traffico API e abbina il suo instruction tuning, requisito di contesto, parametri di generazione e comportamento di chat il più strettamente possibile. Non iniziare spostando ogni modello sperimentale.

Fase 2: Convalida il Comportamento dell’API

Esegui i test di integrazione esistenti contro l’endpoint vLLM, inclusi streaming, cancellazione, timeout, tool call, richieste malformate, overflow di contesto e accesso concorrente. Registra le differenze comportamentali piuttosto che nasconderle dietro retry del client.

Fase 3: Stabilisci una Baseline

Misura prima le prestazioni di una singola richiesta. Questo conferma che il modello è caricato correttamente e fornisce un riferimento per test successivi.

Registra token di prompt al secondo, token di output al secondo, tempo al primo token, latenza totale e utilizzo della memoria GPU.

Fase 4: Aggiungi Concorrenza Realistica

Testa il numero di richieste simultanee attese in normale operazione e durante un picco plausibile, usando lunghezze rappresentative di prompt e output piuttosto che richieste sintetiche identiche. Osserva code, uso della cache, preemption, tempo al primo token e latenza di coda.

Fase 5: Sposta un Client

Inoltra un’applicazione non critica o una piccola percentuale di traffico a vLLM. Mantieni Ollama disponibile come fallback finché il nuovo server non ha operato affidabilmente sotto uso reale.

Fase 6: Tuna da Misurazioni

Regola lunghezza del modello, utilizzo della memoria, sequenze attive massime, caching dei prefissi, parallelismo e quantizzazione solo dopo aver identificato un vincolo misurato. Cambiare diversi parametri alla volta rende difficile spiegare le regressioni prestazionali.

Un Elenco di Controllo Pratico per la Migrazione

Prima di spostare i client, verifica quanto segue:

[ ] Il modello di destinazione è supportato da vLLM
[ ] Il checkpoint e la quantizzazione selezionati si adattano nella VRAM
[ ] Resta abbastanza VRAM per la KV cache richiesta
[ ] La lunghezza massima del contesto riflette l'uso reale
[ ] Il template di chat corretto è disponibile
[ ] I token di stop e i default di generazione sono testati
[ ] Lo streaming funziona con i client esistenti
[ ] I tool call e l'output strutturato sono convalidati
[ ] L'alias pubblico del modello rimane stabile
[ ] L'autenticazione è abilitata
[ ] Il server non è esposto direttamente a internet
[ ] Le metriche Prometheus sono raccolte
[ ] Le metriche GPU sono raccolte separatamente
[ ] I load test includono concorrenza realistica
[ ] Timeout e cancellazioni sono gestiti
[ ] Esiste un percorso di rollback verso Ollama

Questo elenco è intenzionalmente operativo. Installare vLLM è generalmente più facile che dimostrare che si comporta correttamente per un’applicazione esistente.

Sicurezza ed Esposizione di Rete

Né un endpoint Ollama locale né un endpoint vLLM dovrebbero essere casualmente esposti a internet pubblico. Un server di inferenza non autenticato può consumare capacità GPU costosa, rivelare il comportamento del modello e diventare una via per attacchi denial-of-service attraverso prompt o output molto lunghi.

vLLM può richiedere una chiave API per i suoi endpoint compatibili con OpenAI, ma una chiave API non è un confine di sicurezza completo. Per l’accesso condiviso o remoto, posizionare il servizio dietro un reverse proxy o un API gateway che fornisca TLS, restrizioni di rete, limiti di dimensione delle richieste, limiti di tasso, logging di accesso e autenticazione appropriata — lo stesso modello coperto in Ollama dietro un reverse proxy con Caddy o Nginx si applica altrettanto bene davanti a vLLM.

Considera anche i rischi specifici del modello. Il caricamento di URL multimodali, codice di modello personalizzato, file remoti ed esecuzione di tool senza restrizioni possono espandere la superficie di attacco oltre la generazione di testo ordinaria.

Quando Non Migrare

Restare con Ollama quando:

• Uno o due utenti accedono al server
• Le richieste sono prevalentemente sequenziali
• Il modello offre già una latenza accettabile
• La gestione facile di GGUF è importante
• È richiesto offloading CPU o GPU parziale
• I modelli cambiano frequentemente
• Nessuno vuole operare infrastruttura aggiuntiva
• Non c’è un problema misurato di concorrenza o throughput

Un passaggio a vLLM dovrebbe risolvere un limite concreto. “Produzione” non è una soglia magica che invalida Ollama, specialmente per un servizio interno con traffico modesto.

Al contrario, non mantenere Ollama solo perché era più facile da installare. Se gli utenti aspettano regolarmente in una coda, i prefissi ripetuti consumano tempo significativo di prefill o un modello più grande deve essere distribuito su GPU, il server più semplice potrebbe essere diventato la scelta più costosa operativamente.

Mantieni Ollama per lo Sviluppo e Aggiungi vLLM per il Servizio Condiviso

L’architettura più pratica spesso non è una sostituzione completa. Gli sviluppatori possono mantenere [Ollama in esecuzione in Docker Compose](https://www.glukhov.org/it/llm-hosting/ollama/ollama-in-docker-compose/ “Esegui Ollama in Docker Compose”}) sulle loro workstation per esplorazione dei modelli, test di GGUF e uso interattivo privato mentre un’istanza vLLM condivisa serve un modello stabile ad applicazioni e team. Quella separazione conta anche per [sovranità AI](https://www.glukhov.org/it/llm-hosting/self-hosting/llm-selfhosting-and-ai-sovereignty/ “Self-hosting LLM per la sovranità AI”}) — mantenere entrambi i runtime self-hosted significa che prompt, pesi e log di inferenza restano sotto il tuo controllo indipendentemente da quale server gestisca una data richiesta.

Questo separa due flussi di lavoro diversi:

Ollama:
sperimentazione -> cambio modello -> strumenti personali -> chat locale

vLLM:
modello selezionato -> endpoint condiviso -> traffico concorrente -> monitoraggio

L’arrangement riduce anche il rischio di migrazione. I modelli possono essere testati localmente prima che un checkpoint adatto sia promosso al deployment vLLM condiviso.

Flusso di Decisione per la Migrazione

Il seguente diagramma riassume i punti chiave di decisione:

Conclusione

Ollama è difficile da battere come esecutore di modelli locali. Rimuove abbastanza lavoro di packaging e configurazione che gli sviluppatori possono concentrarsi sul modello e sull’applicazione piuttosto che sullo stack di inferenza.

vLLM diventa la scelta più forte quando il server stesso è il problema da ingegnerizzare. Traffico concorrente, code, lunghi prefissi ripetuti, modelli multi-GPU, pianificazione della capacità e osservabilità di produzione sono i segnali di migrazione che contano.

Non migrare perché vLLM ha un elenco di funzionalità più lungo. Migra quando le misurazioni mostrano che il modello operativo più semplice di Ollama non corrisponde più al carico di lavoro. Fino a quel punto, la semplicità non è una debolezza tecnica; è un’ottimizzazione.