xtrain/docs/runs/README.md

Scaling Runs

xtrain 的 scaling 阶段：在 v0-baseline 之上逐版放大数据 + 参数，每版一份 docs/runs/NN-<version>.md 设计文档（数据来源 / 架构 + 参数 / 超参 / 结果 val-loss + 采样 / 相比上一版的提升），训练完存入 dash5 模型 registry（~/projects/tiny-models/<version>/）并导出 xserv 格式验证可服务。

模型核心参数（core params）= Config::core_params() = 总参数减去两张 vocab×dim 表 （token embedding + lm_head）。gpt2 vocab=50257 使这两张表固定占 ~25.7M（dim256 时），它不反映 模型容量，所以阶梯按 core 来量。

对比表

val loss 一栏给的是各版各自训练 run 报告的 best val（held-out 1M token，全量 train 末尾切片）。 注：v0/v1 训练用 seq128、v2 用 seq256，eval 窗口不同 → 同一保留集 + 同一 eval 设置（seq256/64batch） 重评 v1=2.6756→v2=2.0418（低 0.634，apples-to-apples）；下表 best-val 同向。

tokens / epoch 两列让数据饱和可见：v4→v5 同 arch、数据 ×3.5（1.54→5.33 epoch），val 仅 ↓0.06（~5%） 且末段走平 ⇒ TinyStories 在 dim768 已近数据天花板（详见 05-v5）。v6→v7 同样揭示 「重复老数据」边际薄：同一 2.255B FineWeb 子集多喂 epoch（1.02→1.45），FineWeb val 仅 ↓0.05 且走平 ⇒ 该子集 在 dim768 也近顶（详见 07-v7）。两条都说明：真·增益要新数据（v6 换更广语料才抬了天花板），不是同子集多读几遍。 v8 改测容量轴：同 v6/v7 子集、纯把 dim768→dim1024（core 127M→226M），FineWeb val 3.07/3.01→2.98 ⇒ 容量有用（v6/v7 部分 capacity-limited）；但增益仅 ~3%、val 末步仍在降未饱和 ⇒ 到 v8，数据轴与容量轴的 单步杠杆都收敛到 ~3%/lever = 全面边际递减，要双轴一起 scale（Chinchilla，详见 08-v8）。 v9 兑现双轴：dim1024→dim1280（core 226M→357M）并把 FineWeb token 从 2.255B 子集扩到 6.013B， best val 2.8854，相比 v8 再降 0.0947（~3.2%）。结论：双轴 scale 有效，但仍是稳健增量而非质变。 v10 只补数据轴：同 v9 架构，只补 shard010 到 6.765B token，moving-tail best/final val 2.8816。 注意追加 shard 会移动 held-out tail；固定 eval v1 上 v6→v10 为 3.2328 / 3.1850 / 3.1515 / 2.9278 / 2.8814。

⚠️ v6 起换了保留集（语料）：v0–v5 的 val 都是 TinyStories 1M 留出集（彼此可比）；v6 换成纯 FineWeb-edu（真实网页文本），它的 val（3.07）是另一把尺子上的另一个分布，不能和 v0–v5 的 ~1.1 比大小——真实网页熵高，~3.0 是预期值不是回退。v6 的判据是采样质量 + transfer eval（见 06-v6）。下表 v6 行的 val 单独标注分布。

版本	数据	训练 token	epoch	架构 (dim/L/heads·hd/ffn)	core 参数	总参数	val loss	备注
v0-baseline	TinyStories valid 3MB 切片 (~72 万 tok)	~0.72M	—	32 / 4 / 2·16 / 64	~41K	3.26M	3.8050	太小不可用；采样陷入 "mommy's mommy's mommy" 循环
v1-tinystories-dim256	TinyStories 全量 train (468.3M tok, u16 缓存)	~5.1M	—	256 / 8 / 8·32 / 1024	8.39M	34.13M	2.5847	全量数据 + dim256/8L；val 低 1.22，采样连贯成篇；~25.9min/单卡
v2-tinystories-dim384	TinyStories 全量 (复用 v1 缓存)	~36.9M	—	384 / 12 / 12·32 / 1536	28.32M	66.92M	1.7055	dim384/12L + DDP 4 卡；val 比 v1 低 0.88，情节更长；~2.8h/4 卡。⚠️ DDP 弱扩展见 KI-1
v3-tinystories-dim512	TinyStories 全量 (复用 v1 缓存)	~245.8M	~0.53	512 / 16 / 16·32 / 2048	67.13M	118.59M	1.3027	dim512/16L + 单卡 batched (T10)；val 比 v2 低 0.40，带动机/转折的连续叙事；~2.65h/单卡 ~26K tok/s。T10 修 KI-1 根因(launch-bound)，单卡避开 KI-5
v4-tinystories-dim768	TinyStories 全量 (复用 v1 缓存)	~720.9M	~1.54	768 / 18 / 24·32 / 2048	127.43M	204.63M	1.1690	dim768/18L + 8 卡 DDP fp32；val 比 v3 低 0.13，细节更具体、结构更完整；~84min/8 卡 ~145K tok/s。验证 T11 缓存分配器在 dim768 多卡扩展；⚠️ fp32 per-rank batch 32 OOM = bf16(KI-2) 触发点
v5-tinystories-dim768	TinyStories 全量 (复用 v1 缓存)	~2.49B	~5.33	768 / 18 / 24·32 / 2048 (同 v4)	127.43M	204.63M	1.1102	架构同 v4，唯一变量=数据量 + 8 卡 DDP bf16(global 256)；~3.2h/8 卡 ~217K tok/s。⚠️ 数据天花板：数据 ×3.5 仅 val ↓0.06(~5%) 且末段走平 ⇒ TinyStories 在 dim768 近饱和，v6 该换轴(更大模型/更广语料)
v6-fineweb-edu-dim768	FineWeb-edu 真实网页 (2.255B 语料)	~2.29B	~1.02	768 / 18 / 24·32 / 2048 (同 v4/v5)	127.43M	204.63M	3.0652 ⚠️*(FineWeb val,与上不可比)*	第一版脱离 TinyStories，唯一变量=数据来源 + 8 卡 DDP bf16；~1.9h/8 卡 ~218K tok/s。val 是另一分布(真实网页熵高,~3.0 是预期非回退)，判据=采样质量+transfer。FineWeb val 末步仍单调降=未饱和；transfer: v6→TinyStories val 2.75(v5 native 1.11)，纯通用数据对窄分布有代价。采样: v6 写真实说明文 vs v5 一律掉进小故事
v7-fineweb-edu-dim768	同 v6 的 2.255B FineWeb-edu 子集(非新数据)	~3.28B	~1.45	768 / 18 / 24·32 / 2048 (同 v4/v5/v6)	127.43M	204.63M	3.0149 (FineWeb val,与 v6 可比)	唯一变量=epoch 数(1.02→1.45) + 8 卡 DDP bf16；~4.2h/8 卡 ~218K tok/s。⚠️核心发现：同子集多 epoch 近天花板——多喂 ~1B token，val 仅 ↓0.05(3.07→3.01)且 ~step44000 后走平、采样无质变。真"更多数据"要新 FineWeb shards(更多样 token)，非重复同一子集。与 v5 的 TinyStories 数据量饱和同类(重复老数据边际薄)，v6 换语料才是抬天花板的轴
v8-fineweb-edu-dim1024	同 v6/v7 的 2.255B FineWeb-edu 子集(非新数据)	~2.36B	~1.05	1024 / 18 / 32·32 / 2730	226.50M	329.42M	2.9801 (FineWeb val,与 v6/v7 可比)	唯一变量=模型容量(dim768→dim1024, core 127M→226M +78%) + bf16 + 激活重计算(T13) 装下 dim1024；~5h/8 卡 ~129K tok/s(重算税)。⭐核心 A/B：容量有用——同 ~1ep v6 3.07→v8 2.98(↓0.085)，且 v8(1.05ep) < v7(1.45ep 更多老数据) 3.01 ⇒ 放大容量 > 重复老数据 ⇒ v6/v7 部分 capacity-limited。⚠️但增益仅 ~3%(与数据轴单步同量级)，val 末步仍在降未饱和。元结论：单轴(数据/容量)单步都已 ~3%/lever = 全面边际递减，要双轴一起 scale(Chinchilla)
v9-fineweb-edu-dim1280-gqa	FineWeb-edu 扩展 shards 000-009(6.013B token)	~6.01B	~1.00	1280 / 18 / 40·32 / 4096, kv=10 GQA	356.89M	485.55M	2.8854 (moving-tail FineWeb val)	Chinchilla 双轴：dim1024→1280 + 真 GQA + 新 FineWeb token，Phase-2 stack(--flash+accum+bf16+recompute+DDP)，21.25h/8 卡 ~78.6K tok/s。相比 v8 moving-tail 再降 0.0947 (~3.2%)，验证双轴 scale 有效；greedy 样本更像真实说明文但仍重复，增益主要体现在 val 而非质变
v10-fineweb-edu-dim1280-gqa-data6765	FineWeb-edu 扩展 shards 000-010(6.765B token)	~6.76B	~1.00	同 v9	356.89M	485.55M	2.8816 (moving-tail FineWeb val)	只补数据轴：同架构从头训，23.86h/8 卡 ~79.0K tok/s。moving-tail 比 v9 只低 0.0038，不宜过读；固定 eval v1 上 v9 2.9278→v10 2.8814，说明补 shard010 对新分布有效。greedy 复读未解决

下一档（提案）

• v11：优先走更大模型 + 更长 context，而不是继续只补数据。smoke 已验证 dim1536/20L/48q/12kv/ffn6144 能跑 seq512 和 seq1024，但峰值约 30.5GiB，贴近 5090 32GB 上限。建议先做 v11a（seq512，约 42h）， 或明确接受 2.5 天预算后做 v11b（seq1024，约 61h）。v11 必须使用固定 eval v1，避免 moving-tail 继续污染横比。

v7 时的提案（已被 v8 兑现，归档）：v7 把首选定为「新 FineWeb shards」，把「更大模型(dim1024+，容量轴， 需先做 T13 激活重计算)」列为待测。v8 走了容量轴并证明它有用（但 ~3%），把「是否 capacity-limited」从 悬念变成了「部分是」的结论。