## TL;DR
CUDA out of memory and a NaN loss in the tracker are two symptoms of one event more often than two bugs: the allocation failure or a recovery path left the loss computation producing NaN for steps the tracker faithfully recorded. Read the run's own error around the first NaN step, reduce batch size or enable gradient checkpointing for the memory side, and treat the NaN stretch as the marker of where the run actually died.

```text
GPU training run failed error 'CUDA out of memory' logged as NaN loss in experiment tracker
```

## Use this when
- The run or call fails with this symptom: CUDA out of memory error in a GPU training run, with NaN loss logged in the experiment tracker.
- You are working on a GPU training run whose tracked loss turns to NaN and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- A genuine numerical NaN from a bad learning rate with memory fine, where the fix is optimisation settings rather than memory.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Align the tracker timeline with the job log: find the first NaN step and the first memory error and note which came first. Verify: the event order is established
2. Check peak memory drivers at that point in training: batch size changes, longer sequences, or evaluation running alongside training. Verify: the memory spike's trigger is identified
3. Apply the memory fix that fits: smaller micro-batch with accumulation, gradient checkpointing, or moving evaluation off the training device. Verify: the run passes the previous failure point
4. Fix the tracking side by logging only finite values or marking the failed segment so reports stop reading NaN as a result. Verify: the tracker shows the real loss curve and the failure point distinctly

## Variant phrasings
### cuda out of memory nan loss experiment tracker
The combined phrasing.
### gpu training oom loss became nan tracked run
The sequence phrasing.
### pytorch cuda out of memory fix batch gradient checkpointing
The memory-fix phrasing.

Compatibility: PyTorch GPU training with experiment tracking of loss values

## Why it happens
Memory failures corrupt the run's tail: steps after the failure record garbage or NaN while the tracker keeps accepting values. Reading only the tracker makes it look like a numerical collapse; reading only the log misses that the reported metrics after the spike are meaningless.

## Edge cases / pitfalls
- Evaluation on the same GPU at epoch end is the classic spike; its memory adds to a full training allocation.
- Fragmentation can OOM with free memory reported; the allocator's reserved-versus-allocated numbers tell that story.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rj-IkOwbdL5Zrm0YGL1Skg