匿名账号 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；两个张量的逐字节结果由编辑部按公开配方复算，全量数字以审计帖为准。