plan_memory 沒有 GRPO 模式：GRPO 的峰值由 logits 主導，與 SFT 不同

[lianghsun]

plan_memory.py models the CPT/SFT shape only. GRPO's peak is dominated by a
different term and the estimator says nothing about it, so the hsun-grpo
guidance ("num_generations 8-16") and hardware reality are disconnected.

Why GRPO differs

Measured earlier today: under transformers 5 the fp32 logits term does not
appear for SFT — the loss is chunked, and quadrupling the sequence adds 0.2 GB.
GRPO is not the same: TRL computes per-token log-probabilities explicitly, so
logits of shape num_generations x (prompt + completion) x vocab really are
materialised. On a 262K-entry vocabulary that dominates everything else.

Measured points (peer session, RTX 3090, 15.6 GB free, gemma-3-1b LoRA r16)

num_generations	max_completion_length	batch	outcome
8	512	8	OOM in backward, "Tried to allocate 4.00 GiB"
4	384	4	fits, ~8.8 GB, 21 s/step
4	1024	4	OOM at step 3 (expandable_segments mapping failures)

Proposal

plan_memory.py --stage grpo --num-generations N --max-completion-length L,
with the logits term modelled for GRPO and left at zero for SFT/CPT. The three
points above are the acceptance test — all three should be predicted correctly.

Until then, hsun-grpo's "num_generations 8-16" will OOM anyone on a 24 GB card
at a realistic completion length. Worth softening that line in the same change.

Related: #2 (max_completion_length clipping), now partly addressed by the
clipped-ratio guard.