v7 = same arch as v4/v5/v6 (dim768/18L, bf16, 8-GPU DDP global 256), trained the SAME 2.255B-token FineWeb-edu subset to 1.45 epoch (vs v6's 1.02), best FineWeb val 3.0149 (v6 3.0652). Exported + archived to registry v7-fineweb-edu-dim768, serves in xserv (coherent expository English, ~v6 quality). Key finding: more epochs of the SAME subset gave only ~0.05 val drop and the curve flattened (~step 44000) with no sampling quality gain → the 2.255B FineWeb subset is near its ceiling at dim768. Same class as v5's TinyStories data-volume saturation: repeating old data has thin margins; true further gains need FRESH shards (more diverse tokens), as v6's corpus-swap (which raised the ceiling) showed. Adds docs/runs/07-v7-*.md; updates docs/runs/README.md (+v7 row, intro saturation note, v8 proposal) and docs/evolution.md (+v7 row, dataset-axis ceiling note). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6.5 KiB
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 换更广语料才抬了天花板),不是同子集多读几遍。
⚠️ 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(待定方向):v7 校正了 v6「这本语料还没喂够」的乐观读法——把 FineWeb-edu 同一 2.255B 子集 epoch
从 1.02 拉到 1.45,FineWeb val 仅 ↓0.05(3.07→3.01)且走平、采样无质变 = 同子集多 epoch 在 dim768 已近顶
(与 v5 的 TinyStories 数据量饱和是同一类现象:重复老数据边际都薄)。所以「更多数据」这条杠杆的前提是真·更多:
1. 新 FineWeb shards(首选,真·更多/不重复 token:再下 sample/10BT 之外分片或 100BT 子集,磁盘紧需 /dashscope-tmp 暂存);
2. 更大模型(dim1024+,容量轴;要先做 KI-3 激活重计算,且需配新数据一起测是否 capacity-limited);
3. 数据混合(TinyStories+FineWeb,治 v6 transfer 退化 1.11→2.75,为「连贯+广度」服务)。判断 先走 1——
v7 已证「重复老数据」到头,下一步必须给模型没见过的 token。详见
07-v7-*.md末尾 "v8 提案"。