Torch._dynamo hit config.cache_size_limit when adding LR scheduler

visionscaper: <p>I’m currently looking into using <code>torch.compile()</code>. Everything works great, however when I add a scheduler.step() at the end of a compiled training step (I update the LR per batch training step), I’m getting warnings (same for each rank):</p>
<p>After the first 12 steps:</p>
<blockquote>
<p>torch._dynamo.convert_frame: [WARNING] torch._dynamo hit config.cache_size_limit (8)<br>
torch._dynamo.convert_frame: [WARNING]    function: ‘step’ (/root/.virtualenvs/mlpug/lib/python3.10/site-packages/torch/optim/adamw.py:151)<br>
torch._dynamo.convert_frame: [WARNING]    <strong>last reason: L[‘self’].param_groups[0][‘lr’] == 4.8361308593749987e-05     # has_complex = self._init_group(  # optim/adamw.py:176 in step</strong><br>
torch._dynamo.convert_frame: [WARNING] To log all recompilation reasons, use TORCH_LOGS=“recompiles”.<br>
torch._dynamo.convert_frame: [WARNING] To diagnose recompilation issues, see <a href="https://pytorch.org/docs/master/compile/troubleshooting.html" class="inline-onebox" rel="noopener nofollow ugc">PyTorch 2.0 Troubleshooting — PyTorch master documentation</a>.</p>
</blockquote>
<p>After step 16:</p>
<blockquote>
<p>…<br>
torch._dynamo.convert_frame: [WARNING]    function: ‘adamw’ (/root/.virtualenvs/mlpug/lib/python3.10/site-packages/torch/optim/adamw.py:279)<br>
torch._dynamo.convert_frame: [WARNING]    <strong>last reason: L[‘lr’] == 3.208388020496905e-05                              # if foreach and isinstance(lr, Tensor) and not capturable:  # optim/adamw.py:320 in adamw</strong><br>
…</p>
</blockquote>
<p>After step 20:</p>
<blockquote>
<p>…<br>
torch._dynamo.convert_frame: [WARNING]    function: ‘_multi_tensor_adamw’ (/root/.virtualenvs/mlpug/lib/python3.10/site-packages/torch/optim/adamw.py:479)<br>
torch._dynamo.convert_frame: [WARNING]    <strong>last reason: L[‘lr’] == 2.6132520951198568e-05                             # if isinstance(lr, Tensor) and not capturable:  # optim/adamw.py:503 in _multi_tensor_adamw</strong><br>
…</p>
</blockquote>
<p>After that no more warnings … but the training step is 3-4 times as slow.</p>
<p>Have this been observed before when using scheduler.step() per (compiled) batch training step? Is there a specific way this can be resolved?</p>
<p>Thanks,<br>
– Freddy</p>

visionscaper: <p>PS1: It seems to me that the training step is recompiled everytime the LR is changed. However, that doesn’t make much sense to me because it doesn’t change the graph or the size of tensors in any way. It would be great if someone can explain this.</p>

visionscaper: <p>PS2: When setting:</p>
<blockquote>
<p>torch._dynamo.config.cache_size_limit = 64</p>
</blockquote>
<p>The training steps are slow, implying that the step function is recompiled with every call.<br>
Further, the warnings now start after step 69, which makes sense now that the cache size is much bigger.</p>

visionscaper: <p>I gathered some batch training times at a few (semi-random) steps with and without LR scheduling per batch, see the table below. In both cases the training step time converge to the same duration, but the training steps with LR scheduling need much more time to converge (a lot of recompilation going on I guess).</p>
<pre><code class="lang-auto">--------------------------------------------------------------------------
| Epoch | Batch step | Batch training time     | Batch training time     |
|       |            | (NO LR scheduler)       | (With scheduler.step()) |
--------------------------------------------------------------------------
|   0   |    10/976  |        12937ms          |     21789ms             |
|   0   |    20/976  |         7011ms          |     26957ms             |
|   0   |   300/976  |         1718ms          |      3271ms             |
|   0   |   900/976  |         1474ms          |      1994ms             |
|   2   |   430/976  |         1338ms          |      1339ms             |
--------------------------------------------------------------------------
</code></pre>
<p><a class="mention" href="/u/ptrblck">@ptrblck</a> <a class="mention" href="/u/marksaroufim">@marksaroufim</a> do you have any idea why a <code>torch.optim.lr_scheduler</code> scheduler could cause so much havoc for <code>toch.compile</code>? It is only changing the <code>lr</code> per parameter group …</p>
<p>Next would maybe be to log all compilation reasons (<code>TORCH_LOGS=“recompiles”</code>), but I can imagine that you already came across this issue; LR scheduling at the batch training level is normal for LLM training where we don’t train for many epochs.</p>

marksaroufim: <p>Which PyTorch version are you using? IIRC latest released fixed some issues with LR schedulers, could you please try nightlies? If that doesn’t’ work then it’d be worth opening an issue on Github and tagging me since this is important</p>

visionscaper: <p>Hi <a class="mention" href="/u/marksaroufim">@marksaroufim</a>, thanks for your reply.</p>
<p>In my previous message I used the following PyTorch version:</p>
<blockquote>
<p>$ pip show torch<br>
Name: torch<br>
Version: 2.2.1<br>
Summary: Tensors and Dynamic neural networks in Python with strong GPU acceleration<br>
Home-page: <a href="https://pytorch.org/" rel="noopener nofollow ugc">https://pytorch.org/</a><br>
Author: PyTorch Team<br>
Author-email: <a href="mailto:packages@pytorch.org">packages@pytorch.org</a><br>
License: BSD-3<br>
Location: /root/.virtualenvs/mlpug/lib/python3.10/site-packages<br>
Requires: filelock, fsspec, jinja2, networkx, nvidia-cublas-cu12, nvidia-cuda-cupti-cu12, nvidia-cuda-nvrtc-cu12, nvidia-cuda-runtime-cu12, nvidia-cudnn-cu12, nvidia-cufft-cu12, nvidia-curand-cu12, nvidia-cusolver-cu12, nvidia-cusparse-cu12, nvidia-nccl-cu12, nvidia-nvtx-cu12, sympy, triton, typing-extensions<br>
Required-by:</p>
</blockquote>
<p>I tried the same experiment with Nightly and found that the performance is even worse, it takes even longer for the duration to converge, however the final batch step training duration is slightly better than before.</p>
<blockquote>
<p>$ pip show torch<br>
Name: torch<br>
Version: 2.3.0.dev20240228+cu121<br>
Summary: Tensors and Dynamic neural networks in Python with strong GPU acceleration<br>
Home-page: <a href="https://pytorch.org/" rel="noopener nofollow ugc">https://pytorch.org/</a><br>
Author: PyTorch Team<br>
Author-email: <a href="mailto:packages@pytorch.org">packages@pytorch.org</a><br>
License: BSD-3<br>
Location: /root/.virtualenvs/mlpug/lib/python3.10/site-packages<br>
Requires: filelock, fsspec, jinja2, networkx, nvidia-cublas-cu12, nvidia-cuda-cupti-cu12, nvidia-cuda-nvrtc-cu12, nvidia-cuda-runtime-cu12, nvidia-cudnn-cu12, nvidia-cufft-cu12, nvidia-curand-cu12, nvidia-cusolver-cu12, nvidia-cusparse-cu12, nvidia-nccl-cu12, nvidia-nvtx-cu12, pytorch-triton, sympy, typing-extensions<br>
Required-by: torchaudio, torchvision</p>
</blockquote>
<pre><code class="lang-auto">----------------------------------------------------------------------------------------------------
| Epoch | Batch step | Batch training time     | Batch training time     | Batch training time     |
|       |            | (NO LR scheduler)       | (With scheduler.step()) | (With scheduler.step()) |
|       |            | (PyTorch 2.2.1, Cu12)   | (PyTorch 2.2.1, Cu12)   | (PyTorch Nightly, Cu121)|
----------------------------------------------------------------------------------------------------
|   0   |    10/976  |         12937ms         |      21789ms            |      23120ms            |
|   0   |    20/976  |          7011ms         |      26957ms            |      28752ms            |
|   0   |   300/976  |          1718ms         |       3271ms            |       3419ms            |
|   0   |   900/976  |          1474ms         |       1994ms            |       2036ms            |
|   2   |   430/976  |          1338ms         |       1339ms            |       1328ms            |
----------------------------------------------------------------------------------------------------
</code></pre>
<p>I will open an issue on Github and tag you there.</p>

visionscaper: <p>PyTorch Github issue filed <a href="https://github.com/pytorch/pytorch/issues/120934" rel="noopener nofollow ugc">here</a>.</p>