← Latest papers
🤖 machine learning

No Subspace to Track: Non-Identifiability and Optimizer State in Low-Rank Training

This paper demonstrates that the low-rank gradient subspace assumed to be trackable by memory-efficient optimizers like GaLore is fundamentally non-identifiable due to high estimator noise, revealing that performance gains instead stem from correctly transporting optimizer state across subspace refreshes rather than from the subspace's stability.

Original authors: Noel Thomas

Published 2026-07-08
📖 5 min read🧠 Deep dive

Original authors: Noel Thomas

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Idea: Chasing a Ghost

Imagine you are trying to teach a giant robot (a Large Language Model) to speak. To do this efficiently, the robot uses a special trick called GaLore.

The trick works like this: Every few minutes, the robot looks at the "mistakes" it just made (the gradients) and tries to find the top 128 directions where those mistakes are happening. It then ignores everything else and only learns in those 128 directions. The assumption is that these 128 directions are like a slow-moving river; they drift a little bit, but they stay mostly the same, so the robot can "track" them.

The paper's main discovery is shocking: The river isn't flowing slowly. It's not even a river. It's a waterfall that completely changes its shape every single time you look at it.

The authors prove that beyond a tiny core of about 39 directions, the "top 128 directions" the robot picks are essentially random noise. If the robot picks a set of directions now, and picks another set 10 seconds later, the two sets will be almost completely different (like two people picking 128 random numbers from a hat and getting almost no matches).

Why Does GaLore Work Then?

You might ask: "If the directions keep changing randomly, why does the robot still learn?"

The paper explains that GaLore works not because it is tracking a specific path, but because it is catching energy.

  • The Analogy: Imagine you are trying to catch rain in a bucket. You don't need to know exactly where every single drop will fall. You just need to hold the bucket in the general area where the rain is falling.
  • Even though the "top 128 directions" change completely every time, they still capture about 67–73% of the total "energy" (the useful information) of the mistakes. So, the robot keeps learning, even though it is constantly switching its map.

Why Averaging Doesn't Help

A natural idea to fix the "changing map" problem is: "Let's just look at the last 10,000 maps and average them to get a stable one."

The authors tested this and found it doesn't work.

  • The Analogy: Imagine the rain isn't just random noise; it's a specific pattern of wind and clouds (a signal). If you try to average the rain over time, you don't get a clear picture of where the rain is; you just get a blurry mess.
  • The "noise" in the robot's mistakes isn't just random static; it's a complex signal that shrinks very slowly when you try to average it out. No matter how much you average, you can never create a stable "top 128" list because the list doesn't truly exist in a stable form.

The Real Problem: The Robot's Memory

The real issue isn't the map; it's the robot's memory.
The robot uses an optimizer called Adam, which has a long-term memory (it remembers mistakes from the last 1,000 steps).

  • The Problem: Every time the robot refreshes its map (every 160 steps), the map rotates 90 degrees. But the robot's memory is still pointing at the old map. It's like driving a car where the steering wheel suddenly turns 90 degrees, but your hands are still holding the wheel in the old position. The robot is trying to steer based on a map that no longer exists.

The Solutions Found in the Paper

The authors tested two ways to fix this "steering wheel" problem:

  1. Rotate the Memory (Transport): Instead of leaving the memory stuck in the old position, the robot should physically rotate its memory to match the new map.
    • Result: This works very well. It's like realizing the steering wheel turned and immediately turning your hands to match it.
  2. Shorten the Memory: The robot's memory is too long (remembering 1,000 steps back). Since the map changes every 160 steps, remembering 1,000 steps is useless because those old steps are from a completely different world.
    • Result: By telling the robot to only remember the last 100 steps (instead of 1,000), it stops trying to steer based on outdated maps. This also works well.

The Takeaway for Builders

If you are building a system that uses these low-rank tricks, here is the advice from the paper:

  1. Don't try to track the subspace. It's a ghost. It changes too fast to be tracked.
  2. Check your "Reproducible Rank" (kk^*). Before you trust a rank of 128, check how many directions are actually real. The paper found that only about 39 are real; the rest are noise.
  3. If you use a rank higher than the real number:
    • Rotate your memory: Make sure your optimizer's memory moves with the new map.
    • Shorten your memory: Don't let the robot remember too far back.
    • Stop averaging: Don't waste time trying to average the maps to make them stable; it won't work.

In short: The "low-rank subspace" isn't a stable object you can follow. It's a rapidly changing cloud. The trick to making these systems work isn't to follow the cloud better; it's to stop trying to follow it and instead adjust your memory to handle the constant changes.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →