第 4 章 LLM模型规模MoE

第 4 章模型大小与规模

学习目标

说清参数量、层数、宽度、上下文窗口这些「规模」维度的含义与关系；
理解稠密模型 vs MoE 的本质区别：总参数量 vs 激活参数量；
掌握 FLOPs、模型显存、KV Cache、优化器状态的估算公式——贯穿全书的「算力账」；
理解 Scaling Law 与 Chinchilla 规律，知道「规模收益的边际递减」；
理解小模型为什么有价值：蒸馏、量化、端侧、低延迟。

4.1 规模的维度：参数量、层数、宽度、深度、词表、上下文

「模型多大」不是一个数，而是一组互相牵制的维度：

维度	含义	对资源的影响
参数量（Parameters）	模型所有可学习参数总数	模型存储、训练显存、推理权重显存
层数（Layers）	Transformer 块的数量（深度）	训练深度、串行延迟
宽度（Width）	隐藏维度 $d_{\text{model}}$	单层计算量、每层参数
词表大小（Vocab）	token 种类数	Embedding 层参数
上下文窗口（Context）	单次处理的最大 token 数	KV Cache 显存、注意力计算量
头数/头维度	注意力结构	注意力参数与计算

它们之间的关系不是独立的：经验上，深度与宽度要按一定比例增长才划算（比如宽度 4096 配 32 层），盲目加宽或加深都会浪费。这就是为什么「7B」「70B」这种参数量成了约定俗成的「型号」，背后是一整套配套的超参数。

# 估算一个 Decoder-only Transformer 的参数（Llama 风格，忽略 RMSNorm 与词表共享细节）
def count_params(hidden, layers, vocab):
    # 每层：注意力(QKV+O) + FFN(gate+up+down)，隐藏×隐藏占大头
    per_layer = 12 * hidden * hidden
    return layers * per_layer + vocab * hidden  # + embedding

print(count_params(4096, 32, 152064))  # ≈ 7B（Llama 2-7B 量级）

4.2 稠密模型 vs 稀疏模型 vs MoE

稠密模型（Dense）：每个 token 的每个 token 都要经过所有参数。Llama 系、GPT 系传统上是稠密的。

MoE（Mixture of Experts，混合专家）：把 FFN 替换成多个「专家」FFN，每个 token 由路由器（Router）选择激活其中少数几个专家（如 top-2）。于是出现两个不同的「规模」概念：

总参数量：所有专家参数之和——模型文件大小、存储、加载成本由它决定；
激活参数量（Active Parameters）：每个 token 实际参与的参数量——计算量、推理延迟由它决定。

模型	总参数量	激活参数量	说明
Llama 2-70B	70B	70B	稠密，全激活
Mixtral-8x7B	47B	~13B	8 专家取 2，激活约 1/4
DeepSeek-V3	671B	~37B	256 专家 + 细粒度专家，MoE 极致

MoE 的核心权衡：用「更大的模型文件」换「更低的每次计算量」。训练和推理时，模型权重需要完整加载进显存（存储压力大），但每个 token 只算一部分（计算省）。KV Cache 与激活无关，只与上下文和层结构有关——这是第 14 章推理优化的关键事实。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
graph LR
    A[Token] --> B[Router 路由器]
    B -->|top-2| C[专家 3]
    B -->|top-2| D[专家 7]
    B --> E[其余专家
不激活]
    C --> F[加权求和输出]
    D --> F

工程含义（第 3、4、13、14 章反复出现的主题）：

存储瓶颈：671B 的权重在 BF16 下约 1.3TB，单机装不下，必须多机张量/专家并行（第 10-11 章）；
计算红利：激活 37B，单 token 计算量约为稠密 70B 的一半多，推理吞吐更高；
通信代价：MoE 的 all-to-all 专家通信是分布式推理的新瓶颈（第 20 章）。

4.3 FLOPs、内存占用、显存、KV Cache、优化器状态

工程上必须会算「一笔账」：模型跑起来要多少计算量、多少显存。下面给出贯穿全书的估算公式。

4.3.1 FLOPs

设参数量为 $N$ ，训练 token 总数为 $D$ 。训练一个稠密模型，每个 token 的前向 + 反向计算量约为：

$C_{\text{token}} \approx 6N \quad (\text{forward } 2N + \text{backward } 4N)$

前向：约 $2N$ FLOPs/token；
反向：约 $4N$ FLOPs/token（反向约为前向两倍）；
训练总计算量： $C_{\text{train}} \approx 6ND$ ，其中 $D$ 为训练 token 总数；
推理（每 token）：约 $2N$ FLOPs/token（只前向）。

这是「6N 定律」（Kaplan et al., 2020; Hoffmann et al., 2022 中的常用近似）。用它可以快速判断：

训练 7B 模型 1 万亿 token： $6 \times 7\times10^9 \times 10^{12} \approx 4.2\times10^{22}$ FLOPs；
用 8 张 H100（每张约 $1\times10^{15}$ FP16 FLOPs/s，MFU 40%）：约需 $4.2\times10^{22} / (8 \times 4\times10^{14}) \approx 1.3\times10^7$ 秒 ≈ 150 天。这就是为什么大模型训练要「千卡万卡、数月成本」。

注：MoE 的 FLOPs 要用激活参数量而不是总参数量来算。

4.3.2 模型权重显存

权重（BF16，每个参数 2 字节）： $M_{\text{weights}} = 2N$ 字节；
7B 模型 ≈ 14GB；70B ≈ 140GB；671B（MoE）≈ 1.3TB。
推理通常只需权重 + KV Cache；训练还需要梯度与优化器状态（下一节）。

4.3.3 训练显存四件套

训练时 GPU 显存被四样东西占满：

占用项	估算	说明
模型权重	$2N$ 字节（BF16）	7B → 14GB
梯度	$2N$ 字节（BF16）	与权重同量级
优化器状态	$12N$ 字节（Adam）	Adam 存一阶矩+二阶矩+主权重(FP32)
激活值	依赖 batch×seq×hidden	可通过重计算/检查点削减

粗算：7B 全参训练（Adam + BF16）单卡 ≈ $14 + 14 + 84 \approx 112$ GB + 激活。这就是为什么 7B 全参训练单卡 80GB 放不下，必须用 ZeRO/FSDP 分片（第 8、11 章），也是 LoRA/QLoRA 存在的理由（把优化器状态从 $12N$ 降到几乎为零）。

4.3.4 KV Cache

第 3 章已给出公式，这里补全并给一个完整算例：

$M_{\text{KV}} = \underbrace{2}_{\text{K 和 V 两份}} \times L \times G \times d_h \times S \times B \times p$

其中 $L$ 为层数、 $G$ 为 KV 头数（GQA）、 $d_h$ 为头维度、 $S$ 为序列长度、 $B$ 为并发数（batch）、 $p$ 为每个数值的字节数（FP16/BF16 时 $p=2$ ，FP8 时 $p=1$ ）。第一个因子 $2$ 与 $p$ 含义不同：前者是每个 token 要同时缓存 K 和 V 两份矩阵，后者是精度决定的单元大小。KV 量化（第 13 章）降的就是 $p$ ，显存直接减半。

算例：32 层、GQA 8 头、头维 128、上下文 32K、并发 256：

$M_{\text{KV}} = 2 \times 32 \times 8 \times 128 \times 32768 \times 256 \times 2\ \text{B} \approx 2.1\ \text{TB}$

比 7B 权重（14GB）大两个数量级。KV Cache 是 LLM 服务并发与长上下文的头号显存瓶颈，直接催生 PagedAttention、KV 量化、前缀缓存（第 14 章）。

4.3.5 存储、带宽、通信量与成本

存储：模型文件大小 = 权重字节数。大规模模型要放到对象存储/模型仓库（第 19 章）。
带宽：推理时每个 token 都要从 HBM 读一遍权重（memory-bound），这就是为什么「带宽越大、单 token 延迟越低」，也是量化（把权重从 2B 降到 1B/0.5B）能直接提速的机理（第 13 章）。
通信量：分布式训练中，梯度同步通信与参数量成正比，网络决定扩展效率（第 10-11 章）。
成本：训练成本 ≈ GPU 时数 × 单价；推理成本 ≈ 吞吐 × 单价。全部可换算成「每百万 token 多少钱」，这是 LLMOps 的核心度量（第 17、21 章）。

4.4 Scaling Law、Chinchilla 规律、规模收益与边际成本

4.4.1 Scaling Law（Kaplan et al., 2020）

模型性能与三个量呈幂律关系：参数量 $N$ 、数据量 $D$ 、计算量 $C$ 。给定算力预算，模型损失大致 $\mathcal{L} \propto C^{-\alpha}$ （注意这里的 $\mathcal{L}$ 是损失，与 KV Cache 公式里表示层数的 $L$ 不是同一个量）。早期结论是「算力一定时，优先把参数量做大、数据次之」——这催生了「越大越好」的信仰。

4.4.2 Chinchilla 规律（Hoffmann et al., 2022）

2022 年 DeepMind 的 Chinchilla 论文修正了结论：模型参数量与训练 token 数应按约 1:1 比例增长（每 1B 参数 ≈ 20B token，即「20 tokens per param」经验法则）。之前业界普遍「欠训练」（模型过大、数据不足），Chinchilla 提出「同样算力下，更小模型 + 更多数据更好」。

结论	要点	工程影响
Kaplan	算力固定时参数量优先	「越大越好」
Chinchilla	参数与数据按 1:1 扩展	数据质量/数量更受重视

4.4.3 规模收益与边际成本

规模化不是免费的。收益（能力提升）随规模呈对数增长——从 7B 到 70B，能力提升明显；从 70B 到 700B，提升变小。而成本随规模线性甚至超线性增长。这就是「边际成本递增、边际收益递减」：

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
graph LR
    subgraph 收益曲线
    A[7B] -->|大幅提升| B[70B]
    B -->|小幅提升| C[700B]
    end
    subgraph 成本曲线
    D[7B 单卡] -->|线性增长| E[70B 多机]
    E -->|非线性增长| F[700B 万卡集群]
    end

工程含义：规模决策不是「越大越好」，而是「在能力需求与成本约束下找平衡点」。很多业务用 7B 微调 + RAG 就能达到 70B 通用模型的效果，因为垂直数据与检索补足了通用能力的不足。这是第 2 章「模型大小 ≠ 能力大小」的量化依据。

4.5 小模型价值：蒸馏、量化、端侧、低延迟

大模型的规模化有收益也有成本，于是「小模型路线」应运而生。小模型的价值来自四个维度：

蒸馏（Distillation）：用大模型当教师，把能力「教给」小模型（第 13 章）。端侧小模型（Llama 3.2 1B/3B）几乎都来自大模型蒸馏或直接用其合成数据训练。
量化（Quantization）：把权重从 16bit 压到 4bit/8bit，7B 模型压缩到 4-5GB，普通消费级 GPU 甚至端侧可跑（第 13 章）。
端侧部署：隐私、离线、低延迟、低成本——手机、车机、浏览器上的 AI 只能用小模型（第 18 章）。
低延迟：单 token 延迟与激活参数量正相关，小模型在实时交互（语音助手、代码补全）上有压倒性优势。

小模型不是大模型的「缩水版」，而是「针对场景的专用化产物」：用蒸馏继承大模型的知识，用垂直数据微调补足领域能力，用量化换取部署弹性。它们的权衡是「通用性 vs 专用性、能力 vs 成本」——这是全书最反复出现的主题。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[旗舰大模型
通用能力强/成本高] -->|蒸馏/合成数据| B[垂直小模型
领域强/成本低]
    A -->|量化/剪枝| C[轻量模型
端侧可跑]
    B --> D[部署到高吞吐/实时场景]
    C --> D

本章要点回顾

规模的六个维度（参数、层、宽、词表、上下文、头）互相牵制，参数量只是表象。
MoE 区分总参数量与激活参数量：存储看总参数，计算看激活参数。
三笔账：训练 ≈ 6N×token FLOPs；训练显存 ≈ 权重+梯度+优化器(12N)+激活；KV Cache 是推理显存头号瓶颈。
显存账决定了：为什么必须 ZeRO/FSDP/LoRA（训练），为什么必须 PagedAttention/量化（推理）。
Scaling Law 说「越大越好」，Chinchilla 修正为「参数与数据 1:1」。
规模收益递减、成本递增：选型是在能力与成本间找平衡。
小模型 = 蒸馏 + 量化 + 垂直数据的产品化产物，不是大模型的廉价复制。

习题

用 6N 定律估算：用 512 张 H100（每张约 1e15 FLOPs/s，MFU 40%）训练 70B 模型 1 万亿 token 需要多久。
计算 Mixtral-8x7B 与 Llama 2-70B 在「存储」与「单 token 计算量」上的差异，解释为什么 MoE 能省算力。
一个 8B 模型（GQA 4 头、32 层、头维 128），要支持 128K 上下文、512 并发，KV Cache 需要多少显存？这决定你要几台 8×80GB 的机器？
查 DeepSeek-V3 的技术报告，复述它如何在 MoE 基础上做细粒度专家与共享专家，为什么能提升激活参数利用率。
为什么 7B 全参训练用单张 80GB 卡放不下？用 4.3.3 的账算一遍。

下一章预告

第 5 章从「模型本身」切换到「模型的整个生命周期与工程视角」：研究 vs 生产、模型卡、MLOps/LLMOps/ModelOps 的区别，以及为什么「训练完不是结束」。

第 4 章模型大小与规模

第 4 章模型大小与规模

4.1 规模的维度：参数量、层数、宽度、深度、词表、上下文

4.2 稠密模型 vs 稀疏模型 vs MoE

4.3 FLOPs、内存占用、显存、KV Cache、优化器状态

4.3.1 FLOPs

4.3.2 模型权重显存

4.3.3 训练显存四件套

4.3.4 KV Cache

4.3.5 存储、带宽、通信量与成本

4.4 Scaling Law、Chinchilla 规律、规模收益与边际成本

4.4.1 Scaling Law（Kaplan et al., 2020）

4.4.2 Chinchilla 规律（Hoffmann et al., 2022）

4.4.3 规模收益与边际成本

4.5 小模型价值：蒸馏、量化、端侧、低延迟

本章要点回顾

习题

延伸阅读

下一章预告

📑 大语言模型全生命周期工程：从 Transformer 到 LLMOps

第 4 章 模型大小与规模

第 4 章 模型大小与规模

4.1 规模的维度：参数量、层数、宽度、深度、词表、上下文

4.2 稠密模型 vs 稀疏模型 vs MoE

4.3 FLOPs、内存占用、显存、KV Cache、优化器状态

4.3.1 FLOPs

4.3.2 模型权重显存

4.3.3 训练显存四件套

4.3.4 KV Cache

4.3.5 存储、带宽、通信量与成本

4.4 Scaling Law、Chinchilla 规律、规模收益与边际成本

4.4.1 Scaling Law（Kaplan et al., 2020）

4.4.2 Chinchilla 规律（Hoffmann et al., 2022）

4.4.3 规模收益与边际成本

4.5 小模型价值：蒸馏、量化、端侧、低延迟

本章要点回顾

习题

延伸阅读

下一章预告

📑 大语言模型全生命周期工程：从 Transformer 到 LLMOps

第 4 章模型大小与规模

第 4 章模型大小与规模