Gradient Checkpointing: More Checkpoints, Higher Memory Usage

swalton: <p>So I was playing around trying to learn gradient checkpointing. I found an interesting behavior that does not match my understanding of the paper I found that there was a sweet spot for the number of checkpoints and going beyond that memory would increase. I found the exact same behavior with <code>checkpoint_sequential</code> and <code>checkpoint</code>. Here’s <a href="https://github.com/stevenwalton/Gradient-Checkpointing/blob/master/sequential/simple.py" rel="noopener nofollow ugc">a link</a> to my code with <code>checkpoint_sequential</code> (go back a dir for the non-sequential). I am working on a 2080 Super and I just made a overly simple linear model (linear, relus, and end with a sigmoid) such that it barely doesn’t fit into memory (if you want code in here I can replicate with a network that will look nicer). I get the following results</p>
<p>| Num Splits | SMI Memory |<br>
|        2          |      7212MB  |<br>
|        4          |      6000MB  |<br>
|        8          |      5428MB  |<br>
|       10         |      5810MB  |<br>
|       16         |      6190MB  |</p>
<p>The non-sequential version has similar results (one splitting actually uses 7908MB!). <code>cuda.max_memory_allocated()</code>shows the same trend (but smaller numbers) but <code>cuda.memory_allocated()</code> does not.</p>
<p>So my understanding is that the more checkpoints I do the lower my memory usage should be. Rather my results show something very different and reminds me more of how there are optimal number of CPUs to use in parallel processing (where overhead starts to use too many resources). So:</p>
<ul>
<li>Do I have a bug somewhere?</li>
<li>Am I misunderstanding the paper?
<ul>
<li>If so, how do I find the optimal number of checkpoints?</li>
</ul>
</li>
</ul>

albanD: <blockquote>
<ul>
<li>Do I have a bug somewhere?</li>
</ul>
</blockquote>
<p>I don’t think so.</p>
<blockquote>
<p>So my understanding is that the more checkpoints I do the lower my memory usage should be.</p>
</blockquote>
<p>This is not true no. The checkpointing only saves the input/output and is able to free all the buffers in the middle. But if the content of the checkpoint is too small, then there are not intermediary buffers to free and so you won’t see any memory improvement.</p>
<blockquote>
<p>If so, how do I find the optimal number of checkpoints?</p>
</blockquote>
<p>It is hard to say as it has to balance not recomputing too big a chunk (that uses a lot of memory) with not having too small a chunk (for which no intermediary buffer can be freed).<br>
You will most likely have to see it experimentally for your particular model.</p>

swalton: <p>Thanks! This makes sense to me but didn’t match my understanding of the paper.</p>
<p>Are there any best practices/intuition you or others can offer?</p>

albanD: <p>Hi,</p>
<p>I am afraid I don’t have a very large practical experience. But for vision models, it is common to checkpoint the conv/relu/norm blocks. You can check <a href="https://github.com/pytorch/vision/blob/f8e2291df81aa4e395b1caf919c2e43ebf30c127/torchvision/models/densenet.py#L82">here</a> how this is used for the torchvision models.</p>

taehyunzzz: <p>Have you discovered the reason for increasing memory when using more splits?<br>
Maybe with more splits, you get more checkpoints to keep in memory, and that causes the memory to increase?</p>