Comment nous calculons la configuration requise des LLM

Chaque chiffre de ces pages provient des formules ci-dessous — aucune magie cachée, aucune fiche technique scrapée. Ce sont des approximations, et nous expliquons leurs limites.

Taille de téléchargement selon la quantisation

size_GB = params_B × bits_per_weight ÷ 8

La taille du fichier d'un modèle est : nombre de paramètres × bits par poids ÷ 8. Les valeurs de bits par poids incluent la surcharge du format GGUF — par exemple Q4_K_M correspond à 4,85 bits effectifs, donc un modèle 8B fait 8 × 4,85 ÷ 8 ≈ 4,9 GB. Les builds GGUF réels varient de quelques pour cent.

RAM système minimale

min_RAM = size_GB × 1.25 + 1.5 → next standard tier

Nous prenons la taille en mémoire en Q4_K_M, ajoutons 25 % de surcharge d'exécution (activations, buffers) plus 1,5 GB pour le système d'exploitation, puis arrondissons à la taille mémoire standard supérieure (8, 12, 16, 24, 32 GB, etc.). Cette valeur arrondie est la « RAM min. » affichée dans chaque tableau.

Cache KV selon la longueur de contexte

kv_bytes/token ≈ 131 072 × (params_B ÷ 8)^0.45

Le cache KV grossit linéairement avec la longueur du contexte. Nous nous ancrons sur Llama 3.1 8B avec grouped-query attention — 32 couches × 8 têtes KV × 128 de dimension de tête × 2 (K et V) × 2 octets ≈ 131 kB par token — et appliquons une mise à l'échelle sous-linéaire avec le nombre de paramètres (puissance 0,45), car la profondeur et la largeur KV croissent plus lentement que le total des paramètres. C'est pourquoi un modèle qui tient à 4K de contexte peut manquer de mémoire à 32K.

Estimations de vitesse (tok/s)

tok/s ≈ bandwidth_GBs × 0.85 ÷ active_size_GB

La génération de tokens est limitée par la bande passante mémoire : produire un token lit une fois tous les poids actifs. Donc tok/s ≈ bande passante × 0,85 ÷ taille du modèle en Q4, où 0,85 est un facteur d'efficacité empirique par rapport à un benchmark de copie brute. Pour les modèles mixture-of-experts, seuls les paramètres actifs comptent — c'est pourquoi un MoE de 30B peut être plus rapide qu'un 8B dense.

Le benchmark de bande passante dans le navigateur

Le benchmark optionnel mesure la bande passante mémoire effective du GPU par des copies répétées de gros buffers WebGPU et prend environ 1 à 2 secondes. Il s'exécute entièrement dans votre navigateur ; rien n'est envoyé et rien n'est stocké. Sur Apple Silicon, la bande passante mesurée affine aussi l'estimation de la classe de puce (base / Pro / Max / Ultra).

Limites connues

Ce sont des estimations de planification, pas des benchmarks de votre machine exacte. La vitesse réelle varie selon le runtime (llama.cpp, MLX, vLLM), la longueur du contexte, la taille de batch et la dissipation thermique. Les verdicts de compatibilité supposent le build Q4_K_M recommandé et une machine presque au repos — quand un modèle est limite, prévoyez de fermer des applications ou de descendre d'un niveau de quantisation.

Bits effectifs par poids

Quantisation	Bits/poids	Qualité
Q2_K	3.35	Perte sensible
Q4_K_M	4.85	Recommandée
Q5_K_M	5.65	Élevée
Q8_0	8.5	Quasi originale
F16	16	Originale

Les tailles sont estimées à partir du nombre de paramètres × bits par poids ; les builds GGUF réels varient légèrement. · Données mises à jour: 2026-06-11