Monter en charge le throughput d'inférence de modèles
Augmentez progressivement le trafic du modèle via Unity Gateway lors du lancement d’une charge de travail ou du changement de modèle. Ce guide s’applique aux modèles propriétaires et aux modèles à poids ouverts fournis par Databricks ainsi qu’aux modèles accessibles par l’intermédiaire de fournisseurs externes connectés.
Augmenter le trafic progressivement
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 de capacité temporaires même lorsque le trafic reste dans les limites de débit configurées. Une augmentation de quota seule ne réserve pas de capacité de service.
Pour augmenter le throughput :
- Vérifiez les limites de débit de service configurées ainsi que les limites du modèle ou du fournisseur externe. Estimez les taux de jetons d’entrée et de sortie ainsi que les requêtes simultanées, y compris les tailles représentatives des messages et des réponses.
- Start à un niveau de trafic stable connu. Pour une nouvelle charge de travail, start avec une petite charge représentative.
- Augmenter le trafic par petites étapes. Maintenir chaque niveau stable tout en monitoring le taux de succès des requêtes, la latence, l’utilisation des jetons, la profondeur de la file d’attente et les erreurs de limitation ou de capacité. Augmentez à nouveau uniquement lorsque la charge de travail est stable et atteint les objectifs de fonctionnement de votre application.
- En cas de limitation, d’erreurs de capacité ou d’augmentation de la latence au-delà de la tolérance de votre application, suspendez la montée en charge et revenez au dernier niveau de trafic stable. Réduisez la concurrence et mettez en file d’attente ou reportez les tâches de moindre priorité.
Choisissez des tailles de pas et des périodes d’observation basées sur votre charge de travail et les conseils pour le modèle ou le fournisseur. Répétez cette validation lors du changement de modèles, de régions ou de capacité de service.
Gérer les erreurs de limitation de débit et de capacité
Vérifiez 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 APIs unifiées et les APIs natives du fournisseur.
Réponse | Signification et action |
|---|---|
| Une limite de débit configurée ou une limitation en aval empêche la demande. Certains fournisseurs limitent également les augmentations soudaines du trafic. Identifiez la limite à partir du corps de l’erreur, réduisez le débit de la demande et augmentez progressivement le trafic. Si l’erreur nécessite une modification de quota ou de facturation, résolvez cette condition avant de réessayer. |
| Le service ou le modèle est temporairement incapable de traiter la requête. Cela peut se produire lors d’une augmentation du trafic, y compris en dessous des limites de débit configurées. Réessayez dans la limite d’un budget défini et suspendez la montée en charge si les erreurs persistent. |
Autres erreurs de surcharge du fournisseur | Certaines API de fournisseur utilisent d’autres réponses, telles que |
Une erreur de capacité seule n’établit pas que la mise à l’échelle automatique est en cours ni n’indique quand la capacité devient disponible.
Configurer les nouvelles tentatives
- Respectez l’en-tête
Retry-Afterlorsque la réponse l’inclut. Sinon, réessayez les erreurs de limitation et de capacité transitoires avec un backoff exponentiel et une gigue aléatoire. - Limitez le nombre total de tentatives et le temps écoulé pour respecter le 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 nouvelles tentatives à travers les couches afin qu’elles ne multiplient pas la charge.
- Gérez les erreurs après le start d’une réponse en streaming dans le consommateur de Stream. La relecture d’une requête après la réception de la sortie peut dupliquer la sortie ou le travail.
Pour les erreurs persistantes, contactez votre équipe de compte Databricks avec les IDs de demande, les Timestamp, les noms de modèle et de fournisseur, les taux de jetons observés, la simultanéité et le calendrier d’augmentation 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 batch
Pour les charges de travail hors ligne importantes avec des modèles pris en charge, utilisez AI Functions, qui gèrent la parallélisation, les nouvelles tentatives et la mise à l'échelle. Suivez les instructions d'inférence par batch au lieu d'appliquer une boucle de nouvelle tentative distincte à chaque ligne.