Menez votre propre évaluation comparative des LLM Endpoint
Les sujets décrits sur cette page s'appliquent aux charges de travail à débit throughput qui servent des modèles provisionnant la capacité d'inférence basée sur des *jetons par seconde*. Les modèles suivants s’appliquent :
- Meta Llama 3.3
- Meta Llama 3.2 3B
- Meta Llama 3.2 1B
- Meta Llama 3.1
- GTE v1.5 (Anglais)
- BGE v1.5 (Anglais)
- DeepSeek R1 (non disponible dans Unity Catalog)
Consultez Unités de modèle dans le throughput provisionné pour les modèles pris en charge qui utilisent des *unités de modèle* (pas des jetons par seconde) pour provisionner la capacité d'inférence.
Cet article fournit un exemple de Notebook recommandé par Databricks pour évaluer un Endpoint LLM. Il comprend également une brève introduction à la façon dont Databricks effectue l'inférence LLM et calcule la latence et le throughput en tant qu'indicateurs de performance des endpoints.
L'inférence LLM sur Databricks mesure les jetons par seconde pour le mode throughput provisionné pour les APIs de modèle de fondation. Pour plus de détails sur la façon dont la capacité d'inférence est en provisionnement, voir Unités de modèle en throughput provisionné.
Exemple de notebook de benchmarking
Vous pouvez importer le Notebook suivant dans votre environnement Databricks et spécifier le nom de votre Endpoint LLM pour exécuter un test de charge.
Analyse comparative d'un endpoint LLM
Introduction à l'inférence LLM
Les LLM effectuent une inférence en deux étapes :
- Préremplissage , où les jetons de l'invite d'entrée sont traités en parallèle.
- Décodage , où le texte est généré un jeton à la fois de manière autorégressive. Chaque jeton généré est ajouté à l'entrée et réinjecté dans le modèle pour générer le jeton suivant. La génération s'arrête lorsque le LLM génère un jeton d'arrêt spécial ou lorsqu'une condition définie par l'utilisateur est remplie.
La plupart des applications de production ont un budget de latence, et Databricks vous recommande de maximiser le throughput étant donné ce budget de latence.
- Le nombre de jetons d'entrée a un impact substantiel sur la mémoire requise pour traiter les requêtes.
- Le nombre de jetons de sortie domine la latence globale de la réponse.
Databricks divise l'inférence LLM en les sous-métriques suivantes :
- Délai avant le premier jeton (TTFT) : C'est la rapidité avec laquelle les utilisateurs start à voir la sortie du modèle après avoir entré leur requête. Des temps d'attente faibles pour une réponse sont essentiels dans les interactions en temps réel, mais moins importants dans les charges de travail hors ligne. Cette métrique est déterminée par le temps nécessaire pour traiter l'invite et ensuite générer le premier jeton de sortie.
- Temps par jeton de sortie (TPOT) : Temps nécessaire pour générer un jeton de sortie pour chaque utilisateur qui interroge le système. Cette métrique correspond à la manière dont chaque utilisateur perçoit la « rapidité » du modèle. Par exemple, un TPOT de 100 millisecondes par token représenterait 10 tokens par seconde, soit environ 450 mots par minute, ce qui est plus rapide que ce qu'une personne typique peut lire.
Selon ces métriques, la latence totale et le throughput peuvent être définis comme suit :
- Latence = TTFT + (TPOT) * (le nombre de jetons à générer)
- **Throughput** = nombre de jetons de sortie par seconde pour toutes les requêtes concurrentes.
Sur Databricks, les Endpoints de service LLM sont capables de monter en charge pour s'adapter à la charge envoyée par les clients avec plusieurs requêtes concurrentes. Il y a un compromis entre la latence et le throughput. En effet, sur les Endpoint de service LLM, les requêtes concurrentes peuvent être et sont traitées simultanément. Avec de faibles charges de requêtes concurrentes, la latence est la plus faible possible. Cependant, si vous augmentez la charge des requêtes, la latence pourrait augmenter, mais le throughput augmentera probablement aussi. C'est parce que deux requêtes de jetons par seconde peuvent être traitées en moins de deux fois le temps.
Par conséquent, le contrôle du nombre de requêtes parallèles dans votre système est essentiel pour équilibrer la latence et le throughput. Si vous avez un cas d'usage à faible latence, vous souhaitez envoyer moins de requêtes simultanées à l'Endpoint pour maintenir une latence faible. Si vous avez un cas d'utilisation à high throughput, vous voulez saturer l'endpoint avec de nombreuses requêtes de concurrence, car un throughput plus élevé en vaut la peine même au détriment de la latence.
- Les cas d'utilisation à fort throughput peuvent inclure les inférences par batch et d'autres tâches non destinées aux utilisateurs.
- Les cas d'utilisation à faible latence peuvent inclure des applications en temps réel qui nécessitent des réponses immédiates.
Outil de benchmarking Databricks
Le Notebook d'exemple de benchmarking précédemment partagé est le cadre de benchmarking Databricks. Le Notebook affiche la latence **totale** sur toutes les requêtes et les métriques de throughput, et trace la courbe throughput par rapport à la latence pour différents nombres de requêtes parallèles. La stratégie d'autoscaling des Endpoint Databricks équilibre la latence et le throughput. Dans le Notebook, vous observez que la latence et le throughput augmentent à mesure que davantage d'utilisateurs simultanés interrogent l'Endpoint.
Cependant, vous commencez également à constater qu'à mesure que le nombre de requêtes parallèles augmente, le throughput commence à plafonner, atteignant une limite d'environ 8 000 jetons par seconde. Ce plafond est atteint car le throughput provisionné pour l'endpoint limite le nombre de workers et de requêtes parallèles qui peuvent être effectuées. À mesure que davantage de requêtes sont effectuées au-delà de ce que l'endpoint peut gérer simultanément, la latence totale continue d'augmenter à mesure que des requêtes supplémentaires attendent dans la file d'attente.
Plus de détails sur la philosophie de Databricks concernant le benchmarking des performances des LLM sont décrits dans le blog LLM Inference Performance Engineering: Best Practices.