Anthropic Mythos 权重泄露是真的吗？burner22/numbat 核查：14T 参数、7.72TB、NVFP4，多项证据指向伪造

这两天最火的一条消息是：Hugging Face 上一个叫 burner22/numbat 的仓库，自称放出了 Anthropic“Mythos 级”下一代模型训练中期的检查点，14 万亿参数、114 层、1,224 个专家、7.72TB 权重。如果这是真的，它会是史上最惊人的闭源权重泄露之一。我们的判断先放在前面：这起所谓的 Mythos 权重泄露，目前没有任何来源证据，反而有多项公开、可检查的证据指向“按名字生成的随机数据”，我们倾向于把它当作伪造。需要强调的是，我们没有下载任何权重，也没有运行任何代码，下面的所有数字都来自 Hugging Face 的页面与接口、仓库里的小文本文件、以及他人公开的审计，并逐条标明出处。如果你刚读完我们之前对热门“魔改模型”的核查（OBLITERATUS 版和 GSQ-RCO 版），这一篇是同一种思路：先查数字，再查来历。

要点速览（更新于 2026-11-02，北京时间）

• 仓库真实存在、公开、未被下架：772 个权重分片，HF 记录的存储用量为 7,720,640,941,879 字节，和它声称的 7.72TB 吻合。

• 14T 和 HF 页面上的“6.85T”并不矛盾：HF 按字节数记 4 位权重，折算后约 13.68T 个数值。数字自洽，但这并不能证明真实，造假同样可以做到自洽。

• 一名社区成员报告：43 个完整张量可以只靠“张量名做种子的 NumPy 随机数”逐位重现；另一名成员称 NVFP4 大矩阵同样如此（约占文件体积 99.6%）。这两项我们没有复现，作者也承认这不能单独证明来源。

• 仓库自己的说法有矛盾：声称“训练中期”，元数据却写在第 183 万步/约 196 万步（约 93%）；声称在 Trainium2 上做 NVFP4 评测，而 AWS 文档并未列出 FP4。

• 我们没有找到 Anthropic 对这个仓库的任何声明。已知的官方表态只有：Claude Code 源码泄露不涉及模型权重，Mythos Preview 不计划普遍开放。

先说结论：Mythos 权重泄露的七项说法逐一对照

下面这张表把仓库的主要说法放在我们实际读到的内容旁边。“结论”一栏只表达我们对证据的判断，不是对任何人动机的判断。

numbat 仓库里到底有什么

我们在 2026-11-02 上午通过 Hugging Face 公开接口读取了仓库信息，并只下载了几个很小的文本文件（README、config.json、ckpt_metadata.json、hf_quant_config.json、两个 .py 文件、约 66KB 的训练日志尾部），没有碰任何权重分片。读到的情况如下：仓库公开，未设门槛，也没有被禁用；创建时间是 2026-10-23 01:37（UTC），最后一次提交是 2026-10-24 19:09（UTC，北京时间 10 月 25 日凌晨 3 点多），提交标题是“Upload model-00645-of-00772.safetensors with huggingface_hub”，看起来是分批上传的；页面显示约 5,846 次下载（页面口径，不代表有人真正运行过）和 204 个点赞；文件除 772 个分片外还有 12 个小文件，包括 README、配置、一个 1.5 亿字节的索引文件、分词器、两个自定义 Python 文件和一份训练日志尾部。上传账号 burner22 只有这一个模型，sysnote 报道称账号创建于 10 月 16 日。

README 的主要声称是：约 14T 参数、114 层、GDN 与 MLA 混合、MoE 有 1,224 个专家（每个 token 激活 48 个，另加 1 个共享专家）、NVFP4 量化、内部代号 numbat、“Anthropic 下一代 Mythos 级训练运行”的检查点、“训练中期”取得。它还给出了一个“为什么应该相信”的清单：代号在 Claude Code 泄露里出现过、架构“符合人们对下一代的预期”、每个张量“内部自洽”、文件大小与索引条目是确定性的。注意这四条论据没有一条是来历证据：代号是公开信息，架构是公开论文的组合，自洽与确定性恰恰是生成数据的特征。

数字对不对：14T 与 7.72TB 的算术核对

这是最容易被误读的一点，网上出现了两种相反的说法：一种说“HF 显示 6.85T，和 14T 对不上，所以是假的”，另一种说“体积对得上，所以是真的”。两种都不严谨。

HF 的安全张量元数据列出了三类数据：BF16 168.5 亿个，F32 约 13.9 万个，U8 约 6.83 万亿个，合计 6,849,377,242,584，也就是页面上显示的 6.8T。但 NVFP4 把两个 4 位数值打包进一个字节（U8），所以 6.83 万亿个字节对应约 13.67 万亿个 4 位权重，再加上 BF16 部分，总数约 13.68T，和“约 14T”基本吻合。也就是说，页面上的 6.85T 是按存储字节计数造成的假象，并不构成“数字对不上”的证据。

体积同样对得上：NVFP4 每 16 个权重共用一个 8 位缩放，所以每个权重约 4.5 位（0.5625 字节）。14T 乘以 0.5625 约为 7.88TB；以 13.67T 个 4 位权重计，4 位部分约 6.83TB，缩放约 0.85TB，再加 BF16 部分约 34GB，合计约 7.72TB，与 HF 记录的 7.72064TB 一致。我们自己还按 config.json 估算了总参数：107 个 MoE 层、每层 1,224 个专家、每个专家三个 12,288×2,816 的矩阵，仅路由专家就约 13.6T，与声称的规模吻合。结论是：数字全部自洽。但自洽只说明做这份文件的人算得很仔细，不说明里面的数据来自训练。

为什么说权重“看起来不像训练出来的”

这是整件事里最关键的一块证据，也是我们必须小心措辞的一块。

讨论 #13 的作者做了一次可复现的审计：他用 HTTP 范围请求只读取很小的字节段，没有执行仓库里的任何 Python 代码，然后发现 43 个完整张量（28 个归一化权重共 238,848 个值，15 个卷积核共 491,520 个值，合计 730,368 个 BF16 数值）可以仅凭张量名重新生成：取名字 SHA-256 的前 8 个字节作为种子，输入 NumPy 的 PCG64 随机数发生器，就得到逐位相同的结果。他还说在读取之前先记录了 21 个张量的预测值，之后全部吻合。同一个作者也写明了限制：这不能逻辑上排除“这些参数被刻意冻结”的训练设置，也不能证明来源。

讨论 #19 的作者进一步声称，NVFP4 大矩阵本身也是这样来的：用同样的种子方案抽取随机数，套一个简单的缩放公式，再做标准 NVFP4 量化，连同缩放约占整个检查点的 99.6%；他检查了来自 770 个分片的 5,503 个张量的符号，约 1.62 亿个全部吻合，并重建了 10 个张量，约 4.656 亿个 4 位码里只有约 1,500 个不同，还说 lm_head 约等于 0.891 倍的嵌入矩阵，尽管配置声称两者不共享。第三方 sysnote 用范围请求抽样了归一化权重：各层输入归一化的均值约 1.0、标准差约 0.06、没有异常值，读起来像 1 + 0.06×随机数；而训练到 93% 的真实网络，归一化权重通常会明显偏离初始值并出现异常通道。

我们的立场：这些都是公开、可检查、方法描述清楚的说法，彼此独立指向同一个方向，而且没有人拿出反证；但我们没有自己复现，所以在文章里始终写成“某某报告”。如果你是研究者，最有价值的做法是按讨论 #13 的方法自己用范围请求抽几个张量验证，而不是整个下载。

仓库自己的说法互相矛盾的地方

除了权重统计，仓库的自述里有几处无需任何复现就能看出的矛盾，我们逐项核对了。

第一，“训练中期”。README 说检查点“pulled mid-pretraining”，FAQ 又写它是约 196 万步运行里的第 1,830,000 步，约 93.4%；训练日志尾部每一行都标着 lr_phase=decay，学习率约 7.19e-5 缓慢下降。第 93% 步处于学习率衰减阶段，更像训练接近尾声而非中期。

第二，在 Trainium2 上评测 NVFP4。FAQ 解释说评测团队把每个异步检查点量化成 NVFP4，以便只用一小部分 Trainium2 就能评测，“仍需约 85 块”。我们核对了 AWS Neuron 文档：Trainium2 单芯片 96GiB HBM，文档列出的数据类型是 FP32、TF32、BF16、FP16 和 FP8 系列，没有 FP4。有社区评论指出 NVFP4 是 NVIDIA 的格式，两者对不上。从内存算术看，85 块 × 96GiB 约 8.76TB，确实刚好装得下 7.72TB，但这只是体积上说得通，不解决数据类型问题。

第三，评测与日志的细节。ckpt_metadata.json 自带 MMLU 0.8849（n=14,042）、ARC-Challenge 0.7201、HellaSwag（归一化）0.8896，均为自述，无第三方复现。训练日志尾部 400 步里，我们统计了相邻步骤的时间间隔：399 个间隔中 261 个是 7 秒、93 个是 6 秒、45 个是 8 秒，每秒约 1,100 万到 1,300 万 token。有评论认为这种整齐的间隔本身可疑，我们认为这是弱证据：时间戳精度只到秒，每步约 7 秒，6 到 8 秒的波动是正常的。按每步约 8,400 万 token 估算，到第 183 万步累计约 150T token，我们无法判断这对任何实验室是否现实，只提醒读者这是一个未经核实的惊人数字。

代号 numbat 与 Anthropic 官方立场

仓库最有说服力的一条是代号：多家来源引用称，2026 年 3 月 31 日 Claude Code 通过 npm 的 source map 泄露源码，其中一条注释写着“Remove this section when we launch numbat.”。Anthropic 当时对媒体的表态是“打包失误，不是安全入侵，未涉及客户数据或凭证”，Fortune 的报道还明确说这次泄露没有暴露模型权重。BleepingComputer 报道 Anthropic 随后对泄露的源码镜像发出了 DMCA 通知。代号是公开信息，任何人读了泄露的注释都能拿来命名自己的仓库，所以它只能证明上传者看过这条新闻。

关于 Mythos 本身，Anthropic 在 2026 年 4 月 7 日宣布 Project Glasswing 时说：“We do not plan to make Claude Mythos Preview generally available”，仅向受限的合作机构开放。我们没有找到 Anthropic 对 burner22/numbat 的任何公开声明，包括确认或否认。另外要提醒：Hacker News 上有评论问“这个仓库挂了一周都没被版权下架，现实吗”，这是读者的推理而不是证据；按我们 2026-11-02 上午的读取，仓库仍然公开，页面上也有用户提交的“违规内容”举报帖，但这些是用户行为，HF 是否处理我们无从得知。

社区与媒体怎么说

仍然无法排除什么

诚实地说，有三件事我们无法排除。其一，我们没有读完所有 7.72TB，审计主要覆盖归一化、卷积与一部分矩阵，如果有人在专家权重里发现训练痕迹，结论需要修改。其二，“伪造”只是我们基于现有公开证据的判断，我们不知道上传者是谁、动机是什么。其三，即使是伪造，也不代表 Anthropic 没有这样的模型，更不代表未来不会发生真实的权重泄露。

对普通读者意味着什么

最现实的建议是：不要下载，更不要用 trust_remote_code=True 去加载。仓库自带的 Python 文件会在加载时执行；我们读过 modeling_numbat.py（543 行）和 configuration_numbat.py，只看到对 torch、transformers 和标准库 math、typing 的引用，没有发现网络、子进程或写文件的调用，但这是抽查而非审计，仓库也可能在我们读过之后变化。即使一切正常，7.72TB 的数据对任何个人电脑都没有意义。想知道这种规模的模型到底需要什么硬件、如何识别“泄露模型”骗局、以及版权和商业秘密风险，请看我们的姊妹篇：14T 参数 MoE 要什么硬件，以及如何识别假泄露模型。如果你想用开源模型了解权重泄露带来的隐私问题，也可以看本地大模型与隐私，以及如何看懂大模型评测。

我们做了什么、没做什么

我们读取了仓库的公开接口与几个小文本文件，阅读了配置与自定义代码，阅读并统计了训练日志尾部，核对了 AWS Neuron 与 Anthropic、Fortune 的公开页面，阅读了 HF 讨论区与 Hacker News、sysnote、X 上的公开内容。我们没有下载任何权重分片，没有运行任何代码，没有复现任何审计，没有联系 Anthropic 或上传者。文章里的“已核对”指“与公开页面一致”，不是“我们亲手验证”。

常见问题 FAQ

Anthropic Mythos 权重真的泄露到 Hugging Face 了吗？

目前没有证据支持。仓库是真的，文件也是真的，但没有任何来源能把这些数据与 Anthropic 联系起来，而社区审计报告了多项指向生成数据的迹象。我们的判断是倾向于伪造，但我们没有自己复现审计。

为什么 HF 显示 6.8T，而仓库说 14T？

因为 NVFP4 把两个 4 位权重打包进一个字节，HF 按字节计数。折算后约 13.68T，所以这个差异本身不能说明真假。

体积和配置都对得上，不就说明是真的吗？

不能。自洽只说明制作者算得仔细；一个精心制造的伪造品可以做到所有数字对得上，这正是“按名字生成随机数据”的做法。

numbat 真的是 Anthropic 的内部代号吗？

多家来源引用泄露的 Claude Code 源码注释这样说，我们没有打开泄露的源码来核对。但即使是真的，它也只说明上传者读过这条新闻。

这个仓库安全吗，可以下载试试吗？

不建议。我们抽查的两个 Python 文件没有发现恶意调用，但加载它需要 trust_remote_code=True，意味着执行仓库提供的代码，而且数据对个人设备毫无用处。更多检查方法见姊妹篇。

下载或传播“泄露”权重合法吗？

如果是真的，它可能涉及商业秘密与版权问题，具体因地区而异；这是一般信息，不是法律意见，需要时请咨询律师。我们不提供任何下载链接。

和我们聊聊

对热门“泄露”“魔改”模型有疑问，想让我们帮你核查，或者想交流自己的审计方法？欢迎到社区留言，或发邮件到 admin@microaione.com，附上你看到的链接和问题。

参考资料：HF 讨论 #13（张量重现审计）、Hacker News 讨论、sysnote 抽样分析、Anthropic：Project Glasswing、Fortune：Claude Code 源码泄露报道、AWS Neuron：Trainium2 架构。数据读取于 2026-11-02，北京时间。

延伸阅读：大模型越狱与安全专题｜越狱防御怎么做：从对齐训练、分类器到权限隔离，大模型安全的分层防线｜本地模型红队测试入门：用 garak、PyRIT、promptfoo 与 Inspect 评估你自己部署的大模型

延伸阅读：模型泄露与破解传闻的核查方法