vLLM Quickstart: Serving ad alte prestazioni di LLM - nel 2026

vLLM è un motore di inferenza e servizio per Large Language Models (LLM) ad alto throughput e efficiente nella gestione della memoria, sviluppato dal Sky Computing Lab dell’UC Berkeley.

Grazie al suo rivoluzionario algoritmo PagedAttention, vLLM raggiunge un throughput 14-24 volte superiore rispetto ai metodi di servizio tradizionali, rendendolo la scelta ideale per le implementazioni di LLM in produzione. Per scoprire come vLLM si colloca tra Ollama, Docker Model Runner, LocalAI e i provider cloud—inclusi i compromessi in termini di costi e infrastruttura—consulta LLM Hosting: Infrastruttura Locale, Self-Hosted e Cloud Confrontata.

Cos’è vLLM?

vLLM (virtual LLM) è una libreria open-source per l’inferenza e il servizio rapido di LLM che è rapidamente diventata lo standard del settore per le implementazioni in produzione. Lanciato nel 2023, ha introdotto PagedAttention, una tecnica rivoluzionaria di gestione della memoria che migliora drasticamente l’efficienza del servizio.

Caratteristiche Principali

Prestazioni ad Alto Throughput: vLLM offre un throughput 14-24 volte superiore rispetto a HuggingFace Transformers utilizzando la stessa hardware. Questo enorme guadagno di prestazioni deriva dal batching continuo, dai kernel CUDA ottimizzati e dall’algoritmo PagedAttention che elimina la frammentazione della memoria.

Compatibilità con l’API OpenAI: vLLM include un server API integrato completamente compatibile con il formato di OpenAI. Questo consente una migrazione senza interruzioni da OpenAI a un’infrastruttura self-hosted senza modificare il codice dell’applicazione. Basta puntare il client API all’endpoint di vLLM e funzionerà in modo trasparente.

Algoritmo PagedAttention: L’innovazione principale alla base delle prestazioni di vLLM è PagedAttention, che applica il concetto di paging della memoria virtuale ai meccanismi di attenzione. Invece di allocare blocchi di memoria contigui per le cache KV (che porta alla frammentazione), PagedAttention divide la memoria in blocchi di dimensioni fisse che possono essere allocati su richiesta. Questo riduce lo spreco di memoria fino a 4 volte e consente dimensioni dei batch molto più grandi.

Batching Continuo: A differenza del batching statico dove si attende che tutte le sequenze siano completate, vLLM utilizza il batching continuo (rolling). Non appena una sequenza termina, una nuova può essere aggiunta al batch. Questo massimizza l’utilizzo della GPU e minimizza la latenza per le richieste in arrivo.

Supporto Multi-GPU: vLLM supporta il parallelismo tensoriale e il parallelismo di pipeline per distribuire modelli grandi su più GPU. Può servire in modo efficiente modelli che non rientrano nella memoria di una singola GPU, supportando configurazioni da 2 a 8+ GPU.

Ampio Supporto per i Modelli: Compatibile con architetture di modelli popolari tra cui LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma e molti altri. Supporta sia modelli istruiti (instruction-tuned) che modelli di base (base models) da HuggingFace Hub.

Quando Utilizzare vLLM

vLLM eccelle in scenari specifici in cui i suoi punti di forza brillano:

Servizi API in Produzione: Quando è necessario servire un LLM a molti utenti concorrenti tramite API, l’alto throughput e il batching efficiente di vLLM lo rendono la scelta migliore. Le aziende che gestiscono chatbot, assistenti di codice o servizi di generazione di contenuti beneficiano della sua capacità di gestire centinaia di richieste al secondo.

Carichi di Lavoro ad Alta Concorrenza: Se la tua applicazione ha molti utenti simultanei che effettuano richieste, il batching continuo e PagedAttention di vLLM consentono di servire più utenti con la stessa hardware rispetto alle alternative.

Ottimizzazione dei Costi: Quando i costi delle GPU sono una preoccupazione, il throughput superiore di vLLM significa che puoi servire lo stesso traffico con meno GPU, riducendo direttamente i costi dell’infrastruttura. L’efficienza della memoria 4x derivante da PagedAttention consente anche di utilizzare istanze GPU più piccole ed economiche.

Implementazioni Kubernetes: Il design stateless e l’architettura amichevole per i contenitori di vLLM lo rendono ideale per i cluster Kubernetes. Le sue prestazioni coerenti sotto carico e la gestione delle risorse semplice si integrano bene con l’infrastruttura cloud-native.

Quando NON Utilizzare vLLM: Per lo sviluppo locale, l’esperimentazione o scenari utente singolo, strumenti come Ollama o llama.cpp offrono una migliore esperienza utente con una configurazione più semplice. La complessità di vLLM è giustificata quando hai bisogno dei suoi vantaggi prestazionali per carichi di lavoro in produzione.

Come Installare vLLM

Prerequisiti

Prima di installare vLLM, assicurati che il tuo sistema soddisfi questi requisiti:

• GPU: GPU NVIDIA con capacità di calcolo 7.0+ (V100, T4, A10, A100, H100, serie RTX 20/30/40)
• CUDA: Versione 11.8 o superiore
• Python: 3.8 a 3.11
• VRAM: Minimo 16GB per modelli 7B, 24GB+ per 13B, 40GB+ per modelli più grandi
• Driver: Driver NVIDIA 450.80.02 o più recente

Installazione tramite pip

Il metodo di installazione più semplice è utilizzare pip. Questo funziona su sistemi con CUDA 11.8 o versioni successive:

# Crea un ambiente virtuale (raccomandato)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Installa vLLM
pip install vllm

# Verifica l'installazione
python -c "import vllm; print(vllm.__version__)"

Per sistemi con versioni CUDA diverse, installa la wheel appropriata:

# Per CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# Per CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Installazione con Docker

Docker fornisce il metodo di distribuzione più affidabile, specialmente per la produzione:

# Scarica l'immagine ufficiale di vLLM
docker pull vllm/vllm-openai:latest

# Esegui vLLM con supporto GPU
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

Il flag --ipc=host è importante per le configurazioni multi-GPU poiché abilita una corretta comunicazione inter-processo.

Compilazione dalle Sorgenti

Per le funzionalità più recenti o modifiche personalizzate, compila dalle sorgenti:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Guida Rapida a vLLM

Esecuzione del Tuo Primo Modello

Avvia vLLM con un modello utilizzando l’interfaccia a riga di comando:

# Scarica e servi Mistral-7B con API compatibile OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM scaricherà automaticamente il modello da HuggingFace Hub (se non è in cache) e avvierà il server. Vedrai un output che indica che il server è pronto:

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

Effettuazione di Richieste API

Una volta che il server è in esecuzione, puoi effettuare richieste utilizzando il client Python OpenAI o curl:

Utilizzando curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Spiega cos'è vLLM in una frase:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Utilizzando il Client Python OpenAI:

from openai import OpenAI

# Puntare al tuo server vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM non richiede autenticazione per impostazione predefinita
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Spiega cos'è vLLM in una frase:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API Chat Completions:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Sei un assistente utile."},
        {"role": "user", "content": "Cos'è PagedAttention?"}
    ],
    max_tokens=200
)

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

Configurazione Avanzata

vLLM offre numerosi parametri per ottimizzare le prestazioni:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Usa il 95% della memoria GPU
    --max-model-len 8192 \            # Lunghezza massima della sequenza
    --tensor-parallel-size 2 \        # Usa 2 GPU con parallelismo tensoriale
    --dtype float16 \                 # Usa precisione FP16
    --max-num-seqs 256                # Dimensione massima del batch

Parametri Chiave Spiegati:

• --gpu-memory-utilization: Quanta memoria GPU utilizzare (0.90 = 90%). Valori più alti permettono batch più grandi ma lasciano meno margine per picchi di memoria.
• --max-model-len: Lunghezza massima del contesto. Ridurre questo valore salva memoria per batch più grandi.
• --tensor-parallel-size: Numero di GPU su cui dividere il modello.
• --dtype: Tipo di dati per i pesi (float16, bfloat16 o float32). FP16 è solitamente ottimale.
• --max-num-seqs: Numero massimo di sequenze da elaborare in un batch.

vLLM vs Ollama

vLLM è progettato per il servizio in produzione ad alto throughput e multi-utente con batching continuo, PagedAttention e supporto multi-GPU. Ollama ottimizza per una configurazione locale rapida, convenienza per un singolo utente e gestione semplice dei modelli.

Per una guida decisionale dettagliata che copre segnali di migrazione, passaggi di pianificazione, configurazione Docker Compose e un elenco pratico, consulta Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale.

vLLM vs Docker Model Runner

Docker ha recentemente introdotto Model Runner (precedentemente GenAI Stack) come la loro soluzione ufficiale per il deployment locale di modelli AI. Come si confronta con vLLM?

Filosofia Architetturale

Docker Model Runner mira ad essere il “Docker per l’AI” – un modo semplice e standardizzato per eseguire modelli AI localmente con la stessa facilità con cui si eseguono contenitori. Astrae la complessità e fornisce un’interfaccia coerente tra diversi modelli e framework.

vLLM è un motore di inferenza specializzato focalizzato esclusivamente sul servizio di LLM con prestazioni massime. È uno strumento di livello inferiore che containerizzi con Docker, piuttosto che una piattaforma completa.

Configurazione e Avvio

L’installazione di Docker Model Runner è semplice per gli utenti Docker:

docker model pull llama3:8b
docker model run llama3:8b

Questa somiglianza con il flusso di lavoro delle immagini Docker lo rende immediatamente familiare agli sviluppatori che utilizzano già i contenitori.

vLLM richiede una configurazione iniziale più complessa (Python, CUDA, dipendenze) o l’uso di immagini Docker precompilate:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <nome-modello>

Caratteristiche delle Prestazioni

vLLM offre un throughput superiore per scenari multi-utente grazie a PagedAttention e al batching continuo. Per i servizi API in produzione che gestiscono centinaia di richieste al secondo, le ottimizzazioni di vLLM forniscono un throughput 2-5 volte migliore rispetto agli approcci di servizio generici.

Docker Model Runner si concentra sulla facilità d’uso piuttosto che sulle prestazioni massime. È adatto per lo sviluppo locale, i test e carichi di lavoro moderati, ma non implementa le ottimizzazioni avanzate che rendono vLLM eccellente su larga scala.

Supporto Modelli

Docker Model Runner fornisce una libreria di modelli curata con accesso in un comando ai modelli popolari. Supporta più framework (non solo LLM) inclusi Stable Diffusion, Whisper e altri modelli AI, rendendolo più versatile per diversi carichi di lavoro AI.

vLLM si specializza nell’inferenza dei LLM con supporto approfondito per i modelli linguistici basati su transformer. Supporta qualsiasi LLM compatibile con HuggingFace ma non si estende ad altri tipi di modelli AI come la generazione di immagini o il riconoscimento vocale.

Deployment in Produzione

vLLM è stato testato in produzione da aziende come Anthropic, Replicate e molte altre che servono miliardi di token quotidianamente. Le sue caratteristiche prestazionali e la stabilità sotto carico pesante lo rendono lo standard de facto per il servizio LLM in produzione.

Docker Model Runner è più recente e si posiziona più per scenari di sviluppo e test locali. Sebbene possa servire traffico di produzione, manca del track record comprovato e delle ottimizzazioni prestazionali che le distribuzioni in produzione richiedono.

Ecosistema di Integrazione

vLLM si integra con gli strumenti di infrastruttura di produzione: operatori Kubernetes, metriche Prometheus, Ray per il servizio distribuito e ampia compatibilità con l’API OpenAI per le applicazioni esistenti.

Docker Model Runner si integra naturalmente con l’ecosistema Docker e Docker Desktop. Per i team già standardizzati su Docker, questa integrazione fornisce un’esperienza coerente ma meno funzionalità specializzate per il servizio LLM.

Quando Utilizzare Ciascuno

Utilizza vLLM per:

• Servizi API LLM in produzione
• Deployment ad alto throughput e multi-utente
• Deployment cloud sensibili ai costi che necessitano di massima efficienza
• Ambienti Kubernetes e cloud-native
• Quando hai bisogno di scalabilità e prestazioni comprovate

Utilizza Docker Model Runner per:

• Sviluppo e test locali
• Esecuzione di vari tipi di modelli AI (non solo LLM)
• Team fortemente investiti nell’ecosistema Docker
• Sperimentazione rapida senza configurazione dell’infrastruttura
• Scopi di apprendimento ed educativi

Approccio Ibrido: Molti team sviluppano con Docker Model Runner localmente per comodità, per poi distribuire con vLLM in produzione per le prestazioni. Le immagini Docker Model Runner possono anche essere utilizzate per eseguire contenitori vLLM, combinando entrambi gli approcci.

Best Practice per il Deployment in Produzione

Deployment Docker

Crea una configurazione Docker Compose pronta per la produzione:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Deployment Kubernetes

Distribuisci vLLM su Kubernetes per la scala di produzione:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Monitoraggio e Osservabilità

vLLM espone metriche Prometheus per il monitoraggio:

import requests

# Ottieni metriche
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Metriche chiave da monitorare:

• vllm:num_requests_running - Richieste attive
• vllm:gpu_cache_usage_perc - Utilizzo della cache KV
• vllm:time_to_first_token - Metrica di latenza
• vllm:time_per_output_token - Velocità di generazione

Ottimizzazione delle Prestazioni

Ottimizza l’Utilizzo della Memoria GPU: Inizia con --gpu-memory-utilization 0.90 e regola in base al comportamento osservato. Valori più alti permettono batch più grandi ma rischiano errori OOM durante i picchi di traffico.

Regola la Lunghezza Massima della Sequenza: Se il tuo caso d’uso non necessita della lunghezza massima del contesto, riduci --max-model-len. Questo libera memoria per batch più grandi. Ad esempio, se hai bisogno solo di un contesto 4K, imposta --max-model-len 4096 invece di usare il massimo del modello (spesso 8K-32K).

Scegli la Quantizzazione Appropriate: Per i modelli che lo supportano, usa versioni quantizzate (8-bit, 4-bit) per ridurre la memoria e aumentare il throughput:

--quantization awq  # Per modelli quantizzati AWQ
--quantization gptq # Per modelli quantizzati GPTQ

Abilita la Caching dei Prefissi: Per applicazioni con prompt ripetuti (come chatbot con messaggi di sistema), abilita la caching dei prefissi:

--enable-prefix-caching

Questo memorizza nella cache i valori KV per i prefissi comuni, riducendo il calcolo per le richieste che condividono lo stesso prefisso del prompt.

Risoluzione dei Problemi Comuni

Errori di Memoria Insufficiente (Out of Memory)

Sintomi: Il server crasha con errori CUDA out of memory.

Soluzioni:

• Riduci --gpu-memory-utilization a 0.85 o 0.80
• Diminuisci --max-model-len se il tuo caso d’uso lo consente
• Abbassa --max-num-seqs per ridurre la dimensione del batch
• Usa una versione quantizzata del modello
• Abilita il parallelismo tensoriale per distribuire su più GPU

Throughput Basso

Sintomi: Il server gestisce meno richieste del previsto.

Soluzioni:

• Aumenta --max-num-seqs per permettere batch più grandi
• Aumenta --gpu-memory-utilization se hai margine
• Verifica se la CPU è il collo di bottiglia con htop – considera CPU più veloci
• Verifica l’utilizzo della GPU con nvidia-smi – dovrebbe essere al 95%+
• Abilita FP16 se stai usando FP32: --dtype float16

Tempo del Primo Token Lento

Sintomi: Alta latenza prima dell’inizio della generazione.

Soluzioni:

• Usa modelli più piccoli per applicazioni critiche per la latenza
• Abilita la caching dei prefissi per prompt ripetuti
• Riduci --max-num-seqs per dare priorità alla latenza rispetto al throughput
• Considera il decoding speculativo per i modelli supportati
• Ottimizza la configurazione del parallelismo tensoriale

Fallimenti nel Caricamento del Modello

Sintomi: Il server non si avvia, non riesce a caricare il modello.

Soluzioni:

• Verifica che il nome del modello corrisponda esattamente al formato HuggingFace
• Controlla la connettività di rete a HuggingFace Hub
• Assicurati di avere spazio su disco sufficiente in ~/.cache/huggingface
• Per modelli con accesso limitato (gated), imposta la variabile d’ambiente HF_TOKEN
• Prova a scaricare manualmente con huggingface-cli download <modello>

Funzionalità Avanzate

Decoding Speculativo

vLLM supporta il decoding speculativo, dove un modello draft più piccolo propone token che un modello target più grande verifica. Questo può accelerare la generazione di 1.5-2 volte. Per una guida completa ai metodi di decoding speculativo — modelli draft, EAGLE-3, P-EAGLE e n-gram — consulta Decoding Speculativo: Inferenza Più Veloce Senza Perdita di Qualità.

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

Adattatori LoRA

Servi più adattatori LoRA sopra un modello base senza caricare più modelli completi:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Poi specifica quale adattatore usare per richiesta:

response = client.completions.create(
    model="sql-lora",  # Usa l'adattatore SQL
    prompt="Converti questo in SQL: Mostrami tutti gli utenti creati questo mese"
)

Servizio Multi-LoRA

Il servizio multi-LoRA di vLLM permette di ospitare decine di adattatori fine-tuned con un minimo overhead di memoria. Questo è ideale per servire varianti di modelli specifiche per cliente o per compito:

# Richiesta con adattatore LoRA specifico
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Scrivi query SQL"}],
    extra_body={"lora_name": "sql-lora"}
)

Caching dei Prefissi

Abilita la caching automatica dei prefissi per evitare di ricalcolare la cache KV per i prefissi dei prompt ripetuti:

--enable-prefix-caching

Questo è particolarmente efficace per:

• Chatbot con prompt di sistema fissi
• Applicazioni RAG con template di contesto consistenti
• Prompt few-shot learning ripetuti tra le richieste

La caching dei prefissi può ridurre il tempo fino al primo token del 50-80% per le richieste che condividono prefissi del prompt.

Esempi di Integrazione

Integrazione con LangChain

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Spiega PagedAttention in termini semplici")
print(response)

Integrazione con LlamaIndex

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("Cos'è vLLM?")
print(response)

Applicazione FastAPI

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Benchmark delle Prestazioni

I dati prestazionali reali aiutano a illustrare i vantaggi di vLLM:

Confronto di Throughput (Mistral-7B su GPU A100):

• vLLM: ~3.500 token/secondo con 64 utenti concorrenti
• HuggingFace Transformers: ~250 token/secondo con la stessa concorrenza
• Ollama: ~1.200 token/secondo con la stessa concorrenza
• Risultato: vLLM offre un miglioramento di 14x rispetto alle implementazioni di base

Efficienza della Memoria (LLaMA-2-13B):

• Implementazione standard: 24GB VRAM, 32 sequenze concorrenti
• vLLM con PagedAttention: 24GB VRAM, 128 sequenze concorrenti
• Risultato: 4x più richieste concorrenti con la stessa memoria

Latenza Sotto Carico (Mixtral-8x7B su 2xA100):

• vLLM: Latenza P50 180ms, Latenza P99 420ms a 100 req/s
• Servizio standard: Latenza P50 650ms, Latenza P99 3.200ms a 100 req/s
• Risultato: vLLM mantiene una latenza coerente sotto carico elevato

Questi benchmark dimostrano perché vLLM sia diventato lo standard de facto per il servizio LLM in produzione dove le prestazioni contano.

Analisi dei Costi

Comprendere le implicazioni di costo nella scelta di vLLM:

Scenario: Servire 1M di richieste/giorno

Con Servizio Standard:

• Richiesto: 8x GPU A100 (80GB)
• Costo AWS: ~$32/ora × 24 × 30 = $23.040/mese
• Costo per 1M token: ~$0.75

Con vLLM:

• Richiesto: 2x GPU A100 (80GB)
• Costo AWS: ~$8/ora × 24 × 30 = $5.760/mese
• Costo per 1M token: ~$0.19
• Risparmio: $17.280/mese (riduzione del 75%)

Questo vantaggio di costo cresce con la scala. Le organizzazioni che servono miliardi di token mensilmente risparmiano centinaia di migliaia di dollari utilizzando il servizio ottimizzato di vLLM invece di implementazioni naive.

Considerazioni di Sicurezza

Autenticazione

vLLM non include l’autenticazione per impostazione predefinita. Per la produzione, implementa l’autenticazione a livello di reverse proxy:

# Configurazione Nginx
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Oppure usa API gateway come Kong, Traefik o AWS API Gateway per autenticazione e limitazione della frequenza (rate limiting) di livello enterprise.

Isolamento di Rete

Esegui vLLM in reti private, non esposte direttamente a Internet:

# Esempio di NetworkPolicy Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Limitazione della Frequenza (Rate Limiting)

Implementa la limitazione della frequenza per prevenire l’abuso:

# Esempio usando Redis per la limitazione della frequenza
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # Finestra di 60 secondi
    
    if requests > 60:  # 60 richieste al minuto
        raise HTTPException(status_code=429, detail="Limite della frequenza superato")
    
    return await call_next(request)

Controllo Accesso ai Modelli

Per deployment multi-tenant, controlla quali utenti possono accedere a quali modelli:

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Tutti i modelli
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Guida alla Migrazione

Da OpenAI a vLLM

La migrazione da OpenAI a vLLM self-hosted è semplice grazie alla compatibilità dell’API:

Prima (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Ciao"}]
)

Dopo (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Se hai aggiunto l'autenticazione
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Ciao"}]
)

Sono necessarie solo due modifiche: aggiorna base_url e il nome del model. Tutto il resto del codice rimane identico.

Da Ollama a vLLM

Ollama utilizza un formato API diverso. La modifica di base lato client è il passaggio dall’endpoint REST di Ollama all’API compatibile OpenAI di vLLM:

API Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Perché il cielo è blu?'})

Equivalente vLLM:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Perché il cielo è blu?"
)

Per una guida alla migrazione approfondita che copre la selezione del modello, template di chat, migrazione graduale e un elenco pratico, consulta Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale.

Da HuggingFace Transformers a vLLM

Migrazione dell’uso diretto di Python:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Ciao", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Ciao", sampling_params)
result = outputs[0].outputs[0].text

L’API Python di vLLM è più semplice e molto più veloce per l’inferenza in batch.

Il Futuro di vLLM

vLLM continua lo sviluppo rapido con funzionalità entusiasmanti in roadmap:

Servizio Disaggregato: Separare prefill (elaborazione del prompt) e decode (generazione del token) su GPU diverse per ottimizzare l’utilizzo delle risorse. Il prefill è legato al calcolo mentre il decode è legato alla memoria, quindi eseguirli su hardware specializzato migliora l’efficienza.

Inferenza Multi-Nodo: Distribuire modelli molto grandi (100B+ parametri) su più macchine, abilitando il servizio di modelli troppo grandi per configurazioni a nodo singolo.

Quantizzazione Avanzata: Supporto per nuovi formati di quantizzazione come GGUF (usato da llama.cpp) e integrazione migliorata AWQ/GPTQ per migliori prestazioni con modelli quantizzati.

Miglioramenti del Decoding Speculativo: Modelli draft più efficienti e strategie di speculazione adattiva per raggiungere accelerazioni superiori senza perdita di accuratezza.

Ottimizzazioni dell’Attenzione: FlashAttention 3, ring attention per contesti estremamente lunghi (100K+ token) e altri meccanismi di attenzione all’avanguardia.

Copertura dei Modelli Migliorata: Espansione del supporto a modelli multimodali (modelli visione-linguaggio), modelli audio e architetture specializzate man mano che emergono.

Il progetto vLLM mantiene uno sviluppo attivo con contributi da UC Berkeley, Anyscale e la più ampia comunità open-source. Man mano che il deployment di LLM diventa più critico per i sistemi di produzione, il ruolo di vLLM come standard prestazionale continua a crescere. Per un confronto più ampio di vLLM con altre infrastrutture LLM locali e cloud, controlla il nostro LLM Hosting: Infrastruttura Locale, Self-Hosted e Cloud Confrontata.

Link Utili

Articoli Correlati su Questo Sito

• Hosting Locale LLM: Guida Completa 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio & Più - Confronto completo di 12+ strumenti di hosting LLM locale includendo un’analisi dettagliata di vLLM accanto a Ollama, LocalAI, Jan, LM Studio e altri. Copre maturità API, supporto tool calling, compatibilità GGUF e benchmark prestazionali per aiutare a scegliere la soluzione giusta.

• Cheat Sheet Ollama - Riferimento completo dei comandi Ollama e cheat sheet che copre installazione, gestione modelli, uso API e best practice per il deployment locale LLM. Essenziale per gli sviluppatori che usano Ollama insieme o in alternativa a vLLM.

• Guida Rapida llama.cpp con CLI e Server - Inferenza C/C++ leggera per modelli GGUF con llama-cli e llama-server compatibile con OpenAI. Ideale quando hai bisogno di controllo fine-grained, deployment offline o uno stack minimale senza Python.

• Docker Model Runner vs Ollama: Quale Scegliere? - Confronto approfondito tra Model Runner di Docker e Ollama per il deployment locale LLM, analizzando prestazioni, supporto GPU, compatibilità API e casi d’uso. Aiuta a comprendere il panorama competitivo in cui opera vLLM.

• Cheat Sheet Docker Model Runner: Comandi & Esempi - Cheat sheet pratico di Docker Model Runner con comandi ed esempi per il deployment di modelli AI. Utile per i team che confrontano l’approccio di Docker con le capacità specializzate di servizio LLM di vLLM.

Risorse Esterne e Documentazione

• Repository GitHub vLLM - Repository ufficiale vLLM con codice sorgente, documentazione completa, guide all’installazione e discussioni della comunità attive. Risorse essenziali per restare aggiornati con le ultime funzionalità e risolvere problemi.

• Documentazione vLLM - Documentazione ufficiale che copre tutti gli aspetti di vLLM dall’installazione di base alla configurazione avanzata. Include riferimenti API, guide di tuning prestazionali e best practice di deployment.

• Paper PagedAttention - Paper accademico che introduce l’algoritmo PagedAttention che alimenta l’efficienza di vLLM. Lettura essenziale per comprendere le innovazioni tecniche dietro i vantaggi prestazionali di vLLM.

• Blog vLLM - Blog ufficiale vLLM con annunci di rilascio, benchmark prestazionali, approfondimenti tecnici e casi studio della comunità da deployment in produzione.

• Model Hub HuggingFace - Repository completo di LLM open-source che funzionano con vLLM. Cerca modelli per dimensione, compito, licenza e caratteristiche prestazionali per trovare il modello giusto per il tuo caso d’uso.

• Documentazione Ray Serve - Documentazione del framework Ray Serve per costruire deployment vLLM scalabili e distribuiti. Ray fornisce funzionalità avanzate come autoscaling, servizio multi-modello e gestione delle risorse per sistemi di produzione.

• NVIDIA TensorRT-LLM - TensorRT-LLM di NVIDIA per inferenza altamente ottimizzata su GPU NVIDIA. Alternativa a vLLM con strategie di ottimizzazione diverse, utile per il confronto e la comprensione del panorama di ottimizzazione dell’inferenza.

• Riferimento API OpenAI - Documentazione ufficiale dell’API OpenAI con cui l’API di vLLM è compatibile. Riferisciti a questo quando costruisci applicazioni che devono funzionare sia con OpenAI che con endpoint vLLM self-hosted in modo intercambiabile.