Das Repository numbat, hochgeladen vom anonymen Konto burner22 auf Hugging Face, gibt sich als Checkpoint aus der Mitte des Pretrainings eines kommenden Modells der Mythos-Klasse von Anthropic aus: rund 14 Billionen Parameter, 114 Schichten, 772 Shards, insgesamt etwa 7,72 TB. Das Repo wurde am 23. Oktober angelegt und sprach sich um den 1. November in Entwicklerkreisen herum; binnen gut eines Tages wurden im Diskussionsbereich 31 Themen eröffnet.
Das Ergebnis des jüngsten Community-Audits ist eindeutig: Ein großer Teil dieser Dateien besteht aus Pseudozufallszahlen, die mit dem Tensornamen als Seed erzeugt wurden. Das Modell wurde nicht trainiert.
Wenige Zeilen Code genügen zum Nachrechnen
Nutzer FloxUnder veröffentlichte das Rezept als Erster: Den Tensornamen mit SHA-256 hashen, die ersten 8 Bytes als Seed für den PCG64-Zufallsgenerator nehmen, eine Standardnormalverteilung erzeugen und eine feste Transformation anwenden. Bei Normalisierungsschichten wird exp(0.06z) verwendet, Faltungskerne werden mit 1/6 multipliziert. Nach diesem Rezept reproduzierte er 43 vollständige Tensoren mit insgesamt 730368 Werten bitgenau.
Nutzer ressl lud anschließend alle 784 Dateien mit 7,01 TiB herunter und prüfte sie. 289 Normalisierungsschichten und 258 Faltungskerne stimmten Byte für Byte überein; bei 24 stichprobenartig geprüften NVFP4-Tensoren mit zusammen 192 Millionen Elementen lag die Übereinstimmung der Vorzeichenbits bei 100 %.
Wir haben es ebenfalls nachgerechnet. Die Redaktion schrieb nach dem öffentlichen Rezept ein Prüfskript, das nur per HTTP-Range-Anfrage den Header des ersten Shards und zwei Tensoren las; wir haben das Modell nicht heruntergeladen und keinen Code aus dem Repository ausgeführt. Die 12288 Werte von model.layers.0.input_layernorm.weight und die 24576 Werte von model.layers.0.self_attn.k_conv1d.weight stimmten nach der Neuberechnung exakt mit dem Dateiinhalt überein. Wir haben nur diese beiden Tensoren geprüft; die Aussage zum Gesamtbestand stammt aus dem Audit der beiden genannten Nutzer.
Die Verpackung wirkt fast makellos
Das Täuschende an der Sache: Alle strukturellen Prüfungen bestehen. Laut ressls Bericht stimmen die SHA-256-Werte aller 784 Dateien, über 1,57 Millionen Indexeinträge entsprechen eins zu eins den Shard-Headern, es fehlt nichts und es ist nichts überzählig, und auch das Laden der Gewichte im strikten Modus meldet keinen Fehler. Der Abschnitt „Warum das glaubwürdig ist“ in der Repo-Beschreibung führt genau diese Art von Selbstkonsistenz an.
Eine Ebene tiefer fällt die Fassade:
- Falsche Wertverteilung: Wäre eine Normalverteilung auf NVFP4 quantisiert worden, müssten rund sechs Zehntel der Halb-Bytes null sein; gemessen wurden nur 10 %;
- Zu kleine Skalierungstabelle: Im ersten Shard gibt es über 2,16 Millionen Blockskalierungswerte, aber nur 45 verschiedene Ausprägungen;
- Zu glattes Trainingsprotokoll: Der Loss der letzten 400 Schritte schwankt zwischen 1,0359 und 1,0649; der gegen Trainingsende zu erwartende Rückgang ist nicht zu sehen;
- Veralteter Tokenizer: Die Segmentierungsregel ist der reguläre Ausdruck von GPT-2, im Vokabular gibt es kein einziges chinesisches, japanisches oder koreanisches Zeichen-Token;
- Parameterzahl passt nicht: Hugging Face zählt automatisch 6,8 Billionen, das Repo selbst nennt rund 14 Billionen.
Das Audit zieht auch Grenzen. Bei Tensoren wie lm_head und A_log passen die Namens-Seeds nicht; ressl vermutet dort einen anderen Zufallspfad. Er behauptet nicht, jeder Tensor lasse sich aus dem Namen ableiten, beharrt aber auf einem Punkt:
„I am claiming the model is not trained.“
(Ich behaupte, dass dieses Modell nicht trainiert wurde.)
Auch FloxUnder räumt ein, dass sich allein anhand der 43 Tensoren logisch nicht ausschließen lässt, dass diese Parameter beim Training absichtlich eingefroren wurden. Er bittet den Uploader daher, die Trainingskonfiguration vorzulegen. Bis Redaktionsschluss stammen beide Audits von Community-Nutzern, es gibt keine Bestätigung durch eine dritte Stelle; wer der Uploader ist und was er damit bezweckt, lässt sich nicht überprüfen.
Der Codename ist echt, die Gewichte sind eine andere Sache
Das Wort numbat hat tatsächlich einen Ursprung. Im im März abgeflossenen Claude-Code-Quellcode steht in prompts.ts ein Kommentar, dass beim Modellstart ein bestimmter Abschnitt entfernt werden soll; der dort genannte Name ist numbat. Die Repo-Beschreibung führt das als wichtigsten Beleg an.
Setzt man die Lecks dieses Jahres nebeneinander, ist der Unterschied klar. Ende März erfuhr die Öffentlichkeit von Mythos durch Entwürfe, die wegen einer Fehlkonfiguration des Content-Management-Systems sichtbar wurden; der Claude-Code-Vorfall im selben Monat legte Client-Quellcode offen. Keines dieser Materialien betraf Modellgewichte. Das numbat-Repo nutzt einen bekannten Codenamen als Aufhänger und stützt sich dann auf Dateien, die Prüfungen bestehen; ein bereits öffentlich gewordener Codename kann aber von jedem in eine Beschreibung geschrieben werden und belegt nichts über die Herkunft der Dateien.
Für alle, die das Repo heruntergeladen haben, liegt das praktischere Risiko im Code. Das Repository enthält modeling_numbat.py, und die Beschreibung nennt das Laden mit trust_remote_code=True; dieser Parameter führt Python-Code aus dem Repository lokal aus. Wir haben diesen Code nicht auditiert und können nicht sagen, dass er bösartig ist; bei einem Repository unklarer Herkunft sollte dieser Schalter aber nicht aktiviert werden. Wer prüfen will, kann wie im Audit nur Bytes lesen, ohne etwas auszuführen.
Quellen: Hugging-Face-Modellseite und Repository-Metadaten, Community-Audit-Beiträge #13 und #31, CocoLoop; die Byte-Ergebnisse der beiden Tensoren hat die Redaktion nach dem öffentlichen Rezept nachgerechnet, für die Gesamtzahlen gelten die Audit-Beiträge.