Taille d’un modèle IA : calculer le poids réel
Un modèle annoncé en 8 bits peut occuper bien moins qu’un calcul théorique. Voici comment vérifier la taille réelle des fichiers avant téléchargement.
Un modèle annoncé en 8 bits peut peser comme un modèle en 4 bits
Vous préparez le téléchargement d'un grand modèle d'IA et vous vous demandez combien d'espace disque prévoir. La fiche du modèle mentionne une quantification des poids en MXFP4 et des activations en MXFP8, tandis que l'étiquette de la plateforme affiche une précision de 8 bits. Pourtant, si on additionne les fichiers du dépôt puis qu'on divise par le nombre de paramètres annoncé, on tombe sur environ 4,49 bits par paramètre.
Ce n'est pas qu'un détail d'arrondi. Pour 2,78 billions de paramètres, le calcul « théorique » donnerait environ 2 780 Go à 8 bits et 1 390 Go à 4 bits. Or, le checkpoint étudié pèse environ 1 561 Go. Les trois chiffres peuvent être compatibles, mais ils ne répondent pas à la même question.
Conclusion pratique : pour dimensionner un téléchargement ou un stockage, l'étiquette de précision ne suffit pas. Il faut distinguer le format des poids, celui des activations, les autres tenseurs conservés en précision supérieure, et surtout - les fichiers que vous allez réellement récupérer. Voici une méthode vérifiable pour mesurer la taille d'un checkpoint, éviter de compter deux fois les mêmes poids, et interpréter correctement ce que votre mesure signifie (ou ne signifie pas).
Pourquoi les chiffres de précision divergent
Le mot « précision » est souvent utilisé comme s'il parlait d'une seule et même chose. En réalité, une fiche peut décrire la représentation des poids, une autre les activations calculées pendant l'inférence, et l'étiquette de la plateforme peut résumer ce que la plateforme détecte dans les fichiers. Tout ça est lié, mais pas au même niveau.
Poids et activations ne désignent pas la même chose
Les poids sont les paramètres appris et stockés dans le checkpoint. Leur représentation influe directement sur la taille des fichiers que vous téléchargez.
Les activations, elles, sont des valeurs intermédiaires calculées quand le modèle traite une entrée. Leur précision peut jouer sur l'exécution, la mémoire utilisée pendant l'inférence et parfois la stabilité numérique - mais on ne peut pas déduire la taille du checkpoint uniquement à partir de ce point.
Du coup, une mention du type « poids MXFP4, activations MXFP8 » peut vouloir dire : les poids sont majoritairement encodés sur 4 bits, tandis que certaines étapes d'exécution utilisent une représentation sur 8 bits. Une étiquette « 8-bit » ne prouve donc pas que chaque poids occupe huit bits sur disque.
Une précision nominale n'est pas une mesure de fichier
Le calcul « théorique » sert à donner un ordre de grandeur. Si chaque paramètre était stocké sur huit bits (donc un octet), 2,78 billions de paramètres donneraient environ 2 780 Go. En revanche, à quatre bits (un demi-octet), on tomberait près de 1 390 Go.
Mais ce calcul suppose deux choses qui ne sont pas vraies dans la plupart des checkpoints réels : (1) tous les paramètres ont exactement le même format, et (2) la taille ne contient rien d'autre.
Un checkpoint contient souvent des tenseurs à 16 ou 32 bits, des métadonnées, et des données auxiliaires liées à la quantification. De plus, le nombre « paramètres » affiché n'indique pas forcément combien de ceux-ci sont réellement stockés dans le format quantifié annoncé.
Résultat : le nombre de bits par paramètre obtenu à partir de la taille des fichiers est un coût moyen de stockage, pas une description détaillée de chaque tenseur. Pour le checkpoint Kimi K3.1 Pro analysé ici, la somme des fichiers fait 1 561,3 Go pour 2 780 110 363 392 paramètres, soit environ 4,4928 bits par paramètre. Cela dit quelque chose sur le volume total, mais ça ne veut pas dire que chaque poids est encodé exactement sur 4,4928 bits.
Comment calculer la taille réelle d'un checkpoint
Pour estimer un téléchargement, la mesure la plus utile est simple : additionner la taille des fichiers que vous allez réellement récupérer. Une API de dépôt (par exemple sur Hugging Face) peut fournir ces tailles, ainsi que des infos sur le nombre de paramètres associés aux tenseurs. Le calcul se fait vite, mais il faut faire attention à deux points : obtenir les bonnes tailles et éviter de compter plusieurs fois des poids ré-encodés dans le même dépôt.
Additionner les fichiers visés, pas tout le dépôt
Voici un exemple en Python, adapté à l'API publique de Hugging Face. Le paramètre blobs=true demande les tailles. Le filtre .safetensors ne conserve que les fichiers à la racine du dépôt, ce qui correspond ici aux shards visés par le téléchargement étudié.
import json
import urllib.request
repo = "moonshotai/Kimi-K3.1-Pro"
api_url = (
"https://huggingface.co/api/models/"
+ repo
+ "?blobs=true"
)
with urllib.request.urlopen(api_url) as reponse:
donnees = json.load(reponse)
fichiers = [
fichier for fichier in donnees["siblings"]
if fichier.get("size")
and fichier["rfilename"].endswith(".safetensors")
and "/" not in fichier["rfilename"]
]
taille_octets = sum(fichier["size"] for fichier in fichiers)
parametres = donnees["safetensors"]["total"]
print(f"{len(fichiers)} shards, {taille_octets / 1e9:,.1f} Go")
print(f"{parametres:,} paramètres")
print(f"{taille_octets * 8 / parametres:.4f} bits par paramètre")
Pour ce dépôt, on obtient 96 shards, 1 561,3 Go et 4,4928 bits par paramètre. Notez au passage : les gigaoctets ici sont en décimal (1 Go = un milliard d'octets). Sur votre machine, certains outils affichent peut-être en gibioctets (base 2), ce qui peut créer une différence d'affichage sans changer le nombre d'octets à réserver.
Vérifier le périmètre avant de faire confiance au chiffre
La liste des fichiers et le calcul doivent correspondre à ce que vous allez télécharger. Ici, le filtre exclut volontairement les sous-répertoires. Ce choix convient à ce dépôt précis, mais ce n'est pas universel : si les fichiers nécessaires au modèle sont dans un dossier, le filtre pourrait les omettre et vous sous-estimer la taille.
À l'inverse, additionner tous les fichiers du dépôt peut compter deux fois (ou plus) les mêmes poids si le dépôt contient des copies ou plusieurs formats. Avant d'utiliser le total pour établir un budget de stockage, vérifiez :
- quels fichiers seront réellement récupérés par votre méthode de téléchargement ;
- si le dépôt contient plusieurs représentations (formats, copies, variantes) ;
- si les fichiers sont à la racine ou dans des sous-dossiers ;
- si les tailles rapportées couvrent bien tous les fichiers que vous gardez ;
- si vous comparez des Go décimaux à des Gio binaires.
La mesure obtenue est une estimation de la taille des fichiers ciblés. Elle ne couvre pas forcément l'espace temporaire requis pendant le téléchargement, l'extraction ou la conversion. Si votre disque est presque plein, prévoyez une marge plutôt que de réserver exactement le total annoncé.
Pourquoi un checkpoint 4 bits dépasse le calcul théorique
Un fichier quantifié ne contient pas forcément uniquement des poids compactés sur 4 bits. Certaines données peuvent rester en précision supérieure, et la quantification nécessite aussi des informations annexes. Dans l'exemple étudié, ces éléments expliquent presque tout l'écart entre le calcul simplifié « quatre bits » et la taille observée des fichiers.
Décomposer les octets plutôt que se contenter d'une étiquette
La décomposition publiée pour le checkpoint Kimi K3.1 Pro est :
| Élément | Octets | Taille décimale |
|---|---|---|
| Poids quantifiés à 4 bits, à un demi-octet par poids concerné | 1 361 370 415 104 | 1 361,4 Go |
| Tenseurs conservés en 16 et 32 bits | 114 761 311 232 | 114,8 Go |
| Échelles de bloc, estimées à un octet pour 32 poids | 85 085 650 944 | 85,1 Go |
| Total estimé de ces trois postes | 1 561 217 377 280 | 1 561,2 Go |
| Taille mesurée des fichiers | 1 561 293 160 568 | 1 561,3 Go |
| Écart résiduel | 138 589 683 | 0,139 Go |
On est à environ 139 Mo de différence entre l'estimation et la mesure, soit près de 0,009 % du total. Autrement dit : l'explication "ça ressemble principalement à des poids en 4 bits + du reste en précision supérieure + des données d'échelle" tient assez bien.
Le poste des tenseurs à précision supérieure mérite quand même d'être regardé : ici, il pèse 114,8 Go. Donc une partie des données n'est effectivement pas stockée sur 4 bits. Certaines couches peuvent rester en haute précision pour préserver la qualité ; d'autres sont peut-être trop petites pour que l'empaquetage en 4 bits apporte un gain utile. Le point clé : le détail par tenseur n'est pas exposé dans ce calcul, donc on ne peut pas attribuer une cause précise à chaque poids resté en haute précision.
Au fond, l'expression « modèle 4 bits » décrit le format dominant (ou la quantification annoncée), pas forcément la répartition exacte de tous les octets du checkpoint. Deux modèles annoncés « 4 bits » peuvent donc avoir des tailles différentes si la part des tenseurs conservés en haute précision, les métadonnées ou les données auxiliaires ne sont pas les mêmes.
Traiter les échelles comme une hypothèse
Le calcul suppose que les échelles de bloc occupent un octet pour 32 poids. Ces données servent à stocker les facteurs nécessaires à la quantification par blocs, mais leur taille exacte n'est pas forcément publiée séparément dans les informations utilisées ici.
Le rapprochement avec la taille totale est convaincant, mais ce n'est pas une preuve que chaque échelle fait exactement cette taille. Si le schéma de quantification utilise un autre découpage, la ventilation entre catégories peut changer, tout en gardant un total global qui reste "plausible". L'objectif de ce calcul est surtout d'expliquer l'ordre de grandeur et les gros postes ; dès qu'on a besoin d'une lecture au niveau de chaque couche, il faut regarder les tenseurs et/ou la documentation technique.
Que peut-on conclure des étiquettes et du calcul
Le calcul de taille répond à une question opérationnelle : combien d'octets occupent les fichiers ciblés. En revanche, il ne dit rien sur la vitesse d'inférence, la mémoire vidéo nécessaire, ni la qualité du modèle. Mélanger ces sujets mène facilement à des conclusions que les données ne soutiennent pas.
Un dépôt peut contenir plusieurs copies des mêmes poids
Un exemple avec openai/gpt-oss-120b montre bien le piège. Si on additionne tous les shards .safetensors sans distinguer les dossiers, on obtient 195,8 Go pour 116,8 milliards de paramètres, soit 13,405 bits par paramètre. À ce stade, ça paraît incompatible avec un checkpoint censé être en quatre bits.
La cause n'était pas "un mystère sur les bits", mais le périmètre : le dépôt contient des shards MXFP4 à la racine, plus des copies dans original/ et metal/. En ne gardant que les 15 shards à la racine, on retombe à 65,2 Go et 4,4680 bits par paramètre. La décomposition estimée correspondait d'ailleurs à environ 65,2 Go.
Leçon : un dépôt de fichiers n'est pas automatiquement un "checkpoint unique". Il peut héberger plusieurs représentations des mêmes poids. Le calcul doit donc être associé à un ensemble précis de fichiers et à la façon dont vous téléchargez le modèle.
Une étiquette de plateforme n'est pas une jauge de téléchargement
Les deux dépôts examinés portent une étiquette 8 bits sur la plateforme, tout en utilisant une quantification quatre bits pour les poids étudiés. Par ailleurs, le dépôt GPT-OSS-120B mentionne aussi MXFP4. Ces éléments peuvent coexister : l'étiquette et la description du format ne donnent pas forcément la même information.
Une explication plausible (mais non prouvée) est que l'étiquette reflète le type de données utilisé pour certains tenseurs, plutôt que le coût effectif en bits après empaquetage. Par exemple, deux valeurs sur 4 bits peuvent être regroupées dans un conteneur d'un octet. Mais sans savoir comment la plateforme attribue l'étiquette, ce serait risqué d'en faire un fait.
La version simple de la conclusion : une étiquette résume, ce n'est pas une mesure. Pour dimensionner un disque, utilisez la taille des fichiers que votre commande récupère réellement. Pour comprendre le format, regardez la description des poids et des activations, puis comparez-la au contenu réel du dépôt (y compris les éventuelles copies et métadonnées).
Ce que la mesure ne dit pas
Le calcul décrit ici repose sur la réponse de l'API et sur les tailles de fichiers exposées. Il ne repose ni sur le téléchargement complet du modèle, ni sur son chargement en mémoire. Donc rien n'est mesuré concernant le débit réseau, la consommation de mémoire vidéo, ou la performance sur une machine donnée.
Autre limite : la taille sur disque ne suffit pas à prévoir la mémoire nécessaire à l'inférence. Le modèle chargé peut mobiliser des structures supplémentaires, et les activations dépendent de l'exécution et de la configuration. Si votre décision porte sur une machine ou un serveur, vérifiez séparément les besoins de mémoire et les conditions d'exécution. Ne déduisez pas ça du "nombre de bits par paramètre" seul.
À retenir : pour estimer l'espace disque, additionnez les tailles des fichiers réellement ciblés. Pour interpréter le résultat, vérifiez le nombre de paramètres, les formats annoncés et les copies éventuelles dans le dépôt. Une moyenne en bits par paramètre est utile, mais ça ne remplace pas une lecture plus fine des tenseurs.
Conclusion
Les étiquettes de précision donnent une indication sur le format, mais elles ne remplacent pas une mesure basée sur les fichiers. Dans les exemples examinés, le rapport entre les octets du checkpoint et le nombre de paramètres donne environ 4,49 bits par paramètre, même avec une étiquette de plateforme à 8 bits. L'écart vient du fait que les poids ne sont pas tous stockés sur 4 bits : il y a aussi des tenseurs gardés en précision plus haute et des données auxiliaires.
Si vous voulez éviter les erreurs de dimensionnement, gardez une règle simple : définissez quels fichiers vous téléchargez réellement, additionnez leurs tailles, puis comparez ce volume avec les infos sur le nombre de paramètres et la quantification. Vérifiez aussi les sous-dossiers, les copies alternatives, et si vous comparez des unités Go ou Gio. Votre disque, lui, ne s'intéresse pas aux étiquettes : il a juste besoin que les octets soient bien là.