Illustration conceptuelle : le délai initial, le rythme de diffusion et le débit global décrivent différents aspects d’un service. Il ne s’agit pas de données mesurées.
Un serveur peut produire davantage de tokens par seconde alors que la fenêtre de conversation met plus de temps à afficher une réponse. Avant de valider une mise à niveau de l’inférence, une question pratique s’impose : quelle partie de l’attente de l’utilisateur cherchons-nous à réduire ?
Deux façons d’aller « plus vite » dans un même bilan
La PR vLLM #60140, fusionnée le 6 octobre, présente des résultats pour GLM-5.3 après le passage à un cache KV en FP8. Avec TP4, 8 000 tokens en entrée, 1 000 tokens en sortie et 1, 4 ou 16 requêtes simultanées, le tableau indique des gains de débit de 2,3 % à 5,5 %. Pourtant, le délai médian avant le premier token (TTFT) a augmenté de 6,9 % à 11,1 %. La latence totale médiane a diminué de 3,1 % à 6,3 % : la réponse commençait plus tard, mais se terminait plus tôt. Source : PR #60140
Ces résultats ont été publiés par un contributeur ; nous ne les avons pas reproduits. Ils ne comprennent pas non plus de série de tests couvrant des entrées plus longues. Un correctif ultérieur a limité ce comportement par défaut à NVIDIA SM100. Appliquer ces conclusions à tous les déploiements de GLM irait au-delà des éléments disponibles. Source : PR #60281
Distinguer les différentes phases de l’attente
L’utilisateur attend d’abord une première sortie, puis davantage de contenu, et enfin la réponse complète. Le débit du serveur mesure la production globale ; le TTFT mesure le délai initial ; la latence inter-token (ITL) décrit les intervalles entre deux sorties successives diffusées en continu ; le temps total couvre l’ensemble de la requête. Le TTFT mesuré côté serveur par vLLM comprend le traitement de l’entrée : il ne mesure donc pas uniquement le temps de calcul du GPU. Les délais liés au réseau, à la passerelle et à l’affichage méritent aussi d’être observés côté client. Source : conception des métriques
L’ordonnancement implique des compromis. Le préremplissage par blocs (« chunked prefill ») de vLLM découpe les longues entrées et en planifie le traitement aux côtés des requêtes dont la génération est déjà en cours. Selon la documentation, un budget de tokens par lot plus faible favorise l’ITL, tandis qu’un budget plus élevé favorise le TTFT. Cela explique, de manière générale, pourquoi les métriques de latence peuvent évoluer différemment. La PR citée plus haut n’établit pas que ce mécanisme soit la cause de la dégradation du TTFT lors de ce passage au FP8. Source : guide d’optimisation
La mise en cache économise elle aussi du travail dans une phase précise. Le cache de préfixes réutilise les calculs associés à un préfixe d’entrée commun, ce qui facilite le préremplissage (« prefill »), sans réduire directement le travail de décodage (« decode ») qui génère de nouveaux tokens. Des questions répétées sur un même document long peuvent donc en bénéficier différemment de charges de travail dominées par de longues réponses. Source : cache de préfixes et limites
Définir les critères de validation avant la mise à niveau
Le plan de test ci-dessous est notre proposition, et non un ensemble d’expériences déjà réalisées.
-
Garder des conditions de comparaison stables. Consigner le GPU, la version du modèle, le commit du framework d’inférence, la quantification, le parallélisme, le décodage spéculatif et les paramètres d’échantillonnage. Ne modifier à chaque fois que l’élément évalué, afin de pouvoir identifier l’origine d’un gain.
-
Construire une petite matrice. Choisir trois types de tâches réelles : conversations courtes, réponses courtes sur des documents longs et sorties longues. Tester chacun avec des préfixes nouveaux et des préfixes réutilisables, sous une charge faible, habituelle et proche de la capacité maximale. Cela donne 18 cases. Les entrées doivent rester dans les limites prises en charge par le modèle, et les niveaux de charge doivent être choisis à partir de votre propre trafic.
-
Ajouter un pic de trafic. Relever le taux d’arrivée effectif, le nombre effectif de requêtes simultanées, l’attente en file et les requêtes en échec. Un test à nombre fixe de requêtes simultanées et un afflux soudain d’utilisateurs exercent des pressions différentes ; un mécanisme de limitation peut aussi déplacer l’attente vers le client. L’outil de benchmark de vLLM distingue le taux de requêtes du nombre maximal de requêtes simultanées et expose des métriques de file d’attente côté client. Source : paramètres du benchmark
-
Conserver un bilan complet pour chaque case. Relever au minimum les p50/p95/p99 du TTFT, de l’ITL et de la latence totale, ainsi que le débit, les succès de recherche en cache, les préemptions, les dépassements de délai et le taux d’erreur. Répéter les tests de manière indépendante et préciser les méthodes de préchauffage et les tailles d’échantillon. Interpréter les percentiles extrêmes avec une prudence particulière lorsque les échantillons sont petits. Une modification de la quantification exige aussi une vérification distincte de la qualité sur les tâches : la vitesse ne démontre pas l’exactitude.
-
Fixer les seuils avant de comparer les gains. Un assistant interactif peut privilégier la première sortie et les pauses dans la diffusion ; un traitement par lots hors ligne peut privilégier le volume achevé. Les seuils concrets doivent découler des exigences du produit. Compter les requêtes réussies qui respectent aussi les objectifs de latence donne une mesure plus utile de la capacité du service. vLLM permet de définir des seuils de débit utile (« goodput ») pour le TTFT, le temps par token de sortie et la latence de bout en bout. Source : option goodput
Relier le résultat à l’expérience utilisateur
Un rapport de validation utile devrait répondre à une question concrète : « Avec notre trafic et nos exigences de qualité, combien de requêtes supplémentaires pouvons-nous terminer par heure, et combien de temps attendront les utilisateurs servis le plus lentement ? »
Un débit plus élevé est bienvenu. L’examiner avec les temps d’attente, la qualité et les échecs permet de voir précisément ce qu’une mise à niveau améliore.
Sources vérifiées le 19 octobre 2026. Cette analyse technique s’appuie sur des benchmarks publics de contributeurs et sur la documentation officielle. La matrice de test est notre proposition ; nous n’avons effectué aucun test indépendant de performance ou de qualité. Les pages « latest » de la documentation peuvent évoluer. Vérifiez la version que vous déployez réellement.