# Scaling Runs xtrain 的 scaling 阶段:在 v0-baseline 之上逐版放大**数据 + 参数**,每版一份 `docs/runs/NN-.md` 设计文档(数据来源 / 架构 + 参数 / 超参 / 结果 val-loss + 采样 / 相比上一版的提升),训练完存入 dash5 模型 registry(`~/projects/tiny-models//`)并导出 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](05-v5-tinystories-dim768.md))。**v6→v7 同样揭示 「重复老数据」边际薄**:同一 2.255B FineWeb 子集多喂 epoch(1.02→1.45),FineWeb val 仅 ↓0.05 且走平 ⇒ 该子集 在 dim768 也近顶(详见 [07-v7](07-v7-fineweb-edu-dim768.md))。两条都说明:真·增益要**新数据**(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](08-v8-fineweb-edu-dim1024.md))。 **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](06-v6-fineweb-edu-dim768.md))。下表 v6 行的 val 单独标注分布。 | 版本 | 数据 | 训练 token | epoch | 架构 (dim/L/heads·hd/ffn) | core 参数 | 总参数 | val loss | 备注 | |---|---|---|---|---|---|---|---|---| | [v0-baseline](../../docs/05-training-loop.md) | 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](01-v1-tinystories-dim256.md) | 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](02-v2-tinystories-dim384.md) | 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](../known-issues.md) | | [v3-tinystories-dim512](03-v3-tinystories-dim512.md) | 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](04-v4-tinystories-dim768.md) | 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](05-v5-tinystories-dim768.md) | 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](06-v6-fineweb-edu-dim768.md) | **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](07-v7-fineweb-edu-dim768.md) | **同 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](08-v8-fineweb-edu-dim1024.md) | **同 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](09-v9-fineweb-edu-dim1280-gqa.md) | **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](10-v10-fineweb-edu-dim1280-gqa-data6765.md) | **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」从 > 悬念变成了「部分是」的结论。