Verificação pós-instalação
Verifique se o Model Gateway está funcionando corretamente após a instalação, validando a integridade do serviço, a conectividade do modelo, as solicitações de inferência, o comportamento de roteamento e o tratamento de erros.
Após instalar e configurar o Model Inference Gateway, verifique se a implantação está funcionando corretamente. Conclua as tarefas de validação a seguir em ordem. Confirme que cada etapa é concluída com sucesso antes de prosseguir para a próxima.
Verificar a integridade do gateway
Verifique se o pod do Inference Service está em execução e todos os containers estão prontos:
oc get pods -n <bob-namespace> -l app=bob-inferenceVerifique os logs de inicialização para a inicialização do gateway. Uma inicialização bem-sucedida registra cada modelo configurado sendo registrado. Erros de análise de credenciais ou configuração aparecem aqui:
oc logs -n <bob-namespace> deploy/bob-inference --since=5mConfirme que o endpoint /v1/models do gateway está respondendo de dentro do cluster — este é o sinal mais claro de que está ativo e carregou a configuração:
oc exec -n <bob-namespace> deploy/bob-gateway -- \
curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .Validar a conectividade do modelo
Verifique a resposta /v1/models para cada model_name esperado. Um modelo que falhou ao conectar (URL inválida, erro de autenticação, falha TLS) está ausente da lista ou presente com status de erro.
Apenas modelos com exposed: true em model_info aparecem na lista pública /v1/models. Modelos com exposed: false (por exemplo, o modelo guardrail) não aparecem, mas ainda devem ser acessíveis internamente. A ausência da lista nem sempre indica uma falha de conectividade.
Testar a inferência do modelo
Envie uma solicitação de conclusão de teste mínima diretamente para o Inference Service de dentro do cluster para o modelo principal e o 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 .Uma resposta bem-sucedida contém um array choices com um campo message.content.
Erros comuns:
| Status HTTP | Causa |
|---|---|
401 Unauthorized | Credenciais inválidas ou permissões insuficientes |
404 Not Found | O ID do modelo especificado não existe no provedor |
502 Bad Gateway | O endpoint do modelo upstream não pode ser acessado |
O modelo guardrail deve estar acessível e capaz de processar solicitações. Se o modelo guardrail estiver indisponível, o IBM Bob rejeita todas as solicitações de inferência. Certifique-se de que a validação do guardrail seja concluída com sucesso antes de considerar a instalação completa.
Validar o roteamento do modelo
Confirme se o modelo principal está roteando corretamente verificando se o campo model na resposta corresponde ao model_name solicitado.
Se fallbacks estiverem configurados em qualquer entrada de modelo, valide o caminho de fallback apontando temporariamente o base_url do modelo principal para um host inacessível e confirmando que o gateway faz fallback para o próximo modelo na lista. Restaure o base_url correto após os testes.
Para modelos com exposed: false, confirme se o roteamento interno ainda os resolve corretamente mesmo que não apareçam na lista pública de modelos.
Validar o tratamento de erros
Execute os seguintes testes negativos deliberados para confirmar que o gateway lida com falhas de forma graciosa:
| Teste | Como acionar | Comportamento esperado |
|---|---|---|
| Chave de API inválida | Defina temporariamente um valor de chave incorreto no secret | Gateway retorna 401, não falha |
| Endpoint inacessível | Defina base_url para um host inválido | Gateway retorna 502 ou 503, registra o erro upstream |
| ID de modelo malformado | Defina model para um ID inexistente | Provedor retorna 404, erro é exibido ao chamador |
| Variável de ambiente de secret ausente | Remova uma chave de bob.modelGateway.secrets | Falha em tempo de solicitação com um erro registrado referenciando a var ausente |
| Certificado TLS expirado | Forneça um certificado expirado como ca_cert_pem | Falha no handshake TLS registrada em tempo de solicitação |
Coletar logs e solucionar problemas
Transmita logs ao vivo durante uma solicitação de teste para observar as decisões de roteamento do gateway em tempo real:
oc logs -n <bob-namespace> deploy/bob-inference -fColete um dump completo de logs para compartilhar com o suporte:
oc logs -n <bob-namespace> deploy/bob-inference --since=1h > bob-inference.logPadrões de log principais:
| Padrão de log | O que significa |
|---|---|
| Model registered successfully | O gateway carregou a entrada do modelo sem erros |
connection refused / no route to host | Falha de conectividade com o endpoint do modelo |
401 / 403 from upstream | A credencial está incorreta ou sem as permissões necessárias |
certificate signed by unknown authority | Certificado CA ausente ou incorreto em ca_cert_pem |
environment variable not found | Um secret referenciado com env.* não está nos secrets montados |
Para erros a nível de evento (por exemplo, falhas de montagem de secret que impedem o container de iniciar):
oc describe pod -n <bob-namespace> -l app=inference-serviceTrocando o modelo de inferência principal
Para trocar de um modelo de inferência principal suportado para outro após a instalação:
Garantir que o novo modelo está implantado
Confirme que o novo modelo está implantado e em serviço. Consulte Infraestrutura de serviço de modelo.
Atualizar o arquivo de configuração do model gateway
Atualize seu model-gateway.yaml para referenciar o novo modelo. Consulte Configurando o Model Gateway.
Aplicar a mudança
Aplique a configuração atualizada usando bobctl update-model-config:
bobctl update-model-config --model-config ./my-model-config.yaml --update-secretsConsulte Implantando a configuração para a referência completa de flags.