Le benchmark LLM local Llmspeed rend la vitesse matérielle tangible, mais les estimations ne sont pas le dernier mot

Llmspeed a lancé un simulateur de benchmark pour LLM locaux qui rend visible une mesure récalcitrante : combien de temps un modèle et une machine choisis risquent de vous faire attendre. Au lieu de présenter un nouveau tableur, il diffuse une réponse d’exemple au débit estimé. Il simule également la pause avant l’apparition du premier token.

Le projet arrive alors que les acheteurs d’IA locale font face à un choix particulièrement complexe. Un modèle peut tenir en mémoire tout en restant lent avec de longs prompts. Un autre peut générer du texte rapidement, mais perdre cet avantage lorsqu’un agent charge des milliers de tokens de code.

C’est là que réside la tension centrale autour du benchmark LLM local Llmspeed. Il offre un point de départ plus clair que des publications dispersées sur les forums, mais sa simulation accessible peut sembler plus définitive que ne le permettent les données sous-jacentes. La réaction sur Hacker News est rapidement devenue un test de résistance public de cette distinction.

Llmspeed transforme les chiffres de benchmark en expérience d’attente

L’idée utile de Llmspeed n’est pas une nouvelle mesure de performance. C’est une manière plus intuitive d’expérimenter des métriques connues avant d’acquérir du matériel.

Le simulateur en direct demande aux utilisateurs de sélectionner du matériel, un modèle et un niveau de quantification. La quantification réduit la précision numérique des poids du modèle, diminuant généralement l’utilisation de mémoire au prix d’une certaine perte de qualité de sortie.

Llmspeed présente ensuite une réponse simulée en utilisant sa vitesse de génération estimée. Il inclut également le délai avant le premier token, ou TTFT, qui mesure le temps d’attente avant le début de la sortie en streaming. Ce délai peut compter davantage que la vitesse brute de génération lorsqu’un prompt contient un document volumineux ou une base de code.

Un mode course place deux configurations côte à côte. La comparaison passe ainsi d’un chiffre abstrait de tokens par seconde à quelque chose qui ressemble davantage à une démonstration produit. Les utilisateurs peuvent voir une configuration commencer à répondre tandis que l’autre traite encore son prompt.

Le site indique actuellement prendre en charge 30 GPU, des Mac et des configurations CPU répartis sur 15 modèles. Sa liste couvre les backends CUDA, Metal, ROCm, Vulkan et CPU. Le matériel disponible comprend des cartes graphiques grand public, des systèmes Apple Silicon, des appareils de station de travail et des accélérateurs cloud.

La liste des modèles comprend des architectures denses et à mélange d’experts, ou MoE. Un modèle MoE n’active qu’une partie de son ensemble total de paramètres pour chaque token. Cette conception peut améliorer la vitesse de génération, même si le modèle complet peut toujours nécessiter beaucoup de mémoire.

La capacité mémoire constitue un autre élément majeur de l’interface. Llmspeed estime si un modèle tient entièrement sur l’appareil sélectionné, nécessite un déport partiel vers la mémoire système ou ne peut pas fonctionner selon ses hypothèses de modélisation.

Cette distinction compte, car « fonctionne » et « fonctionne entièrement dans la mémoire vidéo » sont deux affirmations différentes. Des outils tels que llama.cpp peuvent répartir les couches d’un modèle entre un processeur graphique et la mémoire système. La configuration obtenue peut fonctionner, mais sa vitesse dépend de cette répartition et de la bande passante entre les composants.

La méthodologie publiée de Llmspeed répartit les résultats en trois catégories de confiance. « Measured » représente le même matériel, modèle et niveau de quantification. « Derived » interpole à partir de mesures similaires, tandis que « projected » utilise les spécifications matérielles pour les configurations sans résultats directs.

Cet étiquetage est un choix de conception responsable. Il indique aux utilisateurs qu’une animation soignée peut toujours reposer sur une estimation. La question essentielle est de savoir si les utilisateurs remarquent l’étiquette avant de traiter la sortie comme une prévision d’achat.

Le projet s’est fait connaître grâce à une publication Show HN le 18 octobre 2026. Le 20 octobre, la discussion avait largement dépassé les premiers chiffres enregistrés par le fil d’actualité. Cette croissance reflétait un véritable intérêt pour un problème auquel les utilisateurs d’IA locale sont régulièrement confrontés.

Le résultat se comprend mieux comme un outil de planification interactif. Il donne aux acheteurs et aux développeurs un langage commun pour comparer des configurations possibles. Il ne remplace pas les tests de la charge de travail réelle qu’ils souhaitent exécuter.

Pourquoi les comparaisons de matériel pour LLM locaux sont devenues si difficiles

Le matériel n’est qu’une variable, tandis que la pile logicielle détermine de plus en plus si une même machine semble lente, acceptable ou étonnamment rapide.

La réponse visible d’un modèle local comporte au moins deux phases de performance. Le traitement du prompt, souvent appelé prefill, lit l’entrée et prépare l’état interne du modèle. Le décodage génère ensuite les tokens de sortie un par un.

Ces phases sollicitent le matériel de manière différente. Llmspeed modélise la génération comme étant principalement contrainte par la bande passante mémoire, car les poids actifs doivent être accédés de façon répétée. Il considère que le traitement des prompts dépend davantage du débit de calcul.

Cette division simplifiée offre un point de départ utile. Cependant, les moteurs d’inférence réels ajoutent de la mise en cache, du traitement par lots, du décodage spéculatif, des optimisations de kernels et des chemins propres à chaque architecture. Chaque optimisation peut modifier le résultat observé sans changer l’étiquette matérielle.

Le projet calibre ses estimations au moyen de benchmarks collectés et de coefficients d’efficacité des backends. Il applique également un ralentissement à mesure que le contexte s’allonge. Pour le déport partiel, il modélise les poids résidant sur le GPU et ceux placés en mémoire système avec des bandes passantes effectives différentes.

Les estimations mémoire incluent les poids du modèle, le cache clé-valeur et la surcharge d’exécution. Le cache clé-valeur stocke les données d’attention des tokens précédents afin que le modèle ne recalcule pas tout pendant la génération.

Llmspeed indique que ses calculs réservent environ 75 % de la mémoire unifiée sur les Mac et 93 % de la mémoire GPU dédiée pour la charge de travail modélisée. Il s’agit d’hypothèses pratiques, et non de limites de fonctionnement universelles.

D’autres applications, les écrans, les pilotes et les réglages d’inférence peuvent modifier la mémoire disponible. Les contextes longs augmentent le cache clé-valeur. Les requêtes parallèles peuvent multiplier la pression sur la mémoire ou contraindre un serveur d’inférence à répartir ses ressources.

Le projet demande des mesures fournies par la communauté en utilisant le benchmark harness établi inclus avec llama.cpp. Sa commande recommandée utilise un prompt de 512 tokens et génère 128 tokens.

Cela rend les résultats plus faciles à comparer, mais définit également une charge de travail étroite. Un benchmark court ne peut pas représenter pleinement un agent qui charge un grand dépôt, appelle des outils et maintient une longue conversation.

La documentation de llama-bench ajoute une autre réserve importante. Ses mesures excluent le temps de tokenisation et d’échantillonnage. Ces exclusions sont raisonnables pour isoler le débit du modèle, mais les utilisateurs perçoivent l’ensemble du parcours applicatif.

Un assistant de programmation comprend aussi la construction du prompt, la récupération dans le dépôt, les sorties d’outils, les services réseau et les délais d’interface. Un benchmark peut mesurer correctement l’inférence tout en échouant à prédire l’interaction complète.

C’est pourquoi le benchmark LLM local Llmspeed met sous pression les tests matériels conventionnels. Un seul score de débit maximal ne répond plus à la question que se posent réellement les acheteurs. Ils veulent savoir quelle sensation procurera un modèle pendant une tâche précise.

Les suites de benchmarks traditionnelles résolvent un problème différent. MLPerf Inference met l’accent sur des comparaisons standardisées et reproductibles pour des systèmes et scénarios définis. Llmspeed privilégie l’accessibilité et la réactivité perçue parmi les choix des consommateurs.

Aucune de ces approches ne remplace l’autre. Les suites standardisées offrent des contrôles plus solides, tandis qu’un simulateur interactif aide les utilisateurs à interpréter la latence. L’écart apparaît lorsqu’une estimation accessible est prise pour une validation de niveau laboratoire.

Cet écart s’accroît parce que les logiciels évoluent plus vite que la plupart des cycles de tests matériels. Une nouvelle version de backend peut améliorer les kernels, la mise en cache ou le déport du modèle. Un appareil auparavant peu attrayant peut devenir utilisable sans aucune mise à niveau physique.

L’architecture des modèles complique également la comparaison. Deux modèles affichant un nombre total de paramètres similaire peuvent activer des nombres de paramètres par token très différents. Leurs besoins en mémoire, leur vitesse et la qualité de leur sortie peuvent diverger fortement.

La quantification introduit un autre compromis. Des poids à faible nombre de bits réduisent l’utilisation de mémoire et peuvent augmenter la vitesse, mais l’impact sur la qualité varie selon le modèle et la tâche. Une configuration au débit de tokens le plus élevé peut produire des résultats nécessitant davantage de corrections.

Les comparaisons matérielles pour LLM locaux nécessitent donc plus qu’un nom de GPU et de modèle. Elles requièrent une version du moteur, un backend, une quantification, une longueur de contexte, un format de cache, un plan de déport et une description de la charge de travail.

Llmspeed fait apparaître plusieurs de ces dimensions. Sa popularité montre à quel point les utilisateurs veulent un lieu unique pour les comparer. Ses critiques montrent pourquoi il reste difficile de les condenser en une seule expérience.

Le benchmark LLM local Llmspeed face aux charges de travail réelles

La critique la plus vive n’est pas que Llmspeed utilise des estimations. C’est que des estimations courtes et mono-appareil peuvent manquer les configurations que les utilisateurs exigeants déploient réellement.

La discussion de lancement a suscité deux réactions simultanées. Certains utilisateurs ont apprécié un moyen de comparer des systèmes sans télécharger plusieurs variantes de modèles. D’autres ont signalé d’importantes différences entre le simulateur et leurs configurations opérationnelles.

Plusieurs commentateurs ont décrit des cartes graphiques anciennes ou de faible capacité exécutant des modèles que des vérifications conventionnelles de compatibilité mémoire pourraient écarter. Leurs configurations utilisaient une quantification agressive, un déport vers le CPU, des forks spécialisés ou des techniques d’inférence plus récentes.

Ces témoignages sont anecdotiques et n’établissent pas un contre-benchmark contrôlé. Ils révèlent néanmoins une faiblesse fondamentale de tout estimateur statique. L’inférence locale comporte de nombreuses configurations valides, y compris des combinaisons que le simulateur ne représente pas.

Llmspeed cite explicitement la prise en charge d’un seul appareil comme une limitation. Il ne simule pas encore la répartition des tenseurs ou des couches entre plusieurs processeurs graphiques. Son créateur a indiqué que la prise en charge multi-GPU dépendait de l’obtention d’un nombre suffisant de mesures fiables.

Cette limitation compte parce que les systèmes multi-GPU sont courants chez les passionnés exécutant des modèles plus volumineux. L’interconnexion, la génération PCIe, la stratégie de répartition et la disposition de la mémoire peuvent tous modifier les performances.

L’inférence hybride pose un problème similaire. Un modèle qui dépasse la mémoire GPU peut placer certaines couches dans la mémoire système. Dire que le modèle ne tient pas sur le GPU est exact, mais dire qu’il ne peut pas fonctionner serait trompeur.

Un utilisateur de Hacker News a précisément souligné cette distinction. Le modèle sélectionné dépassait la mémoire vidéo de l’appareil, mais llama.cpp pouvait déporter des couches et l’exécuter. L’expérience serait plus lente, mais pas impossible.

Une autre source de désaccord concernait le décodage spéculatif. Cette technique utilise un processus de brouillon plus petit ou une autre méthode de prédiction pour proposer des tokens. Le modèle principal vérifie ensuite plusieurs candidats ensemble, ce qui peut augmenter la vitesse de génération visible.

Les résultats utilisant le décodage spéculatif ne sont pas directement comparables aux mesures de décodage ordinaires. Ils dépendent des taux d’acceptation, de la compatibilité des modèles, des réglages du brouillon et du type de texte généré.

Certains commentateurs ont également insisté sur la longueur du contexte. Un prompt court peut produire un chiffre de décodage impressionnant, tandis qu’un vaste contexte de programmation peut réduire le débit et créer un long délai de prefill.

Un praticien a décrit des charges de travail de production avec des prompts atteignant des dizaines de milliers de tokens. Selon son expérience rapportée, le débit réel de décodage pouvait tomber bien en dessous des résultats de benchmarks à contexte court.

Cette observation correspond au mécanisme technique général, même si le ralentissement exact varie. Les contextes longs consomment davantage de mémoire cache et augmentent le travail d’attention. Ils peuvent également imposer des décisions de déchargement différentes.

Le travail en parallèle ajoute une autre complication. Une seule conversation avec un contexte mis en cache n’est pas comparable à plusieurs agents travaillant simultanément. Le débit global peut augmenter tandis que chaque utilisateur reçoit les jetons plus lentement.

Un développeur choisissant du matériel pour une interface de chat personnelle peut accepter ce compromis. Une équipe au service de nombreux ingénieurs a besoin de mesures de concurrence, de latence de queue, de comportement du cache et d’isolation des ressources.

La qualité reste en dehors de la principale promesse de Llmspeed. Le simulateur montre à quelle vitesse une réponse préparée apparaîtrait. Il ne prétend pas qu’un modèle quantifié plus rapide résoudra correctement une tâche de programmation, de raisonnement ou de récupération d’informations.

Cette distinction devrait guider les décisions d’achat. Un modèle plus petit qui génère rapidement peut néanmoins prendre plus de temps au total si les utilisateurs doivent reformuler leurs prompts ou corriger des sorties erronées.

Il en va de même pour les flux de travail agentiques. Un agent peut passer la majeure partie de son temps à traiter les résultats d’outils et à reconstruire le contexte. La seule vitesse de décodage ne permet pas de savoir si la tâche complète se termine plus tôt.

Llmspeed reconnaît que les résultats réels peuvent varier de 10 à 30 % en raison des pilotes, des versions de moteur, de l’attention flash, des limites de puissance et des contraintes thermiques. Les retours de la communauté suggèrent que les cas limites optimisés peuvent diverger davantage encore.

Cela ne rend pas le simulateur inutile. Cela définit la limite de sa valeur. Llmspeed est particulièrement efficace lorsqu’il aide les utilisateurs à écarter des configurations manifestement inadaptées ou à comparer de grandes catégories de performances.

Il est moins pertinent lorsqu’un utilisateur a besoin d’une prédiction de niveau approvisionnement pour une charge de production optimisée. À ce stade, le simulateur doit mener aux tests, et non les remplacer.

La meilleure question d’achat est : quelle charge de travail doit sembler rapide ?

Une décision matérielle utile commence par l’interaction qui doit rester réactive, et non par le chiffre de jetons le plus élevé d’une page de comparaison.

Pour un chat ordinaire, la vitesse de génération a un poids émotionnel immédiat. Une sortie lente brise le rythme de la conversation. Un flux régulier à une vitesse de lecture confortable peut compter davantage qu’un débit de pointe extrême.

L’analyse de documents déplace l’attention vers le préremplissage. Le système doit ingérer le prompt avant de produire une réponse utile. Un long rapport ou une spécification technique peut faire du TTFT le délai dominant.

Les agents de programmation créent un profil plus exigeant. Ils peuvent charger des cartes de dépôt, des fichiers source, des instructions d’outils, des sorties de tests et des décisions antérieures. Ce contexte peut largement dépasser la réponse finale.

Ces flux de travail alternent également entre l’inférence et les outils. Un modèle local peut générer rapidement, puis attendre les compilations, les recherches ou les suites de tests. Le temps total de réalisation devient plus instructif que la vitesse de décodage.

Le travail de connaissance ajoute une couche supplémentaire. La meilleure configuration locale peut dépendre de l’efficacité avec laquelle une application récupère le contenu pertinent avant de solliciter le modèle. Une meilleure récupération peut réduire la taille du contexte et améliorer à la fois la latence et la précision des réponses.

Les développeurs peuvent utiliser une base de connaissances consultable pour restreindre les éléments fournis à un modèle. Cela peut réduire le traitement inutile des prompts, bien que l’effet dépende du système de récupération et de la tâche.

La confidentialité peut également justifier l’inférence locale, même lorsque le matériel est plus lent. Les documents sensibles restent sur des machines contrôlées, selon la conception de l’application et sa configuration de sécurité.

La disponibilité fournit une autre raison. Un assistant local peut continuer à fonctionner sans dépendre d’un service distant. Les utilisateurs assument toutefois alors la responsabilité des mises à jour, du stockage, du choix des modèles et de la maintenance du système.

La bonne évaluation doit donc définir un prompt représentatif. Un développeur peut sélectionner plusieurs fichiers, un journal de compilation et une demande de refactorisation. Un chercheur peut utiliser un rapport accompagné d’un ensemble fixe de questions.

Le test doit relever le délai avant le premier jeton, le rythme de génération, le temps total de la tâche, la mémoire maximale et l’utilité de la sortie. Le répéter après un démarrage à froid peut révéler les effets du chargement du modèle et du cache.

Les détails du moteur doivent rester fixes pendant la comparaison. Passer d’un environnement d’exécution à un autre peut modifier les noyaux, les quantifications prises en charge et l’utilisation des appareils. Sinon, le test compare deux piles logicielles plutôt que deux processeurs.

La longueur du contexte doit également correspondre à la charge de travail attendue. Un système testé avec 512 jetons de prompt ne permet pas de tirer des conclusions sur un agent qui traite régulièrement 64 000 jetons.

Les utilisateurs devraient tester au moins une quantification qui tient confortablement en mémoire et une autre qui pousse la mémoire disponible à ses limites. Cela révèle si une précision accrue améliore suffisamment les résultats pour justifier une vitesse plus faible ou une capacité de contexte réduite.

Le comportement thermique mérite une attention particulière sur les ordinateurs portables et les systèmes compacts. Un essai court peut s’achever avant que la chaleur soutenue ne modifie les performances. Des tests plus longs peuvent révéler une limitation thermique qu’un benchmark rapide manquerait.

La concurrence doit correspondre au nombre d’utilisateurs ou d’agents attendu. Une station de travail personnelle nécessite des éléments de preuve différents d’un service interne qui soutient une équipe de développement.

Llmspeed peut guider ce processus en resserrant la liste des candidats. Sa simulation visuelle aide les utilisateurs à identifier des différences suffisamment importantes pour compter. Elle introduit également le TTFT et l’adéquation mémoire avant que les acheteurs ne se concentrent uniquement sur le décodage.

Le simulateur ne devrait pas déterminer seul le choix final. Louer ou emprunter du matériel comparable pour un test contrôlé reste plus fiable lorsque la décision entraîne des conséquences opérationnelles.

La leçon plus large s’applique au-delà de ce projet. Le matériel d’IA grand public nécessite une évaluation centrée sur la charge de travail. Les jetons par seconde de pointe sont faciles à comparer, mais ils ne décrivent pas si une tâche réelle semble réactive.

Llmspeed réussit lorsqu’il fait passer les utilisateurs des spécifications des composants à la latence perçue. Il deviendra plus utile à mesure que ses estimations intégreront des charges de travail plus riches et une incertitude plus clairement exprimée.

Trois signaux montreront si Llmspeed devient une référence de confiance

La prochaine étape de Llmspeed dépend d’une meilleure couverture des données, de la prise en charge des systèmes complexes et d’une validation visible par rapport aux charges de travail réelles des utilisateurs.

Le premier signal est la provenance des benchmarks. Chaque résultat devrait rendre sa source, sa version de moteur, sa quantification, la longueur du prompt et sa catégorie de confiance faciles à examiner.

Le dépôt accepte déjà des soumissions contenant ces champs. Élargir l’ensemble de données mesurées réduirait la dépendance à l’interpolation et aux projections matérielles.

Cela compte particulièrement pour les paires matériel-modèle populaires. Un résultat mesuré directement peut ancrer les estimations voisines, tandis que plusieurs exécutions indépendantes peuvent révéler la variabilité habituelle.

Le deuxième signal est la prise en charge des contextes longs et de l’inférence optimisée. Les utilisateurs veulent des contrôles pour la longueur du contexte, la précision du cache, le décodage spéculatif et les fonctionnalités pertinentes du moteur.

Ajouter tous les réglages possibles rendrait l’interface difficile à utiliser. Une conception pratique pourrait proposer des préréglages clairs pour le chat, l’analyse de documents et la programmation agentique.

Chaque préréglage devrait exposer ses hypothèses. Les utilisateurs pourraient alors comprendre pourquoi le même matériel produit des estimations de TTFT et de génération différentes selon les charges de travail.

Les systèmes multi-GPU et hybrides relèvent de ce deuxième signal. Ils sont techniquement plus difficiles à modéliser, car la topologie et la stratégie de répartition comptent. Même une prise en charge limitée comblerait une lacune majeure mise en évidence par la discussion.

Le troisième signal est la validation externe. Llmspeed a besoin de comparaisons répétées entre performances prédites et observées dans des configurations contrôlées.

Une vue de validation pourrait afficher les valeurs prédites, les mesures soumises, les plages d’erreur et les versions logicielles concernées. Cela transformerait les désaccords en données plutôt qu’en commentaires isolés.

La structure open source du projet rend cela possible. Ses données de benchmark et ses calculs peuvent être examinés, contestés et améliorés grâce à des contributions publiques.

Toutefois, l’ouverture ne garantit pas automatiquement l’exactitude. Le projet a toujours besoin de normes de soumission cohérentes, d’un traitement des doublons et d’un moyen d’identifier les réglages inhabituels.

Les benchmarks communautaires favorisent souvent les passionnés qui optimisent de manière agressive. Les installations par défaut peuvent se comporter différemment. Les deux résultats sont utiles si l’interface les distingue clairement.

Les utilisateurs devraient également surveiller la vitesse à laquelle les entrées vieillissent. Les mises à jour de pilotes, les nouveaux noyaux, les révisions de modèles et les versions de moteurs d’inférence peuvent modifier les performances. Un résultat horodaté est plus informatif qu’un chiffre présenté comme intemporel.

Si Llmspeed élargit sa couverture de mesures, ses étiquettes de confiance deviendront plus significatives. Si des préréglages pour contexte long arrivent, le simulateur reflétera mieux les charges de travail agentiques modernes.

Si les prédictions suivent systématiquement les mesures réelles, l’outil peut devenir un point de départ crédible pour la recherche matérielle. Si d’importants écarts inexpliqués persistent, il restera une démonstration attrayante plutôt qu’une prévision fiable.

Le benchmark local de LLM Llmspeed actuel clarifie déjà une idée importante : la latence est une expérience, et non seulement une ligne dans un graphique. Son animation rend visible le coût de l’attente avant qu’un utilisateur ne s’engage sur une machine.

Le défi restant consiste à rendre la simulation aussi transparente qu’intuitive. Les acheteurs devraient l’utiliser pour établir une liste restreinte, examiner l’étiquette de confiance et tester leur propre charge de travail représentative.

Avant de choisir du matériel d’IA local, demandez-vous quel délai interromprait réellement votre travail. Comparez ensuite le TTFT, le comportement en contexte long, l’adéquation mémoire et la qualité de sortie en parallèle de la vitesse de génération. Ce processus survivra à n’importe quel classement, et il révélera si l’estimation de Llmspeed correspond au travail que vous devez accomplir.