Dein Trainingslauf crasht mit einem CUDA Out of Memory. Erklär mir, was du prüfst.

Arbeite die Speicherverbraucher der Reihe nach ab: Batch Size und Sequenzlänge, für den Backward Pass gehaltene Aktivierungen, Optimizer State und Fragmentierung durch variable Shapes. Schnelle Gegenmittel sind ein kleinerer Batch mit Gradient Accumulation, um die effektive Batch Size zu erhalten, Gradient Checkpointing, bf16 und ein speichereffizienter Optimizer. Prüf außerdem, dass du keine Tensoren sammelst, die noch einen Computation Graph mitschleppen.

Als Erstes prüfe ich, ob es sofort stirbt oder nach ein paar hundert Steps, weil das verschiedene Bugs sind. Sofort ist ein Kapazitätsproblem, wachsend ist ein Leck. Bei Kapazität schlüssele ich auf, was tatsächlich resident ist: Gewichte, Gradienten, Optimizer State (bei Adam sind das zwei zusätzliche Kopien) und für den Backward gespeicherte Aktivierungen. Bei einem Transformer dominieren üblicherweise die Aktivierungen, und die skalieren mit Batch Size mal Sequenzlänge, das sind also die ersten Regler. Ich senke den Batch und nutze Gradient Accumulation, um die effektive Batch Size identisch zu halten, das kostet Wall Clock und sonst nichts. Danach Gradient Checkpointing, das Aktivierungen im Backward neu berechnet und grob dreißig Prozent zusätzliche Rechenzeit gegen eine große Speicherersparnis tauscht. bf16 halbiert obendrauf die Aktivierungsgröße. Wenn es über die Steps wächst, hält etwas einen Graphen. Der Klassiker ist, den rohen Loss-Tensor fürs Logging an eine Liste zu hängen, was den Computation Graph jedes Steps am Leben hält, und die Lösung ist ein Aufruf von item darauf. Ich bestätige das, indem ich alle hundert Steps allocated und reserved memory ausgebe, denn eine saubere Treppe nach oben ist das Verräterische.