1. 什么是 LLM
LLM（Large Language Model，大语言模型） 是一类基于 Transformer 架构、通过海量文本数据训练而成的深度学习模型。它通过学习文本中的统计规律和语义关系，具备了理解和生成自然语言的能力。
LLM 的核心能力：
- 文本生成：给定一段提示（Prompt），生成连贯的后续文本
- 语言理解：理解语义、情感、指代关系
- 推理能力：逻辑推理、数学计算、代码分析
- 多任务泛化：同一个模型可以翻译、总结、问答、写代码，无需针对每个任务单独训练
- 上下文学习（In-Context Learning）：通过 Prompt 中的示例学习新任务，无需微调
核心洞察
LLM 的本质是一个概率模型——给定前面的 Token 序列，预测下一个 Token 的概率分布。所有看似「智能」的行为，都是这个简单的自回归目标在大规模数据和参数下的涌现。
2. Transformer 架构
Transformer 是 LLM 的基础架构，由 Vaswani 等人在 2017 年的论文《Attention Is All You Need》中提出。它彻底取代了 RNN/LSTM，成为 NLP（以及后来的多模态）领域的主导架构。
2.1 自注意力机制（Self-Attention）
自注意力机制是 Transformer 的核心。它解决了 RNN 的根本问题：无法并行处理长序列，且长距离依赖容易丢失。
自注意力的计算过程：
- 每个 Token 生成三个向量：Query（Q）、Key（K）、Value（V），通过与权重矩阵相乘得到
- 计算每对 Token 之间的注意力分数：
Attention(Q, K, V) = softmax(QK^T / √d_k) V - 注意力分数决定了每个 Token 在表示当前位置时应该「关注」哪些其他 Token
直观理解：
- Query：「我在找什么信息？」
- Key：「我能提供什么信息？」
- Value：「我的实际内容是什么？」
- 注意力分数：Query 和 Key 的匹配程度，决定了 Value 的权重
例子
句子「猫坐在垫子上，因为它累了」中，当模型处理「它」这个词时，自注意力机制会计算「它」与每个词的注意力分数。「猫」的分数会很高，因为「它」最可能指代「猫」。这就是模型理解指代关系的方式。
2.2 多头注意力（Multi-Head Attention）
单个注意力头只能学习一种注意力模式。多头注意力通过并行运行多个注意力头，让模型同时关注不同的语义关系：
- 一个头可能关注语法关系（主谓宾）
- 另一个头可能关注语义相似性
- 另一个头可能关注位置邻近性
多头注意力的输出是所有头的拼接后经过线性变换的结果。
2.3 前馈网络与残差连接
Transformer 的每个层除了注意力模块，还包含：
- 前馈网络（Feed-Forward Network, FFN）：两层线性变换 + 激活函数（GELU）。注意力负责「信息聚合」，FFN 负责「信息处理」
- 残差连接（Residual Connection）：将输入直接加到输出上，缓解深层网络的梯度消失问题
- 层归一化（Layer Normalization）：稳定训练过程。现代 LLM 多使用 RMSNorm（去掉均值中心化，只做缩放）
2.4 Encoder-Decoder vs Decoder-Only
| 架构 | 代表模型 | 特点 | 适用场景 |
|---|---|---|---|
| Encoder-Decoder | T5、BART | 编码器理解输入，解码器生成输出 | 翻译、摘要 |
| Encoder-Only | BERT | 只做理解，不做生成 | 分类、NER、语义匹配 |
| Decoder-Only | GPT 系列、LLaMA、Claude | 自回归生成，统一架构 | 通用语言模型（当前主流） |
当前几乎所有主流 LLM（GPT-4、Claude、LLaMA、Gemini）都采用 Decoder-Only 架构。原因：
- 统一的训练目标（下一个 Token 预测）简单且可扩展
- 架构简单，工程实现更容易
- 经过海量数据训练后，Decoder-Only 模型同样能完成 Encoder-Decoder 的任务
- 自然支持自回归生成和上下文学习
3. 分词与词嵌入
3.1 Tokenizer
模型处理的是 Token，不是原始文本。Tokenizer 负责将文本切分为 Token 序列。
常见分词算法：
| 算法 | 原理 | 代表模型 |
|---|---|---|
| BPE（Byte Pair Encoding） | 从字符开始，迭代合并最频繁出现的相邻对 | GPT 系列、LLaMA |
| WordPiece | 类似 BPE，但基于似然而非频率选择合并 | BERT |
| SentencePiece | 语言无关的分词框架，支持 BPE 和 Unigram | T5、LLaMA |
| Byte-Level BPE | 在字节级别而非字符级别做 BPE，支持任意语言 | GPT-4、Claude |
分词的影响：
- 同一个句子在不同 Tokenizer 下的 Token 数量不同，直接影响上下文窗口的有效长度
- 中文在大多数 Tokenizer 下 Token 数量比英文多（因为训练数据以英文为主，中文字符没有充分合并）
- 代码的 Token 效率通常较高（因为 BPE 能很好地合并重复的代码模式）
3.2 词嵌入与位置编码
词嵌入（Embedding）：将每个 Token 映射为一个高维向量（通常 4096 维或更高）。语义相近的 Token 在向量空间中距离更近。
位置编码（Positional Encoding）：自注意力机制本身不包含位置信息（置换不变性），需要额外注入位置信息。
- 绝对位置编码：原始 Transformer 使用正弦/余弦函数生成固定的位置向量
- 旋转位置编码（RoPE）：通过旋转矩阵编码相对位置关系，是当前 LLM 的主流方案（LLaMA、GPT-NeoX、Qwen）
- ALiBi：在注意力分数上添加线性偏置，不需要额外的位置嵌入参数
4. 预训练
4.1 训练目标
LLM 的预训练目标是自回归语言建模（Autoregressive Language Modeling）：
- 给定前面的 Token 序列，预测下一个 Token
- 损失函数：交叉熵损失（Cross-Entropy Loss）
- 数学表达：最大化
P(x_t | x_1, x_2, ..., x_{t-1})
这个目标看似简单，但迫使模型学习：语法结构、语义关系、事实知识、推理模式、世界模型。所有涌现能力都来自这个目标函数。
4.2 数据工程
预训练数据的质量和多样性对模型能力至关重要。典型数据来源：
- 网页数据：Common Crawl（经过清洗过滤）、Wikipedia
- 书籍：BookCorpus、Gutenberg、书籍扫描数据
- 代码：GitHub 开源代码、StackOverflow
- 学术论文：arXiv、PubMed、Semantic Scholar
- 对话数据：论坛、Reddit、社交媒体
数据处理流程：
- 去重：精确去重（URL 级别）和模糊去重（SimHash、MinHash）
- 质量过滤：去除低质量内容（乱码、广告、自动生成文本）
- 安全过滤：去除 PII（个人身份信息）、有害内容
- 数据混合（Data Mixing）：按照一定比例混合不同来源的数据
注意
数据质量比数据数量更重要。经过精心清洗的小数据集训练出的模型，可能比用大量噪声数据训练的模型效果更好。这也是为什么很多团队不愿意公开数据配方——数据工程是核心竞争力。
4.3 缩放定律（Scaling Laws）
Kaplan et al.（2020）和 Chinchilla et al.（2022）的研究发现，模型性能与三个因素之间存在幂律关系：
- 模型参数量 N
- 训练数据量 D
- 计算量 C
核心结论：
- 增加任何一个因素都能提升性能，但存在收益递减
- 最优分配：模型参数和数据量应该等比例增长（Chinchilla 定律）
- 同等计算预算下，更小的模型 + 更多数据 > 更大的模型 + 更少数据
实践意义
Chinchilla 定律推动了「小模型 + 大数据」的趋势。LLaMA 系列就是典型代表——用较少的参数但更多的 Token 数量训练，效果媲美参数量更大的模型。这也使得开源模型更容易部署到消费级硬件上。
5. 对齐与微调
预训练模型虽然知识丰富，但并不「听话」。对齐（Alignment）的目标是让模型按照人类期望的方式使用这些知识。
5.1 指令微调（SFT）
Supervised Fine-Tuning（SFT） 是最基本的对齐方式：
- 准备高质量的「指令-回答」数据对
- 在预训练模型上继续训练，但只计算回答部分的损失
- 模型学会：收到指令 → 生成符合格式和期望的回答
SFT 数据的质量关键在于：
- 多样性：覆盖各种任务类型（问答、总结、翻译、代码、推理等）
- 准确性：回答必须正确，否则模型会学习错误知识
- 风格一致性：回答风格统一（详细程度、格式、语气）
5.2 RLHF
RLHF（Reinforcement Learning from Human Feedback） 通过人类偏好信号进一步优化模型：
- 收集偏好数据：对同一个问题，模型生成多个回答，人类标注哪个更好
- 训练奖励模型（Reward Model）：学习人类的偏好排序
- PPO 优化：用强化学习（PPO 算法）调整语言模型，使其生成的回答能得到更高的奖励分数
RLHF 解决的问题：有些回答虽然语法正确、信息准确，但人类就是不喜欢（太啰嗦、太机械、不安全等）。这些微妙的偏好很难用监督学习表达，但可以通过人类对比标注来学习。
5.3 DPO 与 RLHF 的替代方案
RLHF 的 PPO 阶段复杂且不稳定，近年出现了替代方案：
| 方法 | 原理 | 优势 |
|---|---|---|
| DPO（Direct Preference Optimization） | 直接从偏好数据优化策略，不需要单独训练奖励模型 | 实现简单、训练稳定 |
| RLAIF | 用 AI 替代人类做偏好标注 | 成本更低、可扩展 |
| KTO（Kahneman-Tversky Optimization） | 只需要「好/坏」二元标签，不需要对比对 | 数据要求更低 |
| GRPO（Group Relative Policy Optimization） | DeepSeek 提出，基于组内相对优势优化 | 在推理任务上效果突出 |
6. 推理与解码策略
6.1 自回归生成
LLM 的推理过程是逐个 Token 生成的：
- 将输入文本编码为 Token 序列
- 模型前向传播，得到下一个 Token 的概率分布
- 从概率分布中采样一个 Token
- 将新 Token 追加到序列中，重复步骤 2-3
- 直到生成结束标记（EOS）或达到最大长度
每生成一个 Token 都需要一次完整的模型前向传播，这就是为什么长文本生成比处理慢得多。
6.2 采样策略
| 策略 | 参数 | 效果 |
|---|---|---|
| Greedy | 无 | 每次选概率最高的 Token。输出确定但可能重复 |
| Temperature | 0.0-2.0 | 控制随机性。低温度趋近 Greedy，高温度更随机 |
| Top-K | K 值 | 只从概率最高的 K 个 Token 中采样 |
| Top-P（Nucleus） | P 值（0-1） | 从累积概率达到 P 的最小 Token 集合中采样 |
| Repetition Penalty | >1.0 | 降低已出现 Token 的概率，减少重复 |
推荐设置
创意写作：Temperature 0.7-0.9 + Top-P 0.9。代码生成：Temperature 0.0-0.2（确定性优先）。事实问答：Temperature 0.0-0.3。
6.3 KV Cache
自回归生成中，每一步都需要计算所有之前 Token 的 Key 和 Value。如果不做缓存，每次生成都要重新计算整个序列的注意力，极其低效。
KV Cache：缓存已经计算过的 Key 和 Value 向量，每步只需要计算新 Token 的 Q、K、V，然后与缓存拼接。
KV Cache 的挑战：
- 显存占用随序列长度线性增长，是长上下文推理的主要瓶颈
- 每个注意力头的每个层都需要独立缓存
- **GQA（Grouped Query Attention）**和 **MQA（Multi-Query Attention）**通过减少 KV 头的数量来减少缓存大小
7. 推理优化技术
7.1 量化
将模型权重从高精度（FP32/FP16）转换为低精度（INT8/INT4/FP8），减少显存占用和计算量。
| 量化方式 | 精度 | 显存节省 | 质量损失 |
|---|---|---|---|
| FP16 | 16-bit | 基准 | 几乎无 |
| INT8（W8A8） | 8-bit | ~50% | 极小 |
| INT4（GPTQ/AWQ） | 4-bit | ~75% | 轻微可接受 |
| FP8 | 8-bit | ~50% | 极小 |
常用量化工具：
- GPTQ：基于逐层量化的后训练量化方法
- AWQ（Activation-Aware Weight Quantization）：考虑激活值分布的量化方法，效果优于 GPTQ
- GGUF/GGML：llama.cpp 使用的量化格式，支持 CPU 推理
- bitsandbytes：HuggingFace 生态中的量化库
7.2 推理框架
| 框架 | 特点 | 适用场景 |
|---|---|---|
| vLLM | PagedAttention、连续批处理、高吞吐 | API 服务、高并发场景 |
| llama.cpp | C/C++ 实现、CPU/GPU 混合推理、GGUF 格式 | 本地部署、边缘设备 |
| TensorRT-LLM | NVIDIA 官方、极致 GPU 优化 | NVIDIA GPU 上的生产部署 |
| ollama | 一行命令启动、本地运行 | 个人使用、快速原型 |
| SGLang | 结构化生成、RadixAttention | Agent 应用、复杂 Prompt |
7.3 长上下文处理
将上下文窗口从 4K 扩展到 100K+ 需要解决几个问题：
- 位置编码外推：RoPE 的频率缩放（NTK-aware Scaling）、YaRN
- KV Cache 优化：StreamingLLM（保留注意力汇聚点）、H2O（Heavy Hitter Oracle）
- 注意力机制改进：Ring Attention（分布式长序列）、Flash Attention（IO 优化的精确注意力）
- 分层注意力：将长序列分块处理，不同层使用不同的注意力范围
8. 大模型生态
8.1 主流模型家族
| 模型 | 开发方 | 架构特点 |
|---|---|---|
| GPT-4 / GPT-4o | OpenAI | 多模态、MoE（疑似）、最强推理能力之一 |
| Claude 3.5 / Claude 4 | Anthropic | 长上下文（200K）、安全性、Agent 能力 |
| Gemini | Google DeepMind | 原生多模态、超长上下文（1M+） |
| LLaMA 3 | Meta | 开源、高质量、多种尺寸（8B-405B） |
| Mixtral | Mistral AI | MoE 架构、高效率 |
| DeepSeek | 深度求索 | 开源、MoE、推理模型（DeepSeek-R1） |
| Qwen | 阿里通义 | 开源、多模态、中文优化 |
8.2 开源 vs 闭源
| 维度 | 开源（LLaMA、Qwen、DeepSeek） | 闭源（GPT-4、Claude） |
|---|---|---|
| 成本 | 自行部署，GPU 成本可控 | 按 Token 计费 |
| 数据安全 | 数据不出本地 | 数据发送到第三方服务器 |
| 定制化 | 可微调、可修改架构 | 只能通过 Prompt 工程 |
| 性能 | 快速追赶，部分领域已持平 | 目前仍有优势（推理、长上下文） |
| 部署难度 | 需要 GPU 集群或量化到消费级硬件 | API 调用即可 |
9. 从 LLM 到 Agent
LLM 从「文本生成器」进化为「Agent」的关键在于赋予它使用工具和执行动作的能力。
Agent 的核心组件：
- LLM 核心：负责理解和推理
- 工具调用（Tool Use）：让模型能够调用外部工具（搜索、代码执行、API 调用）
- 记忆系统：短期记忆（上下文窗口）和长期记忆（向量数据库、文件系统）
- 规划能力：将复杂任务分解为子任务，制定执行计划
- 行动执行：通过代码、API、操作界面与环境交互
Agent 框架：
- LangChain / LangGraph：灵活的 Agent 编排框架
- CrewAI：多 Agent 协作框架
- AutoGPT / Open Interpreter：自主执行任务的 Agent
- Anthropic Claude Code：代码领域的 Agent，基于 Claude 模型
- OpenAI Assistants API：云端 Agent 服务
趋势
2024-2025 年 LLM 的发展方向已经从「更大的模型」转向「更强的 Agent 能力」。模型的推理能力（Reasoning）、工具使用能力（Tool Use）、多步骤规划能力（Planning）成为新的竞争焦点。DeepSeek-R1、Claude 的 extended thinking、OpenAI o1/o3 都体现了这一趋势。