Dernière mise à jour: 17 octobre 2026

Llmspeed : ressentir la vitesse d’un LLM local avant d’acheter

Llmspeed est un outil web gratuit et open source, disponible sur llmspeed.dev. Vous choisissez un GPU, un Mac ou un CPU et un modèle, et il affiche une réponse d’exemple à la vitesse prévue pour ce matériel, y compris l’attente avant le premier token. Il a été présenté sur Hacker News en Show HN le 17 octobre 2026.

Qu’est-ce que Llmspeed ?

La plupart des benchmarks de LLM locaux donnent un nombre de tokens par seconde. Llmspeed le rend visible : le texte apparaît au rythme prévu, après une attente réaliste selon la longueur du prompt. Le projet se présente comme un moyen de « ressentir la vitesse d’un LLM local avant d’acheter le matériel ».

C’est un site statique construit avec Vite, Preact et TypeScript, sous licence MIT. Toutes les prédictions sont dans un seul fichier de données du dépôt GitHub, chacun peut donc vérifier d’où vient chaque chiffre.

• Simulation en temps réel. Le texte défile au nombre de tokens par seconde prévu, après un temps jusqu’au premier token qui dépend du prompt.
• Mode course. Fait tourner deux configurations côte à côte, par exemple une RTX 5090 contre un Mac Studio.
• Tenue en mémoire. Indique si un modèle tient dans chaque quantification, s’il faut en décharger une partie en RAM système ou s’il ne peut pas tourner.
• Couverture. 30 GPU, Mac et CPU et 15 modèles populaires, avec les backends CUDA, Metal, ROCm, Vulkan et CPU.
• Liens partageables. Chaque configuration ou course a son propre lien.

Source: GitHub : albinstman/llmspeed (README)

Source: llmspeed.dev (site officiel)

Comment utiliser Llmspeed

1. Ouvrez llmspeed.dev dans un navigateur. Rien à installer, pas de compte ; la page a besoin de JavaScript.
2. Choisissez le matériel que vous avez ou que vous envisagez d’acheter : RTX 4090, Mac Studio, PC sans GPU…
3. Choisissez un modèle et une quantification (par exemple Q4_K_M, Q8_0 ou FP16). L’indicateur de mémoire dit s’il tient, s’il déborde en RAM ou s’il ne se charge pas.
4. Choisissez la longueur du prompt. Plus il est long, plus le premier token tarde ; le fichier de données propose 42, 290, 1 800 et 12 500 tokens.
5. Lancez la simulation et regardez la réponse défiler. Vérifiez l’étiquette à côté du résultat : Measured, Derived ou Projected.
6. Activez le mode course pour ajouter une seconde configuration, puis copiez le lien pour partager la comparaison.

Llmspeed ne simule que la vitesse. Il n’exécute aucun modèle dans votre navigateur et ne dit rien de la qualité des réponses.

Source: GitHub : albinstman/llmspeed (README)

Source: llmspeed.dev (site officiel)

Source: GitHub : llmspeed data/app-data.json

Llmspeed est-il fiable ? Measured, Derived et Projected

Chaque estimation porte une étiquette qui indique le degré de confiance :

Dans le fichier de données consulté le 17 octobre 2026, sur 1 446 combinaisons matériel, modèle et quantification, 76 étaient Measured, 385 Derived et 985 marquées comme impossibles à exécuter. La plupart des résultats exécutables sont donc interpolés, pas mesurés directement.

Source: GitHub : albinstman/llmspeed (README)

Source: GitHub : llmspeed data/app-data.json

Comment Llmspeed estime les tokens par seconde

Les chiffres mesurés viennent de benchmarks communautaires collectés et vérifiés sur r/LocalLLaMA, localscore.ai, les discussions llama.cpp et d’autres sources. Sans benchmark, le README explique que l’outil repart des principes de base :

• La vitesse de génération dépend de la bande passante mémoire : chaque token relit une fois les poids actifs. Pour les modèles mixture-of-experts, seuls les paramètres actifs comptent.
• Le traitement du prompt (temps jusqu’au premier token) dépend de la puissance de calcul, en TFLOPS FP16.
• Les deux utilisent des coefficients d’efficacité par backend calibrés sur les mesures, plus un ralentissement à mesure que le contexte grandit.
• Le déchargement partiel suit un modèle hybride : la part sur le GPU va à la bande passante du GPU, la part en RAM à une bande passante effective calibrée sur des mesures réelles.
• La tenue en mémoire compte les poids, le cache KV et le surcoût d’exécution face à la mémoire utilisable : environ 75 % de la mémoire unifiée sur Mac et 93 % de la VRAM sur GPU dédié.

Notre calculateur de VRAM Qwen4 · Faire tourner Qwen4 en local

Source: GitHub : albinstman/llmspeed (README)

Source: r/LocalLLaMA

Source: localscore.ai

Source: GitHub : llama.cpp

Liste du matériel Llmspeed : 30 GPU, Mac et CPU

Voici les machines du fichier de données du projet au 17 octobre 2026, triées par bande passante mémoire, principal facteur de vitesse de génération dans son modèle. Mémoire et bande passante sont les valeurs utilisées par le fichier.

Source: GitHub : llmspeed data/app-data.json

Quels modèles Llmspeed couvre-t-il ?

Le fichier de données liste 15 modèles choisis selon leur popularité : Qwen 3.6/3.8 27B, Qwen 3.5/3.6 35B A3B, Qwen3 30B A3B, Qwen 3.5 9B, GLM-5.3 Flash, DeepSeek V4 Flash, DeepSeek R1 Distill 14B, GPT-OSS 20B, GPT-OSS 120B, Gemma 4 26B A4B, Gemma 4 31B, Llama 3.1 8B, Ornith 1.5 35B A3B, Ornith 1.5 9B, Muse Glimmer 30B.

Les modèles mixture-of-experts comme GPT-OSS 120B, DeepSeek V4 Flash et GLM-5.3 Flash ne lisent que leurs paramètres actifs à chaque token : ils peuvent donc générer plus vite que leur taille totale ne le laisse penser, à condition de tenir en mémoire. Les plus gros sont proposés en quantifications à très peu de bits pour tenir sur des Mac et stations de travail bien dotés en mémoire.

Source: GitHub : llmspeed data/app-data.json

Source: GitHub : albinstman/llmspeed (README)

Ajouter votre propre mesure

La contribution la plus utile est une vraie mesure. Lancez le benchmark de llama.cpp sur votre machine, ajoutez une ligne à benchmarks/submissions.csv (matériel, modèle, quantification, backend, version du moteur, gen_tps, prefill_tps, tokens du prompt, lien source, notes) et collez la sortie complète de llama-bench dans la pull request. Les résultats MLX, vLLM ou ExLlama sont aussi acceptés si vous nommez le moteur.

# 1. Measure your own machine with llama.cpp's benchmark tool
llama-bench -m your-model.gguf -p 512 -n 128
# tg128 = generation speed (gen_tps), pp512 = prompt speed (prefill_tps)
# 2. Add a row to benchmarks/submissions.csv and open a pull request

Source: GitHub : albinstman/llmspeed (README)

Source: GitHub : llmspeed benchmarks/submissions.csv

Source: GitHub : llama.cpp

Faire tourner Llmspeed en local

Le site est entièrement statique, vous pouvez donc héberger votre propre copie. Les commandes de développement du README :

# Run the site locally (Vite + Preact + TypeScript)
git clone https://github.com/albinstman/llmspeed
cd llmspeed
npm install
npm run dev

Source: GitHub : albinstman/llmspeed (README)

Les limites de Llmspeed

• Une seule machine : les configurations multi-GPU (découpage par tenseur ou par couche) ne sont pas encore simulées.
• Des estimations, pas des garanties : selon le README, pilotes, versions du moteur, flash attention, limites de puissance et températures peuvent faire varier les chiffres réels de 10 à 30 %.
• Les chiffres projetés pour du matériel non sorti seront remplacés par des mesures dès qu’elles existent.
• Sur Hacker News, certains ont dit que les prédictions ne correspondaient pas à leurs machines, ont demandé le multi-GPU, NVLink et plus de quantifications, et ont rappelé qu’en usage réel le traitement du prompt et la longueur du contexte comptent souvent plus que la vitesse de génération.
• Autre suggestion de la même discussion : louer un GPU dans le cloud quelques minutes est un moyen peu coûteux de tester vraiment une configuration avant d’acheter.

Source: GitHub : albinstman/llmspeed (README)

Source: daily.dev : résumé de la discussion Show HN (17 oct. 2026)

Guide indépendant, sans lien avec Llmspeed ni son auteur. Les informations viennent du README et du fichier de données de Llmspeed sur GitHub et d’un résumé de la discussion Hacker News, consultés le 17 octobre 2026. Nous n’avons pas fait nos propres mesures. Les noms de matériel et de modèles sont des marques de leurs propriétaires.