Optimiser les Model Serving Endpoint pour la production
Découvrez comment optimiser les endpoints de Model Serving pour les charges de travail de production qui nécessitent un throughput élevé, une faible latence et des performances fiables.
Les stratégies d'optimisation se répartissent en trois catégories :
- Optimisations d'Endpoint: Configurez l'infrastructure d'Endpoint pour une meilleure performance
- Optimisations de modèle: Améliorez l’efficacité et le throughput du modèle
- Optimisations client: Optimiser la manière dont les clients interagissent avec les endpoints de diffusion
Quand optimiser votre Endpoint
Envisagez d’optimiser votre endpoint de Model Serving lorsque vous rencontrez l’un des scénarios suivants :
- Volume de requêtes élevé : votre application envoie plus de 50 000 requêtes par seconde (QPS) à un endpoint unique
- Exigences en matière de latence : Votre application nécessite des temps de réponse inférieurs à 100 ms
- Goulots d'étranglement de mise à l'échelle : les Endpoints connaissent une mise en file d'attente ou renvoient des erreurs HTTP 429 lors des pics de trafic
- Optimisation des coûts : vous souhaitez réduire les coûts de service tout en maintenant les objectifs de performance
- Préparation à la production : Vous vous préparez à passer du développement aux charges de travail de production
Optimisations de l'infrastructure
Les optimisations de l'infrastructure améliorent le routage réseau, le comportement de mise à l'échelle et la capacité de compute.
Optimisation des itinéraires
L'optimisation des routes offre l'amélioration d'infrastructure la plus significative pour les charges de travail à haut throughput. Lorsque vous activez l'optimisation des routes sur un Endpoint, Databricks Model Serving améliore le chemin réseau pour les requêtes d'inférence, ce qui se traduit par une communication plus rapide et plus directe entre les clients et les modèles.
Avantages en termes de performances :
Fonctionnalité | Limite d'Endpoint standard | Limite d'endpoint optimisé pour l'itinéraire |
|---|---|---|
Requêtes par seconde (QPS) par Workspace | 200 | 50 000+ (contactez Databricks pour des limites plus élevées) |
Concurrence client par workspace | De 192 à 1 024 (varie selon la région) | Aucune limite explicite (limité par la simultanéité de provisionnement) |
Concurrence provisionnée des Endpoint par entité servie | 1 024 | 1 024 (contactez Databricks pour des limites supérieures) |
Quand utiliser l'optimisation des itinéraires :
- Charges de travail nécessitant plus de 200 QPS
- Applications avec des exigences strictes en matière de latence (surcoût inférieur à 50 ms)
- Déploiements de production servant plusieurs utilisateurs simultanés
L’optimisation des routes n’est disponible que pour les Endpoint de service de modèle personnalisés. Les APIs de modèle de fondation et les modèles externes ne prennent pas en charge l'optimisation du routage. Les jetons OAuth sont requis pour l’authentification ; les jetons d’accès personnels ne sont pas pris en charge.
Consultez Optimisation du routage sur les Endpoint de diffusion pour les instructions de configuration et Interrogation des Endpoint de diffusion optimisés pour le routage pour les détails de l'interrogation.
Simultanéité provisionnée
La simultanéité provisionnée contrôle le nombre de requêtes simultanées que votre endpoint peut traiter. Configurez la simultanéité provisionnée en fonction de vos exigences attendues en matière de QPS et de latence.
Consignes de configuration :
- Concurrence minimale : Réglez-la suffisamment haut pour gérer le trafic de base sans file d'attente
- Simultanéité maximale : Définissez-la suffisamment élevée pour faire face aux pics de trafic tout en maîtrisant les coûts.
- Dimensionnement automatique : activez le dimensionnement automatique pour ajuster dynamiquement la capacité en fonction de la demande.
Calculer la concurrence requise :
Required Concurrency = Target QPS × Average Latency (seconds)
Par exemple, si votre cible est de 100 QPS avec une latence moyenne de 200 ms :
Required Concurrency = 100 × 0.2 = 20
Utilisez des tests de charge pour mesurer la latence réelle et déterminer les paramètres de concurrence optimaux.
Types d'instances
Choisissez les types d'instances en fonction des exigences de compute de votre modèle :
Type d'instance | Idéal pour | Compromis |
|---|---|---|
Processeur (petit, moyen, grand) | Modèles légers, logique d'inférence simple | Coût inférieur, plus lent pour les modèles à forte intensité de compute |
GPU (Petit, Moyen, Grand) | Grands modèles, calculs complexes, traitement d'images/vidéos | Coût plus élevé, performances optimales pour le deep learning |
Start par des instances de CPU pour le développement et les tests. Passez aux instances GPU uniquement si vous observez une latence d'inférence élevée ou si votre modèle nécessite un compute spécialisé (telles que les opérations d'apprentissage profond).
Optimisations de modèles
Les optimisations des modèles améliorent la vitesse d’inférence et l’efficacité des Ressources.
Taille du modèle et complexité
Taille et complexité du modèle : les modèles plus petits et moins complexes conduisent généralement à des temps d'inférence plus rapides et à un QPS plus élevé. Envisagez des techniques telles que la quantification ou l'élagage du modèle si votre modèle est volumineux.
Batch
Si votre application peut envoyer plusieurs requêtes en un seul appel, activez le traitement par batch côté client. Cela peut réduire considérablement la charge de travail par prédiction.
Optimisation du prétraitement et du post-traitement
Déchargez le pré-traitement et le post-traitement complexes des Endpoint de service pour réduire la charge sur l'infrastructure d'inférence.
Optimisations côté client
Les optimisations côté client améliorent la façon dont les applications interagissent avec les Endpoint de service.
Pool de connexions
Le pooling de connexions réutilise les connexions existantes au lieu de créer de nouvelles connexions pour chaque requête, réduisant considérablement la surcharge.
- Utilisez le Databricks SDK, qui implémente automatiquement les meilleures pratiques de regroupement de connexions
- Si vous utilisez des clients personnalisés, implémentez vous-même la mise en commun des connexions.
Gestion des erreurs et stratégies de nouvelle tentative
Implémentez une gestion robuste des erreurs pour gérer avec élégance les défaillances temporaires, en particulier lors d'événements d'autoscaling ou de disruptions réseau.
Optimisation de la taille de la charge utile
Réduisez la taille des charges utiles des requêtes et des réponses afin de réduire le temps de transfert réseau et d'améliorer le throughput.
Mesurer et améliorer les performances
Monitoring des performances
Surveillez les performances des Endpoint à l'aide des outils fournis par Model Serving :
Métriques | Ce qu'il mesure | Cible | Action en cas de dépassement |
|---|---|---|---|
Latence (P50, P90, P99) | Temps de réponse pour les requêtes | Dépend de l'application (généralement <100-500 ms) | Vérifiez la mise en file d'attente, optimisez le modèle ou le client. |
Throughput (QPS) | Requêtes terminées par seconde | Dépend du Workload | Activer l'optimisation des itinéraires, augmenter la simultanéité provisionnée |
Taux d'erreur | Pourcentage de requêtes ayant échoué | <1% | Examinez les Logs de service, vérifiez les problèmes de capacité |
Profondeur de la file d'attente | Requêtes en attente de traitement | 0 (pas de mise en file d'attente) | Augmenter la simultanéité provisionnée ou activer l'autoscaling |
Utilisation du CPU/de la mémoire | Utilisation des ressources | <80% | Monter en charge le type d'instance ou accroître la concurrence |
Consultez Surveiller la qualité des modèles et la santé des Endpoint pour des conseils détaillés sur le monitoring et Suivre et exporter les métriques de santé des Endpoint de service vers Prometheus et Datadog pour exporter des métriques vers des outils d'observabilité.
Tests de charge
Les tests de charge mesurent les performances de l'Endpoint dans des conditions de trafic réalistes et vous aident à :
- Déterminez les paramètres optimaux de provisionnement simultané
- Identifiez les goulots d'étranglement des performances
- Valider les exigences de latence et de throughput
- Comprendre la relation entre la concurrence du client et celle du serveur.
Voir Tests de charge pour les Endpoint de service.
Résoudre les problèmes de performance courants
Mise en file d'attente
Model Serving prend en charge l'autoscaling pour ajuster la capacité en fonction des modèles de trafic. Cependant, les pics de trafic soudains peuvent provoquer des mises en file d'attente, car l'autoscaling nécessite du temps pour détecter une charge accrue et provisionner une capacité supplémentaire. Pendant cette période, les requêtes entrantes peuvent temporairement dépasser la capacité disponible, ce qui entraîne la mise en file d'attente des requêtes.
La mise en file d'attente se produit lorsque le taux de requêtes ou la simultanéité dépasse la capacité de traitement actuelle de l'endpoint. Cela se produit généralement lors de pics de trafic importants, de surcharges de travail ou lorsque l'Endpoint a une simultanéité provisionnée insuffisante. Les Endpoints de Model Serving permettent une mise en file d'attente temporaire pour gérer les pics, mais au-delà d'un threshold défini, l'Endpoint renvoie des erreurs HTTP 429 (Trop de requêtes) pour protéger la stabilité du système.
La mise en file d'attente augmente la latence car les requêtes en attente attendent d'être traitées. Pour minimiser la mise en file d'attente :
- Définissez une simultanéité provisionnée minimale suffisamment élevée pour gérer le trafic de base et les pics typiques.
- Activer l’optimisation des itinéraires pour des limites de capacité plus élevées
- Mettez en œuvre une logique de nouvelle tentative avec interruption exponentielle dans vos applications clientes.
Goulots d'étranglement de l'API externe
Les modèles appellent souvent des APIs externes pour l'enrichissement de données, la récupération de fonctionnalités ou d'autres tâches pendant l'inférence. Ces dépendances externes peuvent devenir des goulots d'étranglement de performance :
- Latency : Mesurez le temps de réponse de chaque appel d'API externe. Une latence élevée dans ces appels augmente directement la latence globale du service et réduit le throughput.
- **Limites de throughput** : les APIs externes peuvent imposer des cadences maximales ou des contraintes de capacité. Le dépassement de ces limites peut entraîner des ralentissements, des erreurs et une dégradation des performances.
- Taux d'erreur : des erreurs fréquentes provenant d’APIs externes peuvent Trigger des nouvelles tentatives et augmenter la charge sur votre Endpoint de service.
- Mise en cache : implémentez la mise en cache pour les données fréquemment consultées à partir d'APIs externes afin de réduire le nombre d'appels et d'améliorer les temps de réponse.
Surveillez ces facteurs pour identifier les goulets d'étranglement et mettre en œuvre des optimisations ciblées pour les workloads à haut throughput.