Monitoraggio dell'inferenza LLM in produzione (2026): Prometheus e Grafana per vLLM, TGI e llama.cpp

L’inferenza LLM sembra “un altro API” — fino a quando i picchi di latenza, le code si ingorgano e le tue GPU rimangono al 95% di memoria senza una spiegazione ovvia.

Il monitoraggio diventa fondamentale nel momento in cui si supera una configurazione a singolo nodo o si inizia a ottimizzare per il throughput. A quel punto, le metriche API tradizionali non sono sufficienti. È necessaria visibilità su token, comportamento del batching, tempo di coda e pressione della cache KV: i veri colli di bottiglia dei moderni sistemi LLM.

Questo articolo fa parte della mia guida più ampia su 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 dei carichi di lavoro di inferenza LLM.

(Se stai decidendo sull’infrastruttura, vedi la mia guida sull’hosting LLM nel 2026. Se vuoi un’analisi approfondita della meccanica del batching, dei limiti VRAM e dei compromessi tra throughput e latenza, vedi la guida all’ingegneria delle prestazioni LLM.)

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

Questa guida è un percorso pratico, focalizzato sulla produzione, per costruire il 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 estrarre /metrics dai server comuni (vLLM, Hugging Face TGI, llama.cpp)
• Esempi 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 indipendenti dal fornitore. Che tu aggiunga successivamente il tracciamento OpenTelemetry, l’autoscalamento o un service mesh, lo stesso modello di metriche si applica.

Perché dovresti monitorare l’inferenza LLM in modo diverso

Il monitoraggio API tradizionale (RPS, latenza p95, tasso di errore) è necessario ma non sufficiente. Il servizio LLM aggiunge assi aggiuntivi:

1) La latenza ha due significati

• Latenza E2E: tempo dalla ricezione della richiesta → ritorno del token finale.
• Latenza inter-token: tempo per token durante il decode (critico per l’UX di streaming).

Alcuni server espongono entrambi. Ad esempio, TGI espone 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 è paragonabile a uno che ne restituisce 500. Il tuo “RPS” dovrebbe spesso essere “token/sec”.

3) La coda è il prodotto

Se esegui un batching 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 precursore di interruzione

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

Checklist delle metriche per il monitoraggio dell’inferenza LLM

Usa questo come tua stella polare. Non hai bisogno di tutto dal primo giorno, ma alla fine ne vorrai la maggior parte.

Segnali d’oro (versione LLM)

• Traffico: richieste/sec, token/sec
• Errori: tasso di errore, timeout, OOM (Out of Memory), 429 (limitazione delle richieste)
• Latenza: durata richiesta p50/p95/p99; latenza prefill vs decode; latenza inter-token
• Saturazione: utilizzo GPU, utilizzo memoria, utilizzo cache KV, dimensione coda

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

Per una visione più ampia dell’osservabilità LLM oltre le metriche — inclusi tracciamento, log strutturati, test sintetici, profiling GPU e progettazione SLO — vedi la mia guida approfondita sull’osservabilità per sistemi LLM.

Dimensioni utili (etichette)

Mantieni la cardinalità delle etichette bassa. Etichette valide:

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

Evita etichette come:

• prompt grezzo, user_id grezzo, ID richieste — questi esplodono il conteggio delle serie.

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

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

vLLM: /metrics compatibile con Prometheus

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

Per la configurazione del container, il servizio compatibile con OpenAI e l’ottimizzazione runtime orientata al throughput, vedi vLLM Quickstart: High-Performance LLM Serving.

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 richieste

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

Di particolare rilievo:

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

La configurazione operativa—Docker, GPU, flag di avvio e i fallimenti che appaiono come estrazioni vuote o fuorvianti—è trattata in TGI - Text Generation Inference - Install, Config, Troubleshoot.

Server llama.cpp: abilita endpoint metriche

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

Per i percorsi di installazione, i flag runtime chiave e l’uso del server compatibile con OpenAI, vedi llama.cpp Quickstart with CLI and Server.

Se esegui llama.cpp dietro un proxy, estrai il server direttamente ogni volta possibile (per evitare che la latenza a livello di proxy nasconda il comportamento reale di inferenza).

Configurazione Prometheus: estrarre i tuoi server di inferenza

Questo esempio presuppone:

• vLLM su http://vllm:8000/metrics
• TGI su http://tgi:8080/metrics
• llama.cpp su http://llama:8080/metrics
• intervallo di scraping ottimizzato per feedback rapidi

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 config di scraping, degli exporter, del relabeling e delle regole di alerting, vedi la mia guida completa su come configurare il monitoraggio Prometheus.

Pro tip: aggiungi un’etichetta “service”

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

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

Esempi PromQL da copiare/incollare

Tasso di richieste (RPS)

sum(rate(tgi_request_count[5m]))

Per vLLM, usa i suoi contatori di richiesta (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]))
)

Latenza p95 per metriche istogramma (Prometheus)

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

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

Tempo di coda p99

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 vincolata da colli di bottiglia nel decode e dalla larghezza di banda della memoria — argomenti trattati in dettaglio nella guida all’ottimizzazione delle prestazioni LLM.

Profondità della coda (istantaneo)

max(tgi_queue_size)

Utilizzo cache KV vLLM (istantaneo)

max(vllm:kv_cache_usage_perc)

Dashboard Grafana: pannelli che aiutano davvero l’on-call

Grafana può visualizzare gli istogrammi in diversi modi (percentili, heatmaps, distribuzioni 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 richiesta p95 (serie temporale)
2. Latenza inter-token p95 (serie temporale)
3. Tasso di errore (serie temporale + stat)

Riga 2 — Capacità e saturazione

4. Dimensione coda (serie temporale)
5. Richieste in esecuzione vs in attesa (stackato)
6. Utilizzo cache KV % (gauge)

Riga 3 — Throughput

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

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

Esempi di query Grafana

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

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

Se stai decidendo tra architetture di inferenza locali, self-hosted o cloud, vedi l’analisi completa nella mia guida al confronto hosting LLM.

Crea una cartella simile a:

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, vedi la mia guida passo-passo su come installare e usare Grafana su Ubuntu.

Provisioning datasource Grafana (grafana/provisioning/datasources/datasource.yml)

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

Provisioning 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 usi kube-prometheus-stack (Prometheus Operator), estrai i target tramite ServiceMonitor.

Per i compromessi infrastrutturali tra Kubernetes, Docker a singolo nodo e provider di inferenza gestiti, vedi 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 scala pulitamente man mano che aggiungi repliche.

3) Alerting: regole stile SLO (esempio)

Ecco buoni alert di partenza:

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

Esempio regola (durata richiesta p95):

- 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)"

Troubleshooting: fallimenti comuni Prometheus + Grafana negli stack LLM

1) Target Prometheus è “DOWN”

Sintomi

• UI Prometheus → Targets mostra DOWN
• “context deadline exceeded” o connessione rifiutata

Checklist

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

Test rapido

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

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

Cause più comuni

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

Correzione

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

3) I percentili dell’istogramma sembrano “piatti” o sbagliati

Gli istogrammi 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 del quantile lato server. La guida alla visualizzazione degli istogrammi di Grafana include pattern pratici per i pannelli.

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

Sintomi

• Utilizzo RAM Prometheus in aumento
• Errori “too many series”

Causa radice tipica

• Hai aggiunto prompt, user_id o ID richieste come etichette in un exporter personalizzato.

Correzione

• Rimuovi le etichette ad alta cardinalità
• Pre-aggrega in etichette a bassa cardinalità (modello, endpoint, status)
• Considera l’uso di log/tracci per il debug per richiesta invece che delle etichette

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

Le metriche sono necessarie, ma a volte serve correlazione:

• Aggiungi log strutturati con metadati della richiesta (modello, conteggio token, TTFT)
• Aggiungi tracciamento (OpenTelemetry) attorno al tuo gateway + server di inferenza
• Usa esemplari (quando supportati) per saltare da un picco di latenza a un tracciato

Un buon flusso di lavoro: picco dashboard Grafana -> clicca su Explore -> restringi per istanza/modello -> controlla log/tracci per quel periodo.

Questo segue il classico modello metriche -> log -> tracci descritto nella guida all’architettura di osservabilità e monitoraggio.

6 vLLM / stranezze metriche multi-processo

Se il tuo stack di servizio funziona in più processi, potresti aver bisogno della configurazione multi-processo di Prometheus (dipende da come il processo espone le metriche). La documentazione vLLM sottolinea l’esposizione delle metriche tramite /metrics per il polling Prometheus; controlla la modalità metriche del server quando deployi.

Un set di dashboard e alert pratici “giorno 1”

Se vuoi una configurazione snella che funzioni comunque in produzione, inizia con:

Pannelli Dashboard

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

Alert

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

Guide di Osservabilità Correlate

• Guida all’Osservabilità: Prometheus, Grafana & Monitoraggio in Produzione
• Monitoraggio Prometheus: Setup & Best Practices
• Installazione e uso di Grafana su Ubuntu: Guida Completa

Guide Infrastrutturali LLM Correlate

• Hosting LLM nel 2026: Locale, Self-Hosted & Cloud Confrontati
• Prestazioni LLM nel 2026: Benchmark & Ottimizzazione

Note conclusive

Prometheus + Grafana ti dà la visione “sempre attiva” della salute dell’inferenza. Una volta che hai le basi, le prossime grandi vittorie solitamente arrivano da:

• SLO per modello / tenant
• modellatura delle richieste (max token, limiti di concorrenza)
• autoscalamento legato al tempo di coda e alla testata della cache KV

Per una spiegazione più ampia sul monitoraggio vs osservabilità, i fondamenti di Prometheus e i pattern per la produzione, vedi la mia guida completa all’osservabilità.