Hugging Faceは2026年3月10日、Hub向けStorage Bucketsを発表した。これはmodel repoやdataset repoのようなversioned artifact配布用の場所ではなく、checkpoint、optimizer state、processed shard、log、traceなど、頻繁に変化するintermediate ML artifactを保存するためのmutableかつnon-versionedなobject storage層である。

なぜ別のstorage層が必要なのか

Hugging Faceは、Gitベースのrepoは最終成果物の公開には向いている一方で、何度も上書きされ複数jobから同時に書き込まれる高変動データには向かないと説明する。Storage Bucketはそのギャップを埋めるS3-like storageで、userまたはorganization namespace配下に置けて、hf://buckets/... 形式でprogrammatic accessもできる。

基盤にはHugging Faceのchunk-based backendであるXetが使われている。Hugging Faceによると、Xetはファイルをchunkに分割して重複部分をdeduplicateするため、似たdatasetやsuccessive checkpointのuploadで既存byteを再送せずに済む。これによりbandwidth削減、転送高速化、storage効率向上が見込めるという。Enterpriseでは課金もdeduplicated storage基準だ。

運用機能とworkflow統合

Storage BucketsはAWSとGCPを対象にpre-warmingも提供する。これはcomputeが動くcloud regionの近くへhot dataを前もって寄せる仕組みで、distributed trainingや大規模pipelineのthroughput改善を狙うものだ。さらにHugging Faceは、この機能をhf CLI、Pythonのhuggingface_hub、JavaScriptの@huggingface/hub、fsspec互換filesystemに接続している。

そのためBucketsは単なる一時保管先ではなく、training、data processing、agent trace保存、最終公開までをHub内でつなぐための基盤と位置づけられる。Hugging Faceは将来的にBucketとversioned repoの直接移動もサポートするとしており、working layerとpublishing layerを一つの流れにしたい考えだ。

なぜ重要か

今回の発表はインフラ寄りだが、Hugging Faceがmodel hostingを超えてML運用のstorage substrateまで広げようとしている点で戦略的な意味がある。特にagent trace、memory、shared knowledge graphを明示的に例示したことから、同社がLLM applicationの運用状態そのものをstorage課題として見ていることが分かる。Hubをすでに使うチームにとって、Bucketsが想定どおり機能すれば、artifactを外部object storageへ分散させる必要は減るかもしれない。

もっとも普及の速度は、大規模transfer性能、pre-warmingの実効性、そしてHub-native workflowが既存のGit repoと外部object storageの組み合わせより本当に単純かどうかに左右される。

Source: Hugging Face

#xet

Hugging Face、HubにStorage Bucketsを導入 Xet基盤のS3型ML artifact保管層