第 7 课：Scaling Laws 与算力预算

第一部分我们看清了模型长什么样。现在进入第二部分——模型是怎么被"造"出来的。第一站是最底层的约束：给定一笔算力预算，该造多大的模型、喂多少数据？这不是拍脑袋，而是有可计算的公式。

🎯 学完这 6 步你将能够：
① 用 C ≈ 6ND 估算一次训练的算力，并反推给定预算下的最优模型大小与 token 数
② 说清 Chinchilla 的 20:1 规则怎么来的，以及为什么现代模型故意"过训练"
③ 判断一个模型的训练配方是否合理，并解释 MoE（混合专家：把模型拆成许多个专家子网络，每个 token 只激活其中少数几个，用较少计算换取更大参数量）为什么让数据墙更严重
🗺 本节推理链（6 步：从"算力怎么算"到"给定预算怎么分配"）
1要谈"该造多大模型"，必须先能算清一次训练花多少算力——因此需要一条可复算的公式：训练 FLOPs ≈ 6 × 参数量 × token 数（前向 2 + 反向 4），否则"预算"只是一个说不清的量。
↓
2有了算力公式，下一个问题是这笔算力怎么在"模型大小 N"和"数据量 D"之间分——这就要求做实验找出最优分配：Chinchilla 用 400+ 次训练发现 N 与 D 应等比例增长（各正比于 C0.5），于是得到"约 20 token / 参数"的经验规则。
↓
3但 20:1 只是"训练最省"的点，因为 inference 成本正比于参数量而非 token 数，所以现代模型故意过训练——用远超 20:1 的数据量训一个更小的模型，训练多花一点、推理长期省很多（Llama 3 8B 用了约 1875:1）。
↓
4过训练需要海量数据，这就要求回答"数据够不够"——高质量公开文本约 300 万亿 token（估算），而 Chinchilla 规则下万亿参数模型需要 20 万亿 token 量级，于是出现"数据墙"：算力还在涨，可用的新数据却快见底。
↓
5数据墙之下，因此出现两条绕行路线：一是 MoE（把总参数做大、激活参数压住，用容量换数据效率），二是合成数据与数据复用；但 MoE 让 token 需求按总参数而非激活参数增长，于是数据墙反而更严重。
↓
6把上面五步收成一个可操作的决策流程：给定预算 C → 用 Nopt ≈ √(C / (6 × 20)) 定模型大小 → 按过训练倍数定 token 数 → 检查数据是否够 → 不够则考虑 MoE 或合成数据，于是你就能自己审一份训练配方。
Scaling LawsChinchillaCompute BudgetOvertrainingData WallMoE
1
模型越大越好，还是数据也要按比例跟上？——两篇论文为此打了一架，后来谁赢了？
提示：先想"模型大小"和"数据量"是不是在抢同一笔算力预算；再看两篇论文各主张把预算多分给谁；最后想：如果实验口径或做法有偏差，结论会不会整个反过来。
▾
知识背景
Scaling Law（缩放律：把「模型多大、数据多少」写成能预测的经验公式）领域最有名的一次分歧。① Kaplan et al. 2020（《Scaling Laws for Neural Language Models》, arXiv:2001.08361）：损失随模型规模 N、数据量 D、算力 C 呈幂律（power law：损失按固定指数随规模下降的规律）下降；他们发现「更大的模型样本效率更高」，主张把算力主要投给模型——算力翻 10 倍时，参数涨约 5.5 倍、数据只涨约 1.8 倍。② Hoffmann et al. 2022（《Training Compute-Optimal Large Language Models》, arXiv:2203.15556，DeepMind）：用 400+ 次受控实验修正为 N 与 D 近似等比例增长（各 ∝ C0.5），经验上约 20 token / 参数；并用 70B 参数、1.4T token（模型读写文本的最小单位）的 Chinchilla，在同等的算力下打败了 280B 参数的 Gopher。痛点：当时整个行业都在「把模型做大、数据几乎不变」，却没人验证过这笔账到底该怎么分。

上一课我们把 LLM 家族画成了一张全景图。从这一课起，镜头切到「模型是怎么被造出来的」，第一站是最底层的约束——算力。

要谈「该造多大模型」，前提是先能算清一次训练花多少算力。这条公式（训练 FLOPs ≈ 6 × 参数量 × token 数，算力按 BF16（一种训练常用的半精度浮点格式）口径计）已在第 5 课推导过，这里直接拿来用，不再重复。

但「怎么算」只是一把尺子，真正有故事的问题是怎么分：同一笔算力预算，是换成一个更大的模型，还是换成更多的训练数据？2019 到 2022 年，这个问题被两篇论文公开「吵」了一架。

可以把这类比成给仓库配货架和货：算力是装修预算，货架是模型参数（决定能装多少），货是要喂的数据（决定装了什么）。Kaplan 一派说「多搭货架，货少一点也高效」；Chinchilla 一派说「货架和货要按比例一起加，光搭货架是浪费」。

谁赢了、为什么赢，以及这个故事怎么直接引出后面「过训练」的那张卡，都在下面的算账里。

照 Kaplan 的配方，算力会被浪费：GPT-3 用 175B 参数却只喂了 300B token（约 1.7 token / 参数），而按后来修正的 20:1，它本应喂约 3.5T token——数据少了约 12 倍，多出来的是「空转」的大模型。

🧮 两篇论文的算账：同一笔预算到底怎么分
Step 1：两派的主张——算力翻 10 倍，各分给谁
论文参数量随算力增长数据量随算力增长两者相乘（≈6ND 倍数）
Kaplan et al. (2020)N ∝ C0.73（约 5.5×）D ∝ C0.27（约 1.8×）5.5 × 1.8 ≈ 9.9×
Chinchilla (2022)N ∝ C0.50（约 3.16×）D ∝ C0.50（约 3.16×）3.16 × 3.16 ≈ 10×
两派都自洽——都把算力放大了约 10 倍。差别全在「给谁多」：Kaplan 让模型涨 5.5 倍、数据只涨 1.8 倍；Chinchilla 让两者都涨约 3.16 倍。这就是「模型越大越好」与「数据也要跟上」的分歧点。
Step 2：同一笔预算，两种分法各花多少（数值为示意）
方案参数量 N数据 D算力 6ND相对基准
基准（示意）10B100B6 × 10e9 × 100e9 = 6 × 10²¹1×
只把参数翻倍（Kaplan 式）20B100B6 × 20e9 × 100e9 = 1.2 × 10²²2×
参数与数据一起翻倍（Chinchilla 式）20B200B6 × 20e9 × 200e9 = 2.4 × 10²²4×
同样把参数翻倍：数据不动，算力只涨 2 倍；数据跟着翻倍，算力才涨 4 倍。因为 C ≈ 6ND 是 N 与 D 的乘积——两者各翻一倍，乘积就翻四倍。（这一组数值是示意，不指向任何真实模型。）
Step 3：把「20:1」解出来
步骤计算结果
算力公式C ≈ 6 × N × D——
代入 D = 20 NC ≈ 6 × N × 20N= 120 N²
反解模型大小N ≈ √(C / 120)给定预算即可定 N
复算 Chinchilla70B × 20= 1.4 × 10¹² = 1.4T token
70B × 20 = 1.4T，与论文里 Chinchilla 的「70B 参数、1.4T token」完全对上。所以「20 token / 参数」不是拍脑袋的经验值，而是从 N ∝ C0.5、D ∝ C0.5 与 C ≈ 6ND 联立解出来的。
Step 4：Gopher vs Chinchilla——同算力下的胜负
模型参数量训练 tokentoken / 参数训练算力 6ND
Gopher280B300B≈1.16 × 280e9 × 300e9 ≈ 5.04 × 10²³
Chinchilla70B1.4T206 × 70e9 × 1.4e12 ≈ 5.88 × 10²³
两者算力几乎一样（5.04e23 vs 5.88e23，相差约 17%），Chinchilla 的参数只有 Gopher 的 1/4，却在多数基准上更好。这一局 Chinchilla 赢——因为 Gopher 正是「模型大、数据少」的旧配方（1.1 token / 参数，远低于 20）。
🎯 关键认知

这不是「谁对谁错」的学术八卦，而是一次关于口径与实验方法的教训：Kaplan 的分配之所以偏保守，是因为实验中的口径偏差（哪些参数与算力被计入）与设置差异，把结论推向了「模型越大越好」。Chinchilla 修正后给出一个可复算的答案——同一笔算力下，模型与数据应近似等比例增长（约 20 token / 参数）。但「训练最省」不等于「总成本最省」：工业界很快发现，把模型压小、数据喂到远超 20:1（过训练），长期推理反而更便宜——这正是本课第 3 张卡要算的账。

AI 助教
👋 对 Kaplan 与 Chinchilla 的分歧有疑问？比如「为什么两篇会算出不同答案？」「20:1 是普适常数吗？」

我会用具体数字帮你算。
2
给定一笔算力预算，模型该造多大、数据该喂多少？
提示：先想两个极端——模型极大但数据极少，和模型极小但数据极多，哪个更亏？再想"每翻倍一次模型，数据该跟着翻多少"。
▾
知识背景
Chinchilla 缩放律（Hoffmann et al., DeepMind, 2022）：在固定算力预算下，模型大小 N 与训练 token 数 D 应等比例增长——Nopt ∝ C0.5、Dopt ∝ C0.5，经验上约 20 token / 参数。论文训练了 400+ 个模型（70M~16B 参数、5B~500B token）得出该结论，并用 70B 参数 / 1.4T token 的 Chinchilla 模型在同等算力下击败了 280B 参数 / 300B token 的 Gopher。

上一张卡片我们有了算力公式 C ≈ 6ND。现在问题来了：给定一笔预算 C，N 和 D 该怎么分？

先看两个极端：模型极大但数据极少（参数没喂饱），或模型极小但数据极多（容量不够用）。因为两者都会浪费算力，所以必然存在一个最优分配点——Chinchilla 用 400+ 次实验把它找了出来。

可以把这类比成给一个固定大小的厨房配厨师和食材：厨师太多（参数大）但食材不够，厨师闲着；厨师太少（参数小）但食材堆积，做不完。最优配比是两者同步增长。

🧮 Chinchilla 规则：从实验到 20:1
Step 1：Kaplan 与 Chinchilla 的分歧
结论Nopt 的指数Dopt 的指数含义
Kaplan et al. (2020)C0.73C0.27算力主要用来放大模型
Chinchilla (2022)C0.50C0.50模型与数据等比例增长
分歧的根因有三条（Porian et al., 2024, arXiv:2406.19146）：① 算力 / 参数口径——Kaplan 统计 non-embedding 参数、且未计入最后一层等算力项；② 学习率与 warmup——各 run 用同一套固定调度，短训练被系统性低估，Chinchilla 把调度对齐到每个 run 的实际长度；③ 实验规模——Kaplan 主要靠小模型外推。三条一并修正后，结论就与 Chinchilla 一致了。
Step 2：20:1 是怎么算出来的
项目计算结果
算力公式C ≈ 6 × N × D——
代入 D = 20NC ≈ 6 × N × 20N = 120 N²——
反解 NNopt ≈ √(C / 120)给定预算即可算最优参数量
Chinchilla 验证N = 70B → D = 20 × 70B= 1.4T token（与论文一致）
所以"20 token / 参数"不是拍脑袋的经验值，而是从 N ∝ C0.5、D ∝ C0.5 与 C ≈ 6ND 联立解出来的。
Step 3：Gopher vs Chinchilla——同算力下的对照实验
模型参数量训练 tokentoken/参数MMLU 平均（Chinchilla 论文口径，可核验）
Gopher280B300B≈1.160.0%
GPT-3175B300B≈1.743.9%
Chinchilla70B1.4T2067.5%
Chinchilla 参数只有 Gopher 的 1/4，MMLU 平均却从 60.0% 提到 67.5%（同一论文口径），且用几乎同样的算力——这直接证明了"当时的模型普遍训练不足"。（表中为 MMLU 平均，非全基准平均；早期曾引用"75.1/73.9/77.7"的写法查无一手来源，已改用可核验口径。）
🎯 关键认知

Chinchilla 的结论可以一句话概括：在固定算力下，模型大小和数据量应该同步增长，而不是一味放大模型。这条规则把"该造多大"从直觉变成了可计算的问题——给定预算 C，最优参数量就是 √(C/120)。

AI 助教
👋 对 Chinchilla 规则有疑问？比如"为什么 Kaplan 会算错？""20:1 是普适常数吗？"

我会用具体数字帮你算。
3
既然 20:1 最省算力，为什么现代模型要故意"过训练"？
提示：算力只在训练时花一次，但模型上线后要被调用几亿次。想清楚"训练省"和"推理省"是不是同一件事。
▾
知识背景
过训练（Overtraining）：故意用远超 Chinchilla 最优比例的数据量去训一个更小的模型。原因是推理成本正比于参数量——模型训一次、服务几十亿次，把参数压小、数据喂多，长期总成本更低。实测比例：Llama 2 70B 约 28 token/参数，Llama 3 8B 约 1875 token/参数（Chinchilla 建议约 160B token，实际用了 15T）。

上一张卡片我们得到 20:1 这个"训练最省"的点。但现实是：Llama 3 8B 用了约 1875:1——是 Chinchilla 建议的近 100 倍。为什么？

因为算力只在训练时花一次，而推理成本要跟着模型服务一辈子，所以"训练最省"不等于"总成本最低"。可以把这类比成买车：买车时多花点钱买省油的车，长期油费省得更多。反过来说，死守 20:1 也不划算：8B 模型按 20:1 只需喂约 160B token，训练端暂且省了，可上线之后推理要按每次调用重复付出——省的是「训练一次」，亏的是「推理一辈子」。

🧮 过训练账：训练多花 vs 推理省下
Step 1：两种方案的训练成本对比
方案参数量 Ntoken Dtoken/参数训练算力 6ND
Chinchilla 最优70B1.4T20:16 × 70e9 × 1.4e12 = 5.9 × 10²³
过训练（示意）20B4T200:16 × 20e9 × 4e12 = 4.8 × 10²³
过训练方案把模型压到 20B、数据加到 4T（200:1），训练算力 4.8e23 比 Chinchilla 最优的 5.9e23 低约 19%——即"用低一档的训练算力，换一个更小、但喂得更饱的模型"。
Step 2：推理成本才是大头
项目70B 模型20B 模型倍数
单次推理 FLOPs（每 token）2 × 70e9 = 1.4e112 × 20e9 = 4.0e103.5×
权重显存（fp16）140 GB40 GB3.5×
假设服务 10¹² 个 token1.4e23 FLOPs4.0e22 FLOPs3.5×
推理算力 = 2 × N × 生成 token 数（只有前向，系数 2）。注意：这里只算权重项，未计入注意力随序列长度平方增长的部分——长上下文推理时该项会显著上升（与 7-1 追问 4 的口径一致）。服务量越大，参数量带来的差距越致命。
Step 3：盈亏平衡点在哪
项目计算结果
训练算力差5.9e23 − 4.8e231.1 × 10²³ FLOPs（70B 多花）
每 token 推理算力差1.4e11 − 4.0e101.0 × 10¹¹ FLOPs
平衡服务量1.1e23 ÷ 1.0e11≈ 1.1 × 10¹² token
只要模型累计服务超过约 1.1 万亿 token，过训练方案的总算力就更省。对一个日活百万的产品，这个量级几周就能达到——所以过训练几乎总是划算的。
🎯 关键认知

Chinchilla 回答的是"训练最省"，而工业界要的是"总成本最省"。因为推理成本正比于参数量、且要乘以服务次数，所以把模型压小、把数据喂多（过训练）几乎总是更优——这就是为什么现代开源模型普遍在 100:1 到 2000:1 之间，而不是 20:1。

AI 助教
👋 对过训练有疑问？比如"过训练有没有上限？""为什么不能无限过训练？"

我会用具体数字帮你算。
4
过训练需要海量数据，可用的高质量文本到底还剩多少？
提示：先估一下互联网上高质量公开文本的总量，再算一个万亿参数模型按 Chinchilla 规则需要多少 token。两个数一对比，问题就出来了。
▾
知识背景
数据墙（Data Wall）：Epoch AI 估算互联网上高质量、可公开获取的人类文本总量约 300 万亿 token（估算值，不同机构定义差异大），并预测这一存量将在 2026~2032 年间（80% 置信区间）被完全用尽。而按 Chinchilla 规则，一个 10 万亿参数模型需要约 200 万亿 token。同时，MIT 牵头的 Data Provenance Initiative 发现：一年内 28% 的最活跃维护的关键来源被施加了访问限制（改服务条款或技术封锁），C4 数据集中已有 45% 受限。

上一张卡片我们看到过训练需要海量数据。那问题来了：数据够吗？

因为高质量公开文本的总量是有限的，而模型规模还在指数增长，所以必然存在一个"撞墙"的时刻。可以把这类比成粮仓：粮食总量固定，但吃饭的人越来越多、饭量越来越大。

🧮 数据墙账：需求 vs 存量
Step 1：需求侧——不同规模模型要多少 token
模型规模Chinchilla 最优 token（20:1）过训练 100:1
7B140B700B
70B1.4T7T
405B8.1T40.5T
1T20T100T
10T200T1000T
注意：过训练把需求又放大了 5 倍。10T 参数模型按 100:1 需要 1000 万亿 token——远超存量估算。
Step 2：供给侧——存量与"被锁住"的部分
项目数值说明
高质量公开文本存量≈300 万亿 tokenEpoch AI 估算（口径差异大）
被施加访问限制约 25%~28% 的最活跃关键来源（二手来源口径不一）Data Provenance Initiative 报告；"C4 中 45% 受限"未见一手原句，需人工核实
实际可用（保守估计）≈216 万亿 token 量级（按"关键来源 28%"近似套用于 token 存量，粗估）300 × (1 − 28%)
被锁住的恰恰是最活跃维护、质量最高的那部分（新闻、论坛、代码托管），不是边角料。注意口径：28% 指"关键来源"的占比，不是"全部 token"的占比（后者约 5%）——若严格按 token 级受限比例（约 5%）算，可用存量约 285 万亿；两种口径结果不同（216T vs 285T），此处取保守的 216T，数值需人工核实。
Step 3：缺口有多大
对比项需求可用存量缺口
1T 参数模型（20:1）20T216T无缺口
10T 参数模型（20:1）200T216T接近耗尽
10T 参数模型（100:1）1000T216T缺 4.6 倍（按 285T 口径则约 3.5 倍）
结论：在 Chinchilla 规则下，10T 参数模型已经接近耗尽全部高质量文本；若再叠加过训练，缺口达数倍。这就是"数据墙"的量化含义。
🎯 关键认知

数据墙不是"没有数据"，而是"能直接下锅的数据不够"：存量有限（约 300 万亿 token，估算）、最活跃的关键来源还在被锁（28%）、而过训练又把需求放大了 5 倍。这三者叠加，使得"继续靠堆数据提升能力"这条路在 2026~2032 年间逐步失效。

AI 助教
👋 对数据墙有疑问？比如"300 万亿 token 这个数怎么估的？""数据不够了怎么办？"

我会用具体数字帮你算。
5
数据不够了，MoE 能解决问题吗？
提示：先想 MoE 省的是什么——是显存还是算力？再想"每个专家要看到多少 token 才能学好"，这个需求是按总参数算还是按激活参数算？
▾
知识背景
MoE 与数据需求：稀疏 MoE 模型比 dense 模型更容易过拟合（Fedus et al., 2022；Zoph et al., 2022）。原因是每个专家在均衡路由下只看到约 K/E 的训练 token（K 为每 token 激活的专家数、E 为专家总数；本例 8/256 = 1/32），重复数据对它的伤害更大。因此 MoE 的数据需求按总参数而非激活参数增长——这让数据墙更严重，而不是更轻。

上一张卡片我们看到数据墙。一个自然的想法是：用 MoE 不就能绕过去吗？——毕竟 MoE 每 token 只激活一小部分参数，看起来"更省"。

但这个直觉是错的。因为 MoE 省的是算力不是显存，而数据需求恰恰跟着总参数走，所以 MoE 让数据墙更严重。可以把这类比成一家有 256 位专科医生的大医院：挂号只叫 8 位进诊室（省算力），但每位医生都得积累足够病例才能成为专家（数据需求按 256 人算）。

🧮 MoE 的数据账：为什么它让数据墙更严重
Step 1：MoE 省的是算力，不是显存
资源看哪个参数以 671B/37B 为例
显存占用总参数671B（4-bit 约 404GB）
每 token 算力激活参数37B（约为总参数的 5.5%）
所以 MoE 让"推理更便宜"，但没让"模型更小"。
Step 2：每个专家看到多少 token
项目计算结果
路由专家数 E——256（DeepSeek-V3 口径，另有 1 个共享专家）
每 token 激活的专家数 K——8（top-8 路由）
每专家实际见到的 tokenD × K ÷ ED × 8 / 256 = D / 32
若 D = 15T15e12 × 8 ÷ 256≈ 4.7 × 10¹¹（4700 亿）
注意口径：因为每 token 会被 8 个专家同时看到，所以每专家见到的 token 是 D×8/E 而非 D/E。即便如此，4700 亿 token 相对 671B 的总参数仍然偏少——专家"吃不饱"，所以需要更多数据。
Step 3：数据需求按总参数还是激活参数
口径数据需求（20:1）是否现实
按激活参数 37B740B token看起来很容易满足
按总参数 671B13.4T token接近 Llama 3 的 15.6T 量级
实测经验支持后者：MoE 模型的数据需求按总参数增长。所以 671B 的 MoE 需要万亿级 token——和 405B dense 模型是同一量级。
🎯 关键认知

MoE 是一个算力-数据交换：用"更多参数、更少激活"换取推理便宜，代价是数据需求按总参数增长。所以在数据墙的背景下，MoE 不是解药——它把问题从"算力不够"换成了"数据更不够"。真正的出路是合成数据、数据复用与推理时计算（test-time compute）。

AI 助教
👋 对 MoE 与数据的关系有疑问？比如"专家数越多越好吗？""共享专家起什么作用？"

我会用具体数字帮你算。
6
拿到一笔预算，怎么一步步定出模型大小和数据量？
提示：把前面五步串起来——先用 C ≈ 6ND 和 20:1 反解参数量，再按过训练倍数定 token 数，最后检查数据够不够。每一步都有公式。
▾
知识背景
把 Scaling Laws 用于工程决策的标准流程：① 用 C ≈ 6ND 把预算换算成算力；② 用 Nopt ≈ √(C/120) 定模型大小（Chinchilla 20:1）；③ 按过训练倍数（通常 100:1~2000:1）定实际 token 数；④ 检查数据存量是否够；⑤ 不够则考虑 MoE、合成数据或推理时计算。这套流程是审阅任何训练配方的通用框架。

前面五张卡片分别讲了算力公式、Chinchilla 规则、过训练、数据墙、MoE。现在把它们串成一个可操作的决策流程。

因为每一步都有明确公式，所以这套流程可以当"审配方"的检查表用——拿到任何一份训练方案，都能逐步验算它是否合理。可以把这类比成装修前的预算表：先算总面积（算力），再定房间数（模型大小），最后核对材料够不够（数据存量）——每一步都能提前验算，而不是装到一半才发现钱不够。

🧮 决策流程：给定预算 C，五步定方案
Step 1：把预算换算成算力
输入换算示例
GPU 数量 × 卡时× 单卡有效算力16384 卡 × 54 天
单卡有效算力BF16 dense 峰值 × 利用率989 TFLOPS × 50% ≈ 4.9e14 FLOP/s（50% 为假设的 MFU，估算）
总算力 C16384 × 4.9e14 × 54×86400≈ 3.8 × 10²⁵ FLOPs
Step 2：用 Chinchilla 反解模型大小
步骤公式代入 C = 3.8e25
Chinchilla 关系C ≈ 120 N²——
反解 NN ≈ √(C / 120)√(3.8e25 / 120) ≈ 5.6 × 10¹¹
结果——≈ 560B 参数（Chinchilla 最优）
注意：这是"训练最省"的点。实际 Llama 3 405B 比它小——因为选择了过训练。
Step 3：按过训练倍数定 token 数，并检查数据
方案参数量token 数数据是否够
Chinchilla 最优560B11.2T（20:1）够（存量 216T）
过训练约 38:1405B15.6T够（Llama 3 实际选择）
过训练 100:1405B40.5T够，但需大量重复
过训练 100:11T100T接近存量上限
Llama 3 405B 实际用了 15.6T token（约 38:1），介于 Chinchilla 最优与激进过训练之间——这是"训练成本"与"推理成本"的折中。
🎯 关键认知

这套流程的价值在于：它把"造模型"从"烧钱试错"变成了"先算后做"。给定预算，你能提前算出模型该多大、数据要多少、会不会撞数据墙——而不是训完才发现配方不对。这也是为什么第二部分后续每一课（数据、预训练、微调、对齐）都要建立在这张算力账上。

AI 助教
👋 对决策流程有疑问？比如"怎么判断一份训练配方是否合理？""预算翻倍该怎么调整？"

我会用具体数字帮你算。

第 7 课完成 · 下一课：第 8 课「数据工程」

进入第 8 课：数据工程 →　·　← 上一课：从 Transformer 到 LLM 全景图