iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The only defensible way to measure an “AI SSD” is a controlled before-and-after test: run the same AI workload on the existing storage path, replace or reconfigure only the storage component, and run it again under the same conditions. Measure the application result (such as time per training epoch, tokens per second, or inference tail latency) alongside storage throughput, IOPS, latency, and accelerator utilization. A faster SSD benchmark is not evidence of a faster model if the workload is limited by the GPU, CPU, network, filesystem, or software path.
“AI SSD” is not a universal performance class. It can mean a directly attached NVMe drive, a set of drives behind a server, or storage in a disaggregated system. Your result therefore applies to the exact workload and configuration you document—not to every SSD with an AI-oriented label.
What the comparison should prove
Define the decision before collecting numbers. A useful question is, “Does this storage change reduce training time, improve inference service-level objectives, or allow the accelerator to stay busier at the intended concurrency?” A vague goal such as “show that the AI SSD is faster” encourages misleading measurements.
There are two valid comparisons:
- Isolated storage comparison: keep the I/O path, filesystem, cache policy, RAID layout, and software unchanged, and change only the drive or drive set.
- Configuration comparison: compare the complete old and new paths when the SSD requires a different filesystem, RAID layer, network protocol, GPU-direct path, or storage server. Report it as a configuration result rather than attributing the entire change to the SSD.
In either case, state exactly what changed. Storage performance depends on the complete data path, including PCIe topology, host processors, memory, filesystem, network, and the application’s I/O behavior. NVIDIA’s GPUDirect Storage Benchmarking and Configuration Guide and its NVIDIA-Certified Storage documentation both emphasize matching the test to the system and workload.
#1 Best Overall
- MEET THE NEXT GEN: Consider this a cheat code; Our Samsung 990 PRO Gen4 SSD helps you reach near max performance with lightning-fast speeds; Whether you’re a hardcore gamer or a tech guru, you’ll get power efficiency built for the final boss
- REACH THE NEXT LEVEL: Gen4 steps up with faster transfer speeds and high-performance bandwidth; With a more than 55% improvement in random performance compared to 980 PRO, it’s here for heavy computing and faster loading
- THE FASTEST SSD FROM THE WORLD'S FLASH MEMORY BRAND: The speed you need for any occasion; With read and write speeds up to 7450/6900 MB/s you’ll reach near max performance of PCIe 4.0 powering through for any use
- PLAY WITHOUT LIMITS: Give yourself some space with storage capacities from 1TB to 4TB; Sync all your saves and reign supreme in gaming, video editing, data analysis and more
- IT’S A POWER MOVE: Save the power for your performance; Get power efficiency all while experiencing up to 50% improved performance per watt over the 980 PRO; It makes every move more effective with less consumption
Freeze the baseline before touching the hardware
Record the baseline while it is still intact. The baseline is the reference against which every percentage and speedup is calculated.
Record hardware and topology
- Server or workstation model, CPU model and count, installed memory, accelerator model, and accelerator count.
- Existing storage model, capacity, number of drives, interface, PCIe generation and link width, controller or HBA, RAID level, and slot topology.
- Whether data is local, on a storage server, or delivered over a network; record link speed, switch path, and client count.
- Cooling, power mode, and any thermal or power limits that could change during a long run.
Record software and data
- Operating-system release and kernel, driver and CUDA (or equivalent accelerator stack) versions, framework, runtime, benchmark commit or package version, and filesystem.
- Storage software, RAID or volume-manager settings, mount options, I/O scheduler, compression, encryption, and checksumming.
- Dataset identity, size, file count, file-size distribution, sharding, format, and location. Use a copy that is byte-for-byte identical in both conditions.
- Model architecture and checkpoint, batch size, sequence length, precision, data-loader workers, prefetch depth, augmentation, and random seed or sampling protocol.
Record the run protocol
- Warm-up policy, number of measured iterations, synchronization points, start and stop conditions, and timeout behavior.
- Concurrent jobs, client and worker counts, CPU affinity, NUMA placement, and accelerator power or clock policy.
- Cache state (cold, warm, or deliberately mixed), network state, and whether other jobs are permitted on the hosts.
- Ambient conditions and the time of each run when thermal throttling or a shared storage service could matter.
For the SSD condition, write down the model, firmware, usable capacity, endurance or over-provisioning setting if relevant, number of drives, and exact slot or PCIe switch. If you change a filesystem or storage protocol at the same time, put that in the comparison name.
Choose workload-shaped cases
A synthetic sequential-read test can make a drive look impressive while an AI data loader performs small, concurrent, metadata-heavy operations. Select cases that resemble the deployment you care about. NVIDIA’s certification profiles are useful starting points, but they are not a substitute for describing your application’s actual I/O.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Workload | Typical storage behavior | Representative object sizes in NVIDIA’s profile | Application outcomes to capture |
|---|---|---|---|
| Training | Large sequential dataset reads from many parallel streams; periodic large sequential checkpoint writes | 256 KiB–4 MiB | Time per epoch, samples per second, data-stall time, checkpoint duration, accelerator utilization |
| Fine-tuning | Repeated reads of base weights; iterative small or medium writes for adapter deltas and checkpoints | 64 KiB–1 MiB | Time per fine-tuning step or epoch, time to reload a checkpoint, samples or tokens per second |
| Inference | Hot reads of model weights, embeddings, and prompt/context features; metadata-heavy lookups | 4 KiB–256 KiB | Requests per second, tokens per second, time to first response, median and tail latency |
| KV cache | Random reads and writes with temporal locality | 1–5000 KiB | Token throughput, cache-hit behavior, request latency, eviction or spill time |
| Query and retrieval | Random approximate-nearest-neighbor or vector lookups with small ingestion and update writes | 1–120 KiB | Queries per second, p95/p99 lookup latency, ingestion rate, end-to-end response time |
The size ranges above come from NVIDIA’s certified-storage workload documentation. Treat them as representative ranges, not requirements. Measure the actual read/write sizes and access pattern produced by your data loader, inference server, vector index, or cache.
Training case
Run enough steps to include normal data loading and at least one checkpoint if checkpoint writes are part of the production job. A test that reads a tiny, already-cached dataset cannot answer whether storage affects a full training epoch. Capture the interval in which the accelerator waits for input as well as the total epoch time.
Rank #2
- Ideal for high speed, low power storage
- Gen 4x4 NVMe PCle performance
- Up to 6,000MB/s read, 4,000MB/s write
- Includes Acronis cloning software
- 5-year limited warranty
Fine-tuning case
Include the repeated base-model reads and the writes made by the adapter or checkpointing scheme. If the real job resumes from checkpoints, measure restart and reload time; do not report only the steady-state steps.
Inference case
Separate model-startup or weight-loading time from steady-state serving. Exercise the intended prompt and context distribution, because hot weights and metadata lookups can behave very differently from a single large sequential file read. Record a latency distribution, not just an average.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsKV-cache and retrieval cases
Use the same cache size, eviction policy, index, query mix, and update rate in both conditions. Temporal locality can make a random workload appear faster after warm-up, so report whether the result is cold-cache, warm-cache, or a defined mixture.
Measure application impact and the storage path together
Every run should produce at least one application metric and one or more storage metrics. Keep their time windows aligned so that a storage spike can be related to an application stall.
Application metrics
- Training or fine-tuning: seconds per step or epoch, samples or tokens per second, checkpoint and restart time, and accelerator utilization.
- Inference: requests or tokens per second, time to first response, inter-token latency where applicable, and p50, p95, and p99 latency.
- Retrieval: queries per second, p95/p99 lookup latency, ingestion or update rate, and complete response time including model work.
- Any workload: model or dataset load time, error and timeout count, host CPU use, memory pressure, and accelerator idle periods.
Storage metrics
- Read and write throughput, with units and read/write mix.
- IOPS at the stated block or object size and queue depth.
- Latency distribution, not only an average; include p95 or p99 when the application has a tail-latency objective.
- Outstanding I/O, queue depth, retries, and utilization of each drive or storage server.
NVIDIA distinguishes throughput, IOPS, and latency as different measures in its benchmarking guide. Do not substitute a drive’s headline sequential throughput for training speed or inference capacity. A drive can deliver high bandwidth while the application remains limited by CPU preprocessing, an accelerator kernel, network delivery, or metadata operations.
Rank #3
- SPEED UP PROJECTS. Launch creator applications fast with uncompromising PCIe 4.0 read speeds up to 7,100MB/s,[2] (1TB and 2TB[1] models) and write speeds up to 6,700MB/s[2] (1TB[1]-4TB[1] models).
- CREATE AND STORE MORE. Make more room for your 4K videos and high-resolution images with capacities from 500GB[1] up to 4TB[1] on M.2 2280 built with our trusted 8th generation SANDISK BiCS QLC 3D CBA NAND.
- IT GOES WHERE YOU GO. With an all-new power efficient design, your drive delivers high performance with low power, giving you more time to be productive while on the go.
- UNCOMPROMISED RELIABILITY. With up to 1,200 TBW[3] (4TB[1] model) endurance rating, your drive is designed for creators.
- KEEP YOUR DRIVE UPDATED. Monitor your SSD’s performance and check for updates with the downloadable SANDISK Dashboard application.[5]
System-context metrics
Sample accelerator utilization, host CPU utilization by process, memory bandwidth or pressure, PCIe link activity, and network throughput. A rise in accelerator utilization with unchanged storage throughput can indicate that the new path removed a feed bottleneck. Conversely, higher storage throughput with unchanged accelerator utilization suggests that storage was not on the critical path.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Control cache state and the I/O path
The operating-system page cache can turn a storage test into a memory test. NVIDIA states: “Any performance evaluation of the storage technology requires bypassing the page cache to ensure that actual storage performance is being measured, and not the page cache read/write performance.” Its GDS guidance documents O_DIRECT for the GDS I/O path.
Use two explicitly named modes when both matter:
- Cold-cache, storage-focused mode: start from a defined cache state and use a cache-bypassing path where the application and filesystem support it. Document the exact method rather than assuming that dropping caches is safe or equivalent across systems.
- Warm-cache, application mode: run the workload as users normally do, allow the intended cache to populate, and report that the result includes memory-cache effects.
Do not apply O_DIRECT blindly. Alignment, filesystem support, buffering, and application semantics vary. Verify that the program actually uses the requested path and that the measured bytes reach the intended device.
Also identify whether transfers are CPU-mediated or use a GPU-direct path such as GDS. Changing that path can alter CPU overhead and accelerator feeding independently of the SSD. Include the filesystem, mount options, storage library, and direct-I/O setting in the run label.
Run the experiment in layers
- Define the hypothesis. Write the target outcome, such as “reduce cold model-load time” or “keep the accelerator above a specified utilization at 32 concurrent inference requests.” Choose the baseline and candidate path.
- Freeze and record the configuration. Capture all hardware, software, dataset, model, cache, and concurrency details listed above. Photograph or export PCIe topology if slot placement could matter.
- Verify data integrity. Compare checksums, file counts, model hashes, and dataset manifests. A different shard order or compressed copy invalidates a storage comparison.
- Measure the idle system. Confirm that no unrelated jobs, background rebuilds, scrubs, downloads, or thermal alarms are active. Record the accelerator clocks, temperature, and power state.
- Run a storage microbenchmark. Use read/write mixes, object sizes, queue depths, and concurrency that resemble the selected AI case. Repeat each setting. This diagnoses the device and path; it does not prove an AI application benefit.
- Run the production-like AI workload. Use the same model, data, software, batch or request mix, worker count, and stopping rule for both configurations. Keep warm-up separate from measured iterations.
- Repeat each condition. Report the run count, median or mean as appropriate, spread, and outliers. Do not publish only the fastest run. Reset cache state and other state according to the declared protocol.
- Test expected scale. Increase request concurrency, data-loader workers, client count, or node count if the deployment will do so. Stop when another resource becomes the clear limit and record that transition.
- Restore and cross-check. Swap back to the baseline or use a second baseline run to detect time drift, thermal changes, or data corruption. Treat a failed reproducibility check as a result requiring investigation.
Use microbenchmarks for diagnosis, not a verdict
A microbenchmark can reveal whether the candidate device reaches its expected bandwidth, IOPS, and latency at a given queue depth. It is especially useful for finding a miswired PCIe slot, an undersized network link, an incorrect RAID setting, or a filesystem that is serializing requests.
Recommended Free Tools
Rank #4
- HUGE SPEED BOOST: Get random read/write speeds that are 40%/55% faster than 980 PRO; Experience up to 1400K/1550K IOPS, while sequential read/write speeds up to 7,450/6,900 MB/s reach near the max performance of PCIe 4.0*
- BREAKTHROUGH POWER EFFICIENCY: Use less power and get more performance; Enjoy up to 50% improved performance per watt over 980 PRO, plus optimal power efficiency with max PCIe 4.0 performance**
- SMART THERMAL CONTROL: Samsung's own nickel-coated controller delivers effective thermal control; With its slim size, 990 PRO is a perfect fit for desktops and laptops that meet the PCI-SIG D8 standard***
- THE CHAMPION MAKER: Up to 65% improvement in random performance enables faster loads for an ultimate gaming experience on PS5 and DirectStorage PC games****
- SAMSUNG MAGICIAN SOFTWARE: Get the most out of your SSD with Samsung Magician's advanced yet intuitive optimization tools; Monitor drive health, protect valuable data, and receive important updates for your 990 PRO
It cannot show whether a model trains faster. Whole-system behavior includes data decoding, batching, synchronization, metadata, CPU scheduling, accelerator kernels, and application backpressure. NVIDIA describes microbenchmarks as building blocks and distinguishes them from production-like benchmarks in its GDS guide.
For example, Samsung’s MLPerf Storage paper discusses 3D U-Net, ResNet50, and CosmoFlow. It notes that sample processing can create small sequential I/O directed at repeatedly changing random addresses, so labeling a workload simply “sequential” or “random” can hide the behavior that matters. Throughput and accelerator utilization are more informative views of application impact.
Calculate and explain the result
For a metric where lower is better, such as epoch time or latency, calculate speedup as baseline value ÷ SSD value. For a metric where higher is better, such as throughput, calculate SSD value ÷ baseline value. Report the underlying values, units, run count, and spread so readers can audit the percentage.
Interpret the pairs, not isolated numbers:
- Application improves and storage improves: storage was probably on the critical path, although confirm that no other component changed.
- Storage improves but application does not: the workload was likely limited elsewhere, or the application did not issue I/O in the pattern exercised by the microbenchmark.
- Application improves but device throughput does not: lower latency, better queue handling, reduced CPU overhead, or a changed I/O path may matter more than peak bandwidth.
- Results improve only at higher concurrency: show the scaling curve and identify the point at which network, CPU, PCIe, filesystem, or accelerator capacity becomes dominant.
- Results vary widely between repeats: investigate cache state, background activity, garbage collection, thermal throttling, network contention, and request-mix drift before drawing a conclusion.
What published examples do—and do not—show
Published figures are useful context only when their scope stays attached to the number.
- Samsung reports about 270 GB/s for a particular 10-storage-node disaggregated-storage rack in its Memory Solutions Lab test. The article describes six servers in two configurations, DSS v0.6, NFS v4, and their stated operating systems and kernels. This is a system-level result, not a per-drive figure or a general SSD promise; Samsung also says further testing with actual GPU servers was still needed.
- A 2023 SNIA summary cites, for the challenging workload described in that work, a Samsung PM9A3 result of 25× I/O, 3.4% inference-time overhead, and 3× higher throughput compared with the MLPerf inference implementation. Those figures are workload-specific and must not be generalized to another SSD, model, or deployment.
Neither example establishes a universal uplift for a product category called an AI SSD. Your controlled application result is the evidence relevant to your system.
Best Value
- This product has been replaced by our latest generation. Please search for the SANDISK Optimus GX 7100 NVMe SSD
- HIGH-OCTANE GAMING. Experience speeds up to 7,250MB/s read and 6,900MB/s write (1-2TB models), with up to 35% faster performance than previous generation.
- PURPOSE-BUILT. Designed for serious on-the-go gamers, with a PCIe Gen4 interface and SANDISK’s next generation TLC 3D NAND.
- MORE TIME TO CLEAR THAT CHECKPOINT. Built with laptops and handheld gaming devices in mind, with up to 100% more power efficiency over the previous generation.
- DO MORE WITH DASHBOARD. Ensure your drive is optimized for prime performance with the downloadable WD_BLACK Dashboard (Windows only).
Test scaling instead of a single “best” run
Storage that looks equal on one client can behave differently with many workers or nodes. Test at the concurrency levels your deployment will use: for example, several data-loader worker counts, inference request rates, or storage clients. Keep the per-client workload defined so that increasing concurrency does not silently change batch size, prompt mix, or model precision.
Plot application throughput and latency against concurrency, and plot storage throughput, IOPS, and tail latency on the same points. Mark where accelerator utilization stops rising, where queue depth grows without application benefit, and where network or host CPU reaches saturation. If the candidate SSD helps only until a shared network link fills, the link—not the SSD—is the scaling limit.
Build a report another engineer can reproduce
Use a table or appendix with one row per condition and no ambiguous labels. Include:
- Baseline or SSD configuration name, drive model and firmware, capacity, drive count, interface, PCIe topology, controller or RAID layout.
- Server, accelerator, CPU, memory, operating system, kernel, drivers, framework, storage library, filesystem, mount options, and I/O path.
- Dataset and model identifiers, file and object characteristics, read/write mix, I/O sizes, queue depth, worker or client count, and network details.
- Cold or warm cache policy, direct-I/O or buffered mode, warm-up length, measured duration, synchronization method, run count, and cache-reset procedure.
- Application metrics, storage metrics, accelerator and host utilization, network utilization, errors, and variability.
State the geography or deployment context when it affects the path—for example, a local server test versus a multi-node disaggregated system. Do not call a local NVMe result evidence for enterprise shared storage, or vice versa.
Troubleshoot a result that looks wrong
The SSD benchmark is high but training time is unchanged
- Check accelerator utilization and data-loader wait time. The job may be compute-bound.
- Compare the application’s actual I/O sizes and read/write mix with the microbenchmark.
- Check whether the dataset or model was already in memory.
- Verify that the new drive is not behind a slower PCIe link, filesystem layer, or network path.
The first run is much slower than later runs
- Label it as cold-cache behavior if that is the intended use case.
- Separate model or index initialization from steady state.
- Reset or preserve cache state consistently; never mix cold and warm runs in one average.
Results fluctuate between repeats
- Look for background jobs, filesystem maintenance, SSD garbage collection, thermal throttling, and network contention.
- Use a fixed power and CPU policy, isolate benchmark processes where practical, and increase the number of repeats.
- Report the spread and investigate outliers instead of deleting inconvenient runs without a documented rule.
Only high concurrency shows a difference
- Run intermediate concurrency points to find the knee in the curve.
- Measure host CPU, network, PCIe, queue depth, and accelerator utilization at each point.
- Describe whether the gain is capacity for more clients, lower latency, or both.
Direct I/O produces errors or worse results
- Confirm alignment and filesystem support for the application’s direct-I/O mode.
- Verify that the intended library and device path are being measured.
- Keep a buffered, warm-cache application run as a separate, clearly labeled condition rather than silently mixing modes.
Decide whether the SSD is worth the change
Adopt the new storage configuration only when it improves the outcome that matters for your workload—training completion time, serving capacity, tail latency, restart time, or accelerator utilization—under the concurrency and cache policy you actually need. A large increase in synthetic throughput with no application benefit is a diagnostic result, not a business case. Conversely, a modest bandwidth change that cuts tail latency or removes accelerator starvation can be valuable.
Keep the final claim narrow: name the workload, model, dataset, software versions, storage path, cache mode, concurrency, and measured outcome. That is what makes a with-and-without-AI-SSD comparison useful instead of a generic speed claim.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
