Batch size has a direct, proportional relationship with VRAM consumption during both training and inference: each sample in a batch requires its own memory allocation for input tensors, intermediate activations at every layer, and output tensors, all of which must reside in GPU memory simultaneously while the batch is being processed. Decreasing the batch size means fewer samples occupy memory concurrently, directly reducing peak VRAM consumption — this is precisely why reducing batch size is one of the first, most common remedies when a model run fails with an out-of-memory (OOM) error on a GPU with limited VRAM.

Option C states the inverse of the correct relationship and is a genuinely important misconception to correct: increasing batch size increases VRAM consumption, not decreases it — parallelism across the batch means more simultaneous memory occupancy, not less. It's true that larger batches improve GPU compute *utilization* and *throughput* (better amortizing fixed kernel-launch overhead and better exploiting parallel hardware) up to the point VRAM allows, but that throughput benefit is a separate effect from, and does not reduce, memory consumption. Options A and B both incorrectly claim batch size is memory-neutral, when it is in fact one of the most direct, easily controlled levers for managing VRAM usage — alongside model precision (quantization, mixed precision) and activation checkpointing, covered in the Performance Optimization domain elsewhere in this set.