Optimization checkpoint 2026-11-05
An optimization checkpoint is a saved description of an ongoing optimization algorithm from which its optimizer updates can resume. It combines the current parameters with the relevant optimizer state. The practical criterion is optimizer restart equivalence: after restoring the saved information and supplying the same subsequent inputs, the chosen update rule should produce the same subsequent states.
For a deterministic scalar example, minimize the quadratic function with gradient , learning rate and momentum buffer recurrence , followed by . Start with . After one step the saved pair is . Restoring both gives and . Restoring only and initializing a new momentum buffer to zero gives and . Equal saved parameters can therefore lead to unequal continuations. These numbers are an original calculation for the declared recurrence.
In PyTorch, a general training checkpoint commonly serializes separate model and optimizer dictionaries, together with the training position. The model dictionary contains learned parameters and registered model buffers; the optimizer dictionary contains its own changing state and group settings.[ref]
Saving and Loading Models in the PyTorch tutorials. What is a state_dict?; Saving & Loading a General Checkpoint for Inference and/or Resuming Training
Restoring the optimizer state-to-parameter association also matters: the optimizer loader pairs stored identifiers with parameters in group order, without independently establishing that they denote the same mathematical parameters.[ref]torch.optim in the PyTorch documentation. PyTorch2.15, Optimizer.state_dict, state/param_groups and loading note
The required checkpoint boundary depends on the computation being resumed. A changing learning rate schedule, the next position in the training data, and the state of a pseudorandom number generator can influence future updates. Matching them is part of computational reproducibility; a saved parameter vector alone does not specify the whole training process.
Optimizer restart equivalence 2026-11-05
Optimizer restart equivalence means that restoring an optimization checkpoint reproduces the uninterrupted optimizer's parameter sequence for a specified subsequent computation. State the optimizer update rule, continuation inputs and intended notion of equality. Exact mathematical equality and agreement within a numerical tolerance are different claims.
For a deterministic algorithm modeled by , equality of the restored full state at step , together with the same update rule and future inputs , is sufficient. One application of gives equal next states; mathematical induction then gives equal continuations. This is a sufficient condition for the chosen observations, not a claim that every internal field must always affect them.
For an original exact example, take andFrom , one step gives . Restoring that pair gives and , exactly as uninterrupted execution. Resetting the buffer while restoring gives and . Thus a parameter-only save is not restart-equivalent for this recurrence.
Practical checkpoints must also retain the optimizer state-to-parameter association and the relevant settings, update position, learning rate schedule, data position and pseudorandom number generator state.[ref]
Saving and Loading Models in the PyTorch tutorials. General checkpoint for resuming training: model and optimizer dictionaries and training position
Fixing a random seed alone does not specify all of this continuation. Floating-point arithmetic and nondeterministic operations can additionally affect exact reproduction across environments; the primary documentation does not guarantee identical results across releases or platforms.[ref]Reproducibility in the PyTorch documentation. PyTorch2.15, opening reproducibility statement and controlling randomness
Warm restart (optimization) 2026-11-05
A warm restart continues an optimization process from an already obtained solution while restarting specified algorithm controls or history. Its meaning depends on which fields are retained. In SGDR, the current parameters are retained while the learning rate schedule starts another cycle; the original paper explicitly distinguishes this from starting the optimization from scratch.[ref]
SGDR: Stochastic Gradient Descent with Warm Restarts by Ilya Loshchilov and Frank Hutter. Version5, section3, printed p4, retained current solution and restarted learning rate
Write a complete algorithm state as , where holds parameters, is optimizer state and holds controls such as the schedule phase. A restart map can retain while replacing , or can also replace selected parts of . Saying only “restart” does not specify the next optimizer update.
For an original scalar example, take and the momentum buffer recurrenceAt current , stored , and restarted learning rate , retaining the buffer givesRetaining the same parameters but resetting the buffer to zero gives and . Both runs start the next update at ; they differ in the history carried through the restart.
A schedule-only restart can also change the next step without changing stored parameters immediately. In a plain gradient descent update from , increasing the learning rate from 0.01 to 0.1 changes the next value from 1.98 to 1.8. The change takes effect through the subsequent gradient step.
An optimization checkpoint instead records enough information to reproduce a specified continuation. A deliberate warm restart may intentionally alter some of that information. Record the retained parameter state, the new schedule phase and the policy for buffers or counters before comparing trajectories or claiming optimizer restart equivalence.