Vérification post-installation
Vérifiez que le Model Gateway fonctionne correctement après l'installation en validant la santé du service, la connectivité des modèles, les requêtes d'inférence, le comportement de routage et la gestion des erreurs.
Après avoir installé et configuré le Model Inference Gateway, vérifiez que le déploiement fonctionne correctement. Effectuez les tâches de validation suivantes dans l'ordre. Confirmez que chaque étape réussit avant de passer à la suivante.
Vérifier la santé de la passerelle
Vérifiez que le pod du service d'inférence (Inference Service) est en cours d'exécution et que tous les conteneurs sont prêts :
oc get pods -n <bob-namespace> -l app=bob-inferenceConsultez les journaux de démarrage pour suivre l'initialisation de la passerelle. Un démarrage réussi consigne l'enregistrement de chaque modèle configuré. Les erreurs d'analyse des identifiants ou de la configuration apparaissent ici :
oc logs -n <bob-namespace> deploy/bob-inference --since=5mConfirmez que l'endpoint /v1/models de la passerelle répond depuis l'intérieur du cluster — c'est le signal le plus clair indiquant qu'elle est opérationnelle et qu'elle a chargé la configuration :
oc exec -n <bob-namespace> deploy/bob-gateway -- \
curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .Valider la connectivité des modèles
Vérifiez la réponse de /v1/models pour chaque model_name attendu. Un modèle qui n'a pas pu se connecter (URL incorrecte, erreur d'authentification, échec TLS) est absent de la liste ou présent avec un statut d'erreur.
Seuls les modèles avec exposed: true dans model_info apparaissent dans la liste publique /v1/models. Les modèles avec exposed: false (par exemple, le modèle de guardrail) n'apparaissent pas mais doivent tout de même être accessibles en interne. L'absence de la liste n'indique pas systématiquement un échec de connectivité.
Tester l'inférence de modèle
Envoyez une requête de complétion de test minimale directement au service d'inférence depuis l'intérieur du cluster pour le modèle principal et le modèle de guardrail :
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 .Une réponse réussie contient un tableau choices avec un champ message.content.
Erreurs courantes :
| Statut HTTP | Cause |
|---|---|
401 Unauthorized | Identifiants non valides ou autorisations insuffisantes |
404 Not Found | L'ID de modèle spécifié n'existe pas chez le fournisseur |
502 Bad Gateway | L'endpoint de modèle en amont ne peut pas être joint |
Le modèle de guardrail doit être accessible et capable de traiter les requêtes. Si le modèle de guardrail est indisponible, IBM Bob rejette toutes les requêtes d'inférence. Assurez-vous que la validation du guardrail réussit avant de considérer l'installation comme terminée.
Valider le routage des modèles
Confirmez que le modèle principal effectue le routage correctement en vérifiant que le champ model dans la réponse correspond au model_name demandé.
Si des options de secours (fallbacks) sont configurées sur une entrée de modèle, validez le chemin de secours en pointant temporairement l'attribut base_url du modèle principal vers un hôte inaccessible et en confirmant que la passerelle bascule sur le modèle suivant dans la liste. Restaurez le base_url correct après le test.
Pour les modèles avec exposed: false, confirmez que le routage interne les résout correctement même s'ils n'apparaissent pas dans la liste publique des modèles.
Valider la gestion des erreurs
Exécutez les tests négatifs délibérés suivants pour confirmer que la passerelle gère correctement les pannes :
| Test | Comment le déclencher | Comportement attendu |
|---|---|---|
| Clé d'API non valide | Définissez temporairement une mauvaise valeur de clé dans le secret | La passerelle renvoie 401, ne plante pas |
| Endpoint inaccessible | Définissez base_url sur un hôte non valide | La passerelle renvoie 502 ou 503, consigne l'erreur en amont |
| ID de modèle mal formé | Définissez model sur un ID inexistant | Le fournisseur renvoie 404, l'erreur est renvoyée à l'appelant |
| Variable d'environnement de secret manquante | Supprimez une clé de bob.modelGateway.secrets | Échec au moment de la requête avec une erreur journalisée faisant référence à la variable manquante |
| Certificat TLS expiré | Fournissez un certificat expiré en tant que ca_cert_pem | Échec de négociation TLS consigné au moment de la requête |
Collecter les journaux et résoudre les problèmes
Diffusez les journaux en direct lors d'une requête de test pour observer les décisions de routage de la passerelle en temps réel :
oc logs -n <bob-namespace> deploy/bob-inference -fCollectez un dump complet des journaux pour le partager avec le support :
oc logs -n <bob-namespace> deploy/bob-inference --since=1h > bob-inference.logMotifs de journaux clés :
| Motif de journal | Ce que cela signifie |
|---|---|
| Model registered successfully | La passerelle a chargé l'entrée du modèle sans erreur |
connection refused / no route to host | Échec de connectivité vers l'endpoint du modèle |
401 / 403 from upstream | L'identifiant est erroné ou n'a pas les autorisations requises |
certificate signed by unknown authority | Le certificat CA est manquant ou incorrect dans ca_cert_pem |
environment variable not found | Un secret référencé avec env.* ne figure pas dans les secrets montés |
Pour les erreurs au niveau des événements (par exemple, des échecs de montage de secret qui empêchent le conteneur de démarrer) :
oc describe pod -n <bob-namespace> -l app=inference-serviceChanger le modèle d'inférence principal
Pour passer d'un modèle d'inférence principal pris en charge à un autre après l'installation :
S'assurer que le nouveau modèle est déployé
Confirmez que le nouveau modèle est déployé et actif. Voir Infrastructure de service de modèles.
Mettre à jour le fichier de configuration du model gateway
Mettez à jour votre model-gateway.yaml pour faire référence au nouveau modèle. Voir Configuration du Model Gateway.
Appliquer la modification
Appliquez la configuration mise à jour à l'aide de bobctl update-model-config :
bobctl update-model-config --model-config ./my-model-config.yaml --update-secretsVoir Déploiement de la configuration pour la référence complète des drapeaux.