DeepSeek 的 DeepSeek-V4.1-Flash-1017 由 48 个 safetensors 分片加上配置和分词器组成，一共 510 GB。发布之后，这些文件就不会再变，每个想运行这个模型的人下载的都是同样的字节。正因为如此，torrent 完美适合模型分发。
电影就不一样了。在 torrent 网站上搜一部电影，你会看到 4K remux、1080p、720p，还有各种音轨和字幕的版本。每个版本都是一个单独的 torrent，观众被分散到许多小的 swarm 里，大多数人随便挑一个能播放的就行，但没有人这样下载模型：要 DeepSeek-V4.1-Flash-1017 的人，要的都是同样的 48 个分片。
- 电影：很多版本，每个都有自己的 torrent 哈希和小节点群
- 模型版本：一组字节，一个 torrent 哈希，一个节点群
名字来自内容
要理解这为什么重要，得先看 torrent 的名字从哪里来。每个 torrent 都用它内容的哈希来命名。无论谁用同样的文件和设置来制作 torrent，得到的哈希都一样。
最早的 v1 格式（BEP 3）把所有文件首尾相接，切成同样大小的分块，用 SHA-1 给每一块算哈希，再把这些哈希连同文件名和分块大小放进一个叫 info 字典的结构里。这个字典的 SHA-1 是一个 40 位的十六进制字符串。
- 文件被切成固定大小的分块
- 每个分块都被哈希
- 哈希、文件名和分块大小组成 info 字典
- info 字典的 SHA-1 就是 torrent 哈希
- 改动一个字节，torrent 哈希就完全不同
后来的 v2 格式（BEP 52）对模型分发来说还要更好。它不再把文件连在一起，而是给每个文件单独建一棵 Merkle 树：每 16 KiB 的数据块用 SHA-256 算哈希，再两两合并继续算，直到每个文件只剩下一个根哈希。
文件按列出的顺序首尾相接，再切成分块。换一个顺序，分块和哈希都会变。
- model-00001.safetensors
根哈希 A - model-00002.safetensors
根哈希 B - config.json
根哈希 C
每个文件有自己的 Merkle 树和根哈希，与文件的顺序无关。
Hybrid torrent 在同一个 info 字典里同时带有这两套哈希，所以 v1 和 v2 客户端可以待在同一个 swarm 里。
找到彼此：tracker 和 Model DHT
即使有了共同的名字，下载的人仍然需要找到彼此。最简单的办法是去问一个 tracker。tracker 是一台服务器：你问它"谁还有 be10fee2…？"，它就会告诉你哪些节点正在分享。每个 Pirate Face 磁力链接都带有 udp://tracker.pirateface.co:6969/announce。
Model DHT（一种分布式哈希表）不靠中心服务器也能回答同样的问题。它是一张分散在数百万个 torrent 客户端上的表，用 torrent 的哈希就能查到正在分享这个 torrent 的节点。
- 向已知最近的节点询问 torrent 哈希
- 它回复 ID 更近的节点（异或距离）
- 重复：每一跳与目标共享更多前导位
- 最近的节点返回节点地址
- 向它们宣告，下一个客户端就能找到你
查找的时候，客户端先问它认识的、离目标最近的节点，这些节点再告诉它更近的节点。即使网络里有数百万个节点，也只需要几步就能找到。
实时 · tracker 此刻检查
Model DHT 的首页
早期的网络也经历过类似的阶段。先是 Yahoo! 这样的人工目录，然后是 AltaVista 这样的全文搜索，直到 1998 年 Google 开始按网页之间的链接排序，大多数人才真正有了找东西的办法。Model DHT 能帮你找到节点，却没有一个首页告诉你该找哪个 torrent。
Pirate Face 可以成为你通往 Model DHT 的首页：每个模型版本一个校验过的 torrent、一个 tracker 和实时的 swarm 数据。