Benchmark vLLM : reproduisez la latence, le débit et le coût GPU avant le déploiement

Un benchmark vLLM n’est utile que s’il ressemble au trafic que votre application enverra réellement. Un chiffre de tokens par seconde mis en avant peut masquer un premier token lent, une file d’attente surchargée ou une distribution de prompts qui n’apparaît jamais en production. Ce guide vous propose un benchmark de serving reproductible : choisissez une charge de travail, faites varier la charge proposée, enregistrez conjointement la distribution de latence et le débit, puis comparez les configurations GPU à objectif de qualité égal.

Réponse rapide : Utilisez vllm bench serve avec une version de vLLM et un modèle figés, sur un serveur GPU dédié. Gardez fixes le modèle, la précision, les longueurs des prompts et des sorties, les paramètres d’échantillonnage, l’état du cache et l’emplacement du client. Exécutez plusieurs débits de requêtes, capturez le TTFT, le TPOT, la latence de bout en bout, le taux de requêtes réussies et les tokens de sortie par seconde, puis choisissez la configuration la moins coûteuse qui respecte votre objectif de service à charge de pointe. Une seule exécution au débit maximal ne constitue pas un plan de capacité.

Éléments à mesurer dans un benchmark vLLM

La documentation de benchmark vLLM définit le TTFT, la latence inter-tokens et le TPOT selon leurs points de mesure. Utilisez ces définitions lorsque vous comparez des outils. En particulier, le TTFT côté client inclut le transport et le travail du frontend ; des métriques facultatives côté serveur peuvent dissocier l’attente de l’ordonnanceur de l’exécution du modèle, mais leur activation ajoute de la surcharge. Gardez les exécutions de diagnostic séparées des résultats mis en avant.

Figez une comparaison équitable avant l’exécution

Consignez la révision du modèle et le tokenizer, la version de vLLM, le type et le nombre de GPU, la taille du parallélisme tensoriel, les options de serving, le format de quantification, la longueur de contexte et l’environnement logiciel. Utilisez les mêmes prompts et objectifs de sortie pour chaque candidat. Si vous changez simultanément le modèle, la précision et le GPU, le résultat ne peut pas vous indiquer quel changement a aidé.

Choisissez au moins deux charges de travail. Une charge synthétique à longueur fixe est utile pour des variations contrôlées ; une trace assainie de longueurs de requêtes réelles est préférable pour une décision de production. Préservez la distribution des prompts longs, des réponses courtes et des rafales. Pour un produit de chat, mesurez le point de terminaison de chat avec le backend de benchmark correspondant. Pour une charge de complétions, utilisez le backend de complétions. Ne comparez pas leurs chiffres comme si le formatage des requêtes était identique.

Définissez les critères de réussite avant l’exécution. Par exemple, indiquez un taux de requêtes réussies requis ainsi que des TTFT p95 et latence de bout en bout p95 maximum pour votre propre charge de travail. Nous ne publions pas de seuil universel : il dépend de l’expérience utilisateur et de la taille de sortie. Un tableau d’acceptation avec les seuils, les résultats mesurés et le motif de réussite/échec est plus utile qu’un seul score de performance.

Exécutez un test de serving contrôlé

Le guide CLI de vLLM actuel répertorie vllm bench serve pour les mesures de serving en ligne et recommande l’extra bench pour ses dépendances. Le plan suivant utilise l’exemple de complétions documenté de vLLM. Remplacez le modèle et le jeu de données par des ressources que vous êtes autorisé à exécuter et qui conviennent à votre matériel. Ces commandes sont un modèle reproductible, et non des résultats mesurés de Flatkey.

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

Dans un second terminal, une fois le serveur prêt :

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

Répétez ensuite l'opération avec une courte série de valeurs plus élevées de --request-rate tout en conservant les autres paramètres fixes. Utilisez suffisamment de prompts pour éviter d'interpréter une poignée de requêtes comme une distribution de latence de queue. Enregistrez les résultats bruts et la commande exacte pour chaque exécution. L'exemple de benchmark en ligne officiel présente les champs de sortie et explique comment --save-result et --save-detailed préservent les éléments de preuve. Pour les requêtes de chat, utilisez le backend openai-chat documenté et le point de terminaison /v1/chat/completions avec un jeu de données et un modèle prenant en charge le formatage de chat.

N'exécutez pas ce benchmark sur un point de terminaison de production partagé sans plan de trafic. Il génère intentionnellement de la charge. Utilisez un déploiement de test isolé ou une fenêtre de maintenance contrôlée, et consignez toute activité d'arrière-plan susceptible d'affecter le résultat.

Balayez jusqu'à trouver le point d'inflexion de la latence

Représentez le taux de requêtes proposé sur l'axe horizontal. Représentez les requêtes terminées par seconde, le TTFT p95, la latence de bout en bout p95 et les tokens de sortie par seconde sous forme de séries distinctes. Au début, le débit peut augmenter approximativement avec la charge proposée. Au-delà de la zone soutenable, la file d'attente s'allonge, la latence de queue augmente et le débit réussi peut plafonner. Ce point d'inflexion importe davantage que le plus grand chiffre affiché lors d'une seule exécution.

Conservez une exécution de préchauffage distincte. vLLM avertit que la répétition d'un benchmark sur le même serveur peut réutiliser des préfixes mis en cache et gonfler le débit. Si la réutilisation du cache ne fait pas partie de la charge de travail du produit, faites varier la graine ou réinitialisez le serveur ou le cache conformément aux recommandations officielles de benchmark. Si la réutilisation du cache est réaliste, indiquez le taux de succès du cache et incluez une comparaison avec cache froid. Un benchmark sans politique de cache déclarée est difficile à reproduire.

Lorsqu'une exécution n'atteint pas son objectif, examinez la séquence. Une augmentation du TTFT avec une file d'attente croissante peut indiquer une saturation ou un contrôle d'admission. Un TPOT médiocre avec un temps de file d'attente stable peut indiquer un problème de décodage, de bande passante mémoire, de parallélisme ou un choix de précision inefficace. Si les échecs augmentent, examinez les délais d'expiration, les OOM et les journaux du serveur avant d'ajuster les paramètres du modèle. Modifier plusieurs variables à la fois masque la cause.

Comparez les options GPU selon le travail accepté, et non la vitesse brute

Un GPU plus grand peut produire davantage de tokens de sortie par seconde tout en coûtant plus cher par requête acceptée. Calculez un coût approximatif pour chaque configuration :

Coût GPU pour 1 000 requêtes réussies = coût GPU horaire ÷ requêtes réussies par heure × 1 000

Utilisez un devis actuel pour la région et l'engagement exacts, et incluez l'infrastructure non GPU ou les incréments de facturation minimums s'ils sont pertinents. Comparez uniquement les exécutions qui atteignent vos objectifs de latence et d'erreur. Une configuration moins chère qui ne respecte pas le TTFT p95 n'est pas une solution moins chère pour fournir le même service.

Pour une première comparaison dans le cloud, conservez le modèle et la configuration de serving fixes tout en ne modifiant que le type de GPU. Testez ensuite un petit nombre de modifications de réglage, telles que les paramètres de lot et de mémoire, une à la fois. Capturez l'utilisation, la marge de VRAM, la profondeur de file d'attente, le taux de réussite des requêtes et l'artefact de benchmark. Flatkey Compute peut être une option de capacité à évaluer ; vérifiez le GPU proposé, la région et le devis actuel avant de l'utiliser dans une comparaison de coûts. Ce guide n'affirme pas qu'un GPU particulier est toujours plus rapide ou moins cher.

Un résultat de benchmark vLLM que vous pouvez remettre à un évaluateur

Pour chaque exécution, consignez : le modèle et sa révision ; les versions de vLLM et du pilote ; le GPU et la topologie ; la commande et la somme de contrôle du jeu de données ; la distribution des longueurs d'entrée/sortie ; l'emplacement du client ; la politique de cache ; le taux de requêtes ; les requêtes terminées et échouées ; le TTFT p50/p95/p99 ; la latence de bout en bout p50/p95/p99 ; le débit de tokens de sortie ; l'utilisation du GPU et la VRAM ; le devis horaire ; le coût par requête acceptée ; et la réussite ou l'échec par rapport à l'objectif prédéterminé.

C'est également le moment de garder la sécurité et la qualité visibles. Les prompts de benchmark doivent être purgés des données client, et la qualité des sorties doit être vérifiée lors de la comparaison de modèles quantifiés ou de différentes révisions de modèle. Un gain de vitesse apparent qui modifie la qualité des tâches n'est pas une amélioration comparable à périmètre égal.

Questions fréquentes

vllm bench throughput est-il identique à vllm bench serve ?

Non. Le premier vise le débit d’inférence hors ligne ; le second envoie des requêtes en ligne à un serveur en cours d’exécution et mesure le comportement de service côté client. Utilisez bench serve pour la planification de la latence et de la capacité d’un déploiement d’API. La référence CLI de vLLM répertorie les deux commandes.

Quelle métrique dois-je optimiser en premier ?

Commencez par l’objectif de service : le taux de réussite et la latence de queue au trafic de pointe attendu. Réduisez ensuite le coût au minimum parmi les configurations qui satisfont ces critères. Le débit agrégé de jetons est utile pour diagnostiquer la capacité, mais il ne peut pas remplacer un objectif de latence côté utilisateur.

Puis-je comparer les chiffres de benchmark publiés par différents fournisseurs ?

Uniquement si le modèle, la précision, la charge de travail, la longueur de sortie, le point de terminaison, la politique de cache, le régime de taux de requêtes et les définitions des mesures concordent. Dans la plupart des cas, réexécuter la même charge de travail dans les deux environnements fournit une comparaison plus défendable.

Étape suivante : prenez une trace représentative, fixez les critères de validation, effectuez un court balayage de taux sur deux configurations GPU et conservez les résultats complets avec la décision. Si vous modifiez également la précision, utilisez le guide de quantification vLLM distinct pour évaluer la mémoire et la qualité avant d’attribuer toute différence de vitesse au GPU.