号称泄漏的 Anthropic 模型 numbat，43 个张量能用随机数逐位算出

模型卡上的一长串数字

仓库名是 burner22/numbat。据公开页面信息，账号 10 月 16 日才注册，仓库 10 月 23 日创建，至今约有 5800 多次下载。模型卡给出的说法很具体：

• 约 14 万亿参数、114 层，混合专家结构共 1224 个专家，每次激活前 48 个外加 1 个共享专家
• 权重为 4 位的 NVFP4 格式，分成 772 个分片，索引文件标注的总大小约 7.72 TB
• 声称是预训练第 183 万步的检查点（全程约 196 万步），还没做后训练
• 元数据自报 MMLU 88.49%、ARC-Challenge 72.01%、HellaSwag 71.85%，均无独立复现

来源方面，模型卡只有作者的自述，并写明不要私信询问出处。没有签名，没有官方哈希，也没有任何能和 Anthropic 对上的外部记录。

不用下载 7 TB，几段字节就够了

这么大的文件，绝大多数人既下不动也跑不起，有 Hacker News 评论者估计要好几个 GPU 机架才能运行。体量本身就挡住了最直接的检验办法：加载起来问它几个问题。

讨论区第 13 号帖换了条便宜得多的路。审计者 FloxUnder 用 HTTP Range 请求只读取小段字节，没有执行仓库里的任何 Python 代码。其发现是：对张量名称取 SHA256，用前 8 个字节给 NumPy 的 PCG64 生成器做种子，再按固定公式换算，得到的数值与仓库里的权重完全一致。这样对上的张量有 43 个，共 730,368 个 BF16 值，其中 28 个是归一化层权重，15 个是卷积核。

更有说服力的是接下来这一步：摸清公式后，审计者先预测了另外 21 个还没读取的张量，再去读文件，结果全部吻合。训练过的权重会被梯度一步步推离初始值，几乎不可能还和一个只靠名字就能算出的随机序列逐位相同。

不过这项审计的范围要说清楚。73 万个数值放在万亿级的总量里只占极小一部分，审计者也写明没有检查全部张量，没有复现完整推理，也不能从逻辑上排除训练时刻意冻结这些参数的可能。另有评论者称，部分张量与这个公式对不上，可能用了别的配方或叠加了噪声。所以目前能说的是：至少这一部分不是训练出来的。其余约 7 TB 里是什么，还没人给出答案。

数字对得上，并不能说明什么

最早引发怀疑的是参数量：Hugging Face 自动统计为 6.8 万亿，上传者却说约 14 万亿。这一条其实解释得通。如果 4 位数值两两打包进一个字节，统计工具按字节计数，换算回去约 13.67 万亿，和 7.72 TB 的体积也大致吻合。

但这种自洽只能说明文件之间彼此配套，配置、代码和权重完全可以一起生成，真货和假货都做得到。其他技术线索同样两边都有人解读：有用户指出 AWS 文档并未列出 Trainium2 原生支持 FP4，与模型卡的评估说法不合；也有人在评估配置里找到一个编译器参数，认为它与这类硬件上的实际问题相符，但同时强调这证明不了真伪。

代号也是同样的道理。今年 3 月 31 日，Claude Code 2.1.88 的 npm 包误带 source map，约 51 万行 TypeScript 源码外流，Anthropic 称这是人为失误造成的打包问题，不涉及客户数据和凭证。据多篇二手报道，源码里出现过 numbat 这个未发布模型的名字，但这一点我们没能从一手来源确认。就算属实，这个名字也已公开流传七个多月，谁都可以拿来命名自己的仓库。

挂在讨论区里的那个问题

截至 11 月 1 日的公开报道，没有发现 Anthropic 的回应，Hugging Face 也没有公开的下架记录。对一家公司来说，这类说法回应了反而可能替它扩散，沉默本身不算证据，无论往哪边解读都一样。

仓库里还带着 modeling_numbat.py 等自定义代码。这并不说明代码有问题，我们也没有审查过它，但加载时若开启远程代码执行，等于在本机运行陌生账号写的程序。审计者特意绕开这些代码，是个值得照做的习惯。

FloxUnder 在帖子里直接请上传者解释这些匹配，并提供训练配置，好判断参数是否被有意冻结。这是一个只有真正持有训练记录的人才答得上来的问题。在我们查阅时，帖子下只有其他用户的复现，还没有看到上传者的回复。