How does L-BFGS make Newton-style optimization affordable for a 10,000-parameter model?
answer
- never form the matrix at all
- curvature read off successive gradients
- store pairs, not a d-by-d matrix
- m trades memory for curvature fidelity
- noisy gradients poison the stored pairs
basics
~10 sL-BFGS never forms an inverse Hessian. It stores only m recent pairs of parameter and gradient differences and rebuilds the step from them, cutting memory from about d squared entries to m times d.
solid answer
~50 sAt 10,000 parameters the exact Newton step is out of reach: a dense Hessian is 10^8 entries, and factorizing it costs on the order of d^3 arithmetic per iteration. Quasi-Newton methods sidestep the second derivatives by *learning* curvature from the trajectory: each iteration contributes a pair `s = x_new - x_old` and `y = g_new - g_old`, and BFGS uses those to update an approximation of the inverse Hessian. Plain BFGS still keeps a dense d-by-d matrix, so it is no better on memory. L-BFGS keeps only the last m pairs, typically 5 to 20, and computes the product of the implicit inverse-Hessian approximation with the current gradient by a two-pass recursion over those pairs, at O(m*d) memory and time. Larger m models curvature more faithfully but costs memory and can retain stale pairs from a region of the surface you have left; smaller m degrades toward a first-order step. It also assumes reasonably accurate gradients, since noisy differences corrupt the stored curvature pairs.
go deeper
Know that a full Hessian is quadratic in the parameter count and quickly becomes impossible to store, and that quasi-Newton methods approximate curvature from gradients instead.
Explain the secant relation between the step and the gradient difference, why BFGS still stores a dense matrix, and what limited memory replaces it with.
Show operational judgment: pick m for the memory you have, insist on a proper line search, and recognise when gradient noise makes the stored curvature pairs worthless.
Own the call between a quasi-Newton method on full-data gradients and a cheaper iterative scheme, and articulate what the choice costs in engineering complexity, reproducibility and wall-clock time.
## Why the exact step is unaffordable For a model with d = 10,000 parameters, the Hessian is a 10,000-by-10,000 symmetric matrix. That is 10^8 entries — roughly 800 MB in double precision — and you would need to build it fresh at every iteration. Solving the linear system for the Newton step costs on the order of d^3, about 10^12 arithmetic operations. Even where the memory fits, the per-iteration cost is out of proportion to what the step buys. Anything past a few thousand parameters therefore needs an approximation. ## The quasi-Newton idea Quasi-Newton methods refuse to compute second derivatives at all. Instead they infer curvature from the gradients they have already paid for. Between two consecutive iterates define ``` s = x_new - x_old (the step taken) y = g_new - g_old (the change in gradient) ``` For a quadratic these satisfy `y = H s` exactly, and in general they satisfy it approximately over the region traversed. The **secant condition** demands that the maintained approximation `B` of the inverse Hessian reproduce this: `B y = s`. That is one matrix equation with far fewer constraints than unknowns, so a specific update rule is chosen to fill the gap. BFGS picks the update that satisfies the secant condition, stays symmetric, and changes the previous approximation as little as possible in a particular matrix norm — and, crucially, preserves positive definiteness as long as `s^T y > 0`, a curvature condition that a line search satisfying the Wolfe conditions enforces. Positive definiteness matters because it is what keeps every step a descent direction. ## What limited memory changes Plain BFGS carries the dense approximation explicitly. For d = 10,000 that is the same 10^8 entries the Hessian had, so the memory problem is not solved — only the second derivatives are avoided. L-BFGS makes the decisive move: never materialise the matrix. Observe that the only thing the algorithm ever needs is the **product** of the inverse-Hessian approximation with the current gradient. That product can be computed directly from a list of stored `(s, y)` pairs by a two-pass recursion — one backward sweep accumulating scalar coefficients, a scaling in the middle, one forward sweep correcting them. Keeping only the m most recent pairs and discarding the rest gives: - **Memory:** on the order of `m * d` numbers. With m = 10 and d = 10,000 that is 200,000 doubles, a couple of megabytes, versus hundreds of megabytes for the dense form. - **Per-iteration cost:** on the order of `m * d` arithmetic — a few dozen vector dot products and scalings — plus whatever the gradient evaluation itself costs. ## Choosing m m is the one real knob. Small m (say 3) keeps almost no curvature history and the method behaves closer to a scaled first-order step; convergence needs more iterations. Large m (say 50 or 100) captures more curvature directions but multiplies memory and per-step work, and has a subtler cost: old pairs describe curvature at points the optimizer has since left, and on a strongly non-quadratic surface stale pairs can actively mislead the step. The conventional range of roughly 5 to 20 reflects that the benefit saturates quickly. Implementations also discard any pair violating the curvature condition `s^T y > 0`, since accepting it would destroy positive definiteness. ## Operating conditions Two practical caveats decide whether L-BFGS is the right choice. **Gradient quality.** The stored pairs are *differences* of gradients. If gradients are noisy — for instance evaluated on a different random subset of data each iteration — the differences are dominated by noise rather than curvature, and the approximation degrades or becomes actively harmful. L-BFGS is at its best with deterministic or very-low-noise gradients, which is why it is a natural fit for full-data convex fits and smooth scientific objectives. **Line search.** The theory relies on step lengths that satisfy sufficient-decrease and curvature conditions. An implementation that takes fixed-length steps loses the positive-definiteness guarantee and can produce garbage curvature pairs. ## The short interview answer Name the cost that makes exact Newton impossible at d = 10,000, explain that quasi-Newton reads curvature off successive gradients rather than computing it, and then make the limited-memory point precisely: the matrix is never formed, only its action on the gradient, reconstructed from m stored pairs. Finish with the m tradeoff and the sensitivity to gradient noise, and you have covered what the question is actually probing.
- What distinguishes L-BFGS from plain BFGS in memory terms?Plain BFGS maintains a dense d-by-d approximation of the inverse Hessian, so at 10,000 parameters it still needs about 10^8 stored numbers. L-BFGS never builds that matrix; it keeps the last m pairs of step and gradient-difference vectors and computes the matrix-vector product it needs from them, so memory scales as m times d. Both avoid second derivatives; only the limited-memory form avoids quadratic storage.
- How would you choose m, and what goes wrong at the extremes?Start in the usual 5 to 20 range and raise it only if iteration counts are high and memory is spare. Too small and the step carries almost no curvature information, so it behaves closer to a first-order method. Too large and you pay memory and per-step work for pairs describing regions the optimizer has already left, which on a strongly non-quadratic surface can mislead rather than help.
- Why does noise in the gradients hurt a quasi-Newton method more than it hurts a plain first-order step?Quasi-Newton curvature comes from differences of consecutive gradients. Differencing amplifies noise relative to signal, so when each gradient carries independent error the pairs describe noise rather than the surface, and the resulting steps can be worse than an unmodified gradient step. This is why L-BFGS is usually run on deterministic or very-low-noise gradient evaluations.
- Why do implementations reject a curvature pair when s^T y is not positive?The positivity of `s^T y` is exactly the condition that keeps the maintained approximation positive definite, and positive definiteness is what guarantees the computed direction is a descent direction. A pair violating it would let the approximation admit a negative-curvature direction and produce an uphill step, so implementations skip such pairs or reset the history.
Instead of carrying a full map of the terrain, you keep notes on your last ten strides and how the slope changed during each, and reconstruct just enough of the shape to choose the next stride.
saying these in an interview costs you the question
- Says BFGS itself solves the memory problem
- Believes L-BFGS computes second derivatives
- Thinks bigger m is always better
- Applies it happily to heavily noisy gradients
- Claims quasi-Newton keeps the exact quadratic convergence rate