Best SSD for a Local LLM Workstation: NVMe vs SATA Model-Load Latency Tested

Best SSD for a Local LLM Workstation: NVMe vs SATA Model-Load Latency Tested

If you've been running local LLMs — ollama, llama.cpp, LM Studio, or a vLLM stack — you've almost certainly waited through a cold-start model load and wondered whether your SSD was the bottleneck. The question is reasonable. A 70B-parameter model in Q4_K_M quantization weighs 42GB. Something has to ferry that data off disk and into RAM or VRAM before inference can begin. How much does drive speed actually matter?

We tested four drives across four model sizes to answer this with actual numbers rather than spec-sheet extrapolation. The short version: NVMe is meaningfully faster for cold starts, but SATA is sufficient if you load once and run for hours. The full picture is more nuanced — and the three-tier hot/warm/cold storage workflow at the end of this article will save most operators more time than upgrading drives.

Key Takeaways

• NVMe is for cold-start speed, not inference throughput. Once a model is loaded into VRAM or system RAM, the SSD is completely idle. Tokens generate entirely in memory.
• Samsung 970 EVO Plus is the cost-performance optimum. Gen 3 NVMe at 3,500 MB/s sequential read covers every realistic local LLM use case without the Gen 4 price premium.
• SATA SSDs are acceptable for single-session operators. If you load one model in the morning and run it all day, a Crucial BX500 saves money with a one-time 75-second load penalty.
• HDDs are archive-only. Never use a spinning disk as your active model directory. A 70B cold load from HDD takes nearly five minutes.
• Plan for 500GB minimum, 1–2TB preferred. A small library of Q4_K_M models across 8B, 32B, and 70B variants fills 200–400GB fast.
• Three-tier storage works. Keep actively switched models on NVMe (hot tier), loaded-once-per-day models on SATA (warm tier), and FP16 source weights on HDD (cold archive).

Why SSD Speed Matters for Local LLM — And When It Doesn't

The inference loop for a local LLM is almost entirely in-memory once the model is loaded. The llama.cpp project has detailed benchmark infrastructure that makes this explicit: disk I/O is not in the hot path. The GPU executes matrix multiplications against weights already resident in VRAM. The CPU handles prompt evaluation against weights in system RAM for CPU-offloaded layers. Once loaded, the SSD sits idle unless you're doing memory-mapped inference — which some tools do for very large models that don't fit in RAM/VRAM.

Where SSD speed shows up:

1. Cold start — loading a model from disk to RAM/VRAM for the first time.
2. Model switching — unloading one model and loading another. This happens every time you change the active model in ollama or switch contexts in LM Studio.
3. Layer eviction and reload — rare, but tools that swap layers between RAM and disk (e.g., llama.cpp with aggressive --n-gpu-layers splits) read from disk during inference.

For scenario 1 and 2, sequential read speed is the binding constraint. For scenario 3, random 4K read IOPS matter more. We focus on sequential throughput here because that's where the marketed NVMe vs SATA difference manifests.

Testbench Configuration

All testing was performed on a single workstation to eliminate motherboard, PCIe lane, and memory subsystem variables:

• CPU: AMD Ryzen 7 5800X (8 cores / 16 threads, PBO enabled)
• RAM: 64GB DDR4-3200 (2x32GB, dual channel)
• GPU: NVIDIA RTX 3060 12GB (VRAM ceiling: 12GB; overflow to system RAM)
• OS: Ubuntu 22.04 LTS, kernel 6.5.0, ext4 filesystem on all test drives
• Software: ollama 0.1.44, llama.cpp b3456, Python 3.11
• Measurement method: time ollama run <model> "" for 5 consecutive cold starts per drive (page cache cleared between runs via sync && echo 3 > /proc/sys/vm/drop_caches). Median of 5 runs reported.

Drives were connected to their native interfaces — NVMe drives to the M.2 PCIe 3.0 x4 slot, SATA drives to the chipset SATA 6Gb/s port. No RAID, no software caching layers active during measurement.

The Drives

Samsung 970 EVO Plus — Recommended Daily Driver

The Samsung 970 EVO Plus is a Gen 3 NVMe drive that has maintained its position at the top of the value tier for over four years. It uses Samsung's 96-layer V-NAND and ships with the in-package DRAM cache that makes sustained write behavior consistent — important when you're writing multi-gigabyte model files. TechPowerUp's full review of the 970 EVO Plus confirms sequential read of 3,500 MB/s, which translates directly to fast model loads.

At roughly $0.08 per GB in the 500GB configuration, it is the default recommendation for any new LLM workstation build on a budget of $40–$80 for storage.

Samsung 860 PRO — DRAM-Backed SATA Benchmark

The 860 PRO is Samsung's MLC-based premium SATA drive. It includes a DRAM cache, which smooths write latency and makes sequential behavior predictable. At 550 MB/s sequential read, it hits the SATA 6Gb/s ceiling cleanly. We include it as the reference point for what a premium SATA drive looks like — its performance represents the ceiling for any SATA option.

SanDisk Ultra 3D — Mid-Range SATA

The SanDisk Ultra 3D is a TLC-based SATA SSD with DRAM cache. It performs nearly identically to the 860 PRO for large sequential reads because both drives saturate the SATA interface. The price-per-GB is lower, making it the practical SATA recommendation if you don't need the 860 PRO's superior write endurance.

Crucial BX500 — Budget SATA (No DRAM)

The Crucial BX500 1TB is a DRAM-less SATA SSD. It uses the host memory buffer (HMB) architecture, which means the drive borrows a slice of system RAM for its FTL table cache. For large sequential reads — which is exactly what model loading is — HMB drives perform similarly to DRAM-cached SATA drives at the start of a transfer. The BX500 is the budget option and costs roughly $0.05 per GB in 1TB configuration.

Drive Specification Comparison

The spec comparison reveals what the benchmark will confirm: the real performance gap is between NVMe and SATA, not between SATA drives. Premium SATA drives like the 860 PRO cost nearly 3x more per gigabyte than the BX500 for effectively identical sequential read performance.

Cold-Start Load Time Benchmark

The following times represent median cold-start model load to first-token-ready state. All times in seconds.

The NVMe advantage is consistent and substantial: approximately 6x faster than SATA for cold starts across all model sizes. However, the SATA drives are nearly indistinguishable from each other. Spending extra on a premium SATA drive like the 860 PRO buys better endurance and write consistency — not faster model loading.

For a single-session workflow (load once, use all day), even the 79-second BX500 load time for a 70B model is a one-time cost. For a workflow that involves switching models multiple times per hour, those 79 seconds compound into meaningful lost time across a workday.

Example math for a 5-model-switches-per-day workflow:

For operators who switch models frequently, the NVMe investment pays back in recovered time within weeks.

Quantization Storage Matrix

Understanding how much disk space each model configuration consumes is essential for planning your storage tier. The following matrix covers the most common quantization variants available via llama.cpp's GGUF format:

A practical local LLM library — one 8B model, two 32B models, and one 70B model in Q4_K_M — totals approximately 88GB. Add a second 70B variant (e.g., Qwen 2.5 72B) and you're at 132GB. Add Q5 variants for quality comparisons and you hit 200GB comfortably.

Recommended storage budget by operator type:

• Light user (1–2 models, 8B–14B): 100GB NVMe sufficient
• Standard hobbyist (3–5 models, mix of 8B–70B): 500GB NVMe
• Power user (10+ models, 70B in rotation): 1TB NVMe hot tier + 1TB SATA warm tier
• Fine-tuning / research (FP16 weights needed): 2TB NVMe + 4TB HDD archive

The Three-Tier Storage Strategy

The most cost-effective approach for operators running more than 3–4 models is to classify your model library by access frequency and route each tier to appropriate storage:

Hot Tier — NVMe SSD (500GB–1TB)

Models you switch between multiple times per session. These need sub-15-second load times. Budget NVMe like the Samsung 970 EVO Plus is appropriate — you don't need Gen 4 speeds for this.

What goes here:

• Your daily-driver 8B or 14B chat model
• The 70B model you run for complex reasoning
• Any model you're actively benchmarking or comparing

Warm Tier — SATA SSD (1–2TB)

Models you load once per session but don't switch. The 75-second load penalty is acceptable when it happens once at session start. SanDisk Ultra 3D or Crucial BX500 cover this tier cost-effectively.

What goes here:

• Specialty models (code, vision, embedding) you use for specific tasks
• Older 13B or 34B models you keep for comparison
• Quantization variants you test occasionally

Cold Archive — HDD (4TB+)

FP16 source weights, base models before fine-tuning, and anything you might want to reload in six months. Never use as an active model directory. A 4TB HDD at ~$70 can hold the full FP16 weights for a Llama 70B model with room to spare.

What goes here:

• FP16 .safetensors source weights from Hugging Face
• Merged adapter checkpoints before re-quantization
• Archived GGUF files for models you've replaced but haven't deleted

ollama Model Directory Configuration

To implement the hot-tier / warm-tier split, configure your ollama model directory explicitly:

# Set OLLAMA_MODELS in /etc/environment or your shell profile
# Point to your NVMe mount for the hot tier
export OLLAMA_MODELS=/mnt/nvme/ollama/models

# For models on the warm tier, use a symlink into the SATA mount
ln -s /mnt/sata/ollama/models/blobs /mnt/nvme/ollama/models/blobs-warm

For llama.cpp-based workflows, the -m flag accepts any path:

# Load from NVMe hot tier
./llama-cli -m /mnt/nvme/models/llama3.1-70b-q4_k_m.gguf --n-gpu-layers 80

# Load from SATA warm tier (slower cold start, same inference speed)
./llama-cli -m /mnt/sata/models/qwen2.5-32b-q5_k_m.gguf --n-gpu-layers 48

Inference throughput (tokens per second) is identical regardless of which tier the model was loaded from, once it's in memory.

Gen 3 vs Gen 4 NVMe: Is the Upgrade Worth It?

Gen 4 NVMe drives (PCIe 4.0 x4) deliver up to 7,000 MB/s sequential read — double the Gen 3 ceiling. For local LLM cold starts, this translates to roughly 30–50% faster load times versus Gen 3.

Gen 4 load time estimate for Llama 3.1 70B-Q4_K_M: approximately 8 seconds vs 12 seconds on Gen 3.

That 4-second gap is real but narrow in the context of a single daily session. Gen 4 drives command a 20–30% price premium per gigabyte. The math only works in favor of Gen 4 if you are switching large models several times per hour — a workflow common in model comparison work or automated benchmarking pipelines, but rare for typical LLM users.

Recommendation: Buy Gen 3 NVMe (970 EVO Plus or equivalent) for the hot tier unless you are running automated evaluation pipelines that switch 70B models more than 10 times per hour. At that throughput, Gen 4 pays back the premium within a month of time savings.

Related Reading

If you are building out a full LLM workstation, SSD selection is one component of a broader storage and compute decision. These related guides cover adjacent decisions:

• Best 1TB SATA SSD for Cloning and OS Migration — if you are migrating an existing OS to a new boot drive before adding model storage
• Best SATA SSD Boot Drive Upgrade for Aging Desktops — budget system upgrades where SATA is the only available interface
• RTX 3060 12GB Local LLM Quantization Guide 2026 — choosing quantization levels that fit within the 3060's 12GB VRAM ceiling
• Local LLM Demo Coach: Quake 3, UT99, Ryzen 5800X, RTX 3060 — full system testbench using the same CPU and GPU as our SSD test rig

Frequently Asked Questions

Does NVMe really matter for running local LLMs?

Yes, but only for cold-start latency — not for inference throughput. Once a model is loaded into VRAM or system RAM, the SSD is idle. Inference tokens are generated entirely in GPU or CPU memory. The SSD speed only matters when you first launch ollama, switch between models, or load a quantization variant mid-session. On a Samsung 970 EVO Plus at 3,500 MB/s, Llama 3.1 70B-Q4_K_M takes about 12 seconds to load from cold. On a Crucial BX500 SATA SSD at 550 MB/s, the same load takes approximately 75 seconds. If you switch models frequently, NVMe pays for itself in cumulative wait time across a day of work.

How much SSD space do I need for a local LLM library?

Plan for at least 500GB, with 1-2TB ideal if you want to keep multiple quantization variants running simultaneously. A single Q4_K_M quantization of Llama 3.1 70B takes 42GB. Qwen 2.5 72B-Q4_K_M is 44GB. Running five to ten different models in a mix of 8B, 32B, and 70B variants in Q4_K_M will consume 200-400GB quickly. If you add the FP16 source weights for fine-tuning or reference, those weigh 2-4x the quantized size. A tiered setup works best: 500GB NVMe for the active model hot-tier, 1TB SATA for cold model storage. That covers most hobbyist setups without overspending.

Is the Samsung 970 EVO Plus still worth it in 2026?

Yes, at its current price-per-GB. It is a Gen 3 NVMe drive delivering 3,500 MB/s sequential read, sufficient for fast model loading without paying the Gen 4 premium. Gen 4 drives like the WD Black SN850X or Samsung 990 Pro deliver 7,000 MB/s sequential, but real-world model-load advantage over the 970 EVO Plus narrows to under 30% for large models because DRAM bandwidth saturates before the PCIe 4.0 ceiling. The 970 EVO Plus costs roughly $0.08 per GB in 500GB configuration. Unless you are switching 70B models every few minutes, the Gen 3 performance is more than adequate for local LLM workloads in 2026.

Can I use an HDD instead of an SSD for model storage?

Only for archival cold storage — never as your active model directory during inference sessions. A 7200 RPM HDD delivers around 150 MB/s sequential read. A 42GB Llama 3.1 70B load from HDD takes roughly 280 seconds — nearly five minutes just to start a conversation. Modern ollama and vLLM do no pre-caching from disk during inference, so the full model must be read on every cold start. Use an HDD as a third-tier archive for fp16 source weights you access rarely. Keep quantized GGUF models you use daily on SATA SSD minimum, NVMe preferred. A 4TB HDD at around $70 is sensible for the archive role.

What is the difference between NVMe Gen 3 and Gen 4 for LLM loading?

Gen 3 NVMe via PCIe 3.0 x4 delivers up to 3,500 MB/s sequential read. Gen 4 via PCIe 4.0 x4 delivers up to 7,000 MB/s. For LLM cold-start loading, the real-world difference is 30-50% faster on Gen 4 — a 70B model that loads in 12 seconds on Gen 3 loads in roughly 8 seconds on Gen 4. For a workstation where you load models once per session and then run inference for hours, that 4-second difference is hard to justify at the 20-30% price premium Gen 4 commands per gigabyte. Gen 3 NVMe is the cost-performance optimum for most local LLM operators in 2026. Upgrade to Gen 4 only if you are switching models multiple times per hour.

Verdict: What to Buy

For most local LLM operators: Samsung 970 EVO Plus 500GB or 1TB on the hot tier. It is fast enough that model switching is not a friction point during a normal workday. Add a Crucial BX500 1TB for the warm tier if you maintain a large model library. Skip Gen 4 unless your workflow involves model switching more than 5–10 times per hour.

For budget-first builds: Crucial BX500 1TB as the sole storage device. You will wait 75–80 seconds for 70B model loads, but inference performance is identical to NVMe once the model is resident. If you load once and run all day, this is rational.

For high-throughput model evaluation: Gen 4 NVMe (WD Black SN850X or Samsung 990 Pro) in 2TB configuration. The speed premium justifies itself when you are running automated model comparison pipelines that switch models continuously.

The bottom line: your GPU is the performance constraint during inference. Your SSD is the performance constraint during the first 12–80 seconds of a session. Size accordingly, tier your storage, and put your budget where the bottleneck actually is.