Handleiding voor foutopsporing voor Model Serving

In dit artikel worden de stappen voor foutopsporing beschreven voor veelvoorkomende problemen die gebruikers kunnen tegenkomen bij het werken met eindpunten voor modellen. Veelvoorkomende problemen kunnen fouten zijn die gebruikers tegenkomen wanneer het eindpunt niet kan worden geïnitialiseerd of gestart, buildfouten met betrekking tot de container of problemen tijdens de bewerking of het uitvoeren van het model op het eindpunt.

Logboeken openen en controleren

Databricks raadt aan om build logs te bekijken voor het opsporen en oplossen van fouten in uw model-serving workloads. Zie Modelkwaliteit en eindpuntstatus bewaken voor informatie over logboeken en hoe u deze kunt weergeven.

Controleer de gebeurtenislogboeken voor het model in de gebruikersinterface van de werkruimte en controleer op een bericht over een geslaagde containerbuild. Als u na een uur geen buildbericht ziet, neemt u contact op met databricks-ondersteuning voor hulp.

Als uw build is geslaagd, maar er andere fouten optreden, ziet u Foutopsporing nadat de containerbuild is geslaagd. Als uw build mislukt, raadpleeg Foutopsporing na een containerbuildfout.

Geïnstalleerde bibliotheekpakketversies

In uw buildlogboeken kunt u de pakketversies bevestigen die zijn geïnstalleerd.

• Als u voor MLflow-versies geen versie hebt opgegeven, gebruikt Model Serving de nieuwste versie.
• Voor aangepaste GPU-services installeert Model Serving de aanbevolen versies van cuda en cuDNN volgens de openbare PyTorch- en Tensorflow-documentatie.

Logboekmodellen waarvoor een logboek is vereist flash-attn

Als u een model aanmeldt dat vereist is flash-attn, raadt Databricks aan een aangepaste wielversie van flash-attnte gebruiken. Anders kunnen buildfouten optreden, zoals ModuleNotFoundError: No module named 'torch' dit kan optreden.

Als u een aangepaste wielversie van flash-attnwilt gebruiken, geeft u alle pip-vereisten op als een lijst en geeft u deze als parameter door aan uw mlflow.transformers.log_model functie. U moet ook de versies van pytorch, torch en torchvision opgeven die compatibel zijn met de CUDA-versie die is opgegeven in uw flash attn wheel-bestand.

Databricks raadt bijvoorbeeld aan de volgende versies en wielen voor CUDA 11.8 te gebruiken:

• Pytorch
• Torch 2.0.1+cu118
• Torchvision 0.15.2+cu118
• Flash-Attn

logged_model=mlflow.transformers.log_model(
transformers_model=test_pipeline,
       artifact_path="artifact_path",
       pip_requirements=["--extra-index-url https://download.pytorch.org/whl/cu118", "mlflow==2.13.1", "setuptools<70.0.0", "torch==2.0.1+cu118", "accelerate==0.31.0", "astunparse==1.6.3", "bcrypt==3.2.0", "boto3==1.34.39", "configparser==5.2.0", "defusedxml==0.7.1", "dill==0.3.6", "google-cloud-storage==2.10.0", "ipython==8.15.0", "lz4==4.3.2", "nvidia-ml-py==12.555.43", "optree==0.12.1", "pandas==1.5.3", "pyopenssl==23.2.0", "pytesseract==0.3.10", "scikit-learn==1.3.0", "sentencepiece==0.1.99", "torchvision==0.15.2+cu118", "transformers==4.41.2", "https://github.com/Dao-AILab/flash-attention/releases/download/v2.5.8/flash_attn-2.5.8+cu118torch2.0cxx11abiFALSE-cp311-cp311-linux_x86_64.whl"],
       input_example=input_example,
       registered_model_name=registered_model_name)

Voordat validatiecontroles voor modelimplementatie worden uitgevoerd

Databricks raadt u aan de richtlijnen in deze sectie toe te passen voordat u uw model gaat bedienen. Met de volgende parameters kunt u problemen vroegtijdig ondervangen voordat u op het eindpunt wacht. Zie De modelinvoer valideren voordat de implementatie om uw modelinvoer te valideren voordat u uw model implementeert.

Voorspellingen testen vóór implementatie

Voordat u uw model implementeert op het servereindpunt, test u offlinevoorspellingen met een virtuele omgeving met behulp van mlflow.models.predict en invoervoorbeelden. MLflow biedt validatie-API's die de implementatieomgeving simuleren en het testen van gewijzigde afhankelijkheden toestaan.

Er zijn twee opties voor validatie vóór de implementatie: de MLflow Python-API en de MLflow CLI. Zie MLflow-documentatie voor het testen van voorspellingen voor gedetailleerdere richtlijnen.

U kunt de volgende parameters opgeven:

• Het model_uri model dat is geïmplementeerd voor het leveren van modellen.
• Een van de volgende opties:
  • De input_data in de verwachte indeling voor de mlflow.pyfunc.PyFuncModel.predict() aanroep van het model.
  • Hiermee input_path definieert u een bestand met invoergegevens die worden geladen en gebruikt voor de aanroep.predict
• De content_type in csv - of json notatie.
• Een optioneel output_path om de voorspellingen naar een bestand te schrijven. Als u deze parameter weglaat, worden de voorspellingen afgedrukt naar stdout.
• Een omgevingsmanager, env_manager, die wordt gebruikt om de omgeving te bouwen voor het leveren van:
  • De standaardwaarde is virtualenv. Aanbevolen voor validatie.
  • local is beschikbaar, maar mogelijk foutgevoelig voor het uitvoeren van validatie. Over het algemeen alleen gebruikt voor snelle foutopsporing.
• Of u de huidige versie van MLflow wilt installeren die zich in uw omgeving bevindt met behulp van install_mlflowde virtuele omgeving. Deze instelling wordt standaard ingesteld op False.
• Of u nu verschillende versies van pakketafhankelijkheden wilt bijwerken en testen voor probleemoplossing of foutopsporing. U kunt dit opgeven als een lijst van overschrijvingen of toevoegingen van afhankelijkheden van tekenreeksen met behulp van het argument overschrijving, pip_requirements_override.

Voorbeeld:

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Modelafhankelijkheden bijwerken

Als er problemen zijn met de afhankelijkheden die zijn opgegeven met een geregistreerd model, kunt u de vereisten bijwerken met behulp van de MLflow CLI of mlflow.models.model.update_model_requirements() in de MLflow Python-API zonder dat u een ander model hoeft te registreren.

In het volgende voorbeeld ziet u hoe u de pip_requirements.txt van een geregistreerd model direct kunt bijwerken.

U kunt bestaande definities bijwerken met opgegeven pakketversies of niet-bestaande vereisten toevoegen aan het pip_requirements.txt bestand. Dit bestand bevindt zich in het MLflow-modelartefact op de opgegeven model_uri locatie.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

de modelinvoer valideren vóór de implementatie

Bij het leveren van modellen voor eindpunten wordt een speciale indeling van json invoer verwacht om te controleren of uw modelinvoer werkt op een dienend eindpunt voordat de implementatie wordt uitgevoerd. U kunt validate_serving_input in MLflow gebruiken om een dergelijke validatie uit te voeren.

Hier volgt een voorbeeld van de automatisch gegenereerde code op het tabblad artefacten van de uitvoering als uw model is geregistreerd met een geldig invoervoorbeeld.

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)

U kunt ook invoervoorbeelden testen op basis van het vastgelegde model met behulp van de convert_input_example_to_serving_input API om een geldige json-invoer te genereren.

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)

Debuggen nadat de containerbuild is geslaagd

Zelfs als de container is gebouwd, kunnen er problemen zijn wanneer u het model uitvoert of tijdens de bewerking van het eindpunt zelf. In de volgende subsecties worden veelvoorkomende problemen beschreven en wordt beschreven hoe u problemen kunt oplossen en fouten kunt opsporen

Ontbrekende afhankelijkheid

Mogelijk krijgt u een foutmelding zoals An error occurred while loading the model. No module named <module-name>.. Deze fout kan erop wijzen dat een afhankelijkheid ontbreekt in de container. Controleer of u alle afhankelijkheden hebt aangegeven die moeten worden opgenomen in de build van de container. Let vooral op aangepaste bibliotheken en zorg ervoor dat de .whl bestanden worden opgenomen als artefacten.

Servicelogboeken herhalen

Als uw containerbuild mislukt, controleert u de servicelogboeken om te zien of u merkt dat ze worden herhaald wanneer het eindpunt het model probeert te laden. Als u dit gedrag ziet, voert u de volgende stappen uit:

1. Open een notebook en koppel deze aan een cluster voor alle doeleinden dat gebruikmaakt van een Databricks Runtime-versie, niet Databricks Runtime voor Machine Learning.
2. Laad het model met behulp van MLflow en probeer daar de foutopsporing uit te voeren.

U kunt het model ook lokaal op uw pc laden en daar fouten opsporen. Laad uw model lokaal met behulp van het volgende:

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 mislukt of time-out wanneer aanvragen naar het eindpunt worden verzonden

Mogelijk krijgt u een foutmelding zoals Encountered an unexpected error while evaluating the model. Verify that the input is compatible with the model for inference. wanneer het model door predict() wordt aangeroepen.

Er is een codeprobleem in de predict() functie. Databricks raadt u aan het model vanuit MLflow in een notebook te laden en aan te roepen. Als u dit doet, worden de problemen in de predict() functie gemarkeerd en kunt u zien waar de fout zich in de methode voordoet.

Hoofdoorzaakanalyse van mislukte aanvragen

Als een aanvraag voor een eindpunt mislukt, kunt u hoofdoorzaakanalyse uitvoeren met behulp van deductietabellen. Deductietabellen registreren automatisch alle aanvragen en antwoorden op uw eindpunt in een Unity Catalog-tabel, zodat u query's kunt uitvoeren.

• Zie voor externe modellen, ingerichte doorvoereindpunten en AI-agents, het bewaken van weergegeven modellen met behulp van inferentietabellen die door de AI Gateway zijn ingeschakeld.

• Zie voor aangepaste modellen inferentietabellen voor bewaking en foutenopsporing van modellen.

Query's uitvoeren op deductietabellen:

1. Ga in uw werkruimte naar het tabblad Server en selecteer de naam van uw eindpunt.
2. Zoek in de sectie Deductietabellen de volledig gekwalificeerde naam van de deductietabel. Bijvoorbeeld: my-catalog.my-schema.my-table.
3. Voer het volgende uit in een Databricks-notebook:

   %sql
   SELECT * FROM my-catalog.my-schema.my-table
   

4. Bekijk en filter op kolommen zoals request, responserequest_time en status_code om inzicht te verkrijgen in de aanvragen en resultaten te verfijnen.

   %sql
   SELECT * FROM my-catalog.my-schema.my-table
   WHERE status_code != 200
   

5. Als u agenttracering hebt ingeschakeld voor AI-agents, raadpleegt u de kolom Antwoord om gedetailleerde traceringen weer te geven. Zie Deductietabellen inschakelen voor AI-agents.

Werkruimte overschrijdt de voorzien gelijktijdigheid

Mogelijk treedt er een Workspace exceeded provisioned concurrency quota fout op.

U kunt gelijktijdigheid verhogen, afhankelijk van de beschikbaarheid van regio's. Neem contact op met uw Databricks-accountteam en geef uw werkruimte-id op om een gelijktijdigheidsverhoging aan te vragen.

Debugging na een container buildfout

In deze sectie vindt u informatie over problemen die kunnen optreden wanneer uw build mislukt.

OSError: [Errno 28] No space left on device

De No space left fout kan worden veroorzaakt doordat te veel grote artefacten onnodig naast het model worden geregistreerd. Controleer in MLflow of overbodige artefacten niet naast het model worden geregistreerd en probeer het afgeslankte pakket opnieuw te implementeren.

Problemen met Azure Firewall met het leveren van modellen uit Unity Catalog

U kunt de fout zien: 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..

Neem contact op met uw Databricks-accountteam om het probleem op te lossen.

Fout bij het bouwen door gebrek aan beschikbare GPU

Mogelijk ziet u een fout: Build could not start due to an internal error - please contact your Databricks representative..

Neem contact op met uw Databricks-accountteam om het probleem op te lossen.