Weryfikacja po instalacji
Sprawdź, czy brama modelu działa poprawnie po instalacji, weryfikując kondycję usługi, łączność z modelami, żądania wnioskowania, zachowanie routingu i obsługę błędów.
Po zainstalowaniu i skonfigurowaniu bramy wnioskowania modelu sprawdź, czy wdrożenie działa poprawnie. Wykonaj poniższe zadania weryfikacyjne w podanej kolejności. Przed przejściem do następnego potwierdź, że każdy krok zakończył się sukcesem.
Sprawdzenie kondycji bramy
Sprawdź, czy pod usługi wnioskowania działa i czy wszystkie kontenery są gotowe:
oc get pods -n <bob-namespace> -l app=bob-inferenceSprawdź dzienniki startowe pod kątem inicjalizacji bramy. Pomyślne uruchomienie rejestruje każdy skonfigurowany model podczas rejestracji. Błędy danych uwierzytelniających lub parsowania konfiguracji pojawiają się tutaj:
oc logs -n <bob-namespace> deploy/bob-inference --since=5mPotwierdź, że punkt końcowy /v1/models bramy odpowiada z wnętrza klastra — to najwyraźniejszy sygnał, że brama działa i załadowała konfigurację:
oc exec -n <bob-namespace> deploy/bob-gateway -- \
curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .Weryfikacja łączności z modelami
Sprawdź odpowiedź /v1/models dla każdej oczekiwanej wartości model_name. Model, który nie nawiązał połączenia (zły URL, błąd uwierzytelniania, awaria TLS), jest nieobecny na liście lub obecny ze statusem błędu.
Na publicznej liście /v1/models pojawiają się tylko modele z exposed: true w model_info. Modele z exposed: false (na przykład model guardrail) nie pojawiają się, ale powinny być nadal wewnętrznie dostępne. Nieobecność na liście nie zawsze oznacza awarię łączności.
Testowanie wnioskowania modelu
Wyślij minimalne testowe żądanie uzupełnienia bezpośrednio do usługi wnioskowania z wnętrza klastra zarówno dla głównego modelu, jak i modelu 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 .Pomyślna odpowiedź zawiera tablicę choices z polem message.content.
Typowe błędy:
| Status HTTP | Przyczyna |
|---|---|
401 Unauthorized | Nieprawidłowe dane uwierzytelniające lub niewystarczające uprawnienia |
404 Not Found | Podane ID modelu nie istnieje u dostawcy |
502 Bad Gateway | Nie można osiągnąć nadrzędnego punktu końcowego modelu |
Model guardrail musi być dostępny i zdolny do przetwarzania żądań. Jeśli model guardrail jest niedostępny, IBM Bob odrzuca wszystkie żądania wnioskowania. Upewnij się, że weryfikacja guardrail zakończyła się sukcesem przed uznaniem instalacji za kompletną.
Weryfikacja routingu modelu
Potwierdź, że główny model jest prawidłowo routowany, sprawdzając, czy pole model w odpowiedzi odpowiada żądanemu model_name.
Jeśli w jakimkolwiek wpisie modelu skonfigurowano fallbacks, sprawdź ścieżkę awaryjną, tymczasowo kierując base_url głównego modelu na niedostępny host i potwierdzając, że brama przełącza się na następny model na liście. Przywróć prawidłowy base_url po testowaniu.
W przypadku modeli z exposed: false potwierdź, że routing wewnętrzny nadal je prawidłowo rozwiązuje, nawet jeśli nie pojawiają się na publicznej liście modeli.
Weryfikacja obsługi błędów
Uruchom następujące celowe negatywne testy, aby potwierdzić, że brama elegancko obsługuje awarie:
| Test | Jak wywołać | Oczekiwane zachowanie |
|---|---|---|
| Nieprawidłowy klucz API | Tymczasowo ustaw błędną wartość klucza w sekrecie | Brama zwraca 401, nie ulega awarii |
| Niedostępny punkt końcowy | Ustaw base_url na nieprawidłowy host | Brama zwraca 502 lub 503, rejestruje błąd nadrzędny |
| Nieprawidłowe ID modelu | Ustaw model na nieistniejące ID | Dostawca zwraca 404, błąd jest przekazywany do wywołującego |
| Brakująca zmienna środowiskowa sekretu | Usuń klucz z bob.modelGateway.secrets | Awaria w czasie żądania z zalogowanym błędem odwołującym się do brakującej zmiennej |
| Wygasły certyfikat TLS | Dostarcz wygasły certyfikat jako ca_cert_pem | Awaria uzgadniania TLS rejestrowana w czasie żądania |
Zbieranie dzienników i rozwiązywanie problemów
Strumieniuj dzienniki na żywo podczas testowego żądania, aby obserwować decyzje routingu bramy w czasie rzeczywistym:
oc logs -n <bob-namespace> deploy/bob-inference -fZbierz pełny zrzut dzienników do udostępnienia w ramach wsparcia:
oc logs -n <bob-namespace> deploy/bob-inference --since=1h > bob-inference.logKluczowe wzorce dzienników:
| Wzorzec dziennika | Znaczenie |
|---|---|
| Model registered successfully | Brama załadowała wpis modelu bez błędów |
connection refused / no route to host | Awaria łączności z punktem końcowym modelu |
401 / 403 od nadrzędnego | Dane uwierzytelniające są błędne lub brakuje wymaganych uprawnień |
certificate signed by unknown authority | Certyfikat CA jest brakujący lub nieprawidłowy w ca_cert_pem |
environment variable not found | Sekret odwoływany przez env.* nie jest w montowanych sekretach |
Dla błędów na poziomie zdarzeń (na przykład awarie montowania sekretów uniemożliwiające uruchomienie kontenera):
oc describe pod -n <bob-namespace> -l app=inference-servicePrzełączanie głównego modelu wnioskowania
Aby przełączyć się z jednego obsługiwanego głównego modelu wnioskowania na inny po instalacji:
Upewnij się, że nowy model jest wdrożony
Potwierdź, że nowy model jest wdrożony i serwuje żądania. Zobacz Infrastruktura do serwowania modeli.
Zaktualizuj plik konfiguracyjny bramy modelu
Zaktualizuj model-gateway.yaml, aby odwoływał się do nowego modelu. Zobacz Konfiguracja bramy modelu.
Zastosuj zmianę
Zastosuj zaktualizowaną konfigurację przy użyciu bobctl update-model-config:
bobctl update-model-config --model-config ./my-model-config.yaml --update-secretsPełne informacje o flagach można znaleźć w artykule Wdrażanie konfiguracji.