分析：为什么BT种子特别适合分发AI模型

为什么说 torrent 天生适合模型分发。

DeepSeek 的 DeepSeek-V4.1-Flash-1017 由 48 个 safetensors 分片加上配置和 tokenizer 组成，总共 510 GB。一旦发布，这些文件就不再变动，每个想运行这个模型的人下载到的都是同样的字节。正因如此，torrent 天生适合模型分发。

电影就不一样了。在 torrent 站点搜一部电影，你会看到 4K remux、1080p、720p，还有带不同音轨和字幕的各种版本。每个版本都是一个独立的 torrent，受众被分散成许多个小 swarm。大多数人随便挑一个能播的就行，但没人会这样下载模型：想要 DeepSeek-V4.1-Flash-1017 的人，要的就是同样的那 48 个分片。

要理解这件事为什么重要，得先看看 torrent 这个名字是怎么来的。每个 torrent 都以其内容的哈希命名。无论谁用相同的文件和设置制作 torrent，得到的哈希都是一样的。

最早的 v1 格式（BEP 3）把文件首尾相接串起来，切成同样大小的块，用 SHA-1 为每一块计算哈希，再把这些哈希连同文件名和块大小一起放进一个叫 info dictionary 的结构里。这个字典的 SHA-1 就是一个 40 位的十六进制字符串。

后来的 v2 格式（BEP 52）对模型分发更友好。它不再把文件拼接在一起，而是为每个文件单独构建一棵 Merkle 树：每个 16 KiB 数据块用 SHA-256 哈希，然后两两合并继续计算，直到每个文件只剩一个根哈希。

文件按列出的顺序首尾相接，然后切块。改变顺序，块和哈希都会变。 根 A model-00002.safetensors根 B config.json根 C 每个文件都有自己的 Merkle 树和根哈希，与文件顺序无关。

混合 torrent 在同一份 info dictionary 里同时携带两套哈希，因此 v1 和 v2 客户端可以留在同一个 swarm 里。

magnet:?xt=urn:btih:be10fee246b1e7845113eb99bdddf1d8f242043e&xt=urn:btmh:1220796d0cd21715ec2b5f02fb26af84293ec93c2ec1d1c0b83c44228a4cff0d2762Magnet 链接v1 torrentv1 哈希 · SHA-1 · 40 位十六进制v2 torrent · 12 = SHA-256，20 = 32 字节v2 哈希 · SHA-256 · 64 位十六进制 互相找到对方：tracker 与 Model DHT 即使有了共同的名字，下载者仍然需要找到彼此。最简单的办法是问 tracker。tracker 是一台服务器：你问它“还有谁有 be10fee2……？”，它告诉你哪些节点在分享。每个 Pirate Face 的 magnet 链接都附带 udp://tracker.pirateface.co:6969/announce。

Model DHT 是一个分布式哈希表，无需依赖中心服务器也能回答同样的问题。它是一张散落在数百万 torrent 客户端上的表。你可以用 torrent 的哈希找到正在分享这个 torrent 的节点。

查找时，客户端先询问它已知的、离目标最近的节点，这些节点再告诉它更近的节点。即使网络中有数百万个节点，也只需几步就能找到。

早期的互联网也经历过类似阶段。先有 Yahoo! 这样的手工目录，然后有 AltaVista 这样的全文搜索。直到 1998 年 Google 开始按网页之间的链接排序，大多数人才真正有了找东西的办法。Model DHT 能帮你找到节点，但并没有一个首页告诉你该去找哪个 torrent。

Pirate Face 可以成为你通往 Model DHT 的首页：每个模型版本都有一个经过验证的 torrent，外加一个 tracker 和实时的 swarm 数据。