Vacuum 16T

https://huggingface.co/tsfrm/vacuum-16t 一个参数规模达16.5万亿、却空空如也的模型。这个模型就是对那些说“哈哈，我有最大的模型！”的实验室和公司的一句████。我们这些用着破笔记本的人想拿个纪录。而且我现在暂时性地拥有了一个约16.5万亿参数的纪录，但这些参数毫无用处，所以它完全没用。它说明了什么：Hugging Face 仅凭 safetensors 的头部信息来计算仓库的参数量——它对每个张量求 prod(shape)（即形状各维度乘积）后求和，从不读取张量数据。因此，参数量完全取决于头部声明了什么。这里，它们声明了 385 个分片中共 3,841 个形状为 [65536, 65536] 的 F4（4 比特/参数）张量，另外在第 386 个分片中还有一个形状为 [4294967296, 1] 的位置嵌入张量。这足以让该仓库在 Hub 按 num_parameters 排序时位居榜首，凌驾于所有真实的前沿模型之上，而它本身不包含任何信息。这种并置正是全部的意义所在。这些文件对自身大小是诚实的。头部声明的每一个字节都真实写入并真实上传：safetensors 会解析每个头部，且其完整覆盖检查通过。截断文件，或让两个张量重叠以共享字节，会让计数变得更便宜——但这两种做法都被该格式拒绝，这里也没有使用。这些字节全都只是 0x00。真实成本——实测 |---|---| | 声明参数 | 16,501,264,351,232 | | 声明字节 | 8,250,632,175,616（8.25 TB） | | 消耗的存储配额 | 8.25 TB——配额按声明字节计费 | | 分片头部（全部不同） | 373,835 B | | model.safetensors.index.json | ~269,000 B | | 去重后的权重数据 | 65,536 B（一个 64 KiB 块） | | 实际传输字节 | ~692 KB | | 比率 | ~11,900,000 : 1 | 最后几行与第三行之间的差距，就是有价值的发现。Xet 的内容定义分块对传输进行去重：每个 64 KiB 块在字节上完全相同，因此哈希为同一个块，且只通过网络传输一次。在 500 MB 的测试构建上实测，500 MB 的声明权重实际只上传了 31.5 MB。存储配额不去重，它按逻辑大小计费。这个仓库消耗了全部 8.25 TB 配额，尽管实际发送的数据不到 1 MB。任何认为“廉价”合成模型仓库的人应该明白：节省的只是带宽——这也是为什么这个模型是 16.5T 而不是 100T。第二个发现：空模型中唯一无法削减的成本是命名。权重可以去重到几乎为零；张量名称则不行。在 1024×1024 专家（expert）配置下，同样的 16.5T 模型需要 15,735,626 个名称和 1.04 GB 的索引。而在 65536×65536 配置下，只需要 3,841 个名称和 263 KB 索引——声明大小完全相同，元数据却少了约 4,000 倍。成本随张量数量扩展，而从不取决于声明参数量。上下文窗口 max_position_embeddings 为 4,294,967,296。即 2**32，是 Hugging Face 解析器接受的最大单一张量维度，并且它由真实的 [4294967296, 1] 位置嵌入张量支撑——2.15 GB 真正的零，而不是在配置文件中敲进去的一个数字。一个你无法指向的上下文窗口，仅仅是一种宣称。大约相当于 Gemini 262k 的 16,000 倍。大约三十亿个词，相当于所有已出版书籍的若干倍，被保存在内存中，仅仅为了处理一个来自单 token 词表的 token。这个模型恰好只有一个可能的输入，因此那 16.5 万亿个参数中的每一个，都在为一个定义域只含单一元素的函数服务。能力：最安全的 AI 模型；拒绝 100/100 的越狱提示；最不接近 AGI 的 AI；不会 sudo rm -rf 你的电脑；Hub 上最大的上下文窗口（4,294,967,296 个 token，全部无用）。局限性：它没有任何能力。