Storage and Network

Storage and network determine how data enters a training job, how checkpoints survive, and how distributed workers communicate. A fast accelerator can still sit idle if the input path or interconnect is the true bottleneck.

Storage Layers

LayerGood ForRisk
CPU RAM cacherepeated reads during one rundisappears on process or node restart
local NVMe / SSDhot dataset cache, temporary shards, checkpoint stagingnot automatically shared or persistent
shared filesystemcommon datasets, team artifacts, Slurm-visible pathsmetadata contention and shared bandwidth
object storage / remote servicearchival artifacts, cross-machine sharinghigher latency and request overhead

Network Layers

PathUse ForWatch
node to shared storagedataset reads, checkpoint writesmetadata storms, small files, contention
CPU host to GPUbatch transfer and pinned memorycopy time, synchronization
GPU to GPU in one nodedata parallel, tensor parallel, peer transfertopology and peer access
GPU to GPU across nodesdistributed trainingall-reduce, bandwidth, latency, rank placement
client to serviceinference servingp95/p99 latency, queueing, payload size

Network Evidence

Realtime bandwidth tools should be selected by the operating environment. Public notes should describe the signal, not the private interface name or endpoint.

ip -s link show dev <interface>
sar -n DEV 1
ifstat <interface>

Use netstat/ss for socket-level symptoms, not as the only measure of interface bandwidth.

ss -s
netstat -s

Classify the result:

SignalInterpretation
high receive/transmit ratebandwidth pressure or expected transfer
packet drops/errorsinterface, driver, cable, switch, or overload class
retransmitscongestion or path-quality issue
many small connectionsmetadata, service, or client pattern issue

Training Data Path

The data path can be written as:

Each arrow can be the bottleneck.

Distributed Training Path

For data parallel training, communication usually appears after backward:

If the all-reduce time grows faster than useful compute, adding more GPUs can reduce throughput per GPU.

Practical Rules

  • Cache hot datasets near the node when reuse is high and policy allows it.
  • Avoid millions of tiny files when a shard format is acceptable.
  • Separate checkpoint staging from long-term artifact storage.
  • Use per-process IO tools to distinguish checkpoint writers, data loaders, copies, and archive extraction.
  • Use controller health tools privately when disk failure is suspected, but publish only the health class.
  • Measure dataloader time separately from GPU compute time.
  • For distributed jobs, record world size, node count, GPU count per node, and interconnect assumption generically.
  • Do not publish private mount paths, hostnames, live topology, device IDs, account names, or exact security controls.

Storage Health Evidence

Disk performance symptoms and disk health symptoms are different. Slow training can come from storage contention even when hardware is healthy; a degraded array can also be masked until writes fail.

sudo iotop -o -a
sudo <raid-tool> /c<controller-id> show
EvidenceMeans
one process dominates write IOcheckpoint, logging, copy, or extraction bottleneck
many workers read tiny filesmetadata contention or dataset layout problem
controller reports degraded arrayhardware maintenance issue, not a model bug
rebuild in progresstemporary performance and reliability risk

Checks

QuestionRoute
Is the issue dataloading?Data loading and IO
Is the issue checkpoint save/load?Checkpointing
Is the issue distributed communication?Distributed training on HPC
Is the issue serving latency?Inference capacity planning
Is the issue a mount or permission problem?Storage mounts and permissions