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.
Augmentez progressivement le trafic des modèles via Unity Gateway lors du lancement d’une charge de travail ou du changement de modèle. Ces recommandations s’appliquent aux modèles propriétaires et aux modèles à poids ouverts fournis par Azure Databricks, ainsi qu’aux modèles accessibles par l’intermédiaire de fournisseurs externes connectés.
Augmentez progressivement le trafic
La capacité disponible dépend du modèle, du fournisseur, de la région et du mode de service. Les requêtes peuvent rencontrer des erreurs temporaires de capacité même lorsque le trafic reste dans les limites de débit configurées. Une augmentation de quota seule ne réserve pas la capacité de service.
Pour augmenter le débit :
- Vérifiez les limites de débit de service configurées et celles du modèle ou du fournisseur externe. Estimer les taux de jetons d’entrée et de sortie ainsi que les requêtes concurrentes, y compris les tailles représentatives des prompts et des réponses.
- Commencez à un niveau de trafic stable et connu. Pour une nouvelle charge de travail, commencez par une charge réduite et représentative.
- Augmentez le trafic par petites étapes. Maintenez chaque niveau stable tout en surveillant le taux de réussite des requêtes, la latence, l’utilisation des jetons, la profondeur de file d’attente et les erreurs de limitation ou de capacité. Augmentez à nouveau uniquement lorsque la charge de travail est stable et qu’elle répond aux objectifs opérationnels de votre application.
- Si le bridage, les erreurs de capacité ou la latence dépassent la tolérance de votre application, suspendez la montée en charge et revenez au dernier niveau de trafic stable. Réduisez le parallélisme et mettez en file d’attente ou reportez les tâches moins prioritaires.
Choisissez la taille des pas et les périodes d’observation en fonction de votre charge de travail et des recommandations du modèle ou du prestataire. Répétez cette validation lors du changement de modèle, de région ou de capacité de service.
Gérer les erreurs de limitation du débit et de capacité
Inspectez à la fois le statut HTTP et le corps de l’erreur de l’API que vous appelez. Les codes d’erreur et les messages peuvent différer entre les API unifiées et celles propres aux fournisseurs.
| Response | Sens et action |
|---|---|
429 Too Many Requests |
Une limite de taux configurée ou un throttling en aval empêche la requête. Certains fournisseurs limitent également le débit en cas de forte augmentation soudaine du trafic. Identifiez la limite à partir du corps d’erreur, réduisez le taux de requête et augmentez progressivement le trafic. Si l’erreur nécessite un changement de quota ou de facturation, résolvez cette condition avant de réessayer. |
503 Service Unavailable |
Le service ou le modèle est temporairement incapable de traiter la requête. Cela peut se produire lors d’une augmentation du trafic, même lorsque les limites de débit configurées ne sont pas atteintes. Réessayez dans la limite d’un budget de tentatives défini et suspendez l’augmentation progressive de la charge si les erreurs persistent. |
| Autres erreurs de surcharge du fournisseur | Certaines API de fournisseurs utilisent d’autres réponses, comme 529, pour la surcharge temporaire. Suivez les recommandations de gestion des erreurs propres au fournisseur et à l’API que vous utilisez. |
Une erreur de capacité seule ne confirme pas que l’autoscaling est en cours ni n’indique quand la capacité devient disponible.
Configurer les nouvelles tentatives
- Honorez l’en-tête
Retry-Afterlorsque la réponse l’inclut. Sinon, réessayez en cas de limitation temporaire ou d’erreurs de capacité, avec un backoff exponentiel et un jitter aléatoire. - Limitez le nombre total de tentatives et le temps écoulé pour correspondre au budget de latence de votre application. Si les erreurs persistent, réduisez le trafic au lieu d’ajouter davantage de tentatives.
- Vérifiez le comportement de nouvelle tentative du SDK avant d’ajouter des nouvelles tentatives au niveau de l’application. Prenez en compte les réessais entre les couches pour éviter qu’ils ne multiplient la charge.
- Gérer les erreurs après le début d’une réponse en flux dans le consommateur de flux. Rejouer une requête après avoir reçu un résultat peut dupliquer le résultat ou le traitement.
Pour des erreurs persistantes, contactez l’équipe en charge de votre compte Databricks avec les identifiants de demande, les horodatages, les noms de modèles et de fournisseurs, les débits de jetons observés, le niveau de concurrence et le calendrier de la montée en charge du trafic. Pour les fournisseurs externes connectés, vérifiez également le statut du service et les limites de compte du fournisseur.
Inférence par lots
Pour de grandes charges de travail hors ligne avec des modèles pris en charge, utilisez AI Functions, qui gèrent la parallélisation, les tentatives et la mise à l’échelle. Suivez leur guide d’inférence par lots au lieu d’appliquer une boucle de nouvelle tentative distincte à chaque ligne.