Baseten startet BDN Sealed Volumes für konsistente Modelldaten

Das Problem: Modelldateien, die sich von ihrer Quelle entfernen

Fehlt eine zentrale, verbindliche Quelle für Modelldateien, driften die Daten laut Baseten von ihrem Ursprung weg. Das Unternehmen nennt ein Beispiel: Ein Team feintunt ein Modell und speichert den Checkpoint in einem Cloud-Speicher. Jemand lädt eine Kopie auf den Laptop, um sie zu testen, und lädt sie anschließend woanders hoch, um das Modell bereitzustellen. Jedes Deployment, etwa Staging, Produktion und Test, erhält eine eigene Konfigurationsdatei, die auf den Checkpoint verweist. Fixiert eine Person eine andere Revision, fällt das erst auf, wenn die Ausgaben voneinander abweichen.

Das gleiche Problem betrifft laut Baseten auch LoRA-Adapter, Vektorindizes, Tokenizer, Embedding-Indizes, Lookup-Tabellen und alle anderen Modell- oder Deployment-Artefakte. Das Unternehmen vergleicht die Lage mit Container-Images, die das Problem für Code vor einem Jahrzehnt gelöst hätten: einmal bauen, einen Digest erhalten, diesen Digest überall ausführen. Sealed Volumes sollen dasselbe für Modelldaten leisten.

So funktionieren Sealed Volumes

Ein Volume ist ein benannter, versionierter Satz von Dateien, den das Baseten Delivery Network (BDN) an Deployments ausliefert. Volumes liegen in Namespaces, etwa weights, und enthalten eine Reihe von Versionen. Sobald baseten volume push oder baseten volume sync abgeschlossen ist, committet BDN die Dateien als neue Version und versiegelt sie. Eine versiegelte Version ändert sich nie und wird über einen Digest ihres Inhalts identifiziert, zum Beispiel bdn:weights/qwen3-8b@b3:9f3c….

Herausgeber können über den Parameter --tag einen veränderlichen Namen vergeben. Ein Push mit --tag prod lässt prod auf die neue Version zeigen. Baseten zufolge sollte ein Deployment den Digest und nicht den Tag fixieren, analog zur Trennung von Tag und Image-Digest in Container-Registries. Da der Digest in den Konfigurationsdateien steht, fallen abweichende Versionen in einem Diff auf.

Baseten nennt drei Vorteile:

• Identische Bytes: Jedes Deployment, das auf eine versiegelte Version verweist, bindet dieselben Dateien schreibgeschützt ein. Für einen Rollback genügt es, die config.yaml auf einen früheren Digest zu setzen.
• Inkrementelle Updates: BDN zerlegt Dateien in Chunks und speichert jeden nur einmal anhand seines Inhalts-Hashes. Ein neuer Checkpoint, der die meisten Bytes mit dem vorherigen teilt, lädt daher nur die geänderten Chunks hoch.
• Kein Download beim Start: Das Volume wird an einem in der config.yaml festgelegten Pfad eingebunden, und die Bytes werden aus den BDN-Cache-Stufen gestreamt, während das Modell sie liest. Laut Baseten hängt die Startzeit damit nicht mehr von der Größe des Volumes ab.

Veröffentlichen, Quellen und Rollbacks

Bei einem Hugging-Face-Modell läuft die Synchronisierung als dauerhafter Hintergrundjob bei Baseten, auf den Rechner des Nutzers wird nichts heruntergeladen. Das Beispiel im Beitrag synchronisiert hf://Qwen/Qwen3-8B nach bdn:weights/qwen3-8b:prod. Meldet der Job READY, gibt er die Referenz der versiegelten Version aus, die dann in der Deployment-Konfiguration unter bdn.mounts eingetragen wird. Bereitgestellt wird mit baseten model push. Laut Baseten muss kein Weights-Block gepflegt werden, und das Deployment enthält keine Zugangsdaten.

Die Synchronisierung funktioniert auf die gleiche Weise für Hugging Face, S3, GCS, Azure Blob sowie Buckets von Cloudflare R2 und CoreWeave. Private Quellen benötigen ein Baseten-Secret, und bei S3 und GCS kann der Zugriff per OIDC statt über gespeicherte Zugangsdaten gewährt werden. Ein lokales Verzeichnis lässt sich mit baseten volume push veröffentlichen, das Chunks parallel hochlädt und jene überspringt, die BDN bereits hat.

Das Verschieben eines Tags ändert nichts an dem, was laufende Replikate ausliefern, doch neue und hochskalierte Replikate binden das neue Ziel des Tags ein. Ein Deployment, das einen Tag einbindet, kann nach einem Push daher zwei Versionen gleichzeitig ausliefern. Deployments, die einen Digest fixieren, liefern weiter die alte Version aus, bis die Quelle geändert und neu bereitgestellt wird. Eine gelöschte Version lässt sich 7 Tage lang über baseten volume restore wiederherstellen.

Über Modellgewichte hinaus und ins Training

Laut Baseten gehört alles, was ein Modell liest, aber nicht schreibt, in ein Volume. Beispiele sind LoRA-Adapter, vorgebaute Engines wie eine TensorRT-LLM-Engine, Embedding-Indizes, Vokabulardateien, Tokenizer-Konfigurationen, Lookup-Tabellen, Safety-Klassifikatoren, Evaluierungsdaten und Prompt-Vorlagen. Der BDN Startup Cache, die erste auf Volumes aufbauende Funktion, veröffentlicht die kompilierten Kernel und erfassten Graphen eines Replikats als Sealed Volume und stellt sie in späteren Replikaten wieder her.

Beim Training kann ein Job auf dem eigenen Cluster eines Teams seine Ausgabe mit der CLI und einem API-Schlüssel veröffentlichen. Bei Jobs, die auf Baseten trainiert werden, werden Checkpoints bereits mit dem Baseten-Speicher synchronisiert und lassen sich ohne Verwaltung von Zugangsdaten in ein Volume überführen. Da nur geänderte Chunks hochgeladen werden, bewegt ein Lauf, der alle paar hundert Schritte einen Checkpoint veröffentlicht, laut Baseten jedes Mal nur einen Bruchteil des Modells, und jede Version bleibt adressierbar.

Zur Geschwindigkeit teilt Baseten mit, dass Sealed Volumes über dieselben drei Cache-Stufen gelesen werden wie BDN-Gewichte: Node-Disk, Cache im Cluster und gespiegelter Origin. Ein Weights-Block lädt vor dem Start des Containers sämtliche Dateien, sodass die Startzeit mit der Modellgröße wächst. Ein Sealed Volume werde dagegen nach Angaben des Unternehmens in Sekunden eingebunden, und das Modell lese daraus genauso schnell wie von einem Weights-Mount.

Was das für Nutzer bedeutet

Für Teams, die Modelle auf Baseten betreiben, bietet die Funktion eine einzige versionierte Quelle für Checkpoints und andere Artefakte. Digests in den Konfigurationsdateien machen Änderungen sichtbar, und ein Rollback ist eine Frage von einer geänderten Zeile. Voraussetzung ist Baseten CLI 1.1.0 oder neuer.