The conventional path from storage into accelerator memory has an extra stop. Data arrives over the network, lands in host memory, gets copied across the bus into device memory. The host CPU and its memory bandwidth are in the path of every byte.

GPUDirect Storage removes the stop: a direct path from the storage device or network adapter into accelerator memory. Lower latency, lower CPU utilisation, higher achievable throughput.

Where the gain is real

Large sequential reads at high rates. Feeding accelerators from a dataset at many gigabytes per second per node, where the host copy is measurably the constraint.

CPU-starved nodes. When the host processors are busy with data preprocessing and augmentation, taking the copy work off them frees real capacity. This is frequently the larger practical benefit and it does not show up in a throughput benchmark.

Very high per-node bandwidth targets. Above a certain rate the host memory bandwidth genuinely becomes the wall, and this is how you get past it.

Where it does not help

Small random reads. Millions of small files is a metadata and latency problem. The bottleneck is not the host copy, and removing the host copy changes little.

Modest throughput. If a node needs one or two gigabytes per second, the conventional path handles it without breathing hard. You would be adding complexity for no measurable gain.

Workloads bound elsewhere. If the constraint is preprocessing on the CPU, or the network, or the file system’s metadata rate, the data path is not your problem. Fix the actual bottleneck.

The prerequisites, which are the real story

This is where it stops being a checkbox. You need compatible accelerators and drivers, a file system with a supported client implementation, a network adapter and driver that participate correctly, and a data path in your application that actually uses the API rather than ordinary file reads.

That last one matters most. The framework or data loader has to be calling through the supported path. If your training loop uses a standard reader, enabling the feature at the infrastructure layer achieves nothing, and it will appear to be enabled while delivering no benefit.

Version compatibility across those four components is a matrix, and the matrix has empty cells. Check every element against the specific versions you intend to run before designing around the feature.

How to evaluate it honestly

Measure first. Run your actual workload and find out where time goes. If host-side copy and CPU utilisation are significant, this is worth pursuing. If the profile is dominated by anything else, note it as a future option and move on.

Then test with your data, not a benchmark. Vendor numbers come from ideal conditions: enormous sequential reads, a tuned stack, no competing load. Your gain will be smaller and may still be worth having.

My position

It is a genuine technology with genuine benefits at the high end, and it is oversold at the middle. For a cluster of a dozen nodes doing fine-tuning on modest datasets, it is not where your attention should go. For a large training cluster where per-node ingest is the design constraint, it is part of the design and you should be checking the support matrix early.

Either way, it is an optimisation. Get the data layout right, get the metadata tier right, get the network right. Then, if the profile says so, take the host copy out of the path.

Next: the small-file problem, which is the thing you should fix first.