Sort of. You mentioned a quite large buffer in your description (30Gb). In practice, PyTorch’s dataloader mostly relies on having enough workers to get you the data faster than your program can consume it. There’s still a buffer (each worker will prefetch 2 batches), but it’s much smaller and that’s okay.
Here’s how the steps will look like instead:

Initialize Dataset whose item retrieval is lazy-load image, augment image, return result
Initialize Dataloader with num_workers=X.
a) Each worker will be allocated their own subset of the images to load
b) Each worker will begin fetching data and building batches. They’ll load prefetch_factor number of batches in advance.
c) They will return these batches to your main program to be used.
If you’re finding that data loading is still a bottleneck, increase the num_workers further

Each worker is it’s own independent process that will go and get data. Assuming you have the computation power, you can always add more workers. (Normally you wouldn’t do more workers that say processes, but this requires a little bit of testing)
Let’s assume that your program is consuming datapoints faster than we can load them. Then we can increase the number of workers. If this fixes it, fantastic. Let’s suppose it doesn’t. Then you need to look for bottlenecks elsewhere. For example, disk read could be your bottle neck. In that situation, increase the prefetch_factor or num_workers won’t really help because they’re all attempting to use the same resources. There’s still ways to remedy this, but I won’t really get into it because it’s likely that just increasing the number of workers will be sufficient (but let me know if you’re still encountering a bottleneck and we can go over other methods).