Today we are opening early access to Runix FS, a POSIX file system and a multi-tier distributed cache that sits in front of the object storage a team already runs. Training jobs, inference servers and agents read the same data through a local path, and the bucket stays the durable copy. This post is about why we think that layer is missing from most AI stacks, what we are building it on, and what we will and will not claim about it.
The gap between the bucket and the GPU
AI data ends up in object storage for good reasons: it is cheap, durable and effectively unlimited. It is also a poor file system. Listing a prefix with millions of objects is slow, opening a file is a network request, there is no atomic rename, and every read of a small file pays a full request's overhead. Training code, data loaders and most tools were written for files, not for objects.
Teams paper over the gap in the same three ways. They copy the data to local disks before a job starts, and pay for it in start-up time and in a second copy to keep in sync. They attach block volumes, and run into per-node attachment limits long before a node runs out of CPU, which is exactly where an agent platform with one workspace per agent lives. Or they rewrite their I/O around an object SDK, and give up the tools that expect a path. Meanwhile the most expensive hardware in the cluster waits.
What Runix FS is
Runix FS keeps the bucket as the source of truth and puts two things in front of it. The first is a file system: masters hold the metadata and replicate it with Raft, and clients see an ordinary namespace through a FUSE mount, an S3-compatible gateway, an HDFS-compatible client or SDKs for Java, Python and Rust. The second is a cache: workers hold blocks in memory, SSD and HDD tiers, serve them directly to clients, and read from the bucket on a miss.
Two properties matter more than any benchmark. File paths map one-to-one to object keys, so the data in your bucket keeps its original layout and stays readable by anything else, with or without the cluster running. And on Kubernetes, the CSI driver provisions a volume by creating a directory rather than calling a cloud API, so provisioning keeps up when thousands of pods start at once.
Built on Curvine
Runix FS is built on Curvine, an open-source distributed file system and cache written in Rust, released under Apache 2.0 and accepted as a Cloud Native Computing Foundation Sandbox project. We chose to build on an open core rather than write our own for the reason buyers usually ask about first: if we disappear, your data does not, and neither does the software that reads it.
The project has published evidence we can point to rather than restate as our own. AWS published a reference architecture for LLM inference on SageMaker HyperPod that uses Curvine as a shared KV-cache tier, and reported up to 2.7× faster time to first token at 2,500 tokens (the AWS post). The project also provisioned 10,000 volumes for 10,000 agent pods on 99 EKS nodes, with a storage cluster of four pods (the write-up).
What we will not claim
The throughput and metadata figures on the product page are the Curvine project's own benchmark results, on its own hardware, and we label them that way. They are not a Runix service level, and there is no published availability number during early access. What a cache does for a given workload depends on the working set, the access pattern and the instances, so during early access we measure on yours before anyone signs anything.
How early access works
- Where it runs: in your own AWS, Google Cloud or Azure account, next to your GPUs and your bucket.
- How it is deployed: we size the cluster with you, how much of the working set to cache and on which tiers, and deploy it together.
- Who supports it: our team, with a reply within one business day, under a contract with Runix AI Inc, a US company.
- What it costs: quoted per deployment during early access. An AWS Marketplace listing is in preparation; until then you contract with us directly.
If you want to see the engine first, the quick start brings up a single-node cluster, attaches a bucket and mounts it in a few commands. If you would rather start from your workload, tell us where your data lives, how big it is and what reads it.