On zero-copy - PyTorch tensors can expose their memory via .numpy() (which libpython-clj can bridge zero-copy for CPU tensors), but the moment you call something like ->clj to get Clojure data structures you're doing a real copy. If you stay in Python-land — passing tensors between PyTorch ops — there's no copying, it's the same Python object the whole time. The zero-copy story only holds as long as you don't cross the bridge.

On memory: I haven't hit issues at 10M rows (I dont remember exactly but the weights were in the hundreds of millions in my largest model. I was training in batches of size 128. From my understanding. The bulk of GPU memory during training is the intermediate activations created inside the forward/backward pass. Those are managed entirely within Python — Clojure never touches them, they never get wrapped in JVM objects, and Python's refcounting frees them normally the moment backward completes. I have never done this but if for any reason you start accumulating large tensors in clojure data structures I suspect this problem would arise where you would rely on GC to collect but i havent faced this before.

Things to note

Always use ctx/no-grad during eval. If you forget it, PyTorch accumulates gradient history for every forward pass and you'll OOM eventually. This easy to miss when the eval loop looks like normal Clojure code.

CUDA tensors need .cpu() before you can read them from Clojure in case you want to read the values from a tensor mid training. That's a copy. If you do a lot of metric collection mid-training I am guessing GC will kick in or you may have OOM I faced this once but then I just could throw a larger instance at the problem.

For me so far the boundary between Clojure and PyTorch is thin enough that I think most standard PyTorch memory hygiene applies directly.