Debug Why This PyTorch Model Is Not Learning
Apply the systematic debugging method from PyTorch Zero to Hero Step 08 to a real repository without guessing or rewriting the model prematurely.
How to use this
- Open a repository-aware AI assistant.
- Give it access to the repository or files you want reviewed.
- Copy the prompt below and run it unchanged first.
- Use the evidence it finds to decide what to inspect or change next.
PromptCopy and run against your own project
You are debugging a PyTorch model that runs but is not learning correctly.
Do not begin by changing the architecture, optimizer, learning rate, or model size.
First determine where learning actually breaks.
Inspect the repository and trace one complete training path from batch creation to parameter update.
Work in this order:
1. Establish the symptom.
- What metric or loss indicates that learning is failing?
- Is the failure flat loss, divergence, oscillation, overfitting, underfitting, NaNs, or apparently correct training with bad evaluation?
- Identify the exact training command/configuration if available.
2. Trace the data.
- Inspect dataset construction, transforms, batching, labels/targets, masks and splits.
- Verify representative input and target shapes, dtypes, ranges and devices.
- Look for train/eval leakage or preprocessing differences.
3. Trace the forward pass.
- Record important tensor shapes through the model.
- Check accidental broadcasting, wrong dimensions, silent reductions, masking errors and activation assumptions.
4. Trace the loss.
- Verify output and target semantics match the chosen loss.
- Check logits versus probabilities, label encoding, reduction, masking and class dimensions.
- Identify whether the observed loss scale is plausible.
5. Trace autograd.
- Identify trainable parameters expected to receive gradients.
- Look for detach(), no_grad(), tensor recreation, in-place operations or frozen parameters that break the graph.
- Determine whether gradients are absent, zero, exploding, NaN or merely small.
6. Trace the optimizer update.
Verify the actual order of:
- zero/reset gradients
- forward
- loss
- backward
- clipping, if any
- optimizer step
- scheduler step
Confirm the optimizer owns the intended parameters.
7. Compare train and evaluation modes.
- Check model.train() / model.eval().
- Check dropout, batch normalization, inference-mode behavior and metric calculations.
8. Only after correctness checks, inspect optimization choices.
Consider learning rate, scheduler, initialization, batch size, normalization and capacity only if the earlier path is coherent.
For every finding provide:
- file and symbol
- observed evidence
- why it can prevent or distort learning
- confidence: high / medium / low
- smallest test or change that can confirm the diagnosis
End with:
A. Most likely root cause
B. Confirmed defects
C. Plausible but unproven causes
D. Experiments to run next, ordered by information value
E. Architectural changes that should NOT be attempted yet
Do not declare the problem solved because the code looks conventional.
Do not recommend a larger model or more training until the existing learning path has been verified.