Nibmeister/auto-antislop
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add measured FTPO speedup numbers from the max_seq_length fix

Browse Source 
Ran a 30-minute validation with finetune_max_seq_length=1280 to confirm the
predicted speedup from the previous commit. Measured ~40s/step steady-state
(vs ~160-185s/step at max_seq_length=4000) -- a ~4.3x speedup, better than
the ~3x predicted from the token-count ratio alone. Extrapolated full-run
ETA drops from ~34h to ~8.3h. No errors across the validation run.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Joey Grasty
2026-08-08 10:31:30 -05:00
parent cbd88aa758
commit c66cf7a947
1 changed files with 20 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
DGX_SPARK_SETUP.md
View File

@@ -190,12 +190,25 @@ batch-size bump did nothing: total padded-token compute is invariant to how the
collator-design issue, not a hardware ceiling — it would waste the same proportion on any GPU.
**Fix:** lower `finetune_max_seq_length` to comfortably cover the real distribution, e.g. `1280`
(covers p99 with headroom, nothing in the dataset gets truncated) instead of `4000`. That should cut
per-step compute roughly 3x, bringing the ~34h estimate down to somewhere around ~11-12h. We left
(covers p99 with headroom, nothing in the dataset gets truncated) instead of `4000`. We left
`finetune_batch_size` at the default (`1`) since increasing it has no effect either way here.
**Measured, not just predicted:** re-ran training with `finetune_max_seq_length: 1280` for a 30-minute
validation window (46 steps, timing fully steady by the end — no drift):
| | `max_seq_length=4000` | `max_seq_length=1280` |
|---|---|---|
| steady-state step time | ~160-185s/step | **~40s/step** |
| memory used during training | ~82GB | ~25GB |
| speedup | — | **~4.3x** |
| extrapolated full run (750 steps) | ~34h | **~8.3h** |
Better than the ~3x predicted from the token-count ratio alone — the memory savings from shorter
sequences apparently helped beyond just the raw compute reduction. No errors across the validation
run.
If you need it faster still, the other lever is `finetune_max_train_examples` (fewer total steps,
less data coverage) — or just accept the runtime and let it run in the background.
less data coverage) — or just accept the ~8h runtime and let it run in the background.
## Validated results
@@ -205,7 +218,10 @@ Ran the full pipeline against `unsloth/gemma-3-4b-it` (2 iterations, 1200 prompt
- Iteration 1 (with ban lists from iteration 0's analysis): completed in 1h31m43s (slower — active
backtracking around bans), `repetition_per_100k_chars` = 56 — a real, measured reduction in slop
- FTPO training: confirmed working end-to-end (750 steps, 12,000 preference pairs) after the
patches in §6; not run to completion due to the ~34h runtime (§7)
patches in §6. At the original `finetune_max_seq_length: 4000`, steady-state was ~160-185s/step
(~34h for the full run). After the fix in §7 (`finetune_max_seq_length: 1280`), measured
~40s/step over a 30-minute validation run — a confirmed ~4.3x speedup, ~8.3h extrapolated for the
full 750 steps. Not run to full completion.
## Quick-reference: full env setup