AIPerf : mesurer son serveur LLM sans se tromper

Ce qui se passe

Un modèle tourne sur votre serveur, les réponses arrivent : est-ce rapide ? La boucle de curl ou le script asyncio écrit en dix minutes donnent un chiffre, mais pas forcément celui du serveur. Un client mono-processus plafonne vite, le GIL de Python limitant la concurrence, et c'est lui qui devient le goulot.

NVIDIA présente AIPerf, désigné comme successeur de GenAI-Perf et réécrit de zéro. Il ne repose plus sur Perf Analyzer : des processus générateurs de charge, des services séparés pour traiter les résultats, le tout coordonné par ZeroMQ. Il gère plus de quinze types de points d'accès (chat, responses, rankings, génération d'images…), les jeux de données publics comme ShareGPT et le rejeu de traces de production (formats Mooncake, Baseten, WEKA).

Comment s'y prendre

Avec un serveur vLLM servant Qwen/Qwen3-0.6B sur le port 8000 :

uv tool install aiperf

aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --synthetic-input-tokens-mean 128 --synthetic-input-tokens-stddev 0 \
  --output-tokens-mean 128 --output-tokens-stddev 0 \
  --extra-inputs min_tokens:128 \
  --extra-inputs ignore_eos:true

Trois options portent l'essentiel de la méthode :

• --streaming : sans lui, le serveur renvoie la réponse d'un bloc, et ni le temps jusqu'au premier token (TTFT) ni l'intervalle entre tokens (ITL) ne sont mesurables.
• min_tokens et ignore_eos : sans eux, le modèle s'arrête quand il a fini, souvent avant la longueur visée ; le débit mesuré est alors trop bas et change d'un essai à l'autre.
• les écarts-types à 0 fixent exactement 128 tokens en entrée et en sortie, le scénario statique le plus courant.

Passer à une charge réaliste

aiperf profile --model Qwen/Qwen3-0.6B --endpoint-type chat --streaming \
  --url localhost:8000 \
  --request-rate 10 --arrival-pattern poisson \
  --synthetic-input-tokens-mean 512 --synthetic-input-tokens-stddev 128 \
  --output-tokens-mean 128 --output-tokens-stddev 32 \
  --random-seed 42 --request-count 200

Les requêtes arrivent en moyenne à 10 par seconde, avec des rafales et des creux, et des prompts de 154 à 818 tokens dans l'exemple publié. La graine rend la séquence rejouable. Résultat : la distribution du TTFT s'étale nettement par rapport au cas d'un seul utilisateur, parce que préremplissage et décodage se chevauchent.

Ce que ça change

AIPerf rend TTFT, ITL, latence de requête et débit en tokens par seconde, en percentiles (p25, p50, p75, p90, p95, p99), en CSV et en JSON, avec la commande pour refaire le test. Avec DCGM ou pynvml, il ajoute puissance, utilisation et mémoire du GPU dans la même sortie. Le p99 est le chiffre à regarder : une moyenne saine peut cacher une queue de distribution qui casse en production.

Limite pratique : sur aarch64, la dépendance crick n'existe qu'en source et demande une chaîne de compilation C (build-essential sur Debian/Ubuntu).

Source : Benchmarking LLM Inference at Scale with AIPerf, NVIDIA Developer, 18 septembre 2026. Dépôt : ai-dynamo/aiperf.