Ollama a vLLM: quando migrare il proprio server LLM locale

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

È qui che vLLM diventa rilevante. Migrare da Ollama a vLLM non è però un aggiornamento automatico. È uno scambio: si rinuncia a parte della semplicità di Ollama in cambio di un maggiore controllo su batching, gestione della memoria, concorrenza, inferenza distribuita e operazioni di produzione.

Questa guida copre i segnali pratici che indicano quando la migrazione è giustificata, i rischi di un passaggio troppo precoce e un approccio graduale che mantiene entrambi i server attivi fianco a fianco durante la validazione. L’obiettivo è aiutarti a decidere sulla base di misurazioni anziché di elenchi di funzionalità. Per una visione più ampia delle opzioni locali, self-hosted e cloud oltre a questi due runtime, consulta Hosting LLM nel 2026: Infrastrutture Locali, Self-Hosted e Cloud a Confronto.

Ollama e vLLM Risolvono Problemi Diversi

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

vLLM è un motore di inferenza e una piattaforma di serving. Le sue preoccupazioni centrali sono la pianificazione delle adatte ad alto throughput, la gestione efficiente della cache KV, il batching continuo, il parallelismo dei modelli e la compatibilità con applicazioni costruite per API in stile OpenAI.

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

Un utile riepilogo:

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 una visione completa che vada oltre questi due runtime, il nostro confronto tra Ollama, vLLM, LocalAI, Jan, LM Studio e altri strumenti LLM locali copre il panorama più ampio.

Segnali che Hai Supersato Ollama

Una risposta lenta non giustifica da sola una migrazione. La velocità di generazione è spesso vincolata dalla dimensione del modello, dalla quantizzazione, dalla banda di memoria, dalla lunghezza del prompt o dalla capacità della GPU, piuttosto che dal motore di serving, e i segnali di migrazione più forti emergono solo quando la forma stessa 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 degradare bruscamente quando più client si collegano. Le richieste iniziano ad attendere dietro generazioni lunghe, il tempo al primo token diventa incoerente 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 possa gestire contemporaneamente — consulta come Ollama gestisce le richieste parallele per la meccanica di code e memoria dietro tale impostazione. Tale parallelismo non è gratuito: i requisiti di memoria crescono sia con il numero di richieste parallele configurato sia con la lunghezza del contesto.

Questo è spesso il primo avvertimento pratico. Una configurazione che funziona per una conversazione da 8K potrebbe diventare impossibile quando quattro client riservano ciascuno un contesto molto più grande.

vLLM è progettato per combinare il lavoro da 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 terminano — un modello di pianificazione che generalmente diventa più prezioso man mano che la concorrenza aumenta.

Utilizzo GPU Basso Durante l’Attesa in Coda

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

Il pianificatore di vLLM è progettato per mantenere più lavoro utile in corso. PagedAttention gestisce la memoria della cache KV a blocchi, mentre il batching continuo permette alle sequenze attive di entrare ed uscire dal batch di esecuzione dinamicamente.

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

Prompt Lunghi Dominano il Tempo al Primo Token

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

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

Questo è particolarmente utile quando le richieste condividono:

• Un lungo prompt di sistema
• Le stesse definizioni di strumenti
• Un riassunto stabile del repository
• Esempi few-shot ripetuti
• Un prefisso comune di documenti RAG
• Una cronologia di conversazione condivisa

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

Ti Serve Più di una GPU

Un modello che non si adatta su una sola GPU è una forte ragione 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 indolore. La banda di interconnessione GPU, la topologia PCIe, l’architettura del modello, la memoria condivisa dei container e l’overhead di comunicazione influenzano ancora le prestazioni.

Tuttavia, vLLM offre 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.

Ti Serve Osservabilità di Livello Produzione

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

vLLM espone metriche compatibili con Prometheus attraverso il suo endpoint /metrics. Questo rende più facile monitorare volume delle richieste, code, tempo al primo token, latenza inter-token, utilizzo della cache, preemption, throughput ed esito delle richieste nel tempo.

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

Dove vLLM Vince Davvero

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 di accelerazione e la potenza di calcolo costosa tra 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 diverse migliaia di token di codice.

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

Questo migliora il throughput quando il traffico è concorrente e disomogeneo. 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 cache KV può consumare una grande quantità di memoria GPU, specialmente con contesti lunghi e più sequenze attive.

vLLM gestisce questa cache a blocchi anziché richiedere che ogni sequenza riservi un’unica allocazione continua larga. L’approccio riduce la frammentazione della memoria e permette alla capacità della cache disponibile di essere utilizzata in modo più flessibile.

Il valore pratico è una maggiore concorrenza all’interno dello stesso budget di memoria. Non rimuove il costo sottostante del contesto lungo, ma riduce lo spreco evitabile intorno a quel costo. Per l’aritmetica dietro quel costo sottostante — quanti byte ha effettivamente bisogno una data lunghezza di contesto e come la precisione della cache (FP8, Q8_0, Q4_0) si confronta con essa su una scheda da 16 GB — consulta KV Cache su GPU da 16 GB.

Caching dei Prefissi

Molte richieste di produzione condividono un inizio sostanziale. Gli agenti abilitati a strumenti possono inviare schemi di funzione identici, i bot di supporto possono usare gli stessi documenti di policy e gli assistenti di codifica 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 specifico della richiesta relativamente piccolo.

È 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 al prefisso di corrispondere.

Inferenza Parallela e Distribuita

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

Per una workstation con due GPU adatte, il parallelismo tensoriale può consentire a un modello più grande di essere eseguito 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. Devono essere adottate perché le misurazioni dimostrano un problema di capacità, non perché l’inferenza distribuita appare più sofisticata.

Controlli di Produzione Più Ampii

vLLM espone controlli per l’utilizzo della memoria GPU, la lunghezza massima del modello, le sequenze attive massime, la quantizzazione, i tipi di dati della cache, decodifica speculativa, chiamata a strumenti, output strutturato, alias dei modelli, chiavi di autenticazione ed esecuzione distribuita.

Tale flessibilità rende il server più facile da tarare per un carico di lavoro particolare, ma crea anche più opportunità per una configurazione non valida o inefficiente. Migrare a vLLM significa assumersi la responsabilità di queste 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 un’API locale occasionale, i vantaggi operativi di vLLM potrebbero non compensare mai la sua configurazione aggiuntiva.

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

Collezioni di Modelli GGUF

Ollama ha un workflow naturale intorno ai modelli GGUF e ai Modelfiles. Gli utenti esistenti potrebbero avere quantizzazioni curate, adattatori, template, prompt di sistema e parametri che funzionano affidabilmente con il loro hardware.

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

Offloading Misto CPU e GPU

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

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

Cambio Rapido dei Modelli

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

Un deployment vLLM viene 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 opinionato. 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 creerà probabilmente lavoro anziché rimuoverlo.

Non Migrare Solo in Base ai Token per Secondo

La velocità di generazione dei token per singola richiesta è un benchmark incompleto. Due server potrebbero produrre un throughput di decodifica simile per una sequenza comportandosi in modo molto diverso con otto client concorrenti.

Una valutazione utile dovrebbe misurare almeno:

• Tempo al primo token
• Latenza inter-token
• Latenza end-to-end della richiesta
• Throughput di elaborazione del prompt
• Throughput di token di output
• Richieste completate al minuto
• Tempo di attesa in coda
• Consumo di memoria GPU
• Utilizzo GPU
• Tasso di fallimenti 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 e la configurazione del modello che i motori di serving.

Il confronto più utile è un piccolo test di carico che rappresenta il tuo traffico reale. Per un assistente di codifica condiviso, questo potrebbe includere prompt di sistema lunghi, 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 su identificatori di modelli vLLM equivalenti. Un pacchetto Ollama potrebbe contenere una particolare quantizzazione GGUF, un template di prompt, una configurazione di stop-token e parametri predefiniti.

Prima di cambiare il server, identifica:

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

Poi scegli un checkpoint supportato da vLLM che corrisponda al comportamento previsto. Non dare per scontato che un checkpoint AWQ o FP8 si comporterà identicamente al build GGUF precedentemente usato in Ollama — la migrazione del modello è spesso più significativa che la 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
+ cache KV
+ grafici CUDA e allocazioni runtime
+ workspace temporaneo
+ cache del processore multimodale, se usato
+ margine di sicurezza

I contesti lunghi e le sequenze concorrenti espandono principalmente il requisito della cache KV. 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 completo.

Inizia con un --max-model-len realistico anziché il valore più grande pubblicizzato dal modello ed evita di impostare l’utilizzo della memoria GPU in modo così aggressivo 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 Docker Compose Minimo per vLLM

L’esempio seguente 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é le opzioni da riga di comando, le implementazioni dei modelli, le metriche e il comportamento del motore possono evolversi. Questo file Compose è intenzionalmente minimo; per la guida di configurazione più completa — compatibilità API OpenAI, tuning PagedAttention e un confronto più approfondito tra vLLM e Ollama — consulta il Quickstart vLLM.

La Compatibilità API OpenAI Non È Interchangeabilità Completa

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

Per 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 delle chiamate a strumenti
• Gestione dell’output di ragionamento
• Output vincolato a JSON o schema
• Endpoint di embedding
• Input multimodali
• Report di utilizzo dei token
• Formati di risposta agli errori
• 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 parser di tool-call particolare o da un’estensione non standard.

I Template di Chat Sono un Fallimento Comune nella Migrazione

I modelli instruction-tuned si aspettano che le conversazioni vengano 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 confeziona gran parte di questo comportamento all’interno della sua definizione del modello. Con vLLM, il template viene normalmente ottenuto dalla configurazione del tokenizer del modello, anche se un operatore può fornirlo esplicitamente.

Un server potrebbe 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
• Le chiamate a strumenti sono malformate
• 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 renderizzato usato da ciascun deployment.

Usa una Migrazione Graduale

Sostituire un server locale funzionante in un solo passo crea un rischio non necessario. Ollama e vLLM possono funzionare fianco a fianco su porte diverse mentre validi il nuovo deployment.

Fase 1: Riproduci un Modello

Scegli il modello responsabile della maggior parte del traffico API e allinea la sua instruction tuning, il requisito di contesto, i parametri di generazione e il comportamento di chat il più vicino possibile. Non iniziare spostando ogni modello sperimentale.

Fase 2: Valida il Comportamento dell’API

Esegui i test di integrazione esistenti contro l’endpoint vLLM, inclusi streaming, cancellazione, timeout, chiamate a strumenti, richieste malformate, overflow del contesto e accesso concorrente. Registra le differenze comportamentali anziché nasconderle dietro retry del client.

Fase 3: Stabili un Baseline

Misura prima le prestazioni di una richiesta singola. Questo conferma che il modello è caricato correttamente e fornisce un riferimento per i 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 previste in normale operazione e durante un picco plausibile, usando lunghezze di prompt e output rappresentative anziché richieste sintetiche identiche. Monitora code, utilizzo della cache, preemption, tempo al primo token e latenza di coda.

Fase 5: Sposta un Client

Indirizza un’applicazione non critica o una piccola percentuale del traffico a vLLM. Mantieni Ollama disponibile come fallback finché il nuovo server non ha operato in modo affidabile sotto uso reale.

Fase 6: Tara dalle 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 i regressioni delle prestazioni.

Un Checklist Pratico per la Migrazione

Prima di cambiare i client, verifica quanto segue:

[ ] Il modello target è supportato da vLLM
[ ] Il checkpoint e la quantizzazione selezionati si adattano nella VRAM
[ ] Sufficiente VRAM rimane per la cache KV richiesta
[ ] La lunghezza massima del contesto riflette l'uso reale
[ ] Il template di chat corretto è disponibile
[ ] Stop token e default di generazione sono testati
[ ] Lo streaming funziona con i client esistenti
[ ] Le chiamate a strumenti e l'output strutturato sono validati
[ ] 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 test di carico includono concorrenza realistica
[ ] Timeout e cancellazioni sono gestiti
[ ] Esiste un percorso di rollback a Ollama

Questo elenco è deliberatamente operativo. Installare vLLM è solitamente 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 all’Internet pubblico. Un server di inferenza non autenticato può consumare capacità GPU costosa, rivelare il comportamento del modello e diventare una via per attacchi di 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 accesso condiviso o remoto, posizionare il servizio dietro un reverse proxy o un gateway API che fornisca TLS, restrizioni di rete, limiti di dimensione delle richieste, limiti di velocità, logging degli accessi e autenticazione appropriata — lo stesso modello coperto in [Ollama dietro un reverse proxy con Caddy o Nginx](https://www.glukhov.org/it/llm-hosting/ollama/ollama-behind-reverse-proxy/ “Proteggi Ollama dietro un reverse proxy”}) si applica altrettanto bene davanti a vLLM.

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

Quando Non Migrare

Rimani con Ollama quando:

• Uno o due utenti accedono al server
• Le richieste sono prevalentemente sequenziali
• Il modello fornisce già una latenza accettabile
• La gestione facile di GGUF è importante
• È richiesto l’offloading su CPU o GPU parziale
• I modelli vengono cambiati 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 coda, i prefissi ripetuti consumano tempo significativo di prefill o un modello più grande deve essere distribuito su GPU, il server più semplice può essere diventato la scelta più costosa operativamente.

Mantieni Ollama per lo Sviluppo e Aggiungi vLLM per il Serving 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 GGUF e uso interattivo privato mentre un’istanza vLLM condivisa serve un modello stabile a applicazioni e team. Questa separazione conta anche per la [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 rimangono sotto il tuo controllo indipendentemente da quale server gestisca una data richiesta.

Questo separa due workflow diversi:

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

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

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

Flusso di Decisione per la Migrazione

Il seguente diagramma riassume i punti di decisione chiave:

Conclusione

Ollama è difficile da battere come esecutore di modelli locali. Rimuove abbastanza packaging e lavoro di 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, prefissi lunghi 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.