大模型是怎么来的：从数据到 Foundation Model

大模型是怎么来的：从数据到 Foundation Model

作者：吴佳浩Alben

撰稿时间：2026.5.1 更新时间：2026.8.17

核心问题：一个百亿、千亿参数的大模型到底如何诞生？

今天的内容会比较长能够帮助你更好的理解你天天用的大模型到底是怎么来的，增加的个人的软实力希望我的言语足够简约能够帮助筒子们快速的理解。

在展开任何细节之前，先回答一个最根本的问题：数据为什么最后会变成参数？ 下面这张图，是本文接下来所有章节共同解释的对象------后面每一节，其实都是在放大这张图里的某一段箭头。

简单说：原始数据经过清洗和编码后变成 Token，Token 经过 Embedding 变成向量，向量经过 Transformer 层层计算后给出一个预测，预测的对错通过 Loss 和反向传播转化为"该怎么修改参数"的信号，AdamW 据此更新参数------这个循环在数万亿个 Token 上重复执行，最终收敛出的那组参数，就是 Foundation Model。 下面逐段展开。

---

一、一个 70B 模型到底意味着什么？

在讲数据、讲架构之前，先建立一个直觉：为什么训练一个大模型需要几千张 GPU？

以一个 70B（700 亿）参数模型为例，只看存储参数本身：

参数数量：700 亿
若用 FP16/BF16 存储（每个参数 2 Byte）：

  700亿 × 2 Byte ≈ 140 GB 显存

这只是"放下模型"的开销。真正训练时，还需要同时保存：

训练时显存占用 = 参数 + 梯度 + Adam一阶动量 + Adam二阶动量

以 AdamW + 混合精度训练为例，按每个参数拆算：

  BF16 参数（用于前向/反向计算）        2 Byte
  FP32 Master Weight（主权重，精确更新用）  4 Byte
  FP32 一阶动量（Momentum）             4 Byte
  FP32 二阶动量（Variance）             4 Byte
  BF16/FP16 梯度                       2 Byte
  ------------------------------------------
  合计 ≈ 16 Byte / 参数

70B × 16 Byte ≈ 1120 GB ≈ 1.1 TB

即：训练一个 70B 模型，仅参数、梯度和 Adam 优化器状态就需要约 1TB 级显存，再叠加激活值、通信 buffer 后实际需求更高。

单张 H100 显存也就 80GB，连"放下参数+梯度+优化器状态"都做不到，更不用说还要留出激活值和 KV Cache 的空间。所以结论很直接：

70B 模型的训练阶段，从第一天开始就不是"训练一个模型"这么简单的事，而是一个分布式系统工程问题。

需要特别说明的是，这个"必须依靠大规模集群"的结论主要针对训练阶段 。推理阶段是完全不同的量级问题------通过量化（INT8/FP8/4bit）、KV Cache 优化、模型并行等手段，70B 模型可以部署在 4×H100、8×A100，甚至消费级 48GB 显卡组成的小规模集群上。训练和推理对硬件规模的要求，不能混为一谈。

这也是为什么本文后半部分要花大篇幅讲 Tensor Parallel、Pipeline Parallel、ZeRO/FSDP------它们不是"锦上添花"的优化技巧，而是训练能否跑起来的前提条件。

带着这个体量感，我们再从头梳理一个 Foundation Model 的完整诞生链路：

---

二、数据：大模型真正的燃料

业界公认：数据质量决定模型能力的上限，架构和训练技巧决定能否逼近这个上限。

2.1 数据采集

数据来源	典型占比	特点
Common Crawl（网页快照）	40%~60%	规模最大，质量参差不齐
书籍（Books3、图书馆扫描）	5%~10%	长文本、语言规范
代码（GitHub）	5%~15%	提升推理与结构化能力
学术论文（arXiv、PubMed）	2%~5%	专业知识密度高
百科（Wikipedia）	1%~3%	事实性强、噪声低
对话/论坛（Reddit、StackExchange）	5%~10%	提升问答与推理能力

2.2 清洗、去重、过滤：三道基础工序

一段说明性的清洗代码（核心逻辑，非生产级）：

import re
from langdetect import detect

def clean_document(text: str) -> str | None:
    text = re.sub(r"<[^>]+>", "", text)          # 去HTML标签
    text = re.sub(r"\s+", " ", text).strip()       # 归一化空白
    if len(text) < 200:                            # 过短文档信息量不足
        return None
    try:
        if detect(text) not in ("zh-cn", "en"):     # 语言过滤
            return None
    except Exception:
        return None
    return text

去重最常用 MinHash + LSH（Locality Sensitive Hashing） ：在亿级文档规模下，以近似线性复杂度找出高度相似的文档对并剔除，避免模型对重复内容"过拟合"。过滤则依赖三类手段：启发式规则 （符号占比、重复行数）、质量分类器 （用 Wikipedia/书籍等高质量语料训练分类器打分）、困惑度过滤（用小模型算 perplexity，过高或过低都剔除）。

2.3 数据增强

常见方式：回译 （中→英→中生成新表达）、结构化转写 （表格/知识图谱转自然语言问答）、难例挖掘（针对模型薄弱任务如数学推理定向扩充）。

2.4 从 Internet Data 到 AI Generated Data：一个正在发生的范式转变

这是理解 2025-2026 大模型数据体系必须补充的一环。数据来源正在发生结构性变化：

典型案例：

• 教师模型生成训练数据：用 GPT-4 级别的强模型生成带思维链的解题过程、代码题解，再蒸馏训练学生模型（Phi 系列是代表）
• Qwen：后训练阶段大量使用合成指令数据和拒绝采样数据
• DeepSeek：大量使用合成的数学推理数据来强化推理能力

需要警惕的风险是模型坍缩（Model Collapse）------完全用模型生成的数据训练模型会导致分布收窄、多样性下降，因此合成数据通常要与真实数据混合并严格过滤。

更准确地说，现在的数据格局已经不是简单的"真实数据 vs 合成数据"二元对立，而是四类数据的协同：

真实数据（Internet Data）
    +
模型生成数据（Synthetic Data）
    +
人工验证数据（Human Preference Data）
    +
Agent 交互数据（Agent Generated Data）

其中 Agent 交互数据 是最值得关注的新增量------下一代模型的重要训练素材，可能不再是网页文本，而是 AI 智能体在真实完成任务过程中产生的行为轨迹（如多步工具调用、代码执行反馈、任务成功/失败的完整过程）。这类数据天然带有"结果验证"信号，也是未来 Agent 相关模型能力的重要来源。

一个越来越明显的趋势：高质量数据已经成为比参数规模更稀缺的资源。 互联网上"容易获取的高质量文本"正在被各大模型消耗殆尽，这也是合成数据、Agent 交互数据地位持续上升的根本原因。

2.5 数据配比（Data Mixing）

常见做法：分阶段配比 （LLaMA-3 的 annealing 阶段会提高书籍/代码/数学数据比例）、配比搜索 （DoReMi 等方法先在小模型上搜索最优配比再应用到大模型）、课程学习（由易到难组织数据顺序）。

---

三、Tokenizer：模型如何理解世界

大模型不直接处理文字，而是处理 Token。

3.1 BPE 核心思想

从字符级别开始，不断合并出现频率最高的相邻符号对，逐步构建词表：

核心逻辑一段代码即可说明：

from collections import Counter

def get_pair_freqs(word_freqs: dict) -> Counter:
    pairs = Counter()
    for word, freq in word_freqs.items():
        for i in range(len(word) - 1):
            pairs[(word[i], word[i + 1])] += freq
    return pairs
# 每轮取频率最高的相邻符号对合并为一个新token，循环直到词表达到目标大小

GPT 系列使用的 Byte-level BPE 直接在字节层面操作，天然覆盖所有 Unicode 字符，不存在未登录词问题。SentencePiece（LLaMA、Qwen 采用）则是语言无关的实现，把空格也当作普通字符处理，对中文、日文等无空格语言更友好。

一个真实的分词效果直观感受一下------Tokenizer 切出来的从来不是"字"或"整词"，而是一种介于两者之间的子词单元：

"ChatGPT"
    ↓
["Chat", "G", "PT"]

"今天我们学习Transformer"
    ↓
["今天", "我们", "学习", "Transform", "er"]

可以看到，高频完整词（"今天"）会被当作一个 Token，而低频或复合词（"Transformer"）则会被拆成多个子词片段。这正是 BPE"按频率合并"这套机制的直接体现。

3.2 词表设计与 Token 效率

模型	词表大小	说明
GPT-2	~50K
LLaMA-1/2	32K
LLaMA-3	128K	大幅扩容，提升多语言/代码效率
Qwen2.5	~150K	专门优化中文压缩率

词表越大，同样文本的 Token 序列越短，推理更省算力，但 Embedding 层参数和显存占用也随之增大------这是一个需要权衡的超参数。Token 效率通常用"每个 Token 平均代表多少字符"衡量，效率越高意味着同等上下文窗口能装下更多实际内容。

这里可以直观感受一下为什么中文模型格外需要大词表。英文以空格自然分词，"Artificial intelligence" 用 BPE 大概率能压缩成 2 个 Token；而中文没有天然的词边界，如果词表偏小，"人工智能正在改变世界" 可能被拆成"人/工/智/能/正/在..."这样接近逐字的粒度，Token 数量会显著膨胀。中文、多语言模型扩大词表，本质是在降低 tokenization loss（分词损失），而不是简单地增加参数量------同样一句话用更少的 Token 表达，模型能在同样的上下文窗口里"看到"更多信息，训练和推理效率也随之提升。

3.3 Embedding：Token 如何变成向量

这是整条链路里经常被忽略、但至关重要的一步。Tokenizer 只是把文本切成了一串整数编号（Token ID） ，Transformer 并不能直接处理整数------它需要的是向量。这中间还差一步：

Embedding 本质上是一张巨大的查找表（矩阵）：词表里每一个 Token ID，都对应矩阵里的一行，这一行就是这个 Token 的向量表示（初始随机，训练中不断被更新）。查到向量后，还会叠加位置编码（如 RoPE），让模型知道每个 Token 在序列中的位置。

Transformer 从来没有真正处理过"文字"或"Token"，它处理的自始至终都是向量（Embedding）。 后面所有的 Attention、FFN 计算，都是在向量空间里进行的矩阵运算。

---

四、模型架构：Transformer 如何产生智能

4.1 整体结构（Decoder-only）

4.2 Attention

$Attention(Q,K,V)=softmax\; (\; QKT\; dk\; )\; V\backslash text\{Attention\}(Q,K,V)=\backslash text\{softmax\}\backslash left(\backslash frac\{QK^T\}\{\backslash sqrt\{d\_k\}\}\backslash right)V$ Attention(Q,K,V)=softmax(dk QKT)V

Decoder-only 用 causal mask 保证每个位置只能看到自己及之前的 token，这是自回归生成的基础。

这里防止大家生疏l了或者不太理解这个公式 ，下面加个表格 ， 本来想加个例子，但是本文已经够长了 例子大家自行脑补吧！！

参数	含义	可以理解为
Q（Query）	查询向量	我现在想找什么信息？
K（Key）	键向量	我能够提供什么信息？
V（Value）	值向量	真正要传递的内容
QKᵀ	Query 与 Key 的相似度	当前 Token 与其它 Token 的相关程度
√dₖ	缩放因子（Head Dimension）	防止点积过大导致 Softmax 饱和，保持训练稳定
Softmax	归一化	将相关性转换为权重，所有权重之和为 1
V	加权求和	根据注意力权重融合所有 Token 的信息

4.3 RoPE / RMSNorm / SwiGLU（原理速览）

模块	解决的问题	核心思路
RoPE	位置编码需要具备相对位置感知能力，还要能外推到更长序列	对 Q、K 向量按位置施加旋转变换，两向量点积后旋转角自然抵消为相对位置差
RMSNorm	LayerNorm 均值中心化计算量大	去掉均值步骤，只做均方根缩放归一化
SwiGLU	传统 ReLU/GELU 激活表达力有限	引入门控机制，用 SiLU(xW1) 逐元素乘 xW2 动态控制信息流

以 RMSNorm 为例给出最小实现（其余两个模块思路类似，不再逐一展开完整代码）：

class RMSNorm(nn.Module):
    def __init__(self, dim, eps=1e-6):
        super().__init__()
        self.eps = eps
        self.weight = nn.Parameter(torch.ones(dim))

    def forward(self, x):
        rms = x.pow(2).mean(-1, keepdim=True).add(self.eps).sqrt()
        return x / rms * self.weight   # 只做缩放，不做均值中心化，计算更快、更稳定

LLaMA、Qwen、Mistral 等主流模型已全面采用 RoPE + RMSNorm + SwiGLU 这套组合。

4.4 GQA/MQA：压缩推理时的 KV Cache

标准 MHA 中 Q、K、V 头数相同，推理时 KV Cache 显存开销很大。

MQA 显存最省但效果略有损失，GQA 是折中方案------LLaMA-2/3、Qwen2.5 均采用 GQA。

4.5 MoE：稀疏激活，扩大参数量但不等比例扩大算力

模型总参数量可以很大（Mixtral、Qwen2.5-MoE、DeepSeek-MoE），但每个 token 只激活其中一小部分专家（如 Top-2），核心挑战是负载均衡 和专家并行的通信开销。

4.6 GPT-4 之后的另一条主线：长上下文优化

架构演进除了 GQA、MoE 这些"扩大规模/提升效率"的方向，还有一条同样重要的主线：如何支撑更长的上下文窗口（128K、256K，乃至 1M token）。这不是单一技术，而是一组组合拳：

Attention 效率优化（如 FlashAttention 减少显存读写）
    +
KV Cache 压缩（GQA/MQA/MLA）
    +
RoPE Scaling（让训练时较短的位置编码外推到更长序列）
    +
Sliding Window Attention（滑动窗口，限制每个token的有效感受野）
    +
Context Parallel（把超长序列切分到多张GPU并行处理）

这条主线和前面 GQA/MoE 是互补关系------GQA/MoE 解决"参数规模与推理成本"的平衡，长上下文优化解决"能处理多长的输入"，两者共同决定了一个模型的实际可用性上限。

---

五、训练：让模型学会预测下一个 Token

5.1 Next Token Prediction

用一个更细的例子看清楚模型每一步到底"看到"什么、"预测"什么：

第1步  模型看到："今天 天气 很"          → 预测下一个token："好"
第2步  模型看到："今天 天气 很 好"        → 预测下一个token："。"

也就是说，训练数据里的每一句话，都会被拆成很多个"用前面的词预测下一个词"的小样本，模型永远只被要求做一件事：给定已经看到的内容，猜下一个 Token 最可能是什么。

def compute_ntp_loss(logits, labels):
    # 错位对齐：用第i个位置预测第i+1个位置
    shift_logits = logits[:, :-1, :].contiguous()
    shift_labels = labels[:, 1:].contiguous()
    return F.cross_entropy(
        shift_logits.view(-1, shift_logits.size(-1)),
        shift_labels.view(-1), ignore_index=-100,
    )

这个看似简单的目标，配合海量数据和参数规模，涌现出了理解、推理、生成等复杂能力------但"为什么要做得这么大"，需要 Scaling Law 来回答；而"猜错了之后模型怎么变聪明"，需要下一节的反向传播来回答。

5.2 反向传播与 AdamW：Loss 是如何变成参数更新的

很多人知道模型在"训练"，但不知道"训练"两个字背后到底发生了什么。答案很朴素：训练就是不断修改参数，让下一次预测更准确。

具体来说：Loss 衡量的是"模型预测"和"真实答案"之间的差距；反向传播（Backpropagation）根据链式法则，把这个差距逐层往回传，算出每一个参数 该往哪个方向、调整多大幅度才能让 Loss 变小（也就是梯度，Gradient）；AdamW 则是当前大模型训练最主流的优化器，它在原始梯度下降的基础上，为每个参数自适应地调整更新步长，让训练更稳定、收敛更快。这一整套流程执行一次，700 亿个参数就都被微调了一次------而这个循环，会在数万亿个 Token 上重复执行无数次。

参数本身并不"保存知识"，它只是神经网络中数百亿条连接的权重。所谓训练，就是不断修改这些权重，让模型越来越擅长预测下一个 Token------理解、推理这些"智能"表现，是这个过程的涌现结果，而不是被直接编码进某个参数里的。

5.3 Scaling Law：大模型为什么越来越大？

GPT-3 最重要的贡献之一，就是系统性验证了一个规律：

模型性能 ≈ f(参数规模, 数据规模, 训练计算量)

更准确地说，OpenAI 的 Scaling Law 论文发现，Loss 会随着训练计算量（Compute）呈幂律（Power Law）下降，且在观测范围内没有出现明显的平台期：

也就是"投入的算力越多，Loss 越低，而且这条曲线相当平滑、可预测"------这正是过去几年整个行业敢于疯狂堆 GPU、投入巨额算力训练更大模型的信心来源：因为收益是可预期的，不是赌博。

但 Chinchilla（DeepMind，2022） 提出了一个关键修正：不是参数越大越好，而要看参数和数据是否匹配。举例：

在同样的训练算力预算下，一个"参数更小但吃的数据更多"的模型，往往比一个"参数更大但训练不充分"的模型效果更好。这也是为什么 LLaMA 系列刻意选择"用远超 Chinchilla 最优点的数据量去训练相对较小的模型"------因为推理成本 也要纳入综合考量，不能只看训练阶段的最优解。现代大模型追求的是模型规模、数据规模、训练步数三者的动态平衡，而不是单纯堆参数。

5.4 混合精度、BF16 与梯度累积

BF16 与 FP32 指数位相同、尾数位更少，数值范围与 FP32 一致，不需要 FP16 那样的 Loss Scaling，是当前大模型训练的主流选择。当单卡显存不足以支撑目标 batch size 时，用梯度累积模拟大 batch：

loss = compute_ntp_loss(logits, labels) / accumulation_steps
loss.backward()               # 梯度自动累加到.grad，不会覆盖
if (step + 1) % accumulation_steps == 0:
    optimizer.step()
    optimizer.zero_grad()

5.5 把它们拼起来：一个完整的训练循环

把前面几节的碎片拼在一起，其实就是下面这不到 20 行代码------这几行代码，正是 GPT、LLaMA、Qwen、DeepSeek 每天都在执行的事情，只不过在数万亿个 Token 上重复了千万次：

model = model.cuda()
optimizer = torch.optim.AdamW(model.parameters(), lr=3e-4)

for batch in dataloader:
    optimizer.zero_grad()
    with torch.autocast(device_type="cuda", dtype=torch.bfloat16):
        logits = model(batch["input_ids"])              # 前向传播，预测下一个token
        loss = compute_ntp_loss(logits, batch["labels"])  # 与真实token对比算Loss
    loss.backward()      # 反向传播，算出每个参数的梯度
    optimizer.step()     # AdamW根据梯度更新参数

---

六、分布式训练：把模型拆到万张 GPU 上

回到第一节的体量测算------千亿参数模型必须靠并行策略拆分。

6.1 四种基础策略速览

策略	拆分对象	特点
Data Parallel	数据分片，每卡完整模型副本	简单，但模型必须能放进单卡显存
Tensor Parallel	单层内部的矩阵运算	通信频繁，一般只用于单机内高速互联（NVLink）的多卡
Pipeline Parallel	模型按层切分到不同GPU	需配合 micro-batch + 1F1B 调度减少"气泡"
ZeRO / FSDP	优化器状态/梯度/参数按卡切分	消除数据并行的冗余存储，Stage越高显存节省越多、通信开销也越大

6.2 真实案例：一个千亿模型训练集群长什么样

以公开信息中的 LLaMA-3 405B 为参照：

模型规模：405B 参数
训练集群：约 16000 × H100 GPU
并行策略：Tensor Parallel + Pipeline Parallel + Data Parallel + Context Parallel（四维并行）
卡间通信：机内 NVLink（高带宽）+ 跨机 InfiniBand
训练软件栈：PyTorch + 类Megatron-LM张量/流水线并行实现 + ZeRO/FSDP风格的显存优化

这就是为什么说：大模型本质上是算法问题 + 超级计算问题 + 分布式系统问题的叠加。模型结构设计（RoPE、GQA、MoE）解决的是"算法效率"，而并行策略解决的是"这套算法能不能在物理硬件上真正跑起来、跑得够快"------两者缺一不可。

---

七、后训练：Foundation Model 如何变成 ChatGPT/Qwen 这样的产品

预训练得到的 Foundation Model 只会"续写"，还不会"对话"和"服从指令"，需要经过后训练。这是很多人对大模型最大的误解之一，值得先直观对比一下：

预训练模型（Foundation Model）：

  输入："今天北京天气"
  输出："很好" / "晴朗" / "不错，适合出门"...
       （只是在预测"接下来最可能出现的词"，没有"回答问题"的意识）

Chat 模型（如 ChatGPT/Qwen-Chat）：

  输入："帮我写一个方案"
  输出：结构化、切题、有帮助、带安全边界的完整回答

中间差的，正是本节要讲的 SFT + Alignment（对齐）------预训练模型知道"语言长什么样"，后训练教会它"该怎么说话、该怎么帮人"。

• SFT（Supervised Fine-Tuning）：用高质量的"指令-回答"对，让模型学会遵循指令、按对话格式输出
• RLHF（人类反馈强化学习）：训练一个奖励模型（Reward Model）拟合人类偏好，再用强化学习（如 PPO）优化生成策略
• DPO（Direct Preference Optimization）：跳过显式奖励模型，直接用偏好数据对（更好回答 vs 更差回答）优化模型，训练流程更简洁，是近两年被广泛采用的替代方案
• Reasoning 强化：针对数学、代码等需要多步推理的任务，用强化学习进一步提升模型的思维链质量（DeepSeek-R1 是典型代表）

这一阶段大量依赖第二部分提到的合成数据------拒绝采样生成候选答案、教师模型生成推理链，都是后训练数据的重要来源。

---

八、案例分析

8.1 GPT 系列（OpenAI）

• GPT-2：验证 Decoder-only + 大规模网页数据 + Next Token Prediction 的可扩展性
• GPT-3：175B 参数，系统性验证 Scaling Law，提出 In-Context Learning
• GPT-4 及之后：更强调数据质量与配比、大规模 RLHF 后训练，推测采用 MoE 架构以扩大参数规模同时控制推理成本

8.2 LLaMA 系列（Meta）

• LLaMA-1/2：RoPE + RMSNorm + SwiGLU 标准组合，验证"用更多数据训练相对较小的模型"同样能取得优异效果
• LLaMA-2：引入 GQA，大幅降低推理时 KV Cache 显存占用
• LLaMA-3：词表扩至 128K，训练数据 15T+ token，最大规模达 405B，采用张量/流水线/数据/上下文并行组合训练

8.3 Qwen 系列（阿里）

• 自研 BPE Tokenizer，词表约 150K，专门优化中文与多语言压缩效率
• 同时提供稠密模型与 MoE 模型（如 Qwen2.5-MoE），覆盖从边缘端到云端
• 训练数据强调多阶段配比：早期偏重通用网页数据保证多样性，后期显著提高代码/数学/合成数据比例
• 后训练阶段大量使用 SFT + DPO 及拒绝采样生成的高质量合成数据

8.4 DeepSeek 系列：从"堆参数"到"优化效率"的新路线

DeepSeek 代表了一条与"传统扩大 Dense 模型"不同的路线，值得单独拿出来看：

• MoE（DeepSeek-V2/V3）：用稀疏激活扩大总参数量而不等比例增加推理算力
• MLA（Multi-head Latent Attention，多头潜在注意力） ：MLA 不是简单的"KV 头数压缩"，而是通过低秩潜变量（latent representation）压缩历史 Key/Value 的表示------不再保存完整的 K/V 张量，而是保存一个更小的压缩后潜变量，需要时再还原展开。这让 KV Cache 在长上下文场景下的显存占用大幅降低，同时比 GQA/MQA 更好地保留了接近 MHA 的表达能力
• FP8 训练：在 BF16 基础上进一步降低数值精度以提升训练吞吐，对数值稳定性提出更高要求
• DeepSeek-R1：通过强化学习专门强化推理能力，是"Reasoning 强化"路线的代表性工作

这条路线传递的信号是：大模型的竞争已经从单纯"堆参数规模"，转向"如何用更少的算力和显存获得同等甚至更强的能力"------效率本身正在成为核心竞争力。

---

九、回到起点：700 亿参数到底是怎么组成的？

文章开头，我们从"70B 需要多少显存"入手建立了体量感；现在整条链路都讲完了，可以回过头回答一个更本质的问题：这 700 亿参数，具体"住"在网络的哪些地方？

（以上数字为典型 70B 级 Dense 模型的经验量级示意，不同模型的具体配比会有差异）

也就是说，70B 从来不是一整块巨大的矩阵 ，而是把 Embedding 层、每一层的 Attention（Q/K/V/O 投影）、每一层的 FFN（SwiGLU 的三组矩阵）、Norm 层、以及最后的输出层（LM Head）这些成千上万个较小的矩阵 逐一累加起来的总和------其中 FFN 通常是参数占比最大的部分，因为它在每一层都包含了维度被显著放大再收缩回来的两三组大矩阵；Attention 次之；Embedding 和 LM Head 相对占比较小（尤其在层数很深的模型里）。

所谓 70B，并不是一个巨大的矩阵，而是整个神经网络中所有可训练参数------Embedding、每一层的 Attention、每一层的 FFN、Norm、输出层------加总在一起的总和。理解了这一点，也就理解了为什么架构设计（层数、隐藏维度、头数、FFN 扩展比）的每一个选择，都会直接决定"这 700 亿参数具体分布在哪里、发挥什么作用"。

---

总结

一句话概括：

数据决定模型能力的上限，架构决定能力利用的效率，而系统工程决定模型能否突破规模的边界。

GPT、LLaMA、Qwen、DeepSeek 的技术报告背后，真正的工作量分布往往是"数据与工程占大头，模型结构创新占相对较小的一部分"------理解了这一点，也就理解了为什么一个 70B 模型从立项第一天起，就注定是一场数据工程、算法设计与超级计算系统工程的协同作战。

如果读完本文之后，还想继续往前走一步，不妨亲自跑一遍一个真正的大模型训练项目。

不妨看看这个由我参与开发开源项目 Train LLM From Scratch ，它完整实现了从 Tokenizer、Transformer 到模型训练、文本生成的全过程，比较适合作为 Foundation Model 入门实践的一份参考。

ok 筒子们 今天就讲到这里，希望对你的大模型世界观增加一些新的认知，See ya！