Hugging Face 收购 XetHub：告别 Git LFS，千亿模型改参数不用重传

想象一下，你精心整理了一个 10GB 的 Parquet 数据集，后来发现漏了一条记录。你补上这一行，然后不得不把整整 10GB 的大文件重新上传一遍。

改一个字母，传十个 G，这就是目前在 Hugging Face 上折腾模型和数据的人每天都在忍受的荒诞现实。

Hugging Face 宣布收购西雅图初创团队 XetHub，要把自家的底层存储彻底换掉。这家只有 12 个人的团队，此前一直在琢磨怎么把 Git 扩展到可以支撑 TB 级仓库的数据协作平台。

治好 Git LFS 的大模型综合征

问题出在底层的 Git LFS 上。

据 Hugging Face 首席技术官 Julien Chaumond 回忆，2020 年搭建 Hugging Face Hub 时，团队为了快速跑通业务，选择了业界最通用的 Git LFS 作为大文件存储后端。但他坦言，Git LFS 虽然名字带「大文件」，但从来就不是为了今天动辄几十 GB、几百 GB 的 AI 权重设计的。

在现有的 Git LFS 机制下，文件只要发生一点变动，系统就必须当成一个全新的文件完整重传。

XetHub 带来的解法是基于数据块的分块切片和去重技术。接入这套系统后，那个 10GB 的文件即便加了一行，你也只需要上传包含这行增量的几个数据块。

模型微调和量化爱好者也会省下大量时间。比如社区开发者给 Llama 3.1 405B 的 GGUF 格式文件修改模型头部的元数据，过去要折腾半天，未来只要重新上传几 KB 大小的单个分块就行。

每天烧掉 6PB 带宽背后的数字

Hugging Face 选在这个节点动手，很大程度上是因为 Hub 的体量已经膨胀到了物理极限。

官方公布了一组相当惊人的数据。目前 Hub 上托管了 130 万个模型、45 万个数据集和 68 万个 Spaces 演示应用。通过 Git LFS 存储的总数据量达到了 12PB，包含了 2.8 亿个大文件，而纯文本等非 LFS 存储其实只有 7.3TB。

更夸张的是流量消耗。Hub 目前每天要响应 10 亿次请求，每天消耗的 CloudFront 网络带宽高达 6PB。

XetHub 的三位联合创始人 Yucheng Low、Ajit Banerjee 和 Rajat Arya 此前都在苹果负责内部机器学习基础设施建设。Yucheng Low 过去把 GraphLab 卖给苹果后，曾在苹果内部管理超过 100PB 的 AI 数据，支撑过内部几十个团队每年上线数百个功能。

随着社区开始出现万亿参数规模的开源模型，如果还抱着老旧的 Git LFS 不放，Hugging Face 的服务器带宽和开发者的上传进度条迟早会一起崩掉。

为什么重要

对于开源社区和开发者来说，这项收购的价值非常直观。不论是个人开发者微调量化模型，还是企业团队维护动态扩充的训练集，都不用再为了一点小改动而反复等待漫长的上传和下载。AI 的版本迭代终于能像写现代软件那样，只拉取和提交增量差分。

对行业而言，开源模型的参数竞赛正在从几百亿冲向万亿。文件越来越大，传统的软件分发机制完全跟不上节奏。Hugging Face 通过这次收购，实际上是在把自家的护城河从单纯的「模型社区」延伸到「AI 原生版本控制底层」。如果这套增量存储跑顺了，其他想要挑战 Hugging Face 平台地位的对手，在开发者体验和基础设施成本上的差距会被进一步拉开。

我们认为 Hugging Face 这步棋走得非常聪明。收购一个成熟且在苹果打过硬仗的小团队，比自己从零重写一套分布式去重存储要稳妥得多。不过这也有一层隐患：把 12PB、近三亿个历史文件的后端平滑迁移到新架构上，工程复杂度极高。新旧协议的兼容、客户端工具链的适配，以及企业版私有化部署的平稳过渡，看起来都需要很长时间去消化。