Skip to main contentBlog
What a network volume is, and what it isn't. This article will help you choose the right tool for the job.
Most of the storage attached to a Pod is temporary by design. Network volumes are the exception. A network volume exists on its own, outlives any single Pod or worker, and can be picked up by the next one. This post covers how network volumes work, how they compare with Runpod’s other storage options, and how to create, maintain, and delete one.
A network volume is a persistent disk that lives on Runpod’s storage infrastructure inside a data center, not on the GPU machine running your code. Your Pod or Serverless worker mounts it over the network. It looks like an ordinary directory, but the data isn’t tied to that machine. The volume exists independently of the GPU hardware, so its data stays put when a Pod is terminated or when Serverless workers scale down to zero, and you can use it to share data across machines. You can even connect multiple pods to the same storage, which isn't possible with the traditional machine-based storage volumes.
Bear in mind that concurrent writes can corrupt data if not handled properly. Give each writer its own directory, or coordinate writes in your application.
A useful comparison is a network-attached storage on your home network; you can connect to a NAS from your smart TV, your computer, and your cell phone, but you cannot read your desktop PC's drive with your phone (not without a lot of extra configuration, at least.)
Measure twice, cut once; you'll want to know how network volumes function in production to avoid a time-consuming move later on.
This is the property that shapes every other decision. A network volume sits in one data center, and any compute that mounts it runs in that same Secure Cloud data center. In practice, the GPU types you can pick are limited to what that data center has available. This means you'll want to exercise some level of forethought before you decide to call a particular DC home. The UI on our Storage page will show you which GPUs are available in which data centers, or you can use MCP if you prefer to use natural language.
Global volumes (currently in beta) have no defined data center and can be attached to any Secure Cloud pod, but it's important to know that global volumes are also object storage and not a POSIX-compatible file system like network volumes are. Use them for read-mostly files such as model weights, and keep write-heavy work and installed environments on a network volume. They bill for stored data plus per-request fees rather than for a provisioned size. Global volumes are great for holding weights, but you won't be able to execute code from them.
Network volumes run on NVMe SSDs, with typical transfer speeds of 200–400 MB/s and peaks up to 10 GB/s. That’s fast for a network disk, but it’s still a network disk. Container or machine-based storage is going to have the edge in raw throughput, just because there are fewer layers the data has to traverse.
High-performance storage offers up to 3x the throughput and 4x the IOPS of the standard tier on parallel workloads, and it’s aimed at training, fine-tuning, and latency-sensitive inference. If your GPUs sit idle waiting on slow dataloaders, long checkpoint writes, or slow model loads, consider the high-performance tier; otherwise standard is the economical choice. You can’t convert an existing standard volume in place; you create a new high-performance volume and copy your data over, so this also requires some thought beforehand, just like selecting a data center.
Models on Pods: Download weights once, and every Pod you launch in that data center can use them. You stop paying for re-downloads every time you start a session. You also stop losing setup work when you terminate a Pod.
Models on Serverless that don’t fit the cache: Examples include weights that aren’t on Hugging Face, a large catalog of fine-tuned variants or LoRAs, and files you update often. In those cases a volume mounted at /runpod-volume is the practical choice.
Datasets: Prepare a dataset once, then run many training jobs against it without copying it each time. If your dataloader can’t keep the GPU busy, look at the high-performance tier.
Caches and environments: The Hugging Face cache, pip or conda environments, and compiled artifacts can all live on the volume. A new Pod then starts with your environment already set up, not with twenty minutes of installs.
Checkpoints and shared assets: A training Pod writes checkpoints, an evaluation Pod reads them, and a Serverless endpoint in the same data center serves the result. None of that requires downloading files to your laptop or uploading them again.
A network volume is probably the wrong choice in these cases:
The data center decision is permanent for this volume, so check three things first.
From the console, go to Storage, click New Network Volume, choose a data center, name, size, and tier, and create it. From the CLI:
runpodctl network-volume create \
--name "llm-weights" \
--size 200 \
--data-center-id "US-KS-2"
runpodctl network-volume list # note the volume IDThe CLI uses the data center’s default tier. To choose the tier explicitly, use the console, or the REST API with "type": "HIGH_PERFORMANCE":
You can create volumes up to 4,000 GB on your own; support can help if you need a larger volume.
One option is to start a pod in your data center and download your data in from the terminal or runpodctl, but that can get a bit spendy if the only available GPU in your DC is a B300. CPU pods, if available, can do this much more cheaply.
If your data center supports the S3-compatible API, upload directly from your machine or CI. You don’t need to start a Pod. Create an S3 API key on the Credentials page, run aws configure with it, then:
export NV_ID=your_volume_id
export DC=US-KS-2
export S3_URL=https://s3api-us-ks-2.runpod.io/
# Upload a model directory
aws s3 cp --recursive --region $DC --endpoint-url $S3_URL \
./my-model s3://$NV_ID/models/my-model/
# Confirm it landed
aws s3 ls --region $DC --endpoint-url $S3_URL s3://$NV_ID/models/my-model/Paths map directly: s3://VOLUME_ID/my-folder/file.txt is the same file as /workspace/my-folder/file.txt on a Pod and /runpod-volume/my-folder/file.txt on a Serverless worker.
It's worth bearing in mind that network volumes are meant to be used in combination with compute and aren't considered long-term cold storage. There's no backups to pull if there's data loss, whether it's from a user process or hardware failure. Remember that two is one and one is none; keep a copy of anything irreplaceable in redundant storage outside of Runpod.
With that in mind, turn on low-balance notifications. A volume whose storage charges go unpaid can be terminated, and its data also can’t be recovered.
Standard network volumes are billed hourly. You pay for the provisioned size whether or not anything is attached or how much of it's actually used. High-performance storage carries a per-GB premium that varies by data center, and the console shows the rate as you configure the volume. Using the S3-compatible API doesn’t change what you pay. Because size only grows, the main pricing mistake is over-provisioning “just in case.” Start close to what you need and grow the volume later.
Blog Posts
