Hugging Face Hub の Git LFS から Xet への移行

Hugging Face は、AI 構築者の膨大なデータ要件に対応できるよう設計された新しいストレージバックエンドである Xet に、Git LFS から 500,000 のリポジトリと 20 PB のデータを移行しました。この移行により、ユーザーが既存のワークフローを変更することなく、転送が高速化し、スケーラビリティが向上します。

Git LFS ブリッジによるシームレスな下位互換性

「ハードカットオーバー」を回避し、ユーザーへの影響を最小限に抑えるため、Hugging Face は Xet 対応リポジトリが Xet と LFS の両方のファイルを保持できるシステムを実装しました。この互換性の中心となるのが Git LFS Bridge で、古いクライアントを使用しているユーザーでも Xet バックエンドのファイルにアクセスできるようにします。

Git LFS ブリッジの仕組み

非 Xet 対応クライアント（例: 古いバージョンの huggingface_hub や huggingface.js）が resolve エンドポイントを介してファイルを要求すると、Git LFS Bridge は次の処理を行います：

単一のプリサインド URL を構築し、LFS プロトコルを模倣して返します。
S3 に保存されているコンテンツからファイルを再構築します。
再構築されたファイルをリクエスターに返します。

Xet 対応クライアントのワークフロー

Xet 対応クライアント（例: hf-xet や huggingface_hub の Xet 統合）はブリッジをバイパスし、完全な Xet スタックを使用します：

アップロード: ファイルはコンテンツ定義型チャンク分割でチャンクに分割され、Content Addressed Store（CAS）に渡され、S3 に保存されます。
ダウンロード: クライアントはファイル再構築情報を要求し、CAS を介して S3 から特定のチャンク範囲を取得します。

背景移行プロセス

Hugging Face は、リポジトリのロックやアクティブなアップロード・ダウンロードを中断することなく、LFS から Xet へデータを移行するバックグラウンド移行プロセスを利用しています。

ファイルが移行されると、Webhook がオーケストレータによって処理される分散キューをトリガーします。オーケストレータはリポジトリで 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 スループット改善

これらの最適化により、Content Addressed Store（CAS）のスループットが大幅に向上しました：

初期移行: 約 35 Gb/s を維持（通常の Hub トラフィックは約 5 Gb/s）。
最新の移行: ベースライン負荷約 40 Gb/s を処理しながら、ピークで約 300 Gb/s に達しました。

今後のロードマップと提供状況

2025 年 7 月時点で、Xet は新規ユーザーおよび組織のデフォルトとなっています。Hugging Face は現在、すべてのユーザーへの Xet アクセスを拡大しており、既存のすべてのリポジトリを LFS から Xet へ自動的に移行することが含まれます。

今後の開発には以下が含まれます:

チャンクベースのサポート（ブラウザベースのアップロード/ダウンロードおよび Git 用）。
Xet プロトコルと全インフラストラクチャスタックのオープンソース化。