Monitoren van LLM-inferentie in productie (2026): Prometheus en Grafana voor vLLM, TGI en llama.cpp

LLM-inferentie lijkt op “nog een API” — totdat de latentie piekt, wachtrijen oplopen en je GPU’s 95% geheugen gebruiken zonder duidelijke verklaring.

Monitoring wordt van cruciaal belang zodra je uitkomt boven een single-node-setup of begint te optimaliseren voor doorvoer. Op dat moment zijn traditionele API-metrics niet genoeg. Je hebt inzicht nodig in tokens, batching-gedrag, wachtrijtijden en KV-cache-belasting: de echte bottlenecks van moderne LLM-systemen.

Dit artikel is onderdeel van mijn bredere gids voor observabiliteit en monitoring, waarin ik de fundamenten van monitoring vs observabiliteit, Prometheus-architectuur en productiebest practices bespreek. Hier focussen we specifiek op het monitoren van LLM-inferentiewerklasten.

(Als je een keuze moet maken voor infrastructuur, zie dan mijn gids voor LLM-hosting in 2026. Als je dieper wilt duiken in batching-mechanica, VRAM-limieten en de afweging tussen doorvoer en latentie, zie dan de LLM-prestatie-engineering gids.)

In tegenstelling tot typische REST-services wordt LLM-servicing bepaald door tokens, continue batching, KV-cache-gebruik, GPU/CPU-verzadiging en wachtrijdynamiek. Twee verzoeken met identieke payload-groottes kunnen radicaal verschillende latentie hebben, afhankelijk van max_new_tokens, concurrentie en cache-hergebruik.

Deze gids is een praktische, productie-gerichte walkthrough voor het bouwen van LLM-inferentiemonitoring met Prometheus en Grafana:

• Wat te meten (p95/p99 latentie, tokens/sec, wachtrijduur, cache-gebruik, foutpercentage)
• Hoe /metrics te scrapen van veelgebruikte servers (vLLM, Hugging Face TGI, llama.cpp)
• PromQL-voorbeelden voor percentielen, verzadiging en doorvoer
• Implementatiepatronen met Docker Compose en Kubernetes
• Problemen oplossen die alleen onder echte belasting verschijnen

De voorbeelden zijn opzettelijk vendor-neutraal. Of je nu later OpenTelemetry-tracing, autoscaling of een service mesh toevoegt, hetzelfde metriekmodel is van toepassing.

Waarom je LLM-inferentie anders moet monitoren

Traditionele API-monitoring (RPS, p95 latentie, foutpercentage) is noodzakelijk maar niet voldoende. LLM-servicing voegt extra dimensies toe:

1) Latentie heeft twee betekenissen

• E2E-latentie: tijd van ontvangen verzoek → teruggeven van laatste token.
• Inter-token latentie: tijd per token tijdens decode (cruciaal voor streaming UX).

Sommige servers tonen beide. Bijvoorbeeld: TGI exposeert duur van verzoeken en gemiddelde tijd per token als histogrammen.

2) Doorvoer is in tokens, niet in verzoeken

Een “snelle” service die 5 tokens teruggeeft, is niet vergelijkbaar met een die 500 tokens teruggeeft. Jouw “RPS” moet vaak “tokens/sec” zijn.

3) De wachtrij is het product

Als je continue batching uitvoert, is de diepte van de wachtrij wat je verkoopt. Het observeren van wachtrijduur en wachtrijgrootte vertelt je of je aan de verwachtingen van gebruikers voldoet.

4) Cache-belasting is een voorteken van uitval

KV-cache-uitputting (of fragmentatie) komt vaak naar voren als plotselinge latentiepieken en time-outs. vLLM exposeert KV-cache-gebruik als een gauge.

Metriekenlijst voor LLM-inferentiemonitoring

Gebruik dit als je noordster. Je hebt niet alles nodig op dag één, maar je zult uiteindelijk het meeste ervan willen.

Gouden signalen (LLM-variant)

• Verkeer: verzoeken/sec, tokens/sec
• Fouten: foutpercentage, time-outs, OOMs, 429s (rate limiting)
• Latentie: p50/p95/p99 verzoekduur; prefill vs decode latentie; inter-token latentie
• Verzadiging: GPU-gebruik, geheugengebruik, KV-cache-gebruik, wachtrijgrootte

Als je low-level inzicht nodig hebt in GPU-geheugengebruik, temperatuur en gebruik buiten Prometheus om (voor debugging of single-node setups), zie dan mijn gids voor GPU-monitoringtoepassingen in Linux / Ubuntu.

Voor een breder overzicht van LLM-observabiliteit buiten metrics om — inclusief tracing, gestructureerde logs, synthetisch testen, GPU-profileren en SLO-ontwerp — zie dan mijn diepgaande gids over observabiliteit voor LLM-systemen.

Nuttige dimensies (labels)

Houd label-cardinaliteit laag. Goede labels:

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

Vermijd labels zoals:

• ruwe prompt, ruwe user_id, verzoek-IDs — deze doen het aantal series explosief groeien.

Metrics blootstellen: ingebouwde /metrics-endpoints (vLLM, TGI, llama.cpp)

De eenvoudigste weg is: gebruik de metrics die de server al exposeert.

vLLM: Prometheus-compatibel /metrics

vLLM exposeert een Prometheus-compatibel /metrics-endpoint (via zijn Prometheus-metrics logger) en publiceert server-/verzoekmetrics met het voorvoegsel vllm:, inclusief gauges zoals lopende verzoeken en KV-cache-gebruik.

Voor container-setup, OpenAI-compatibel serveren en runtime-tuning gericht op doorvoer, zie vLLM Quickstart: High-Performance LLM Serving.

Voorbeeldmetrics die je doorgaans ziet:

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

Hugging Face TGI: /metrics met wachtrij + verzoekhistogrammen

TGI exposeert vele productie-georiënteerde metrics op /metrics, inclusief wachtrijgrootte, verzoekduur, wachtrijduur en gemiddelde tijd per token.

Opmerkelijke:

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

Operationele setup—Docker, GPU’s, launch-flags en de failures die verschijnen als lege of misleidende scrapes—wordt behandeld in TGI - Text Generation Inference - Install, Config, Troubleshoot.

llama.cpp server: metrics-endpoint inschakelen

De llama.cpp-server ondersteunt een Prometheus-compatibel metrics-endpoint dat moet worden ingeschakeld met een flag (bijv. --metrics).

Voor installatiepaden, belangrijke runtime-flags en OpenAI-compatibel servergebruik, zie llama.cpp Quickstart met CLI en Server.

Als je llama.cpp draagt achter een proxy, scrape de server dan direct waar mogelijk (om proxy-level latentie te vermijden die het echte inferentiegedrag verbergt).

Prometheus-configuratie: je inferentieservers scrapen

Dit voorbeeld neemt aan:

• 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 in Prometheus of een diepere uitleg wilt over scrape-configs, exporters, relabeling en alerting-regels, zie dan mijn volledige Prometheus-monitoring setup gids.

Pro-tip: voeg een “service label” toe

Als je meerdere modellen/replicas draait, voeg relabeling toe om een stabiel service-label voor dashboards in te sluiten.

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

PromQL-voorbeelden die je kunt kopiëren/plakken

Verzoeksnelheid (RPS)

sum(rate(tgi_request_count[5m]))

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

Foutpercentage (%)

Als je *_success-tellers hebt, bereken dan de faalratio:

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

p95 latentie voor histogrammetrics (Prometheus)

Prometheus-histogrammen zijn gebuckette tellingen; gebruik histogram_quantile() over rate() van de buckets. Prometheus documenteert dit model en de histogram vs. summary afwegingen.

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

p99 wachtrijtijd

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 in detail worden behandeld in LLM-prestatieoptimalisatiegids.

Wachtrijdiepte (instant)

max(tgi_queue_size)

vLLM KV-cache-gebruik (instant)

max(vllm:kv_cache_usage_perc)

Grafana-dashboards: panelen die echt helpen bij on-call

Grafana kan histogrammen op meerdere manieren visualiseren (percentielen, heatmaps, bucket-verdelingen). Grafana Labs heeft een gedetailleerde gids voor Prometheus-histogramvisualisatie.

Een minimaal, hoog-signaal dashboard-layout:

Rij 1 — Gebruikerservaring

1. p95 verzoeklatentie (tijdserie)
2. p95 inter-token latentie (tijdserie)
3. Foutpercentage (tijdserie + stat)

Rij 2 — Capaciteit en verzadiging

4. Wachtrijgrootte (tijdserie)
5. Lopende vs wachtende verzoeken (gestapeld)
6. KV-cache-gebruik % (gauge)

Rij 3 — Doorvoer

7. Verzoeken/sec
8. Genereerde tokens/verzoek (p50/p95)

Als je streaming hebt, voeg dan een paneel toe voor “eerste token latentie” (TTFT) indien beschikbaar.

Voorbeeld Grafana-query’s

• p95 latentie paneel: de histogram_quantile(0.95, …) query hierboven
• heatmap paneel: plot de bucket-rates (*_bucket) als een heatmap (Grafana ondersteunt deze aanpak)

Implementatieoptie 1: Docker Compose (snelle lokale + single-node)

Als je moet kiezen tussen lokale, self-hosted of cloud-based inferentie-architecturen, zie dan de volledige analyse in mijn LLM-hosting vergelijkingsgids.

Maak een map aan 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 handmatige Grafana-installatie kiest in plaats van Docker, zie dan mijn stap-voor-stap gids over Grafana installeren en gebruiken 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 infrastructuur-afwegingen tussen Kubernetes, single-node Docker en beheerde inferentieproviders, zie dan mijn LLM-hosting in 2026 gids.

1) Exposeer je inferentie-deploy 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 aan

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 schaalbaar schoon op als je replicas toevoegt.

3) Alerting: SLO-stijl regels (voorbeeld)

Hier zijn goede startalerts:

• Hoge p95 latentie (burn rate)
• Wachtrijtijd p99 te hoog (gebruikers wachten)
• Foutpercentage > 1%
• KV-cache-gebruik > 90% aanhoudend (capaciteitstekort)

Voorbeeldregel (p95 verzoekduur):

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

Probleemoplossing: veelvoorkomende Prometheus + Grafana-fouten in LLM-stacks

1) Prometheus target is “DOWN”

Symptomen

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

Controlelijst

• Exposeert de server daadwerkelijk /metrics?
• Fout poort? Fout schema (http vs https)?
• Kubernetes: selecteert de Service de pods? Is het ServiceMonitor-label release correct?

Snel test

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

2) Je kunt metrics scrapen, maar panelen zijn leeg

Meest voorkomende oorzaken

• Fout metrieknaam (serverversie is 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 ruisig zijn)

Oplossing

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

3) Histogrampercentielen lijken “vlak” of onjuist

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 server-side kwantiele berekening.
Grafana’s histogramvisualisatiegids bevat praktische paneelpatronen.

4) Cardinaliteit-explosie (Prometheus geheugenspieken)

Symptomen

• Prometheus RAM-gebruik stijgt
• “too many series” fouten

Typische oorzaak

• Je hebt prompt, user_id of verzoek-IDs als labels toegevoegd in een custom exporter.

Oplossing

• Verwijder labels met hoge cardinaliteit
• Aggregeren van tevoren naar labels met lage cardinaliteit (model, endpoint, status)
• Overweeg logs/traces voor per-verzoek debugging in plaats van labels

5) “We hebben metrics, maar geen idee waarom het langzaam is”

Metrics zijn noodzakelijk, maar soms heb je correlatie nodig:

• Voeg gestructureerde logs toe met verzoekmetadata (model, tokenaantallen, TTFT)
• Voeg tracing (OpenTelemetry) toe rondom je gateway + inferentieserver
• Gebruik exemplaren (indien ondersteund) om van een latentiepiek naar een trace te springen

Een goede workflow: Grafana-dashboardspiek -> klik naar Explore -> verfijnen op instance/model -> check logs/traces voor die periode.

Dit volgt het klassieke metrics -> logs -> traces model zoals beschreven in observabiliteit en monitoring architectuur gids.

6) vLLM / multi-proces metrieke eigenschappen

Als je stack draait in meerdere processen, heb je mogelijk Prometheus multi-proces configuratie nodig (afhankelijk van hoe het proces metrics exposeert). De vLLM-docs benadrukken het exposure van metrics via /metrics voor Prometheus polling; controleer de metrics-mode van de server bij implementatie.

Een praktische “dag-1” dashboard- en alertset

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

Dashboard panelen

1. p95 verzoeklatentie
2. p95 gemiddelde tijd per token
3. wachtrijgrootte
4. p95 wachtrijduur
5. foutpercentage
6. KV-cache-gebruik %

Alerts

• p95 verzoeklatentie > X voor 10m
• p99 wachtrijduur > Y voor 10m
• foutpercentage > 1% voor 5m
• KV-cache-gebruik > 90% voor 15m
• Prometheus target down (altijd)

Gerelateerde Observabiliteit Gidsen

• Observabiliteit Gids: Prometheus, Grafana & Productie Monitoring
• Prometheus Monitoring: Setup & Best Practices
• Grafana Installeren en Gebruiken op Ubuntu: Complete Gids

Gerelateerde LLM Infrastructuur Gidsen

• LLM Hosting in 2026: Lokaal, Self-Hosted & Cloud Vergelijken
• LLM Prestatie in 2026: Benchmarks & Optimalisatie

Afsluitende opmerkingen

Prometheus + Grafana geeft je het “always-on” overzicht van inferentiezakelijkheid. Zodra je de basis hebt, komen de volgende grote winsten meestal voort uit:

• SLO’s per model / tenant
• verzoekvorming (max tokens, concurrentielimieten)
• autoscaling gekoppeld aan wachtrijduur en KV-cache headroom

Voor een bredere uitleg over monitoring vs observabiliteit, Prometheus-fundamenten en productiepatronen, zie dan mijn complete observabiliteit gids.