Débit et goodput des LLM : quelle métrique utiliser ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Le débit d’un LLM mesure la quantité de travail qu’un serveur accomplit par seconde. Le goodput mesure le taux de travail qui respecte également des exigences de service définies. Pour les décisions de serving, utilisez le débit de tokens de sortie ainsi que le nombre de requêtes réussies par seconde qui respectent vos objectifs de latence du premier token et de génération.
Un serveur qui produit plus de tokens alors que des requêtes expirent peut avoir un débit supérieur et une capacité utile inférieure.
Définir une requête qui respecte les exigences
Avant les tests, définissez les conditions qu’une requête doit remplir. Par exemple : une exécution réussie, un TTFT inférieur à 500 ms et un TPOT moyen inférieur à 50 ms. Comptez ensuite les requêtes terminées qui respectent ces conditions pendant l’intervalle de mesure :
request goodput = qualifying completed requests / measured seconds
output throughput = generated output tokens / measured secondsIl s’agit d’un exemple de SLO et de deux définitions explicites de métriques. Si 100 requêtes se terminent en dix secondes, mais que seules 60 respectent les exigences, le débit de requêtes terminées est de dix requêtes par seconde et le goodput de six. Indiquez aussi le débit de tokens de sortie, car la longueur des réponses peut varier.
DistServe utilise le goodput pour évaluer le serving avec des exigences de TTFT et de génération de tokens. Précisez toujours si votre unité est la requête ou le token respectant les exigences : le mot seul ne définit ni le dénominateur ni les règles d’éligibilité.
Garder une charge de travail comparable
| À consigner | Pourquoi cela affecte le résultat |
|---|---|
| Longueurs des entrées et des sorties | Le travail de prefill, la taille du cache et la durée du décodage varient |
| Modèle, précision, GPU et révision du runtime | Ils modifient le coût d’exécution |
| Requêtes offertes par seconde | Détermine la pression sur la file d’attente |
| Requêtes simultanées | Modifie la constitution des lots et l’utilisation de la mémoire |
| Politique de cache | Les préfixes répétés peuvent réduire le travail de prefill |
| Erreurs et annulations | La réussite de l’exécution fait partie de la capacité utile |
Avec de petits lots de décodage, ajouter des requêtes peut améliorer la réutilisation des poids. Des lots plus grands ou une hausse de la charge offerte peuvent finir par augmenter la latence ou dépasser les limites de mémoire, de calcul ou de communication. La courbe dépend de la charge de travail ; une progression linéaire n’est pas garantie.
Augmentez la charge offerte par paliers et tracez le débit, le goodput, la latence P99, les erreurs et la longueur de la file d’attente. Choisissez une charge qui respecte les exigences avec une marge pour les variations de trafic. L’expérience d’Anyscale sur le traitement continu par lots montre pourquoi une comparaison doit préciser la distribution des requêtes.
Le guide d’ingénierie : débit et compromis avec la latence explique ce compromis du serving dans son contexte.