Verifica que el gateway de modelos funciona correctamente después de la instalación validando el estado del servicio, la conectividad con los modelos, las solicitudes de inferencia, el comportamiento del enrutamiento y el manejo de errores.

Después de instalar y configurar el gateway de inferencia de modelos, verifica que el despliegue funciona correctamente. Completa las siguientes tareas de validación en orden. Confirma que cada paso tiene éxito antes de continuar con el siguiente.

Verificar el estado del gateway

Comprueba que el pod del servicio de inferencia está en ejecución y todos los contenedores están listos:

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

Revisa los logs de inicio para la inicialización del gateway. Un inicio correcto registra cada modelo configurado siendo registrado. Los errores de credenciales o de análisis de configuración aparecen aquí:

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

Confirma que el endpoint /v1/models del gateway responde desde dentro del clúster — esta es la señal más clara de que está activo y ha cargado la configuración:

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

Validar la conectividad con los modelos

Comprueba la respuesta de /v1/models para cada model_name esperado. Un modelo que no ha podido conectarse (URL incorrecta, error de autenticación, fallo TLS) está ausente de la lista o presente con un estado de error.

Nota:

Solo los modelos con exposed: true en model_info aparecen en la lista pública /v1/models. Los modelos con exposed: false (por ejemplo, el modelo guardrail) no aparecen, pero deben seguir siendo accesibles internamente. La ausencia de la lista no siempre indica un fallo de conectividad.

Probar la inferencia de modelos

Envía una solicitud de completado de prueba mínima directamente al servicio de inferencia desde dentro del clúster para el modelo principal y el modelo 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 .

Una respuesta exitosa contiene un array choices con un campo message.content.

Errores comunes:

Estado HTTP	Causa
`401 Unauthorized`	Credenciales inválidas o permisos insuficientes
`404 Not Found`	El ID del modelo especificado no existe en el proveedor
`502 Bad Gateway`	No se puede alcanzar el endpoint del modelo upstream

Advertencia:

El modelo guardrail debe ser accesible y capaz de procesar solicitudes. Si el modelo guardrail no está disponible, IBM Bob rechaza todas las solicitudes de inferencia. Asegúrate de que la validación del guardrail tenga éxito antes de considerar la instalación completa.

Validar el enrutamiento de modelos

Confirma que el modelo principal enruta correctamente comprobando que el campo model en la respuesta coincide con el model_name solicitado.

Si hay fallbacks configurados en alguna entrada de modelo, valida la ruta de fallback apuntando temporalmente la base_url del modelo principal a un host inalcanzable y confirmando que el gateway pasa al siguiente modelo de la lista. Restaura la base_url correcta después de la prueba.

Para los modelos con exposed: false, confirma que el enrutamiento interno los resuelve correctamente aunque no aparezcan en la lista pública de modelos.

Validar el manejo de errores

Ejecuta las siguientes pruebas negativas deliberadas para confirmar que el gateway maneja los fallos correctamente:

Prueba	Cómo activarla	Comportamiento esperado
Clave API inválida	Establece temporalmente un valor de clave incorrecto en el secreto	El gateway devuelve `401`, no se bloquea
Endpoint inalcanzable	Establece `base_url` en un host inválido	El gateway devuelve `502` o `503`, registra el error upstream
ID de modelo malformado	Establece `model` en un ID inexistente	El proveedor devuelve `404`, el error se propaga al llamador
Variable de entorno de secreto faltante	Elimina una clave de `bob.modelGateway.secrets`	Fallo en tiempo de solicitud con un error registrado referenciando la variable faltante
Certificado TLS expirado	Proporciona un certificado expirado como `ca_cert_pem`	Fallo del handshake TLS registrado en tiempo de solicitud

Recopilar logs y resolver problemas

Transmite logs en tiempo real durante una solicitud de prueba para observar las decisiones de enrutamiento del gateway en tiempo real:

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

Recoge un volcado completo de logs para compartir con el soporte:

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

Patrones clave de logs:

Patrón de log	Qué significa
Model registered successfully	El gateway cargó la entrada del modelo sin errores
`connection refused` / `no route to host`	Fallo de conectividad al endpoint del modelo
`401` / `403` from upstream	La credencial es incorrecta o le faltan los permisos requeridos
`certificate signed by unknown authority`	El certificado CA falta o es incorrecto en `ca_cert_pem`
`environment variable not found`	Un secreto referenciado con `env.*` no está en los secretos montados

Para errores a nivel de evento (por ejemplo, fallos de montaje de secretos que impiden el inicio del contenedor):

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

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

Consulta Desplegar la configuración para la referencia completa de flags.

Verificación post-instalación

Verificar el estado del gateway

Validar la conectividad con los modelos

Probar la inferencia de modelos

Validar el enrutamiento de modelos

Validar el manejo de errores

Recopilar logs y resolver problemas

Cambiar el modelo de inferencia principal

Asegurarte de que el nuevo modelo está desplegado

Actualizar el archivo de configuración del gateway de modelos

Aplicar el cambio

En esta página