A local minimum is a point on the loss surface where every small step in any direction increases the loss, but a better solution exists somewhere else. Training halts there because gradient descent only sees the immediate neighbourhood. In practice, for deep networks with many parameters, true local minima are rarer than the phrase suggests — most stalls are saddle points, a learning rate that has decayed too far, or a plateau caused by saturated activations. Diagnosing which one you have matters, because the three have different fixes.
A flat loss curve is a symptom, not a diagnosis. Reaching for a different optimiser before identifying the cause is the most common way a week of GPU time gets spent without moving the metric.
What problem does this solve?
A telecom churn model trains for forty epochs. Loss falls sharply for six epochs, settles at 0.42, and stays there. Validation accuracy sits at 71% when the business case needed 80%. The team doubles the epochs, sees nothing change, and concludes the model has hit its ceiling.
That conclusion is usually premature. A flat curve has several possible causes and they are not interchangeable: the optimiser may be in a genuine basin, it may be at a saddle point where the gradient is near zero but not minimal, the learning rate may have decayed until steps are too small to escape anything, or half the ReLU units may have died and stopped passing gradient at all.
Because these look identical on a loss plot, teams often cycle through optimisers at random. Adam, then SGD with momentum, then back to Adam with a different learning rate — a lot of compute spent without a hypothesis.
How the solution works
Separate the diagnosis from the fix. Log gradient norms per layer, the current learning rate, and the fraction of activations that are exactly zero. Those three numbers distinguish the four causes in a single run.
If gradients are near zero everywhere and the loss surface is flat in all directions, that is a plateau or a saddle. If gradients are healthy but the learning rate has decayed to near-nothing, the schedule is the problem. If a large fraction of ReLU outputs are zero, the units are dead and no optimiser change will help.
The interventions differ accordingly: warm restarts and momentum for saddles, a revised schedule for over-decay, weight re-initialisation or a LeakyReLU for dead units, and a genuinely different initialisation seed when you suspect a real basin.
- 1Gradient descent is local Each step moves parameters against the gradient computed at the current point. Nothing in the update rule can see beyond the immediate neighbourhood.
- 2A minimum is where the gradient vanishes At a stationary point the gradient is zero, so the update becomes zero and training stops moving regardless of how many epochs remain.
- 3Curvature decides the type If every direction curves upward the point is a local minimum. If some directions curve down it is a saddle point, and escape is possible.
- 4High dimensions favour saddles For a point to be a true local minimum, every one of millions of directions must curve upward simultaneously — statistically far less likely than at least one curving down.
- 5Momentum carries through Accumulated velocity lets the optimiser continue past a region of near-zero gradient rather than stopping in it.
Reference architecture
Four independent factors shape whether training escapes a flat region. Changing them together makes the result uninterpretable.
| Layer | What it contains |
|---|---|
| Loss surface | Determined by architecture, loss function and data. Wider layers and skip connections tend to produce fewer isolated basins. |
| Initialisation | Where on the surface training begins. He or Xavier initialisation avoids starting in saturated regions. |
| Update rule | Momentum, Adam and RMSProp each carry different amounts of history through low-gradient regions. |
| Schedule | Learning rate over time. Warm restarts deliberately raise it again to escape regions a decayed rate cannot leave. |
Deployment options: Relevant on any training hardware, but the cost of the mistake scales with it. On a multi-GPU node an unnecessary re-run is measured in hours of compute, which is why diagnosis before intervention pays for itself quickly.
Key capabilities
Training-run instrumentation
Gradient norms, learning rate and dead-unit fractions logged per layer so a stall has a cause rather than a guess.
availableSchedule and restart design
A learning-rate schedule with warm restarts sized to the actual epoch budget.
availableInitialisation review
Initialisation matched to the activation function so training does not begin in a saturated region.
custom developmentCompute-efficiency assessment
An honest judgement of whether more GPU hours will help before hardware is ordered.
custom developmentIntegrations
Optimisation diagnostics belong in the training platform rather than in a notebook, because the value comes from comparing runs.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| Experiment tracking | Loss curves, gradient norms and schedules logged per run so two runs can be compared meaningfully. | bi-directional |
| Training orchestration | Checkpoints allow a run to be resumed from before the stall with a modified schedule. | bi-directional |
| Compute platform | GPU utilisation correlated with training progress, so idle capacity is visible. → AI Products Portfolio | bi-directional |
Industry use cases
Telecom churn prediction
Tabular networks on wide feature sets plateau early; the cause is usually schedule or dead units rather than surface geometry.
Retail demand forecasting
Sequence models stall when gradients vanish over long horizons, which reads as a plateau but is a different problem.
Industrial anomaly detection
Autoencoders settle into reconstructing the mean; momentum and restarts often break the symmetry.
Document classification
Fine-tuning a pretrained encoder with too high a learning rate destroys pretrained structure and produces a stubborn plateau.
UAE & GCC considerations
Where training must stay on-premise for data residency, GPU capacity is fixed and cannot be elastically expanded mid-project. That makes diagnosis before intervention a budget question rather than an engineering preference: each speculative re-run consumes capacity that another workload needs. Confirm the available node hours, the queueing policy and who authorises a re-run before planning a training schedule.
Implementation approach
- 1Instrument first Log gradient norm, learning rate and dead-unit fraction before changing anything.
- 2Rule out the schedule If the learning rate has decayed to near zero, that alone explains the stall.
- 3Check for dead units A large fraction of exactly-zero ReLU outputs means no optimiser change will help.
- 4Add momentum or restarts For a genuine flat region, momentum and cosine warm restarts are the cheapest effective interventions.
- 5Change one thing at a time Altering the optimiser, schedule and initialisation together makes the result impossible to attribute.
Security & deployment
Training logs record gradient statistics and loss values, not raw records, and are generally safe to retain outside the data boundary. Checkpoints are a different matter: model weights fitted on sensitive data can leak information about that data and should be stored under the same controls as the training set itself.
A worked example
Take the one-dimensional function L(x) = x^4 - 3x^3 + 2, which has a shallow dip and a deeper one, to see how the starting point decides the outcome.
- The derivative. L'(x) = 4x^3 - 9x^2 = x^2 * (4x - 9), so stationary points sit at x = 0 and x = 2.25.
- Classify them. L''(x) = 12x^2 - 18x. At x = 2.25, L'' = 20.25 > 0, a genuine minimum. At x = 0, L'' = 0 — a saddle-like inflection, not a minimum at all.
- Start at x = 0.05. The gradient is 4(0.000125) - 9(0.0025) = -0.0220, tiny. With a learning rate of 0.01 the step is 0.00022. Progress is glacial and the curve looks flat.
- Add momentum. With momentum 0.9, accumulated velocity builds across steps and carries the parameter through the flat region toward x = 2.25.
Same function, same optimiser, different outcome — decided entirely by whether the update rule could accumulate velocity through a flat region. The loss curve for the first case looks exactly like a model that has 'converged'.
In code
Rather than guess, instrument the run. This logs the three quantities that separate the causes.
import torch
import torch.nn as nn
model = nn.Sequential(
nn.Linear(32, 128), nn.ReLU(),
nn.Linear(128, 64), nn.ReLU(),
nn.Linear(64, 1),
)
optimizer = torch.optim.SGD(model.parameters(), lr=0.05, momentum=0.9)
scheduler = torch.optim.lr_scheduler.CosineAnnealingWarmRestarts(
optimizer, T_0=10, T_mult=2,
)
dead_relu_fraction = {}
def record_dead(name):
def hook(_module, _inp, out):
dead_relu_fraction[name] = (out == 0).float().mean().item()
return hook
for i, layer in enumerate(model):
if isinstance(layer, nn.ReLU):
layer.register_forward_hook(record_dead(f"relu_{i}"))
def diagnose(step):
total = 0.0
for p in model.parameters():
if p.grad is not None:
total += p.grad.detach().norm().item() ** 2
grad_norm = total ** 0.5
lr = optimizer.param_groups[0]["lr"]
print(f"step={step} grad_norm={grad_norm:.6f} lr={lr:.6f} dead={dead_relu_fraction}")
# grad_norm ~ 0 and lr healthy -> plateau or saddle: try warm restarts
# grad_norm healthy and lr ~ 0 -> schedule decayed too far
# dead fraction > 0.5 -> dead ReLUs: re-init or use LeakyReLUPer-step gradient norm, current learning rate and the fraction of zero ReLU outputs per layer. The combination identifies which of the three causes you are looking at; the comments map each pattern to its intervention.
Diagnostic checks
- Plot gradient norm alongside loss. A flat loss with healthy gradients is not a minimum — look at the learning rate.
- Print the current learning rate every epoch. Aggressive decay schedules frequently reach values too small to move anything.
- Measure the fraction of ReLU activations that are exactly zero. Above roughly half, dead units are the constraint.
- Restart training from a different random seed. If the plateau lands at a noticeably different loss, the surface has multiple basins.
- Overfit a single batch deliberately. If the model cannot drive loss to near zero on ten samples, the problem is capacity or a bug, not optimisation.
When to use it
- This diagnosis applies when training loss flattens well above the level the task should reach.
- Validation loss tracks training loss closely — meaning the model is not overfitting, it is failing to fit.
- The same plateau reproduces across seeds, which points to something systematic rather than an unlucky start.
- The architecture is known to be sufficient for the task, so capacity is not the limiting factor.
When not to use it
- Training loss keeps falling while validation loss rises — that is overfitting and belongs in a different diagnosis.
- The plateau sits at exactly the level a majority-class predictor would achieve, which points to class imbalance instead.
- Loss is oscillating rather than flat, which indicates a learning rate that is too high, not too low.
- The model has too few parameters for the task; no optimisation change compensates for insufficient capacity.
Limitations & prerequisites
- In high-dimensional networks, true local minima are far less common than the term's popularity suggests; most stalls are something else.
- There is no practical way to prove a point is a global minimum for a large network, so 'escaped the local minimum' is always provisional.
- Warm restarts increase total training time and can undo useful convergence if applied too aggressively.
- Momentum can carry the optimiser past a good solution as readily as past a bad one.
Telling the four causes apart
All four produce a flat loss curve. Only the instrumentation distinguishes them.
| Cause | Signature | Intervention |
|---|---|---|
| Local minimum | Gradient near zero, curvature upward, reproduces across seeds | New initialisation, wider architecture |
| Saddle point | Gradient near zero, some directions curve down | Momentum, warm restarts |
| Decayed learning rate | Gradients healthy, learning rate near zero | Revise schedule, warm restart |
| Dead ReLU units | Large fraction of activations exactly zero | Re-initialise, LeakyReLU, lower learning rate |
The instrumentation costs one run. Cycling through optimisers blindly costs several, and still leaves you without a cause.
Key takeaways
- A flat loss curve is a symptom with four common causes that look identical on a plot.
- Gradient norm, learning rate and dead-unit fraction distinguish them in a single instrumented run.
- True local minima are rarer in deep networks than the term implies — suspect saddles and schedules first.
- Momentum and cosine warm restarts are the cheapest interventions for a genuine flat region.
- Change one variable at a time, or the result cannot be attributed to anything.
FAQ
Less than the term suggests. In high-dimensional parameter spaces, a point where every direction curves upward is statistically unlikely; most stalls are saddle points, decayed learning rates or dead units.
By curvature. At a saddle some directions still curve downward, so momentum or a warm restart can escape. Practically, if restarts break the plateau it was not a minimum.
No. Adam adapts per-parameter step sizes, which helps traverse regions of uneven curvature, but it converges to stationary points like any gradient method.
Only after checking the schedule. Raising it during a genuine plateau can help, but if the plateau is caused by dead units a higher rate usually kills more of them.
Not if the gradient is effectively zero. Additional epochs at a vanished learning rate change nothing and consume compute.
Yes. It determines where on the surface training begins, and He or Xavier initialisation matched to the activation function avoids starting in a saturated region.
A schedule that periodically raises the learning rate back up after decaying it, giving the optimiser enough step size to leave a region it had settled into.
Training runs eating budget without moving the metric?
Send the loss curve, the batch size, the optimiser settings and the hardware. We will tell you whether the constraint is optimisation, data or compute before anyone orders more GPUs.
Discuss AI server sizingSources & evidence
- PyTorch: optimization — Official reference for optimisers and learning-rate schedulers including warm restarts.
- Loshchilov & Hutter, SGDR (ICLR 2017) — The paper introducing cosine annealing with warm restarts.
- Dauphin et al., Saddle point problem (NeurIPS 2014) — Evidence that saddle points, not local minima, dominate high-dimensional loss surfaces.
- TensorFlow: optimizers — Official optimiser and schedule reference.
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.