Types of storage volumes in Compute

In Compute, storage resources that can be added to virtual machines (VMs) as separate managed resources are called volumes. Compute offers two types of managed volumes and one host-local storage option:

• Disks:
  • Network SSD disks: managed block storage volumes.
  • Local SSD disks: ephemeral host-local block storage.
• Shared filesystems are file storage volumes. A filesystem can be shared by multiple VMs.

Nebius AI Cloud also provides object storage through a separate service, Object Storage. Together, these block, file and object storage options cover all use cases for data preparation, training and inference workloads, as well as associated infrastructure (boot disks, database hosts etc.)

​

Disks

Disks provide block storage for Compute VMs. Data that you put on disks is divided into blocks that are stored efficiently and reliably on underlying physical drives. Compute offers two kinds of disks:

• Network SSD disks can be created as a boot disk for a VM, from one of the boot disk images provided by Nebius AI Cloud, or as an empty additional (non-boot) disk. One Compute network SSD disk can only be added to one running VM at a time.
• Local SSD disks are Non-Volatile Memory Express (NVMe) drives physically attached to the compute host that runs a virtual machine (VM). They are not created or managed as separate storage resources, and you can only add them when creating a VM.

​

Network SSD disks

• Network SSD (network_ssd) Reliable disks backed by solid state drives (SSDs). Best used for infrastructure purposes: as VM boot disks, disks on Slurm controller VMs, etc. Reliability of Network SSD disks is ensured by means of erasure coding. A disk will tolerate up to two concurrent hardware failures in the Nebius AI Cloud region.
• Network SSD Non-replicated (Network SSD NRD, network_ssd_non_replicated) High-performance disks backed by SSDs. Best used as temporary storage without strict reliability requirements, e.g., a boot disk for nodes in Managed Service for Kubernetes® clusters where redundancy is less important. Data blocks of Network SSD Non-replicated disks are stored in NVMe namespaces on underlying SSDs. The size of each namespace is 93 GiB, so the disk size must be a multiple of 93 GiB.
  Network SSD Non-replicated disks have no redundancy. It’s not recommended to store any persistent data on these disks. If a disk fails, its data will be lost.
• Network SSD IO M3 (network_ssd_io_m3) High-performance and reliable disks backed by SSDs. Best used in performance-critical storage solutions, e.g., as storage disks in GlusterFS clusters. In addition to performance levels similar to Network SSD Non-replicated disks, Network SSD IO M3 disks are reliable through replication, with each disk’s data mirrored to three physical drives. In the disk type name, “IO” stands for “input/output (optimized)” and “M3” stands for “mirrors 3”.

​

Local SSD disks

Consider local SSD disks if your workload needs high-performance, low-latency storage for data that can be recreated. Local SSD disks are ephemeral, meaning temporary: their data is erased when the VM is stopped or deleted. Local SSD disks are available only on some platforms, presets and regions. For details, see Availability. Local SSD disks are useful for:

• Scratch space for files and intermediate outputs that can be recreated.
• Training or inference workloads that require low latency.
• Read or write caches for data that can be recreated.

​

Disk types comparison

Network SSD disk types are differentiated by several characteristics:

• Performance (bandwidth and IOPS): Local SSD > SSD IO M3 = SSD Non-replicated > SSD
• Reliability: SSD IO M3 > SSD > SSD Non-replicated = Local SSD
• Price per 1 GiB per month: SSD Non-replicated < Local SSD < SSD < SSD IO M3

You can choose the size of a network disk, but local SSD disks are attached to the VM host as part of a predefined configuration for the selected platform and preset. For more details, see the following comparison table. The values for local SSD disks are the performance numbers per one local SSD disk. The bandwidth and IOPS values below are upper bounds; actual performance depends on workload. ¹ For local SSD disks, the listed values are achieved under synthetic workload. ² The listed prices are valid as of March 9, 2026. For up-to-date prices, see Price per 1 GiB per month.

​

Encryption of disks

To store personal and other sensitive data securely, and to reduce the risk of unauthorized access, you can enable data encryption. To do so, create a disk with data encryption enabled. For Network SSD disks, encryption is enabled by default and cannot be disabled. For Network SSD NRD and Network SSD IO M3 disks, encryption is optional and you can enable it. Encryption is available for both boot disks and secondary disks. Local SSD disks are not encrypted and no other data protection method is applied to them. Ensuring the protection of data stored on these devices is your responsibility. We don’t recommend using local SSD disks for data that can’t be recreated. For more information, see Encryption in Nebius AI Cloud.

​

Disk performance

Disk performance depends on both the disk type and its size — it increases as you add more allocation units. Every allocation unit contributes equally to the overall bandwidth and IOPS until you reach the upper bounds for the disk. While you have fewer allocation units than needed to reach the upper bounds, the disk performance equals the sum of each unit’s performance. Once the sum reaches the upper bound for bandwidth or IOPS, adding more capacity does not increase performance any further. Disk performance metrics per allocation unit are shown in the following table. The bandwidth and IOPS values below are upper bounds; actual performance depends on workload. ¹ For local SSD disks, the listed values are peak numbers achieved per disk under synthetic workload. Disk encryption also affects the disk performance. Encryption requires additional processing of write operations; therefore, it can reduce performance by up to 15%. Local SSD disks can only be enabled during VM creation, cannot be scaled later, and are available only in fixed configurations. For supported configurations, see Using local SSD disks on Compute virtual machines. For other disks, you can choose your disk size in multiples of its allocation units to achieve the desired performance. Examples:

​

Shared filesystems

Shared filesystems provide file storage for Compute VMs. When VMs work with file storage, they work with a hierarchy of folders and files, as opposed to blocks when disks are involved. One shared filesystem can be attached to multiple VMs at once. All VMs that the filesystem is attached to must belong to the same project. Sharing a filesystem across projects is not supported, even if the projects are in the same region. To use a shared filesystem on a VM that it is attached to, you must mount it as a virtiofs device. Filesystems support data encryption by default; you cannot disable it. Encryption allows you to store personal and other sensitive data on filesystems securely, and reduce the risk of unauthorized access.

​

Filesystem specifications

Nebius provides shared filesystems that are generally based on solid state drives (network_ssd in developer tools such as Nebius AI Cloud CLI or provider for Terraform) to back them up. Shared filesystems have the following specifications:

• Capacity: 1–5,242,880 GiB (= 5120 TiB = 5 PiB)
• Read bandwidth per client: up to 12 GiB/s
• Write bandwidth per client: up to 8 GiB/s
• Aggregate read bandwidth: up to 940 GiB/s
• Aggregate write bandwidth: up to 475 GiB/s
• Maximum file size: 512 GiB × filesystem’s block size in KiB (for example, for the default block size it will be 512 GiB × 4 = 2TiB)
• Maximum number of inodes:
  • For filesystems up to 256 GiB: 4,194,304 (4 × 2²⁰)
  • For filesystems larger than 256 GiB: filesystem’s size ÷ 64 KiB
  For example, if the filesystem’s size is 512 GiB, its maximum number of inodes is (512 × 2³⁰) ÷ (64 × 2¹⁰) = 8 × 2²⁰ = 8,388,608.

• Reliability features: Erasure coding – tolerates two concurrent hardware failures
• Price per 1 GiB per month¹: $0.07

¹ The price is shown as of July 2, 2025. For up-to-date prices, see Price per 1 GiB per month.

​

Filesystem performance

Filesystem performance depends on its size — performance increases with each 4 TiB of the filesystem size. Every 4 TiB contributes equally to the overall bandwidth until you reach the upper bounds for the filesystem. Each 4 TiB of SSD filesystem improves the performance metrics by the following values:

• Read bandwidth: by up to 3.70 GiB/s.
• Write bandwidth: by up to 1.89 GiB/s.

​

Storage types comparison

​

Use cases and suggestions

Here is an overview of various stages of ML/AI workloads and storage options that Compute and other Nebius AI Cloud services provide for these stages, as well as general suggestions for using Compute storage.

​

Infrastructure

• VM boot disks: Network SSD disks For OS and system data on your VMs, the main storage requirement is reliability, so the suggested disk type is Network SSD.
• VM storage disks: Network SSD IO M3 disks If you are building storage solutions on VMs, e.g., GlusterFS clusters, use Network SSD IO M3 disks for speed and reliability.
• Managed Kubernetes node storage: Network SSD Non-replicated disks For Kubernetes worker nodes where data reliability isn’t a top priority (as the data is often transient), Network SSD Non-replicated disks provide high performance and low latency.
• Database hosts: Network SSD IO M3 disks Database workloads often demand consistent and high input/output operations per second (IOPS), and Network SSD IO M3 disks offer the best combination of reliability and speed.

​

Data preparation

• Storing and preprocessing datasets: Object Storage buckets Object Storage is ideal for handling large, unstructured datasets and provides a scalable solution for preprocessing tasks like data normalization or augmentation.

​

Training

• Streaming datasets to workers: SSD shared filesystems or Object Storage buckets In most cases, SSD shared filesystems ensure fast access to datasets during training, without bottlenecks. For exceptionally large datasets (1 PiB+) or distributed training across external workers, Object Storage buckets provide a scalable solution.
• Sharing code between workers: SSD shared filesystems By using SSD shared filesystems, multiple workers can efficiently access and synchronize code during distributed training, ensuring consistency and minimizing latency.
• Checkpoints: SSD shared filesystems, then Object Storage buckets During training, SSD shared filesystems allow for quickly saving and loading checkpoints, thus ensuring minimal disruption. Once training is completed, asynchronous transfer to Object Storage reduces costs while maintaining accessibility for future use.

• Scratch space: local SSD disks On supported platforms, presets and regions, local SSD disks provide host-local NVMe for data that can be recreated and benefits from high performance and low latency. Treat them as ephemeral and keep important data on durable storage.

​

Inference

• Autoscaling, sharing weights between GPUs: SSD shared filesystems When inference workloads require scaling across multiple VMs with GPUs, SSD shared filesystems allow for fast sharing of model weights, thus ensuring consistent performance across nodes during autoscaling.
• Sharing results: Object Storage buckets Once inference tasks are completed, Object Storage is ideal for sharing outputs such as logs, predictions or reports with other users or systems, due to its scalable and cost-efficient nature.

​

General suggestions

• For maximum IOPS, reads and writes to a volume should be close to its block size.
• For maximum bandwidth, reads and writes to a volume should be in 4 MiB chunks.

​

See also

• How to create a virtual machine
• Creating and resizing Compute volumes
• Attaching and mounting Compute volumes to VMs
• How to detach additional volumes from virtual machines
• Local SSD disks for Compute virtual machines