Calculateur de mémoire : quel LLM tient sur quelle machine ?
Combien de mémoire faut-il pour servir un modèle à poids ouverts, et sur quelle machine tient-il ? Ce calculateur applique la règle de nos 210 fiches de dimensionnement, ajoute le cache clé-valeur que les fiches ne comptent pas, et donne le contexte maximal tenable par machine.
Sur les huit machines des fiches
| Machine | Mémoire, Go | Verdict | Contexte max, tokens |
|---|
Les formules, telles qu'appliquées
Poids seuls = paramètres (milliards) × octets par paramètre du format. FP16 : 2 octets ; FP8 : 1 ; NVFP4 : 0,5 ; Q4 : 0,6 échelles comprises. Ce sont des définitions de format, pas des mesures.
Poids avec marge = poids seuls × 1,15. La marge de 15 % pour activations, tampons et fragmentation est une hypothèse d'exploitation QDNA, non mesurée.
Cache clé-valeur = Kio par token × 1 024 × contexte × requêtes simultanées. Attention par têtes : 2 × couches × têtes KV × dimension × octets. Attention latente : (latent + RoPE) × couches × octets.
Verdict : « tient » si poids avec marge ≤ 75 % de la mémoire et total ≤ mémoire ; « tient tout juste » si total ≤ mémoire ; « ne tient pas » sinon. Contexte maximal = (mémoire − poids avec marge) ÷ (Kio par token × 1 024 × requêtes).
Hypothèses et sources, datées
- Paramètres des huit modèles : nombre annoncé par l'éditeur, relu le 2 septembre 2026 sur config.json et l'API Hugging Face (le nombre d'éléments de tenseurs peut différer de quelques pour cent, la note de chaque fiche le dit).
- Mémoire des huit machines : fiche technique du constructeur, relue le 2 septembre 2026 ; somme des GPU pour un serveur, mémoire unifiée pour un poste.
- Octets par paramètre : définitions des formats (connaissance/faits.yaml, famille quantifications, vérifiée le 31 août 2026). Les poids publiés en 4 bits pèsent 0,54 à 0,56 octet avec leurs échelles.
- Cache clé-valeur : valeurs relues sur config.json dans nos articles GLM 5.3, GLM-5.3-Flash, Qwen3.8-27B et Qwen3.8-Flash-Next ; hors clés d'indexeur DSA (128 octets par couche) là où il y en a.
- Ne sont pas comptés : le modèle d'embedding, le reranker, le système d'exploitation, la mémoire du runtime au-delà de la marge, ni la vitesse (voir les fiches mesures).
Questions fréquentes
Pourquoi les fiches de dimensionnement ne comptent-elles pas le cache clé-valeur ?
Parce qu'il dépend de deux choix d'exploitation que la fiche ne connaît pas : la longueur de contexte servie et le nombre de requêtes simultanées. Les fiches donnent le verdict sur les poids et réservent un quart de la mémoire ; ce calculateur remplit ce quart avec vos valeurs et dit jusqu'où le contexte peut aller.
Le nombre de paramètres suffit-il pour calculer les poids ?
Presque. Le poids réel d'un dépôt dépend du nombre d'éléments de tenseurs et des échelles de quantification, qui ajoutent quelques pour cent que la marge de 15 % absorbe. Pour DeepSeek V4 Pro, 1 599 milliards d'éléments publiés en FP4 et FP8 mixtes pèsent 865 Go ; le calcul NVFP4 donne 800 Go avant marge.
Comment trouver les valeurs de cache pour un modèle absent de la liste ?
Dans le config.json du dépôt : nombre de couches, têtes clé-valeur et dimension de tête pour une attention par têtes ; taille du latent et de la clé RoPE pour une attention latente. Le mode « calcul depuis config.json » applique la formule affichée plus bas, en FP16 ou FP8 selon le runtime.
Pour aller plus loin
- Les 210 fiches de dimensionnement
- Prefill, decode et cache clé-valeur
- Qwen3.8-27B : 262 144 tokens sur une seule machine
- Comparateur de coût API au token ou serveur sur site
Un dimensionnement sur votre cas
Un échange sans engagement pour poser modèles, contexte et concurrence réels.
Réserver un échange