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.
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
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.
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.
Commentaires
Veuillez vous connecter.
Aucune entrée pour le moment.