上一课讲完 AdamW 之后，大模型训练最微观的一条链终于闭环了。
一个 Token 预测错了。
Loss 告诉我们：
错得有多严重。
Gradient 告诉我们：
参数应该往哪边改。
Optimizer 再决定：
这一步到底怎么改。
最后：
θₜ → θₜ₊₁
Parameter 真正发生变化。
然后下一个 Batch。
再变一点。
再下一个 Batch。
再变一点。
如果把大模型训练放到显微镜下面看，所谓 Learning，其实就是无数次这种小到几乎看不见的 Parameter Update。
可问题来了。
我们已经知道：
一个参数是怎么学的。
接下来真正麻烦的问题却是：
到底应该有多少参数？
7B？
70B？
700B？
为什么这些年模型越做越大？
是不是只要 GPU 够多，就应该无脑增加 Parameter？
如果明天老板突然告诉你：
“训练预算批下来了，GPU 给你增加 10 倍。”
你准备怎么花？
这看起来像一个工程问题。
其实它直接把我们带到了现代大模型训练最重要的问题之一：
Scaling Law，缩放定律。
而真正理解 Scaling Law 之前，先把网上最常见的一句废话扔掉：
“模型越大，能力越强。”
这句话不能说完全错。
但如果你只理解到这里，基本等于还没开始理解 Scaling。
真正的问题是：
同样一笔算力，我到底应该拿去造一个更大的脑子，还是让现在这个脑子多读几本书？
这才是今天真正要解决的问题。
一、老板突然多给你 10 倍 GPU，你会怎么花？
先别谈论文。
假设我们现在正在训练一个：
7B 模型。
它原本会训练：
1T Tokens。
现在突然有：
10 倍训练预算。
第一种方案特别直觉。
模型扩大 10 倍：
7B → 70B
数据还是：
1T Tokens
完事。
听起来没毛病。
但是还有第二种方案。
模型一个参数都不增加：
还是：
7B
但让它读：
10T Tokens。
还有第三种。
模型扩大约 3 倍：
7B → 22B 左右
同时数据也扩大约 3 倍：
1T → 3T 多 Tokens
现在问题来了。
这三种方案：
谁更值？
别急着回答。
因为你刚刚其实已经撞上了大模型 Scaling 最核心的矛盾：
算力增加以后，我们到底应该增加 Model，还是增加 Data？
如果答案永远都是：
“加模型。”
那根本不需要 Scaling Law。
买更多 GPU，造更大的模型就完了。
Scaling Law 真正有价值，就是因为现实并没有这么简单。
今天先记住第一句话：
Scaling 从来不是“模型怎么变大”，而是 Parameters、Data、Compute 三笔账怎么一起算。
二、Parameter 多，到底多出来了什么？
很多人会有一个潜意识：
7B 模型里面装了 70 亿份知识。
70B 里面装了 700 亿份。
所以参数越多，知识就越多。
不是这么回事。
Parameter 不是数据库的 Cell。
不是：
Parameter 13841 = 北京
Parameter 28413 = 中国首都
Parameter 72651 = Python
知识和能力通常分布在大量 Parameter、Activation 和内部 Representation 的复杂协作里。
所以如果一定要用一句人话解释 Parameter，我更愿意把它理解成：
模型可以被塑造成多复杂。
也就是：
Capacity，容量。
假设模型只有非常少的 Parameter。
它能够表示的 Function 很有限。
模型扩大以后：
可调整的自由度增加了。
它可能形成：
更复杂的 Feature（特征）
更精细的 Representation（表征）
更复杂的 Pattern（模式）
更多内部 Circuit（计算回路）
更强的函数逼近能力
所以 Parameter 增加确实有意义。
但这里最容易犯的错误来了。
有容量，不等于容量已经被利用。
举一个特别极端的例子。
我现在给你：
1T Parameters。
一万亿参数。
听起来够吓人了吧？
然后我只拿：
1000 个 Token
训练它。
这个模型会因为有 1T 参数，突然变成超级智能吗？
显然不会。
为什么？
因为 Parameter 提供的只是：
可塑性。
真正负责“塑造”这些参数的，是：
Data。
所以这里有一句我认为比“参数越大越强”准确得多：
Parameter 买来的不是能力，而是能力的可能性。
这句话后面学 MoE 时还会再回来。
三、Data 又到底买来了什么？
现在反过来。
模型永远不变。
就是：
7B。
但我们不断增加数据。
100B Tokens。
1T Tokens。
5T Tokens。
10T Tokens。
发生了什么？
模型会看到更多：
语言表达。
事实关联。
代码 Pattern。
数学结构。
语法规律。
长尾知识。
跨领域组合。
不同上下文里的同一种规律。
这些东西最终通过：
Forward
→ Loss
→ Backward
→ Gradient
→ Parameter Update
一点点改变模型。
所以 Data 真正提供的是：
Training Signal，训练信号。
Parameter 是：
哪里可以改。
Data 决定：
为什么改成这样。
到这里我们就可以先建立一个非常朴素的 Mental Model：
Parameters = Capacity
模型有多少潜在表达能力。
Data = Training Signal
有多少信息可以真正去塑造这些能力。
这两者其实缺谁都不行。
有一个很大的模型，
但是不给数据：
学不出来。
有海量数据，
但是模型太小：
它也未必装得下足够复杂的规律。
于是你会发现：
训练大模型真正麻烦的地方，从来不是单独把某一个变量拉满。
而是：
几个变量必须匹配。
四、一个 1000 亿参数模型，只读了很少的书，会发生什么？
这里可以把模型想象成一个学生。
这个学生：
脑容量特别大。
推理能力的潜力特别强。
记忆能力也很好。
但问题是：
从出生开始，
你只给他看三页书。
然后问：
为什么他还不会微积分？
问题显然不在：
脑子不够大。
而在：
没有得到足够训练。
大模型也是一样。
假设我们的 Scale 一路扩大：
1B
→ 10B
→ 100B
→ 1T
可 Training Tokens 基本不变。
你就会得到越来越大的 Capacity。
但是 Data 并没有同步增长。
这意味着：
大量 Parameter 没有获得与其规模匹配的 Training Signal。
这就是后面经常看到的一个词：
Under-training。
训练不足。
注意。
这里的 Under-training 不是：
“今天少训练了两个小时。”
而是：
相对于 Model Capacity，这个模型没有获得足够充分的训练。
于是就出现一种非常尴尬的浪费：
GPU 花了。
Parameter 建出来了。
显存占了。
训练也贵了。
但大量 Capacity 没有真正变成能力。
所以：
一个大模型最贵的浪费，不是 Parameter 不够多，而是买了一堆 Parameter，却没给它足够的数据把这些 Parameter 训练出来。
五、既然这样，那模型别做大了，疯狂喂 Data 不就完了吗？
很自然。
既然数据这么重要：
那我就训练 7B。
不加 Parameter。
不断加 Token。
1T。
10T。
100T。
1000T。
是不是最后也能无限变强？
这里又会撞到另一面墙。
Model Capacity。
还是刚才那个学生。
假设他的能力只够理解小学数学。
你给他：
100 本一年级数学教材。
可能有帮助。
1000 本。
还能继续熟练一点。
但是你给他：
100 万本一年级练习册。
他会因此自动悟出：
黎曼几何吗？
不会。
因为这时候真正限制他的已经不是：
教材数量。
而是：
表达复杂知识的 Capacity。
模型也一样。
一个非常小的模型，
数据增加到一定阶段以后，
继续塞更多 Token：
仍然可能有收益，
但边际收益会越来越低。
因为模型自己开始成为瓶颈。
现在我们就第一次看清了 Scaling 的两种浪费：
模型太大，数据太少：
Capacity 没吃饱。
模型太小，数据太多：
Training Signal 吃不下。
所以今天第二句话：
Scaling 最怕的从来不是资源少，而是资源之间严重失衡。
六、现在第三个人终于出场了：Compute
Parameters 有了。
Data 有了。
还差一个东西。
Compute。
计算量。
很多人看到 Compute，就会把它理解成：
“有多少张 GPU。”
严格来说不对。
GPU 是：
Hardware。
硬件。
Compute 更接近：
整个训练过程真正执行了多少计算。
对一个传统 Dense Transformer（稠密 Transformer），经常会用一个非常粗略的工程近似：
C ≈ 6ND
这里：
C = Training Compute
N = Number of Parameters
D = Number of Training Tokens
今天不用研究那个 6 从哪里来。
我们只看最重要的关系：
C ∝ N × D
什么意思？
模型越大：
每处理一个 Token 越贵。
Token 越多：
模型需要重复训练的次数越多。
所以：
大模型 × 大数据 = 巨大 Compute。
这一刻，三个变量终于连起来了。
Parameters：
Capacity。
Data：
Training Signal。
Compute：
你有多少钱让 Capacity 和 Training Signal 真正发生训练。
七、现在再看那 10 倍 GPU，事情就完全不一样了
为了好算，我们先不考虑常数。
假设：
C ≈ N × D
原来的 Model Size：
N = 1
原来的 Training Data：
D = 1
那么：
C = 1。
现在老板把 Compute Budget 提升到：
10。
你可以怎么玩？
方案 A：
N = 10
D = 1
Compute = 10
方案 B：
N = 1
D = 10
Compute = 10
方案 C：
N = 2
D = 5
Compute = 10
方案 D：
N = 5
D = 2
Compute = 10
甚至还有：
N ≈ 3.16
D ≈ 3.16
因为：
3.16 × 3.16 ≈ 10
发现问题了吗？
同样烧掉 10 倍算力，你可以训练出完全不同的模型。
所以 Scaling 最核心的问题终于出现：
当 Compute 固定时，N 和 D 到底怎么分，最后的 Loss 才最低？
注意这一刻发生了什么。
我们已经不再讨论：
“模型做多大？”
而是在讨论：
Resource Allocation Problem。
资源分配问题。
这才是 Scaling 真正进入训练核心的地方。
八、Scaling Law 到底是什么？别急着背指数
接下来才正式说：
Scaling Law。
缩放定律。
但如果一上来就给：
L(N) = A/N^α + …
基本又把人讲睡着了。
我们还是从现象开始。
如果 Model Size 不断增加：
Loss 通常会下降。
如果 Dataset 不断增加：
Loss 通常也会下降。
如果 Training Compute 不断增加：
Loss 通常还是会下降。
这些都不算特别震撼。
真正让人觉得有意思的是：
这种下降不是毫无规律地乱跳。
大量实验发现，在一定范围内：
Model Size。
Dataset Size。
Compute。
和最终 Cross-Entropy Loss 之间会呈现出比较稳定的：
Power Law。
幂律关系。
2020 年 Kaplan 等人的《Scaling Laws for Neural Language Models》系统研究了这种现象：语言模型的 Cross-Entropy Loss 与模型规模、数据量以及训练 Compute 之间，在很大的尺度范围内都表现出了可预测的幂律趋势。
这件事情真正厉害的地方不是：
“模型大了 Loss 会降。”
而是：
我们居然可以尝试预测，它大到某个程度以后，Loss 大概会降到哪里。
九、什么叫 Power Law？其实没有想象中那么玄
先看一个很简化的形式：
L(N) ≈ A · N^-α + L∞
不要背。
看趋势。
N 增加：
Loss 下降。
但问题是：
不是线性下降。
参数扩大：
10 倍。
不代表：
Loss 变成原来的 1/10。
也不代表：
能力直接 ×10。
规模越大，
继续增加同样比例的资源，
仍然可能获得提升，
但成本会越来越惊人。
这就是我们熟悉的：
Diminishing Return。
边际收益递减。
比如：
100M → 1B
可能明显改善。
1B → 10B
继续改善。
10B → 100B
还是改善。
但你想继续抠出同样多的 Loss Improvement：
需要的 Compute 可能越来越夸张。
所以不要把 Scaling Law 理解成：
“无限堆 GPU，就会线性获得智能。”
更准确的是：
Scaling 告诉我们能力仍然可以通过规模继续购买，但这笔账会越来越贵。
十、为什么 Scaling 曲线经常看起来像直线？
这里顺便把很多论文图里的一个小疑惑解决掉。
Power Law：
y = axᵇ
两边取 Log：
log y = log a + b log x
有没有发现？
后面变成了：
一条直线形式。
所以 Scaling 论文非常喜欢使用：
Log-Log Plot。
双对数坐标。
你会看到：
100M。
1B。
10B。
100B。
这些差了很多数量级的模型，
最后在 Log Scale 上竟然可以呈现出非常漂亮的趋势。
而这件事情有一个特别现实的价值：
你可能根本不用一上来就训练最终那个：
500B。
1T。
超大模型。
你可以先训练：
100M。
500M。
1B。
3B。
7B。
观察曲线。
然后尝试预测：
更大规模会发生什么。
这意味着：
我们开始可以拿相对便宜的小实验，去指导极其昂贵的大训练。
这才是 Scaling Law 为什么值钱。
十一、可是一个问题仍然没有解决：模型和数据，到底应该先加谁？
Kaplan 的工作已经让人看到：
Model。
Data。
Compute。
之间并不是毫无规律。
但是 Training Compute 有上限。
你不可能：
模型无限大。
数据无限多。
因为钱不是无限的。
所以真正的问题还是：
假设今天就给你这么多 FLOPs。
怎么分？
这时候就出现：
Compute-optimal Training。
计算最优训练。
先把它翻译成人话：
在固定训练算力下，找到更合理的 Model Size 和 Training Tokens 组合。
重点来了。
Compute-optimal 追求的并不是：
最大的模型。
而是：
同样的钱，最后 Loss 最低。
这两个目标差得非常远。
十二、2022 年 Chinchilla 做了一件特别重要的事：重新算了这笔账
2022 年，Hoffmann 等人的 Chinchilla 工作专门研究：
在固定 Compute Budget 下，
Model Size 和 Training Tokens 应该怎样配。
他们训练了 400 多个不同配置的语言模型，模型规模覆盖约 70M 到 16B 参数，数据量覆盖 5B 到 500B Tokens。实验给出的关键结论是：在他们研究的 Compute-optimal 区间中，模型规模和训练 Token 数应该大体同步增长。也就是说，如果模型规模翻倍，训练 Tokens 也应该大约翻倍。
这句话看起来特别普通。
其实非常狠。
因为它意味着：
假如 Compute 多了，
你不应该本能地：
全部拿去堆 Parameter。
Data 也应该一起长。
十三、来算一个很有意思的账：10 倍 Compute，不代表 10 倍模型
还记得：
C ∝ N × D
吗？
假设按照一个极简的平衡思想：
Model Size 扩大：
k 倍。
Training Tokens 也扩大：
k 倍。
那么新的 Compute：
k × k = k²
现在假设：
Compute 增加 10 倍。
那么：
k² = 10
所以：
k ≈ √10 ≈ 3.16
也就是说：
在这个极度简化的直觉下：
10 倍 Compute，
可能并不是：
模型 ×10。
而更像：
Model ×3.16
同时：
Data ×3.16
因为：
3.16 × 3.16 ≈ 10。
第一次真正把这个式子算出来的时候，你会发现一件特别反直觉的事情：
更多算力，并不天然属于更多 Parameter。
Data 也在跟 Parameter 抢这笔预算。
这才是真正的 Scaling。
十四、“最大的模型”和“算力利用最好的模型”，第一次分家了
Chinchilla 有一个非常经典的例子。
Gopher：
280B Parameters。
Chinchilla：
70B Parameters。
Chinchilla 的参数只有 Gopher 的四分之一左右。
如果按照最粗暴的 Parameter Ranking：
谁大？
当然 Gopher。
但是 Chinchilla 使用了大约 4 倍更多的训练数据，在相近训练 Compute 下，最终在大量下游评测上超过了 Gopher。
这一幕为什么这么重要？
因为它狠狠打碎了一个特别容易形成的错觉：
最大的模型 = 最好的训练方案。
不一定。
你造了一个特别大的模型。
但如果它没读够书，
它可能还不如一个小很多、却训练得更充分的模型。
所以以后再看到：
“某某模型 500B。”
别急着高潮。
继续问：
训练了多少 Token？
Data Quality 怎么样？
Training Compute 是多少？
有没有被充分训练？
如果这些东西不知道，
单独一个 Parameter Count：
信息其实非常有限。
这里有一句特别适合留下：
Parameter Count 告诉你脑子造了多大，Training Tokens 才告诉你这个脑子到底读了多少书。
十五、现在终于可以把 Under-training 讲准确了
假设一个模型：
特别大。
但是在固定 Compute Budget 下，
为了容纳它巨大的 N，
你只能把 D 压得很小。
结果：
模型很大。
训练 Token 却不够。
那么它就可能：
Under-trained。
训练不足。
注意：
不是模型完全没训练。
而是：
这个 Capacity 没有获得足够的 Training Signal。
就像建了一所超级大学。
一百栋教学楼。
五十个实验室。
两万间宿舍。
最后：
只招了 200 个学生。
你当然可以对外宣传：
“我们学校面积全国第一。”
但问题是：
这堆 Capacity 根本没吃满。
所以：
Under-training 本质上不是“训练时间短”，而是模型容量与训练信号严重不匹配。
这时候继续加 Parameter，
很多 Compute 可能还不如拿去增加 Data。
十六、那反过来，是不是会有 Over-training？
会。
但这里特别容易被一个词骗到。
Over-training ≠ Overfitting。
Overfitting：
过拟合。
讲的是：
训练集越来越好。
泛化越来越差。
而我们这里说的小模型训练大量 Tokens，更准确的意思是：
相对于某个特定的 Training Compute Optimum，这个模型可能训练得超过了最省训练算力的点。
重点是：
这不一定是一件坏事。
甚至现实中经常故意这么做。
为什么？
因为训练成本只付一次。
Inference：
推理成本。
可能要付十亿次。
十七、这件事特别像买车：别只算出厂成本，还得算以后每天烧多少油
假设我们有两个模型。
A：
100B。
训练 Compute 非常划算。
B：
20B。
为了把能力追上来，
训练了更多 Token。
如果只看：
Pretraining Compute，
A 可能更优。
可是模型上线以后：
每天调用 10 亿次。
这时候：
100B 每一次 Forward 都更贵。
20B 每一次 Forward 都便宜很多。
一年呢？
三年呢？
这时候企业真正应该优化的，已经不是：
Training Cost。
而可能是：
Training + Inference Total Cost。
所以：
一个模型即使在纯训练视角下看起来“训练得偏久”，
也可能换来了：
更低的部署成本。
更小显存。
更低 Latency。
更高 Throughput。
这就是为什么：
Compute-optimal
后面永远都必须跟一句：
对于什么目标？
Training-optimal？
Inference-optimal？
Latency-optimal？
Cost-optimal？
这些根本不是同一道题。
这里有一句非常重要：
工程世界里没有脱离目标函数的“最优”。
上一课这句话适用于 Optimizer。
这一课同样适用于 Scaling。
十八、到这里还没完，因为“1T Token”这个数字本身也会骗人
前面为了把逻辑讲清楚，我们一直把数据简化成：
D。
好像：
1T Token
就是：
1T Token。
可真实训练根本不是这样。
假设两份数据。
数据 A：
高质量书籍。
代码。
数学。
论文。
经过严格 Filtering（过滤）。
Deduplication（去重）。
低垃圾率。
另外一份 B：
广告。
重复网页。
SEO 垃圾。
机器拼接内容。
大量低质量文本。
两边都是：
1T Tokens。
你觉得 Training Signal 一样吗？
显然不一样。
所以这里必须再补一个非常重要的概念：
Data Quantity
数据数量。
和：
Data Quality
数据质量。
不是一回事。
这也是为什么现实中的 Scaling 根本不能只背：
“XX Tokens per Parameter。”
然后全行业通用。
因为你的：
Data Distribution。
Data Quality。
Tokenizer。
Architecture。
Optimizer。
都会改变最后的曲线。
所以我其实不太喜欢把 Scaling Law 教成：
“背一个神奇比例。”
真正值得学的是：
研究方法。
十九、所谓 Scaling Law，真正值钱的是“能在烧大钱之前先做小实验”
现在换成真正的 Frontier Model 团队视角。
假设最后要训练一个巨型模型。
一次正式训练：
代价极高。
你当然不可能每个想法都直接：
“上集群！”
跑完发现不行。
重来。
又不行。
再重来。
这种试错方式根本扛不住 Frontier Training 的成本。
于是怎么办？
先训练 Small-scale Model。
比如：
100M。
500M。
1B。
3B。
改变：
Parameters。
Training Tokens。
Learning Rate。
Batch Size。
Data Mixture。
然后看：
Loss Curve。
Validation Loss。
Scaling Trend。
如果小规模实验出现了稳定规律，
就尝试进行：
Extrapolation。
外推。
预测更大规模。
所以 Scaling Law 真正带来的工程价值其实非常朴素：
用小钱犯错，再用大钱训练。
或者换一句我更喜欢的：
真正昂贵的训练，不应该负责发现最基本的规律；那些规律应该尽量在便宜的时候就被摸清楚。
这才是一个成熟训练团队该有的思维。
二十、但是别把 Scaling Law 当成算命
讲到这里，很容易又走向另一个极端。
既然：
100M
1B
3B
都在一条漂亮的 Scaling Curve 上。
那是不是拿直尺往后一延：
1T
也一定在那里？
不一定。
因为模型变大以后会出现以前根本没遇到的问题。
比如：
Optimization Stability。
优化稳定性。
Communication Bottleneck。
通信瓶颈。
Memory Bottleneck。
显存瓶颈。
Data Exhaustion。
高质量数据耗尽。
Architecture Bottleneck。
架构瓶颈。
甚至硬件利用率都会改变。
所以：
Scaling Law 是：
Empirical Law。
经验规律。
不是：
物理宇宙定律。
它能帮我们做：
Prediction。
Decision。
Resource Planning。
但不能保证：
未来一定严格照着曲线发生。
所以：
Scaling Law 是地图，不是命运。
二十一、还有一个更容易被忽略的问题：Loss 下降，不等于所有能力一起等比例上涨
别忘了我们研究的很多 Scaling Law，
首先观察的是：
Cross-Entropy Loss。
也就是：
Next Token Prediction
做得怎么样。
但是用户真正关心的能力可能是：
数学。
代码。
长上下文。
Instruction Following。
Tool Use。
Agent。
复杂推理。
这些能力和 Pretraining Loss 有关系，
但不能简单写成：
Loss 降 10%
→ 数学能力提升 10%
→ Coding 提升 10%
→ Agent 提升 10%
没这种公式。
所以以后看到某个 Scaling Curve 特别漂亮，
不要马上脑补：
“所有智能都可以沿着这一条线预测。”
能预测什么，
首先取决于：
你测量了什么。
这一点等以后进入：
SFT。
RL。
Reasoning。
Agent Training。
还会再次出现。
二十二、现在重新回答开头：老板给你 10 倍 GPU，怎么办？
如果你现在回答：
“那我训练 10 倍大的模型。”
说明这一课白看了。
真正应该做的是先问：
我当前是：
Model-limited？
还是：
Data-limited？
现在这个 Model Size：
是不是已经 Under-trained？
继续增加 Parameter：
边际收益还有多少？
Data Quality：
还能不能继续扩？
我的目标到底是：
最低 Pretraining Loss？
最终 Benchmark？
最便宜 Inference？
最低 Latency？
还是产品生命周期总成本？
然后：
才轮到决定：
Model Size。
Training Tokens。
Compute Allocation。
所以大模型 Scaling 最终真正研究的是：
如何把有限的 Compute，兑换成尽可能多的模型能力。
这才是今天最重要的答案。
二十三、把 Parameters、Data、Compute 翻译成人话
如果几天以后，
你已经忘记：
Kaplan。
Chinchilla。
甚至忘记：
Power Law 公式。
都没关系。
但是下面这三个对应关系一定留下。
Parameters
不要记：
“模型多少 B。”
记：
Capacity。
模型可以被塑造成多复杂。
Data
不要记：
“多少 T Tokens。”
记：
Training Signal。
有多少有效信息可以真正塑造 Parameter。
Compute
不要记：
“多少张 H100。”
记：
Budget。
你允许 Model 和 Data 发生多少训练计算。
然后三者合在一起：
Capacity × Training Signal，在 Compute Budget 下做资源配置。
这就是 Scaling。
二十四、真正学懂以后，你再看到“700B 参数”，反应应该完全不一样
以前看到：
“700B。”
第一反应：
卧槽，好大。
现在应该继续问：
700B 是：
Total Parameters？
还是：
Activated Parameters？
训练了多少 Tokens？
训练 Compute 多少？
Data Quality 怎么样？
为什么选 700B？
为什么不是：
200B + 更多数据？
是不是充分训练？
这些问题，
才叫站在模型训练角度看一个 Frontier Model。
等等。
刚才里面出现了一个词：
Activated Parameters。
激活参数。
这是什么？
这个词会直接把我们带到下一课。
因为 Scaling Law 虽然告诉我们：
Model Capacity 有价值。
可传统 Dense Model 有一个非常恶心的问题。
二十五、Dense Model 最大的矛盾：你想要更大的脑子，就得每次都让整个脑子工作
假设有一个：
100B Dense Model。
来了一个 Token。
模型 Forward。
大量 Parameter 参与计算。
现在想增加 Capacity。
怎么办？
扩大到：
200B。
500B。
1T。
Capacity 确实越来越大。
但是每一个 Token 需要付出的 Compute：
也越来越贵。
也就是说：
传统 Dense Scaling 把两个东西死死绑在了一起。
Total Capacity。
模型一共有多少能力空间。
和：
Per-token Compute。
每来一个 Token 到底要算多少。
模型变大：
两个一起涨。
这才是真正麻烦的地方。
二十六、想象一家拥有 1000 个专家的公司
公司里有：
1000 个 Expert。
有人懂：
Python。
有人懂：
法律。
有人懂：
服装。
有人懂：
数学。
有人懂：
金融。
有人懂：
医学。
现在用户问了一句：
“Python 里面怎么把 List 去重？”
如果这是 Dense Model 的逻辑：
怎么办？
1000 个专家：
全部开会。
法律专家来了。
医学专家来了。
服装专家来了。
数学专家来了。
金融专家也来了。
1000 个人全部坐会议室。
然后共同回答：
Python List 怎么去重。
是不是有点离谱？
但这就是下一课最关键的矛盾。
我们真正需要的是：
公司可以：
拥有 1000 个专家。
但是一个任务来了以后：
只叫最相关的：
几个专家。
那么会发生什么？
公司的：
Total Capacity
可以非常大。
但是一次任务真正花掉的：
Activated Compute
却可以很小。
注意。
这一刻我们实际上干了一件非常重要的事情：
把“拥有多少参数”和“每次使用多少参数”拆开了。
二十七、这就是下一代 Scaling 问题真正开始的地方
这一课我们一直在研究：
Parameters。
Data。
Compute。
最后发现：
Dense Model 有一个根本问题。
如果增加：
Parameters，
通常也会提高：
Per-token Compute。
那有没有可能：
模型总参数：
1T。
但一个 Token 来了以后：
只激活：
几十 B？
这样：
我们仍然拥有：
巨大的 Capacity。
但是：
不需要每次都支付 1T Dense Model 的全部计算成本。
如果答案是：
可以。
那么我们就进入了现代 Frontier Model 一个非常重要的世界：
Sparse Computation。
稀疏计算。
而 Sparse Computation 真正著名的一种实现路线，就是：
MoE。
Mixture of Experts。
混合专家模型。
但下一课我不会一上来就让你背：
Router。
Top-K。
Expert。
Load Balancing。
那种讲法很容易再次变成名词大全。
我们还是按照这门课一直使用的方法来。
先问：
Dense 到底哪里出了问题？
然后一步一步把 MoE 从这个问题里“逼”出来。
二十八、这一课如果只允许带走五句话
第一句：
Parameter 买来的不是能力，而是能力的可能性。
第二句：
Data 决定的不是模型有多大，而是这些 Parameter 到底能被塑造成什么。
第三句：
Scaling 最怕的不是资源少，而是 Parameters、Data、Compute 三者严重失衡。
第四句：
Compute-optimal 追求的不是“最大的模型”，而是“同样一笔算力，怎么花最值”。
第五句：
真正理解 Scaling 以后，你看到的不再是 7B、70B、700B，而是一场 Capacity、Training Signal 和 Compute Budget 之间的资源交易。
如果这五句话你真的理解了，
以后再看到：
10T Tokens。
100B Parameters。
1T Parameters。
多少 FLOPs。
多少张 GPU。
你看到的就不再是一堆很唬人的大数字。
你会开始问：
为什么资源要这么配？
而一旦开始问这个问题，
你才真正开始站到了：
Model Training
而不是：
Model User
的视角。
下一课：当模型越来越大，为什么不能只让“该干活的人”干活？
Scaling Law 告诉我们：
更大的 Capacity 仍然有价值。
但 Dense Model 的代价也越来越明显：
模型有多少 Parameter，每个 Token 就得为这套巨大模型支付越来越昂贵的计算成本。
于是下一课的问题会非常直接：
假设：
我想拥有：
1T Parameters 的 Capacity。
但我不想：
每处理一个 Token 都算 1T Parameters。
怎么办？
这会把我们第一次真正带进：
Sparse Computation。
以及现代超大模型绕不开的一条核心路线：
MoE，Mixture of Experts——混合专家模型。
下一课真正要解决的，不是：
“MoE 是什么？”
而是一个更根本的问题：
为什么一个拥有 1000 个专家的公司，处理一个 Python 问题时，非得让 1000 个人全部开会？
想明白这一点，
MoE 就不再是一个难记的模型缩写。
它会变成 Dense Scaling 走到一定规模以后，几乎必然会出现的一种答案。
