模块 00 — AI 与大模型概述

一、AI 发展史：从符号主义到大模型

理解大模型，首先要理解 AI 的三次范式转移。范式转移（Paradigm Shift）指的是：整个领域看待问题、解决问题的方式发生了根本性的变化——不是小修小补，而是「换了一套打法」。

三次范式转移的核心区别

二、什么是"大"模型？——三个维度

大模型的"大"不只是参数量，而是三个维度的同步放大。在解释之前，先快速建立两个最基础的概念：参数和token，因为接下来的所有讨论都离不开它们。

现在来看"大"的三个维度。注意表格中传统 ML 的训练数据只有 KB-MB（几 KB 到几 MB），而大模型要 TB-PB（万亿 Token），差距是天文数字：

三、什么是 Token？——模型读字的「最小颗粒」

前面提到大模型训练数据是「万亿 Token」，但到底什么是 token？为什么不用「字」或「词」来计量？这一节专门讲清楚，因为 token 会贯穿你学习大模型的整个过程。

Token（词元）：大模型处理文本的最小单位。模型在读取或生成文字时，不是逐字、也不是逐词，而是把文本切成一段段「token」来处理。一个 token 可能是一个完整的词、一个词的一部分、一个汉字，甚至是标点符号。

具体例子：同一句话在不同模型里切成几个 token？

为什么 token 这么重要？

• 决定上下文窗口容量：模型标称「128K 上下文」指的是 128K 个 token，不是 128K 个字。同样 128K 窗口，Qwen 能放更多中文，LLaMA 放的中文少——因为同样的中文 LLaMA 占的 token 更多。
• 决定 API 计费：调用 OpenAI、Anthropic、DeepSeek 的 API，都是按 token 计费（输入 token + 输出 token 分别计价）。所以同样一段中文，用 LLaMA 系 API 比 Qwen 系更贵。
• 决定中文效率：这是国产模型的核心优势之一。Qwen 2.5、DeepSeek、GLM 都针对中文优化了 tokenizer，1 个汉字 ≈ 1-1.5 token；而 LLaMA 系列是 2-3 token。这意味着处理同样的中文语料，国产模型训练和推理都更省钱。
• 不同模型 tokenizer 不通用：LLaMA 用 SentencePiece，GPT 用 BPE，Qwen 用自己的 tiktoken 变体。用 A 模型的 tokenizer 处理 B 模型的输入会输出乱码——这就是后面踩坑指南会提到的「tokenizer 陷阱」。

四、什么是参数？——模型的「脑容量」

接下来讲 Scaling Laws（缩放定律）之前，必须先把「参数」这个概念讲透，因为 Scaling Laws 的核心就是研究「参数量翻倍，性能怎么变」。

参数（Parameter）：模型中可学习的权重数量，类似大脑中突触连接的数量。每一个参数都是一个可以调节的数值（一个小数），模型训练的过程就是不断调整这几十亿、几百亿个参数的值，让模型的输出越来越接近正确答案。

用类比理解参数

• 参数 = 大脑中的突触连接：人脑约有 100 万亿个突触连接，GPT-3 有 1750 亿个参数。虽然参数比突触少，但已经足够「记住」海量语言模式。
• 参数 = 可调节的「旋钮」：1B（10 亿）参数 = 10 亿个旋钮。训练就是找到这 10 亿个旋钮各自该拧到什么角度，让模型整体表现最好。
• 参数 = 模型的「记忆容量」：参数越多，模型能记住的模式越多（语法、常识、专业知识、推理套路……），但也更容易过拟合（Overfitting）——就是把训练数据背得太死，反而对新数据反应差。过拟合就像一个学生把历年真题背得滚瓜烂熟，但遇到新题型就懵了。

参数量的规模感

参数量到底有多大？给几个参照物：

五、参数量演进时间线

了解了「参数」和「token」的含义，现在可以看懂下面这张参数量演进表了。注意「关键突破」一栏里的术语，我都在首次出现时给出白话定义：

关于 MoE 和密集模型：2024年后，MoE（Mixture of Experts，混合专家）成为主流——它把模型拆成多个「专家网络」，每次推理只调用最相关的几个专家，总参数大但激活参数小，推理成本大幅降低。与之相对的是密集模型（Dense Model）：每次推理使用全部参数的模型（对比 MoE 只用一部分）。DeepSeek V3 总参数671B但每次推理只激活37B，性能媲美70B密集模型但推理速度快数倍。

六、主流大模型对比（2025-2026）

Benchmark 说明（先看官方定义，再看白话版）：

• MMLU：57学科多选题，考察知识广度
• HumanEval：164道Python编程题，考察代码生成
• GSM8K：8500道小学数学应用题，考察基础推理
• MATH：12500道竞赛数学题，考察高级推理

🎯 白话版（这才是你应该记住的）：

• MMLU → 考 57 个学科的选择题，看模型知识面广不广。就像一场「百科知识竞赛」，从历史、法律、医学到物理都考，考的是「知道多少」
• HumanEval → 让模型写 164 道 Python 题，看代码能不能跑通。就像一场「编程上机考」，考的是「写出来的代码能不能用」，不是写得漂不漂亮
• GSM8K → 考小学数学应用题，看模型会不会推理。比如「小明有 5 个苹果，吃了 2 个，又买了 3 个，现在有几个？」——考的是「能不能一步步算对」
• MATH → 考高中竞赛数学题，看模型推理能力有多强。题目涉及代数、几何、数论，难度远超 GSM8K，是区分顶尖模型的「拉分项」

七、Scaling Laws——为什么"大"有用

2020年 OpenAI 发表的 Scaling Laws（缩放定律，Kaplan et al.）揭示了一个核心规律：模型性能与参数量(N)、数据量(D)、算力(C)呈幂律关系。这条定律是大模型时代最重要的发现，值得花时间彻底理解。

第一步：先搞懂「Loss」是什么

在讲公式之前，必须先理解 Loss（损失）这个概念，因为 Scaling Laws 衡量的就是 Loss 怎么变化。

Loss（损失）：模型预测与正确答案的差距，Loss 越小说明模型越准。具体来说，模型每预测下一个 token 时会给出一个概率分布（比如「下一个词是"猫"的概率 0.7，是"狗"的概率 0.2，是"鱼"的概率 0.1」），如果正确答案真的是"猫"，Loss 就比较低；如果正确答案是"鱼"，Loss 就比较高。训练的目标就是让 Loss 尽可能低。

用生活类比：Loss 就像考试扣分。模型预测对了，Loss 接近 0（没扣分）；预测错了，Loss 很高（扣很多分）。整个训练过程就是不断调整参数，让 Loss 持续下降——就像学生不断做题订正，让扣分越来越少。Loss 从 4.0 降到 3.0，听起来降得不多，但对应到「考试得分」上可能是从 30 分涨到 80 分的质变。

第二步：读懂公式

现在可以看公式了。核心公式（简化版）：

别被符号吓到，逐个翻译成大白话：

• L = Loss（损失），就是上面说的「模型犯错程度」，越低越好
• N = 参数量（N 来自 "Number of parameters"）。N 越大，L 越小
• D = 数据量（D 来自 "Data"），单位是 token。D 越大，L 越小
• C = 算力（C 来自 "Compute"），单位是 FLOP（浮点运算次数）。C 越大，L 越小
• Nc / Dc / Cc = 三个常数（不用管怎么来的，是研究者从实验数据拟合出来的）。它们的作用是让公式能对齐到具体的数值范围
• α = 衰减速度（一个很小的指数）。α 越大，说明「投入产出比」越高——但这里 α 都很小（0.05-0.095），意味着收益是递减的：参数翻倍，Loss 不会减半，只会减少一点点

用最直白的一句话总结这个公式：参数量每翻 10 倍，Loss 大约降低 15%。

第三步：走个数字例子

假设当前参数量 N₁ = 10B 时 Loss = 4.0。如果把参数量翻 10 倍到 N₂ = 100B，按公式：

参数量翻了10倍，Loss 从 4.0 降到 3.30——看起来降得不多，但在对数坐标上这是稳定线性下降，对应到实际能力上是质的飞跃（从「胡言乱语」到「能写代码」）。这就是为什么 Scaling Laws 让整个行业疯狂：虽然每次投入 10 倍只换来 15% 的 Loss 下降，但这 15% 在能力曲线上可能恰好跨过了「涌现」的门槛。

第四步：Chinchilla 修正——参数和数据要同步放大

2022年 DeepMind 的 Chinchilla 论文修正了这一结论：最优训练需要参数和数据同步放大，比例约为 20 tokens/参数。即一个 70B 模型最优训练需要 ~1.4T tokens。换句话说，光堆参数不堆数据是不够的——每增加 1 个参数，要配 20 个 token 的训练数据才「划算」。

关键洞察：LLaMA 系列故意"过训练"（用更多数据训练更小的模型），牺牲训练成本换推理成本降低——因为推理是持续开销，训练是一次性的。

八、大模型能力边界

✅ 大模型擅长的

• 文本生成与改写：摘要、翻译、风格转换、续写
• 代码生成：Python/JS/SQL 等主流语言，HumanEval >80%
• 知识问答：训练数据覆盖的领域，准确率高
• 结构化提取：从非结构化文本提取 JSON/表格
• 创意写作：营销文案、故事、诗歌
• 基础推理：GSM8K 数学题 >90%，但复杂多步推理仍不可靠

❌ 大模型不擅长的

• 精确计算：大数乘除、浮点运算经常出错（本质是token预测不是计算器）
• 实时信息：训练数据截止后的信息不知道（需RAG）
• 长期记忆：上下文窗口内能记住，超出就"遗忘"
• 可验证的正确性：生成内容可能"看起来对但实际错"（幻觉）
• 空间/物理推理：理解3D空间关系、物理因果关系较弱
• 严格执行规则："必须输出JSON"偶尔会失败，需格式约束

九、训练成本深度分析

大模型训练成本由三部分组成：

真实训练成本案例

DeepSeek V3 为什么便宜？下面每一项技术名词都给出白话解释：

• MoE架构：每次只激活37B参数，训练时通信开销小（前面讲过，像医院按需挂号）
• FP8 混合精度训练：用8位浮点数（而非32位）存储和计算，省一半显存，精度损失极小。类比：原来用 32 位精度记小数点（比如 3.14159265），现在用 8 位（比如 3.14），省一半存储空间，但绝大部分场景够用了
• DualPipe 流水线并行：「双向流水线」，让GPU边算边传数据，不闲着等通信。类比：工厂流水线上，工人不用等上一道工序把全部零件送来才开始，而是来一批做一批，同时下一批已经在路上
• H800而非H100：中国禁令下用H800（H100的降速版），单价更低
• 极致的工程优化：无张量并行（TP=1），减少AllReduce通信：
  • 张量并行 (Tensor Parallelism)：把一个大的矩阵运算拆到多张GPU上同时算。DeepSeek 故意不用它（TP=1），因为张量并行需要 GPU 间频繁同步
  • AllReduce：多GPU同步梯度的通信操作，是分布式训练的主要通信开销。不用张量并行 = AllReduce 通信量大幅减少 = GPU 花更多时间算、更少时间等

十、动手代码：加载和使用大模型

下面两段代码演示如何加载和使用开源大模型。每行关键参数都加了详细注释，解释「这是什么、为什么要这样设」。

# 方法1：使用 HuggingFace transformers 加载开源模型
# transformers 是 HuggingFace 出品的模型加载/推理库，是最基础的入门工具
from transformers import AutoModelForCausalLM, AutoTokenizer

# 指定要加载的模型名（HuggingFace Hub 上的仓库 ID）
# 这里用 DeepSeek 的 7B 对话模型，适合单卡 16GB 显存运行
model_name = "deepseek-ai/deepseek-llm-7b-chat"

# 加载 tokenizer：tokenizer 负责 把文本切成 token（数字ID）
# trust_remote_code=True 表示允许执行模型仓库里的自定义代码（DeepSeek/Qwen 等国产模型需要）
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)

# 加载模型本体（即那几十亿个参数）
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",          # 自动选择精度：模型仓库存什么精度就用什么（通常是 FP16/BF16）
                                  # FP16 = 16位浮点数，比默认的 32位省一半显存，精度足够
    device_map="auto",            # 自动把模型不同层分配到不同 GPU 上（多卡时用）
                                  # 单卡时会全部放到一张卡上
    trust_remote_code=True        # 同上，允许执行自定义代码
)

# 构造对话输入：用 chat 格式（role=user 表示用户提问）
messages = [{"role": "user", "content": "解释什么是Transformer架构"}]

# 用 tokenizer 把对话转成模型能理解的数字 ID 序列
# return_tensors="pt" 表示返回 PyTorch 张量格式
# .to(model.device) 表示把数据搬到模型所在的 GPU 上
input_ids = tokenizer.apply_chat_template(messages, return_tensors="pt").to(model.device)

# 调用 model.generate 生成回答
outputs = model.generate(
    input_ids,
    max_new_tokens=512,          # 最多生成 512 个新 token（不是 512 个字！）
                                  # 512 token 大约能写 400-600 个汉字，够解释一个概念了
    temperature=0.7,             # 温度：控制生成的随机性
                                  # temperature=0 → 永远选概率最高的词（确定性，但枯燥、重复）
                                  # temperature=1  → 完全按概率分布采样（随机，有创意但可能跑偏）
                                  # temperature=0.7 → 折中：有一定随机性但不太离谱（对话常用值）
    top_p=0.9,                   # 核采样（Nucleus Sampling）：只从「累计概率前 90%」的词里采样
                                  # 作用：屏蔽那些概率极低的离谱词（比如问"今天天气"时排除"原子弹"）
                                  # top_p=0.9 表示把候选词按概率从高到低排，累加到 90% 就停，只在这批里选
    do_sample=True               # 开启采样模式（配合 temperature/top_p 使用）
                                  # 如果 do_sample=False，则忽略 temperature/top_p，永远贪心选最高概率词
)

# 把模型输出的数字 ID 序列解码回人类可读的文字
# outputs[0] 是第一组生成结果，[len(input_ids[0]):] 表示只取「新生成」的部分（去掉输入部分）
# skip_special_tokens=True 表示去掉模型内部的特殊标记（如 <|endoftext|> 结束符）
response = tokenizer.decode(outputs[0][len(input_ids[0]):], skip_special_tokens=True)
print(response)

# ---- 输出示例 ----
# Transformer是一种基于自注意力机制的神经网络架构...
# 它由编码器和解码器组成，核心思想是通过注意力机制...

# 方法2：使用 vLLM 高性能推理（生产环境推荐）
# vLLM 是一个高性能推理引擎，比 HuggingFace 快 ~100 倍
# 适合需要处理大量并发请求的生产场景（如客服、API 服务）
from vllm import LLM, SamplingParams

# 初始化 vLLM 引擎（会自动加载模型并优化显存布局）
llm = LLM(
    model="deepseek-ai/deepseek-llm-7b-chat",
    tensor_parallel_size=1,          # 张量并行大小 = 使用的 GPU 数量
                                      # tensor_parallel_size=1 表示单卡运行
                                      # 多卡时设为卡数（如 2、4），vLLM 会自动切分模型
    max_model_len=4096,              # 模型支持的最大上下文长度（单位：token）
                                      # 设太小会截断长输入，设太大会浪费显存（预分配 KV Cache）
                                      # 4096 对大多数对话场景够用
    gpu_memory_utilization=0.9,      # GPU 显存使用率上限
                                      # 0.9 = 允许 vLLM 最多占用 90% 显存
                                      # 留 10% 给系统和其它进程，避免 OOM（显存溢出）
    trust_remote_code=True           # 同上，允许执行自定义代码
)

# 设置采样参数（对应 HuggingFace 的 temperature/top_p/max_new_tokens）
sampling_params = SamplingParams(
    temperature=0.7,                 # 同上，控制随机性
    top_p=0.9,                       # 同上，核采样
    max_tokens=512                   # 最多生成 512 个 token（vLLM 里叫 max_tokens，HF 里叫 max_new_tokens）
)

# vLLM 支持批量推理：一次传入多个 prompt，内部用 Continuous Batching 高效调度
prompts = ["解释什么是Transformer架构", "写一个快速排序的Python实现"]
outputs = llm.generate(prompts, sampling_params)

# 遍历输出结果
for output in outputs:
    print(output.outputs[0].text)    # 每个输出对象的 outputs[0].text 就是生成的文本
    print("---")

# vLLM vs HuggingFace 性能对比（7B模型, A10 GPU）:
# HuggingFace generate:  ~15 tokens/s        （一对一服务，慢但简单）
# vLLM generate:         ~2000+ tokens/s      （高并发流水线，快 100 倍以上）
# 速度差异主要来自两个技术：PagedAttention + Continuous Batching

十一、⚠️ 踩坑指南

十二、决策框架：如何选择大模型

需求是什么？
├── 通用对话/问答
│   ├── 追求最强能力 → GPT-4o / Claude 3.5 Sonnet (API)
│   ├── 追求性价比 → DeepSeek V3 (API, ~1/10 GPT-4 价格)
│   └── 需要本地部署 → LLaMA 3.1 8B / Qwen 2.5 7B (单卡)
├── 代码生成
│   ├── 最强 → Claude 3.5 Sonnet (HumanEval 92%)
│   ├── 开源 → DeepSeek-Coder V2 / Qwen 2.5 Coder
│   └── 本地 → CodeLlama 7B/13B
├── 中文场景
│   ├── 最强中文 → Qwen 2.5 / GLM-4 / DeepSeek
│   └── 英文为主 → LLaMA / GPT / Claude
├── 推理密集（数学/逻辑）
│   ├── 最强 → DeepSeek R1 / OpenAI o3
│   └── 开源 → DeepSeek R1 蒸馏版 (1.5B-70B)
├── 长上下文 (>128K)
│   ├── 最长 → Gemini 1.5 Pro (1M+)
│   └── 开源 → Yarn-LLaMA / Qwen 2.5 (256K)
└── 多模态（图+文）
    ├── 最强 → GPT-4o / Gemini 1.5 Pro
    └── 开源 → LLaVA / Qwen-VL