Quelles métriques surveiller dans un système de serving de LLM ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Surveillez les valeurs de TTFT, TPOT, latence totale, erreurs et goodput visibles côté client, ainsi que les files du serveur, les longueurs en tokens, l’utilisation du KV cache et les préemptions. Le taux d’utilisation du GPU ne permet pas à lui seul de distinguer le travail utile de la surcharge. Évaluez séparément la qualité des réponses ; un service rapide peut tout de même renvoyer des réponses incorrectes.
Commencez par le résultat visible pour l’utilisateur
TTFT mesure le temps entre l’envoi de la requête et le premier token de sortie. TPOT mesure l’intervalle moyen entre les tokens de sortie suivants. Pour au moins deux tokens de sortie :
Mesurez ces instants à la livraison du premier et du dernier token de sortie. Enregistrez séparément la latence jusqu’à la fin de la requête ; les métadonnées finales ou le nettoyage de la connexion peuvent intervenir après le dernier token. Enregistrez aussi les interruptions individuelles de livraison. La moyenne TPOT d’une requête peut masquer une pause. Les fragments SSE peuvent contenir plusieurs tokens : les intervalles entre fragments et entre tokens sont donc des mesures différentes.
Présentez les percentiles de latence par groupes de charge pertinents, par exemple selon la longueur du prompt et le modèle. Gardez des limites de mesure cohérentes : les métriques du serveur excluent une partie du temps réseau et du traitement côté client.
Goodput compte les requêtes par seconde qui respectent tous les SLO de serving définis. Si le service termine 100 requêtes par seconde et que 40 ne respectent pas au moins un seuil obligatoire, le goodput est de 60 requêtes par seconde. Cela mesure les performances du serving, pas l’exactitude factuelle des réponses. DistServe utilise le goodput sous contraintes de latence pour évaluer les architectures de serving.
Ajoutez les métriques qui expliquent les défaillances
La documentation des métriques de vLLM décrit les requêtes en cours et en attente, les histogrammes de latence, les nombres de tokens, l’utilisation du KV et les préemptions. Adaptez les tableaux de bord à la version déployée.
| Mesure | Ce qu’il faut examiner lorsqu’elle augmente |
|---|---|
| Requêtes en attente et temps en file | Taux d’arrivée par rapport à la capacité de traitement admise |
| Utilisation du KV cache et préemptions | Séquences longues, lots actifs et allocation de mémoire |
| TTFT avec TPOT stable | Files d’attente, tokenisation, prefill ou délai réseau |
| TPOT et interruptions de livraison | Ordonnancement du décodage, trafic mémoire ou mise en tampon côté client |
| Tokens et nouvelles tentatives par requête terminée | Sorties plus longues ou travail répété |
La métrique de type gauge de vLLM vllm:kv_cache_usage_perc utilise une fraction de 0 à 1 malgré son nom. Déduisez les seuils d’alerte des tests de charge et du délai de rétablissement requis. Reliez un petit ensemble d’évaluations de qualité et de traces de défaillance aux métriques de serving.
Pour une vue plus générale de la conception, lisez la surveillance des systèmes LLM dans le guide.