Ollama mit Prometheus und Grafana überwachen: GPU, VRAM und Tokens/s im Blick

TL;DR

Ollama bringt keinen nativen /metrics-Endpunkt mit. Für vollständige Observability kombinieren Sie einen Ollama-Exporter (Tokens, Latenz, Requests) mit dem NVIDIA DCGM-Exporter (GPU-Auslastung, VRAM, Temperatur). Prometheus scrapt beide, Grafana visualisiert. Aufbauzeit: rund ein halber Arbeitstag pro Server.

Ihr lokaler Ollama-Server läuft, die Modelle antworten — aber woher wissen Sie, ob die GPU zu 40 oder 95 Prozent ausgelastet ist? Ob der VRAM knapp wird, bevor ein Modell abstürzt? Ob die Latenz nachts unter Batch-Last einbricht? Ohne Monitoring raten Sie. Genau das wird teuer, sobald ein Fachbereich sich auf die lokale KI verlässt.

Dieser Artikel zeigt den kompletten Stack: welche Metriken zählen, wie Sie sie exponieren, und wie das Grafana-Dashboard am Ende aussieht. Wenn Sie Ollama noch nicht installiert haben, starten Sie zuerst mit der Ollama-Installationsanleitung für Ubuntu.

Warum Ollama-Monitoring anders funktioniert als App-Monitoring

Ein klassischer Webservice exponiert einen /metrics-Endpunkt, und Prometheus zieht sich die Zahlen. Bei Ollama fehlt genau dieser Endpunkt. Der entsprechende Feature-Request (Issue #3144) ist seit März 2024 offen, mit mehreren offenen Pull Requests, aber ohne stabile Implementierung in der Standard-Auslieferung (Stand Mitte 2026). Verlassen Sie sich nicht darauf, dass ein curl http://localhost:11434/metrics etwas Nützliches liefert.

Die zweite Besonderheit: Die wichtigsten Zahlen für einen LLM-Server sind Hardware-nah. Tokens pro Sekunde, VRAM-Belegung und GPU-Auslastung entstehen tief im NVIDIA-Treiber, nicht in der Ollama-Anwendung. Deshalb brauchen Sie zwei Datenquellen, die Prometheus getrennt scrapt.

Unsere Empfehlung: Trennen Sie beide Ebenen sauber. Ein Exporter für die Ollama-Anwendungsmetriken, der DCGM-Exporter für die GPU. Das ist robuster als jeder All-in-One-Hack, den Sie irgendwann selbst warten müssen.

Diese Metriken sollten Sie überwachen

Nicht jede Zahl ist gleich viel wert. Für einen produktiven Ollama-Server im Mittelstand haben sich diese Metriken als aussagekräftig erwiesen:

Tokens pro Sekunde ist die Zahl, nach der Sie als Erstes gefragt werden. Ollama-Exporter liefern sie meist nicht direkt, sondern als kumulativen Zähler ollama_generated_tokens_total. Die Rate rechnen Sie in PromQL selbst aus — dazu unten mehr.

GPU-Metriken mit dem NVIDIA DCGM-Exporter

Der DCGM-Exporter ist der Standard für GPU-Telemetrie unter Prometheus. Er ist in Go geschrieben, exponiert die Metriken auf Port 9400 unter /metrics und läuft als Container direkt neben Ollama. Der Start ist ein Einzeiler:

# DCGM-Exporter als Container auf der GPU-Node starten
docker run -d --restart unless-stopped \
  --gpus all \
  --net host \
  --cap-add SYS_ADMIN \
  --name dcgm-exporter \
  nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless

Danach prüfen Sie mit curl http://localhost:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL, ob Werte kommen. Wenn der Container mit einem SYS_ADMIN-Fehler stirbt, fehlt meist das --cap-add SYS_ADMIN oder das NVIDIA Container Toolkit ist nicht installiert. Das ist der häufigste Stolperstein.

Welche Felder gesammelt werden, steuern Sie über eine CSV-Datei. Per -f /etc/dcgm-exporter/default-counters.csv oder über die Umgebungsvariable DCGM_EXPORTER_COLLECTORS reduzieren Sie das auf die Metriken aus der Tabelle oben. Weniger Felder bedeuten weniger Kardinalität in Prometheus — bei einem Single-Server-Setup vernachlässigbar, bei mehreren GPU-Nodes relevant.

Für Cluster-Setups mit dem NVIDIA GPU Operator wird der DCGM-Exporter automatisch installiert, aber standardmäßig nicht gescrapt. Sie brauchen einen ServiceMonitor als Prometheus-Custom-Resource. Wie das im Kubernetes-Kontext aussieht, behandeln wir im Guide zu GPU-Clustern mit Kubernetes.

Ollama-Anwendungsmetriken exponieren

Da Ollama selbst nichts liefert, schieben Sie einen kleinen Proxy-Exporter dazwischen. Mehrere Open-Source-Projekte tun das; einer davon exponiert Metriken auf Port 8080 und spricht im Hintergrund mit der Ollama-API auf 11434:

# Ollama-Metrics-Exporter als Proxy vor die Ollama-API setzen
docker run -d --restart unless-stopped \
  --name ollama-metrics \
  -e OLLAMA_HOST=http://ollama:11434 \
  -e PORT=8080 \
  -p 8080:8080 \
  ghcr.io/norskhelsenett/ollama-metrics:latest

Danach liefert http://localhost:8080/metrics unter anderem ollama_generated_tokens_total, ollama_prompt_tokens_total, ollama_request_duration_seconds und ollama_loaded_models.

Ein ehrlicher Hinweis: Diese Community-Exporter sind kein offizielles Ollama-Projekt. Prüfen Sie den Quellcode, bevor Sie ihn in ein KRITIS- oder regulatorisch relevantes Umfeld stellen — ein Proxy vor der Inferenz-API sieht jeden Prompt. Wer tiefere Trace-Level-Observability über einzelne Prompts hinweg braucht (welcher Nutzer, welches Modell, welche Kette), sollte parallel ein Tracing-Tool evaluieren; dazu haben wir den Vergleich zu Langfuse als self-hosted LLM-Monitoring geschrieben.

Prometheus als zentraler Scraper konfigurieren

Prometheus zieht beide Endpunkte in einem definierten Intervall. Die Konfiguration ist übersichtlich — zwei Jobs, ein Scrape-Intervall:

# prometheus.yml — scrapt Ollama-Exporter und DCGM-Exporter
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'dcgm-exporter'
    static_configs:
      - targets: ['192.168.10.20:9400']
        labels:
          host: 'ki-server-01'

  - job_name: 'ollama-metrics'
    static_configs:
      - targets: ['192.168.10.20:8080']
        labels:
          host: 'ki-server-01'

rule_files:
  - 'ollama_alerts.yml'

Ein scrape_interval von 15 Sekunden ist ein guter Startwert. Für Tokens/s-Auflösung in Echtzeit können Sie auf 5 Sekunden gehen, zahlen das aber mit mehr Speicher in der Time-Series-Datenbank. Bei einem einzelnen Server merken Sie den Unterschied kaum; bei zehn GPU-Nodes schon.

Prüfen Sie nach dem Neustart unter http://<server>:9090/targets, ob beide Jobs den Status UP zeigen. Rote Targets bedeuten fast immer eine Firewall-Regel oder eine falsche IP — nicht ein kaputter Exporter.

Die entscheidenden PromQL-Abfragen

Rohdaten sind wertlos ohne die richtigen Abfragen. Diese vier decken 90 Prozent des Alltags ab.

Tokens pro Sekunde über die letzten fünf Minuten:

# Generierungsgeschwindigkeit als Rate des kumulativen Zählers
rate(ollama_generated_tokens_total[5m])

95. Perzentil der Antwortlatenz — aussagekräftiger als der Durchschnitt, weil er die Ausreißer zeigt, über die sich Nutzer beschweren:

histogram_quantile(0.95,
  rate(ollama_request_duration_seconds_bucket[5m]))

VRAM-Auslastung in Prozent, direkt aus den DCGM-Framebuffer-Metriken:

# Belegter VRAM relativ zum Gesamt-VRAM
DCGM_FI_DEV_FB_USED
  / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) * 100

Durchschnittliche GPU-Auslastung pro Host — das schnelle Signal, ob Sie noch Modell-Kapazität haben oder aufrüsten müssen:

avg by (host) (DCGM_FI_DEV_GPU_UTIL)

Das Grafana-Dashboard aufbauen

Grafana verbindet sich mit Prometheus als Datenquelle (URL http://prometheus:9090), danach bauen Sie die Panels. Für einen Ollama-Server hat sich diese Aufteilung bewährt:

• Kopfzeile mit Stat-Panels: aktuelle Tokens/s, GPU-Auslastung, VRAM-Prozent, Anzahl geladener Modelle. Auf einen Blick erkennbar, ob der Server gesund ist.
• Zeitreihe GPU: DCGM_FI_DEV_GPU_UTIL und Temperatur übereinander. Throttling wird sofort sichtbar, wenn die Auslastung einbricht, während die Temperatur die 83-°C-Grenze berührt.
• Zeitreihe VRAM: belegt versus frei als gestapelte Fläche. Der Moment, in dem ein zweites Modell geladen wird, ist als Stufe gut zu sehen.
• Latenz-Panel: p50 und p95 der ollama_request_duration_seconds. Divergieren die Linien, haben Sie ein Tail-Latenz-Problem unter Last.

Für den GPU-Teil müssen Sie nicht bei null anfangen. NVIDIA pflegt ein offizielles DCGM-Exporter-Dashboard (Grafana-Dashboard-ID 12239), das Sie über die Import-Funktion mit der Dashboard-ID direkt laden. Es deckt Auslastung, Speicher, Temperatur und Takt ab. Die Ollama-spezifischen Panels bauen Sie dann obendrauf.

Ein Praxis-Tipp aus eigenen Setups: Legen Sie eine Dashboard-Variable host an, die auf das Label aus der Prometheus-Config zeigt. Sobald Sie den zweiten oder dritten KI-Server dazustellen, filtern Sie per Dropdown statt zehn Dashboards zu pflegen.

Alerting: Wann Sie nachts geweckt werden wollen

Ein Dashboard, auf das niemand schaut, verhindert keinen Ausfall. Zwei Alerts reichen für den Anfang und decken die realistischen Fehlerfälle ab. Die Regeln landen in der ollama_alerts.yml, die Prometheus über rule_files lädt:

# ollama_alerts.yml — VRAM-Knappheit und GPU-Überhitzung
groups:
  - name: ollama_gpu
    rules:
      - alert: VRAMFastVoll
        expr: >
          DCGM_FI_DEV_FB_USED
          / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) > 0.90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'VRAM auf {{ $labels.host }} über 90 Prozent'

      - alert: GPUUeberhitzt
        expr: DCGM_FI_DEV_GPU_TEMP > 85
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'GPU-Temperatur über 85 Grad auf {{ $labels.host }}'

Das for: 5m ist wichtig: Kurze VRAM-Spitzen beim Modell-Laden sind normal und sollen nicht sofort ein Ticket auslösen. Erst wenn die Belegung fünf Minuten am Limit klebt, ist es ein echtes Problem. Wir raten davon ab, jeden Latenz-Ausschlag zu alerten — das erzeugt Alarm-Müdigkeit, und nach zwei Wochen ignoriert Ihr Team die Benachrichtigungen.

Die Zustellung übernimmt der Alertmanager, der an E-Mail, Slack oder Microsoft Teams weiterreicht. Für die meisten Mittelständler reicht ein Teams-Webhook.

Ressourcenbedarf und wo dieser Aufbau an Grenzen stößt

Der Monitoring-Stack selbst ist genügsam. Prometheus, Grafana, Alertmanager und die beiden Exporter laufen problemlos in Docker-Containern auf demselben Server wie Ollama oder auf einer kleinen separaten VM. Der DCGM-Exporter erzeugt vernachlässigbare GPU-Last, weil er nur Treiber-Zähler ausliest, nicht rechnet. Zur Hardware-Dimensionierung des eigentlichen KI-Servers finden Sie Details im Hardware-Guide für GPU-Server.

Was dieser Aufbau nicht leistet: Er zeigt Ihnen keine Prompt-Level-Details — welcher Nutzer welche Anfrage gestellt hat, welches Modell eine Halluzination produziert hat, wie eine Agenten-Kette verlaufen ist. Dafür brauchen Sie Tracing, nicht Metriken. Und er ersetzt kein Kosten-Reporting pro Fachabteilung; das müssen Sie über die Labels und zusätzliche Aggregation selbst bauen.

Häufig gestellte Fragen

Hat Ollama einen eingebauten Prometheus-Endpunkt?

Nein, Stand Mitte 2026 nicht. Der Feature-Request (Ollama-Issue #3144) ist seit März 2024 offen, mit mehreren offenen Pull Requests, aber ohne stabile Auslieferung im Standard-Build. Sie brauchen einen separaten Exporter, der die Ollama-API abfragt und die Metriken im Prometheus-Format bereitstellt.

Wie messe ich Tokens pro Sekunde bei Ollama?

Über den kumulativen Zähler ollama_generated_tokens_total eines Exporters und die PromQL-Abfrage rate(ollama_generated_tokens_total[5m]). Der Zähler zählt nur hoch; die tatsächliche Geschwindigkeit ist immer die Ableitung über ein Zeitfenster, nie der Rohwert.

Brauche ich zwingend den DCGM-Exporter oder reicht nvidia-smi?

Für einen einmaligen Blick reicht nvidia-smi. Für kontinuierliches Monitoring mit Historie, Alerting und Dashboards führt kaum ein Weg am DCGM-Exporter vorbei, weil er die GPU-Metriken sauber im Prometheus-Format auf Port 9400 exponiert. nvidia-smi in einem Cron-Job zu parsen ist fehleranfällig und liefert keine Zeitreihen.

Was kostet dieser Monitoring-Stack?

Prometheus, Grafana, Alertmanager und der DCGM-Exporter sind Open Source und lizenzkostenfrei. Der einzige Aufwand ist die Einrichtung — realistisch ein halber Arbeitstag pro Server für ein IT-Team, das mit Docker vertraut ist. Es entstehen keine laufenden Lizenzgebühren.

Läuft das auch bei mehreren Ollama-Servern?

Ja. Sie fügen jeden Server als weiteres Target in die scrape_configs ein und geben ihm ein eindeutiges host-Label. In Grafana filtern Sie dann über eine Dashboard-Variable. Für Kubernetes-basierte GPU-Cluster übernehmen ServiceMonitor-Ressourcen die automatische Erkennung.

Fazit und nächster Schritt

Ollama-Monitoring ist kein Hexenwerk, aber es besteht aus zwei getrennten Ebenen: Anwendungsmetriken über einen Exporter und GPU-Telemetrie über den DCGM-Exporter, beide von Prometheus gescrapt und in Grafana visualisiert. Der Aufbau kostet einen halben Tag und verhindert danach die stille Klasse von Ausfällen, die Sie sonst erst bemerken, wenn ein Fachbereich anruft.

Wenn Sie Ollama produktiv im Mittelstand einsetzen, richten Sie das Monitoring ein, bevor der erste Fachbereich abhängig davon wird — nicht danach. Starten Sie mit dem DCGM-Exporter und den vier PromQL-Abfragen oben, der Rest baut darauf auf.