Méthode et sources des données
Mémoire
Mémoire nécessaire = poids du modèle + cache KV + surcoût runtime + marge de sécurité. Les poids utilisent la taille réelle du fichier GGUF quand elle a été importée ; sinon paramètres × bits effectifs par poids (ci-dessous), présentés comme une estimation avec une plage de ±6 %. Le cache KV est calculé depuis l'architecture (couches × têtes KV × dimension par tête × contexte × octets), en tenant compte explicitement de MLA et de l'attention à fenêtre glissante.
| F16 | 16 |
|---|---|
| BF16 | 16 |
| Q8_0 | 8,5 |
| Q6_K | 6,57 |
| Q5_K_M | 5,7 |
| Q4_K_M | 4,9 |
| Q4_0 | 4,64 |
| IQ4_XS | 4,46 |
| Q3_K_M | 4 |
| Q2_K | 3,17 |
| MXFP4 | 4,9 |
Niveaux de compatibilité
Tient en VRAM utilisable avec 15 % de marge et au moins 10 tok/s → Excellent. Tient → Compatible. Tient seulement dans le bas de l'estimation → Compatible avec limites. A besoin de la RAM système avec au moins 50 % sur le GPU → Offload CPU/GPU ; moins → Possible mais lent. Sous 5 tok/s → Possible mais lent ; sous 2 tok/s → Déconseillé. Ne tient pas du tout → Incompatible.
Apple Silicon : par défaut, le GPU peut utiliser environ 67 % de la mémoire unifiée jusqu'à 36 Go et 75 % au-delà. Il n'y a pas d'offload.
Vitesse
Les benchmarks réels sur le même matériel, le même modèle et la même quantification passent en premier (marqués « mesuré »). Ensuite des benchmarks de la même famille sur le même matériel, ou du même modèle sur un autre matériel, extrapolés. Sinon un modèle de bande passante : temps par token ≈ octets lus par token ÷ (efficacité × bande passante) + couches × surcoût fixe par couche. Ce surcoût (lancement des calculs, synchronisation) explique qu'un GPU très rapide ne fasse pas tourner les petits modèles proportionnellement plus vite. Les deux plages, par backend et par type de modèle (ci-dessous), sont ajustées sur les résultats llama-bench approuvés : modèles denses d'après les tableaux de référence de llama.cpp (Llama 2 7B), mélanges d'experts d'après gpt-oss et Qwen3 Coder, qui lisent des experts dispersés et paient environ deux fois plus de surcoût par couche. Un backend sans benchmark garde un surcoût nul. Une estimation par formule a toujours une confiance faible.
| Backend | Type de modèle | Efficacité (part de la bande passante crête) | Surcoût par couche et par token |
|---|---|---|---|
| CUDA | Dense | 72–92 % | 0,02–0,06 ms |
| CUDA | Mélange d'experts | 60–78 % | 0,04–0,09 ms |
| ROCm | Dense | 66–88 % | 0,04–0,1 ms |
| ROCm | Mélange d'experts | 50–70 % | 0,07–0,16 ms |
| Vulkan | Dense | 60–88 % | 0,01–0,06 ms |
| Vulkan | Mélange d'experts | 50–74 % | 0,02–0,12 ms |
| SYCL | Dense | 35–55 % | 0–0 ms |
| SYCL | Mélange d'experts | 35–55 % | 0–0 ms |
| Metal | Dense | 62–86 % | 0–0,1 ms |
| Metal | Mélange d'experts | 55–75 % | 0,11–0,24 ms |
| CPU | Dense | 45–70 % | 0–0 ms |
| CPU | Mélange d'experts | 45–70 % | 0–0 ms |
Quelle est la précision des estimations de vitesse ?
Chaque benchmark approuvé est réestimé par la formule seule, comme si la mesure n'existait pas, puis comparé à ce qui a été mesuré. 157 vitesses mesurées sur 172 (91 %) tombent dans la plage estimée, sur 40 GPU, Mac et machines à mémoire unifiée différents. En médiane, le milieu de la plage vaut 1,03× la vitesse mesurée, et 95 % des milieux de plage sont entre 0,75× et 1,35× la mesure. Les lignes hors plage sont conservées : ce sont de vraies mesures. Quand un benchmark existe pour votre matériel, votre modèle et votre quantification exacts, le site l'affiche à la place, marqué « mesuré ».
| Backend | Mesures | Dans la plage estimée |
|---|---|---|
| CUDA | 79 | 67 |
| Metal | 10 | 10 |
| ROCm | 39 | 39 |
| Vulkan | 44 | 41 |
D'où viennent les benchmarks
Chaque vitesse mesurée est un résultat llama-bench publié par son auteur dans le dépôt llama.cpp ou ses discussions GitHub. Une ligne entre en attente et n'est utilisée qu'après une vérification manuelle face à sa source ; les lignes rejetées restent enregistrées pour ne pas être réimportées.
Merci aux 72 personnes dont les résultats publiés sont utilisés ici : @1337hero, @65a, @aajll, @AdamNiederer, @andj1210, @ariya, @bloodsweatncode, @brunodantas, @CarvalhoLeonardo, @cebeach, @chavdarb, @ckane, @daMustermann, @daniandtheweb, @davispuh, @ddpasa, @Diablo-D3, @easyfab, @elgris, @eugr, @fassn, @firefox42, @fkdosilovic, @ggerganov, @grgsim, @gyhor, @Hadrianneue, @Hassan-A-K, @Hedede, @hspak, @hypengw, @ilcommm, @ivanfioravanti, @Johnreidsilver, @JonRickSanchez, @KawaiiHachimi, @Kraust, @kresle, @l8bloom, @lhl, @marcingomulkiewicz, @max-krasnyansky, @MihaiBojescu, @NO-ob, @odbguru, @panasalik, @pontostroy, @prototypicall, @pwilkin, @QuantiusBenignus, @ranma, @Ristovski, @RodriMora, @rohan-sircar, @roykim98, @savvadesogle, @slaren, @spamshaker, @StarGuardian, @suneet-kumar-yunextraffic, @tabletuser-blogspot, @TinyServal, @Tom94, @totaldev, @ubergarm, @vgrebinski, @volyrique, @wbruna, @xog64, @xxxajk, @ygafarov, @zacharyarnaise.
Signaler une erreur ou citer un chiffre
Si un chiffre vous semble faux pour votre matériel, écrivez à contact@runllmlocally.com en indiquant la page, votre configuration et, si vous l'avez, la sortie de llama-bench. Le chiffre est vérifié face à sa source et corrigé.
Pour citer un chiffre, faites un lien vers la page d'où il vient et donnez la version des données affichée en bas de page, par exemple : « Run LLM Locally, Méthode et sources des données, données du 25 septembre 2026. »
Sources des données
Architectures des modèles d'après le config.json de chaque modèle sur Hugging Face ; spécifications matérielles de NVIDIA, AMD, Intel et Apple. Chaque donnée conserve sa source, son URL et sa date de récupération. Une donnée manquante est affichée comme non disponible, jamais devinée.
Spécification officielleDonnées mises à jour il y a 24 joursSource: Hugging Face, NVIDIA, AMD, Apple