clamp: y += (C - <y,v_hat>)v_hat at all positions -- bounded perturbation
regardless of generation length, vs add's per-step accumulation via KV cache.
C=0 is directional ablation. Smoke (Qwen3-0.6B, happy/joy): clamp C=+20 stays
coherent and on-concept (drifts to 'happiness and joy of my childhood', in
Chinese) while add C=+8 already degenerates to 'joyjoyjoy...'.
Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
Three OOM kills (551/552/553) from the user's bursty live VS Code kernel, but
jlens resumes from checkpoint each time (n_done 36->45->64, monotonic). Rather
than predict the bursts, relaunch until exit 0. MAX_RETRIES=40 caps a genuine
no-progress bug; n_done logged per retry to distinguish OOM from a real crash.
Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
552 CUDA-OOM'd at n_done=45: the user's VS Code GPU kernel grew to 8.18GB
while this fit's 13.23GB hit the 23.5GB ceiling (44MB free, fragmentation).
dim_batch=4 shrinks the fit to ~10.5GB (polite co-tenant, leaves user ~13GB)
and expandable_segments:True defragments (the OOM's own suggestion). Still
only changes the backward schedule, not the Jacobian. Resumes from n_done=45.
Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
Run 551 was OOM-killed at n_done=36: the user's VS Code Jupyter kernel
(jsteer venv, PID 3214401) co-loaded ~1.5GB VRAM + 1.9GB RAM while the fit
sat at the 22.4/24.6GB ceiling. Clean SIGKILL with no CUDA traceback = host
OOM killer, not a CUDA OOM. dim_batch=8 halves the fit's peak footprint;
it changes only the backward schedule, not the accumulated Jacobian, so U4
exactness is preserved. Resumes from checkpoint (n_done=36), lossless.
Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
+C collapses to "joy", -C to negative tone: sign correct. Coherence
breaks at |C|=8 uncalibrated, as expected.
Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
