← Back

Métriques importantes pour l'inférence LLM

Les utilisateurs ressentent un retard avant de voir les mots. Une faible latence est cruciale pour une bonne expérience utilisateur et pour optimiser les performances d'un modèle, car la réduction des temps de réponse a un impact direct sur la façon dont les utilisateurs perçoivent les systèmes d'IA génératifs. Les systèmes tombent en panne lorsque les files d'attente s'étirent et que la mémoire est épuisée. Un petit ensemble de mesures peut vous avertir rapidement et vous indiquer la bonne solution. Le suivi de ces indicateurs est essentiel pour garantir la fiabilité du système et maintenir les performances du modèle. Gardez la liste courte, branchez-la bien et rendez les alertes ennuyeuses.

Sur Calculer, une VllM point final vous fournit une URL HTTPS avec des itinéraires de type OpenAI et une capacité prévisible. Placez-le à proximité des utilisateurs, puis regardez TTFT, TPS et cache headroom.

Indicateurs de base

Il s'agit des principaux indicateurs de performance pour l'inférence LLM. Différents facteurs, tels que la complexité des instructions de saisie, l'utilisation des ressources et la configuration du système, influencent ces mesures. Des outils de surveillance et différentes méthodes sont utilisés pour les suivre et les analyser.

Heure avant le premier jeton (TTFT). Écart entre l'envoi de la demande et le premier jeton. Le chiffre le plus important pour les temps de réponse perçus et l'expérience utilisateur. Le mécanisme d'attention et le temps de préremplissage contribuent de manière significative au délai avant le premier jeton, car le modèle traite les jetons d'entrée et construit son cache clé-valeur avant de générer des réponses. Suivez p50 et p95. Le dernier jeton marque la fin d'une réponse.

Jetons par seconde (TPS). Débit une fois que les jetons démarrent. Plus c'est haut, mieux c'est pour l'expérience utilisateur et la capacité. Le TPS est calculé en fonction du nombre de demandes traitées et du nombre de jetons de sortie générés par seconde pour toutes les demandes, souvent mesuré parallèlement aux demandes par seconde. La latence entre jetons est le temps moyen entre deux jetons consécutifs, et le TPS total est un indicateur clé du débit du système. Un calcul d'attention efficace peut contribuer à réduire la latence entre jetons. Suivez p50 et p95.

Longueur de la file d'attente. Demandes en attente d'un emplacement de décodage. L'augmentation de la longueur avec un trafic plat est synonyme de problèmes.

marge de mémoire du GPU. VRAM gratuite pendant les périodes de pointe. Une faible marge de manœuvre prédit des échecs, des démarrages lents et des expulsions. L'utilisation des ressources et les implications financières doivent être prises en compte lors de la surveillance de la mémoire GPU.

Taux de réussite du cache. État de santé du KV‑Cache et de tous les caches d'invite. Des taux de réussite plus faibles expliquent souvent le fluage du TTFT.

Temps de préremplissage et temps de décodage. Le temps de préremplissage est affecté par l'invite de saisie et le nombre de jetons d'entrée, car ces facteurs déterminent le temps que le modèle passe dans la phase de préremplissage avant le décodage.

Taux d'erreur par type. La complexité et d'autres facteurs peuvent influencer les taux d'erreur. Le suivi par type permet donc d'identifier les causes profondes.

Remarque : Ces mesures peuvent varier en fonction de la configuration du système, de la complexité de la charge de travail et du fournisseur de services.

Start in seconds with the fastest, most affordable cloud GPU clusters.

Launch an instance in under a minute. Enjoy flexible pricing, powerful hardware, and 24/7 support. Scale as you grow—no long-term commitment needed.

Try Compute now

Indicateurs complémentaires

Taux de demande (RPS). Paires avec longueur de file d'attente pour expliquer la pression. Le taux de demandes est généralement calculé en tant que demandes par seconde, fournissant une mesure quantitative du débit du système.

Temps de préremplissage et temps de décodage. Le fait de les séparer permet d'isoler les longues invites de la génération lente. L'invite de saisie et le nombre de jetons de saisie sont des facteurs clés qui influent sur le temps de préremplissage, car des instructions plus complexes ou plus longues peuvent augmenter la durée de traitement.

Taux d'erreur par type. OOM, délais d'attente, 4xx/5xx. Regroupez par itinéraire et modèle. La complexité et d'autres facteurs peuvent influencer les taux d'erreur, d'où l'importance d'analyser les types d'erreurs dans leur contexte.

Latence du réseau. RTT du point de terminaison Client ↔ par région. Les pics peuvent imiter la lenteur du serveur.

Thermiques et horloges. L'étranglement apparaît sous la forme d'un TPS plat et d'un TTFT en hausse. La surveillance de l'utilisation des ressources et des coûts est importante pour évaluer la marge de manœuvre de la mémoire GPU ou les taux d'erreur, car ceux-ci peuvent avoir un impact à la fois sur les performances et le budget.

Les indicateurs connexes sont suivis à l'aide d'outils de surveillance afin de garantir une observabilité complète et une détection rapide des problèmes.

Une instrumentation rentable

Une instrumentation efficace pour l'observabilité du LLM repose sur des outils de surveillance et diverses méthodes pour garantir un suivi et une analyse complets.

  • Minuteurs pour les clients. Tamponnez request_start, first_token et last_token. Le suivi du calendrier des réponses est un élément clé du processus d'évaluation des performances des modèles.
  • Les serveurs s'étendent sur plusieurs serveurs. Capturez la durée de la file d'attente, préremplissez, décodez et videz le flux. Différentes méthodes peuvent être utilisées pour saisir les données pertinentes à chaque étape.
  • Identifiants stables. Envoyez un request_id du client au serveur et dans les journaux.
  • Compteurs de jetons. Enregistrez les jetons d'invite et les jetons de sortie par demande. La surveillance de l'utilisation des ressources est importante pour comprendre l'efficacité du système. Ignorez le texte brut sauf si vous en avez vraiment besoin.
  • Échantillonnage Conservez tous les détails pour une partie du trafic et des cumuls pour le reste. Sélectionnez la méthode d'échantillonnage appropriée afin d'équilibrer les détails et l'évolutivité.

Nombre minimal d'événements à enregistrer par demande

  • horodatage, itinéraire, modèle
  • request_id, identifiant utilisateur/session (haché)
  • jetons_rapides, jetons_sortie
  • ttft_ms, tps_jetons_par_seconde
  • longueur_de_file d'attente au début
  • gpu_mem_free_mb, cache_hit_rate
  • état (ok/timeout/oom/error_code)
  • utilisation des ressources (par exemple, utilisation du CPU/GPU, utilisation de la mémoire)
  • détails de la réponse (par exemple, longueur de la réponse, état de la réponse)

Des tableaux de bord qui répondent à de vraies questions

Les tableaux de bord sont créés à l'aide d'outils de surveillance pour visualiser les indicateurs de performance clés pour les grands modèles linguistiques (LLM).

« Les utilisateurs se sentent-ils lents en ce moment ? »
TTFT p50/p95 au fil du temps avec superposition de trafic. Percez par région et par modèle. Les temps de réponse et les réponses sont des indicateurs clés de l'expérience utilisateur.

« Pouvons-nous supporter plus de charge ? »
TPS p50/p95, longueur de la file d'attente et marge de mémoire du GPU. TPS plat + file d'attente croissante = pas encore.

« Pourquoi la latence a-t-elle augmenté ? »
Séparez le préremplissage par rapport au décodage, ajoutez le réseau RTT. Préremplissage long → invites trop grandes. Décodage long → capsules ou forme du lot.

« Est-ce que nous gaspillons des jetons ? »
Distribution des jetons de sortie par rapport à vos plafonds. Grande queue = réglages lâches.

Remarque : Les mesures du tableau de bord doivent être interprétées dans leur contexte, car les variations des conditions de mesure ou des configurations des modèles peuvent affecter les résultats.

Alertes et SLO

Définissez des seuils que vous pouvez défendre. Exemples pour commencer :

  • TTFT p95 > 1 000 ms pendant 5 minutes à un RPS stable.
  • Le TPS p50 baisse de 30 % avec RPS plat.
  • Sans GPU < 10 % pendant 5 minutes.
  • Délais d'attente > 1 % ou CHAMBRE > 0,2 % plus de 10 minutes.

Définissez un objectif de niveau de service (SLO), tel que « TTFT p95 ≤ 800 ms et taux d'erreur ≤ 1 % sur 28 jours. » Un SLO fait souvent partie d'un accord de niveau de service (SLA), qui est un contrat formel entre le fournisseur de services et l'utilisateur spécifiant des normes de performance et de qualité. Suivez le budget d'erreur et la page lorsque vous la gravez trop vite.

Utilisez des outils de surveillance et différentes méthodes pour suivre les SLO et les indicateurs de performance. Pour les alertes, sélectionnez la méthode qui correspond le mieux à vos besoins opérationnels.

Remarque : Les SLO doivent être adaptés aux besoins du fournisseur de services et des utilisateurs afin de garantir qu'ils sont significatifs et réalisables.

Tests de charge que vous devriez réellement exécuter

Voici les méthodes courantes pour les tests de charge :

  • Test de rampe. Cette méthode augmente progressivement la simultanéité ; à mesure que les demandes simultanées augmentent, le TPS total augmente jusqu'à ce qu'un point de saturation soit atteint, après quoi les performances peuvent diminuer. Continuez jusqu'à ce que TTFT p95 dépasse votre objectif.
  • Test d'éclatement. Déclenchez une onde soudaine égale au pic attendu et observez le TPS total sous charge.
  • Invitations mitigées. Mélangez les demandes courtes et longues ; surveillez le comportement du planificateur.
  • Annulez Storm. Arrêtez de nombreux flux de milieu de génération ; vérifiez le nettoyage.
  • Basculement. Redémarrez un nœud ; vérifiez la restauration et le client recommence.

Remarque : Les résultats peuvent varier en fonction de la méthode utilisée et de la configuration du système.

Pièges courants

  • À la recherche de la vitesse en cas de demande unique. La concurrence l'emporte plus souvent.
  • Sorties non plafonnées. Les longues générations affament tout le monde, augmentant l'utilisation des ressources et faisant grimper les coûts.
  • Des instructions détaillées du système. Coûteux et souvent ignoré par le modèle, ce qui entraîne une utilisation inutile des ressources et une augmentation des coûts.
  • Aucune stratégie régionale. Les appels interrégionaux ajoutent une latence évitable.
  • Mauvais comptage des jetons. Gardez le tokenizer et le modèle alignés.

Remarque : Ces pièges peuvent entraîner une augmentation des coûts opérationnels et une utilisation inefficace des ressources s'ils ne sont pas gérés correctement.

Dernières pensées

Il est plus efficace de se concentrer sur les indicateurs essentiels que d'en suivre un trop grand nombre. De petits indicateurs stables surpassent un mur de graphiques. Regardez TTFT et TPS, réduisez les files d'attente et laissez de la marge en mémoire. Corrigez les instructions et les majuscules avant de changer de matériel.

Remarque : La simplicité est essentielle : donnez la priorité aux indicateurs essentiels pour éviter toute complexité inutile.

Essayez Compute dès aujourd'hui
Vous préférez des opérations prévisibles ? Lancez un VllM point de terminaison activé Calculer en France ou aux Émirats arabes unis, plafonnez les jetons et suivez TTFT/TPS dès le premier jour.

FAQ

Qu'est-ce que le TTFT ?

Délai avant le premier jeton : délai avant le début de la sortie du modèle, en particulier le temps nécessaire pour créer le premier nouveau jeton. Les utilisateurs le ressentent plus que tout autre indicateur.

Qu'est-ce qu'un bon TPS ?

De quoi faciliter le chat et réduire les files d'attente à votre trafic. Mesurez à l'aide de vos instructions. Le TPS total (jetons par seconde) reflète le débit de toutes les demandes et dépend du nombre de demandes traitées simultanément. Optimisez la forme du lot et les bouchons pour le surélever.

De combien de métriques avons-nous réellement besoin ?

Cinq solutions principales couvrent la plupart des problèmes : TTFT, TPS, longueur de la file d'attente, marge de mémoire GPU et taux d'accès au cache. Il s'agit des indicateurs de performance essentiels pour la surveillance des LLM. Il existe différentes méthodes pour suivre ces indicateurs, en fonction de votre infrastructure et de vos besoins d'évaluation. Ajoutez le taux de demandes et les types d'erreur pour le contexte.

Comment tester les alertes sans réveiller les gens ?

Utilisez le trafic synthétique dans un environnement intermédiaire, ou augmentez temporairement les seuils de production et déclenchez une rafale contrôlée. Des outils de surveillance et diverses méthodes peuvent être utilisés pour tester efficacement les systèmes d'alerte.

Avons-nous besoin d'un traçage distribué ?

Utile lorsque vous exécutez plusieurs nœuds ou une passerelle. Le traçage distribué est l'un des nombreux outils et méthodes de surveillance permettant d'assurer l'observabilité du système. Commencez par les identifiants de demande et effacez les spans ; ajoutez le suivi au fur et à mesure de votre croissance.

Qu'est-ce que le TTFT ?

TTFT, ou Time to First Token, mesure le délai entre l'envoi d'une demande et la réception du premier jeton de la sortie du modèle. Cette métrique inclut le temps de préremplissage, pendant lequel le mécanisme d'attention traite l'entrée et crée le cache clé-valeur nécessaire à la création du premier jeton. Il s'agit d'un indicateur essentiel de la perception de la réactivité.

Comment mesurer le TTFT ?

Le TTFT est calculé en mesurant le temps nécessaire pour créer le premier nouveau jeton. Cela implique d'enregistrer l'horodatage lorsqu'une demande est envoyée et l'horodatage de l'arrivée du premier jeton de sortie, puis de calculer la différence.

Qu'est-ce que la métrique TPOT ?

Le TPOT (Time per Output Token) est le temps moyen nécessaire pour générer chaque jeton après le premier, reflétant la vitesse de génération de jetons en régime permanent. Plus précisément, le TPOT mesure la latence inter-jetons entre les jetons consécutifs produits par le modèle. Un calcul d'attention efficace peut contribuer à réduire cette latence entre jetons, améliorant ainsi l'efficacité globale du décodage.

Qu'est-ce que TPS in LLM ?

TPS est l'abréviation de Tokens par seconde et indique le nombre de jetons qu'un modèle peut générer chaque seconde lors de l'inférence, en mesurant le débit. Le TPS est étroitement lié aux demandes par seconde, car les deux indicateurs permettent d'évaluer les performances du système. Le TPS total mesure le débit global de toutes les demandes traitées simultanément, reflétant la capacité du système à générer des jetons de sortie par seconde pour toutes les demandes combinées.

Qu'est-ce qu'un jeton par seconde ?

Un jeton par seconde est une unité qui mesure le nombre de jetons produits par le modèle chaque seconde pendant la génération de la sortie. Cette métrique est calculée en divisant le nombre de jetons générés par le temps écoulé.

Combien de jetons par seconde fait ChatGPT ?

ChatGPT génère généralement des jetons à un rythme d'environ 20 à 30 jetons par seconde, en fonction de la charge du serveur et de la version du modèle.

Remarque : Le TPS peut varier en fonction de paramètres de performance tels que la latence et le débit, ainsi que de l'état du système.

Combien de mots font 1 000 jetons ?

Environ 750 mots correspondent à 1 000 jetons, car un jeton contient en moyenne 0,75 mot en anglais. Le ratio mot-jeton est calculé en fonction de la longueur moyenne des mots et du processus de tokenisation.

Est-ce que 7 jetons par seconde sont bons ?

Sept jetons par seconde, c'est relativement lent pour de nombreuses applications en temps réel, mais cela peut être acceptable pour des générations plus longues et moins sensibles au facteur temps.

Comment mesurer l'inférence ?

L'inférence est mesurée à l'aide de différentes méthodes, notamment le suivi des indicateurs de performance tels que la latence (TTFT, temps de génération total) et le débit (TPS).

Quels sont les 5 exemples d'inférence ?

Les exemples incluent la complétion de texte, la réponse à des questions, la traduction, le résumé et la génération de code. Ce sont tous des exemples de réponses générées en tant que sortie du modèle.

Quelles sont les 5 étapes principales de l'inférence ?

Le processus d'inférence commence par l'invite de saisie, qui est transformée en jetons d'entrée. Le mécanisme d'attention traite ces jetons d'entrée pendant la période de préremplissage, créant ainsi le cache clé-valeur nécessaire pour que le modèle génère une réponse. Cette phase de préremplissage est cruciale pour créer le premier nouveau jeton, qui marque le début de la génération du jeton de sortie. Le modèle continue ensuite à décoder et à générer des jetons de sortie jusqu'à ce que la réponse soit complète.

Que signifie l'inférence devant un tribunal ?

Au tribunal, l'inférence fait référence à une conclusion fondée sur des preuves et un raisonnement plutôt que sur des déclarations explicites.

Qu'entendez-vous par observabilité ?

L'observabilité est la capacité à comprendre l'état interne d'un système en analysant ses résultats, tels que les journaux, les métriques et les traces, à l'aide d'outils de surveillance et de diverses méthodes pour évaluer et interpréter le processus et les résultats.

Qu'est-ce que l'observabilité par rapport à la surveillance ?

La surveillance utilise des mesures et des alertes prédéfinies, qui s'appuient souvent sur des outils de surveillance et des méthodes spécifiques pour suivre l'état de santé du système. L'observabilité et la surveillance font appel à des outils et à des méthodes de surveillance, mais l'observabilité permet une analyse exploratoire sans connaissances préalables, ce qui permet de mieux comprendre le processus et de fournir des informations plus approfondies.

Quels sont les trois piliers de l'observabilité ?

Les métriques, les journaux et les traces sont les trois piliers qui fournissent une visibilité complète du système, soutenue par divers outils et méthodes de surveillance.

Qu'est-ce que l'observabilité dans DevOps ?

Dans DevOps, l'observabilité aide les équipes à détecter, diagnostiquer et résoudre les problèmes de manière proactive en collectant et en analysant les données de télémétrie. L'observabilité repose sur des outils de surveillance et diverses méthodes pour analyser le processus, garantissant ainsi une détection et une résolution efficaces des problèmes.

Qu'est-ce qu'un cache KV ?

Un cache KV (clé-valeur) stocke des paires clé-valeur intermédiaires lors de l'inférence du modèle afin d'accélérer la génération de jetons et permet un calcul d'attention efficace lors de l'inférence.

Qu'est-ce que le cache GPU KV ?

Le cache GPU KV fait référence au stockage de paires clé-valeur dans la mémoire GPU afin d'optimiser les calculs d'attention lors de l'inférence LLM, permettant ainsi un calcul d'attention efficace.

Qu'est-ce que le cache KV dans LLM ?

Le cache KV contient les clés et les valeurs d'attention précédemment calculées afin d'éviter les calculs redondants lors de la génération de nouveaux jetons. Ce cache est essentiel pour un calcul d'attention efficace, permettant un traitement plus rapide et plus optimal lors de la génération de jetons.

Qu'est-ce que le cache de stockage clé-valeur ?

Un cache de stockage clé-valeur est une structure de données qui stocke des données indexées par des clés uniques pour une récupération rapide.

Qu'entendez-vous par débit ?

Le débit est un indicateur de performance clé qui représente la quantité de travail effectuée ou de sortie produite par un système au cours d'une période donnée, comme les jetons générés par seconde. Le débit est généralement calculé comme la sortie divisée par le temps et peut être mesuré à l'aide de différentes méthodes en fonction de l'approche d'évaluation.

Qu'est-ce que le débit par rapport à la bande passante ?

Le débit mesure les données réellement traitées au fil du temps, tandis que la bande passante est le taux de transfert de données maximal possible. Le débit et la bande passante sont des indicateurs de performance importants pour évaluer l'efficacité du système.

Quel est un exemple de débit ?

Le débit est une mesure de performance calculée en jetons par seconde. Par exemple, la génération de 100 jetons par seconde lors de l'inférence LLM démontre le débit.

Quel est un autre mot pour désigner le débit ?

Débit de sortie ou taux de traitement.

La latence de 95 % est-elle bonne ?

Une latence inférieure à 500 millisecondes au 95e percentile est généralement considérée comme bonne pour les applications en temps réel.

Qu'est-ce que la latence de queue du p95 ?

La latence de queue P95 est la valeur de latence en dessous de laquelle 95 % des demandes sont traitées, ce qui indique les pires performances pour la plupart des utilisateurs.

Qu'est-ce que la latence du P50 ?

La latence P50 est la latence médiane, ce qui signifie que la moitié des demandes sont traitées plus rapidement et l'autre moitié plus lentement que cette valeur.

Est-ce que p95 est une moyenne ?

Non, p95 est une métrique en centile représentant la valeur en dessous de laquelle 95 % des observations tombent, et non une moyenne. p95 et average sont des types de mesures de performance utilisées pour évaluer et comparer les performances du système.

Qu'est-ce que le concept de budget d'erreur ?

Un budget d'erreurs définit le seuil autorisé d'erreurs ou de ruptures de latence au cours d'une période de service afin de trouver un équilibre entre fiabilité et innovation. Les budgets d'erreur font généralement partie d'un contrat de niveau de service (SLA) entre le fournisseur de services et l'utilisateur et sont basés sur des indicateurs de performance tels que la latence et le débit.

Comment calculez-vous le budget d'erreur ?

Le budget d'erreur est calculé à l'aide des indicateurs de performance suivants : Budget d'erreur = (1 - cible SLO) × nombre total de demandes ou période.

Quelle est la différence entre le budget d'erreur et le SLO ?

Le SLO (objectif de niveau de service) définit l'objectif de performance dans le cadre d'un accord de niveau de service entre le fournisseur de services et l'utilisateur, et est basé sur des mesures de performance ; le budget d'erreurs quantifie les écarts autorisés par rapport à cet objectif.

Qu'est-ce qu'une erreur budgétaire ?

Une erreur budgétaire se produit lorsque le budget d'erreur est dépassé, ce qui indique des problèmes de fiabilité du service et des problèmes potentiels liés aux indicateurs de performance tels que la latence, le débit ou d'autres résultats d'analyse comparative.

Qu'est-ce qu'une mémoire GPU ?

La mémoire GPU est la mémoire vive dédiée d'une unité de traitement graphique utilisée pour stocker les données et les calculs pendant le traitement. Il s'agit d'un aspect clé de l'utilisation des ressources, car la surveillance de la mémoire GPU permet de suivre l'utilisation globale des ressources et les mesures de performance dans les solutions d'observabilité LLM.

De quelle quantité de mémoire GPU ai-je besoin ?

La mémoire GPU requise dépend de la taille du modèle, de la taille du lot, de la précision, de l'utilisation des ressources et de divers facteurs tels que le débit, la latence et la qualité de réponse ; les modèles et les lots plus volumineux nécessitent davantage de mémoire.

Qu'est-ce qui utilise la mémoire GPU ?

L'utilisation de la mémoire GPU fait référence à l'allocation de la RAM GPU pour les paramètres du modèle, les données intermédiaires et les calculs lors de l'inférence. Il s'agit d'une forme d'utilisation des ressources, car le suivi de l'utilisation de la mémoire GPU est essentiel pour comprendre les performances et l'efficacité globales du système.

Comment puis-je vérifier la mémoire du GPU ?

Vous pouvez vérifier l'utilisation de la mémoire GPU à l'aide d'outils tels que nvidia-smi sur les GPU NVIDIA, d'un logiciel de surveillance du système ou d'outils de surveillance spécialisés conçus pour une observabilité avancée. Les outils de surveillance peuvent vous aider à suivre l'utilisation de la mémoire GPU, à vous alerter en cas de problème et à fournir des mesures détaillées pour une gestion efficace du système.

← Back