feat(adversary): stateless sign-ascent SRC_STEP for persistent-PGD sources (SPEC §6)#943
feat(adversary): stateless sign-ascent SRC_STEP for persistent-PGD sources (SPEC §6)#943ocg-goodfire wants to merge 2 commits into
Conversation
…urces (SPEC §6)
Implements the `sign` SRC_STEP variant already named in SPEC §6:
`sources += lr·sign(grad)` with the same S15 clamp projection, configured as
`optimizer: {type: sign, lr_schedule: ...}` (discriminated union with `adam`
on PersistentPGDReconLossConfig.optimizer).
The variant is stateless: PersistentAdversary.opt_state is SourcesAdamState |
None (None iff sign), so the Adam m/v buffers never exist — on full32L that
is −19 GiB/GPU resident (2× the 9.5 GiB source bundle), on top of the
validated bf16-source win (source bundle 28.5 → ~4.75 GiB combined).
S13'/S14' lifecycle (n_warmup supplemental ascents + one final ascent from
the main backward, coeff-unscaled) is unchanged; sources_ascend_project
dispatches on the optimizer config and the adam path
(sources_adam_ascend_project) is bit-untouched. Production remains ★ adam.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ALaUCqhksKmWNbxjfmuMUi
…4L PPGD-bsc, 10k steps)
Four arms off pile_ppgd_bsc.yaml (steps 10k, dp 8, slow_every 2000, same
seed): adam control (production ★) + sign at lr {0.003, 0.01, 0.03} — a
step-size sweep since Adam's normalized update ≈ lr was tuned at 0.01 but
sign steps are exactly lr. All arms fp32 source to isolate the update rule.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ALaUCqhksKmWNbxjfmuMUi
|
Tier-1 quality A/B result: sign-ascent FAILS the gate at all three step sizes (pile-4L PPGD-bsc, 10k steps, same seed, fp32 sources; runs p-e6f2e806 adam / p-992df179 lr.003 / p-41cee32f lr.01 / p-07b7e68b lr.03). The adversary-independent robustness probe (fresh-PGD 20-step eval) vs adam control:
Conclusion: Adam's adaptive per-coordinate scaling is load-bearing for the persistent adversary (3 ascents/step tracking a moving target — unlike fresh PGD's 20 dedicated sign steps from scratch). The −19 GiB m/v saving is not available via naive sign; bf16 source+moments (#938, −14.25 GiB) remains the validated path. Full writeup: lore Merge-or-close is the team's call: the impl is a faithful SPEC §6 |
What
Implements the
signSRC_STEP variant already named as a valid instantiation in SPEC §6:sources += lr·sign(grad)with the same S15 clamp projection, selected viaoptimizer: {type: sign, lr_schedule: ...}(a discriminated union withadamonPersistentPGDReconLossConfig.optimizer).The variant is stateless:
PersistentAdversary.opt_stateis nowSourcesAdamState | None(None iff sign), so the source Adamm/vbuffers never exist. On full32L that is −19 GiB/GPU resident (2× the 9.5 GiB source bundle); combined with the validatedsource_dtype: bfloat16(#938) the source bundle goes 28.5 → ~4.75 GiB.Invariants (SPEC IDs)
signwas already a named valid instantiation — no SPEC amendment. Production stays ★adam.n_warmupsupplemental ascents + one final ascent from the main backward, coeff-unscaled;sources_ascend_projectdispatches on the optimizer config.sources_adam_ascend_project) is bit-untouched.Configs
Four Tier-1 quality A/B arms (pile-4L PPGD-bsc, 10k steps, same seed, dp 8): adam control + sign at lr {0.003, 0.01, 0.03} — a step-size sweep since Adam's normalized per-update magnitude ≈ lr was tuned at 0.01, but sign steps are exactly lr. All arms fp32 source to isolate the update rule. Results will be logged on the bridge task (lp-sign-ascent-source).
Validation
pytest param_decomp/tests/green at default device count; adversary/checkpoint tests also green atXLA_FLAGS=--xla_force_host_platform_device_count=4.test_sign_src_step.py(unit: ±lr move, clamp, dtype, statelessness) +test_step_trains_with_sign_src_step(full jitted train step: losses finite, sources move and stay projected,opt_statestays None).make checkclean (ruff + basedpyright 0 errors).🤖 Generated with Claude Code
https://claude.ai/code/session_01ALaUCqhksKmWNbxjfmuMUi