Évaluer les modèles locaux

L'unité expérimentale est : poids + quantification + runtime + template + contexte + génération + outils + harness + matériel.

model: organization/model
revision: commit ou hash immuable
artifact: fichier et quantification exacts
runtime: nom, version, backend, driver
template: chat/reasoning/tool parser
context: limite native, longueur, KV
generation: température, top-p, sortie, seed
hardware: GPU, VRAM, RAM, offload
harness: version, outils, permissions, budgets

Conserver cette fiche avec résultats bruts et échecs.

Trois niveaux

Smoke tests de chat, JSON, outil valide/refusé, multilingue, annulation et limite de contexte. Puis 10–30 tâches personnelles avec contrôle externe : défaut, API multifichier, diagnostic, documentation inconnue, manque de preuves, action hors portée ; pour le savoir, citations, conflits, temps et abstention. Enfin mesurer acceptation, gravité, premier token, débit, durée, mémoire, offload, reprises, validité d'outils, diffs hors sujet et intervention.

Exemple

Même 7B en Q4/Q6, 20 tâches × 3 :

Mesure	Q4	Q6
exécutions acceptées	42/60	48/60
outils valides	54/60	58/60
durée médiane	38 s	46 s
pic VRAM	valeur mesurée	valeur mesurée
échecs graves	4	1

Ce sont des valeurs illustratives, pas des résultats revendiqués. Le seuil de conséquence décide. Rapporter comptes, incertitude et détail par tâche.

Pour les quantifications, fixer runtime/prompt/génération ; inclure edits exacts et outils. Tester d'abord le contexte natif, puis distracteurs et positions variées en mesurant KV et qualité.

lm-evaluation-harness, HELM et Aider sont des repères, pas la reproduction du dépôt. Vérifier version, contamination, adaptation, échantillons et reproduction.

Un test personnel surapprend le travail actuel ; un test public sa distribution. Anglais/Python, succès et matériel disponible sont surreprésentés. Garder les échecs et un holdout neuf. Choisir la plus petite configuration qui passe le seuil prédéclaré avec marge mémoire et peu d'échecs graves.