Monitoring für Inferenz-Server
Ein laufender Prozess heißt nicht, dass Ihr Modell antwortet. PeakNode prüft den Endpunkt wie ein Client: Statuscode, Antwortzeit und ob die Antwort das erwartete Modell nennt. Fällt der Dienst aus oder wurde das Modell entladen, werden Sie benachrichtigt.
Inferenz-Server-Monitoring heißt: Der Endpunkt wird in festen Abständen aufgerufen, und die Antwort muss drei Bedingungen erfüllen. Der Statuscode stimmt, die Antwort kommt innerhalb des Timeouts, und der Text enthält den Namen des Modells, das geladen sein soll. Ein einfacher Prozess-Check reicht nicht, weil die Health-Route von vLLM nur meldet, dass der Server läuft, nicht ob ein Modell geladen ist.
- Uptime-Monitor: HTTP-Aufruf mit Methode, Headern, Basic Auth, erwartetem Statuscode und erwartetem Text in der Antwort.
- Heartbeat: Für Endpunkte im internen Netz meldet sich ein Cron-Skript auf dem Server bei PeakNode, bleibt die Meldung aus, gibt es Alarm.
- Server-Agent: GPU-Speicher und Auslastung je Karte zeigen, ob die Gewichte geladen sind und ob Anfragen ankommen (siehe GPU-Server-Monitoring).
| Dienst | Aufruf | Erwartung | Intervall | Timeout |
|---|---|---|---|---|
| vLLM, OpenAI-kompatibel | GET /v1/models | Status 200, Antwort enthält "id":"meta-llama/Llama-3.1-70B-Instruct" | 1 Minute | 10 s |
| Ollama | GET /api/tags | Status 200, Antwort enthält "name":"llama3.1:70b" | 5 Minuten | 5 s |
| Triton Inference Server | GET /v2/models/resnet50/ready | Status 200 | 1 Minute | 5 s |
| Text Generation Inference | GET /info | Status 200, Antwort enthält "model_id":"mistralai/Mistral-7B-Instruct-v0.3" | 3 Minuten | 10 s |
| Nächtlicher Evaluierungslauf | Heartbeat nach erfolgreichem Lauf | Meldung alle 24 Stunden, Karenz 2 Stunden | - | - |
Was PeakNode für den Inferenz-Betrieb löst
Ein Modell, das still entladen wurde, fällt erst auf, wenn die erste Anfrage des Tages scheitert. Mit einer Prüfung pro Minute wissen Sie es vorher.
Prüfung auf Inhalt, nicht nur Erreichbarkeit
Der Uptime-Monitor vergleicht die Antwort mit einem erwarteten Text. Fehlt der Modellname in /v1/models oder /api/tags, ist die Prüfung fehlgeschlagen, auch wenn der Server mit 200 antwortet.
Antwortzeit je Prüfung
Jede Prüfung speichert die Antwortzeit. Steigt sie über Tage, sehen Sie es im Verlauf, bevor Nutzer sich beschweren. Timeouts von 1 bis 25 Sekunden sind wählbar.
Authentifizierte Endpunkte
Eigene Request-Header (zum Beispiel Authorization: Bearer …), Basic Auth, HTTP-Methode und Request-Body lassen sich je Monitor festlegen. Auch ein POST auf /v1/chat/completions mit kleinem Prompt ist möglich.
Heartbeats für Jobs und interne Dienste
Evaluierungen, Index-Läufe, Batch-Inferenz: Das Skript ruft am Ende eine Heartbeat-URL auf. Bleibt der Aufruf im erwarteten Intervall plus Karenzzeit aus, werden Sie benachrichtigt.
GPU-Sicht auf den Inferenz-Knoten
Der Server-Agent meldet Speicher und Auslastung je GPU. Belegter Speicher zeigt, dass die Gewichte geladen sind. Eine Karte unter 5 % Auslastung über längere Zeit bedeutet: geladen, aber keine Anfragen.
Ihre Kanäle
Benachrichtigungen per E-Mail, Microsoft Teams, Slack, Discord, Telegram, Google Chat, WhatsApp, SMS, Anruf, ntfy, Push oder Webhook. Entwarnung automatisch, wenn die Prüfung wieder gelingt.
Welche Route Sie je Server prüfen sollten
Die Health-Routen der Inferenz-Server unterscheiden sich darin, ob sie das geladene Modell berücksichtigen. Die Tabelle nennt die Route, die im Uptime-Monitor sinnvoll ist, und den Text, auf den Sie prüfen.
| Server | Route | Was sie aussagt | Prüfung im Monitor |
|---|---|---|---|
| vLLM (OpenAI-kompatibler Server) | GET /health und GET /v1/models | /health meldet nur, dass der Prozess läuft. /v1/models listet die geladenen Modelle mit id. | Status 200 auf /v1/models, Antwort enthält den Modellnamen |
| Ollama | GET /api/tags und GET /api/ps | /api/tags listet installierte Modelle, /api/ps die aktuell geladenen. Ollama entlädt Modelle nach Leerlauf, das ist normales Verhalten. | Status 200 auf /api/tags, Antwort enthält den Modellnamen. /api/ps nur prüfen, wenn das Modell dauerhaft geladen bleiben soll (keep_alive) |
| NVIDIA Triton Inference Server | GET /v2/health/ready, GET /v2/models/<name>/ready | Ready antwortet erst mit 200, wenn der Server bereit ist. Die Modellroute meldet die Bereitschaft eines einzelnen Modells. | Status 200 auf der Modellroute |
| Text Generation Inference (TGI) | GET /health und GET /info | /info liefert unter anderem model_id des geladenen Modells. | Status 200 auf /info, Antwort enthält die erwartete model_id |
| llama.cpp (llama-server) | GET /health | Antwortet während des Ladens mit 503 und erst danach mit 200. | Status 200 |
| Beliebiger OpenAI-kompatibler Endpunkt | POST /v1/chat/completions | Eine echte Mini-Anfrage zeigt, dass Inferenz tatsächlich läuft, nicht nur das Listing. | POST mit kleinem Prompt im Request-Body, Status 200, Antwort enthält "finish_reason" |
Routen laut den Dokumentationen der Projekte, Stand Oktober 2026. Der Uptime-Monitor prüft den erwarteten Text als Teilstring der Antwort. Prüfstandorte: Frankfurt und New York. Intervalle von 1 Minute bis 1 Tag, Timeouts von 1 bis 25 Sekunden.
Wenn der Inferenz-Server nicht aus dem Internet erreichbar ist
Die Uptime-Monitore der Cloud-Version prüfen nur öffentliche Ziele. Private Adressen wie 10.x oder 192.168.x werden aus Sicherheitsgründen abgelehnt. Für interne Dienste gibt es drei Wege.
| Weg | So funktioniert es | Geeignet für |
|---|---|---|
| Reverse Proxy mit Zugangsschutz | Der Endpunkt wird über einen Proxy mit Basic Auth oder Token-Header erreichbar gemacht, der Monitor sendet die Zugangsdaten mit. | Endpunkte, die ohnehin für externe Clients oder Partner erreichbar sein sollen |
| Heartbeat von innen | Ein Cron-Skript auf dem Server oder im Netz ruft den Endpunkt lokal auf und meldet sich nur bei Erfolg an der Heartbeat-URL. Bleibt die Meldung aus, alarmiert PeakNode. | Rein interne Dienste, keine eingehende Verbindung nötig |
| PeakNode On-Premise | Die Plattform läuft in Ihrem Netz und prüft interne Adressen direkt, inklusive Statusseiten im Intranet. | Unternehmen mit mehreren internen Diensten und eigener Datenhaltung |
Der Server-Agent für GPU-Werte ist davon nicht betroffen: Er sendet von innen nach außen und braucht keine eingehende Verbindung.
Einrichtung in drei Schritten
Für einen öffentlich erreichbaren Endpunkt dauert die Einrichtung etwa zwei Minuten.
Uptime-Monitor anlegen
Registrieren, „Uptime-Monitoring" öffnen, Typ Website, die URL der Modellroute eintragen, zum Beispiel https://inference.example.com/v1/models, Intervall und Timeout wählen.
Erwartung festlegen
Unter den erweiterten Einstellungen den erwarteten Statuscode 200 und im Feld Response-Body den Modellnamen eintragen. Bei geschützten Endpunkten den Authorization-Header ergänzen.
Response-Body enthält: "id":"meta-llama/Llama-3.1-70B-Instruct"
Kanäle wählen, Heartbeat ergänzen
Festlegen, wohin Alarme gehen. Für Batch-Jobs einen Heartbeat anlegen und die URL am Ende des Jobs aufrufen. Monitore und Heartbeats lassen sich auf einer Statusseite für Ihr Team veröffentlichen.
curl -fsS https://peaknode.de/webhook-heartbeat/ >/dev/null Häufige Fragen
/health antwortet mit 200, sobald der Serverprozess läuft. Ob ein Modell geladen ist, sagt sie nicht. Erst /v1/models listet die geladenen Modelle. Deshalb prüft PeakNode diese Route und den Modellnamen in der Antwort./api/tags auf das installierte Modell. Soll das Modell dauerhaft geladen bleiben, setzen Sie keep_alive entsprechend und prüfen zusätzlich /api/ps./v1/chat/completions prüft, dass die Inferenz tatsächlich antwortet. Beachten Sie, dass jede Prüfung Rechenzeit auf der GPU kostet, ein Intervall von 5 oder 10 Minuten ist hier meist sinnvoller als 1 Minute.Was es kostet
Jeder Endpunkt ist ein Uptime-Monitor, jeder Job ein Heartbeat, jeder Inferenz-Knoten mit Agent ein Server-Monitor. Die Benachrichtigungskanäle sind in allen Tarifen enthalten.
- Server-Monitore (Knoten)3
- Uptime-Monitore5
- Heartbeats5
- Statusseiten1
- Eigene Domains für Statusseiten0
- Teammitglieder0
- Vorhaltezeit der Messwerte14 Tage
- API-Zugangnein
- Server-Monitore (Knoten)10
- Uptime-Monitore50
- Heartbeats50
- Statusseiten5
- Eigene Domains für Statusseiten1
- Teammitglieder5
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
- Server-Monitore (Knoten)50
- Uptime-Monitore250
- Heartbeats250
- Statusseiten25
- Eigene Domains für Statusseiten5
- Teammitgliederunbegrenzt
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
Alle Details, Zahlungsintervalle und der On-Premise-Betrieb stehen unter Tarife.
PeakNode für Ihren Anwendungsfall
Den ersten Endpunkt in zwei Minuten überwachen
Konto anlegen, Modellroute eintragen, erwarteten Modellnamen festlegen.
Jetzt starten