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

Inferenza rapida delle LLM con l'API di OpenAI

Indice

vLLM è un motore di inference e serving ad alto throughput e con un utilizzo della memoria efficiente per i Large Language Models (LLM), sviluppato dal Sky Computing Lab dell’Università della California a Berkeley.

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

logo vllm

Cos’è vLLM?

vLLM (virtual LLM) è una libreria open source per l’inference e il serving rapidi di LLM che è rapidamente diventata lo standard di settore per le implementazioni in produzione. Lanciata nel 2023, ha introdotto PagedAttention, una tecnica innovativa di gestione della memoria che migliora drasticamente l’efficienza del serving.

Caratteristiche Principali

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

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

Algoritmo PagedAttention: L’innovazione chiave dietro le prestazioni di vLLM è PagedAttention, che applica il concetto di paginazione della memoria virtuale ai meccanismi di attenzione. Invece di allocare blocchi di memoria contigui per le cache KV (che porta a frammentazione), PagedAttention divide la memoria in blocchi di dimensione fissa che possono essere allocati on-demand. Ciò riduce lo spreco di memoria fino a 4 volte e abilita batch di dimensioni molto maggiori.

Continuous Batching: A differenza del batching statico in cui si attende che tutte le sequenze si completino, vLLM utilizza il continuous (rolling) batching. Non appena una sequenza finisce, 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 la parallelizzazione tensoriale e la pipeline parallelism per distribuire grandi modelli 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 dei Modelli: Compatibile con le architetture di modelli popolari come LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma e molte altre. Supporta sia i modelli instruction-tuned sia quelli base da HuggingFace Hub.

Quando Usare vLLM

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

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 per codice o servizi di generazione di contenuti traggono vantaggio dalla sua capacità di gestire centinaia di richieste al secondo.

Carichi di Lavoro ad Alta Concorrenza: Se la tua applicazione ha molti utenti simultanei che fanno richieste, il continuous batching e PagedAttention di vLLM abilitano il serving di più utenti con l’hardware rispetto alle alternative.

Ottimizzazione dei Costi: Quando i costi GPU sono una preoccupazione, il superiore throughput di vLLM significa che puoi servire lo stesso traffico con meno GPU, riducendo direttamente i costi infrastrutturali. L’efficienza di memoria 4x di PagedAttention consente anche l’uso di istanze GPU più piccole e economiche.

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

Quando NON Usare vLLM: Per lo sviluppo locale, la sperimentazione o scenari single-user, strumenti come Ollama o llama.cpp offrono una migliore esperienza utente con un setup più semplice. La complessità di vLLM è giustificata quando ne servono i 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 compute capability 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 è usare pip. Funziona su sistemi con CUDA 11.8 o più recente:

# Crea un ambiente virtuale (consigliato)
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 diverse di CUDA, 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 deployment più affidabile, specialmente per la produzione:

# Scarica l'immagine ufficiale 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 i setup multi-GPU poiché abilita una corretta comunicazione inter-processo.

Compilazione dal Sorgente

Per le funzionalità più recenti o modifiche personalizzate, compila dal sorgente:

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

Guida Rapida a vLLM

Esecuzione del Primo Modello

Avvia vLLM con un modello usando l’interfaccia da riga di comando:

# Scarica e serve Mistral-7B con API compatibile con 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

Esecuzione di Richieste API

Una volta avviato il server, è possibile effettuare richieste usando il client Python di OpenAI o curl:

Usando curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando il Client Python di OpenAI:

from openai import OpenAI

# Indirizza verso il tuo server vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM non richiede autenticazione di default
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

Chat Completions API:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is 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 parallelizzazione tensoriale
    --dtype float16 \                 # Usa precisione FP16
    --max-num-seqs 256                # Dimensione massima del batch

Parametri Chiave Spiegati:

  • --gpu-memory-utilization: Quanta memoria GPU usare (0.90 = 90%). Valori più alti abilitano batch più grandi ma lasciano meno margine per picchi di memoria.
  • --max-model-len: Lunghezza massima del contesto. Ridurre questo valore risparmia 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 è di solito ottimale.
  • --max-num-seqs: Numero massimo di sequenze da elaborare in un batch.

vLLM vs Ollama

vLLM è progettato per il serving in produzione ad alto throughput e multi-utente con continuous batching, PagedAttention e supporto multi-GPU. Ollama ottimizza per setup locale rapido, comodità single-user e gestione semplice dei modelli.

Per una guida dettagliata alle decisioni che copre segnali di migrazione, fasi di pianificazione, setup Docker Compose e una checklist pratica, consulta Da Ollama a vLLM: Quando Migrare il Tuo Server LLM Locale.

vLLM vs Docker Model Runner

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

Filosofia Architetturale

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

vLLM è un motore di inference specializzato focalizzato esclusivamente sul serving di LLM con prestazioni massime. È uno strumento di livello inferiore che si containerizza con Docker, piuttosto che una piattaforma completa.

Setup e Inizio Rapido

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

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

Questa somiglianza con il workflow delle immagini di Docker lo rende immediatamente familiare agli sviluppatori che già usano container.

vLLM richiede più setup iniziale (Python, CUDA, dipendenze) o l’uso di immagini Docker pre-costruite:

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

Caratteristiche Prestazionali

vLLM offre un throughput superiore per gli scenari multi-utente grazie a PagedAttention e continuous batching. 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 serving generici.

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

Supporto dei Modelli

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

vLLM si specializza nell’inference 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 è 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 forte carico lo rendono lo standard de facto per il serving 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 provato e delle ottimizzazioni prestazionali richieste dai deployment in produzione.

Ecosistema di Integrazione

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

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

Quando Usare Ciascuno

Usa vLLM per:

  • Servizi API LLM in produzione
  • Deployment ad alto throughput e multi-utente
  • Deployment cloud sensibili ai costi che richiedono massima efficienza
  • Ambienti Kubernetes e cloud-native
  • Quando serve scalabilità e prestazioni provate

Usa 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 setup infrastrutturale
  • Scopi di apprendimento ed educativi

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

Best Practices 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

Deploya vLLM su Kubernetes per scala in 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 le 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

Tuning 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 abilitano 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 richiede la lunghezza completa del contesto, riduci --max-model-len. Questo libera memoria per batch più grandi. Ad esempio, se hai bisogno solo di contesto 4K, imposta --max-model-len 4096 invece di usare il massimo del modello (spesso 8K-32K).

Scegli la Quantizzazione Appropriata: 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 Prefix Caching: Per applicazioni con prompt ripetuti (come chatbot con messaggi di sistema), abilita la prefix caching:

--enable-prefix-caching

Questo mette in cache i valori KV per i prefissi comuni, riducendo i calcoli per le richieste che condividono lo stesso prefisso 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
  • Riduci --max-num-seqs per ridurre la dimensione del batch
  • Usa una versione quantizzata del modello
  • Abilita la parallelizzazione tensoriale per distribuire su più GPU

Su una singola scheda da 16 GB, la maggior parte di questi errori OOM è riconducibile alla budget della KV-cache piuttosto che solo ai pesi — KV Cache su GPU da 16 GB copre la formula esatta, il dtype FP8 per la KV-cache e i compromessi della prefix-caching dietro --max-model-len e --max-num-seqs prima di ricorrere a un modello più piccolo.

Basso Throughput

Sintomi: Il server gestisce meno richieste del previsto.

Soluzioni:

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

Tempi Lenti per il Primo Token

Sintomi: Alta latenza prima che la generazione inizi.

Soluzioni:

  • Usa modelli più piccoli per applicazioni critiche per la latenza
  • Abilita la prefix caching per prompt ripetuti
  • Riduci --max-num-seqs per dare priorità alla latenza rispetto al throughput
  • Considera lo speculative decoding per i modelli supportati
  • Ottimizza la configurazione della parallelizzazione tensoriale

Fallimenti nel Caricamento del Modello

Sintomi: Il server non riesce ad avviarsi, non può caricare il modello.

Soluzioni:

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

Funzionalità Avanzate

Speculative Decoding

vLLM supporta lo speculative decoding, in cui un modello draft più piccolo propone token che un modello target più grande verifica. Questo può accelerare la generazione di 1.5-2x. Per una guida completa ai metodi di speculative decoding — modelli draft, EAGLE-3, P-EAGLE e n-gram — consulta Speculative Decoding: Inference 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

Serve più adattatori LoRA su 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="Convert this to SQL: Show me all users created this month"
)

Multi-LoRA Serving

Il multi-LoRA serving di vLLM consente di ospitare decine di adattatori fine-tunati con un sovraccarico di memoria minimo. Questo è ideale per servire varianti di modelli specifiche per cliente o per task:

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

Prefix Caching

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

--enable-prefix-caching

Questo è particolarmente efficace per:

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

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

Esempi di Integrazione

Integrazione 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("Explain PagedAttention in simple terms")
print(response)

Integrazione 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("What is 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 sulle prestazioni nel mondo reale aiutano a illustrare i vantaggi di vLLM:

Confronto del 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 fornisce 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: 4 volte 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
  • Serving standard: Latenza P50 650ms, Latenza P99 3.200ms a 100 req/s
  • Risultato: vLLM mantiene una latenza costante sotto forte carico

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

Analisi dei Costi

Comprendere le implicazioni sui costi della scelta di vLLM:

Scenario: Serving 1M richieste/giorno

Con Serving 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 sui costi cresce con la scala. Le organizzazioni che servono miliardi di token mensilmente risparmiano centinaia di migliaia di dollari usando il serving ottimizzato di vLLM invece di implementazioni naive.

Considerazioni di Sicurezza

Autenticazione

vLLM non include l’autenticazione di default. 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 gateway API come Kong, Traefik o AWS API Gateway per autenticazione e rate limiting di livello enterprise.

Isolamento di Rete

Esegui vLLM in reti private, non esposto direttamente a internet:

# Esempio 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

Rate Limiting

Implementa il rate limiting per prevenire abusi:

# Esempio usando Redis per il rate limiting
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="Rate limit exceeded")
    
    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

Migrare da OpenAI a vLLM self-hosted è semplice grazie alla compatibilità 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": "Hello"}]
)

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": "Hello"}]
)

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

Da Ollama a vLLM

Ollama usa un formato API diverso. La modifica di base a livello client è passare dall’endpoint REST di Ollama all’API compatibile con OpenAI di vLLM:

API Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})

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="Why is the sky blue?"
)

Per una guida di migrazione approfondita che copre la selezione del modello, i template di chat, la migrazione graduale e una checklist pratica, 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("Hello", 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("Hello", sampling_params)
result = outputs[0].outputs[0].text

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

Il Futuro di vLLM

vLLM continua uno sviluppo rapido con funzionalità entusiasmanti nella roadmap:

Serving Disaggregato: Separare prefill (elaborazione del prompt) e decode (generazione dei token) su GPU diverse per ottimizzare l’utilizzo delle risorse. Il prefill è compute-bound mentre il decode è memory-bound, quindi eseguirli su hardware specializzato migliora l’efficienza.

Inference Multi-Nodo: Distribuire modelli molto grandi (100B+ parametri) su più macchine, abilitando il serving di modelli troppo grandi per setup single-node.

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

Miglioramenti dello Speculative Decoding: Modelli draft più efficienti e strategie di speculazione adattive per raggiungere speedup più alti senza perdita di accuratezza.

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

Migliore Copertura dei Modelli: Espansione del supporto a modelli multimodali (modelli vision-language), modelli audio e architetture specializzate man mano che emergono.

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

Articoli Correlati su Questo Sito

  • Hosting LLM Locale: Guida Completa 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio e altro - Confronto completo di 12+ strumenti di hosting LLM locali inclusa un’analisi dettagliata di vLLM accanto a Ollama, LocalAI, Jan, LM Studio e altri. Copre la maturità API, il supporto del tool calling, la compatibilità GGUF e i benchmark prestazionali per aiutarti a scegliere la soluzione giusta.

  • Scheda Rapida Ollama - Riferimento completo e scheda rapida dei comandi di Ollama che copre installazione, gestione dei modelli, uso dell’API e best practices per il deployment LLM locale. Essenziale per gli sviluppatori che usano Ollama insieme o al posto di vLLM.

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

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

  • Scheda Rapida Docker Model Runner: Comandi ed Esempi - Scheda rapida pratica 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 serving LLM di vLLM.

Risorse Esterne e Documentazione

  • Repository GitHub di vLLM - Repository ufficiale di vLLM con codice sorgente, documentazione completa, guide di installazione e discussioni di community attive. Risorse essenziali per restare aggiornati sulle ultime funzionalità e risolvere i problemi.

  • Documentazione di vLLM - Documentazione ufficiale che copre tutti gli aspetti di vLLM dal setup di base alla configurazione avanzata. Include riferimenti API, guide al tuning delle prestazioni e best practices per il 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 di vLLM - Blog ufficiale di vLLM con annunci di rilascio, benchmark prestazionali, analisi tecniche approfondite e studi di caso dalla community sui deployment in produzione.

  • Hub dei Modelli HuggingFace - Repository completo di LLM open source che funzionano con vLLM. Cerca modelli per dimensione, task, 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, serving multi-modello e gestione delle risorse per sistemi di produzione.

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

  • Riferimento API OpenAI - Documentazione ufficiale dell’API di OpenAI con cui l’API di vLLM è compatibile. Riferisciti a questa quando costruisco applicazioni che devono funzionare in modo alternato con endpoint OpenAI e vLLM self-hosted.

Iscriviti

Ricevi nuovi articoli su sistemi, infrastruttura e ingegneria AI.