Ce benchmark de LLM dans le navigateur évalue autant votre GPU que le modèle

Un benchmark qui vous prévient que ses modèles vont échouer

MicroLLM Lab, une expérience publiée sur Hacker News, charge de petits modèles de langage quantifiés directement dans un onglet de navigateur et leur fait passer une suite de tests. La ligne la plus honnête de toute l'interface figure dans sa propre explication : les vérifications sont « des contrôles objectifs (regex / jetons exacts), pas une mesure de la qualité d'écriture », et « un modèle de 135M a le droit d'échouer : c'est cela, la mesure ».

Cette posture est plus rare qu'il n'y paraît. La plupart des démonstrations de modèles sont conçues pour les faire paraître capables. Celle-ci est conçue pour savoir si un très petit modèle peut atteindre une cible exacte, et pour chronométrer la vitesse à laquelle il la manque.

Ce qui se passe réellement dans l'onglet

La page se décrit comme initialisant un moteur WebGPU et un catalogue de modèles. WebGPU est l'interface de navigateur qui permet à une page web d'utiliser votre matériel graphique pour du calcul généraliste, ce qui rend l'inférence locale viable sans application native. Les modèles sont décrits comme Q4, c'est-à-dire quantifiés sur quatre bits : les poids du modèle ont été compressés depuis des nombres de plus haute précision jusqu'à quatre bits chacun. Cela réduit suffisamment la taille d'un modèle pour qu'on puisse le télécharger et le conserver en mémoire sur un matériel ordinaire, au prix d'une certaine perte de qualité en sortie.

Une fois chargés, les poids sont mis en cache dans IndexedDB, la base de données locale du navigateur, de sorte qu'une seconde visite ne retélécharge pas tout. Des commandes permettent de charger tous les modèles, de tous les décharger et de choisir un modèle actif, ainsi qu'un plafond de jetons par génération.

Du côté de la mesure, la vitesse est scindée en deux chiffres que l'on confond couramment. La vitesse de pointe est celle du test le plus rapide. La vitesse soutenue provient d'un décodage continu de 256 jetons, une exécution plus longue où le bridage thermique, la pression sur la mémoire et une machine occupée commencent à se faire sentir. Il existe aussi une moyenne de vitesse soutenue sur les modèles testés et un temps d'exécution cumulé de la suite, présentés sous forme de graphiques du temps d'exécution par test et de la précision par test. La page précise clairement que tout cela provient d'exécutions dans votre navigateur et que « les chiffres restent sur cette machine ».

Là où l'annonce et le produit réel divergent

Ce qui est démontré : cela fonctionne, en local, et affiche de vraies mesures de temps issues de votre propre appareil. Ce n'est pas une maquette de rendu, et l'argument de confidentialité découle structurellement de la conception : si rien ne quitte l'onglet, rien ne quitte l'onglet.

Ce qui relève de la démonstration, au sens de suggestif plutôt que concluant :

• Chaque chiffre de vitesse est une mesure conjointe du modèle et de votre matériel, de votre navigateur, de vos pilotes et de tout ce qui tourne en parallèle. Deux personnes qui comparent leurs scores comparent autant leurs ordinateurs portables que leurs modèles.
• La page propose un « Verified Benchmark Certificate » (certificat de benchmark vérifié) avec votre pseudonyme, les informations sur votre appareil, les jetons par seconde en pointe et en régime soutenu, téléchargeable en PNG et partageable sur X et LinkedIn. Rien dans la source n'explique ce qui est vérifié. Une image autogénérée d'une exécution locale autodéclarée est une capture d'écran avec une meilleure typographie.
• La précision est un taux de réussite à des contrôles par regex et jetons exacts. Cela mesure la conformité de format et une justesse étroite, pas le raisonnement ni l'utilité. L'outil le dit lui-même ; le certificat, lui, ne porte pas cette réserve.
• Il existe un éditeur de benchmark personnalisé, et la source indique que son contenu est « passé à eval() dans cette origine ». En clair, le code que vous collez s'exécute comme du JavaScript de confiance à l'intérieur de la page. Cela convient pour vos propres extraits. Cela ne convient pas pour un benchmark envoyé par un inconnu.

Les questions à vous poser

• Si deux appareils produisent des jetons par seconde différents pour le même modèle, que prouve exactement un « score » partagé à la personne qui le lit ?
• Qu'est-ce qui rend le certificat « vérifié » ? Existe-t-il un contrôle autre que le navigateur qui rapporte ses propres chiffres ?
• Un taux de réussite par regex prédit-il quoi que ce soit du comportement d'un minuscule modèle sur votre charge de travail réelle, où la bonne réponse n'est pas une chaîne fixe ?
• Avant de coller le benchmark de quelqu'un d'autre dans un éditeur qui applique eval() dans l'origine de la page, que contient d'autre cette origine ?
• Si la quantification Q4 est la raison pour laquelle ces modèles tiennent dans un onglet, combien de précision cette compression a-t-elle coûté, et par rapport à quelle référence non quantifiée ?

Ce qu'il faut surveiller ensuite

Le signal à guetter est de savoir si le projet publie la liste des modèles et les définitions des tests sous une forme que chacun peut réexécuter et comparer, accompagnée d'une normalisation selon le matériel. Sans cela, les certificats circuleront comme des trophées de matériel. Avec cela, l'outil devient un moyen simple et honnête de découvrir quel minuscule modèle franchit votre seuil sur votre propre machine, ce qui est le seul benchmark qui ait jamais compté pour l'inférence locale.