Udostępnij za pośrednictwem

Debugowanie skryptów scoringu modeli przy użyciu serwera HTTP do wnioskowania w Azure Machine Learning

Serwer HTTP wnioskowania usługi Azure Machine Learning to pakiet języka Python, który uwidacznia funkcję oceniania jako punkt końcowy HTTP i opakowuje kod serwera Flask i zależności w pojedynczy pakiet. Serwer wnioskowania jest dołączany do wstępnie utworzonych obrazów platformy Docker na potrzeby wnioskowania , które są używane podczas wdrażania modelu w usłudze Azure Machine Learning. Jeśli używasz samego pakietu, możesz wdrożyć model lokalnie na potrzeby środowiska produkcyjnego. Możesz również łatwo zweryfikować skrypt oceniania (wpisu) w lokalnym środowisku projektowym. Jeśli wystąpił problem ze skryptem oceniania, serwer wnioskowania zwraca błąd i lokalizację błędu.

Możesz również użyć serwera wnioskowania, aby utworzyć bramy weryfikacji w potoku ciągłej integracji i wdrażania. Na przykład można uruchomić serwer inferencyjny za pomocą skryptu próbnego i przeprowadzić zestaw testów na lokalnym punkcie końcowym.

Ten artykuł obsługuje deweloperów, którzy chcą używać serwera wnioskowania do debugowania lokalnego. W tym artykule zobaczysz, jak używać serwera wnioskowania z punktami końcowymi online.

Wymagania wstępne

  • Środowisko Python w wersji 3.8 lub nowszej
  • Anakonda

Serwer wnioskowania działa w systemach operacyjnych Windows i Linux.

Eksplorowanie lokalnych opcji debugowania dla punktów końcowych online

Debugowanie punktów końcowych lokalnie przed wdrożeniem w chmurze umożliwia wczesne przechwycenie błędów w kodzie i konfiguracji. Aby debugować punkty końcowe lokalnie, masz kilka opcji, w tym:

Poniższa tabela zawiera omówienie obsługi, którą oferuje każda opcja dla różnych scenariuszy debugowania:

Scenariusz Serwer wnioskowania Lokalny punkt końcowy
Aktualizowanie lokalnego środowiska języka Python bez ponownego kompilowanie obrazu platformy Docker Tak Nie.
Aktualizowanie skryptu oceniania Tak Tak
Aktualizowanie konfiguracji wdrożenia (wdrożenie, środowisko, kod, model) Nie. Tak
Integrowanie debugera programu Microsoft Visual Studio Code (VS Code) Tak Tak

W tym artykule opisano sposób używania serwera wnioskowania.

Po uruchomieniu serwera wnioskowania lokalnie możesz skoncentrować się na debugowaniu skryptu oceniania bez obaw o konfiguracje kontenera wdrożenia.

Lokalne debugowanie skryptu oceniania

Aby debugować skrypt oceniania lokalnie, istnieje kilka opcji testowania zachowania serwera wnioskowania:

Poniższe sekcje zawierają informacje o każdej opcji.

Używanie fikcyjnego skryptu oceniania do testowania zachowania serwera wnioskowania

  1. Utwórz katalog o nazwie server_quickstart do przechowywania plików:

    mkdir server_quickstart
cd server_quickstart

  2. Aby uniknąć konfliktów pakietów, utwórz środowisko wirtualne, takie jak myenv, i aktywuj je:

    python -m virtualenv myenv

    Uwaga

    W systemie Linux uruchom source myenv/bin/activate polecenie , aby aktywować środowisko wirtualne.

    Po przetestowaniu serwera wnioskowania można uruchomić deactivate polecenie , aby dezaktywować środowisko wirtualne języka Python.

  3. azureml-inference-server-http Zainstaluj pakiet ze źródła danych PyPI (Python Package Index):

    python -m pip install azureml-inference-server-http

  4. Utwórz skrypt wejściowy. Poniższy przykład tworzy podstawowy skrypt wejściowy i zapisuje go w pliku o nazwie score.py:

    echo -e 'import time\ndef init(): \n\ttime.sleep(1) \n\ndef run(input_data): \n\treturn {"message":"Hello, World!"}' > score.py

  5. azmlinfsrv Użyj polecenia , aby uruchomić serwer wnioskowania i ustawić plik score.py jako skrypt wpisu:

    azmlinfsrv --entry_script score.py

    Uwaga

    Serwer wnioskowania jest hostowany w wersji 0.0.0.0, co oznacza, że nasłuchuje wszystkich adresów IP maszyny hostingu.

  6. Użyj narzędzia curl do wysyłania żądania oceniania do serwera wnioskowania.

    curl -p 127.0.0.1:5001/score

    Serwer wnioskowania publikuje następującą odpowiedź:

    {"message": "Hello, World!"}

  7. Po zakończeniu testowania wybierz Ctrl+C , aby zatrzymać serwer wnioskowania.

Możesz zmodyfikować plik skryptu oceniania score.py. Następnie możesz przetestować zmiany przy użyciu azmlinfsrv --entry_script score.py polecenia , aby ponownie uruchomić serwer wnioskowania.

Integracja z programem VS Code

W programie VS Code można użyć rozszerzenia języka Python do debugowania z pakietem azureml-inference-server-http . Program VS Code oferuje dwa tryby debugowania: uruchamianie i dołączanie.

Przed użyciem dowolnego trybu zainstaluj azureml-inference-server-http pakiet, uruchamiając następujące polecenie:

python -m pip install azureml-inference-server-http

Uwaga

Aby uniknąć konfliktów pakietów, zainstaluj serwer wnioskowania w środowisku wirtualnym. Możesz użyć polecenia pip install virtualenv, aby włączyć środowiska wirtualne dla swojej konfiguracji.

Tryb uruchamiania

W trybie uruchamiania wykonaj następujące kroki, aby skonfigurować plik konfiguracji launch.json programu VS Code i uruchomić serwer wnioskowania w programie VS Code:

  1. Uruchom program VS Code i otwórz folder zawierający skrypt score.py.

  2. W przypadku tego obszaru roboczego w programie VS Code dodaj następującą konfigurację do pliku launch.json:

    {
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug score.py",
            "type": "debugpy",
            "request": "launch",
            "module": "azureml_inference_server_http.amlserver",
            "args": [
                "--entry_script",
                "score.py"
            ]
        }
    ]
  }

  3. Uruchom sesję debugowania w programie VS Code, wybierając pozycję Uruchom debugowanie> lub wybierając pozycję F5.

Tryb dołączania

W przypadku trybu dołączania wykonaj następujące kroki, aby użyć programu VS Code z rozszerzeniem języka Python w celu dołączenia do procesu serwera wnioskowania:

Uwaga

W przypadku systemu Linux najpierw zainstaluj gdb pakiet, uruchamiając sudo apt-get install -y gdb polecenie .

  1. Uruchom program VS Code i otwórz folder zawierający skrypt score.py.

  2. W przypadku tego obszaru roboczego w programie VS Code dodaj następującą konfigurację do pliku launch.json:

    {
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Attach using Process ID",
            "type": "debugpy",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "justMyCode": true
        }
    ]
  }

  3. W oknie polecenia uruchom serwer wnioskowania, uruchamiając azmlinfsrv --entry_script score.py polecenie .

  4. Wykonaj następujące kroki, aby rozpocząć sesję debugowania w programie VS Code:

    1. Wybierz pozycję Uruchom debugowanie> lub wybierz pozycję F5.

    2. W oknie poleceń wyszukaj dzienniki z serwera inferencyjnego, aby zlokalizować identyfikator procesu azmlinfsrv.

      Zrzut ekranu przedstawiający okno polecenia, które pokazuje wiadomości dziennika serwera inferencji. W jednej wiadomości dziennika wyróżniono identyfikator procesu polecenia azmlinfsrv.

      Pamiętaj, aby zlokalizować identyfikator azmlinfsrv procesu, a nie gunicorn procesu.

    3. W debugerze programu VS Code wprowadź identyfikator azmlinfsrv procesu.

      Jeśli nie widzisz selektora procesów programu VS Code, ręcznie wprowadź identyfikator procesu w processId polu pliku launch.json dla obszaru roboczego.

W przypadku trybów uruchamiania i dołączania można ustawić punkty przerwania i debugować skrypt krok po kroku.

Używanie kompleksowego przykładu

Poniższa procedura uruchamia serwer wnioskowania lokalnie z przykładowymi plikami z przykładowego repozytorium usługi Azure Machine Learning. Przykładowe pliki obejmują skrypt oceniania, plik modelu i plik środowiska. Aby uzyskać więcej przykładów używania tych przykładowych plików, zobacz Wdrażanie i ocenianie modelu uczenia maszynowego przy użyciu punktu końcowego online.

  1. Sklonuj przykładowe repozytorium i przejdź do folderu zawierającego odpowiednie pliki przykładowe:

    git clone --depth 1 https://github.com/Azure/azureml-examples
cd azureml-examples/cli/endpoints/online/model-1/

  2. Użyj conda, aby utworzyć i aktywować środowisko wirtualne.

    W tym przykładzie azureml-inference-server-http pakiet jest instalowany automatycznie. Pakiet jest uwzględniony jako biblioteka zależna od pakietu azureml-defaults, który jest wymieniony w pliku conda.yaml.

    # Create the environment from the YAML file.
conda env create --name model-env -f ./environment/conda.yaml
# Activate the new environment.
conda activate model-env

  3. Przejrzyj skrypt oceniania onlinescoring/score.py:

    import os
import logging
import json
import numpy
import joblib


def init():
    """
    This function is called when the container is initialized/started, typically after create/update of the deployment.
    You can write the logic here to perform init operations like caching the model in memory
    """
    global model
    # AZUREML_MODEL_DIR is an environment variable created during deployment.
    # It is the path to the model folder (./azureml-models/$MODEL_NAME/$VERSION)
    # Please provide your model's folder name if there is one
    model_path = os.path.join(
        os.getenv("AZUREML_MODEL_DIR"), "model/sklearn_regression_model.pkl"
    )
    # deserialize the model file back into a sklearn model
    model = joblib.load(model_path)
    logging.info("Init complete")


def run(raw_data):
    """
    This function is called for every invocation of the endpoint to perform the actual scoring/prediction.
    In the example we extract the data from the json input and call the scikit-learn model's predict()
    method and return the result back
    """
    logging.info("model 1: request received")
    data = json.loads(raw_data)["data"]
    data = numpy.array(data)
    result = model.predict(data)
    logging.info("Request processed")
    return result.tolist()

  4. Uruchom serwer wnioskowania, określając skrypt oceniania i ścieżkę do folderu modelu.

    Podczas wdrażania zmienna jest definiowana AZUREML_MODEL_DIR w celu przechowywania ścieżki do folderu modelu. Należy określić wartość w parametrze model_dir . Po uruchomieniu skryptu oceniania pobiera wartość ze zmiennej AZUREML_MODEL_DIR .

    W tym przypadku użyj bieżącego katalogu ./ jako wartości model_dir, ponieważ skrypt oceniania określa podkatalog jako model/sklearn_regression_model.pkl.

    azmlinfsrv --entry_script ./onlinescoring/score.py --model_dir ./

    Gdy serwer wnioskowania zostanie uruchomiony i pomyślnie wywoła skrypt oceniania, otwiera się przykładowy dziennik uruchamiania. W przeciwnym razie dziennik wyświetla komunikaty o błędach.

  5. Przetestuj skrypt oceniania przy użyciu przykładowych danych, wykonując następujące czynności:

    1. Otwórz inne okno polecenia i przejdź do tego samego katalogu roboczego azmlinfsrv , w którym uruchomiono polecenie .

    2. Użyj następującego curl narzędzia, aby wysłać przykładowe żądanie do serwera wnioskowania i otrzymać wynik oceniania:

      curl --request POST "127.0.0.1:5001/score" --header "Content-Type:application/json" --data @sample-request.json

      Jeśli skrypt oceniania nie ma problemów, skrypt zwraca wynik oceniania. Jeśli wystąpią problemy, możesz zaktualizować skrypt oceniania, a następnie ponownie uruchomić serwer wnioskowania, aby przetestować zaktualizowany skrypt.

Przeglądanie tras serwera wnioskowania

Serwer wnioskowania domyślnie nasłuchuje na porcie 5001 w następujących trasach:

Nazwisko Marszruta
Sonda żywotności 127.0.0.1:5001/
Ocena 127.0.0.1:5001/score
OpenAPI (swagger) 127.0.0.1:5001/swagger.json

Przeglądanie parametrów serwera wnioskowania

Serwer wnioskowania akceptuje następujące parametry:

Parametr Wymagania Wartość domyślna opis
entry_script Prawda Nie dotyczy Identyfikuje względną lub bezwzględną ścieżkę do skryptu oceniania
model_dir Fałsz Nie dotyczy Identyfikuje względną lub bezwzględną ścieżkę do katalogu, który zawiera model używany do wnioskowania
port Fałsz 5001 Określa port obsługujący serwera wnioskowania
worker_count Fałsz 1 Podaje liczbę wątków roboczych do przetwarzania współbieżnych żądań
appinsights_instrumentation_key Fałsz Nie dotyczy Udostępnia klucz instrumentacji dla wystąpienia usługi Application Insights, w którym są publikowane dzienniki
access_control_allow_origins Fałsz Nie dotyczy Włącza współużytkowanie zasobów między źródłami (CORS) dla określonych źródeł, gdzie wiele źródeł jest rozdzielonych przecinkiem (,), na przykład microsoft.com, bing.com

Zapoznaj się z przetwarzaniem żądań serwera inferencyjnego

W poniższych krokach pokazano, azmlinfsrvjak serwer wnioskowania obsługuje żądania przychodzące:

  1. Nakładka CLI języka Python zarządza stosem sieciowym serwera inferencji i jest używana do uruchamiania serwera inferencji.

  2. Klient wysyła żądanie do serwera wnioskowania.

  3. Serwer wnioskowania przesyła żądanie za pośrednictwem Web Server Gateway Interface (WSGI), który kieruje je do jednej z następujących aplikacji pracowniczych Flask:

    • W systemie Windows: kelnerka
    • W systemie Linux: gunicorn

  4. Aplikacja procesów roboczych platformy Flask obsługuje żądanie, które obejmuje ładowanie skryptu wpisu i wszelkich zależności.

  5. Skrypt wejścia odbiera żądanie. Skrypt wejściowy wykonuje wywołanie wnioskowania do załadowanego modelu i zwraca odpowiedź.

Diagram przedstawiający sposób uruchamiania serwera inferencji i przepływ żądania do aplikacji Flask, a następnie do kodu użytkownika.

Eksplorowanie dzienników serwera wnioskowania

Istnieją dwa sposoby uzyskiwania danych dziennika dla testu serwera wnioskowania:

  • azureml-inference-server-http Uruchom pakiet lokalnie i wyświetl dane wyjściowe dziennika.
  • Użyj punktów końcowych online i wyświetl dzienniki kontenera. Dziennik dla serwera wnioskowania nosi nazwę Azure Machine Learning Inferencing WERSJA serwera <>HTTP.

Uwaga

Format rejestrowania zmienił się od wersji 0.8.0. Jeśli dziennik używa innego stylu niż oczekiwano, zaktualizuj azureml-inference-server-http pakiet do najnowszej wersji.

Wyświetlanie dzienników uruchamiania

Po uruchomieniu serwera wnioskowania dzienniki pokazują następujące ustawienia serwera początkowego:

Azure ML Inferencing HTTP server <version>


Server Settings
---------------
Entry Script Name: <entry-script>
Model Directory: <model-directory>
Config File: <configuration-file>
Worker Count: <worker-count>
Worker Timeout (seconds): None
Server Port: <port>
Health Port: <port>
Application Insights Enabled: false
Application Insights Key: <Application-Insights-instrumentation-key>
Inferencing HTTP server version: azmlinfsrv/<version>
CORS for the specified origins: <access-control-allow-origins>
Create dedicated endpoint for health: <health-check-endpoint>


Server Routes
---------------
Liveness Probe: GET   127.0.0.1:<port>/
Score:          POST  127.0.0.1:<port>/score

<logs>

Na przykład po uruchomieniu serwera wnioskowania przez wykonanie pełnych przykładowych kroków dzienniki zawierają następujące informacje:

Azure ML Inferencing HTTP server v1.2.2


Server Settings
---------------
Entry Script Name: /home/user-name/azureml-examples/cli/endpoints/online/model-1/onlinescoring/score.py
Model Directory: ./
Config File: None
Worker Count: 1
Worker Timeout (seconds): None
Server Port: 5001
Health Port: 5001
Application Insights Enabled: false
Application Insights Key: None
Inferencing HTTP server version: azmlinfsrv/1.2.2
CORS for the specified origins: None
Create dedicated endpoint for health: None

Server Routes
---------------
Liveness Probe: GET   127.0.0.1:5001/
Score:          POST  127.0.0.1:5001/score

2022-12-24 07:37:53,318 I [32726] gunicorn.error - Starting gunicorn 20.1.0
2022-12-24 07:37:53,319 I [32726] gunicorn.error - Listening at: http://0.0.0.0:5001 (32726)
2022-12-24 07:37:53,319 I [32726] gunicorn.error - Using worker: sync
2022-12-24 07:37:53,322 I [32756] gunicorn.error - Booting worker with pid: 32756
Initializing logger
2022-12-24 07:37:53,779 I [32756] azmlinfsrv - Starting up app insights client
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - Found user script at /home/user-name/azureml-examples/cli/endpoints/online/model-1/onlinescoring/score.py
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - run() is not decorated. Server will invoke it with the input in JSON string.
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - Invoking user's init function
2022-12-24 07:37:55,974 I [32756] azmlinfsrv.user_script - Users's init has completed successfully
2022-12-24 07:37:55,976 I [32756] azmlinfsrv.swagger - Swaggers are prepared for the following versions: [2, 3, 3.1].
2022-12-24 07:37:55,976 I [32756] azmlinfsrv - Scoring timeout is set to 3600000
2022-12-24 07:37:55,976 I [32756] azmlinfsrv - Worker with pid 32756 ready for serving traffic

Informacje o formacie danych dziennika

Wszystkie dzienniki z serwera wnioskowania, z wyjątkiem skryptu uruchamiania, przedstawiają dane w następującym formacie:

<UTC-time> <level> [<process-ID>] <logger-name> - <message>

Każdy wpis składa się z następujących składników:

  • <UTC-time>: godzina wprowadzenia wpisu do dziennika
  • <level>: pierwszy znak poziomu rejestrowania dla wpisu, taki jak E ERROR, I info itd.
  • <process-ID>: identyfikator procesu skojarzonego z wpisem
  • <logger-name>: nazwa zasobu skojarzonego z wpisem dziennika
  • <message>: zawartość komunikatu dziennika

W języku Python istnieje sześć poziomów rejestrowania. Każdy poziom ma przypisaną wartość liczbową zgodnie z jego ważnością:

Poziom rejestrowania Wartość liczbowa
KRYTYCZNY 50
BŁĄD 40
OSTRZEŻENIE 30
INFORMACJI 20
DEBUG 10
NOTSET 0

Rozwiązywanie problemów z serwerem wnioskowania

Poniższe sekcje zawierają podstawowe porady dotyczące rozwiązywania problemów z serwerem wnioskowania. Aby rozwiązać problemy z punktami końcowymi online, zobacz Rozwiązywanie problemów z wdrażaniem i ocenianie punktów końcowych online.

Sprawdzanie zainstalowanych pakietów

Wykonaj następujące kroki, aby rozwiązać problemy z zainstalowanymi pakietami:

  1. Zbierz informacje o zainstalowanych pakietach i wersjach dla środowiska języka Python.

  2. W pliku środowiska sprawdź wersję określonego azureml-inference-server-http pakietu języka Python. W dziennikach uruchamiania serwera HTTP usługi Azure Machine Learning sprawdź wersję serwera wnioskowania, która jest wyświetlana. Upewnij się, że obie wersje są zgodne.

    W niektórych przypadkach narzędzie do rozpoznawania zależności instaluje nieoczekiwane wersje pakietu. Może być konieczne uruchomienie polecenia pip , aby poprawić zainstalowane pakiety i wersje.

  3. Jeśli wymienisz Flask lub jego zależności w środowisku, usuń te elementy.

    • Pakiety zależne obejmują flask, , jinja2, itsdangerouswerkzeug, markupsafe, i click.
    • Pakiet flask jest wyświetlany jako zależność w pakiecie serwera wnioskowania. Najlepszym rozwiązaniem jest umożliwienie serwerowi wnioskowania zainstalowanie flask pakietu.
    • Gdy serwer wnioskowania jest skonfigurowany do obsługi nowych wersji platformy Flask, serwer wnioskowania automatycznie odbiera aktualizacje pakietów w miarę ich dostępności.

Sprawdzanie wersji serwera wnioskowania

Pakiet azureml-inference-server-http serwera jest publikowany w interfejsie PyPI. Na stronie PyPI jest wyświetlana lista zmian i wszystkie wersje pakietu.

Jeśli używasz wczesnej wersji pakietu, zaktualizuj konfigurację do najnowszej wersji. Poniższa tabela zawiera podsumowanie stabilnych wersji, typowych problemów i zalecanych korekt:

Wersja pakietu opis Problem Rozwiązanie
0.4.x W pakiecie w obrazach szkoleniowych datowanych na 20220601 lub wcześniejsze oraz w wersjach pakietu od 0.1.34 do 1.43. Najnowsza stabilna wersja to 0.4.13. W przypadku wersji serwera starszych niż 0.4.11 mogą wystąpić problemy z zależnościami platformy Flask, takie jak can't import name Markup from jinja2. Uaktualnij do wersji 0.4.13 lub 1.4.x, jeśli jest to możliwe, najnowszą wersję.
0.6.x Wstępnie zainstalowane wywnioskujące obrazy z datą 20220516 i wcześniejszymi wersjami. Najnowsza stabilna wersja to 0.6.1. Nie dotyczy Nie dotyczy
0.7.x Obsługuje platformę Flask 2. Najnowsza stabilna wersja to 0.7.7. Nie dotyczy Nie dotyczy
0.8.x Używa zaktualizowanego formatu dziennika. Kończy obsługę języka Python 3.6. Nie dotyczy Nie dotyczy
1.0.x Kończy obsługę języka Python 3.7. Nie dotyczy Nie dotyczy
1.1.x Migruje do pydantic wersji 2.0. Nie dotyczy Nie dotyczy
1.2.x Dodaje obsługę języka Python 3.11. Aktualizuje gunicorn do wersji 22.0.0. Aktualizacje werkzeug wersji 3.0.3 lub nowszej. Nie dotyczy Nie dotyczy
1.3.x Dodaje obsługę języka Python 3.12. certifi Uaktualnienia do wersji 2024.7.4. Uaktualnia flask-cors do wersji 5.0.0. Aktualizuje pakiety gunicorn i pydantic. Nie dotyczy Nie dotyczy
1.4.x waitress Uaktualnienia do wersji 3.0.1. Kończy obsługę języka Python 3.8. Usuwa warstwę zgodności, która zapobiega złamaniu kodu obiektu żądania podczas uaktualniania Flask 2.0. Jeśli zależysz od warstwy zgodności, kod obiektu żądania może nie działać. Przeprowadź migrację skryptu oceny do platformy Flask 2.

Sprawdzanie zależności pakietów

Najbardziej istotne pakiety zależne dla azureml-inference-server-http pakietu serwera obejmują:

  • flask
  • opencensus-ext-azure
  • inference-schema

Jeśli określisz pakiet azureml-defaults w swoim środowisku Python, to pakiet azureml-inference-server-http jest pakietem zależnym. Zależność jest instalowana automatycznie.

Napiwek

Jeśli używasz zestawu AZURE Machine Learning SDK dla języka Python w wersji 1 i nie określasz azureml-defaults jawnie pakietu w środowisku języka Python, zestaw SDK może automatycznie dodać pakiet. Jednak wersja pakietu jest zablokowana względem wersji zestawu SDK. Jeśli na przykład wersja zestawu SDK to 1.38.0, wpis azureml-defaults==1.38.0 zostanie dodany do wymagań środowiska pip.

TypeError podczas uruchamiania serwera wnioskowania

Podczas uruchamiania serwera wnioskowania mogą wystąpić następujące błędy TypeError :

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Ten błąd występuje, gdy platforma Flask 2 jest zainstalowana w środowisku języka Python, ale azureml-inference-server-http wersja pakietu nie obsługuje platformy Flask 2. Obsługa platformy Flask 2 jest dostępna w azureml-inference-server-http pakiecie 0.7.0 i nowszych wersjach oraz azureml-defaults pakiecie 1.44 i nowszych wersjach.

  • Jeśli nie używasz pakietu Platformy Flask 2 w obrazie platformy Docker usługi Azure Machine Learning, użyj najnowszej azureml-inference-server-http wersji pakietu lub azureml-defaults .

  • Jeśli używasz pakietu Flask 2 w obrazie Docker usługi Azure Machine Learning, upewnij się, że wersja kompilacji obrazu jest July 2022 lub późniejsza.

    Wersję obrazu można znaleźć w dziennikach kontenera. Spójrz na przykład na następujące wyrażenia logów:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    Data kompilacji obrazu jest wyświetlana Materialization Build po notacji. W poprzednim przykładzie wersja obrazu to 20220708, czyli 8 lipca 2022 r. Obraz w tym przykładzie jest zgodny z platformą Flask 2.

    Jeśli w dzienniku kontenera nie widzisz podobnego komunikatu, obraz jest nieaktualny i powinien zostać zaktualizowany. Jeśli używasz obrazu Compute Unified Device Architecture (CUDA) i nie możesz znaleźć nowszego obrazu, sprawdź repozytorium AzureML-Containers , aby sprawdzić, czy obraz jest przestarzały. Wyznaczone zamienniki dla przestarzałych obrazów można znaleźć.

    Jeśli używasz serwera wnioskowania z punktem końcowym online, możesz również znaleźć dzienniki w usłudze Azure Machine Learning Studio. Na stronie punktu końcowego wybierz kartę Dzienniki .

Jeśli wdrażasz przy użyciu SDK v1 i nie określisz jawnie obrazu w konfiguracji wdrożenia, serwer wnioskowania użyje openmpi4.1.0-ubuntu20.04 pakietu z wersją zgodną z lokalnym zestawem SDK. Jednak zainstalowana wersja może nie być najnowszą dostępną wersją obrazu.

W przypadku zestawu SDK w wersji 1.43 serwer wnioskowania domyślnie instaluje openmpi4.1.0-ubuntu20.04:20220616 wersję pakietu, ale ta wersja pakietu nie jest zgodna z zestawem SDK 1.43. Upewnij się, że używasz najnowszego zestawu SDK do wdrożenia.

Jeśli nie możesz zaktualizować obrazu, możesz tymczasowo uniknąć problemu, przypinając azureml-defaults==1.43 wpisy lub azureml-inference-server-http~=0.4.13 w pliku środowiska. Te wpisy kierują serwer wnioskowania, aby zainstalować starszą wersję za pomocą polecenia flask 1.0.x.

ImportError lub ModuleNotFoundError podczas uruchamiania serwera wnioskowania

Podczas uruchamiania serwera wnioskowania może wystąpić element ImportError lub ModuleNotFoundError w określonych modułach, takich jak opencensus, jinja2, markupsafelub click. Poniższy przykład przedstawia komunikat o błędzie:

ImportError: cannot import name 'Markup' from 'jinja2'

Podczas korzystania z wersji 0.4.10 lub starszej wersji serwera wnioskowania występują błędy importowania i modułu, które nie przypinają zależności platformy Flask do zgodnej wersji. Aby zapobiec problemowi, zainstaluj nowszą wersję serwera wnioskowania.

Powiązana zawartość