Überprüfe, ob der Model Gateway nach der Installation korrekt funktioniert, indem du Service-Gesundheit, Modellkonnektivität, Inferenzanfragen, Routing-Verhalten und Fehlerbehandlung validierst.

Nachdem du den Model Inference Gateway installiert und konfiguriert hast, überprüfe, ob das Deployment korrekt funktioniert. Führe die folgenden Validierungsaufgaben der Reihe nach durch. Bestätige, dass jeder Schritt erfolgreich ist, bevor du mit dem nächsten fortfährst.

Gateway-Gesundheit überprüfen

Prüfe, ob der Inferenz-Service-Pod läuft und alle Container bereit sind:

oc get pods -n <bob-namespace> -l app=bob-inference

Überprüfe die Startlogs auf Gateway-Initialisierung. Ein erfolgreicher Start protokolliert die Registrierung jedes konfigurierten Modells. Anmeldeinformations- oder Konfigurationsfehler werden hier angezeigt:

oc logs -n <bob-namespace> deploy/bob-inference --since=5m

Bestätige, dass der /v1/models-Endpoint des Gateways aus dem Cluster heraus antwortet — dies ist das deutlichste Signal, dass er läuft und die Konfiguration geladen hat:

oc exec -n <bob-namespace> deploy/bob-gateway -- \
  curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .

Modellkonnektivität validieren

Überprüfe die /v1/models-Antwort für jeden erwarteten model_name. Ein Modell, das keine Verbindung herstellen konnte (fehlerhafte URL, Authentifizierungsfehler, TLS-Fehler), fehlt in der Liste oder ist mit einem Fehlerstatus vorhanden.

Hinweis:

Nur Modelle mit exposed: true in model_info erscheinen in der öffentlichen /v1/models-Liste. Modelle mit exposed: false (z. B. das Guardrail-Modell) erscheinen nicht, sollten aber intern weiterhin erreichbar sein. Das Fehlen in der Liste ist nicht immer ein Konnektivitätsfehler.

Modell-Inferenz testen

Sende eine minimale Test-Completion-Anfrage direkt an den Inferenz-Service aus dem Cluster heraus, sowohl für das Core-Modell als auch für das Guardrail-Modell:

oc exec -n <bob-namespace> deploy/bob-gateway -- \
  curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<model_name>",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 10
  }' | jq .

Eine erfolgreiche Antwort enthält ein choices-Array mit einem message.content-Feld.

Häufige Fehler:

HTTP-Status	Ursache
`401 Unauthorized`	Ungültige Anmeldeinformationen oder unzureichende Berechtigungen
`404 Not Found`	Angegebene Modell-ID existiert beim Provider nicht
`502 Bad Gateway`	Upstream-Modell-Endpoint nicht erreichbar

Warnung:

Das Guardrail-Modell muss erreichbar sein und Anfragen verarbeiten können. Wenn das Guardrail-Modell nicht verfügbar ist, lehnt IBM Bob alle Inferenzanfragen ab. Stelle sicher, dass die Guardrail-Validierung erfolgreich ist, bevor du die Installation als abgeschlossen betrachtest.

Modell-Routing validieren

Bestätige, dass das primäre Modell korrekt routed, indem du überprüfst, dass das Feld model in der Antwort mit dem angeforderten model_name übereinstimmt.

Wenn fallbacks für einen Modelleintrag konfiguriert sind, validiere den Fallback-Pfad, indem du vorübergehend die base_url des primären Modells auf einen nicht erreichbaren Host zeigst und bestätigst, dass der Gateway auf das nächste Modell in der Liste zurückfällt. Stelle die korrekte base_url nach dem Test wieder her.

Für Modelle mit exposed: false bestätige, dass das interne Routing sie weiterhin korrekt auflöst, auch wenn sie nicht in der öffentlichen Modellliste erscheinen.

Fehlerbehandlung validieren

Führe die folgenden bewussten Negativtests durch, um zu bestätigen, dass der Gateway Fehler ordnungsgemäß behandelt:

Test	Auslösung	Erwartetes Verhalten
Ungültiger API-Schlüssel	Vorübergehend einen falschen Schlüsselwert im Secret setzen	Gateway gibt `401` zurück, stürzt nicht ab
Nicht erreichbarer Endpoint	`base_url` auf einen ungültigen Host setzen	Gateway gibt `502` oder `503` zurück, protokolliert den Upstream-Fehler
Fehlerhafte Modell-ID	`model` auf eine nicht vorhandene ID setzen	Provider gibt `404` zurück, Fehler wird an den Aufrufer weitergegeben
Fehlende Secret-Umgebungsvariable	Einen Schlüssel aus `bob.modelGateway.secrets` entfernen	Fehler bei der Anfragenverarbeitung mit einem protokollierten Fehler, der auf die fehlende Variable verweist
Abgelaufenes TLS-Zertifikat	Ein abgelaufenes Zertifikat als `ca_cert_pem` bereitstellen	TLS-Handshake-Fehler zur Anfragenzeit protokolliert

Logs sammeln und Probleme beheben

Live-Logs während einer Testanfrage streamen, um Gateway-Routing-Entscheidungen in Echtzeit zu beobachten:

oc logs -n <bob-namespace> deploy/bob-inference -f

Vollständigen Log-Dump für den Support sammeln:

oc logs -n <bob-namespace> deploy/bob-inference --since=1h > bob-inference.log

Wichtige Log-Muster:

Log-Muster	Bedeutung
Model registered successfully	Der Gateway hat den Modelleintrag ohne Fehler geladen
`connection refused` / `no route to host`	Konnektivitätsfehler zum Modell-Endpoint
`401` / `403` vom Upstream	Anmeldeinformationen sind falsch oder haben nicht die erforderlichen Berechtigungen
`certificate signed by unknown authority`	CA-Zertifikat fehlt oder ist falsch in `ca_cert_pem`
`environment variable not found`	Ein mit `env.*` referenziertes Secret ist nicht in den eingehängten Secrets vorhanden

Für Fehler auf Ereignisebene (z. B. Secret-Einhängungs-Fehler, die den Start des Containers verhindern):

oc describe pod -n <bob-namespace> -l app=inference-service

bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

Die vollständige Flag-Referenz findest du unter Konfiguration deployen.

Verifizierung nach der Installation

Gateway-Gesundheit überprüfen

Modellkonnektivität validieren

Modell-Inferenz testen

Modell-Routing validieren

Fehlerbehandlung validieren

Logs sammeln und Probleme beheben

Wechsel des Core-Inferenz-Modells

Sicherstellen, dass das neue Modell deployed ist

Model-Gateway-Konfigurationsdatei aktualisieren

Änderung anwenden

Auf dieser Seite