InfrastructureOctober 30, 20263 min read

DeepSeek's Open-Source Storage System Hits 6.6 TiB/s — It's Not for Your Laptop

TL;DR3FS is DeepSeek's open-source distributed file system for AI training and inference. It pools thousands of NVMe SSDs behind one namespace, moves data over RDMA, and keeps metadata in FoundationDB, so GPUs rarely wait on storage. Published peak read throughput is about 6.6 TiB/s across 180 storage nodes. It is cluster plumbing, not laptop software.

By Cameron Voss · Updated October 30, 2026

DeepSeek 3FS Fire-Flyer File System
3FS is DeepSeek's shared storage layer for AI workloads, open source under the MIT license.

Your GPU is usually not the slow part of training. A cluster can hold thousands of expensive accelerators and still lose hours because the file system cannot hand over data fast enough. 3FS, short for Fire-Flyer File System, is DeepSeek's fix for that problem. The company built it for its own AI infrastructure and released it under the MIT license in February 2025.

What is 3FS?

3FS makes a pile of separate storage servers look like one very fast disk to a lot of GPU machines at once. A training job opens a path, reads bytes, and closes the file without knowing which server holds the data.

It is not a model or a database. It is the storage layer underneath both.

Why do AI clusters stall on storage?

Three workloads cause most of the pain. Small files: data preparation and dataloaders touch millions of them, and metadata lookups pile up while GPUs sit idle. Checkpoints: a large model writes hundreds of GB per save, and a slow write path turns every save into a pause. KV cache: inference servers reuse attention state instead of recomputing it, and spilling that cache from DRAM to disk only helps when reads are fast.

A traditional file system can handle any one of these. All three on one cluster, at the same time, is the hard part.

Diagram of three AI storage bottlenecks: small files, checkpoints, and KV cache
The three workloads 3FS is designed around. The fix is storage throughput or metadata speed, not more compute.

How is 3FS built?

Four roles do the work: a cluster manager, metadata services, storage services, and clients. Metadata is stateless and lives in FoundationDB, a transactional key-value store. Files are split into chunks and replicated with CRAQ, which stands for Chain Replication with Apportioned Queries. Writes enter at the head of a chain. Any replica can serve reads, so hot data fans out across machines instead of funneling through one node.

Everything runs over RDMA on InfiniBand or RoCE networks, which moves data between machines with little CPU cost. A FUSE client makes 3FS look like a normal mounted file system, and a native client adds a zero-copy fast path. The interface stays familiar, though 3FS is not strict POSIX in every detail: file length is only eventually consistent while writes are in flight, and becomes exact after a close or fsync.

3FS architecture diagram showing clients, cluster manager, metadata service, FoundationDB, and CRAQ storage chains over RDMA
Metadata is separate from data. Writes go through the head of a CRAQ chain, while reads can be served by any replica.

How fast is it?

TestResultSetup
Aggregate read~6.6 TiB/s180 storage nodes, 2 x 200 Gbps InfiniBand NICs and 16 x 14 TiB NVMe each, 500+ clients, training traffic in the background
GraySort110.5 TiB in 30m 14s25 storage nodes, 50 compute nodes, 8,192 partitions, 3.66 TiB/min average
KVCache readUp to 40 GiB/s peakDisk-backed cache clients with 1 x 400 Gbps NIC each

These are cluster benchmarks, not laptop numbers. The read test ran with training traffic in the background, not on an idle system.

3FS benchmark results: 6.6 TiB per second read, 110.5 TiB sorted in 30 minutes, 40 GiB per second KVCache read
Three published benchmarks. Each depends on a specific cluster configuration.

Where does it fit in DeepSeek's stack?

DeepSeek uses 3FS for training and inference. The repo lists data preparation, dataloaders, checkpointing, and KVCache as target workloads, which puts it in the storage layer behind model releases like V3 and R1. The repo does not break usage down by model, and 3FS was open-sourced in February 2025, after those models shipped.

Do you need to run it?

Probably not. If you use DeepSeek through the API or DeepSeek Harness, you never touch it. One GPU plus a fast NVMe drive needs no cluster. The real audience is training-cluster operators, who should budget for Linux servers, an RDMA network, FoundationDB, and someone who can run a distributed system.

3FS is3FS is not
A distributed file system for AI clustersA model or an inference engine
Open source under the MIT licenseA replacement for the disk in your laptop
Built around NVMe SSDs and RDMA networksA managed service
Compatible with a familiar file interfaceA database or an object store

Frequently asked

Can I run 3FS on my home PC?

Technically, you can compile it on Linux. Practically, there is no point: it expects multiple storage nodes, an RDMA network, and FoundationDB. On one machine, a local NVMe drive is faster and much simpler.

How does it help my API calls?

Indirectly. When you send a long prompt from Harness or the API, the server can reuse cached attention state instead of recomputing it. If that cache sits on 3FS, reads are fast and more GPU time goes to generating your tokens.

Do I need to read the C++ and Rust source?

Not unless you plan to operate or modify it. The README and design notes cover the architecture, the benchmarks, and the deployment requirements.

DeepSeek's storage stack supports fast, stable model inference for your token requests. Get a managed endpoint without running a cluster.

See the DeepSeek Coding Plan

Available while stock lasts. Access is delivered as a key after payment.