Why the Hub’s file transfers needed a redesign

The Xet team examined the gap between web-content delivery and the enormous files used in machine learning.

Source artwork for Rearchitecting Hugging Face Uploads and Downloads
Source artwork · Hugging Face / credited contributors ↗
THE SHORT VERSION

Moving AI artifacts efficiently requires treating them differently from ordinary website assets.

Hugging Face’s transfer-design article explained why its existing upload and download infrastructure was being reconsidered. Models and datasets can exceed the assumptions built into conventional delivery systems. File-size limits, global access patterns, and opportunities for deduplication all shaped the redesign.

The distinction is not simply between fast and slow downloads. A storage protocol determines what must be transferred when related files change, how requests are scheduled, and which bottlenecks appear at scale. Those decisions become visible to everyone who repeatedly pushes checkpoints or dataset revisions.

Read this as an engineering explanation of the system’s constraints. Pair it with the later Xet launch rather than assuming every proposed mechanism was already active when the article appeared.

Artifact distribution becomes part of the research bottleneck

As model and dataset files grow, transferring them can consume a meaningful part of an experiment’s time and bandwidth. Repeating complete transfers for related versions adds waste, while interrupted uploads or downloads can leave workflows in uncertain states.

A redesigned transfer system is useful when it improves those practical conditions while preserving a simple promise: a named artifact revision resolves to the intended content. Users should not need to understand every storage detail to know whether a model is ready to load.

Separate the workloads

A first download, a repeated download and an update to a partially changed artifact are different cases. Measure them separately. A cache-friendly result can be valuable without representing the experience of someone accessing the files for the first time.

Include real network conditions and representative file types. Large binary weights and many smaller metadata files can stress different parts of the transfer path. The overall application needs both to arrive correctly.

Make completion unambiguous

A progress bar reaching the end of a network transfer should not be the only signal that the artifact set is usable. Verify required files and preserve revision identity. A partially available model can produce confusing downstream errors that appear unrelated to storage.

For uploads, distinguish a request being accepted from the repository state being complete. Automated publishing should confirm the resulting files rather than reporting success merely because a process started.

Design for recovery

Interrupt a transfer deliberately in a test environment and inspect the retry behaviour. A good recovery path should avoid unnecessary repeated work where possible and should not leave corrupted content appearing valid.

Keep caches disposable. Users can clear them, machines can change and local state can be lost. The workflow should remain correct even when it must reconstruct everything from the remote source.

Measure readiness, not only bandwidth

After transfer, the application may still decompress, map or initialize the model. Record the time until useful computation can begin. Improving network efficiency can reveal another bottleneck, which is a reason to update the measurement rather than to assume the transfer improvement failed.

The broader benefit of better artifact transport is less duplicated infrastructure work. Researchers and developers can rely on a shared versioned distribution path instead of inventing special handling for every large checkpoint. The successful design combines efficiency with correctness, clear completion and recoverable interruption so that moving model data becomes an ordinary dependable step in the workflow.

Source: Rearchitecting Hugging Face Uploads and Downloads · port8080, jsulz, erinys. How we write

← Back to all articles