Reproducible gradient norm spike in QLoRA at step 44 on Mistral-7B — spectral norm constraint as a fix

[fourwheels2512]

While testing several PEFT techniques on Mistral-7B, we noticed a reproducible gradient norm spike specifically with QLoRA at training step 44.

What we observed:

• Gradient norm (gn) jumped to ~15.28 at step 44 vs a normal baseline of ~1.0
• This spike consistently degraded output quality by ~20.5% if left unaddressed
• Plain LoRA did not exhibit the same instability at the same step
• The root cause appears to be the 4-bit quantization introducing gradient instability that LoRA alone doesn't have as severely

Why AdaLoRA and VeRA don't fully solve this:

• AdaLoRA's better rank allocation helps efficiency but doesn't address the underlying gradient dynamics
• VeRA is highly parameter-efficient but tends to be fragile on smaller datasets where this spike is more impactful

What worked for us:
Adding a spectral norm constraint on top of the QLoRA training loop. We built this into a free tool (no GPU required) that you can use to fine-tune and compare results:

https://huggingface.co/spaces/Fourwheels2512/crma-fine-tuner

Happy to share more details on the spectral norm implementation if useful. Has anyone else hit this step-44 spike or similar instability patterns with QLoRA on 7B-class models?

[githubnemo]

Gradient norm spikes are not too unusual, especially when dealing with lower quantizations (as steps get more discrete). Have you tested using max_grad_norm in transformers.Trainer (or other gradient norm clipping utiliies provided by your training framework)?