Monitorare l'Inference degli LLM in Produzione (2026): Prometheus & Grafana per vLLM, TGI, llama.cpp

L’inferenza LLM sembra “solo un’altra API” — finché non si verificano picchi di latenza, si formano code, e i tuoi GPU rimangono al 95% di memoria senza spiegazione apparente.

Il monitoraggio diventa cruciale non appena si esce da un’architettura a singolo nodo o si inizia a ottimizzare per il throughput. A quel punto, le metriche tradizionali delle API non sono sufficienti. Hai bisogno di visibilità sui token, sul comportamento di batch, sulla durata della coda e sulla pressione della cache KV — i reali collo di bottiglia dei sistemi LLM moderni.

Questo articolo fa parte della mia guida più ampia osservabilità e monitoraggio, dove copro i fondamenti del monitoraggio vs osservabilità, l’architettura Prometheus e le best practice per la produzione. Qui, ci concentreremo specificamente sul monitoraggio delle cariche di lavoro di inferenza LLM.

(Se stai decidendo sull’infrastruttura, consulta la mia guida a hosting LLM nel 2026. Se vuoi un’analisi approfondita dei meccanismi di batch, dei limiti di VRAM e dei trade-off tra throughput e latenza, consulta la guida all’ingegneria delle prestazioni LLM.)

A differenza dei servizi REST tipici, il servizio LLM è plasmato da token, batching continuo, utilizzo della cache KV, saturazione GPU/CPU e dinamiche della coda. Due richieste con dimensioni di payload identiche possono avere latenze radicalmente diverse a seconda di max_new_tokens, concorrenza e riciclo della cache.

Questa guida è un walkthrough pratico e orientato alla produzione per costruire monitoraggio dell’inferenza LLM con Prometheus e Grafana:

• Cosa misurare (latenza p95/p99, token/sec, durata della coda, utilizzo della cache, tasso di errore)
• Come raccogliere /metrics da server comuni (vLLM, Hugging Face TGI, llama.cpp)
• Esempi di PromQL per percentili, saturazione e throughput
• Pattern di deployment con Docker Compose e Kubernetes
• Risoluzione dei problemi che appaiono solo sotto carico reale

Gli esempi sono intenzionalmente neutri rispetto ai fornitori. Che aggiungi in seguito il tracciamento OpenTelemetry, l’autoscaling o una rete di servizi, lo stesso modello di metriche si applica.

Perché dovresti monitorare l’inferenza LLM in modo diverso

Il monitoraggio tradizionale delle API (RPS, latenza p95, tasso di errore) è necessario ma non sufficiente. L’esecuzione LLM aggiunge ulteriori assi:

1) La latenza ha due significati

• Latenza E2E: tempo dal momento in cui la richiesta è ricevuta al momento in cui l’ultimo token viene restituito.
• Latenza inter-token: tempo per token durante la decodifica (critico per l’esperienza utente streaming).

Alcuni server espongono entrambi. Ad esempio, TGI esponga la durata della richiesta e il tempo medio per token come istogrammi.

2) Il throughput è in token, non in richieste

Un servizio “veloce” che restituisce 5 token non è confrontabile con uno che restituisce 500 token. Il tuo “RPS” dovrebbe spesso essere “token/sec”.

3) La coda è il prodotto

Se esegui il batch continuo, la profondità della coda è ciò che vendi. Monitorare la durata della coda e la dimensione della coda ti dice se stai soddisfacendo le aspettative degli utenti.

4) La pressione della cache è un preavviso di un’interruzione

L’esaurimento (o frammentazione) della cache KV spesso si manifesta come picchi improvvisi di latenza e timeout. vLLM esponga l’utilizzo della cache KV come un gauge.

Checklist delle metriche per il monitoraggio dell’inferenza LLM

Usa questa come tua bussola. Non hai bisogno di tutto il primo giorno — ma alla fine vorrai la maggior parte di esso.

Segnali d’oro (LLM-flavored)

• Traffico: richieste/sec, token/sec
• Errori: tasso di errore, timeout, OOMs, 429s (limitazione di velocità)
• Latenza: p50/p95/p99 durata richiesta; latenza prefill vs decodifica; latenza inter-token
• Saturazione: utilizzo GPU, utilizzo memoria, utilizzo cache KV, dimensione coda

Se hai bisogno di visibilità di basso livello sull’utilizzo della memoria GPU, temperatura e utilizzo al di fuori di Prometheus (per il debug o configurazioni a singolo nodo), consulta la mia guida a applicazioni di monitoraggio GPU in Linux / Ubuntu.

Per una visione più ampia dell’osservabilità LLM al di là delle metriche — inclusa la tracciabilità, i log strutturati, i test sintetici, il profilo GPU e la progettazione SLO — consulta la mia guida dettagliata su osservabilità per sistemi LLM.

Dimensioni utili (etichette)

Mantieni bassa la cardinalità delle etichette. Buone etichette:

• model, endpoint, method (prefill/decode), status (success/error), instance

Evita etichette come:

• prompt grezzo, user_id grezzo, ID richiesta — questi espandono il numero di serie.

Esposizione delle metriche: endpoint /metrics predefiniti (vLLM, TGI, llama.cpp)

Il percorso più semplice è: usa le metriche che il server già espone.

vLLM: /metrics compatibile con Prometheus

vLLM espone un endpoint /metrics compatibile con Prometheus (tramite il suo logger delle metriche Prometheus) e pubblica metriche del server/richiesta con il prefisso vllm:, inclusi gauge come richieste in esecuzione e utilizzo della cache KV.

Esempi di metriche che vedrai tipicamente:

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI: /metrics con coda + istogrammi delle richieste

TGI espone molte metriche di produzione su /metrics, tra cui la dimensione della coda, la durata della richiesta, la durata della coda e il tempo medio per token.

Tra le più importanti:

• tgi_queue_size (gauge)
• tgi_request_duration (istogramma, latenza E2E)
• tgi_request_queue_duration (istogramma)
• tgi_request_mean_time_per_token_duration (istogramma)

Server llama.cpp: abilita l’endpoint delle metriche

Il server llama.cpp supporta un endpoint delle metriche compatibile con Prometheus che deve essere abilitato con un flag (es. --metrics).

Se esegui llama.cpp dietro un proxy, scansiona il server direttamente quando possibile (per evitare che la latenza del proxy nasconda il comportamento effettivo dell’inferenza).

Configurazione Prometheus: raccogliere i tuoi server di inferenza

Questo esempio assume:

• vLLM a http://vllm:8000/metrics
• TGI a http://tgi:8080/metrics
• llama.cpp a http://llama:8080/metrics
• intervallo di raccolta ottimizzato per feedback rapido

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Se sei nuovo a Prometheus o vuoi una spiegazione più approfondita delle configurazioni di raccolta, degli esportatori, del relabeling e delle regole di alerting, consulta la mia guida completa a configurazione del monitoraggio con Prometheus.

Consiglio professionale: aggiungi un’etichetta “service”

Se esegui più modelli/repliche, aggiungi il relabeling per includere un’etichetta service stabile per le dashboard.

relabel_configs:
  - target_label: service
    replacement: "llm-inferenza"

Esempi di PromQL che puoi copiare/incollare

Tasso di richieste (RPS)

sum(rate(tgi_request_count[5m]))

Per vLLM, usa i contatori delle richieste (i nomi variano per versione), ma il pattern è lo stesso: sum(rate(<counter>[5m])).

Tasso di errore (%)

Se hai contatori *_success, calcola il rapporto di fallimento:

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

p95 latenza per metriche istogramma (Prometheus)

Gli istogrammi di Prometheus sono conteggi per bucket; usa histogram_quantile() su rate() dei bucket. Prometheus documenta questo modello e i trade-off tra istogramma e summary.

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

p99 tempo di coda

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

Tempo medio per token (latenza inter-token)

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

La latenza inter-token è spesso limitata da collo di bottiglia di decodifica e larghezza di banda della memoria — argomenti trattati in dettaglio in guida all’ottimizzazione delle prestazioni LLM.

Profondità della coda (istantanea)

max(tgi_queue_size)

Utilizzo della cache KV vLLM (istantaneo)

max(vllm:kv_cache_usage_perc)

Dashboard Grafana: pannelli che effettivamente aiutano il team di supporto

Grafana può visualizzare gli istogrammi in diversi modi (percentili, heatmap, distribuzione dei bucket). Grafana Labs ha una guida dettagliata alla visualizzazione degli istogrammi Prometheus.

Un layout di dashboard minimo ma ad alto segnale:

Riga 1 — Esperienza utente

1. Latenza p95 delle richieste (serie temporali)
2. Latenza p95 inter-token (serie temporali)
3. Tasso di errore (serie temporali + stat)

Riga 2 — Capacità e saturazione

4. Dimensione della coda (serie temporali)
5. Richieste in esecuzione vs in attesa (pila)
6. Utilizzo della cache KV % (gauge)

Riga 3 — Throughput

7. Richieste/sec
8. Token generati per richiesta (p50/p95)

Se hai lo streaming, aggiungi un pannello per “latenza del primo token” (TTFT) quando disponibile.

Esempi di query Grafana

• Pannello p95 latenza: la query histogram_quantile(0.95, …) sopra
• Pannello heatmap: grafica i tassi dei bucket (*_bucket) come heatmap (Grafana supporta questa approccio)

Opzione di deployment 1: Docker Compose (veloce locale + singolo nodo)

Se stai decidendo tra architetture locali, autohosted o cloud-based per l’inferenza, consulta l’analisi completa nella mia guida di confronto per l’hosting LLM.

Crea una cartella come:

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Se preferisci un’installazione manuale di Grafana invece di Docker, consulta la mia guida passo-passo su installare e usare Grafana su Ubuntu.

Provisioning della fonte dati Grafana (grafana/provisioning/datasources/datasource.yml)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Provisioning delle dashboard (grafana/provisioning/dashboards/dashboards.yml)

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

Opzione di deployment 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Se utilizzi kube-prometheus-stack (Prometheus Operator), raccogli i target tramite ServiceMonitor.

Per i trade-off infrastrutturali tra Kubernetes, Docker a singolo nodo e fornitori gestiti di inferenza, consulta la mia guida all’hosting LLM nel 2026.

1) Espone il tuo deployment di inferenza con un Service

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) Crea un ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

Ripeti per i servizi vLLM e llama.cpp. Questo scalano pulitamente mentre aggiungi repliche.

3) Alerting: regole SLO-style (esempio)

Ecco buone regole di avvio:

• Alta latenza p95 (burn rate)
• Tempo di coda p99 troppo alto (utenti in attesa)
• Tasso di errore > 1%
• Utilizzo cache KV > 90% sostenuto (cliff di capacità)

Esempio di regola (latenza p95 delle richieste):

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "TGI p95 latency > 3s (10m)"

Risoluzione dei problemi: fallimenti comuni di Prometheus + Grafana negli stack LLM

1) Il target Prometheus è “DOWN”

Sintomi

• Interfaccia Prometheus → Target mostra DOWN
• “context deadline exceeded” o connessione rifiutata

Checklist

• Il server espone davvero /metrics?
• Porta errata? Schema errato (http vs https)?
• Kubernetes: il Service seleziona i pod? L’etichetta ServiceMonitor release è corretta?

Test rapido

curl -sS http://tgi:8080/metrics | head

2) Puoi raccogliere le metriche, ma i pannelli sono vuoti

Cause più comuni

• Nome metrica errato (versione server cambiata)
• Il dashboard aspetta _bucket ma hai solo un gauge/counter
• Intervallo di raccolta Prometheus troppo lungo per finestre brevi (es. [1m] con 30s di raccolta può essere rumoroso)

Fix

• Usa Grafana Explore per cercare i prefissi delle metriche (es. tgi_ / vllm:)
• Aumenta la finestra di intervallo da [1m] → [5m]

3) Percentili degli istogrammi appaiono “piatti” o errati

Gli istogrammi di Prometheus richiedono un’aggregazione corretta:

• usa rate(metric_bucket[5m])
• poi sum by (le) (e opzionalmente altre etichette stabili)
• poi histogram_quantile()

Prometheus documenta il modello dei bucket e il calcolo quantile lato server.
La guida alla visualizzazione degli istogrammi di Grafana include modelli di pannelli pratici.

4) Esplosione della cardinalità (picchi di memoria di Prometheus)

Sintomi

• Utilizzo della RAM di Prometheus cresce
• Errori “troppi serie”

Causa tipica

• Hai aggiunto prompt, user_id o ID richiesta come etichette in un esportatore personalizzato.

Fix

• Rimuovi le etichette ad alta cardinalità
• Aggrega preventivamente in etichette a bassa cardinalità (modello, endpoint, stato)
• Considera l’uso di log/tracciamento per il debug richiesta-specifico invece di etichette

5) “Abbiamo le metriche, ma non sappiamo perché è lento”

Le metriche sono necessarie, ma a volte hai bisogno di correlazione:

• Aggiungi log strutturati con metadati richiesta (modello, conteggio token, TTFT)
• Aggiungi tracciamento (OpenTelemetry) intorno al gateway + server di inferenza
• Usa esempi (quando supportati) per saltare da un picco di latenza a una traccia

Un buon flusso di lavoro: picco su Grafana dashboard → clicca in Esplora → restringi per istanza/modello → controlla log/traccia per quel periodo.

Questo segue il modello classico metriche → log → traccia descritto in guida all’architettura osservabilità e monitoraggio.

6) Quirks delle metriche vLLM / multi-process

Se il tuo stack di servizio esegue in più processi, potresti aver bisogno della configurazione multi-process di Prometheus (dipende da come il processo espone le metriche). Le documentazioni vLLM enfatizzano l’esposizione delle metriche tramite /metrics per il polling di Prometheus; controlla la modalità metriche del server durante il deployment.

Un “dashboard e set di alert day-1” pratico

Se vuoi un setup snello che funziona comunque in produzione, inizia con:

Pannelli dashboard

1. Latenza p95 delle richieste
2. Tempo medio per token p95
3. Dimensione della coda
4. Durata della coda p95
5. Tasso di errore
6. Utilizzo cache KV %

Alert

• Latenza p95 delle richieste > X per 10m
• Durata della coda p99 > Y per 10m
• Tasso di errore > 1% per 5m
• Utilizzo cache KV > 90% per 15m
• Target Prometheus down (sempre)

Guide osservabilità correlate

• Guida osservabilità: Prometheus, Grafana & Monitoraggio in Produzione
• Monitoraggio Prometheus: Setup & Best Practice
• Installare e Usare Grafana su Ubuntu: Guida Completa

Guide infrastruttura LLM correlate

• Host LLM nel 2026: Confronto tra Locale, Autohosted e Cloud
• Prestazioni LLM nel 2026: Benchmark & Ottimizzazione

Note finali

Prometheus + Grafana ti danno una visione “sempre attiva” della salute dell’inferenza. Una volta che hai i fondamenti, i prossimi grandi successi vengono spesso da:

• SLO per modello / tenant
• Shape richiesta (token massimi, limiti di concorrenza)
• Autoscaling legato alla durata della coda e headroom della cache KV

Per una spiegazione più ampia del monitoraggio vs osservabilità, i fondamenti di Prometheus e i pattern di produzione, consulta la mia completa guida osservabilità.