---
base_model: Qwen/Qwen3.5-9B
library_name: transformers
tags: [meta-reasoning, sft, data-scaling]
---

# MR_midtrain_9B_v4 — half 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 **37,404 rows / 2,244 problems**, which is
the half 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. Stopped at step 1600 of 1752 (91.3% through the cosine schedule, lr ~5.7e-7 vs a final 2.0e-7) because val loss had been flat to four decimals for 300 steps and the remaining allocation was better spent on the quarter run.

Uses the same `<direction>` / `<summary>` scaffold protocol as v4 — see the
base model card for the prompt format.