Performances et latence

Article
09/20/2024

Cet article vous fournit des informations générales sur le fonctionnement de la latence et du débit avec Azure OpenAI et sur l’optimisation de votre environnement pour améliorer les performances.

Fonctionnement du débit et de la latence

Il existe deux concepts clés à prendre en compte lors du dimensionnement d’une application : (1) Débit au niveau du système et (2) Temps de réponse par appel (également appelé latence).

Débit au niveau du système

Cela examine la capacité globale de votre déploiement : nombre de requêtes par minute et nombre total de jetons pouvant être traités.

Pour un déploiement standard, le quota attribué à votre déploiement détermine partiellement la quantité de débit que vous pouvez obtenir. Toutefois, le quota détermine uniquement la logique d’admission des appels au déploiement et n’applique pas directement le débit. En raison des variations de latence par appel, il se peut que vous ne puissiez pas atteindre un débit aussi élevé que votre quota. En savoir plus sur la gestion du quota.

Dans un déploiement approvisionné, une quantité définie de capacité de traitement de modèle est allouée à votre point de terminaison. La quantité de débit que vous pouvez obtenir sur le point de terminaison est un facteur de la taille d’entrée, de la taille de sortie, du taux d’appel et du taux de correspondance de cache. Le nombre d’appels simultanés et le nombre total de jetons traités peuvent varier en fonction de ces valeurs. Les étapes suivantes expliquent comment évaluer le débit que vous pouvez obtenir pour une charge de travail donnée dans un déploiement approvisionné :

Utilisez le calculateur de capacité pour obtenir une estimation de la taille.
Étalonnez la charge à l’aide d’une charge de travail en trafic réel. Mesurez les métriques d’utilisation et de jetons traités à partir d’Azure Monitor. Exécuter pendant une période prolongée. Le référentiel d’évaluation Azure OpenAI contient du code permettant d’exécuter le point de référence. Enfin, l’approche la plus précise consiste à exécuter un test avec vos propres caractéristiques de données et de charge de travail.

Voici quelques exemples pour le modèle GPT-4 0613 :

Taille de l’invite (jetons)	Taille de génération (jetons)	Appels par minute	Unités de débit approvisionnées (PTU) nécessaires
800	150	30	100
1 000	50	300	700
5 000	100	50	600

Le nombre de PTU est mis à l’échelle de manière approximativement linéaire avec le taux d’appel (peut être sous-linéaire) lorsque la distribution de la charge de travail reste constante.

Latence : temps de réponse par appel

La définition de haut niveau de la latence dans ce contexte est le temps nécessaire pour obtenir une réponse du modèle. Pour les requêtes de saisie semi-automatique et de saisie semi-automatique de conversation, la latence dépend en grande partie du type de modèle, du nombre de jetons dans l’invite et du nombre de jetons générés. En général, chaque jeton d’invite ajoute peu de temps par rapport à chaque jeton incrémentiel généré.

L’estimation de la latence par appel attendue peut être difficile avec ces modèles. La latence d’une requête de saisie semi-automatique peut varier en fonction de quatre facteurs principaux : (1) le modèle, (2) le nombre de jetons dans l’invite, (3) le nombre de jetons générés et (4) la charge globale sur le déploiement et le système. Les facteurs un et trois sont souvent les principaux contributeurs à la durée totale. La section suivante décrit plus en détail l’anatomie d’un appel d’inférence de grand modèle de langage.

Améliorer les performances

Il existe plusieurs facteurs que vous pouvez contrôler pour améliorer la latence par appel de votre application.

La sélection des modèles

La latence varie en fonction du modèle que vous utilisez. Pour une requête identique, attendez-vous à ce que différents modèles aient des latences différentes pour l’appel de saisie semi-automatique de conversation. Si votre cas d’utilisation requiert les modèles à latence la plus faible avec les temps de réponse les plus rapides, nous vous recommandons le dernier modèle GPT-4o mini.

Taille de génération et nombre maximal de jetons

Lorsque vous envoyez une requête de saisie semi-automatique au point de terminaison Azure OpenAI, votre texte d’entrée est converti en jetons qui sont ensuite envoyés à votre modèle déployé. Le modèle reçoit les jetons d’entrée, puis commence à générer une réponse. Il s’agit d’un processus séquentiel itératif, un jeton à la fois. On peut également l’assimiler à une boucle for avec n tokens = n iterations. Pour la plupart des modèles, la génération de la réponse est l’étape la plus lente du processus.

Au moment de la requête, la taille de génération demandée (paramètre max_tokens) est utilisée comme estimation initiale de la taille de génération. Le temps de calcul nécessaire à la génération de la taille complète est réservé par le modèle à mesure que la requête est traitée. Une fois la génération terminée, le quota restant est libéré. Méthodes pour réduire le nombre de jetons :

Définissez le paramètre max_tokens sur chaque appel aussi petit que possible.
Incluez des séquences d’arrêt pour empêcher la génération de contenu supplémentaire.
Générez moins de réponses : les paramètres best_of et n peuvent augmenter considérablement la latence, car ils génèrent plusieurs sorties. Pour la réponse la plus rapide, ne spécifiez pas ces valeurs ou définissez-les sur 1.

En résumé, la réduction du nombre de jetons générés par requête réduit la latence de chaque requête.

Diffusion en continu

La définition de stream: true dans une requête permet au service de renvoyer les jetons dès qu’ils sont disponibles, au lieu d’attendre la génération complète des jetons. Cela ne modifie pas le temps d’obtention de tous les jetons, mais réduit la durée de la première réponse. Cette approche offre une meilleure expérience utilisateur, car les utilisateurs finaux peuvent lire la réponse telle qu’elle est générée.

La diffusion en continu est également utile pour les appels volumineux dont le traitement prend beaucoup de temps. De nombreux clients et couches intermédiaires ont des délais d’expiration sur des appels individuels. Les appels de génération longs peuvent être annulés en raison d’expirations côté client. En diffusant les données en continu, vous pouvez garantir la réception de données incrémentielles.

Exemples d’utilisation de la diffusion en continu :

Bots de conversation et interfaces conversationnelles.

La diffusion en continu a un impact sur la latence perçue. Si vous avez activé la diffusion en continu, vous recevrez des jetons en blocs dès qu’ils sont disponibles. Pour les utilisateurs finaux, cette approche donne souvent l’impression que le modèle répond plus rapidement, même si la durée totale de traitement de la requête reste le même.

Exemples de cas où la diffusion en continu est moins importante :

Analyse des sentiments, traduction linguistique, génération de contenu.

Il existe de nombreux cas d’usage où vous effectuez une tâche en bloc où vous vous souciez uniquement du résultat final, et non de la réponse en temps réel. Si la diffusion en continu est désactivée, vous ne recevrez aucun jeton tant que le modèle n’a pas terminé la réponse entière.

Filtrage du contenu

Azure OpenAI inclut un système de filtrage du contenu qui fonctionne avec les modèles de base. Ce système fonctionne en exécutant l’invite et l’achèvement par le biais d’un ensemble de modèles de classification visant à détecter et à empêcher la sortie de contenu nuisible.

Le système de filtrage du contenu détecte les catégories spécifiques de contenu potentiellement nuisible dans les invites d’entrée et les achèvements de sortie et prend des mesures correspondantes.

L’ajout du filtrage de contenu s’accompagne d'une augmentation de la sécurité, mais aussi de la latence. Il existe de nombreuses applications où ce compromis en termes de performances est nécessaire, mais il existe certains cas d’usage à risque plus faible où la désactivation des filtres de contenu pour améliorer les performances peut être envisagée.

En savoir plus sur la demande de modifications des stratégies de filtrage de contenu par défaut.

Séparation des charges de travail

Le mélange de différentes charges de travail sur le même point de terminaison peut affecter négativement la latence. Cela est dû au fait que (1) ils sont regroupés ensemble pendant l’inférence et les appels courts peuvent attendre des saisies semi-automatiques plus longues et (2) le mélange des appels peut réduire le taux de correspondance dans votre cache car ils sont tous les deux concurrents pour le même espace. Lorsque cela est possible, il est recommandé d’avoir des déploiements distincts pour chaque charge de travail.

Taille de l’invite

Bien que la taille de l’invite ait une influence plus petite sur la latence que la taille de génération, elle affecte la durée globale, en particulier lorsque la taille augmente.

Traitement par lot

Si vous envoyez plusieurs requêtes au même point de terminaison, vous pouvez regrouper les requêtes en un seul appel. Cela réduit le nombre de requêtes que vous devez effectuer et en fonction du scénario, cela peut améliorer le temps de réponse global. Nous vous recommandons de tester cette méthode pour voir si elle est utile.

Comment mesurer votre débit

Nous vous recommandons de mesurer votre débit global sur un déploiement avec deux mesures :

Appels par minute : nombre d’appels d’inférence d’API que vous effectuez par minute. Cela peut être mesuré dans Azure-Monitor à l’aide de la métrique de Requêtes Azure OpenAI et du fractionnement par ModelDeploymentName
Nombre total de jetons par minute : nombre total de jetons traités par minute par votre déploiement. Cela inclut les jetons d’invite et les jetons générés. Il s’agit souvent d’un fractionnement plus approfondi dans la mesure des deux afin de comprendre plus en détail les performances du déploiement. Cela peut être mesuré dans Azure-Monitor à l’aide de la métrique des jetons d’inférence traités.

En savoir plus sur la supervision d’Azure OpenAI Service.

Comment mesurer la latence par appel

Le temps nécessaire pour chaque appel dépend du temps nécessaire pour lire le modèle, générer la sortie et appliquer des filtres de contenu. La façon dont vous mesurez le temps varie si vous utilisez la diffusion en continu ou non. Nous suggérons un ensemble de mesures différent pour chaque cas.