Contents — find the section you need

Change parameters and verify

Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.

Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.

The experiment controls are in English.

Open experiment panel in a new tab

Download reproduction source

Le nombre de jetons par seconde ne suffit pas à expliquer le temps d'attente après l'envoi d'une requête. Il est nécessaire de mesurer séparément le contenu de la première réponse, le taux de génération, le temps d'exécution et la mémoire. Cet article décrit une procédure de mesure et fournit un client ; aucun test de performance sur un modèle réel ni aucun classement matériel n'ont été effectués.

Définition des limites de temps

Diagram 1 · Use the button to switch views
Limites de temps pour la requête, la réflexion, la première réponse et l'exécution.

Le TTFT correspond généralement au temps d'obtention du premier jeton, mais un fragment HTTP ne constitue pas nécessairement un jeton. Ce script indique le TTFC, soit le temps d'obtention du premier fragment non vide response. Il enregistre séparément le contenu de la première réflexion lors de son retour. Cette métrique côté client inclut la mise en file d'attente, le chargement, le traitement des invites et le transport.

Le taux de génération utilise quant à lui le nombre de jetons générés par le serveur et la durée de génération. Les durées Ollama sont exprimées en nanosecondes ; les définitions de l'API Générer ont été vérifiées le 7 septembre 2026.

\text{generation rate [token/s]}=\frac{\text{eval\_count}}{\text{eval\_duration [ns]}}\times10^9

Ceci ne représente pas le débit total de la requête. L'utilisation de différents tokeniseurs implique également que le nombre de tokens pris isolément ne permet pas une comparaison équitable du volume ou de la qualité des réponses en japonais.

Ajuster les conditions

Enregistrer le condensé du modèle, la quantification, la version d'Ollama, le CPU/GPU, la RAM/VRAM, les limites de puissance, la concurrence et l'invite. Conserver les comptes de retour, car un texte identique peut être tokenisé différemment. Séparer la première requête avec un modèle non chargé des requêtes suivantes utilisant un modèle résident.

Les invites répétées peuvent utiliser le cache. Traiter séparément les tests avec un modèle résident et la même invite, ainsi que ceux avec un modèle résident et une nouvelle entrée. Enregistrer l'ordre d'exécution, car les conditions thermiques et les tâches en arrière-plan peuvent biaiser les comparaisons.

Lire le flux

Placer llm_benchmark.py à côté de prompt.txt contenant votre texte de comparaison. Ce script utilise uniquement la bibliothèque standard de Python. Remplacez VOTRE_MODÈLE par un modèle installé :

python3 llm_benchmark.py --model YOUR_MODEL --prompt-file prompt.txt --runs 5 > runs.jsonl

Le point de terminaison par défaut est 127.0.0.1:11434/api/generate. Les requêtes utilisent temperature=0, seed=42, num_predict=128, num_ctx=4096 et keep_alive=5m. Ces paramètres sont expérimentaux et ne garantissent ni le déterminisme ni l’adéquation à tous les modèles. Vérifiez le nombre de sorties et done_reason pour détecter une terminaison prématurée ou un comportement anormal.

Validation des sorties et des échecs

Chaque ligne JSON inclut ttfc_s, first_thinking_s, client_total_s, generation_tokens_s et le nombre/la durée des requêtes serveur. L’absence de fragment de réponse entraîne un TTFC nul ; une durée de génération nulle entraîne un débit nul. Les flux interrompus et les erreurs d’API ont pour statut « error », jamais les succès de zéro seconde.

L’analyse syntaxique, la gestion du temps et des erreurs ont été testées avec des réponses de flux synthétiques, et non avec une génération Ollama réelle. Commencez par cinq essais pour valider la procédure, puis augmentez le nombre de répétitions en appliquant des règles d'échauffement explicites. Indiquez le nombre de succès, la médiane et l'étendue ; ne présentez pas un p95 calculé sur un petit échantillon comme étant précis.

Mesure de la mémoire séparément

Le script ne mesure pas la mémoire. L'API running-model expose des informations de résidence, notamment size_vram, mais pas l'utilisation globale du système ni les pics transitoires. Échantillonnez les métriques OS/GPU de manière cohérente pendant les phases d'inactivité et de génération, en précisant l'intervalle d'observation.

La RAM de processus, le cache de pages et les allocations GPU sont des quantités différentes ; leur addition peut entraîner un double comptage. Vérifiez les limites, en particulier sur les systèmes à mémoire unifiée. Un changement d'affectation, tel qu'un traitement partiel par le CPU, ne doit pas être interprété uniquement comme une différence de capacité du modèle.

Création d'un tableau comparatif pertinent

Incluez le modèle/la quantification, les jetons d'entrée/sortie, les conditions de résidence/cache, les succès, le TTFC médian, le taux de génération médian, le temps total et les métriques de mémoire/l'intervalle d'échantillonnage. Évaluez séparément l'exactitude des réponses. Pour la consommation énergétique, convertissez la même charge de travail en Wh à l'aide de mesure de la consommation du serveur.

What to read next

Compare generation speed with energy per completed workload.Mesurer la consommation énergétique d'un serveur domestique : en veille, en inférence et en stockageReview the backgroundIntroduction à l'apprentissage automatique : Modèles génératifsExplore another aspect of this fieldIntroduction à la détection d'objets et à la segmentation sémantique — Interpréter « Qu'est-ce qui est où » à partir d'une image