与 LFS 的向后兼容

旧版 / 非 Xet 感知客户端在上传时，依然会沿用标准的 Git LFS 流程，即便仓库已经启用了 Xet。文件上传到 LFS 后，后台进程会自动将其迁移到 Xet 存储。
Xet 架构通过提供 Git LFS 桥，为从 Xet 仓库下载文件的旧版客户端提供向后兼容能力。 Xet 感知客户端会从 CAS 获取文件重建信息，以下载 Xet 存储的文件；而旧版客户端会从桥接服务获得一个 URL，该服务负责重建请求的文件并返回资源地址。
这样就可以通过 URL 下载文件，继续使用 Hub 的网页界面或 curl。凭借自动迁移 LFS 上传文件，以及让旧客户端继续从启用 Xet 的仓库下载文件，维护者和社区的其它用户可以按自己的节奏更新流程。

Xet 存储为现有 Hub 仓库提供了平滑的过渡。 实际上，你不必关心是否启用了 Xet 后端。启用 Xet 的仓库仍然使用 Git LFS 指针文件格式；新增的 Xet backed hash 仅在网页界面上作为便利信息显示。 实操上，这意味着现有仓库与新建仓库在执行 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 时，它会将文件内容存放在 S3 中，并以文件内容的 SHA256 哈希作为文件名。 该存储架构相对简单，帮助 Hub 存储了数百万个模型、数据集与 Space 仓库文件。

Git LFS 的主要限制在于其以文件为中心的去重方式。 只要文件发生变动，无论变动大小，整个文件都会产生新版本——这意味着在上传（提交到仓库）或下载（在本地拉取最新版本）时需要传输完整文件，造成较大的传输开销。

这既带来开发体验的下降，也会显著增加额外的存储占用。