Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Découvrez comment optimiser les points de terminaison Model Service pour les charges de travail de production qui nécessitent un débit élevé, une faible latence et des performances fiables.
Les stratégies d’optimisation se répartissent en trois catégories :
- Optimisations des points de terminaison : Configurer l’infrastructure de point de terminaison pour améliorer les performances
- Optimisations des modèles : améliorer l’efficacité et le débit du modèle
- Optimisations des clients : optimiser l’interaction des clients avec les points de terminaison de service
Quand optimiser votre point de terminaison
Envisagez d’optimiser votre point de terminaison Model Service 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 point de terminaison unique
- Exigences en matière de latence : votre application nécessite des temps de réponse de sous-100 ms
- Goulots d'étranglement d'échelle : les points de terminaison subissent des files d'attente ou renvoient des erreurs HTTP 429 pendant les pics de trafic
- Optimisation des coûts : vous souhaitez réduire les coûts de service tout en conservant les objectifs de performances
- Préparation de la production : 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 calcul.
Optimisation des itinéraires
L’optimisation des itinéraires offre l’amélioration de l’infrastructure la plus importante pour les charges de travail à débit élevé. Lorsque vous activez l’optimisation de l’itinéraire sur un point de terminaison, Databricks Model Service améliore le chemin réseau des demandes d’inférence, ce qui accélère la communication directe entre les clients et les modèles.
Avantages en matière de performances :
| Caractéristique | Limite de point de terminaison standard | Limite de point de terminaison optimisée pour l’itinéraire |
|---|---|---|
| Requêtes par seconde (QPS) par espace de travail | 200 | 50 000 + (contactez Databricks pour des limites plus élevées) |
| Concurrence du client par espace de travail | 192-1024 (varie selon la région) | Aucune limite explicite (limitée par la concurrence provisionnée) |
| Concurrence provisionnée par point d'accès pour chaque entité servie | 1,024 | 1 024 (contactez Databricks pour des limites plus élevées) |
Quand utiliser l’optimisation de l’itinéraire :
- Charges de travail nécessitant plus de 200 QPS
- Applications avec des exigences strictes en matière de latence (surcharge inférieure à 50 ms)
- Déploiements de production servant plusieurs utilisateurs simultanés
Important
L’optimisation des itinéraires est disponible uniquement pour les points de terminaison du modèle de service personnalisé. Les API Foundation Model et les modèles externes ne prennent pas en charge l’optimisation des itinéraires. Les jetons OAuth sont requis pour l’authentification ; Les jetons d’accès personnels ne sont pas pris en charge.
Consultez Optimisation des itinéraires sur les points de terminaison de service pour les instructions de configuration et Points de terminaison de service optimisés pour les requêtes pour les détails d’interrogation.
Accès concurrentiel provisionné
L’accès concurrentiel approvisionné contrôle le nombre de demandes simultanées que votre point de terminaison peut traiter. Configurez l’accès concurrentiel provisionné en fonction de vos exigences de QPS et de latence attendues.
Instructions de configuration :
- Concurrence minimale : Réglez suffisamment haut pour gérer le trafic de base sans mise en file d'attente
- Concurrence maximale : définir suffisamment haut pour prendre en charge les pics de trafic tout en contrôlant les coûts
- Mise à l’échelle automatique : activer la mise à l’échelle automatique pour ajuster dynamiquement la capacité en fonction de la demande
Calculez 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 d’accès concurrentiel optimaux.
Types d’instances
Choisissez les types d’instances en fonction des besoins de calcul de votre modèle :
| Type d’instance | Idéal pour | Trade-offs |
|---|---|---|
| PROCESSEUR (petite, moyenne, grande) | Modèles légers, logique d’inférence simple | Moindre coût, plus lent pour les modèles nécessitant beaucoup de ressources de calcul |
| GPU (petite, moyenne, grande) | Modèles volumineux, calculs complexes, traitement image/vidéo | Coût plus élevé, performances optimales pour le Deep Learning |
Conseil / Astuce
Commencez par les instances de processeur pour le développement et le test. Basculez vers des instances GPU uniquement si vous observez une latence d’inférence élevée ou si votre modèle nécessite un calcul spécialisé (par exemple, des opérations d’apprentissage profond).
Optimisations des modèles
Les optimisations de modèle améliorent la vitesse d’inférence et l’efficacité des ressources.
Taille et complexité du modèle
Taille et complexité du modèle : les modèles plus petits et moins complexes entraînent généralement des temps d’inférence plus rapides et des QPS plus élevés. Considérez des techniques telles que la quantification de modèle ou l'élagage si votre modèle est grand.
Batching
Si votre application peut envoyer plusieurs requêtes dans un seul appel, activez le traitement par lots côté client. Cela peut réduire considérablement la surcharge par prédiction.
Prétraitement et optimisation post-traitement
Déchargez le prétraitement complexe et le post-traitement à partir des points de terminaison 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 points de terminaison de service.
Regroupement de connexions
Le regroupement de connexions réutilise les connexions existantes au lieu de créer de nouvelles connexions pour chaque requête, ce qui réduit considérablement la surcharge.
- Utilisez le Kit de développement logiciel (SDK) Databricks, qui implémente automatiquement les meilleures pratiques de regroupement de connexions
- Si vous utilisez des clients personnalisés, implémentez vous-même le regroupement de connexions.
Stratégies de gestion des erreurs et de nouvelle tentative
Implémentez une gestion robuste des erreurs pour gérer correctement les défaillances temporaires, en particulier pendant les événements de mise à l’échelle automatique ou les interruptions réseau.
Optimisation de la taille de la charge utile
Réduisez les tailles de charge utile de requête et de réponse pour réduire le temps de transfert réseau et améliorer le débit.
Mesurer et améliorer les performances
analyse des performances.
Surveillez les performances des points de terminaison à l’aide des outils fournis par Mosaïque AI Model Service :
| Unité de mesure | Ce qu’il mesure | Cible | Action si elle est dépassée |
|---|---|---|---|
| Latence (P50, P90, P99) | Temps de réponse pour les demandes | Dépendant de l’application (généralement <100 à 500 ms) | Vérifier la mise en file d’attente, optimiser le modèle ou le client |
| Débit (QPS) | Demandes terminées par seconde | Dépendant de la charge de travail | Activer l'optimisation de la route, augmenter la simultanéité provisionnée |
| Taux d’erreur | Pourcentage de demandes ayant échoué | <1% | Passer en revue les journaux de service, rechercher les problèmes de capacité |
| Profondeur de file d’attente | Demandes en attente de traitement | 0 (sans file d’attente) | Augmenter la concurrence provisionnée ou activer la mise à l’échelle automatique |
| Utilisation du processeur/de la mémoire | Utilisation des ressources | <80% | Augmenter le type d’instance ou augmenter la concurrence |
Consultez Surveiller la qualité du modèle et l’intégrité des points de terminaison pour obtenir des conseils de surveillance détaillés et suivre et exporter les mesures d’intégrité des points de terminaison vers Prometheus et Datadog pour exporter des métriques vers des outils d’observabilité.
Test de charge
Les tests de charge mesurent les performances des points de terminaison dans des conditions de trafic réalistes et vous aident à :
- Déterminer les paramètres optimaux de concurrence provisionnée
- Identifier les goulots d’étranglement des performances
- Valider les exigences en matière de latence et de débit
- Comprendre la relation entre la concurrence cliente et la concurrence du serveur
Consultez Le test de charge pour le service des points de terminaison.
Résoudre les problèmes de performance courants
Mise en file d'attente
Model Service prend en charge la mise à l’échelle automatique pour ajuster la capacité en fonction des modèles de trafic. Toutefois, les pics de trafic soudains peuvent entraîner une mise en file d’attente, car la mise à l’échelle automatique nécessite du temps pour détecter une charge accrue et approvisionner une capacité supplémentaire. Pendant cette période, les requêtes entrantes peuvent dépasser temporairement la capacité disponible, ce qui entraîne la file d’attente des demandes.
La mise en file d’attente se produit lorsque le taux de requête ou la concurrence dépasse la capacité de traitement actuelle du point de terminaison. Cela se produit généralement pendant des pics de trafic importants, des rafales de charge de travail ou lorsque le point d'accès final a une capacité provisionnée insuffisante. Les points de terminaison de service de modèle permettent la mise en file d’attente temporaire pour gérer les rafales, mais au-delà d’un seuil défini, le point de terminaison retourne 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 demandes mises en file d’attente attendent avant d’être traitées. Pour réduire la file d’attente :
- Définir une concurrence provisionnée minimale suffisamment élevée pour gérer le trafic de référence et les rafales classiques
- Activer l’optimisation des itinéraires pour des limites de capacité supérieures
- Implémentez une logique de nouvelle tentative avec retrait exponentiel dans vos applications clientes.
Goulots d’étranglement de l’API externe
Les modèles appellent souvent des API externes pour l’enrichissement des données, la récupération des fonctionnalités ou d’autres tâches pendant l’inférence. Ces dépendances externes peuvent devenir des goulots d’étranglement des performances :
- Latence : mesurez le temps de réponse de chaque appel d’API externe. La latence élevée dans ces appels augmente directement la latence globale de service et réduit le débit.
- Limites de débit : les API externes peuvent imposer des limites de débit ou des contraintes de capacité. Le dépassement de ces limites peut entraîner un bridage, des erreurs et une dégradation des performances.
- Taux d’erreurs : les erreurs fréquentes provenant d’API externes peuvent déclencher des nouvelles tentatives et augmenter la charge sur votre point de terminaison de service.
- Mise en cache : implémentez la mise en cache pour les données fréquemment sollicitées à partir d’API externes afin de réduire le nombre d’appels et d’améliorer les temps de réponse.
Surveillez ces facteurs pour identifier les goulots d’étranglement et implémenter des optimisations ciblées pour les charges de travail à débit élevé.