HerrHruby's picture
v4 midtrain SFT data-scaling point
72a14f0 verified
|
Raw History Blame Contribute Delete
1.72 kB
---
base_model: Qwen/Qwen3.5-9B
library_name: transformers
tags: [meta-reasoning, sft, data-scaling]
---
# MR_midtrain_9B_v4 β€” quarter corpus
A data-scaling point for [`MR_midtrain_9B_v4`](https://huggingface.co/HerrHruby/MR_midtrain_9B_v4):
the same v4 midtrain SFT recipe on **18,714 rows / 1,095 problems**, which is
the quarter of the full corpus
([`MR_midtrain_V4_sft`](https://huggingface.co/datasets/HerrHruby/MR_midtrain_V4_sft),
74,796 rows / 4,518 problems).
## Scaling result
| corpus | rows | problems | converged val loss |
|---|---|---|---|
| full | 74,796 | 4,518 | 0.6444 |
| half | 37,404 | 2,244 | 0.6586 |
| quarter | 18,714 | 1,095 | 0.6734 |
All three lie on `val_loss = 0.6444 + 0.0145 * log2(74796/rows)` to within
0.0003 β€” each halving of the corpus costs ~0.0145 val loss, log-linear across
the whole 4x range with no threshold.
**This is held-out next-token loss, not a judged score.** Scaffold-eval numbers
for these checkpoints are not yet measured.
## Corpus construction
Scaling points are **nested** (quarter βŠ‚ half βŠ‚ full), split by *problem* rather
than by row: rows within a problem are different layers of one exploration, so a
row-level split would keep nearly every problem and measure intra-trajectory
redundancy instead of corpus size. The validation set is byte-identical at every
point.
## Training
Identical to the reference run except corpus size: Qwen3.5-9B + 4 MR special
tokens, bf16 FSDP, max_length 65536, effective batch 128, lr 2e-5 cosine to
0.01x, warmup 3%, weight decay 0.01, 6 epochs. Trained to completion (876 steps = 6 epochs).
Uses the same `<direction>` / `<summary>` scaffold protocol as v4 β€” see the
base model card for the prompt format.