Hugging Face、Hub全体をGit LFSからXetへ——20PBの静かな大移行
AIモデルのホスティングプラットフォームとして世界最大規模を誇るHugging Faceが、Hubのストレージ基盤を従来のGit LFS（Large File Storage）から自社開発のXetへと移行完了したことを発表した。
移行の規模感
2025年1月に始まった移行プロジェクトは、わずか6ヶ月で以下の規模に達した。
- 移行済みリポジトリ数: 50万件超
- 移行データ量: 約20PB（ペタバイト）
- 利用ユーザー数: 100万人以上
- 報告されたGitHub Issue・フォーラム投稿: 数十件程度
これほどの規模の移行にもかかわらず、ユーザーからの問い合わせがほとんどなかったことは注目に値する。2025年5月には新規ユーザーおよび組織に対してXetがデフォルトストレージとして採用されている。
なぜGit LFSでは限界だったのか
Git LFSはもともとソフトウェア開発用に設計されたファイルサイズ拡張の仕組みであり、数百GBから数TB級のAIモデルファイルを大量に扱うユースケースには設計思想が合わなかった。Xetはこれに対して**コンテンツアドレス型ストレージ（CAS: Content Addressed Store）**を採用し、ファイルをチャンク単位で管理することで重複排除・高速転送・並列ダウンロードを実現している。
無停止移行を支えた2つの仕組み
移行の成功を支えたのは、以下の2つの内部コンポーネントだ。
1. Git LFS Bridge
旧来のhuggingface_hubやhuggingface.jsなど、Xet非対応のクライアントが既存のAPIエンドポイント（/resolve）にアクセスした際、BridgeがXet側のチャンクデータをS3から再構成し、通常のLFSプロトコルと同じ形式のプリサインドURLとして返す。つまり、クライアント側でアップデートなしにシームレスにXet対応リポジトリのファイルへアクセスできる。
2. バックグラウンドコンテンツ移行
非対応クライアントがファイルをアップロードすると、まずLFSストレージに保存され、その後バックグラウンドで自動的にXetへ移行される。この仕組みにより、「一斉切り替え（ハードカットオーバー）」を避け、既存ワークフローを壊さずに段階的移行が実現できた。
設計の哲学
チームが最初に定めた原則は明快だった。
- ハードカットオーバーは行わない
- XetとLFSファイルが1つのリポジトリに混在してよい
- 移行中もダウンロード・アップロードをロックしない
これはユーザーへの影響ゼロを最優先にした判断であり、結果として多くのユーザーが移行に気づかないまま恩恵を受けることになった。
技術スタックの補足
XetのクライアントライブラリはRust製で実装されており、hf-xetとして提供されている。Xet対応クライアントはファイルを**コンテンツ定義チャンキング（Content Defined Chunking）**で分割してアップロードし、ダウンロード時はCASからチャンク範囲情報を取得してS3から直接再構成する。ファイルメタデータの管理にはDynamoDBが使われている。
今後の展開
Hugging Faceはこの移行をまだ「始まり」と位置づけており、今後数週間・数ヶ月でさらに積極的な移行を進めるとしている。日本のAI開発コミュニティにも広く普及しているHugging Face Hubだけに、大規模モデルのダウンロード速度改善など実質的なメリットが今後より顕著になってくるだろう。