An exponentially weighted gradient history assigns geometrically decreasing coefficients to older supplied gradients. For constant and momentum buffer recurrence ,
Each additional update multiplies an old contribution by . The formula follows by substituting the expression for into the recurrence and adding the newest exponent-zero term. The same undampened recurrence, including its initialization convention, appears in the primary stochastic gradient descent documentation.[ref]
For an original example, choose , and gradients , , . Successive buffers are 2, −1, 3.5. Directly expanding the third buffer gives
The newest contribution has coefficient 1; the oldest has coefficient 1/4. The buffer is a weighted sum, not yet a weighted mean. At , its coefficient sum is the geometric series
Here , so the normalized weighted mean is , rather than the ordinary mean .
The coefficients also give a concrete memory scale. In the infinite geometric sequence, the fraction assigned to the newest gradients is . At , 29 gradients account for at least 95% of that coefficient mass, because whereas . This is a statement about coefficients, not a guarantee that gradients at different times are independent or that the optimizer averages a stationary process.
Learning rate 2026-11-05
A learning rate controls the size of an iterative learning update. In gradient descent, it scales a direction obtained from the gradient of a loss:
A stochastic gradient descent update uses an estimated gradient in this expression. The documented SGD algorithm makes the learning rate an explicit multiplier; momentum and other modifications add separate behavior.[ref]
A scalar example shows why size matters. For , the gradient is , so a constant learning rate gives
For nonzero initial value, convergence to zero occurs exactly when , or . With and , the values are . With , they begin : increasing the step has made the iteration diverge rather than merely learn faster.
This threshold belongs to the stated quadratic. Changing curvature changes the allowed scale: for with , the same proof gives . A numerical learning rate therefore has meaning only together with the objective and update rule.
In reinforcement learning, an incremental value estimate can instead use the update . For an illustrative , observed target and , the new estimate is . Here the learning rate weights new evidence against the previous estimate, showing the same step-size idea without requiring a gradient calculation.
A learning rate schedule can vary the rate with iteration. Report the schedule, objective scaling and other update settings when comparing results; the rate alone does not determine stability or final accuracy.
Learning rate schedule 2026-11-05
A learning rate schedule specifies how the learning rate changes during an iterative learning procedure. Its rule can depend on the update count, a training epoch count or another declared event. The rule and the clock must both be stated: changing a rate every parameter update is different from changing it after a complete pass through the training data.
A simple step-decay example is
where counts completed schedule advances from zero. The values at are , those at are , and the value at is . The StepLR implementation documents periodic multiplication by a specified factor; its example advances the scheduler after the training and validation operations.[ref]
A different schedule admits an exact convergence calculation. For gradient descent on , take . With no other update terms,
Multiplying the successive ratios gives a telescoping product:
Starting at gives . This proves convergence for the stated deterministic quadratic, rather than for every objective or noisy learning procedure.
The underlying stochastic gradient descent update also depends on its gradient estimate and any additional terms, not just the scheduled scalar.[ref] Report the initial index, update order and any external changes to the rate. The StepLR documentation explicitly permits other changes alongside its own, so the isolated step formula above assumes that no competing rule intervenes.[ref]
Momentum buffer 2026-11-05
A momentum buffer stores an accumulated history of gradients for an optimization algorithm. In one common convention, a parameter vector , supplied gradient , learning rate and constant coefficient obey the recurrence relation
The buffer belongs to the optimizer state: it remembers earlier inputs even when the current parameters are unchanged. This is the undampened momentum convention used by PyTorch stochastic gradient descent with weight decay and the Nesterov accelerated gradient method disabled; its documented first buffer is the first gradient, agreeing with this recurrence from . Other conventions absorb the learning rate into the stored buffer, so a buffer value needs its update convention to be interpreted.[ref]
Repeated substitution gives the exponentially weighted gradient history
To verify this identity, substitute its expression for into : multiplication by raises every old exponent by one, and the added is precisely the new exponent-zero term. The formula holds at because its sum is empty, completing the mathematical induction.
For an original scalar example with and a constant supplied gradient , the geometric series yields . At , and the limit is 10. The buffer is an unnormalized sum: multiplying it by changes its scale, and would require a corresponding learning rate adjustment to preserve these parameter updates.
The same memory explains why momentum can temporarily oppose the current gradient. If , and the new scalar gradient is , then . With a positive learning rate, the parameter still decreases, although the present negative gradient alone would call for an increase. Persistence can carry motion through rapidly alternating gradients, but this example also shows why the rule need not decrease the objective function at every step.
A momentum buffer can retain enough earlier history that it points against the current gradient. For the undampened rule
the parameter step is for positive learning rate . If , then the directional derivative in direction is . The actual update direction is therefore locally uphill for a differentiable objective function, even though gradient descent would use the opposite direction. This history-dependent recurrence is the non-Nesterov momentum convention documented for stochastic gradient descent with dampening and weight decay disabled.[ref]
For an original scalar example, let , current , stored buffer , coefficient and . The new gradient is 1, but
The objective increases from to . This is a fully specified finite step, not only a first-order prediction.
More generally,
An old buffer sufficiently opposed to the new gradient makes this negative. At , that mechanism disappears. The example explains why a momentum method need not decrease the objective at every step; it does not imply that retaining gradient history always harms convergence. A descent direction test concerns the direction at the current point, while a convergence claim concerns an entire sequence.
Optimizer state 2026-11-05
The optimizer state is information retained by an optimization algorithm beyond the current parameter values. It can include a momentum buffer and algorithm-specific counters or running estimates. Consequently, two runs with identical parameters and current gradients can produce different next optimizer updates if their stored states differ.
For an original scalar example, minimize with the recurrence
This is the momentum form with dampening, decay and the nesterov flag disabled in the PyTorch stochastic gradient descent implementation.[ref] At , and , a stored gives and . A stored instead gives and . The current parameter and gradient were identical; the difference came from history.
An optimization checkpoint that saves only the parameters cannot reproduce that next step. In PyTorch, Optimizer.state_dict() stores per-parameter state and parameter-group settings such as learning rate, but not the parameter values themselves. Its parameter identifiers associate state with ordered parameter groups and are not a check of semantic parameter identity during loading.[ref] Save and restore the corresponding parameters separately and keep the state-to-parameter association consistent. Reproducing an entire training run may additionally require the data order and other changing state.
Figure 1.
Original deterministic quadratic model: keeping or resetting the momentum buffer gives different trajectories from the same parameter value
. Details.
Optimizer update 2026-11-05
An optimizer update changes the adjustable parameters of an optimization problem according to an algorithm's current information. Evaluating a loss function, computing its gradient and changing the parameters are distinct operations. A general update may also change an optimizer state, such as stored information from previous steps:
Here is the supplied gradient and a learning rate. The PyTorch interface makes this separation explicit with gradient computation followed by optimizer.step().[ref]
For plain gradient descent with no extra state, . In an original scalar example, choose , and . The gradient is 2, so the update gives and lowers the loss from 2 to 1.62. Recompute the gradient at the new parameter value to obtain . Reusing the old gradient 2 instead would give 1.6. This explicitly locates where the algorithm obtains its information.[ref]
An update is not automatically an improvement: using for the first step above gives and loss 8. With gradient accumulation, several gradient calculations instead contribute before a single optimizer update; their weighting sets the effective batch size. Track the update count separately from the number of processed groups, particularly when applying a learning rate schedule.