Private beta
QDivZero Storage brings persistent disks to Compute
Storage extends Compute with persistent disks that can be mounted into multiple workloads, shared across launches, and kept attached when a workload moves between providers.
QDivZero Storage is now part of the Compute private beta for workloads that need persistent state.
The goal is straightforward: keep the storage contract with the workload, not with a single provider. Compute already handles model execution, routing, security, and capacity decisions. Storage adds the disk layer that stateful jobs need when they cannot afford to lose their working set every time the scheduler moves them.
What Storage does
Storage gives Compute persistent disks that can be mounted into multiple workloads, shared when several launches need the same data, and kept available when the runtime lands on a different provider. If a workload starts on provider 1 and later resumes on provider 2, the disk moves with it.
That makes it a good fit for:
- checkpoints, fine-tuning runs, model caches, and quantization artifacts,
- retrieval indexes and derived embeddings,
- shared caches and working directories,
- application state that should survive provider changes.
Why it matters
Provider flexibility is useful only if the data layer can move with it. Otherwise, every reschedule becomes a manual migration.
Storage removes that friction. A team can keep using the same Compute flow, let the control plane place workloads where capacity is available, and still preserve the persistent state those workloads depend on.
The same disk pattern also works well for model preparation jobs. Fine-tuning pipelines can keep their checkpoints and working directories in one place, quantization jobs can write derived weights without depending on a single provider-bound volume, and model caches can stay warm so new launches start faster.
Shared state, not duplicated state
The same disk can also be mounted into multiple workloads when a project needs a shared state layer.
That is simpler than copying the same data into separate provider-specific volumes. It keeps the storage boundary clear and avoids scattering the same artifacts across more than one backing store just to satisfy the scheduler.
Where it fits in the platform
Compute still decides where the workload runs. Storage keeps the disk attached. Smart Balancers route traffic. Firewall protects requests before inference starts. The platform stays modular, but the pieces now work together in a way that supports stateful deployments as well as stateless ones.
What comes next
Storage is one more step toward a platform where teams can move workloads without rethinking the data layer every time. That is the operating model we want across the stack: portable, predictable, and easier to run in production.