Cuda out-of-memory run-time error handling --fall back to cpu possibility?

Leonmac: <p>We usually put a simple cuda detect method before using the gpu like below:</p>
<pre><code class="lang-auto">dev = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
</code></pre>
<p>This works fine for detecting if a hw cuda device is available or not, however, I will still meet out-of-memory errors occasionally–in particularly if I have a few tasks run at the same time.<br>
I wonder if some advanced solution would exist, that may help to prevent such error, for exp, have an early check and estimate the hw resource needed, and then compare to actually availability–so to prevent such run-time crash?</p>

ptrblck: <p>A few warmup iterations might help but it would also depend on your actual use case.<br>
E.g. if you are working with a language model each input batch could have a different size depending on the longest sentence in the current batch. These things can be runtime dependent, so even a few warmup iterations wouldn’t help.</p>
<p>Additionally,</p>
<aside class="quote no-group" data-username="Leonmac" data-post="1" data-topic="153749">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/leonmac/48/30837_2.png" class="avatar"> Leonmac:</div>
<blockquote>
<p>in particularly if I have a few tasks run at the same time.</p>
</blockquote>
</aside>
<p>no utility could predict if the user will be running other applications using GPU memory. To limit the available device memory for the current process you could use <code>torch.cuda.set_per_process_memory_fraction(fraction, device=None)</code>.</p>

Leonmac: <p><a class="mention" href="/u/ptrblck">@ptrblck</a> great thanks. That will be helpful.<br>
Just further explore: what I mean are mostly like below:</p>
<ol>
<li>before each task runs, do a check of how many resources would be needed for the upcoming task,</li>
<li>then have a check about the currently available hw resource, etc…</li>
<li>then it should be able to judge if it is safe to go forward, if it is not, it still has a choice to fall back to cpu, rather than just move forward and have the program crash…</li>
</ol>
<p>of course, this can not deal with all situations in particularly the multiple parallelly run-time tasks (which might need locker like in C/C++) but I think that already can cure the problem somewhat and make the program not that easily crash.</p>

Leonmac: <p><a class="mention" href="/u/ptrblck">@ptrblck</a> Back to this topic. I am still occasionally stuck on the CUDA OOM issue.<br>
I am not sure if the below exception handlers strategy for CUDA memory are workable, rather than running into run-time error and exit.</p>
<p>for exp:</p>
<pre><code class="lang-auto">try: 
 # 1.check if GPU is available:
dev = torch.device("cuda:0" if torch.cuda.is_available() else raise exception)
# 2.allocate the memory limitation for the process:
# however this will raise an error if fail to allocate memory?
 torch.cuda.set_per_process_memory_fraction(0.9, device=dev)
# 3.do few "warmup iterations" -- but still, if OOM happen, an error will be raised.
except:
    dev = torch.device("cpu")
else:
   # run a normal  business here on dev
</code></pre>

ptrblck: <p><code>set_per_process_memory_fraction</code> will not avoid the OOM, but will reduce the available memory for PyTorch so that other applications can use the remaining GPU memory.<br>
The suggestion was targeting your use case of running different applications at once.</p>

Leonmac: <p><a class="mention" href="/u/ptrblck">@ptrblck</a> for the below one, is there any suggestion? if something is not correctly configured that OOM happens, the program will be crashed rather then raise an exception…<br>
<code># 3.do few "warmup iterations" -- but still, if OOM happens, an error will be raised.</code></p>

rmast: <p><a class="mention" href="/u/leonmac">@Leonmac</a> I had the same idea. Have you reached any progress on this otherwise?</p>
<p>As on Windows there appears to be enough ‘shared memory’ still available outside my real GPU-memory, probably this UVM-initiative could be helpful?<br>
<a href="https://github.com/pytorch/pytorch/issues/44380" rel="noopener nofollow ugc">Support for NVIDIA UVM technology · Issue #44380 · pytorch/pytorch (github.com)</a></p>