Le dépôt numbat, publié sur Hugging Face par le compte anonyme burner22, se présente comme un checkpoint de mi-préentraînement du prochain modèle de classe Mythos d’Anthropic : environ 14 000 milliards de paramètres, 114 couches, 772 fragments, pour un total d’environ 7,72 To. Créé le 23 octobre, il s’est répandu parmi les développeurs vers le 1er novembre ; en un peu plus d’une journée, l’espace de discussion a ouvert 31 sujets.
La conclusion du dernier audit communautaire est sans détour : une grande partie de ces fichiers sont des nombres pseudo-aléatoires générés avec le nom du tenseur comme graine, et le modèle n’a pas été entraîné.
Quelques lignes de code suffisent à le recalculer
L’utilisateur FloxUnder a été le premier à publier la recette : hacher le nom du tenseur avec SHA-256, prendre les 8 premiers octets comme graine du générateur PCG64, produire une loi normale centrée réduite, puis appliquer une transformation fixe. Pour les couches de normalisation, on utilise exp(0.06z) ; les noyaux de convolution sont multipliés par 1/6. Avec cette recette, il a reproduit au bit près 43 tenseurs complets, soit 730368 valeurs au total.
L’utilisateur ressl a ensuite téléchargé la totalité des 784 fichiers, soit 7,01 TiB, pour les vérifier. Les 289 couches de normalisation et les 258 noyaux de convolution concordent octet par octet ; sur 24 tenseurs NVFP4 échantillonnés, soit 192 millions d’éléments, la concordance du bit de signe est de 100 %.
Nous avons aussi refait le calcul. La rédaction a écrit un script de vérification d’après la recette publique, qui utilise uniquement des requêtes HTTP Range pour lire l’en-tête du premier fragment et deux tenseurs ; nous n’avons pas téléchargé le modèle ni exécuté le moindre code du dépôt. Les 12288 valeurs de model.layers.0.input_layernorm.weight et les 24576 valeurs de model.layers.0.self_attn.k_conv1d.weight, une fois recalculées, sont identiques au contenu du fichier. Nous n’avons vérifié que ces deux tenseurs ; la conclusion sur l’ensemble provient de l’audit des deux utilisateurs cités.
L’emballage est presque sans défaut
Ce qui rend l’affaire trompeuse, c’est que tous les contrôles de structure sont réussis. Le rapport de ressl indique que les SHA-256 des 784 fichiers concordent, que plus de 1,57 million d’entrées d’index correspondent une à une aux en-têtes des fragments, sans manque ni excédent, et que le chargement des poids en mode strict ne signale aucune erreur. La section « Pourquoi c’est crédible » de la description du dépôt invoque précisément ce genre d’autocohérence.
Un niveau plus bas, la façade se fissure :
- Distribution des valeurs incorrecte : s’il s’agissait d’une loi normale quantifiée en NVFP4, environ six dixièmes des demi-octets devraient valoir 0, alors que la mesure n’en donne que 10 % ;
- Table d’échelles trop petite : dans le premier fragment, plus de 2,16 millions de valeurs d’échelle par bloc ne prennent que 45 valeurs distinctes ;
- Journal d’entraînement trop plat : la loss des 400 dernières étapes oscille entre 1,0359 et 1,0649, sans la décroissance attendue vers la fin de l’entraînement ;
- Tokenizer ancien : la règle de découpage est l’expression régulière de GPT-2, et le vocabulaire ne contient aucun token de caractère chinois, japonais ou coréen ;
- Nombre de paramètres incohérent : le décompte automatique de Hugging Face donne 6 800 milliards, alors que le dépôt revendique environ 14 000 milliards.
L’audit trace aussi ses limites. Des tenseurs comme lm_head et A_log ne correspondent pas aux graines dérivées du nom ; ressl estime qu’ils suivent un autre chemin aléatoire. Il n’affirme pas que chaque tenseur se déduit de son nom, mais maintient un point :
« I am claiming the model is not trained. »
(J’affirme que ce modèle n’a pas été entraîné.)
FloxUnder admet lui aussi qu’en ne regardant que ces 43 tenseurs, on ne peut logiquement pas exclure que ces paramètres aient été volontairement gelés pendant l’entraînement ; il demande donc à l’auteur de l’envoi de produire la configuration d’entraînement. À l’heure de la publication, les deux audits émanent d’utilisateurs de la communauté, sans caution d’un tiers ; l’identité de l’auteur de l’envoi et ses motivations ne peuvent pas être vérifiées pour l’instant.
Le nom de code est réel, les poids sont une autre histoire
Le mot numbat a bel et bien une origine. Dans le code source de Claude Code qui avait fuité en mars, le fichier prompts.ts contient un commentaire indiquant qu’un certain passage doit être supprimé au lancement du modèle, et le nom cité est numbat. La description du dépôt en fait sa preuve principale.
Si l’on met bout à bout les fuites de cette année, la différence est nette. Fin mars, l’extérieur a découvert Mythos grâce à des brouillons exposés par une erreur de configuration du système de gestion de contenu ; l’incident Claude Code, le même mois, a exposé du code côté client. Aucun de ces éléments ne concernait des poids de modèle. Le dépôt numbat prend un nom de code connu comme appât, puis s’appuie sur un ensemble de fichiers qui passent les contrôles ; or un nom de code rendu public peut être écrit par n’importe qui dans une description et ne prouve rien sur l’origine des fichiers.
Pour ceux qui l’ont téléchargé, le risque le plus concret se situe dans le code. Le dépôt contient modeling_numbat.py, et la description indique qu’on peut le charger avec trust_remote_code=True ; ce paramètre exécute en local le code Python du dépôt. Nous n’avons pas audité ce code et ne pouvons pas dire qu’il soit malveillant, mais pour un dépôt d’origine inconnue, cet interrupteur ne devrait pas être activé. Pour vérifier, on peut suivre la méthode de l’audit et se contenter de lire des octets, sans rien exécuter.
Sources : page du modèle et métadonnées du dépôt sur Hugging Face, messages d’audit communautaires n° 13 et n° 31, CocoLoop ; les résultats octet par octet des deux tenseurs ont été recalculés par la rédaction d’après la recette publique, et les chiffres globaux sont ceux des messages d’audit.