An AI engineering team notes that their GPU-accelerated model training is running far below expected speed. Profiling reveals a PCIe bottleneck: the GPU is frequently idling while waiting for the host CPU to transfer new data blocks. Which of the following configuration changes would most effectively reduce the frequency of CPU-to-GPU data transfers and alleviate this communication bottleneck?

In GPU-accelerated deep learning, the data pipeline involves loading data from disk to host system memory, preprocessing it on the CPU, and then transferring it to device memory through the PCIe bus. When the batch size is small, the overhead of initiating PCIe transfers dominates, and the GPU finishes processing the batch faster than the CPU can feed it the next one, leading to low GPU utilization and slow training. Increasing the training batch size packages more samples into a single tensor transfer. While the transfer of a larger batch takes slightly longer, the relative overhead is significantly reduced, and the GPU works on a larger chunk of compute, which keeps it active longer. This balances the communication-to-computation ratio and helps bypass the PCIe interface bottleneck. The faster host CPU clock speed change does not address the main issue, which is the bandwidth limits and transfer overhead of the PCIe bus; the latency of setting up driver calls remains the dominant bottleneck. Pre-loading the entire training dataset into GPU VRAM is ideal in theory, but in practice, real-world deep learning datasets such as ImageNet or large text corpora are hundreds of gigabytes or terabytes, far exceeding the physical VRAM capacity of even high-end enterprise GPUs such as the H100 or A100. Distributing the workload across multiple GPUs without modifying the pipeline can actually worsen communication bottlenecks, because it introduces additional multi-GPU synchronization overhead, such as all-reduce, over the PCIe or NVLink channels without resolving the host-to-device transfer efficiency.