LLM/fit

Méthode

Une estimation ne vaut que si on peut la vérifier. Voici chaque formule, chaque réserve, et ce que ce site ne sait pas faire.

Les formules

Poids du modèleGio = paramètres × bits effectifs ÷ 8 ÷ 2³⁰

Les bits effectifs ne sont pas le nom du format. Un fichier Q4_K_M ne pèse pas 4 bits par paramètre : llama.cpp garde certains tenseurs en plus haute précision et ajoute les échelles de quantification. La table utilisée ici est Q2_K ≈ 3.35, Q3_K_M ≈ 3.9, Q4_K_M ≈ 4.85, Q5_K_M ≈ 5.7, Q6_K ≈ 6.6, Q8_0 ≈ 8.5, FP16 ≈ 16 bits par paramètre.

Cache KVGio = 2 × couches × têtes KV × dim. tête × contexte × requêtes × 2 ÷ 2³⁰

Deux tenseurs (clés et valeurs), deux octets par valeur parce que le cache reste en 16 bits chez presque tous les moteurs. C’est ce terme qui explose quand tu montes le contexte, et c’est presque toujours lui qui fait échouer un chargement qui « devrait passer ».

ActivationsGio = 0,05 + requêtes × min(contexte, 8192) × largeur × 2 × 3 ÷ 2³⁰

Le brouillon du modèle pendant qu’il écrit. La contribution du contexte est plafonnée à 8192 tokens : en inférence, le moteur travaille par blocs et ne garde pas tout le graphe comme à l’entraînement.

MoteurGio = max(0,75 ; poids × 10 %)

Ollama, LM Studio ou llama.cpp gardent leurs propres tampons. C’est une réserve forfaitaire, pas une mesure : un moteur peut demander plus.

Vitesse de générationtokens/s ≈ bande passante ÷ (paramètres actifs × bits ÷ 8) × rendement

La génération est limitée par la mémoire, pas par le calcul : chaque token relit les poids. Le rendement réel va de 20 à 50 % de la bande passante théorique selon le moteur, d’où une fourchette et non un chiffre. Sur un modèle à mélange d’experts, seuls les paramètres activés traversent le bus.

Les réserves

  • Carte graphique : 1 Gio retirés pour l’affichage, le pilote et la fragmentation.
  • Système : le plus grand de 4 Go ou 10 % de la RAM, jamais donné au modèle.
  • Mémoire unifiée (Apple) : au plus 75 % de la mémoire physique, parce que macOS ne laisse pas le GPU prendre tout.
  • Au-delà de 85 % du budget, le verdict passe en « ça passe juste » : le chargement réussit souvent, et échoue dès qu’une autre application prend sa part.
  • Les capacités sont reprises telles que le constructeur les annonce (24 Go, 16 Go…) et comptées en gibioctets, soit 2³⁰ octets — c’est la même unité que celle affichée par Ollama ou LM Studio.

Les sources

  • Architecture des modèles : le fichier config.json publié par l’éditeur sur Hugging Face — couches, têtes KV, dimension de tête, contexte maximum. Rien n’est saisi à la main.
  • Nombre de paramètres : l’index safetensors du dépôt, pas le nom du modèle.
  • Dépôts sous licence (Llama, Gemma) : le fichier de configuration est lu sur un miroir public dont le contenu est identique. La page du modèle indique lequel.
  • Cartes graphiques : RightNow GPU Database, dérivée de TechPowerUp — mémoire, bande passante, date de sortie, avec le lien de la fiche.
  • Apple Silicon : bande passante annoncée par Apple, lien vers le communiqué correspondant sur chaque entrée.

Ce que ça ne dit pas

  • Ce n’est pas un test de vitesse. La fourchette tokens/s est une borne physique, pas une mesure sur ta machine.
  • La compatibilité logicielle n’est pas vérifiée : un modèle peut tenir en mémoire et ne pas être encore pris en charge par ton moteur.
  • Les architectures à attention latente (DeepSeek V2/V3), hybrides ou multimodales ne sont pas dans le catalogue, justement parce que la formule du cache y est différente.
  • Les modèles à fenêtre glissante (Gemma 3) sont estimés sur le contexte complet : la vraie consommation peut être plus faible.
  • Une répartition sur plusieurs cartes n’est pas modélisée.
  • La quantification est une taille théorique : un fichier précis peut différer de quelques centaines de mégaoctets, et rien ne garantit qu’il existe dans ce format.