IBM Bob

Walidacja przed instalacją

Zweryfikuj łączność z modelami, dane uwierzytelniające, certyfikaty i ustawienia konfiguracji przed instalacją, aby zidentyfikować i rozwiązać problemy z bramą modelu przed wdrożeniem IBM Bob on-premises.

Przed instalacją IBM Bob on-premises sprawdź, czy punkty końcowe modeli, dane uwierzytelniające, certyfikaty TLS i konfiguracja bramy modelu są prawidłowo skonfigurowane i dostępne z docelowego klastra OpenShift. Przeprowadzenie tych kontroli walidacyjnych pomaga zidentyfikować problemy z łącznością, nieprawidłowe dane uwierzytelniające, problemy z zaufaniem certyfikatów i błędy konfiguracyjne przed wdrożeniem, co zmniejsza liczbę awarii instalacji i nakład pracy związany z rozwiązywaniem problemów.

Przejdź przez tę listę kontrolną przed uruchomieniem bobctl install, aby wcześnie wykryć brakujące konfiguracje.

Testowanie łączności z punktami końcowymi modeli

Potwierdź, że klaster OpenShift może dotrzeć do każdego punktu końcowego modelu przed wdrożeniem jakiegokolwiek komponentu Bob. Uruchom tymczasowy pod debugowania w docelowej przestrzeni nazw i bezpośrednio przetestuj dostępność HTTPS:

# openai_compatible
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -v https://<model-endpoint>/v1/models

# bedrock
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -k https://bedrock.<AWS_REGION>.amazonaws.com/foundation-models \
  --aws-sigv4 "aws:amz:${REGION}:bedrock" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY"

W przypadku punktów końcowych openai_compatible przetestuj wartość base_url z konfiguracji bramy modelu. W przypadku infrastruktury air-gapped lub prywatnej jest to jedyny sposób na walidację łączności, ponieważ z założenia nie ma zewnętrznej dostępności.

Walidacja uwierzytelniania

Sprawdź dane uwierzytelniające przed zakodowaniem ich jako sekretów w config.yaml. Złe dane uwierzytelniające powodują nieudane uruchomienie usługi wnioskowania, często z nieczytelnym komunikatem dziennika.

  • openai_compatible — przetestuj klucz API bezpośrednio z poda debugowania:

    curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

  • bedrock — zweryfikuj wartości AWS_ACCESS_KEY i AWS_SECRET_ACCESS_KEY przy użyciu AWS CLI przed dodaniem ich do config.yaml:

    aws bedrock list-foundation-models --region us-east-1

  • vertex — zdekoduj wartość base64 GEMINI_CREDENTIALS i potwierdź, że jest prawidłowym JSON konta usługi przed jej podaniem:

    base64 -d <<< "$GEMINI_CREDENTIALS" | jq '.type'
# Oczekiwane wyjście: "service_account"

Walidacja certyfikatu TLS

Jeśli używasz ca_cert_pem z punktem końcowym openai_compatible, sprawdź certyfikat przed podaniem go jako sekretu.

Sprawdź, czy certyfikat jest zakodowany w formacie PEM i nie wygasł:

echo "<cert content>" | openssl x509 -noout -dates

Potwierdź, że certyfikat odpowiada łańcuchowi CA punktu końcowego:

openssl s_client -connect <host>:<port> -CAfile ca.pem
Ostrzeżenie:

insecure_skip_verify: true może być używane tymczasowo tylko podczas wstępnego debugowania łączności. Usuń je przed uruchomieniem produkcji. Jeśli ca_cert_pem odwołuje się do zmiennej środowiskowej, która nie jest obecna w bob.modelGateway.secrets, usługa wnioskowania uruchamia się pomyślnie, ale TLS kończy się niepowodzeniem w czasie wnioskowania.

Walidacja wykrywania modeli

Potwierdź, że ID model w bloku dostawcy dokładnie odpowiada temu, co dostawca udostępnia. Niezgodność skutkuje błędem 404 lub model-not-found w czasie wnioskowania, a nie podczas uruchamiania.

W przypadku punktów końcowych openai_compatible sprawdź dostępne ID modeli przed instalacją:

curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

Sprawdzanie typowych błędów konfiguracji

Błąd konfiguracjiObjawSprawdź
Nazwa sekretu w konfiguracji modelu nie odpowiada kluczowi w bloku secrets w config.yamlUwierzytelnianie nie powiedzie się w czasie żądania, nie podczas uruchamianiaPorównaj każde odwołanie env.* w konfiguracji modelu z kluczami bob.modelGateway.secrets
GEMINI_CREDENTIALS nie zakodowane w base64Dostawca Vertex nie może sparsować danych uwierzytelniających podczas uruchamianiaUruchom base64 -d <<< "$VALUE" i potwierdź, że jest prawidłowym JSON z "type": "service_account"
base_url zawiera końcowy / lub sufiks ścieżkiDostawca zwraca 404Usuń końcowe ukośniki — brama sama dołącza ścieżki jak /v1/chat/completions
Zduplikowane wartości model_name na liście modelsNieokreślone zachowanie routinguUpewnij się, że wszystkie wartości model_name są unikalne w konfiguracji
bobctl install uruchomiony bez --model-configPusta brama, brak wnioskowaniaPotwierdź, że --model-config jest przekazany i że plik jest czytelny pod podaną ścieżką
Zmienna środowiskowa ca_cert_pem zdefiniowana w konfiguracji modelu, ale brakująca w secretsAwaria TLS w czasie wnioskowaniaPorównaj każde odwołanie env.* w konfiguracji modelu z blokiem secrets
Jak oceniasz ten temat?

Na tej stronie

Testowanie łączności z punktami końcowymi modeliWalidacja uwierzytelnianiaWalidacja certyfikatu TLSWalidacja wykrywania modeliSprawdzanie typowych błędów konfiguracji