Évaluation comparative de l’inférence LLM à grande échelle avec AIPerf

Benchmarking de l’inférence LLM à l’échelle avec AIPerf

Une démo peut servir une poignée de requêtes par seconde et sembler instantanée. Le même service, sous des centaines d’utilisateurs simultanés, peut passer des secondes à faire la queue avant d’émettre un seul token. Rien n’a changé dans le modèle. Ce qui a changé, c’est que la première mesure a été prise sur un système au repos, et la seconde sur un système chargé.

Cet écart est toute la raison d’être d’un outil de benchmarking dédié à l’inférence de grands modèles de langage. L’article de blog IA de NVIDIA Benchmarking LLM Inference at Scale with AIPerf (https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf) traite d’AIPerf, un outil conçu exactement pour ce problème. Cet article prend ce billet comme ancrage factuel, puis explique la méthodologie qui l’entoure : comment formuler un benchmark d’inférence, quels chiffres méritent confiance, et où la mesure déraille discrètement.

Une note sur les sources, dite clairement. Le fait vérifié qui sous-tend cet article est que NVIDIA a publié le billet ci-dessus au sujet d’AIPerf. Les spécificités de l’outil — son interface, les points de terminaison pris en charge, les types de charges de travail et son ensemble de fonctionnalités — appartiennent à ce billet et à sa documentation, et elles évoluent avec le temps. Tout ce qui suit sur la méthodologie relève de conseils et d’interprétation, et non d’une affirmation sur les rouages internes d’AIPerf. Lorsque cet article ne peut pas vérifier quelque chose, il le dit plutôt que de le deviner.

Pourquoi l’inférence LLM brise les tests de charge conventionnels

Les tests de charge web traditionnels supposent que les requêtes sont courtes, peu coûteuses et interchangeables. L’inférence LLM viole ces trois hypothèses à la fois.

Une requête ne produit pas une seule réponse ; elle produit un flux de tokens au fil du temps. La latence n’est donc pas un scalaire mais une courbe comportant au moins deux régions distinctes : l’attente avant le premier token et la cadence entre les tokens suivants. La perception de la vitesse par un utilisateur dépend principalement de la première région. La perception de la fluidité dépend de la seconde. Un seul « temps de réponse moyen » réduit les deux à un nombre qui ne décrit ni l’une ni l’autre.

Le coût est également variable d’une manière que les requêtes web ne connaissent pas. Un prompt court qui produit vingt tokens et un prompt long qui en produit deux mille sont la même requête HTTP du point de vue du réseau et des charges de travail complètement différentes du point de vue du serveur. Les benchmarks qui les traitent comme équivalentes produisent des chiffres de débit qui ne peuvent être comparés à rien.

Enfin, les serveurs d’inférence sont stateful d’une manière qui compte. Les décisions de batching, l’occupation du cache KV et la pression mémoire dépendent toutes de ce qui d’autre est en cours. Une requête qui arrive dans un cache vide se comporte différemment d’une requête qui arrive derrière un millier de prompts similaires. Tout benchmark qui ne neutralise pas cet état mesure autant l’historique que la capacité.

Ce qu’est AIPerf et où il s’inscrit

Les générateurs de charge polyvalents peuvent produire du trafic HTTP. Produire une charge de travail réaliste de streaming de tokens, enregistrer le timing par token, maintenir une concurrence suffisante pour saturer un accélérateur moderne et agréger les résultats en éléments exploitables pour la décision est un problème d’ingénierie différent — qui justifie un outil conçu pour cela.

C’est la catégorie qu’occupe AIPerf, selon le billet de NVIDIA. L’implication pratique pour une équipe qui évalue une infrastructure d’inférence est simple : le choix de l’outil importe moins que la discipline avec laquelle il est utilisé. Un benchmark bien conçu exécuté avec un outil modeste bat à chaque fois une exécution négligée avec un outil sophistiqué.

Le reste de cet article porte sur cette discipline.

Les métriques qui comptent vraiment

Cinq mesures font l’essentiel du travail.

Time to first token (TTFT) capture le prefill, la mise en file d’attente et l’ordonnancement — tout ce qui se produit avant que l’utilisateur ne voie quoi que ce soit. C’est le principal facteur déterminant de la réactivité perçue dans les applications interactives.

Inter-token latency (ITL), parfois exprimée comme le temps par token de sortie, capture la boucle de décodage. Elle détermine si la sortie paraît fluide ou saccadée. Elle est généralement rapportée sous forme de médiane parce que le premier token est exclu, et parce que la cadence de décodage est relativement stable jusqu’à ce que le serveur sature.

La latence de bout en bout est la somme des deux plus la génération complète. Elle importe surtout pour les charges de travail par lots et agentiques, où aucun humain ne regarde le flux.

Le débit doit être précisé avec exactitude, car deux nombres différents portent ce nom. Le débit de requêtes compte les requêtes terminées par seconde. Le débit de tokens compte les tokens générés par seconde. Un système peut améliorer l’un tout en dégradant l’autre, et les fournisseurs précisent rarement lequel ils désignent.

Le goodput est la métrique qui résout cela. Elle ne compte que les requêtes qui ont satisfait à un objectif de niveau de service défini. Une configuration qui produit 6 000 tokens par seconde tout en manquant son objectif de latence sur un tiers des requêtes a un problème de goodput, pas un triomphe de débit.

Rapportez des percentiles, pas des moyennes. Un p50 qui semble sain à côté d’un p99 quarante fois plus grand décrit un système qui va bien la plupart du temps et est inutilisable parfois — ce qui, pour un produit interactif, est un système défaillant.

Associez toujours la charge de travail au chiffre. « 5 000 tokens par seconde » ne veut rien dire sans les distributions de longueur des prompts et des sorties, le niveau de concurrence, le matériel et les versions logicielles. Sans cela, c’est un chiffre marketing, pas une mesure.

Définir la charge de travail avant de mesurer quoi que ce soit

La plupart des mauvais benchmarks sont mauvais avant même l’envoi de la première requête, parce que la charge de travail n’a jamais été spécifiée.

Commencez par la longueur d’entrée. Les prompts réels ne sont pas uniformes ; un assistant de chat avec récupération produit une distribution à longue traîne. Les tests synthétiques qui utilisent une seule longueur de prompt fixe sont utiles pour isoler des variables et trompeurs lorsqu’ils sont présentés comme représentatifs.

Puis la longueur de sortie. Si le serveur s’arrête à un nombre maximal de tokens, les requêtes qui atteignent ce plafond révèlent quelque chose sur la charge de travail, pas sur le serveur. Décidez à l’avance si les réponses plafonnées comptent comme des succès.

Puis le profil d’arrivée. C’est là que réside la décision de conception la plus lourde de conséquences. Dans un test en boucle fermée, un nombre fixe de clients virtuels n’envoient chacun leur requête suivante qu’après l’achèvement de la précédente. Ce modèle est facile à appréhender et sous-estime systématiquement la surcharge : lorsque le serveur se bloque, les clients attendent poliment, et ce blocage n’est jamais enregistré comme latence. Dans un test en boucle ouverte, les requêtes arrivent selon un calendrier indépendant, que les requêtes précédentes soient terminées ou non. Les délais de mise en file d’attente apparaissent alors là où ils se produisent réellement — dans l’expérience de l’utilisateur.

Ce mode de défaillance est connu sous le nom d’omission coordonnée, et c’est la manière la plus courante pour un benchmark d’inférence de flatter un système. Si votre test ne demande jamais que « à quelle vitesse cette requête a-t-elle été traitée ? » et jamais « combien de temps un utilisateur aurait-il attendu pour sa requête ? », vous avez mesuré le temps de service, pas la latence.

Enfin, décidez à l’avance le balayage de concurrence. Un seul point de concurrence ne vous apprend presque rien ; la forme de la courbe est le résultat.

Un exemple pratique : construire un plan de benchmark

Le scénario ci-dessous est illustratif. Les nombres sont des choix de conception, pas des résultats mesurés.

Supposons que vous qualifiiez un assistant de chat qui préfixe un long prompt système et un contexte récupéré, puis génère des réponses courtes. L’entrée attendue est d’environ 2 000 tokens, la sortie attendue d’environ 150.

Étape un : énoncez l’objectif comme une contrainte, pas un souhait. Par exemple : TTFT p95 inférieur à 800 ms et latence inter-token p95 inférieure à 50 ms, soutenus à 40 requêtes par seconde. Écrire cela d’abord évite le résultat courant consistant à exécuter un benchmark puis à décider quel chiffre semblait impressionnant.

Étape deux : construisez le balayage. Exécutez à des niveaux de concurrence de 1, 8, 32, 128 et 512. Maintenez chaque niveau pendant une fenêtre fixe assez longue pour atteindre un régime permanent. Gardez la distribution des longueurs de prompt identique entre les niveaux afin que les changements de la courbe reflètent la charge, pas le contenu.

Étape trois : figez tout. Révision du modèle, configuration de service, paramètres de parallélisme, limites de batch, matériel client et chemin réseau. Un benchmark non figé produit une anecdote, pas un résultat.

Étape quatre : préchauffez, puis écartez. Les premières requêtes face à un cache froid ne sont pas représentatives d’un fonctionnement en régime permanent. Lancez une phase de préchauffage et excluez-la du rapport.

Étape cinq : répétez et rapportez la dispersion. Trois exécutions à chaque niveau de concurrence, avec la variance indiquée. Une seule exécution qui se trouve être bonne n’est pas une preuve.

Étape six : trouvez le coude, pas le pic. Le débit augmente à peu près linéairement avec la concurrence jusqu’à ce qu’une file d’attente se forme. Au-delà, le débit s’aplatit ou diminue tandis que la latence grimpe fortement. Le résultat utile de l’exercice n’est pas le chiffre le plus élevé que le système ait jamais produit ; c’est la concurrence la plus élevée à laquelle l’objectif de niveau de service tient encore. C’est votre point de fonctionnement.

Où les benchmarks d’inférence se trompent

Le client devient le goulot d’étranglement. La tokenisation, les handshakes TLS et l’échantillonnage par token sont du travail CPU. À forte concurrence, le générateur de charge peut saturer avant le serveur, et vous finissez par mesurer votre machine de benchmark. Confirmez la marge du client avant de faire confiance à un résultat en haut de la courbe.

Les effets de cache gonflent les résultats. Répéter un petit ensemble de prompts identiques produit une réutilisation de cache irréalistement élevée. Utilisez une diversité de prompts correspondant à la production, ou indiquez explicitement que vous mesurez un meilleur cas avec cache chaud.

Les tokeniseurs ne correspondent pas. Compter les tokens avec un tokeniseur différent de celui utilisé par le serveur produit des chiffres de débit faux de quelques pour cent et jamais réconciliés.

La configuration dérive entre les exécutions. Comparer une exécution en parallélisme huit voies à une exécution en quatre voies, ou une exécution avec des paramètres d’échantillonnage différents, produit une différence qui n’a rien à voir avec le changement testé.

La queue est gommée par la moyenne. Rapporter la latence moyenne masque précisément le comportement qui génère les plaintes des utilisateurs et les tickets d’incident.

Le débit est optimisé au détriment de la réactivité. Une configuration avec un excellent débit de tokens et un mauvais TTFT peut être le bon choix pour le traitement par lots hors ligne et le mauvais choix pour une interface de chat. L’ensemble de métriques doit suivre le produit.

Le comportement en surcharge n’est jamais testé. Dépassez délibérément le coude. Le système se dégrade-t-il gracieusement, en délestant la charge et en maintenant la latence, ou s’effondre-t-il brutalement ? Ce comportement est plus précieux à connaître que le chiffre de pic.

Mettre à l’échelle le benchmark lui-même

Au-delà de quelques centaines de flux concurrents, le benchmark devient un système distribué et hérite des problèmes des systèmes distribués.

Les percentiles ne se moyennent pas. Fusionner les p99 de trois générateurs de charge en prenant leur moyenne n’a arithmétiquement aucun sens. Une agrégation correcte exige des distributions de latence fusionnées ou des histogrammes collectés auprès de chaque worker — un détail qui corrompt silencieusement les résultats dans des évaluations par ailleurs soignées.

L’alignement des horloges compte pour la même raison. Si les workers ne sont pas d’accord sur l’heure actuelle, la mesure temporelle par requête devient bruitée exactement à l’échelle où la précision compte le plus.

Les exécutions prolongées à forte concurrence nécessitent aussi la réutilisation des connexions et une gestion mémoire soignée côté client. Un générateur qui alloue à chaque token passera son temps dans le ramasse-miettes plutôt que dans la mesure.

Enfin, les charges de travail multi-tours et à long contexte ajoutent une dimension que les tests à requête unique manquent entièrement. L’état de session, le contexte croissant et les préfixes répétés modifient le comportement du cache de manières qui n’apparaissent que lorsqu’un benchmark modélise une conversation plutôt qu’une requête.

Interpréter et rapporter les résultats

Un rapport de benchmark qui ne peut pas être reproduit n’est pas un rapport. Au minimum, il doit contenir la définition de la charge de travail, les versions matérielles et logicielles, les niveaux de concurrence testés, les valeurs des métriques avec percentiles, et un verdict explicite par rapport à l’objectif de niveau de service.

Un tableau compact fonctionne bien, et celui ci-dessous est un modèle avec des valeurs de remplacement, pas des données mesurées :

Le livrable de cet exercice n’est pas un nombre. C’est une enveloppe de fonctionnement documentée : la plage de charge à l’intérieur de laquelle le service se comporte comme promis, et une description de ce qui se passe en dehors.

Limites non résolues

Plusieurs choses que cet article ne peut pas trancher. La performance d’un modèle spécifique sur un matériel spécifique avec une pile de service spécifique dépend des trois, et aucune recommandation générale ne remplace l’exécution de votre propre charge de travail. Les fonctionnalités des outils évoluent, donc la description faisant autorité des capacités d’AIPerf est le billet source lui-même, pas un résumé secondaire. Et un benchmark, aussi soigneusement soit-il exécuté, caractérise une configuration à un instant donné ; il ne prédit pas le comportement après une mise à jour de pilote, un changement de batching ou une modification de la répartition du trafic.

Traitez les résultats publiés, y compris les favorables, comme des hypothèses sur votre déploiement plutôt que comme des conclusions à son sujet.

Conclusion

L’inférence LLM à l’échelle ne se comporte pas comme le trafic web, et les outils conçus pour le trafic web mesurent les mauvaises choses. Le travail de benchmarking se résume à quelques choix disciplinés : définir la charge de travail avant de l’exécuter, balayer la concurrence plutôt que tester un point unique, préférer des profils d’arrivée en boucle ouverte afin que les délais de mise en file d’attente soient visibles, rapporter des percentiles plutôt que des moyennes, et traiter le goodput — pas le débit de pointe — comme le nombre qui détermine si le système est réellement utilisable.

AIPerf existe pour rendre cette mesure pratique à l’échelle. L’outillage raccourcit la distance entre une question et une réponse ; il ne décide pas quelle question poser. Cette décision — l’objectif, la charge de travail et le point de fonctionnement que vous êtes prêt à mettre en production — vous revient.