上一课讲完 AdamW 之后大模型训练最微观的一条链终于闭环了。一个 Token 预测错了。Loss 告诉我们错得有多严重。Gradient 告诉我们参数应该往哪边改。Optimizer 再决定这一步到底怎么改。最后θₜ → θₜ₊₁Parameter 真正发生变化。然后下一个 Batch。再变一点。再下一个 Batch。再变一点。如果把大模型训练放到显微镜下面看所谓 Learning其实就是无数次这种小到几乎看不见的 Parameter Update。可问题来了。我们已经知道一个参数是怎么学的。接下来真正麻烦的问题却是到底应该有多少参数7B70B700B为什么这些年模型越做越大是不是只要 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 ModelParameters 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 最怕的从来不是资源少而是资源之间严重失衡。六、现在第三个人终于出场了ComputeParameters 有了。Data 有了。还差一个东西。Compute。计算量。很多人看到 Compute就会把它理解成“有多少张 GPU。”严格来说不对。GPU 是Hardware。硬件。Compute 更接近整个训练过程真正执行了多少计算。对一个传统 Dense Transformer稠密 Transformer经常会用一个非常粗略的工程近似C ≈ 6ND这里C Training ComputeN Number of ParametersD Number of Training Tokens今天不用研究那个 6 从哪里来。我们只看最重要的关系C ∝ N × D什么意思模型越大每处理一个 Token 越贵。Token 越多模型需要重复训练的次数越多。所以大模型 × 大数据 巨大 Compute。这一刻三个变量终于连起来了。ParametersCapacity。DataTraining Signal。Compute你有多少钱让 Capacity 和 Training Signal 真正发生训练。七、现在再看那 10 倍 GPU事情就完全不一样了为了好算我们先不考虑常数。假设C ≈ N × D原来的 Model SizeN 1原来的 Training DataD 1那么C 1。现在老板把 Compute Budget 提升到10。你可以怎么玩方案 AN 10D 1Compute 10方案 BN 1D 10Compute 10方案 CN 2D 5Compute 10方案 DN 5D 2Compute 10甚至还有N ≈ 3.16D ≈ 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 Lawy axᵇ两边取 Loglog 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 倍。那么新的 Computek × 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 有一个非常经典的例子。Gopher280B Parameters。Chinchilla70B Parameters。Chinchilla 的参数只有 Gopher 的四分之一左右。如果按照最粗暴的 Parameter Ranking谁大当然 Gopher。但是 Chinchilla 使用了大约 4 倍更多的训练数据在相近训练 Compute 下最终在大量下游评测上超过了 Gopher。这一幕为什么这么重要因为它狠狠打碎了一个特别容易形成的错觉最大的模型 最好的训练方案。不一定。你造了一个特别大的模型。但如果它没读够书它可能还不如一个小很多、却训练得更充分的模型。所以以后再看到“某某模型 500B。”别急着高潮。继续问训练了多少 TokenData 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推理成本。可能要付十亿次。十七、这件事特别像买车别只算出厂成本还得算以后每天烧多少油假设我们有两个模型。A100B。训练 Compute 非常划算。B20B。为了把能力追上来训练了更多 Token。如果只看Pretraining ComputeA 可能更优。可是模型上线以后每天调用 10 亿次。这时候100B 每一次 Forward 都更贵。20B 每一次 Forward 都便宜很多。一年呢三年呢这时候企业真正应该优化的已经不是Training Cost。而可能是Training Inference Total Cost。所以一个模型即使在纯训练视角下看起来“训练得偏久”也可能换来了更低的部署成本。更小显存。更低 Latency。更高 Throughput。这就是为什么Compute-optimal后面永远都必须跟一句对于什么目标Training-optimalInference-optimalLatency-optimalCost-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 当成算命讲到这里很容易又走向另一个极端。既然100M1B3B都在一条漂亮的 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。以及现代超大模型绕不开的一条核心路线MoEMixture of Experts——混合专家模型。下一课真正要解决的不是“MoE 是什么”而是一个更根本的问题为什么一个拥有 1000 个专家的公司处理一个 Python 问题时非得让 1000 个人全部开会想明白这一点MoE 就不再是一个难记的模型缩写。它会变成 Dense Scaling 走到一定规模以后几乎必然会出现的一种答案。