Scaling Laws:给定一笔算力预算,模型该造多大、数据该喂多少?

简介: 本文是大模型课程第7课,用6个问题厘清参数与数据的预算分配:从`C≈6ND`出发,解出20:1最优比,解释为何工业界故意“过训练”、数据为何告急、MoE为何救不了数据墙。内容严谨,含公式推演与实证对比。(239字)

前六篇讲的是模型"长什么样"。这一篇换到最底层的约束:造一个模型,预算怎么分给参数和数据?

这不是拍脑袋。2019 到 2022 年,两篇论文为此公开打了一架,最后一方赢了。这一篇用 6 个问题把账算清:从 C ≈ 6ND 出发,解出 20:1,再解释为什么现代模型故意偏离它、为什么数据快不够了、MoE 为什么救不了。内容来自我做的 34 课大模型课程的第 7 课。

问题 1:模型越大越好,还是数据也要按比例跟上?

两篇论文的结论不一样,而它们算的是同一笔账。

论文 参数量随算力增长 数据量随算力增长 两者相乘
Kaplan et al. (2020) N ∝ C^0.73(约 5.5 倍) D ∝ C^0.27(约 1.8 倍) 5.5 × 1.8 ≈ 9.9 倍
Chinchilla (Hoffmann et al., 2022) N ∝ C^0.50(约 3.16 倍) D ∝ C^0.50(约 3.16 倍) 3.16 × 3.16 ≈ 10 倍

两者都自洽——都把算力放大了约 10 倍。分歧全在"给谁多":Kaplan 让模型涨 5.5 倍、数据只涨 1.8 倍;Chinchilla 让两者一起涨。

为什么差这么多?用 C ≈ 6ND 就看得明白(N 是参数量,D 是 token 数,算力按 BF16 口径):

方案 参数量 N 数据 D 算力 6ND 相对基准
基准(示意) 10B 100B 6 × 10e9 × 100e9 = 6.0 × 10²¹ 1 倍
只把参数翻倍 20B 100B 6 × 20e9 × 100e9 = 1.2 × 10²² 2 倍
参数与数据一起翻倍 20B 200B 6 × 20e9 × 200e9 = 2.4 × 10²² 4 倍

因为它是乘积:N 和 D 各翻一倍,乘积就翻四倍。多搭一倍的货架,只多花一倍钱;货和货架一起加,就要多花三倍。

最后 Chinchilla 赢了,而且是拿实验赢的:

模型 参数量 训练 token token/参数 训练算力 6ND
Gopher 280B 300B ≈ 1.07 5.04 × 10²³
Chinchilla 70B 1.4T 20 5.88 × 10²³

两者算力只差 16.7%,Chinchilla 的参数只有 Gopher 的 1/4,却在多数基准上更好。这一局说明的不是"大模型不好",而是当时整个行业把模型做大、数据几乎没动,那笔账是亏的。

顺带一个数:GPT-3 是 175B 参数、300B token,约 1.7 token/参数。按后来修正的 20:1,它本该喂约 3.5T token——数据少了约 12 倍。

那 Kaplan 是不是错了?2024 年 Porian 等人的复现(arXiv:2406.19146)指出三处口径问题:Kaplan 统计的是非 embedding 参数、漏算了最后一层的算力项、而且所有 run 用同一套学习率调度让短训练被系统性低估。三条一并修正后,结论就和 Chinchilla 一致了。

一句话结论:算力是参数和数据的乘积,只堆一边是浪费;Chinchilla 赢在把两边一起加。

问题 2:给定一笔算力预算,模型该造多大、数据该喂多少?

先看两个极端,两边都亏。

模型极大但数据极少 → 参数没喂饱,容量空转;模型极小但数据极多 → 容量不够,数据白读。既然两头都浪费,中间必然有一个最优点。Chinchilla 用 400 多次受控实验(70M~16B 参数、5B~500B token)把它找了出来:

结论 N 的指数 D 的指数 含义
Kaplan (2020) C^0.73 C^0.27 算力主要用来放大模型
Chinchilla (2022) C^0.50 C^0.50 模型与数据等比例增长

两个指数都是 0.5,意思是:算力翻 4 倍,参数和数据各翻 2 倍。把它代进算力公式,20:1 就自然解出来了:

步骤 计算 结果
算力公式 C ≈ 6 × N × D —
代入 D = 20N C ≈ 6 × N × 20N = 120 N²
反解 N_opt ≈ √(C / 120) 给定预算就能算
验证 70B × 20 = 1.4 × 10¹² = 1.4T token

Chinchilla 就是 70B 参数、1.4T token,和论文对得上。所以"20 token/参数"不是一个拍脑袋的经验数字,而是从上式解出来的。

同算力下的实测对照(Chinchilla 论文口径的 MMLU 平均):

模型 参数量 训练 token token/参数 MMLU 平均
Gopher 280B 300B ≈ 1.07 60.0%
GPT-3 175B 300B ≈ 1.71 43.9%
Chinchilla 70B 1.4T 20 67.5%

参数少 4 倍,分数高 7.5 个百分点,用的算力几乎一样。

一句话结论:给定预算 C,最优参数量是 √(C/120),数据量是它的 20 倍。

问题 3:既然 20:1 最省算力,为什么现代模型要故意"过训练"?

因为 20:1 省的是训练算力,而算力不只花在训练上。

模型训一次,服务几亿次。推理成本正比于参数量,而这笔钱要付一辈子。把参数压小、数据喂多,训练端也许更贵,长期总账却更便宜——这叫过训练(overtraining)。

先看训练端(20B/4T 这组是示意,不指向真实模型):

方案 参数量 token token/参数 训练算力 6ND
Chinchilla 最优 70B 1.4T 20:1 5.88 × 10²³
过训练 20B 4T 200:1 4.80 × 10²³

过训练方案的训练算力还低 18.6%。再看推理端,这里才是大头:

项目 70B 20B 倍数
单 token 前向 FLOPs(2N) 1.4 × 10¹¹ 4.0 × 10¹⁰ 3.5 倍
权重显存(fp16) 140 GB 40 GB 3.5 倍
服务 10¹² token 1.4 × 10²³ 4.0 × 10²² 3.5 倍

推理只有前向,所以系数是 2 而不是 6。这里只算权重项,没算注意力随序列长度平方增长的那部分——长上下文时那项会明显上升。

盈亏平衡点:

项目 计算 结果
训练多花 5.88e23 − 4.80e23 1.1 × 10²³ FLOPs
每 token 推理省下 1.4e11 − 4.0e10 1.0 × 10¹¹ FLOPs
平衡服务量 1.1e23 ÷ 1.0e11 ≈ 1.1 × 10¹² token

累计服务超过约 1.1 万亿 token,过训练方案的总算力就更省。对一个日活百万的产品,这个量级几周就到了。

现实中的比例:Llama 2 70B 用了约 2T token(≈ 28.6 token/参数),Llama 3 用约 15T token——8B 版本算下来是 1875 token/参数,接近 Chinchilla 建议的 100 倍。

一句话结论:20:1 是"训练最省",工业界要的是"总成本最省",所以故意过训练。

问题 4:过训练要海量数据,可用的高质量文本还剩多少?

Epoch AI 给过一个被广泛引用的估算:互联网上高质量、可公开获取的人类文本约 300 万亿 token(估算值,不同机构口径差异很大),并预测这个存量会在 2026~2032 年间被用尽(80% 置信区间)。

需求侧,按 Chinchilla 和按 100:1 过训练分别是:

模型规模 20:1 100:1
7B 140B 700B
70B 1.4T 7T
405B 8.1T 40.5T
1T 20T 100T
10T 200T 1000T

过训练把需求又放大了 5 倍。

供给侧不只看总量,还要减去"被锁住"的部分。Data Provenance Initiative 2024 年审计了 C4、RefinedWeb、Dolma 背后的网页来源,发现一年内:

口径 比例
C4 全部 token 中完全受限 约 5% 以上
C4 中最活跃维护的关键来源受限 28% 以上
计入服务条款限制后的 C4 受限比例 约 45%

被锁的恰恰是维护最勤、质量最高的那部分——新闻、论坛、代码托管,不是边角料。

于是缺口是这样:

对比项 需求 可用存量 缺口
1T 参数(20:1) 20T 216T 无缺口
10T 参数(20:1) 200T 216T 接近耗尽
10T 参数(100:1) 1000T 216T 缺 4.6 倍

这里的 216T = 300 × (1 − 28%),是把"关键来源受限 28%"近似套用到 token 存量上的粗估。如果按 token 级受限比例(约 5%)算,可用存量是 285T,缺口变成 3.5 倍。两种口径都在"缺数倍"这个量级,具体数字需要人工核实。

一句话结论:数据墙说的不是没有数据,是能直接下锅的数据不够——存量有限,关键来源还在被锁,过训练又把需求放大 5 倍。

问题 5:数据不够了,MoE 能解决问题吗?

直觉是:MoE 每 token 只激活一小部分参数,看起来更省,那数据需求应该跟着"激活参数"走。

这个直觉是错的,因为它省的是算力,不是显存。

以 DeepSeek-V3 为例(671B 总参数、每 token 激活 37B、预训练 14.8T token):

资源 看哪个参数 数值
显存占用 总参数 671B(fp8 约 671GB,4-bit 约 336GB)
每 token 算力 激活参数 37B(占总参数 5.5%)

MoE 让推理更便宜,但没让模型更小。而数据需求恰恰跟着总参数走。

再看每个专家能分到多少(DeepSeek-V3 是 1 个共享专家 + 256 个路由专家,每 token 激活 8 个):

项目 计算 结果
每专家见到的 token D × K ÷ E 14.8e12 × 8 ÷ 256
代入 D = 14.8T — ≈ 4.6 × 10¹¹(4600 亿)

注意口径:一个 token 会同时进 8 个专家的门,所以每位专家看到的是 D×8/E,不是 D/E。即便如此,4600 亿 token 对 671B 的参数仍然偏少——专家"吃不饱",所以需要更多数据。

两种算法差 18 倍:

口径 数据需求(20:1) 是否现实
按激活参数 37B 740B token 看起来很容易
按总参数 671B 13.4T token 和 Llama 3 的 15T 同一量级

实测支持后者。MoE 本质是一笔算力-数据交换:用更多参数、更少激活,换推理便宜,代价是数据需求按总参数增长。在数据墙的背景下,它把问题从"算力不够"换成了"数据更不够"。

一句话结论:MoE 省算力不省数据,数据需求按总参数算,所以它让数据墙更严重。

问题 6:拿到一笔预算,怎么一步步定出模型大小和数据量?

把前五问串起来,就是一张可以拿来审任何训练配方的检查表。

第一步:把预算换算成算力。 假设 16384 张卡训练 54 天,单卡 BF16 稠密峰值 989 TFLOPS、利用率 50%(MFU 是假设值,属估算):

C = 16384 × (989e12 × 0.5) × 54 × 86400 ≈ 3.78 × 10²⁵ FLOPs

第二步:用 Chinchilla 反解模型大小。

N ≈ √(C / 120) = √(3.78e25 / 120) ≈ 5.6 × 10¹¹ ≈ 560B 参数

对应的数据量是 560B × 20 = 11.2T token。这是"训练最省"的点。

第三步:按过训练倍数定 token 数,再检查数据够不够。

方案 参数量 token 数 数据是否够
Chinchilla 最优 560B 11.2T(20:1) 够(存量 216T)
实际选择 405B 15.6T(38.5:1) 够(Llama 3 就是这么做的)
激进过训练 405B 40.5T(100:1) 够,但要大量重复
激进过训练 1T 100T(100:1) 接近存量上限

Llama 3 405B 实际用 15.6T token,约 38.5:1——介于"训练最省"和"激进过训练"之间,这是训练成本和推理成本之间的折中,不是算错了。

一句话结论:先算 C,再解 N,再乘过训练倍数,最后查数据够不够——四步能提前验算,不用训完才发现配方不对。

小结

问题 结论 一个数字
谁赢了 Chinchilla:参数和数据要一起加 同算力下参数少 4 倍还更好
怎么分 N_opt ≈ √(C/120) 20 token/参数
为什么要过训练 推理成本正比于参数量、且要付一辈子 平衡点约 1.1 万亿 token
数据够吗 存量约 300 万亿 token,关键来源 28% 被封 10T 参数过训练缺 4.6 倍
MoE 能救吗 省算力不省数据,需求按总参数算 740B vs 13.4T,差 18 倍
怎么定方案 C → N → token 数 → 查数据 3.78e25 FLOPs 对应 560B

参考与说明

  • Kaplan 等,Scaling Laws for Neural Language Models,2020,https://arxiv.org/abs/2001.08361
  • Hoffmann 等,Training Compute-Optimal Large Language Models(Chinchilla),2022,https://arxiv.org/abs/2203.15556
  • Porian 等,Resolving Discrepancies in Compute-Optimal Scaling of Language Models,2024,https://arxiv.org/abs/2406.19146
  • Llama 3 训练数据量(约 15T token):The Llama 3 Herd of Models,2024,https://arxiv.org/abs/2407.21783
  • 数据受限比例:Consent in Crisis: The Rapid Decline of the AI Data Commons,2024,https://arxiv.org/abs/2407.14933
  • DeepSeek-V3 参数与 token 数:技术报告,2024,https://arxiv.org/abs/2412.19437
  • 300 万亿 token 存量与 2026~2032 窗口:Epoch AI 的估算,二手转引较多,属估算值,不同机构口径差异大。
  • 文中所有算术我都用代码独立复算过:6ND 各档、20:1 反解、5.04e23 与 5.88e23 的 16.7% 差、1.1e23 ÷ 1.0e11 = 1.1e12、14.8e12 × 8 ÷ 256 ≈ 4.6e11、√(3.78e25/120) ≈ 5.6e11。标「示意」的表格是为演示构造的,不指向真实模型。
  • 两处口径必须先说清:① Chinchilla 论文写 1.4T token,DeepMind 官方博客写 1.3T,本文用论文口径;② Llama 2 的训练量,Llama 2 论文写 2.0T,Llama 3 论文写 1.8T,本文按 2.0T 算 token/参数比。
  • 说明:这套课程由 AI 在我设计的规则下生成,再经过脚本检查和独立审查;审查发现过不少问题,已写在仓库 README 里。发现错误欢迎提 Issue,写清位置,我逐条核实。

继续学

完整课程 34 课,这一篇是第 7 课。下一篇进入数据工程:预训练语料从哪来、怎么清洗、怎么配比。

相关文章
|
9天前
|
JavaScript API iOS开发
DeepSeek Harness下载、安装、配置一篇搞定(2026整理,送常用插件)
DeepSeek Harness(DSH)是DeepSeek于2026年开源的MIT协议AI Agent框架,支持插件化组装模型、工具、沙箱与UI,兼容主流大模型。本文提供免Node.js的桌面端安装包(Win/macOS),含详细图文教程及热门插件推荐。
3892 41
|
9天前
|
Linux 开发工具 iOS开发
Codex保姆级教程(下载+安装+登录+使用,含所有版本,2026最新)
Codex是OpenAI推出的开源AI编程智能体,本地运行,可理解整个代码库,支持自然语言指令改代码、执行命令、跑测试、修Bug,兼容Win/macOS/Linux。(239字)
3553 13
|
4天前
|
云安全 人工智能 安全
|
10天前
|
iOS开发 Docker MacOS
【2026实测】Docker Desktop下载、安装、汉化、配置教程(附官网安装包)
Docker Desktop 是 Docker 官方推出的桌面容器管理工具,集成引擎、CLI、图形界面与 Kubernetes,支持 Win/macOS/Linux。2026 最新版 4.88.1 强化 ARM 原生运行、镜像加速及资源可视化,附中文汉化与国内镜像配置指南。
1782 6
|
10天前
|
安全 算法 定位技术
《高性价比人生指南》完整原版:普通人用最少的资源,过好这一生的底层逻辑~How To Live Better
📖《高性价比人生指南》是一份基于实证、拒绝焦虑的生存手册,倡导以“人生时薪”为视角,重新计算时间、金钱与精力的成本与收益。它不承诺逆袭,只教人算清账:省下的钱若耗掉时间便亏;买体验比买物品更值;睡眠是最高杠杆的健康投资;关系贵在情绪价值而非表面热络;学习重在改变行为而非自我安慰。核心理念:用低成本、高回报的微小行动,换取长期的选择权——不是成为谁,而是掌控自己人生的主动权。
2082 4
|
云安全 安全 网络安全
|
4天前
|
Linux 开发工具 iOS开发
2026最新codex下载安装保姆级使用教程(下载+安装+登录+使用,含所有历史版本)
本文详解OpenAI Codex国内快速上手指南:提供Win/macOS/Linux全平台免安装包、npm/Homebrew等多方式安装、账号/API Key双登录、简体中文切换,覆盖下载、安装、汉化、使用及高频避坑(如微软商店失败、npm超时等),10分钟即可跑通。
729 1
|
23天前
|
人工智能 API 开发工具
DeepSeek Harness 神插件:白嫖 13 家大厂模型
`dsh-our-free-model` 是 DeepSeek Harness 神级插件:零配置、零API Key、零账号,聚合13家大厂免费模型(含DeepSeek V4.1 Flash、Kimi K3等),支持本地网关、用量看板与自动降级,真正实现“白嫖即用”。
4058 56