Hugging Face Hub 从 Git LFS 迁移到 Xet

Hugging Face 已将 500,000 个仓库和 20 PB 数据从 Git LFS 迁移到 Xet，这是一种为 AI 开发者的大规模数据需求而设计的新存储后端。此转变实现了更快的传输和更好的可扩展性，且无需用户更改现有工作流。

通过 Git LFS Bridge 实现无缝向后兼容

为了避免“硬切换”并将用户中断降至最低，Hugging Face 实现了一个系统，使启用 Xet 的仓库可以同时包含 Xet 和 LFS 文件。此兼容性的核心是 Git LFS Bridge，它确保使用旧客户端的用户仍能与基于 Xet 的文件交互。

Git LFS Bridge 的工作原理

当非 Xet 感知客户端（例如旧版本的 huggingface_hub 或 huggingface.js）通过 resolve 端点请求文件时，Git LFS Bridge 会：

  1. 构建并返回一个模拟 LFS 协议的预签名 URL。
  2. 从存放在 S3 中的内容重建文件。
  3. 将重建后的文件返回给请求者。

Xet 感知客户端工作流

感知 Xet 的客户端（例如 hf-xet 或 huggingface_hub 中的 Xet 集成）会绕过桥接，直接使用完整的 Xet 堆栈：

  • 上传： 文件使用内容定义的分块方式拆分为块，传递给内容寻址存储（Content Addressed Store，CAS），并存储在 S3 中。
  • 下载： 客户端请求文件重建信息，并通过 CAS 从 S3 检索特定块范围。

背景迁移流程

Hugging Face 使用后台迁移流程将数据从 LFS 移动到 Xet，无需锁定仓库，也不会中断活跃的上传和下载。

当文件被迁移时，Webhook 会触发由 orchestrator 处理的分布式队列。该 orchestrator 在仓库上启用 Xet，获取 LFS 修订，并将文件批量化为作业（每批 1,000 个文件或 500 MB）。迁移工作节点随后下载 LFS 文件，并使用 xet-core 将其上传至 Xet CAS。

可扩展性挑战与性能提升

在对大规模高价值用户进行迁移时——包括跨 42,000 个仓库、数据量高达 6.1 PB 的用户——Hugging Face 识别并解决了若干技术瓶颈：

  • 磁盘空间： 修复了全局去重的临时分片文件写入到与 Xet 缓存不同挂载点的 /tmp，导致 No space left on device 错误的问题。
  • 资源分配： 调整 CAS 大小以处理迁移工作节点的突发上传，这与在大型模型发布（如 Llama 4）期间常见的突发下载模式不同。
  • I/O 瓶颈： 升级工作节点规格，以解决网络和 EBS I/O 瓶颈。

CAS 吞吐量改进

通过这些优化，内容寻址存储（CAS）的吞吐量显著提升：

  • 初始迁移： 持续约 35 Gb/s（加上约 5 Gb/s 的常规 Hub 流量）。
  • 最新迁移： 峰值约 300 Gb/s，同时承载约 40 Gb/s 的基线负载。

未来路线图与可用性

截至 2025 年 7 月，Xet 已成为新用户和组织的默认选项。Hugging Face 正在将 Xet 访问权限扩展至所有用户，这包括将所有现有仓库从 LFS 自动迁移到 Xet。

即将推出的功能包括：

  • 基于块的支持，用于浏览器上传/下载以及 Git。
  • 开源 Xet 协议及整个基础设施堆栈。

Sources