Runpod montre comment GuideLLM aide à tirer le maximum de vLLM

Runpod a publié sur son blog un guide consacré à l'association de vLLM et de GuideLLM. L'idée est simple : avant d'ouvrir un modèle aux utilisateurs, simulez un trafic réel et observez trois chiffres, le temps jusqu'au premier token, la latence entre tokens et le débit. Ce sont eux qui déterminent le nombre de GPU nécessaires et le prix que vous paierez pour un million de tokens. La publication d'origine est courte : c'est plutôt l'annonce d'un guide pratique, et elle ne contient donc aucun benchmark chiffré sur des cartes précises. La méthode mérite néanmoins qu'on s'y attarde.

Pourquoi « c'est rapide sur mon portable » ne prouve rien

vLLM est depuis longtemps l'un des moteurs d'inférence standard pour les modèles ouverts. Il s'appuie sur le batching continu et sur PagedAttention pour gérer le KV-cache, et il fonctionne très bien avec quelques requêtes. Les problèmes apparaissent sous charge. Quand des dizaines de requêtes arrivent en même temps, avec des prompts de longueurs différentes, le cache se remplit, la file d'attente s'allonge et la latence du premier token peut être multipliée.

Une requête isolée ne révèle rien de tout cela. Il faut un générateur de charge qui se comporte comme des utilisateurs : les requêtes n'arrivent pas une par une mais par vagues, avec des prompts et des réponses de longueurs variables. C'est précisément le rôle de GuideLLM, un outil open source de l'écosystème vLLM. Il interroge un endpoint compatible OpenAI, envoie des requêtes synthétiques ou celles que vous avez définies, et collecte les statistiques.

À quoi ressemble un test

Le schéma sur Runpod est classique. Vous lancez un pod ou un worker serverless avec vLLM, vous récupérez l'adresse de l'endpoint, puis vous démarrez GuideLLM depuis ce même environnement ou depuis une autre machine. Vous définissez ensuite le profil de charge : longueur de l'entrée et de la sortie en tokens, mode d'envoi des requêtes et durée.

On dispose en général d'un débit constant, d'un flux de Poisson, d'un mode de débit maximal et d'une exécution séquentielle, qui évite de surcharger le serveur. Pour une première exploration, le mode sweep est pratique : il parcourt une charge croissante et montre à quel endroit la courbe de latence se brise. Les noms exacts des options changent d'une version à l'autre, mieux vaut les vérifier dans la documentation.

En sortie, vous obtenez un rapport avec les indicateurs suivants :

• TTFT, le temps jusqu'au premier token : il détermine la réactivité perçue du chat ;
• ITL, la latence entre tokens : elle conditionne la fluidité du streaming ;
• la latence de bout en bout d'une requête complète, importante pour les API et les chaînes d'agents ;
• les requêtes par seconde que le serveur supporte avant de se dégrader ;
• les tokens par seconde et par carte, valeur clé pour calculer le coût ;
• le nombre de requêtes simultanées à partir duquel les files d'attente s'allongent.

Tout l'intérêt est dans la comparaison. Si le TTFT reste dans la valeur cible jusqu'à un certain niveau de charge, puis grimpe, c'est votre plafond de fonctionnement sur la configuration actuelle.

En pratique : des métriques à la facture GPU

Voici la marche à suivre.

1. Décrivez votre trafic réel : longueur moyenne et maximale du prompt, longueur de la réponse, pic de charge. Si vous n'avez pas encore de logs, partez d'estimations prudentes et affinez-les plus tard.

2. Fixez des valeurs cibles de TTFT et d'ITL. Elles ne seront pas les mêmes pour une interface de chat et pour un traitement de documents par lots.

3. Lancez un sweep sur plusieurs configurations : différents GPU, différentes quantifications, différentes valeurs de longueur de contexte maximale et de part de mémoire allouée au KV-cache. 4.

Pour chaque configuration, trouvez la charge maximale à laquelle les objectifs sont tenus, puis divisez le prix horaire de la carte par le nombre de tokens obtenu. C'est le prix réel du token. 5.

Pour un déploiement serverless, vérifiez aussi le démarrage à froid et le comportement en cas de forte hausse soudaine de la file d'attente : un benchmark statique ne les montrera pas.

Il y a une réserve. La charge synthétique reste un modèle, pas la réalité. Si vos utilisateurs ont de longs prompts système avec un préfixe commun, l'activation du prefix caching changera la donne, et le test doit en tenir compte. Les résultats dépendent aussi de la version de vLLM, des pilotes et de la carte utilisée : il vaut donc mieux refaire un test après chaque mise à jour.

L'intérêt principal d'un tel guide tient à la discipline qu'il impose. Choisir un GPU et des réglages au feeling se termine généralement par un surcoût pour une marge dont personne ne se sert. Une demi-heure de test de charge produit des chiffres que l'on peut poser sur le bureau du directeur financier.