Baseten BDN Sealed Volumes: Versioned Model Weights and Deployment Limits

Baseten announced BDN Sealed Volumes on October 26, letting teams publish model weights and data once, then mount a version across deployments. Updates upload changed chunks rather than every byte again. For inference teams, the useful change is making the data a deployment serves as explicit as the code it runs.

The announcement focuses on immutable versions and consistent replicas. The documentation adds an important qualification: that consistency depends on pinning a content digest, rather than following a movable tag.

What a sealed volume contains

A BDN volume is a named collection of files with a series of versions. Publishing seals a snapshot and gives it a digest derived from its contents. Deployments mount the files read-only, so the serving process cannot edit that version in place.

The volume overview distinguishes immutable digests from tags such as prod. A tag is a convenient label pointing to a version, but its target can change.

Each replica resolves a tag when it starts and keeps that version throughout its lifetime. If the tag moves, existing replicas keep their old files while newly started replicas use the new target. One deployment can therefore serve two versions at once.

Pinning a digest avoids that ambiguity. Tags can remain useful names for humans, while the deployment configuration records the precise artifact that should run.

How this differs from existing BDN weight caching

Baseten already used BDN to mirror model weights and cache them near replicas. Its configuration guide now distinguishes the weights configuration from bdn.mounts for published volumes.

Workflow	Weight mirroring	BDN volumes
Input	An external source	A published file version
Sharing	Configured per deployment	Reused across deployments
Startup	Files download before container startup	Files stream as the model reads them
Version control	Pin the external source	Pin the volume digest

Weight mirroring remains supported. A team consuming someone else's repository may not need an extra publication step. Volumes become more useful when the team produces its own checkpoints or needs several services to consume the same set of files.

Streaming removes the requirement to fetch the whole volume before startup. It does not establish that the first prediction is instant: the model still needs the data it actually reads. The launch does not provide a universal cold-start improvement to apply to every workload.

Publishing and rolling back a version

For local files, baseten volume push publishes a directory. Baseten splits the data into chunks and avoids uploading unchanged chunks again. The saving therefore depends on how much the new artifact shares with the previous version, rather than a fixed reduction for every checkpoint.

The management guide explains that a digest-pinned deployment needs an explicit configuration update and redeployment to serve a new version. Rolling back follows the same principle: select the earlier digest and deploy it.

That makes the artifact change visible to code review. A release can identify both the application revision and the model-data revision, which is useful when investigating whether a regression came from serving code or a new checkpoint.

Retention also becomes operationally important. Deleting a version does not stop replicas already running, but new replicas depending on it can fail to start. A cleanup job should check deployment references before treating an older model version as unused.

Remote sources and availability

Baseten also documents background volume syncs. These copy supported remote sources into a sealed version without downloading them through the developer's machine. Sources include Hugging Face, major object stores and Baseten Training checkpoints.

A sync returning an identifier means the job was created, not that the artifact is ready. Deployment automation should wait for the completed result and use the version reference it returns.

The current BDN guide lists volume availability for all organizations, but excludes T4 and L4 GPUs. The overview permits CPU instances and other GPUs. The announcement and overview do not give a separate Sealed Volumes price table, so this should not be read as a promise of free storage or serving.

The main benefit is a clearer release boundary. Model data can be promoted, reviewed and rolled back as a specific artifact instead of an address whose contents might move. Teams get the most from that boundary when they pin it deliberately and keep the versions that production may still need.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders make infrastructure launches and engineering decisions understandable through clear technical writing and founder-led content.

Book a 30-minute call.