与 LFS 的向后兼容性

来自旧版 / 非 Xet 感知客户端的上传仍然遵循标准的 Git LFS 路径，即使该仓库已经由 Xet 提供支持。文件上传到 LFS 后，一个后台进程会自动将该文件迁移到使用 Xet 存储。Xet 架构通过提供 Git LFS 桥接，为从 Xet 支持仓库下载文件的旧版客户端提供了向后兼容性。Xet 感知客户端会从 CAS 接收文件重建信息以下载 Xet 支持的文件，而旧版客户端则会从桥接处获取一个单一 URL，该 URL 负责重建请求的文件并返回指向该资源的 URL。这允许通过 URL 下载文件，因此您可以继续使用 Hub 的 Web 界面或 curl。通过让 LFS 文件上传自动迁移，并让旧版客户端继续从 Xet 支持的仓库下载文件，维护者以及 Hub 的其他部分可以按照自己的节奏更新其流水线。

Xet 存储为现有的 Hub 仓库提供了无缝的过渡体验。用户完全无需了解 Xet 后端是否参与其中。由 Xet 支持的仓库将继续使用 Git LFS 指针文件格式；Xet backed hash 的添加仅作为便利功能显示在 Web 界面上。实际上，这意味着如果您对这些仓库执行 bare clone，现有仓库和新创建的仓库在外观上将没有任何区别。每个大文件（或二进制文件）将继续拥有一个符合 Git LFS 指针文件规范的指针文件。

这种对称性使得不支持 Xet 的客户端（例如 huggingface_hub 的旧版本）也能与基于 Xet 的仓库进行交互，而无需担心兼容性问题。实际上，在一个仓库中，Git LFS 和 Xet 支持的文件可以混合存在。Xet 后端会指示文件是存储在 Git LFS 还是 Xet 存储中，从而允许下游服务从 S3 请求正确的 URL，无论内容实际由哪个存储系统持有。

旧版存储：Git LFS

Hub 上的传统存储系统 Git LFS 采用了与 Xet 支持的仓库相同的许多约定。Hub 的 Git LFS 后端是 Amazon Simple Storage Service (S3)。当调用 Git LFS 时，它会使用 SHA256 哈希值作为文件名，将文件内容存储在 S3 中，以便日后访问。这种存储架构相对简单，使 Hub 能够存储数百万个模型、数据集和空间仓库的文件。

Git LFS 的主要局限在于其以文件为中心的重复数据消除方式。对文件的任何更改，无论改动是大是小，都会导致整个文件被纳入版本控制——这会在文件传输中带来显著的开销，因为提交到仓库时需要上传整个文件，而拉取最新版本到本地时则需要下载整个文件。

这会导致更差的开发体验，并带来额外存储的激增。

Update on GitHub