Da Ollama a vLLM: quando migrare il tuo server locale per modelli di linguaggio

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

È qui che vLLM diventa rilevante. La migrazione da Ollama a vLLM non è un aggiornamento automatico. Si tratta di uno scambio: si cede parte della semplicità di Ollama per ottenere un maggiore controllo sul batching, sulla gestione della memoria, sulla concorrenza, sull’inferenza distribuita e sulle operazioni di produzione.

Questa guida copre i segnali pratici che indicano quando la migrazione è giustificata, i rischi di migrare troppo presto e un approccio graduale che mantiene entrambi i server in esecuzione affiancati durante la convalida. L’obiettivo è aiutarti a decidere in base alle misurazioni piuttosto che a liste di funzionalità. Per una panoramica più ampia sulle opzioni locali, self-hosted e cloud oltre a questi due runtime, consulta LLM Hosting nel 2026: Infrastrutture Locali, Self-Hosted e Cloud Confrontate.

Ollama e vLLM Risolvono Problemi Diversi

Ollama è ottimizzato principalmente 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 le configurazioni comuni da desktop e workstation.

vLLM è un motore di inferenza e una piattaforma di serving. Le sue preoccupazioni centrali sono la pianificazione delle richieste ad alto throughput, la gestione efficiente della cache KV, 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 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 riassunto:

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

Segnali che Hai Superato i Limiti di Ollama

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

Più Utenti Causano Latenza Instabile

Un server LLM locale può sembrare veloce durante un test isolato e poi degradare bruscamente quando si connettono più client. Le richieste iniziano ad aspettare dietro generazioni lunghe, il tempo fino 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 contemporaneamente — consulta come Ollama gestisce le richieste parallele per comprendere la meccanica di coda e memoria dietro questa impostazione. Questo parallelismo non è gratuito: i requisiti di memoria crescono sia con il numero di richieste parallele configurate che con la lunghezza del contesto.

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

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

Utilizzo della GPU Basso Mentre le Richieste Sono in Coda

Una coda non significa necessariamente che la GPU sia utilizzata al massimo. In una configurazione di serving semplice, il lavoro può essere serializzato anche se richieste aggiuntive potrebbero aver contribuito con calcoli utili allo step di decodifica corrente.

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

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

Prompt Lunghi Dominano il Tempo fino al Primo Token

Assistenti di coding con contesti lunghi, pipeline RAG e sessioni di agenti possono inviare ripetutamente grandi prompt di sistema o prefissi di documenti condivisi. L’elaborazione di questi token di input costituisce la fase di prefill e può dominare il tempo fino al primo token.

vLLM supporta il prefill a chunk e la cache dei prefissi automatica. La cache dei prefissi permette alle richieste successive di riutilizzare i blocchi della cache KV quando la loro sequenza di token iniziale corrisponde a un prefisso già elaborato.

Questo è particolarmente utile quando le richieste condividono:

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

La cache dei prefissi non rende più veloce la generazione dell’output. Riduce il calcolo ripetuto dei prompt, quindi il suo beneficio dipende dal fatto che le richieste contengano effettivamente prefissi riutilizzabili identici.

Hai Bisogno di Più di una GPU

Un modello che non entra in una singola GPU è un motivo forte per considerare vLLM. Supporta il parallelismo tensoriale tra GPU e il parallelismo di pipeline tra più nodi o dispositivi.

Questo non rende l’inferenza multi-GPU senza sforzo. La larghezza di banda degli interconnessi GPU, la topologia PCIe, l’architettura del modello, la memoria condivisa dei container e l’overhead di comunicazione influenzano comunque 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 comodamente.

Hai Bisogno di Osservabilità di Livello Produzione

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

vLLM espone metriche compatibili con Prometheus attraverso il suo endpoint /metrics. Questo rende più facile monitorare nel tempo il volume delle richieste, l’attesa in coda, il tempo fino al primo token, la latenza inter-token, l’utilizzo della cache, le preclusioni, il throughput e gli esiti delle richieste.

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

Dove vLLM Vince Davvero

Il vantaggio più importante di vLLM non è che possa produrre una risposta più velocemente di Ollama su ogni macchina. Il vantaggio significativo è che offre all’operatore più meccanismi per utilizzare in modo efficiente la memoria e la potenza di calcolo degli acceleratori costosi 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 classificazione breve, 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 procedono. Le sequenze completate escono, 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 a Pagine

Durante la generazione, il server memorizza le chiavi e i valori di attenzione per i token elaborati in precedenza. 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 invece di richiedere che ogni sequenza riservi un’unica allocazione contigua grande. Questo approccio riduce la frammentazione della memoria e permette di utilizzare la capacità della cache disponibile in modo più flessibile.

Il valore pratico è una maggiore concorrenza entro lo stesso budget di memoria. Non rimuove il costo sottostante del contesto lungo, ma riduce lo spreco evitabile intorno a quel costo.

Cache dei Prefissi

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

La cache dei prefissi automatica 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 i template, i timestamp, l’ordinamento dei documenti o i 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, di pipeline, di dati, di esperti e di contesto. Non ogni deployment ha bisogno di queste modalità, ma la loro disponibilità è importante quando un servizio cresce oltre una singola GPU.

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

Queste funzionalità introducono complessità operativa. Dovrebbero 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 di strumenti, output strutturato, alias dei modelli, chiavi di autenticazione ed esecuzione distribuita.

Questa flessibilità rende il server più facile da ottimizzare 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 utilizza un’interfaccia di chat, un assistente di codice o un’API locale occasionale, i vantaggi operativi di vLLM potrebbero mai compensare la configurazione aggiuntiva.

Ollama si installa rapidamente, scarica i modelli attraverso un registry semplice e nasconde molti dettagli specifici del modello. È ben adatto per l’esperimentazione e l’uso privato da desktop.

Collezioni di Modelli GGUF

Ollama ha un workflow naturale attorno ai modelli GGUF e ai Modelfiles. Gli utenti esistenti potrebbero avere quantizzazioni curate, adattatori, template, prompt di sistema e parametri che funzionano in modo affidabile 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. Trasferire 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 da desktop a volte si affida all’offloading parziale della GPU perché l’intero modello non entra 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à della cache KV richiesta possono essere serviti efficacemente dalla configurazione dell’acceleratore disponibile. Un carico di lavoro che dipende pesantemente 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 cambiare tra molti modelli locali. Questo è utile per la valutazione, la scrittura, il coding, gli embedding, la visione e l’esperimentazione 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 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 Basandoti Solo sui Token al Secondo

La velocità di generazione dei token per una singola richiesta è un benchmark incompleto. Due server potrebbero 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 fino al primo token
• Latenza inter-token
• Latenza end-to-end della richiesta
• Throughput di elaborazione del prompt
• Throughput dei token di output
• Richieste completate al minuto
• Tempo di attesa in coda
• Consumo di memoria GPU
• Utilizzo della 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 e la configurazione del modello piuttosto che i motori di serving.

Il confronto più utile è un piccolo test di carico che rappresenti il tuo traffico reale. Per un assistente di coding 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 di Ollama non mappano automaticamente a identificatori di modello vLLM equivalenti. Un pacchetto Ollama può contenere una particolare 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 originale del modello
2. Se è un modello base o istruzione-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 valori predefiniti di generazione
7. Requisiti di chiamata di strumenti o output strutturato
8. Qualsiasi adattatore LoRA o prompt di sistema personalizzato

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

Controlla la VRAM Prima di Avviare vLLM

Il fatto che un modello entri nella memoria GPU non significa che possa servire il carico di lavoro richiesto. La VRAM deve coprire più dei soli pesi del modello.

Il budget di memoria pratico include:

pesi del modello
+ cache KV
+ grafici CUDA e allocazioni runtime
+ spazio di lavoro temporaneo
+ cache dei processor multimodali, se utilizzati
+ margine di sicurezza

Contesti lunghi e sequenze concorrenti espandono principalmente il requisito della cache KV. Aumentare la lunghezza massima del contesto riduce quindi il numero di richieste simultanee che possono entrare, anche se la maggior parte delle richieste non usa mai il limite completo.

Inizia con un --max-model-len realistico piuttosto che con il valore più grande pubblicizzato dal modello, ed evita di impostare l’utilizzo della memoria GPU in modo così aggressivo che una variazione minore del carico di lavoro causi errori di memoria esaurita. Un servizio stabile con una capacità teorica leggermente inferiore è più utile di uno che fallisce al primo picco di traffico.

Un Deployment Docker Compose Minimale 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": "Spiega il batching continuo in due paragrafi."
      }
    ],
    "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. Esamina le note di rilascio prima di aggiornare perché le opzioni della riga di comando, le implementazioni dei modelli, le metriche e il comportamento del motore possono evolversi. Questo file Compose è intenzionalmente minimale; per la guida di configurazione più completa — compatibilità API OpenAI, ottimizzazione PagedAttention e un confronto più approfondito vLLM-vs-Ollama — consulta il Quickstart di vLLM.

La Compatibilità con l’API OpenAI Non È Interchangeabilità 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.

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": "Cosa dovrei monitorare su un server LLM?",
      }
    ],
    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 di strumenti
• Gestione dell’output di ragionamento
• Output JSON o vincolato da schema
• Endpoint per embedding
• Input multimodali
• Report sull’utilizzo dei token
• Formati delle risposte di errore
• Scoperta del nome del modello
• Applicazione della lunghezza del contesto

Un client che invia solo completamenti di chat ordinari sarà solitamente più facile da migrare rispetto a un framework di agente che dipende da un parser di chiamate di strumenti particolare o da un’estensione non standard.

I Template di Chat Sono un Comune Fallimento nella Migrazione

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

Ollama impacchetta gran parte di questo comportamento all’interno della sua definizione del modello. Con vLLM, il template è 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
• Le chiamate di 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 utilizzato da ciascun deployment.

Usa una Migrazione Graduale

Sostituire un server locale funzionante in un unico passaggio crea rischi inutili. Ollama e vLLM possono essere eseguiti 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 abbinane l’addestramento alle istruzioni, i requisiti di contesto, i parametri di generazione e il comportamento di chat il più 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, chiamate di strumenti, richieste malformate, overflow del contesto e accesso concorrente. Registra le differenze comportamentali anziché nasconderle dietro i tentativi di riconnessione del client.

Fase 3: Stabilisci una Linea di Base

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

Registra i token del prompt al secondo, i token di output al secondo, il tempo fino al primo token, la latenza totale e l’utilizzo della memoria GPU.

Fase 4: Aggiungi Concorrenza Realistica

Testa il numero di richieste simultanee previsto nel normale funzionamento e durante un picco plausibile, usando lunghezze di prompt e output rappresentative anziché richieste sintetiche identiche. Monitora l’attesa in coda, l’uso della cache, le preclusioni, il tempo fino al primo token e la latenza della coda.

Fase 5: Sposta un Client

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

Fase 6: Ottima dalle Misurazioni

Regola la lunghezza del modello, l’utilizzo della memoria, le sequenze attive massime, la cache dei prefissi, il parallelismo e la quantizzazione solo dopo aver identificato un vincolo misurato. Cambiare più parametri contemporaneamente rende difficile spiegare le regressioni delle prestazioni.

Una Checklist Pratica per la Migrazione

Prima di cambiare i client, verifica quanto segue:

[ ] Il modello di destinazione è supportato da vLLM
[ ] Il checkpoint selezionato e la quantizzazione entrano nella VRAM
[ ] Rimane abbastanza VRAM per la cache KV richiesta
[ ] La lunghezza massima del contesto riflette l'uso reale
[ ] Il template di chat corretto è disponibile
[ ] I token di stop e i valori predefiniti di generazione sono testati
[ ] Lo streaming funziona con i client esistenti
[ ] Le chiamate di strumenti 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 vengono raccolte
[ ] Le metriche GPU vengono raccolte separatamente
[ ] I test di carico includono concorrenza realistica
[ ] I timeout e le 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 esposti casualmente al pubblico Internet. Un server di inferenza non autenticato può consumare capacità GPU costosa, rivelare il comportamento del modello e diventare una rotta 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 l’accesso condiviso o remoto, posiziona il servizio dietro un reverse proxy o un gateway API che fornisca TLS, restrizioni di rete, limiti di dimensione delle richieste, limiti di frequenza, logging degli accessi e autenticazione appropriata — lo stesso schema coperto in Ollama dietro un reverse proxy con Caddy o Nginx si applica ugualmente davanti a vLLM.

Considera anche i rischi specifici del modello. Il caricamento di URL multimodali, codice del modello personalizzato, file remoti ed esecuzione di strumenti senza restrizioni 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 principalmente sequenziali
• Il modello offre già una latenza accettabile
• La gestione facile di GGUF è importante
• È richiesto l’offloading CPU o parziale GPU
• I modelli vengono cambiati frequentemente
• Nessuno vuole operare infrastruttura aggiuntiva
• Non c’è un problema di concorrenza o throughput misurato

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

Conversamente, 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 tra GPU, il server più semplice potrebbe 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 sulle loro workstation per l’esplorazione dei modelli, il test GGUF e l’uso interattivo privato, mentre un’istanza vLLM condivisa serve un modello stabile ad applicazioni e team. Questa divisione è importante anche per la sovranità dell’AI — mantenere entrambi i runtime self-hosted significa che prompt, pesi e log di inferenza rimangono sotto il tuo controllo indipendentemente da quale server gestisce una determinata richiesta.

Questo separa due workflow diversi:

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

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

Questa disposizione abbassa 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 runner di modelli locale. 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, attese in coda, 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 una lista di funzionalità più lunga. Migra quando le misurazioni mostrano che il modello operativo più semplice di Ollama non corrisponde più al carico di lavoro. Finché quel punto, la semplicità non è una debolezza tecnica; è un’ottimizzazione.