Microsoft is open-sourcing distributed accelerator for cloud storage (DACS): a caching system for AI workloads. It leverages the local NVMe or SSD storage in the GPU nodes of a Kubernetes cluster to bring data closer to GPUs, while Azure Blob Storage remains the durable source of truth.

Introducing DACS

DACS is Kubernetes native and cluster local. A supported client requests reading a blob chunk of an artifact. If the blob chunk is already cached, then DACS serves it from cache storage. If it is missing, the client reads it from Azure Blob Storage and hydrates the cache for later reads. This read-path suits large, immutable or versioned artifacts, including model weights, datasets, and checkpoint snapshots.

Why Microsoft is open-sourcing DACS

This technology is powering AI workloads at scale within Microsoft. Open source lets others inspect the design, try it in their own environments, and help shape what comes next. It also gives the community a shared starting point for addressing repeated data reads, without asking each team to build its own cache.

Training context: In one large-scale audio-training evaluation, reading from a warm cache reduced long-tail dataset-loading delays and helped a previously unstable workload complete a training run. The share of dataset-loading operations that stalled for at least five seconds fell from 14% to 0.1%.

Inference context: At startup, AI inference jobs load model weights into accelerator memory. When multiple jobs start concurrently, each may fetch the same weights from Azure Blob Storage, increasing network traffic, triggering throttling, and delaying startup while accelerators remain idle. A distributed cache like DACS lets readers reuse the model weight already brought into the Kubernetes cluster, reducing accelerator wait times for model load prior to the first inference request.

These examples show why we are sharing DACS: to help teams spend less time waiting for data and more time making progress. The goal is simple: reduce repeated reads without replacing the durable storage for all AI workloads.

What you can use today

The initial release includes the cache server, a native C/C++ client, and Python and Rust client wrappers. It also includes Helm charts and Kubernetes controller for deployment, Ethernet and InfiniBand transport, health probes, and Prometheus metrics. Current storage integrations use Azure Blob Storage; other providers are opportunities for future contributions.

Start with a trusted Kubernetes cluster containing eligible nodes with local NVMe or SSD storage and then use DACS client for integration. The release does not isolate mutually untrusted tenants. Consult the repository’s README for compatibility, configuration, and deployment guidance.

Start with a real workload

Visit the DACS repository: https://github.com/Azure/dacs

Begin with the README, Helm charts, and deployment examples, including static and node-aware scaling. Choose a workload with repeated artifact reads. Compare its data-load latency and training or serving behavior before and after enabling DACS. Record whether the cache is cold or warm. Share your setup and findings so that others can reproduce them.

What comes next for DACS

Potential future areas include integration with Azure Kubernetes Service and BlobFuse, additional framework integrations, and support for more storage providers. These areas are under consideration and are not available in the initial release.

Try DACS with a workload that repeatedly reads large artifacts, and share your measurements, feedback, and issues in the GitHub repository. Community contributions to framework integrations, storage backends, clients, and documentation can help shape future releases.

---

DACS is a collaboration between Azure AI Platform and Azure Storage. We thank the engineers, reviewers, and early adopters.