This one never got an answer, and the shape of it — fine for roughly 150–300 slices, dead until a full PC restart, and re-creating the model every 50 slices does not help — points away from the model and toward things that grow per iteration. Three suspects, all visible from here:
Re-initializing the model cannot fix any of the three, which fits what you saw.
The check that separates them: log resident memory every 10 slices across three runs. Run A, your code as-is. Run B, inference under torch.inference_mode() storing only plain floats. Run C, B plus a forced allocator release every 50 slices (on CPU, garbage collection plus malloc_trim through ctypes, or simply a worker process per batch).
If B runs flat, it was retention. If B climbs but C is flat, it was the allocator. If all three climb at the same slope, the growth is inside the processor and you have a much rarer bug worth reporting upstream. Once the slope is flat, batching becomes safe: fixed-size batches with a memory ceiling set from the measured slope, and this class of crash is simply gone.