Mesurer mémoire et performance

Deux mesures dominent l'expérience d'un modèle local : la mémoire maximale utilisée et le temps nécessaire pour répondre. Les annoncer sans protocole produit des comparaisons trompeuses.

Estimer les poids

La taille théorique des poids se calcule approximativement avec le nombre de paramètres multiplié par le nombre de bits, puis divisé par huit.

Le fichier réel peut être plus grand à cause des métadonnées et des structures propres au format. La mémoire en exécution ajoute d'autres éléments.

Ce qui s'ajoute

• Le KV cache grandit avec le contexte, le batch et l'architecture.
• Les buffers temporaires accueillent des calculs intermédiaires.
• Le runtime, les bibliothèques et le pilote occupent leur propre mémoire.
• L'interface et le système d'exploitation conservent une marge.

Latence avant le premier token

La latence initiale mesure le temps entre l'envoi de la demande et l'apparition du premier token. Elle dépend du chargement du modèle, de la longueur du prompt, de la vitesse mémoire et de la planification du runtime.

Une interface peut sembler lente malgré un bon débit si le prompt est long. Inversement, un premier token rapide ne garantit pas une génération soutenue.

Débit de génération

Le débit s'exprime souvent en tokens par seconde. Cette mesure dépend du modèle, de la quantization, du batch, du contexte et du matériel. Comparez uniquement des tests réalisés avec une configuration explicitée.

Mesurer en pratique

Pendant qu'un modèle répond, observez la mémoire réellement occupée. Sur un GPU NVIDIA, cette commande affiche chaque seconde la VRAM utilisée et la charge du GPU. Arrêtez-la avec Ctrl+C :

nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv -l 1

Pour la RAM, utilisez free -h sous Linux, l'onglet Performances du Gestionnaire des tâches sous Windows ou le Moniteur d'activité sous macOS.

Ollama affiche ses propres mesures avec l'option --verbose :

ollama run qwen3:8b --verbose "Résume le rôle de la VRAM en trois phrases."

En fin de réponse, prompt eval rate donne la vitesse de traitement du prompt et eval rate le débit de génération, en tokens par seconde. load duration indique le temps de chargement du modèle : il disparaît quand le modèle est déjà en mémoire, d'où l'intérêt d'une exécution de chauffe.

Avec llama.cpp, l'outil llama-bench répète les mesures pour vous :

llama-bench -m ./modeles/qwen3-8b-q4_k_m.gguf -p 512 -n 128 -r 5

La ligne pp512 mesure le traitement d'un prompt de 512 tokens et la ligne tg128 la génération de 128 tokens, chacune répétée cinq fois. Le résultat s'exprime en tokens par seconde, avec son écart type.

Construire un benchmark reproductible

Fixez le modèle exact, le fichier de quantization, le runtime et sa version, le nombre de threads, le contexte, le prompt, la longueur de sortie et le nombre de répétitions.

Effectuez une première exécution de chauffe, puis plusieurs mesures. Conservez la médiane plutôt que le meilleur résultat. Relevez la température et la consommation si la machine peut réduire sa fréquence en charge.

Tester la concurrence

Un serveur destiné à plusieurs utilisateurs doit être testé avec plusieurs requêtes simultanées. Le débit total peut augmenter pendant que la latence individuelle se dégrade. Le scheduler choisit comment regrouper ou intercaler les demandes.

Mesurer pour décider

Le but n'est pas de battre un record. Mesurez jusqu'à répondre à une question : ce modèle tient-il en mémoire, répond-il assez vite et conserve-t-il cette performance sous votre charge ? Une fois la réponse obtenue, optimisez seulement le goulot d'étranglement observé.