Déboguer les délais d'expiration de la mise à disposition de modèles

Cet article décrit les différents délais d'expiration que vous pouvez rencontrer lors de l'utilisation d'endpoints de service de modèle et la façon de les gérer. Elle couvre les délais d'expiration du déploiement de modèles, les délais d'expiration côté serveur et les délais d'expiration côté client.

Délais d'expiration de déploiement de modèle

Lorsque vous déployez un modèle ou mettez à jour un déploiement existant à l'aide de Model Serving, le processus peut expirer pour un certain nombre de raisons. La tab Events de la page d'Endpoint de Model Serving enregistre les messages d'expiration. Recherchez sur « timed out » pour les trouver.

remarque

Le processus de déploiement expire si la création du conteneur et le déploiement du modèle dépassent une certaine durée qui dépend de la configuration de la charge de travail de l'Endpoint. Vérifiez votre configuration avant le déploiement et comparez-la aux déploiements précédents réussis.

La construction du conteneur n'a pas de limite stricte, mais effectue jusqu'à 3 nouvelles tentatives. Le déploiement, une fois le conteneur créé, attendra jusqu'à 30 minutes pour les charges de travail CPU, 60 minutes pour les charges de travail GPU petites ou moyennes, et 120 minutes pour les charges de travail GPU grandes avant d'expirer.

Si vous trouvez un message « timed out » , accédez à l'onglet Logs et examinez les logs de build pour en déterminer la cause. Les exemples incluent les problèmes de dépendance des bibliothèques, les contraintes de ressources, les problèmes de configuration, et ainsi de suite.

Voir Déboguer après l'échec de la construction de conteneur.

Dépassements de délai côté serveur

Si votre endpoint est sain selon les onglets Événements et Logs de votre endpoint de service, mais que vous rencontrez des délais d'expiration lorsque vous effectuez des appels à l'endpoint, le délai d'expiration peut être côté serveur. Le délai d'expiration par default varie en fonction du type d'endpoint de mise en service de modèles. Le tableau suivant présente les délais d'expiration par default côté serveur pour les requêtes envoyées aux Endpoint de mise en service de modèles.

Endpoint type	Limite du délai d'expiration des requêtes (secondes)	Notes
Endpoints de service CPU ou GPU	default 597	Cette limite ne peut pas être augmentée.
Endpoint de service de modèles de fondation	default 597	Cette limite ne peut pas être augmentée.

Endpoint type	Limite du délai d'expiration des requêtes (secondes)	Notes
Endpoints de service CPU ou GPU	default 597	Cette limite ne peut pas être augmentée.
Endpoint de service de modèles de fondation	default 597	Cette limite ne peut pas être augmentée.

Pour déterminer si vous avez rencontré un délai d'expiration côté serveur, vérifiez si vos requêtes expirent avant ou après les limites indiquées ci-dessus.

• Si votre requête échoue systématiquement à la limite, il s'agit probablement d'un dépassement de délai côté serveur.
• Si votre requête échoue avant la limite, cela peut être dû à des problèmes de configuration.
  • Vérifiez les Logs de service pour déterminer s'il y a d'autres erreurs.
  • Confirmez que le modèle a fonctionné localement, par exemple à partir d'un Notebook, ou sur des requêtes précédentes sur des versions antérieures.

Dépassements de délai côté client : configuration MLflow

Les délais d'expiration côté client renvoient généralement des messages d'erreur indiquant « délai d'expiration dépassé » ou **requête incorrecte 4xx**. Les causes courantes de ces délais d'expiration proviennent des configurations des variables d'environnement MLflow. Voici les variables d'environnement MLflow les plus courantes pour les délais d'expiration. Pour la liste complète des variables de délai d'attente, consultez la documentation mlflow.environment_variables.

• MLFLOW_HTTP_REQUEST_TIMEOUT : Spécifie le délai d'expiration en secondes pour les requêtes HTTP MLflow. default timeout 120 secondes.
• MLFLOW_HTTP_REQUEST_MAX_RETRIES : Spécifie le nombre maximal de tentatives avec un délai d'attente exponentiel pour les requêtes HTTP MLflow. Default est de 7 secondes.

remarque

Les délais d’expiration des requêtes HTTP côté client sont définis à 120 secondes, ce qui diffère du délai d’expiration par default côté serveur de 597 secondes pour les Endpoints de service CPU et GPU. Ajustez les variables d'environnement MLflow en conséquence si vous vous attendez à ce que votre charge de travail dépasse le délai d'expiration côté client de 120 secondes.

Effectuez l'une des opérations suivantes pour déterminer si un délai d'expiration est dû à une configuration de variable d'environnement MLflow :

• Testez le modèle localement à l'aide d'exemples d'entrées, par exemple dans un notebook, pour confirmer qu'il fonctionne comme prévu avant d'enregistrer le modèle et de le déployer.

  • Examinez le temps nécessaire pour traiter les requêtes.
    • Si les requêtes dépassent les délais d'expiration par default des variables d'environnement MLflow ou si vous recevez un message « timed out » dans le notebook. Exemple de message ***« timed out »*** :
    • Timed out while evaluating the model. Verify that the model evaluates within the timeout.

• Testez l'endpoint de mise en service du modèle au moyen de requêtes POST.

  • Vérifiez les **Logs de service** pour votre Endpoint ou les tables d'inférence si vous les avez activées.

Configurer les variables d'environnement MLflow

Configurez les variables d'environnement MLflow à l'aide de l'interface utilisateur de service ou par programme à l'aide de Python.

Serving UI

Vous pouvez configurer des variables d'environnement pour un déploiement de modèle

1. Sélectionnez l'Endpoint pour lequel vous souhaitez configurer une variable d'environnement.
2. Sur la page de l'Endpoint, sélectionnez Modifier en haut à droite.
3. Dans « Détails de l'entité » , développez Configuration avancée pour ajouter la variable d'environnement de délai d'attente MLflow pertinente.

Voir Ajouter des variables d’environnement en texte brut.

Python

Vous pouvez configurer par programmation un endpoint de service de modèle et inclure des variables d'environnement MLflow ajustées à l'aide de Python. L'exemple suivant ajuste le délai d'expiration maximal à 300 secondes et le nombre maximal de nouvelles tentatives à trois.

Pour plus de détails sur la charge utile nécessaire à sa configuration, consultez la page de l'API Databricks.

Python

import mlflow.deployments

# Get the deployment client
client = mlflow.deployments.get_deploy_client("databricks")

# Define the configuration with environment variables
config = {
   "served_entities": [
       {
           "name": "sklearn_example-1",
           "entity_name": "catalog.schema.model_name",
           "entity_version": "1",
           "workload_size": "Small",
           "workload_type": "CPU",
           "scale_to_zero_enabled": True,
           "environment_vars": {
               "MLFLOW_HTTP_REQUEST_MAX_RETRIES": 3,
               "MLFLOW_HTTP_REQUEST_TIMEOUT": 300
           }
       },
   ],
   "traffic_config": {
       "routes": [
           {
               "served_model_name": "model_name-1",
               "traffic_percentage": 100
           }
       ]
   }
}

# Create the endpoint with the specified configuration
endpoint = client.create_endpoint(
   name="model_name-1",
   config=config
)

Délais d'attente côté client : APIs client tierces

Les délais d'expiration côté client renvoient généralement des messages d'erreur indiquant « délai d'expiration dépassé » ou **requête incorrecte 4xx**. Semblables aux configurations MLflow, les APIs clientes tierces peuvent provoquer des délais d'attente côté client en fonction de leur configuration. Ces éléments peuvent avoir un impact sur les Endpoints de service de modèle qui se composent de pipelines utilisant ces APIs client tierces. Consultez les modèles PyFunc personnalisés et les agents de schémas personnalisés PyFunc.

De manière similaire aux instructions de debugging de la configuration MLflow, procédez comme suit pour déterminer si un délai d'attente est causé par des APIs clientes tierces utilisées dans votre pipeline de modèle :

• Testez le modèle localement avec des entrées d'échantillon dans un notebook.

  • Si vous voyez un message « timed out » dans le notebook, ajustez les paramètres pertinents pour la fenêtre de temporisation du client tiers.
  • Exemple de message « délai d'attente dépassé » : APITimeoutError: Request timed out.

• Testez l'endpoint de mise en service du modèle au moyen de requêtes POST.

  • Vérifiez les **Logs de service** pour votre Endpoint ou les tables d'inférence si vous les avez activées.

Exemple de client OpenAI

Lorsque vous établissez un client OpenAI, vous pouvez configurer le parameter timeout pour modifier le temps maximal avant l'expiration d'une requête côté client. Le délai d'expiration par default et maximal pour un client OpenAI est de 10 minutes.

L’exemple suivant montre comment configurer un délai d’expiration pour les APIs d’un client tiers.

Python

%pip install openai==1.54.0
dbutils.library.restartPython()

from openai import OpenAI
import os

# How to get your Databricks token: https://docs.databricks.com/en/dev-tools/auth/pat.html
DATABRICKS_TOKEN = os.environ.get('DATABRICKS_TOKEN')
client = OpenAI(
    timeout=10, # Number of seconds before client times out
    api_key=DATABRICKS_TOKEN,
    base_url="<WORKSPACE_URL>/serving-endpoints"
)

chat_completion = client.chat.completions.create(
    messages=[
        {
            "role": "system",
            "content": "You are an AI assistant"
        },
        {
            "role": "user",
            "content": "Tell me about Large Language Models."
        }
    ],
    model="model_name",
    max_tokens=256
)

remarque

Pour le client OpenAI, vous pouvez contourner la fenêtre de délai d'expiration maximale en activant le streaming.

Autres délais d'expiration

Démarrage des Endpoint inactifs

Si un endpoint est mis à l'échelle à 0 et qu'il reçoit une requête qui le met en service, cela pourrait potentiellement entraîner une expiration du délai côté client s'il faut trop de temps pour le mettre en service. Cela peut être une cause de délais d'expiration dans les pipelines qui s'appuient sur des étapes telles que des appels à des endpoints de throughput provisionné ou des index de recherche IA, comme mentionné ci-dessus.

Délai d'expiration de la connexion

Les délais d'attente de connexion sont liés au temps qu'un client attend pour établir une connexion avec le serveur. Si la connexion n'est pas établie dans ce délai, le client annule la tentative. Il est important d'être conscient des clients utilisés dans votre pipeline de modèles et de vérifier les logs de service et les tables d'inférence de l'endpoint de Model Serving pour détecter d'éventuels dépassements de délai de connexion. La messagerie varie en fonction du service.

• Par exemple, un SocketTimeout (pour un service lisant/écrivant sur un SQL Endpoint via une connexion JDBC) peut se présenter comme suit :

  • jdbc:spark://<server-hostname>:443;HttpPath=<http-path>;TransportMode=http;SSL=1[;property=value[;property=value]];SocketTimeout=300

• Pour les trouver, recherchez les messages d'erreur contenant le terme ***« timed out »*** ou ***« timeout »***.

Limites de débit

Plusieurs requêtes effectuées au-delà de la limite de vitesse d'un Endpoint pourraient entraîner l'échec de requêtes supplémentaires. Consultez les limites de ressources et de charge utile pour les limites de taux basées sur les types d'endpoint. Pour les clients tiers, Databricks vous recommande de consulter la documentation du client tiers que vous utilisez.