匿名帳號 burner22 在 Hugging Face 上傳的倉庫 numbat，自稱是 Anthropic 下一代 Mythos 等級模型的預訓練中期檢查點：約 14 兆參數、114 層、772 個分片，總量約 7.72 TB。倉庫於 10 月 23 日建立，11 月 1 日前後在開發者圈子裡傳開，一天多的時間內討論區就開了 31 個話題。
最新一份社群稽核的結論很直接：這批檔案有很大一部分是拿張量名稱當種子產生的偽亂數，模型並沒有經過訓練。
幾行程式碼就能重新算出來
使用者 FloxUnder 最先公布配方：對張量名稱做 SHA-256，取前 8 個位元組作為 PCG64 亂數產生器的種子，產生標準常態分布，再做一次固定轉換。正規化層取 exp(0.06z)，卷積核乘以 1/6。依這個配方，他逐位元重現了 43 個完整張量，共 730368 個數值。
使用者 ressl 隨後把 784 個檔案、7.01 TiB 全部下載下來驗證。289 個正規化層與 258 個卷積核全部位元組層級一致；抽查的 24 個 NVFP4 張量共 1.92 億個元素，符號位元吻合率為 100%。
我們也跑了一遍。編輯部依公開配方寫了驗證腳本，只用 HTTP Range 請求讀取第一個分片的檔頭和兩個張量，沒有下載模型，也沒有執行倉庫裡的任何程式碼。model.layers.0.input_layernorm.weight 的 12288 個值、model.layers.0.self_attn.k_conv1d.weight 的 24576 個值，重新計算的結果與檔案內容完全相同。我們只驗證了這兩個張量，全面性的結論來自上述兩位使用者的稽核。
包裝幾乎挑不出毛病
這件事的迷惑性在於，結構檢查可以全部通過。ressl 的報告列出：784 個檔案的 SHA-256 全部對得上，157 萬多筆索引與分片檔頭一一對應，沒有缺漏也沒有多餘，以嚴格模式載入權重也不會報錯。倉庫說明中「為什麼可信」一節，舉的正是這類自洽性。
再往下一層就露出破綻：
- 數值分布不對：如果是把常態分布量化成 NVFP4，約六成的半位元組應該是 0，實測只有 10%；
- 縮放表太小：第一個分片裡 216 萬多筆區塊縮放值，只有 45 種取值；
- 訓練日誌太平：最後 400 步的 loss 在 1.0359 到 1.0649 之間擺盪，看不出接近訓練尾聲時該有的下降；
- 分詞器很舊：切詞規則是 GPT-2 的正規表示式，詞表裡一個中日韓字元的 token 都沒有；
- 參數量對不上：Hugging Face 自動統計為 6.8 兆，倉庫自稱約 14 兆。
稽核也劃出了界線。lm_head、A_log 等幾類張量與名稱種子對不上，ressl 認為它們走的是另一條亂數路徑。他並未斷言每個張量都能從名稱推出，只堅持一點：
「I am claiming the model is not trained.」
（我主張的是，這個模型沒有被訓練過。）
FloxUnder 也承認，光看那 43 個張量，邏輯上排除不了「訓練時刻意凍結這些參數」的可能，因此請上傳者提出訓練設定。截至發稿，這兩份稽核都出自社群使用者，沒有第三方機構背書，上傳者是誰、意圖為何，目前都無法查證。
代號是真的，權重則是另一回事
numbat 這個詞確實有出處。今年 3 月流出的 Claude Code 原始碼裡，prompts.ts 有一行註解寫著模型上線時要刪掉某段內容，提到的名稱就是 numbat。倉庫說明把這一點當作頭號證據。
把今年幾次外洩串起來看，差別很清楚。3 月底外界得知 Mythos，靠的是內容管理系統設定失誤帶出的文稿；同月的 Claude Code 事件流出的則是用戶端原始碼。這些資料都沒有涉及模型權重。numbat 倉庫拿已知代號當引子，再用一組能通過校驗的檔案撐場面，但一個公開過的代號誰都能寫進說明裡，證明不了檔案的來源。
對下載過的人來說，更實際的風險在程式碼。倉庫附有 modeling_numbat.py，說明裡寫了可以用 trust_remote_code=True 載入，這個參數會在本機執行倉庫內的 Python。我們沒有稽核這份程式碼，不能說它有惡意；但來路不明的倉庫，這個開關不該打開。需要查驗時，可以比照稽核的做法只讀取位元組，不必動手執行。
參考來源：Hugging Face 模型頁與倉庫中繼資料、社群稽核貼文 #13 和 #31、CocoLoop；兩個張量的逐位元組結果由編輯部依公開配方重新計算，全面性的數字以稽核貼文為準。