Best NVMe SSDs for AI Workloads

Storage is the component people most often over-buy for AI work, and the reason is a reasonable-sounding assumption that turns out to be wrong: that because models are large, loading them fast must matter a great deal.

It matters once, at load time. After that the weights are resident in memory and the drive is idle. A PCIe 5.0 drive will shave a few seconds off a model switch and contribute exactly nothing to tokens per second.

What actually matters is capacity, sustained write behaviour under load, thermals, and — if you are training or running virtual machines — endurance. None of those are the number on the box.

What model storage really demands

Capacity, and more than you plan for

Models accumulate faster than anyone expects. At the common 4-bit quantisation, roughly 0.6 GB per billion parameters:

Keep two or three quantisations of a few models, add some image-generation checkpoints and LoRAs, and several hundred gigabytes disappears without any single download feeling large.

1 TB is a sensible floor if you intend to experiment. 2 TB if you work across several model families.

Read speed matters exactly once

Loading a 42 GB model:

• PCIe 4.0 at 7,000 MB/s: about 6 seconds
• PCIe 5.0 at 14,000 MB/s: about 3 seconds

Three seconds, once per model load. If you keep models resident — which OLLAMA_KEEP_ALIVE and its equivalents exist to do — you pay it once per session.

That is the entire inference-side benefit of a faster drive.

Where fast storage genuinely helps

Dataset preparation. Shuffling, tokenising and streaming a large corpus is sequential-throughput-bound, and here a PCIe 5.0 drive earns its price.

Checkpoint writing. Fine-tuning writes multi-gigabyte checkpoints repeatedly. Sustained write performance matters far more than the headline read figure — for reasons covered in the next section.

Working with many small files. Image datasets with hundreds of thousands of files are random-IOPS-bound, which is a different specification again, and the one where DRAM-less drives fall down.

The specification nobody quotes: sustained write

This is the single biggest gap between the number on the box and what you actually get, and it catches people out precisely because it never appears in a product listing.

Consumer SSDs use pseudo-SLC caching. TLC NAND stores three bits per cell, but writing three bits is slow, so the controller writes part of the array one bit per cell — fast — and folds it down to three bits later, during idle time. That fast region is the SLC cache.

The headline “7,000 MB/s write” figure is the SLC cache speed. It applies until the cache is full.

What happens after the cache fills

The cache is usually dynamic — larger on an empty drive, shrinking as it fills. On a 2 TB TLC drive it might absorb 200–300 GB when nearly empty, and a fraction of that when the drive is 80% full.

Once exhausted, write speed drops to the native NAND rate:

That QLC figure is not a typo. A budget 4 TB QLC drive can fall below the sustained write speed of a mechanical hard disk once its cache is spent.

When this actually bites you

It does not affect inference at all. Loading models is a read operation, and reads are unaffected.

It affects three things:

• Writing checkpoints. A 14 GB checkpoint written every few hundred steps will exhaust a small cache and then stall the training loop.
• Bulk-copying a model library. Moving 400 GB of models onto a new drive will run at the post-cache rate for most of the transfer.
• Virtual machine hosts. Sustained mixed writes never let the cache drain.

How to check before buying: look for a review that plots write speed over a sustained multi-hundred-gigabyte transfer rather than quoting a peak. The shape of that curve is the specification you actually want, and it is the one manufacturers do not publish.

Endurance: when TBW is real and when it is theatre

Every SSD carries a TBW rating — terabytes written before the warranty stops covering wear. Current 2 TB drives are typically rated around 1,200 TBW, which is roughly 600 TB per terabyte of capacity.

The question is whether you will ever approach it.

Inference: no, not remotely. Downloading models writes them once. Even an aggressive habit — 500 GB of new models a month — reaches 6 TB a year. That is 0.5% of the rating annually. The drive will be obsolete long before it is worn.

Fine-tuning: getting closer, but still comfortable. A full checkpoint of a 7B model with optimiser state runs to tens of gigabytes. Checkpoint every 500 steps across a 10,000-step run and you write perhaps 280 GB per run. Fifty runs a year is 14 TB — still around 1% of the rating.

Virtualisation hosts: this is where it matters, and not primarily because of TBW. Guest filesystems, host filesystems and copy-on-write layers stack up, and write amplification of five to ten times is normal. A busy node can put 50–100 GB a day onto the drive.

But the real argument against a consumer drive in a VM host is not wear. It is power-loss protection: enterprise drives carry capacitors that let in-flight writes complete during an outage. Consumer drives do not, and sync-heavy filesystems — ZFS in particular — either run slowly or risk data loss without it.

The practical rule: for models and datasets, ignore TBW entirely and buy capacity. For a virtualisation host, look at power-loss protection rather than the endurance figure.

Thermals, and the worst slot on the board

The primary M.2 slot on most consumer motherboards sits between the CPU socket and the top PCIe slot — which is to say, directly underneath the graphics card.

That is the worst-ventilated position in the case, and if the card above it is a 575 W RTX 5090 exhausting downward, the drive is sitting in its heat.

PCIe 5.0 drives are the ones that suffer. They draw noticeably more power than PCIe 4.0 equivalents and can reach throttling temperatures under sustained transfer, at which point the controller reduces speed to protect the NAND. A throttled fast drive is slower than an unthrottled slower one.

Three practical consequences:

• Buy the heatsink version, or fit one. On PCIe 5.0 it is not optional.
• Prefer a lower M.2 slot for the drive you write to most, away from the graphics card.
• A cheaper PCIe 4.0 drive that holds its speed beats a PCIe 5.0 drive that throttles after ninety seconds.

The specifications

The recommendations

Best for model storage

For storing and loading models, this is the right amount of drive.

7,450 MB/s reads load a 42 GB model in around six seconds. Sustained write behaviour is good by consumer standards, thermals are sensible, and the endurance ratings are among the better ones at this tier.

The heatsink version is worth the small premium in a dense case or under a graphics card.

Buy the capacity, not the speed grade: 2 TB of this is a better purchase than 1 TB of something faster.

Best value

The interesting thing about this drive is what it leaves out.

It has no onboard DRAM. Most drives use a DRAM chip to hold the flash translation layer — the map between logical addresses and physical NAND. Without one, the SN770 borrows a small slice of system memory instead, through Host Memory Buffer.

For storing model weights, that trade-off is close to free. Weights are read sequentially and then live in RAM; the access pattern that exposes a DRAM-less design — sustained random writes — never occurs. You get a materially cheaper drive whose only weakness your workload does not touch.

It also runs cooler than most PCIe 4.0 drives, which makes it a sensible choice for that awkward slot under the graphics card.

Where it is the wrong drive: as a virtual machine datastore, as a checkpoint target during training, or in a boot environment that does not support HMB.

Best for datasets and checkpoints

If your work involves preparing datasets or writing checkpoints repeatedly, the extra throughput is real.

14,500 MB/s reads and 12,700 MB/s writes roughly double a good PCIe 4.0 drive on sequential work. For anything that streams data continuously, that shows up directly in wall-clock time.

Two caveats, both covered above. It needs cooling — a heatsink or direct airflow, not an afterthought. And for inference it buys you nothing the 990 PRO does not already deliver.

Best portable

A genuinely useful category that people overlook: a model library you can carry.

Two gigabytes per second over USB-C loads a 42 GB model in about 25 seconds. That is fast enough to work directly from the drive rather than copying to local storage first, which makes moving between a laptop and a workstation practical without re-downloading a few hundred gigabytes.

One thing to check: full speed needs a USB 3.2 Gen 2×2 (20 Gbps) host port. Many machines — including every Mac — top out at 10 Gbps, which halves it. Still quick; just not the number on the box.

Storage across a network

At some point local storage stops being the right place for archives, and a NAS earns its place.

10 GbE is the specification that decides whether network storage is convenient or theoretical. The arithmetic is stark:

Six minutes makes network storage a chore you avoid. Forty seconds makes it somewhere you actually keep things.

Pair it with a switch that can carry the traffic:

Choosing NAS drives: the CMR/SMR trap

This is the mistake that costs people an array, and the specification is frequently buried.

Mechanical drives record data one of two ways. CMR (conventional magnetic recording) writes tracks side by side. SMR (shingled magnetic recording) overlaps them like roof tiles to fit more data on a platter — which means rewriting any track requires reading and rewriting every track that overlaps it.

For sequential writes to an empty drive, SMR is fine. For a RAID rebuild, it is close to catastrophic: the sustained random rewrite pattern collapses throughput, a rebuild that should take a day can take a week, and some controllers time the drive out entirely and drop it from the array — during the exact window when your redundancy is already gone.

Several vendors shipped SMR drives into NAS product lines without disclosure. Check the specification sheet for the recording method explicitly, and treat its absence as an answer.

Two other specifications worth reading on a NAS drive:

• Workload rating, in TB/year. 550 TB/year covers dataset churn comfortably; a desktop drive rated at 55 TB/year does not.
• Rotational vibration sensors. In a populated multi-bay chassis, drives shake each other. Without compensation, throughput drops measurably.

RAID levels, and why RAID is not a backup

For dataset and model archives on large modern drives:

• RAID 5 / RAID-Z1 is no longer sensible above about 8 TB per drive. A rebuild reads every remaining drive in full, for days. At consumer unrecoverable-read-error rates, the chance of hitting an error mid-rebuild — while you have no redundancy left — is not small.
• RAID 6 / RAID-Z2 tolerates two failures and is the sane default at these capacities.
• Mirrors rebuild fastest and waste the most capacity. For a small array of very large drives, that is often the right trade.

And the part that gets skipped: RAID protects against a drive dying. It does not protect against you deleting the wrong directory, a filesystem bug, ransomware, or the building flooding. Model weights are re-downloadable; your own datasets, fine-tuned adapters and training runs frequently are not. Those need an actual backup — a second copy, on different media, with one copy off-site.

A practical layout

For a machine that does AI work:

Most people need the first two. The third is for fine-tuning; the fourth for anyone running more than one machine.

Keeping models on their own drive is worth the small extra cost for an unglamorous reason: a full model directory then cannot take the system drive down with it, and model directories fill up silently.

Where the runtimes actually put things

Having bought a second drive, you have to tell the software to use it. The defaults all land on the system drive:

• Ollama reads OLLAMA_MODELS. Default is ~/.ollama/models on Linux and macOS, %USERPROFILE%\.ollama\models on Windows.
• LM Studio has a models directory setting in the application itself.
• Anything using Hugging Face libraries — diffusers, transformers — reads HF_HOME, defaulting to ~/.cache/huggingface. This one grows enormous without anyone noticing, because it is a cache and nobody looks in caches.

Set these before you start downloading, not after.

What to look for

Capacity before speed. A full drive is a hard problem. A drive that loads a model three seconds slower is not.

Sustained write, not peak. Find a review that plots the whole transfer. The post-cache figure is the real one.

Thermals, especially on PCIe 5.0. Buy the heatsink version, and put the drive you write to most in a slot away from the graphics card.

Recording method on any mechanical drive. CMR, stated explicitly. If the sheet does not say, assume the answer you do not want.

Power-loss protection if it is a virtualisation host. More important than TBW for that role.

Ignore DRAM-less warnings for model storage. The weakness is real and your workload does not touch it. Ignore it for anything write-heavy.

Continue your research

• Best AI Workstations — the machine the storage goes into
• Best Mini PCs for Homelabs — where network storage matters most
• Ollama Hardware Requirements — how much space a model library really needs
• How Much VRAM Do You Need for Local AI? — the memory arithmetic behind the model sizes above