權重張量呈現隨機生成特徵

分析者透過對 Hugging Face 倉庫 burner22/numbat 進行範圍請求（Range requests）與校準測試，發現該模型的嵌入矩陣（embedding matrix）具有真實的語義結構。例如，詞彙「cat」與「cats」的餘弦相似度為 +0.4750，遠高於噪音底線 0.0090，顯示分詞器與嵌入層可能取自真實模型。

然而，其餘所有權重張量均被判定為合成數據。測試發現，每一行權重的標準差分布極度均勻，缺乏真實訓練模型中常見的輸入維度變異（real matrices vary 2× to 5× across input channels）。以 numbat 的第 0 層 up_proj 為例，其列間相對標準差僅為 0.0154，而真實的 Qwen2.5-7B 模型對應層則高達 0.0409 以上。

此外，權重矩陣的行間變異極小，不同類型張量（如 up_proj, down_proj, o_proj）的行間相對標準差均穩定在 0.1206 至 0.1211 之間，差異僅 0.4%。相比之下，真實模型的這些指標會因層級與功能不同而出現顯著波動。

輸出層與量化縮放因子存在數學矛盾

第一項決定性測試針對語言模型頭（lm_head）。該倉庫設定 tie_word_embeddings: false，意味著 lm_head 應獨立於嵌入層訓練。但在真實情況下，兩者的行向量方向應隨機分佈；然而 numbat 的 lm_head 每一行均嚴格遵循公式：lm_head[r] = 0.89 * embed[r] + 0.455 * noise[r]。

這種固定的線性關係在所有 131,072 行中保持一致，餘弦相似度恆定為 0.890。分析指出，真實訓練的矩陣不會出現這種跨所有行的固定係數現象，這強烈暗示 lm_head 是直接由嵌入層通過簡單數學運算生成的。

第二項測試檢查 NVFP4 量化所需的 input_scale（輸入縮放因子）。在 Transformer 架構中，gate_proj 與 up_proj 讀取相同的輸入張量 x，因此它們的 calibrated amax（絕對值最大值）必須完全一致。但在 numbat 倉庫中，所有 1,224 個專家模組（experts）的 gate_proj 與 up_proj 的 input_scale 數值均不相同，且範圍隨機分佈在 0.05 至 0.40 之間。

這種不一致性同樣出現在 GDN 與 MLA 架構的層級中，例如 Layer 2 的 q_proj、k_proj、v_proj 讀取相同輸入卻擁有不同的縮放因子。分析認為這些數值看起來像是隨機抽取（drawn），而非從真實數據測量而來。

上傳行為與帳戶歷史顯示可疑跡象

該倉庫由名為 burner22 的 Hugging Face 帳戶於 2026-10-23 創建。該帳戶僅有 7 位追蹤者，無任何組織成員資格，且在過去從未在任何地方發表過評論，包括在其自己的討論串下。

上傳過程顯示出高度自動化的特徵：所有 11 個元數據文件（README, config, tokenizer 等）在 27 秒內完成上傳，隨後開始上傳權重分片。整個上傳過程持續約 41 小時，平均速度為每小時 18.6 個分片，中位數間隔為 110 秒。

上傳順序並非連續，而是呈現跳躍式模式（如 1, 772, 143, 201...），暗示使用了 12 個並行工作程序。總吞吐量約為 52 MB/s。在上傳完成後，該帳戶已靜默八天，但 README 仍寫著「它們都在上傳中，請耐心等待」。

技術規格與宣稱存在內部矛盾

倉庫宣稱該模型是在 Trainium2 硬體上訓練的 Anthropic 檢查點，並使用 NVFP4 量化格式。然而，NVFP4 是 NVIDIA Blackwell 架構專有的數據格式，Trainium2 並不支援 FP4 路徑。這使得「在 Trainium2 上訓練並直接發布 NVFP4 檢查點」的說法在技術上站不住腳。

此外，該模型宣稱使用 Anthropic 內部架構（Hybrid GDN/MLA），但提供了手寫的 modeling_numbat.py 檔案以支援 Hugging Face Transformers 載入。分析指出，Anthropic 通常不使用 Hugging Face Transformers 進行訓練，且內部檢查點不會包含這種為外部相容性而寫的自動映射代碼。

評估數據也存在不一致：ckpt_metadata.json 報告 MMLU 測試樣本數 n=14042，但訓練日誌顯示 n=281；HellaSwag 測試樣本數從 10042 變為 201。且宣稱一個未經後訓練（post-training）的原始預訓練檢查點在 MMLU 上達到 88.5% 的分數，這處於前沿模型水準，被認為極不尋常。

參數量計算與檔案結構驗證

儘管權重內容可疑，該倉庫的檔案結構與參數量計算在形式上是自洽的。Hugging Face 報告的參數量為 6.8T，但 README 宣稱 14T。分析指出，HF 解析器跳過了 F8_E4M3 類型的張量（即 NVFP4 的縮放因子），若正確計算這些打包數據與 BF16 嵌入層，總參數量確實約為 13.7T 至 14T。

所有 772 個分片檔案均無重複位元組，且每個 NVFP4 區塊都包含有效的 absmax 值，這意味著生成器在構造偽造數據時，仔細模擬了真實量化過程的結構特徵，使得基本的完整性檢查（如文件大小、張量數量）能夠通過。

分析結論認為，該倉庫極有可能是由一個真實的嵌入矩陣與分詞器，加上隨機生成的權重張量組裝而成。若要最終確認，只需執行一層前向傳播，由於 lm_head 與輸入縮放因子均為人工構造，其輸出 logits 將呈現純噪音狀態。