Hugging Face Xet対応リポジトリ：ブロックレベルの集約によるHub転送の高速化

Hugging Faceは、xet-coreとhf_xetを活用した新しいチャンクベースの重複排除システムを導入しています。これにより、Hubでのファイルのアップロードとダウンロードを、場合によっては2〜3倍高速化します。このシステムは、従来のファイル中心の転送から、コンテンツベースのストレージ（CAS）モデルへと移行し、AI開発者の迅速な反復作業をサポートするためにデータの移動と保存方法を最適化します。

ブロックレベルの集約による重複排除のスケーリング

200万件のリポジトリにまたがり、約45PBのデータをホストするHugging Face Hubの規模では、純粋なチャンクベースの重複排除は現実的ではありません。なぜなら、CAS内に数十億もの個別のエントリが作成されてしまうからです。チャンク（平均約64KB）のみを使用する単純なアプローチでは、約6,900億個のチャンクが生成され、数百万件の個別のリクエストによる持続不可能なネットワークオーバーヘッドや、S3やDynamoDBなどのサービスにおけるメタデータ管理の膨大なインフラコストが発生します。

これを解決するために、Hugging Faceは**集約（aggregation）**を採用し、通信とストレージの戦略がチャンクの数に対して1:1でスケールしないようにしています。

• Blocks（ブロック）: 重複排除後、データは最大64MBのブロックにまとめられます。これらのブロックはコンテンツベースの管理を維持しており、CASのエントリ総数を1,000分の1に削減します。
• Shards（シャード）: シャードはファイルをチャンクにマッピングし、それらを含むブロックを参照します。これにより、システムはファイルの特定の変更箇所を特定し、すでにCASに存在するチャンクの転送をスキップできます。

キーチャンクと空間的局所性による転送の最適化

アップロード中にすべてのチャンクに対してネットワーククエリを実行することを避けるため、Hugging Faceは**キーチャンク（key chunks）**を使用しています。キーチャンクは、チャンクハッシュに基づく剰余条件によって選択された、全チャンクの0.1%のサブセットです。

これらのキーチャンクとそれらが存在するシャードのグローバルインデックスを保持することで、キーチャンクがクエリされた際に、関連するシャードを取得できます。これは、同じシャード内で参照されるチャンクは類似している可能性が高いという**空間的局所性（spatial locality）**を活用しています。このメカニズムにより、チャンクがすでにアップロードされているかを確認するために必要なネットワークおよびデータベースのリクエスト数が大幅に削減されます。

量子化モデルへのパフォーマンスへの影響

量子化モデル（.ggufファイルなど）は、量子化の性質上、このシステムの主な恩恵を受けます。量子化は重み行列の値を小さな整数範囲に制限するため、異なる量子化バリアント（例：Q4_K, Q3_K, Q5_K）の間で高い反復性と重複が生じます。

合計191GBの29種類の量子化を含むbartowski/gemma-2-9b-it-GGUFリポジトリを使用した実証テストでは、Xet対応のアプローチにより顕著な効率向上が示されました。

• ストレージ削減: 1,515個のユニークなブロックのみを保存することで、リポジトリのサイズは191GBから約97GBに削減されました（約94GBの節約）。
• アップロード速度: 転送速度50MB/sにおいて、アップロード時間は509分から258分に短縮され、約2倍の高速化を実現しました。
• ダウンロード効率: ローカルチャンクキャッシュにより、ファイルが更新されたり新しい量子化が追加されたりしても、変更されていないチャンクはダウンロードされません。これは、ファイル全体をダウンロードする必要があるファイルベースのアプローチとは異なります。

利用可能性

Hugging Faceは、今後数週間から数ヶ月の間に最初のXet対応リポジトリを順次展開し、Hub上のすべての開発者にとってファイル転送が「意識されないもの（invisible）」にすることを目指しています。