Monitor LLM Inference in Production (2026): Prometheus & Grafana voor vLLM, TGI, llama.cpp

LLM-inferentie lijkt op “gewoon een API” — tot er plots sprongen in latentie optreden, wachtrijen zich opbouwen en je GPUs op 95% geheugen zitten zonder duidelijke verklaring.

Monitoring wordt misschien kritisch belangrijk zodra je verder gaat dan een enkel knooppunt of begint met optimalisatie voor doorvoer. Op dat moment zijn traditionele API-metrieken niet meer voldoende. Je hebt zicht nodig op tokens, batchgedrag, wachttijd en druk op de KV-cache — de echte bottlenecks van moderne LLM-systeem.

Dit artikel is onderdeel van mijn bredere observatie- en monitoringgids, waarin ik de fundamenten van monitoring vs observatie, de Prometheus-architectuur en productiebest practices bespreek. Hier zullen we ons specifiek richten op het monitoren van LLM-inferentielasten.

(Voor het beslissen over infrastructuur, zie mijn gids over LLM-hosting in 2026. Voor een diepgaande analyse van batchmechanica, VRAM-limieten en doorvoer vs latentie, zie de LLM-prestatie-engineeringgids.)

In tegenstelling tot typische REST-diensten is het serveren van LLM bepaald door tokens, continue batchverwerking, KV-cache-gebruik, GPU/CPU-verzadiging en wachtrijdynamiek. Twee aanvragen met identieke payloads kunnen radicaal verschillende latentie hebben afhankelijk van max_new_tokens, concurrentie en cachehergebruik.

Deze gids is een praktische, productiegerichte walkthrough voor het bouwen van LLM-inferentie monitoring met Prometheus en Grafana:

• Wat je moet meten (p95/p99 latentie, tokens/sec, wachttijd, cachegebruik, foutpercentage)
• Hoe /metrics te scrapen van veelgebruikte servers (vLLM, Hugging Face TGI, llama.cpp)
• PromQL-voorbeelden voor percentielen, verzadiging en doorvoer
• Implementatiemodellen met Docker Compose en Kubernetes
• Oplossen van problemen die alleen onder echte belasting optreden

De voorbeelden zijn opzetten op een neutrale leverancier. Of je later OpenTelemetry-tracing, autoscaling of een service mesh toevoegt, hetzelfde metriekmodel geldt.

Waarom je LLM-inferentie anders moet monitoren

Traditionele API-monitoring (RPS, p95 latentie, foutpercentage) is nodig, maar niet voldoende. LLM-servering voegt extra assen toe:

1) Latentie heeft twee betekenissen

• E2E latentie: tijd van aanvraag ontvangen tot laatste token geretourneerd.
• Inter-token latentie: tijd per token tijdens decode (kritisch voor streaming UX).

Sommige servers tonen beide. Bijvoorbeeld TGI toont aanvraagduur en gemiddelde tijd per token als histogrammen.

2) Doorvoer is in tokens, niet in aanvragen

Een “snel” dienst die 5 tokens retourneert, is niet vergelijkbaar met een die 500 tokens retourneert. Je “RPS” zou vaak “tokens/sec” moeten zijn.

3) De wachtrij is het product

Als je continue batchverwerking draait, is de wachtrijdiepte wat je verkoopt. Het observeren van wachttijd en wachtrijgrootte vertelt je of je de verwachtingen van de gebruiker voldoet.

4) Cache-druk is een voorloper van een storing

KV-cache-uitputting (of fragmentatie) verschijnt vaak als plotselinge latentiesprongen en time-outs. vLLM toont KV-cachegebruik als een gauge.

Metriek checklist voor LLM-inferentie monitoring

Gebruik dit als je noordster. Je hoeft niet alles op dag één — maar je zult uiteindelijk de meeste van het hebben.

Gouden signalen (LLM-geflavoreerd)

• Verkeer: aanvragen/sec, tokens/sec
• Fouten: foutpercentage, time-outs, OOMs, 429s (aanvraagbeperking)
• Latentie: p50/p95/p99 aanvraagduur; prefill vs decode latentie; inter-token latentie
• Verzadiging: GPU-gebruik, geheugengebruik, KV-cachegrootte, wachtrijgrootte

Als je laag niveau-insicht nodig hebt in GPU-geheugengebruik, temperatuur en gebruik buiten Prometheus (voor debuggen of single-node setup), zie mijn gids over GPU-monitoring toepassingen in Linux / Ubuntu.

Voor een breder overzicht van LLM-observatie buiten metrieken — inclusief tracing, gestructureerde logs, synthetische testen, GPU-profielen en SLO-ontwerp — zie mijn gedetailleerde gids over observatie voor LLM-systemen.

Nuttige dimensies (labels)

Houd labelkaartdichtheid laag. Goede labels:

• model, endpoint, method (prefill/decode), status (succes/fout), instance

Vermijd labels zoals:

• ruwe prompt, ruwe user_id, aanvraag-ids — deze verhogen de reeks aantal.

Exposeren van metrieken: ingebouwde /metrics endpoints (vLLM, TGI, llama.cpp)

De eenvoudigste weg is: gebruik de metrieken die de server al blootlegt.

vLLM: Prometheus-compatibele /metrics

vLLM blootlegt een Prometheus-compatibele /metrics endpoint (via zijn Prometheus metrieklogger) en publiceert server/aanvraagmetrieken met de voorvoegsel vllm:, inclusief gauges zoals lopende aanvragen en KV-cachegrootte.

Voorbeelden van metrieken die je vaak ziet:

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

Hugging Face TGI: /metrics met wachtrij + aanvraag histogrammen

TGI blootlegt veel productie-gegradeerde metrieken op /metrics, inclusief wachtrijgrootte, aanvraagduur, wachtrijduur en gemiddelde tijd per token.

Opvallende:

• tgi_queue_size (gauge)
• tgi_request_duration (histogram, e2e latentie)
• tgi_request_queue_duration (histogram)
• tgi_request_mean_time_per_token_duration (histogram)

llama.cpp server: metrics endpoint inschakelen

De llama.cpp server ondersteunt een Prometheus-compatibele metrics endpoint die moet worden ingeschakeld met een vlag (bijvoorbeeld --metrics).

Als je llama.cpp achter een proxy draait, scan de server zo veel mogelijk direct (om proxy-niveau latentie te vermijden die de werkelijke inferentiegedrag verbergt).

Prometheus configuratie: scrapen van je inferentieservers

Dit voorbeeld veronderstelt:

• vLLM op http://vllm:8000/metrics
• TGI op http://tgi:8080/metrics
• llama.cpp op http://llama:8080/metrics
• scrape interval afgestemd op snelle feedback

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

Als je nieuw bent op Prometheus of een diepgaande uitleg van scrape configuraties, exporters, relabeling en waarschuwingregels wilt, zie mijn volledige Prometheus monitoring setup gids.

Pro tip: voeg een “service label” toe

Als je meerdere modellen/replicaties draait, voeg relabeling toe om een stabiel service label toe te voegen voor dashboards.

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

PromQL-voorbeelden die je kunt kopiëren/pasten

Aanvraag frequentie (RPS)

sum(rate(tgi_request_count[5m]))

Voor vLLM, gebruik zijn aanvraagtellers (namen variëren per versie), maar het patroon is hetzelfde: sum(rate(<counter>[5m])).

Foutpercentage (%)

Als je *_success tellers hebt, bereken het falenpercentage:

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

p95 latentie voor histogrammetrieken (Prometheus)

Prometheus histogrammen zijn gebundelde tellers; gebruik histogram_quantile() over rate() van de buckets. Prometheus documenteert dit model en de histogram vs summary trade-offs.

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

p99 wachttijd

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

Gemiddelde tijd per token (inter-token latentie)

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

Inter-token latentie wordt vaak beperkt door decode-bottlenecks en geheugenbandbreedte — onderwerpen die uitgebreid worden behandeld in LLM prestatieoptimalisatiegids.

Wachtrijdiepte (instant)

max(tgi_queue_size)

vLLM KV-cachegebruik (instant)

max(vllm:kv_cache_usage_perc)

Grafana dashboards: panels die werkelijk helpen bij on-call

Grafana kan histogrammen visualiseren op verschillende manieren (percentielen, heatmap, bucketverdelingen). Grafana Labs heeft een gedetailleerde gids voor Prometheus histogramvisualisatie.

Een minimale, hoogsignaaldashboardopstelling:

Rij 1 — Gebruikerservaring

1. p95 aanvraaglatentie (tijdreeks)
2. p95 inter-token latentie (tijdreeks)
3. Foutpercentage (tijdreeks + stat)

Rij 2 — Capaciteit en verzadiging

4. Wachtrijgrootte (tijdreeks)
5. Lopende vs wachtende aanvragen (gestapeld)
6. KV-cachegbruik % (gauge)

Rij 3 — Doorvoer

7. Aanvragen/sec
8. Gegenereerde tokens/aanvraag (p50/p95)

Als je streaming gebruikt, voeg een panel toe voor “eerste tokenlatentie” (TTFT) wanneer beschikbaar.

Voorbeeld Grafana queries

• p95 latentiepanel: de histogram_quantile(0.95, …) query hierboven
• heatmappanel: grafiek de bucket-raten (*_bucket) als een heatmap (Grafana ondersteunt deze aanpak)

Implementatieoptie 1: Docker Compose (snel lokaal + single-node)

Als je beslist tussen lokaal, zelfgehost of cloudgebaseerde inferentiearchitecturen, zie de volledige analyse in mijn LLM-hosting vergelijkingsgids.

Maak een map zoals:

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

Als je liever een manuele Grafana installatie prefereert in plaats van Docker, zie mijn stap-voor-stap gids over installeren en gebruiken van Grafana op Ubuntu.

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

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

Dashboard provisioning (grafana/provisioning/dashboards/dashboards.yml)

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

Implementatieoptie 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Als je kube-prometheus-stack (Prometheus Operator) gebruikt, scrape targets via ServiceMonitor.

Voor infrastructuurtrade-offs tussen Kubernetes, single-node Docker en beheerde inferentieproviders, zie mijn LLM-hosting in 2026 gids.

1) Expose je inferentieimplementatie met een Service

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

2) Maak een 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

Herhaal dit voor vLLM en llama.cpp services. Dit schaalt netjes als je replica’s toevoegt.

3) Waarschuwingen: SLO-stijlregels (voorbeeld)

Hier zijn goede startwaarschuwingen:

• Hoog p95 latentie (verbrandingspercentage)
• Wachttijd p99 te hoog (gebruikers wachten)
• Foutpercentage > 1%
• KV-cachegbruik > 90% (capaciteitsklip)

Voorbeeldregel (p95 aanvraagduur):

- 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 latentie > 3s (10m)"

Oplossen van problemen: veelvoorkomende Prometheus + Grafana falen in LLM-stacks

1) Prometheus doel is “DOWN”

Symptomen

• Prometheus UI → Doelen toont DOWN
• “context deadline exceeded” of verbinding geweigerd

Checklist

• Is de server werkelijk /metrics blootstellend?
• Verkeerde poort? Verkeerde schema (http vs https)?
• Kubernetes: is de Service pods selecterend? Is de ServiceMonitor label release correct?

Snel test

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

2) Je kunt metrieken scrapen, maar panels zijn leeg

Meest voorkomende oorzaken

• Fout metrieknaam (serverversie veranderd)
• Dashboard verwacht _bucket maar je hebt alleen een gauge/counter
• Prometheus scrape interval te lang voor korte vensters (bijv. [1m] met 30s scrape kan ruis veroorzaken)

Fix

• Gebruik Grafana Explore om te zoeken op metriekvoorvoegsels (bijv. tgi_ / vllm:)
• Verhoog het bereikvenster van [1m] → [5m]

3) Histogrampercentielen zien er “vlak” of verkeerd uit

Prometheus histogrammen vereisen correcte aggregatie:

• gebruik rate(metric_bucket[5m])
• dan sum by (le) (en optioneel andere stabiele labels)
• dan histogram_quantile()

Prometheus documenteert het bucketmodel en serverzijde quantileberekening.
Grafana’s histogramvisualisatiegids bevat praktische panelpatronen.

4) Cardinaliteit explosie (Prometheus geheugensprongen)

Symptomen

• Prometheus RAM-gebruik stijgt
• “te veel series” fouten

Typische oorzaak

• Je hebt prompt, user_id of aanvraag-ids toegevoegd als labels in een aangepaste exporter.

Fix

• Verwijder hoog-cardinaliteitlabels
• Aggregeer vooraf in laag-cardinaliteitlabels (model, endpoint, status)
• Overweeg logs/traces te gebruiken voor per-aanvraagdebuggen in plaats van labels

5) “We hebben metrieken, maar geen idee waarom het traag is”

Metrieken zijn nodig, maar soms heb je correlatie nodig:

• Voeg gestructureerde logs toe met aanvraagmetadata (model, tokenaantallen, TTFT)
• Voeg tracing (OpenTelemetry) toe rondom je gateway + inferentieserver
• Gebruik exemplars (wanneer ondersteund) om van een latentiesprong naar een trace te springen

Een goede workflow: Grafana dashboard spike -> klik in Explore -> beperk tot instance/model -> controleer logs/traces voor die periode.

Dit volgt het klassieke metrics -> logs -> traces model zoals beschreven in observatie- en monitoringarchitectuur gids.

6) vLLM / multi-process metriek quirks

Als je serving stack draait in meerdere processen, heb je mogelijk Prometheus multi-process configuratie nodig (afhankelijk van hoe het proces metrieken blootstelt). De vLLM documentatie benadrukt het blootstellen van metrieken via /metrics voor Prometheus polling; controleer de servers metriekmodus bij implementatie.

Een praktisch “dag-1” dashboard en waarschuwingenset

Als je een lichte setup wilt die nog steeds werkt in productie, begin met:

Dashboard panels

1. p95 aanvraaglatentie
2. p95 gemiddelde tijd per token
3. wachtrijgrootte
4. p95 wachttijd
5. foutpercentage
6. KV-cachegbruik %

Waarschuwingen

• p95 aanvraaglatentie > X voor 10m
• p99 wachttijd > Y voor 10m
• foutpercentage > 1% voor 5m
• KV-cachegbruik > 90% voor 15m
• Prometheus doel down (altijd)

Gerelateerde observatiegidsen

• Observatiegids: Prometheus, Grafana & productie monitoring
• Prometheus monitoring: setup & best practices
• Installeer en gebruik Grafana op Ubuntu: volledige gids

Gerelateerde LLM-infrastructuurgidsen

• LLM-hosting in 2026: lokaal, zelfgehost & cloud vergeleken
• LLM-prestatie in 2026: benchmarks & optimalisatie

Afsluitende notities

Prometheus + Grafana geeft je de “altijd-actieve” visie op inferentiegezondheid. Zodra je de basis hebt, komen de volgende grote winsten meestal uit:

• SLO’s per model / klant
• aanvraagvorming (max tokens, concurrentielimieten)
• autoscaling gekoppeld aan wachttijd en KV-cachemarge

Voor een breder verklaring van monitoring vs observatie, Prometheus fundamentele kennis en productiepatronen, zie mijn volledige observatiegids.