Monitoring und Observability für KI-Workloads
Monitoring für KI-Workloads bedeutet, drei Ebenen gleichzeitig im Blick zu behalten: die GPU-Hardware (Auslastung, VRAM, Temperatur, Fehler), den Inference-Dienst (Latenz, Token-Durchsatz, Warteschlange) und die Anwendung (Qualität, Nutzung, Kosten). Bewährt hat sich ein offener Stack aus NVIDIA DCGM Exporter, Prometheus und Grafana, ergänzt um die Metriken, die Inference-Server wie vLLM selbst bereitstellen.
Warum klassisches Server-Monitoring bei KI-Workloads nicht reicht
CPU, RAM und Festplatte zu überwachen ist auch bei einem KI-Server Pflicht – aber es beantwortet die wichtigen Fragen nicht. Ein LLM-Dienst kann bei 10 Prozent CPU-Last bereits am Limit sein, weil der VRAM voll ist und Anfragen in der Warteschlange stehen. Umgekehrt kann eine GPU „100 Prozent Auslastung“ melden, obwohl die Rechenwerke nur zu einem Bruchteil gefordert sind: Die klassische GPU-Utilization misst nur, ob in einem Zeitraum überhaupt ein Kernel lief, nicht wie effizient.
Hinzu kommt: Nutzer erleben KI nicht als „Server läuft“, sondern als „Antwort kommt schnell und ist brauchbar“. Observability heißt deshalb, Hardware-, Dienst- und Anwendungsmetriken so zu verknüpfen, dass Sie Ursachen finden statt nur Symptome zu sehen.
Ebene 1: GPU-Metriken mit DCGM und Prometheus
Der NVIDIA Data Center GPU Manager (DCGM) liefert detaillierte Hardware-Telemetrie. Der DCGM Exporter stellt sie im Prometheus-Format bereit, Grafana macht sie als Dashboard sichtbar. Die wichtigsten Kennzahlen:
- GPU-Auslastung (z. B.
DCGM_FI_DEV_GPU_UTIL): Grundindikator, ob die GPU arbeitet - Belegter VRAM (
DCGM_FI_DEV_FB_USED): bei vLLM bewusst hoch, weil der KV-Cache vorab reserviert wird – hier ist der Trend wichtiger als der absolute Wert - Temperatur und Leistungsaufnahme (
DCGM_FI_DEV_GPU_TEMP,DCGM_FI_DEV_POWER_USAGE): Hinweise auf Kühlprobleme oder Drosselung - Taktraten und Throttling-Gründe: erklären plötzliche Leistungseinbrüche
- XID-Fehler (
DCGM_FI_DEV_XID_ERRORS): Treiber- oder Hardwarefehler, die oft einem Absturz vorausgehen - ECC-Fehler bei Karten mit ECC-Speicher: frühe Warnzeichen für Speicherdefekte
Für schnelle Diagnosen direkt auf dem Server bleibt nvidia-smi unverzichtbar, ersetzt aber keine historischen Daten.
Ebene 2: Metriken des Inference-Dienstes
Die Kennzahlen, die Nutzer direkt spüren, liefert der Inference-Server. vLLM etwa stellt einen Prometheus-Endpunkt bereit, unter anderem mit:
| Metrik | Bedeutung | Worauf achten |
|---|---|---|
Time to First Token (vllm:time_to_first_token_seconds) |
Zeit bis zum ersten Wort der Antwort | Wichtigster Wert für gefühlte Reaktionszeit |
Inter-Token-Latenz (vllm:inter_token_latency_seconds) |
Abstand zwischen generierten Tokens | Bestimmt die Lesegeschwindigkeit beim Streaming |
End-to-End-Latenz (vllm:e2e_request_latency_seconds) |
Gesamtdauer einer Anfrage | P95 und P99 betrachten, nicht nur den Mittelwert |
Laufende / wartende Anfragen (vllm:num_requests_running, vllm:num_requests_waiting) |
Auslastung und Rückstau | Dauerhafte Warteschlange = Kapazitätsgrenze |
KV-Cache-Auslastung (vllm:kv_cache_usage_perc) |
Anteil des belegten Kontextspeichers | Nahe 100 Prozent führt zu Verdrängung und Wartezeit |
Prompt- und Generierungs-Tokens (vllm:prompt_tokens_total, vllm:generation_tokens_total) |
Verarbeitete Tokenmengen | Basis für Durchsatz- und Kapazitätsplanung |
Die Metriknamen können sich zwischen Versionen ändern; prüfen Sie nach Updates, ob Dashboards und Alerts noch greifen. Hintergründe zu Latenz und Durchsatz beschreibt der Beitrag KI-Inference optimieren.
Für Trainings- und Batch-Jobs sind andere Werte relevant: Laufzeit pro Job, GPU-Auslastung während des Trainings, Verlauf der Loss-Kurve und Checkpoint-Größen.
Ebene 3: Anwendung, Qualität und Nutzung
Technisch gesunde Systeme können trotzdem schlechte Ergebnisse liefern. Auf Anwendungsebene lohnt es sich, zu erfassen:
- Nutzung pro Anwendung oder Team: Anfragen und Tokens pro API-Schlüssel – wichtig für interne Verrechnung und zum Erkennen von Missbrauch
- Fehlerraten: Zeitüberschreitungen, abgebrochene Anfragen, Antworten mit Fehlerstatus
- RAG-Qualität: Anteil der Antworten mit Quellenangabe, Retrieval-Trefferquote, Nutzerbewertungen
- Tracing: Einzelne Anfragen über Gateway, Retrieval, Reranking und Modell hinweg verfolgen, etwa mit OpenTelemetry – so wird sichtbar, ob die Vektorsuche oder das Modell die Zeit verbraucht
Achten Sie dabei auf Datenschutz: Prompts und Antworten können personenbezogene Daten enthalten. Protokollieren Sie Inhalte nur, wenn es einen klaren Zweck gibt, und begrenzen Sie Zugriff und Aufbewahrungsdauer. Mehr dazu im Beitrag Audit-Trail für KI-Systeme.
Alerting: was wirklich wichtig ist
Zu viele Alarme führen dazu, dass keiner mehr ernst genommen wird. Eine bewährte Staffelung – die konkreten Schwellen hängen von Hardware und Anwendung ab:
Kritisch (sofort handeln)
- Modell-Endpunkt nicht erreichbar oder Fehlerquote stark erhöht
- XID-Fehler oder GPU nicht mehr ansprechbar
- GPU-Temperatur dauerhaft nahe dem vom Hersteller angegebenen Limit
Warnung (zeitnah prüfen)
- Warteschlange über längere Zeit nicht leer
- P95-Time-to-First-Token deutlich über dem Zielwert
- KV-Cache dauerhaft nahezu voll
- GPU-Auslastung hoch, obwohl keine Anfragen anliegen – möglicher Hinweis auf Missbrauch
- Festplatte über 80 Prozent belegt, etwa durch Modelldateien oder Logs
Information
- Neue Modellversion ausgerollt, Backup abgeschlossen, Treiber-Update eingespielt
Häufige Fehler
- Nur Mittelwerte betrachten: Ein guter Durchschnitt kann schlechte Ausreißer für einzelne Nutzer verdecken
- Hohen VRAM-Verbrauch als Problem werten, obwohl der Inference-Server ihn bewusst reserviert
- Keine Basislinie: Ohne Normalwerte lassen sich Abweichungen nicht erkennen
- Monitoring auf demselben Server ohne externe Erreichbarkeitsprüfung – fällt der Server aus, schweigt auch das Monitoring
Monitoring bei Verdacloud
Bei unseren Managed KI-Servern ist die Überwachung Teil des Betriebs: Hardware, System und Erreichbarkeit werden kontinuierlich automatisiert überwacht, wir reagieren auf Alarme und kümmern uns um Updates und Backups – mit festem Ansprechpartner. Für Anwendungen wie Secure Cloud RAG kommen dienstspezifische Kennzahlen hinzu. Welche Metriken Sie selbst einsehen und welche Alarme an Ihr Team gehen, stimmen wir mit Ihnen ab; verbindliche Reaktionszeiten regelt ein SLA im Enterprise-Paket. Wie Monitoring zur Sicherheit beiträgt, lesen Sie im Beitrag KI-Server Sicherheit.
Häufige Fragen
Welche Metrik ist für LLM-Anwendungen am wichtigsten?
Ist ein voller VRAM ein Warnsignal?
Brauche ich für KI-Monitoring kommerzielle Tools?
Wie erkenne ich, dass mein GPU-Server zu klein ist?
Verwandte Artikel
vLLM vs. Ollama vs. TGI: Inference-Frameworks für GPU-Server in der Praxis
vLLM, Ollama oder TGI? Stärken, Grenzen und Projektstatus der Inference-Frameworks – plus eine Methodik für aussagekräftige eigene GPU-Benchmarks.
On-Premise vs. Cloud GPU: Was ist die richtige Wahl für Ihr Unternehmen?
On-Premise, Cloud GPU oder Managed Dedicated Server? Kosten, Datenschutz, Betrieb und Flexibilität im Vergleich – Entscheidungshilfe für den Mittelstand.
VRAM-Guide: Wie viel GPU-Speicher braucht Ihr KI-Modell?
Wie viel VRAM braucht ein LLM? Faustregeln für Inference und Training, KV-Cache, Quantisierung und eine Tabelle mit Richtwerten von 7B bis 70B.