verl comm-eff research · weight trajectory · what breaks between GSM8K and Big-Math

Same rank-1, different projectability
What actually breaks between GSM8K and Big-Math

Two separate analyses on the same model (Qwen2.5-1.5B-Instruct, GRPO) measured two different things about the RLVR weight trajectory. This page puts them together to answer one question: when we move from an easy task (GSM8K) to a hard one (Big-Math), what part of the “weights move in a predictable line” story breaks — the rank-1 structure, or the ability to project forward?

rank-1: RANK1-ANALYSIS{,-MATH}projection: MOAT-48 (GSM8K) · MOAT-58 (Big-Math)same code paths
Answer in one line. Both properties weaken on the harder task, but by wildly different amounts. The rank-1 spatial structure only dents — the accumulated move is still ≈ one direction on both (EVR₁ 99.9% → 95.6% at W=8; 99.7% → 89.9% at W=16). But forward projectability collapses: a damped-linear projector removes 26.3% of the next-step error on GSM8K and essentially nothing (0.2%) on Big-Math, where every coefficient method falls back to “do nothing.” The reconciliation is that these two things live at different timescales: the accumulated / fitted direction is stable on both (rank-1 v₁ barely rotates step-to-step: |cos| 0.99 vs 0.98), yet the raw per-step updates are aligned only on GSM8K (cos 0.86 vs 0.15). Projection needs the next increment to continue the last one — Big-Math’s increments are near-orthogonal noise around a small drift, so the running total still lands near a line (rank-1 ✓) while the next step is unpredictable (projection ✗). Rank-1 ≠ projectable. (Big-Math is also sampled 40× coarser — see limits; the effect direction is robust, the causal split “task vs cadence” is not fully separable.)

On this page: 1 · What stays the same (rank-1) 2 · What breaks (projection) 3 · Why (the mechanism) 4 · Synthesis

1 · What only DENTS — the rank-1 spatial structure

“Rank-1” = stack a tensor’s per-checkpoint deltas and run an SVD; if one component captures almost all the energy, the accumulated move is one direction × a growing number. On both tasks it largely does: EVR₁ medians 99.7% (GSM8K) vs 89.9% (Big-Math) at a 16-checkpoint window. Big-Math is measurably weaker — a ~10-point EVR₁ drop at W=16, and ~6× more of the move sits off the line (§3) — so rank-1 is not perfectly preserved. But it only softens: the accumulated move is still overwhelmingly one-directional. Hold that next to §2, where the projectability doesn’t soften — it collapses to zero.

Rank-1 energy share EVR₁ (W=16) — SPATIAL structure→ higher = more rank-10.900.920.940.960.981.00λ₁ / trace(G) · 1.0 = pure one-direction move
GSM8KBig-Math
Both pile near 1.0 (GSM8K tighter against it). The single-direction description of the accumulated move survives the harder task — dented, not broken.

2 · What BREAKS — projecting the weights forward

Different question: given a stale anchor, can a linear rule predict where the weights go next, better than doing nothing? Metric weight_proj_ratio = projected-error / stale-error; below 1 means projection helps. On GSM8K the damped-linear projector is strongly useful at short horizons (ratio 0.74 at h=1 → removes 26.3% of the error); on Big-Math it is inert — every coefficient method collapses onto the hold-stale line.

Forward projectability — weight_proj_ratio vs horizon (Δ=5)↓ below 1 = projection beats holding stale weightsabove the line = HARMFUL (worse than doing nothing)below the line = GOOD (beats holding stale weights)0.70.80.911.11251020ratio = 1 (hold-stale / do nothing)horizon h (ticks ahead of the stale anchor)weight_proj_ratio (↓ better)
GSM8K damped_linearBig-Math damped_linearGSM8K adaptive_linearBig-Math adaptive_linear
GSM8K (blue) dips well below the break-even line and only slowly climbs back; Big-Math (red) hugs 1.0 at every horizon — the projector defaults to “do nothing.” Even the adaptive arm (dashed) can’t rescue Big-Math.
Explained variance of the projection (op Δ=5, h=10)→ higher = predicts future weights-0.6-0.4-0.200.20 = hold-staledamped_linearadaptive_linearnaive_linearpred_evr (0 = no better than stale)
GSM8KBig-Math
Explained variance of the projection at the operating point (Δ=5, h=10). GSM8K’s linear projectors explain ~+19% of the true future move; Big-Math’s explain ~0 (naive projection is actively harmful on both, far more so on Big-Math).

The projectability verdict, restated. On GSM8K the best simple projector (fixed damped-linear) beats hold-stale (op ratio 0.904, pred_evr +0.19). On Big-Math the same rule is driven to zero strength — ratio 1.000, pred_evr -0.001 — i.e. it becomes hold-stale. Neither modest GSM8K skill nor Big-Math’s null is “great,” but the direction of the difference is unambiguous: projection is useful on GSM8K and useless on Big-Math.

Op-point note: both sides use Δ=5, matched in ticks for a fair side-by-side. The canonical GSM8K record (MOAT verdict) uses Δ=10 → ratio 0.94; at Δ=5 GSM8K looks a touch better (0.90). Matched-in-ticks ≠ matched-in-steps (a Big-Math tick = 40× more training) — see limits.

3 · WHY — the reconciling mechanism (two timescales)

How can the accumulated move be rank-1 on both, yet only GSM8K be projectable? Because “direction” means two different things depending on timescale, and the two tasks agree on one and disagree on the other:

These are not contradictory — their gap is the whole story. Big-Math’s per-step updates are near-orthogonal noise around a small persistent drift: averaging a window still recovers that drift (so v₁ is stable and the move is rank-1), but the next single step is dominated by the orthogonal noise, which a linear projector cannot predict. GSM8K’s steps are themselves aligned, so the window direction and the next step are both predictable. Rank-1 lives on the cumulative timescale; projectability needs the per-step timescale — and only the latter differs between the tasks. The plot below shows the per-step statistic (the one that separates them):

Alignment of consecutive weight updates — THE mechanism→ higher = coherent path to extrapolate00.250.50.751GSM8KBig-Mathcos(Δθₜ, Δθₜ₊₁) median
GSM8K’s updates keep pointing the same way (0.86) → a coherent path to extrapolate. Big-Math’s consecutive updates are nearly orthogonal (0.15) → each step turns a fresh direction, so there is nothing for a linear rule to follow, even though the running total still lands near one line.
Along-line coefficient linearity R² (W=16)→ higher = more linear0.400.520.640.760.881.00R² of c(t)=a·t+b (how straight the along-line clock is)
GSM8KBig-Math
Consistent with the mechanism: the along-line coefficient grows less linearly on Big-Math (median R² 0.939 vs 0.985). (Per-scalar predictability R² tells the same story — Big-Math ≈ −0.99, “not linearly predictable” — but it is highly cadence-sensitive, so we lead with the two robust metrics here.)
Off-line share of accumulated Δθ (rank-1 residual)← lower = stays on one line00.10.20.30.40.5W=8W=16prefixfraction off the v₁ line
GSM8KBig-Math
The rank-1 line leaves far more of Big-Math’s accumulated move unexplained (W=8: 25.1% vs 4.5%) — the residual that incoherent steps pile up off the line.
Direction durability→ higher = lasts0.40.60.810%10%20%30%40%50%60%70%80%90%100%training progress (normalized)|cos| vs earliest v₁
GSM8KBig-Math
And the single direction is less durable over the run (|cos| to start falls to 0.46 on Big-Math vs 0.64 on GSM8K) — the same incoherence, accumulated.

4 · Synthesis

Rank-1 is necessary but not sufficient for projectability consecutive updates ALIGNED → accumulated move is RANK-1 → rank-1 + incoherent (nothing to project along) GSM8K rank-1 ✓ · aligned 0.86 PROJECTABLE (ratio 0.90) Big-Math rank-1 ✓ · aligned 0.15 NOT projectable (ratio 1.00) neither
Rank-1 is necessary but not sufficient for projection. Both tasks sit on the “rank-1” side — their accumulated weight change is one-dimensional. But projecting the weights forward also needs the trajectory to be coherent step-to-step, and that is the axis on which the two runs separate: GSM8K’s per-step updates are aligned (0.86) and projectable; Big-Math’s are near-orthogonal (0.15) and not. So what changes between the runs is not the rank-1 structure (it merely dents) — it is the per-step coherence / linear projectability of the path (it collapses). For the comm-eff ANCHOR design this gives a crisp rule that does not depend on resolving the task-vs-cadence question below: gate weight-projection on measured consecutive-update alignment — project where the path is coherent, fall back to a shorter refresh / hold-stale where it is not — rather than assuming rank-1-ness alone licenses extrapolation.
Honest limits — read the causal claim carefully. The two runs differ ~40× in snapshot cadence (GSM8K ≈0.5 steps/tick, Big-Math 20), and a Big-Math horizon of h ticks = 20h training steps vs a few for GSM8K. So “projection breaks on the harder task” cannot be cleanly separated from “projection breaks at a 40× longer horizon”: the difficulty and the cadence are confounded, and a matched-cadence GSM8K trace can’t be produced (its fp32 trace is gone). What is robust: (a) within Big-Math’s own measurable range, consec_delta_cos is flat at ≈0.15 across Δ∈{2,5,10} (40–200 steps), so the incoherence is not merely a longest-horizon artifact; (b) the rank-1 metrics use fixed checkpoint-count windows; (c) every effect’s direction is consistent. Treat the exact multipliers, and the causal split “task vs cadence,” as indicative rather than settled. Per-scalar linearity R² is cadence-fragile and is cited only in prose. The two consecutive-cosine statistics in §3 measure different timescales (window-fitted v₁ vs raw per-step update) and are reconciled there, not contradictory.

Provenance

Rank-1 axis: RANK1-ANALYSIS (GSM8K, EXP-57) and RANK1-ANALYSIS-MATH (Big-Math, EXP-58) — rank1_scorecard.py / rank1_direction.py. Projection axis: MOAT-48-ANALYSIS/scorecard-perstep (GSM8K) and MOAT-58-ANALYSIS/scorecard-pertick (Big-Math) — moat_scorecard.py, GLOBAL rows, op Δ=5. consec_delta_cos, weight_proj_ratio, pred_evr from those scorecards; EVR₁/coef-R²/off-line/direction from the rank-1 rows. Generated by scripts/projection_vs_rank1_report.py.