Przewodnik debugowania dotyczący obsługi modeli

Artykuł
12/27/2024

W tym artykule przedstawiono kroki debugowania typowych problemów, które użytkownicy mogą napotkać podczas pracy z punktami końcowymi obsługującymi model. Typowe problemy mogą obejmować błędy napotykane przez użytkowników, gdy punkt końcowy nie może zainicjować lub uruchomić, niepowodzenia kompilacji związane z kontenerem lub problemy podczas operacji lub uruchamiania modelu w punkcie końcowym.

Uzyskiwanie dostępu do dzienników i przeglądanie ich

Usługa Databricks zaleca przeglądanie dzienników kompilacji na potrzeby debugowania i rozwiązywania problemów z błędami w modelu obsługującym obciążenia. Zobacz Monitorowanie jakości modelu i kondycji punktu końcowego, aby uzyskać informacje na temat dzienników i sposobu ich wyświetlania.

Sprawdź dzienniki zdarzeń dla modelu w interfejsie użytkownika obszaru roboczego i sprawdź komunikat o pomyślnej kompilacji kontenera. Jeśli po godzinie nie widzisz komunikatu dotyczącego kompilacji, skontaktuj się z pomocą techniczną usługi Databricks, aby uzyskać pomoc.

Jeśli kompilacja zakończy się pomyślnie, ale wystąpią inne błędy, zobacz Debugowanie po pomyślnym zakończeniu kompilacji kontenera. Jeśli kompilacja zakończy się niepowodzeniem, zobacz Debugowanie po niepowodzeniu kompilacji kontenera.

Zainstalowane wersje pakietów biblioteki

W dziennikach kompilacji można potwierdzić zainstalowane wersje pakietów.

W przypadku wersji platformy MLflow, jeśli nie masz określonej wersji, obsługa modelu używa najnowszej wersji.
W przypadku niestandardowej obsługi procesora GPU usługa Model Serving instaluje zalecane wersje cuda i cuDNN zgodnie z publiczną dokumentacją PyTorch i Tensorflow.

Przed sprawdzaniem poprawności wdrożenia modelu

Databricks zaleca przestrzeganie wskazówek zawartych w tym rozdziale, zanim uruchomisz swój model. Poniższe parameters może przechwycić problemy wcześniej, zanim konieczne będzie czekanie na punkt końcowy. Zobacz Zweryfikuj dane wejściowe modelu przed wdrożeniem, aby zweryfikować dane wejściowe modelu przed wdrożeniem modelu.

Testowanie przewidywań przed wdrożeniem

Przed wdrożeniem modelu do punktu końcowego obsługi przetestuj przewidywania offline w środowisku wirtualnym, używając mlflow.models.predict i przykładów wejściowych. Aby uzyskać bardziej szczegółowe wskazówki, zobacz dokumentację MLflow dotyczącą testowania przewidywań.


input_example = {
                  "messages":
                  [
                    {"content": "How many categories of products do we have? Name them.", "role": "user"}
                  ]
                }

mlflow.models.predict(
   model_uri = logged_chain_info.model_uri,
   input_data = input_example,
)

Weryfikowanie danych wejściowych modelu przed wdrożeniem

Punkty końcowe obsługujące model oczekują specjalnego formatu danych wejściowych json, aby zweryfikować poprawność działania danych wejściowych modelu na punkcie końcowym przed wdrożeniem. Aby przeprowadzić taką walidację, możesz użyć validate_serving_input w narzędziu MLflow.

Poniżej przedstawiono przykład kodu generowanego automatycznie na karcie artefaktów uruchomienia, jeśli model jest zarejestrowany z użyciem prawidłowego przykładu danych wejściowych.

from mlflow.models import validate_serving_input

model_uri = 'runs:/<run_id>/<artifact_path>'

serving_payload = """{
 "messages": [
   {
     "content": "How many product categories are there?",
     "role": "user"
   }
 ]
}
"""

# Validate the serving payload works on the model
validate_serving_input(model_uri, serving_payload)

Możesz również przetestować wszystkie przykłady danych wejściowych względem zarejestrowanego modelu przy użyciu interfejsu API convert_input_example_to_serving_input, aby generate prawidłowy kod json obsługujący dane wejściowe.

from mlflow.models import validate_serving_input
from mlflow.models import convert_input_example_to_serving_input

model_uri = 'runs:/<run_id>/<artifact_path>'

# Define INPUT_EXAMPLE with your own input example to the model
# A valid input example is a data instance suitable for pyfunc prediction

serving_payload = convert_input_example_to_serving_input(INPUT_EXAMPLE)

# Validate the serving payload works on the model
validate_serving_input(model_uri, serving_payload)

Debugowanie po pomyślnym zakończeniu kompilacji kontenera

Nawet jeśli kontener zostanie pomyślnie skompilowanych, mogą wystąpić problemy podczas uruchamiania modelu lub podczas działania samego punktu końcowego. W poniższych podsekcjach szczegółowo opisano typowe problemy oraz sposób rozwiązywania problemów i debugowania

Brak zależności

Możesz get błąd, taki jak An error occurred while loading the model. No module named <module-name>.. Ten błąd może wskazywać, że w kontenerze brakuje zależności. Sprawdź, czy poprawnie oznaczono wszystkie zależności, które powinny zostać uwzględnione w kompilacji kontenera. Zwróć szczególną uwagę na biblioteki niestandardowe i upewnij się, że .whl pliki są dołączane jako artefakty.

Zapętlanie dzienników usługi

Jeśli kompilacja kontenera zakończy się niepowodzeniem, sprawdź dzienniki usług, aby sprawdzić, czy zauważysz, że są one zapętlone, gdy punkt końcowy spróbuje załadować model. Jeśli widzisz to zachowanie, spróbuj wykonać następujące czynności:

Otwórz notes i dołącz go do klastra ogólnego przeznaczenia, który używa wersji środowiska Databricks Runtime, a nie środowiska Databricks Runtime na potrzeby uczenia maszynowego.
Załaduj model przy użyciu biblioteki MLflow i spróbuj przeprowadzić debugowanie z tego miejsca.

Możesz również załadować model lokalnie na komputerze i debugować z tego miejsca. Załaduj model lokalnie przy użyciu następujących elementów:

import os
import mlflow

os.environ["MLFLOW_TRACKING_URI"] = "databricks://PROFILE"

ARTIFACT_URI = "model_uri"
if '.' in ARTIFACT_URI:
    mlflow.set_registry_uri('databricks-uc')
local_path = mlflow.artifacts.download_artifacts(ARTIFACT_URI)
print(local_path)

conda env create -f local_path/artifact_path/conda.yaml
conda activate mlflow-env

mlflow.pyfunc.load_model(local_path/artifact_path)

Model kończy się niepowodzeniem, gdy żądania są wysyłane do punktu końcowego

Może pojawić się błąd podobny Encountered an unexpected error while evaluating the model. Verify that the input is compatible with the model for inference. do tego, kiedy predict() jest wywoływany w modelu.

W funkcji występuje problem z predict() kodem. Usługa Databricks zaleca załadowanie modelu z biblioteki MLflow w notesie i wywołanie go. Dzięki temu uwypukla się problemy w funkcji predict() i można zauważyć, że do awarii dochodzi wewnątrz metody where.

Obszar roboczy przekracza aprowizowaną współbieżność

Może zostać wyświetlony Workspace exceeded provisioned concurrency quota błąd.

Możesz zwiększyć współbieżność w zależności od dostępności regionu. Skontaktuj się z zespołem konta usługi Databricks i podaj identyfikator obszaru roboczego, aby zażądać zwiększenia współbieżności.

Debugowanie po niepowodzeniu kompilacji kontenera

Ta sekcja zawiera szczegółowe informacje o problemach, które mogą wystąpić w przypadku niepowodzenia kompilacji.

`OSError: [Errno 28] No space left on device`

Błąd No space left może być spowodowany zbyt wieloma dużymi artefaktami rejestrowanymi obok modelu niepotrzebnie. Sprawdź w MLflow, że nadmiarowe artefakty nie są rejestrowane razem z modelem i spróbuj ponownie wdrożyć smukły pakiet.

Problemy z Azure Firewall dotyczące obsługi modeli z platformy Unity Catalog

Może zostać wyświetlony błąd: Build could not start due to an internal error. If you are serving a model from UC and Azure Firewall is enabled, this is not supported by default..

Skontaktuj się z zespołem ds. kont usługi Databricks, aby rozwiązać ten problem.

Niepowodzenie kompilacji z powodu braku dostępności procesora GPU

Może zostać wyświetlony błąd: Build could not start due to an internal error - please contact your Databricks representative..