最近总有人问我，LLM 到底该怎么学。市面上的资料要么是某个模型的讲解，要么是某篇论文的精读，看完总觉得隔着一层纱，形不成自己的体系。这篇文章是“深入学习 LLM”系列的第一篇，定位就是一个 Overview——先把整张地图铺开，告诉你哪些山头必须爬、哪些坑可以绕、哪些概念必须死磕，后续章节再逐个深入。
这篇文章适合谁？如果你已经会用某个大模型 API 做点小应用，但对模型内部原理还是一团浆糊；或者你是刚入门的研究生、工程师，想系统建立 LLM 的知识骨架，这篇文章就是给你准备的。我的目标很明确：读完你心里能画出一张图，知道 LLM 从数据到部署发生了什么，知道每个环节的核心问题是什么，也知道下一步该学什么。
1. 内容整体设计与思路拆解
1.1 我为什么先写 Overview
很多人学 LLM 最大的问题不是资料少，而是太碎了。今天刷到一篇讲注意力机制的，明天看到一段讲微调的，每块内容单独看都懂，串起来就乱。
先劝几句：LLM 本质上不是一个单一技术，而是一条完整的工业流水线。数据采集、Token 化、预训练、对齐、微调、量化、推理加速、评测、应用开发，每个环节都是独立的学问。任何一个环节出问题，整个系统的效果都会打折。所以学习的第一步不是钻细节，而是建立全局视图。
这也是我坚持先写 Overview 的原因。只有先知道全局，你才知道现在学的某个知识点在整个体系中的位置，也才知道该优先学什么。否则很容易陷入“什么都想学、什么都没学会”的困境。
1.2 LLM 知识全景：一条主线，两条侧链
我习惯把 LLM 知识体系画成一条主线加两条侧链。
- 主线是“训练与对齐”：数据准备 → 预训练 → 指令微调（SFT）→ 偏好对齐（RLHF / DPO）→ 评测迭代。这是模型能力的来源，也是理论最深、论文最密集的地带。
- 侧链一是“推理与部署”：训练好的模型如何低成本、低延迟地跑起来，涉及量化、蒸馏、KV Cache、批处理策略、推理框架，本质是工程问题。
- 侧链二是“应用与工程”：模型怎么接入业务，怎么解决幻觉、上下文管理、工具调用、多步推理，这里衍生出了 RAG、Agent、Function Calling 等方向。
这条主线加两条侧链，基本能把当前 LLM 领域 80% 的热门话题容纳进去。
1.3 学习顺序：从“用”到“拆”，再到“改”
我建议的学习路径是反过来的：先用起来，再拆开看，最后尝试修改。
很多初学者一上来就死磕数学推导，这是最容易劝退的路线。现代 LLM 的数学门槛确实存在，但绝大多数应用场景根本用不到手推反向传播。我更推荐分层递进的学习方式：
- 第一层是“用模型”：通过 API 或开源模型完成具体任务，感受能力边界。
- 第二层是“拆模型”：理解 Transformer 结构、训练流程、推理机制。
- 第三层是“改模型”：做 SFT、做量化、做部署优化，真正碰工程。
第一篇文章就带你走第一层到第二层的过渡，确定自己的知识基线，建立一个真实、不玄乎的 LLM 认知。
2. 核心概念拆解：先啃下五个硬骨头
2.1 Token：模型眼中的“字符”不是字符
学习 LLM 绕不开的第一个概念就是 Token。它不严谨但很好理解：Token 是模型处理文本的基本单位，可以是一个英文单词的一部分、一个完整单词、一个标点，也可以是连续几个汉字。
很多人第一次看 Tokenizer 输出会懵：“为什么这句话被切成了十几个 Token，长短不一？”这很正常。现代主流的 BPE、SentencePiece 这类算法，本质是统计词频后做出的“贪心切分”：高频组合合并成一个 Token，低频字拆得更碎。所以 Token 数量和字符数没有固定比例，英文大约 4 个字符约等于 1 个 Token，中文大约 1 到 1.5 个字约等于 1 个 Token。
理解 Token 有两个直接价值。一个是算成本：调用模型的计费、上下文长度的限制都按 Token 算，你优化 Prompt 的本质就是优化 Token 消耗。另一个是理解模型“看不到字”，它看到的全是 Token 序列，这直接影响了模型处理长文本、代码、多语言时的表现差异。
2.2 Embedding：每个 Token 都有一个“坐标”
Token 解决了“模型读什么”的问题，接下来就是“怎么读”。模型是数值计算系统，不可能直接拿字符串做运算，所以每个 Token 要被映射成一个向量。这个映射过程就叫 Embedding。
用生活化的方式理解：你可以把 Embedding 空间想象成一个多维坐标系，相似的词会落在相近的区域。“猫”和“狗”的距离，一定比“猫”和“汽车”更近。更妙的是，语义关系也体现在向量关系上，“国王”减“男人”加“女人”，得到的向量会非常接近“女王”的向量。
这个看似简单的性质，是整个 LLM 理解能力的基石。后面学注意力机制时你会看到，模型本质上就是在不断调整这些向量的“位置”，让信息按语义流动和汇聚。所以学 LLM 不要跳过 Embedding，它是地基中的地基。
2.3 Attention：模型靠“注意力”决定看谁
聊到 Transformer，必聊 Attention。但我要说的是：很多人把注意力机制神化了，它本质上干了一件事——加权求和。
每个 Token 在计算时，都拿自己的向量去和序列里其它 Token 比较相似度，相似度高的赋予更大权重，然后把所有 Token 的信息按权重混合起来。就好比你在嘈杂的聚会上，虽然满屋子人都在说话，但你只会重点关注你想听的那几个人的声音。
这里有个初学者容易理解的误区：Attention 不是让模型“看到”某个 Token，而是让模型“参考”某个 Token 的信息并融合进自己的表示。这个机制之所以关键，是因为它解决了传统模型难以建模长距离依赖的问题。无论两个词隔得多远，Attention 都能直接建立关联。这个特性直接决定了 Transformer 能成为大模型的基础架构。
2.4 参数：能力藏在数字里，但别神化参数
模型的能力很大程度体现在参数量上。参数就是模型内部的数值，在训练中不断被调整，最终沉淀成某种“知识”或“能力”。常见的小模型有几亿参数，中等模型有几十亿到上百亿，大模型动辄上千亿。
但我不建议初学者过度执着参数量。参数多不代表一定强，训练数据的质量、对齐程度、推理策略都会影响最终效果。参数更像是一个人脑子里神经元连接的数量，它决定的是潜力上限，而不是实际表现。
更实际的意义在于：参数量直接决定显存需求。后面讲部署时你会算一张表，多少参数的模型大概要吃多少显存，这是工程判断的第一个门槛。
2.5 上下文窗口：模型记忆的边界
最后一个核心概念是上下文窗口，也就是模型一次能处理的 Token 总数上限。你可以把它理解为模型的工作记忆容量：它能看到多长的内容，就能在这个范围内理解和推理。
上下文窗口不是越大越好，至少不全是。窗口越长，计算量增长越明显，推理延迟也会上来，并且模型对窗口中间部分的注意力往往有衰减问题。工程上经常说“长文本不等于长记忆”，就是这个意思。
了解了这些概念之后，你已经有能力看懂后续所有进阶内容了。下面我来讲最关键的实操部分——怎么动起手来，把知识变成手上功夫。
3. 实操过程与核心环节实现
3.1 动手第一步：选对实验环境
学 LLM 不动手是不行的。很多人问我一开始用什么环境，我推荐分三个阶梯：
- 第一阶梯是 CPU 笔记本。适合跑参数量 1B 以下的量化模型，做做词法分析、短文本生成、API 调用测试，学习成本极低，适合养成第一手感。
- 第二阶梯是单张消费级显卡。24G 显存级别，可以加载 7B、13B 量化模型，做推理、PEFT 微调实验，这是绝大多数自学者性价比最高的方案。
- 第三阶梯才是多卡集群。做全参数微调或大模型预训练。普通学习者不必强求，大部分概念通过小规模实验就能建立。
操作上，第一周你不需要写任何训练代码。先把推理链路跑通：装好一个主流的深度学习框架，下载某个开源模型（建议选 7B 以下量化版本），写几行推理代码，让它回答几个问题。这一套流程做完，你对“模型怎么被加载”“量化是怎么回事”“推理一次要多久”会有直观认知。
3.2 显存估算：这个模型我跑得动吗
“这个模型我跑得动吗”是出现频率最高的问题。我给你一个非常实用的估算公式，前提是你加载的是某个主流量化格式的模型：
显存需求 ≈ (参数量 × 每个参数字节数) × 1.2
- FP16（半精度）下每个参数占 2 字节
- INT8 量化下每个参数占 1 字节
- INT4 量化下每个参数占 0.5 字节
例如：7B 模型，FP16 加载，理论显存是 7 × 2 = 14GB，加上推理时的激活值和临时缓冲，乘以 1.2 的系数，需要大约 17GB 显存。但如果你加载 INT4 量化版本，理论 3.5GB，实际大约 4.2GB，一张 8G 显卡就能轻松跑起来。
不要问“为什么模型实际占用比文件体积大”，因为加载过程中除了权重文件，还要预留 KV Cache 和中间激活值。上下文越长，这部分占用越大。
3.3 五个必做的小实验
跑通推理后，我建议你按顺序做五个小实验，它们是建立实操手感的关键：
第一个实验是“参数探测”。拿相同的问题，换不同温度系数（Temperature）、不同采样策略（Top-p / Top-k），观察生成的随机性和质量变化。很多人对“随机”没有概念，这个实验能建立直觉。
第二个实验是“上下文窗口测试”。给模型一段长文本，再问它末尾小细节，逐步拉长文本到超限，看它何时开始出错。这会让你理解上下文窗口的真实边界。
第三个实验是“量化对比”。同一个模型，分别加载 FP16 和 INT8、INT4 版本，对比输出质量和生成速度。你会直观感受到量化对效果的影响程度。
第四个实验是“结构化 Prompt 设计”。用不同的 Prompt 格式（直接提问、角色设定、思维链引导）让模型解题，对比正确率，这是入门 Prompt Engineering 最好的方式。
第五个实验是“小样本微调”。挑一个小数据集做指令微调，让模型学会某种固定格式的输出。这一步是概念上的跃迁：你会意识到“模型原有知识并不包含这个格式，但它能学会”。
3.4 从推理走向微调：选好工具链
微调是大部分人进阶的第一个拦路虎，但其实今天工具链已经非常成熟。我推荐你从 PEFT 里的 LoRA 开始：冻结原有模型参数不动，只训练额外插入的小规模参数矩阵。它最大的价值就一句话——消费级显卡也能微调大模型。
以 7B 模型做 LoRA 微调为例，单卡 24G 显存完全可行。训练时需要注意学习率不能太高，常见范围是 1e-4 到 2e-4；批次大小受显存限制时，要开梯度累积保持等效批次足够大。这些参数在大多数微调框架里都有默认值，新手可以先用默认值跑通全流程，再慢慢调整。
我自己第一次跑微调时犯过一个特别低级的错误：没有先跑推理验证原始模型输出，直接就开始训练。结果微调后效果说不清是变好还是变坏，因为没有基线。这里也分享一个习惯：任何一次微调之前，务必先固定一组评测问题，记录原始模型的输出，再训练、再对比。没有对比的实验都是无效实验。
4. 常见问题与排查技巧实录
4.1 五个反复出现的“学习误区”
我见过太多学习者卡在同一个位置，总结起来无非五类。
第一类是“数学焦虑”。一提 Transformer 就要从矩阵乘法手推开始，结果连第一天都没撑过去。学原理要会分层：理解宏观流程并会调用工具，比会推公式更早带来价值。
第二类是“只学不用”。收藏了上百篇论文，几个月后和实操脱节严重。LLM 是极度依赖体感的领域，你读过十篇讲量化的文章，不如亲手跑一次 INT4 加载。
第三类是“只见模型不见数据”。很多初学者以为模型强大，是算法的功劳。事实上数据和算力是关键底座，数据质量和清洗工程对最终效果影响极大，这是做应用时最容易忽略的。
第四类是“忽视评估”。跑了几次生成，觉得“输出看起来还行”，就直接部署了。结果一上线，各种翻车。AI 评估是一门独立学科，至少要学会准备一组固定的评测集，拿数据说话。
第五类是“追逐新名词”。今天学 RAG，明天追 Agent，后天看多模态，找到什么学什么。缺乏主轴的学习效率很低，这也是我强调先建立全景地图的原因。
4.2 推理性能排查实录
以我自己的经验，推理慢是最容易被误判的问题之一。有一次我把一个量化模型部署上线，类 API 响应时间却长达十几秒，起初我以为是模型太大，后来逐个排查才发现是批处理配置出了问题，单请求占满了整卡资源，吞吐率完全没有利用起来。
这类问题的排查思路一般分四层：先看显存和带宽利用情况，再看是否开启了连续批处理，然后检查量化是否生效，最后才考虑是不是模型结构本身的问题。多数情况下，前三个环节就能解决 90% 的性能问题。
另一类高频问题是“输出不稳定”。同一个 Prompt，两次答案差异巨大。这往往不是模型坏了，而是采样参数设置的问题。把温度从 1.0 降到 0.1，把 Top-p 从 0.95 降到 0.8，输出立刻稳定很多。这类排查特别适合新手，因为它不需要懂模型细节，只需理解采样策略。
4.3 避坑清单：替你先踩一遍
我把最值得提醒的坑整理成一个清单，按频率排序：
- 第一，加载模型时没看上下文窗口配置，导致长文本请求直接报错。
- 第二，用 CPU 跑大模型，然后抱怨“为什么这么慢”。CPU 推理慢是正常的，一定要先确认资源匹配再下结论。
- 第三，微调时数据格式不对，Loss 降了但效果完全不对。指令微调的数据格式是生命线，跑通之前先逐条校验。
- 第四，生成结果不理想，第一反应是换模型，而不是调采样参数。很多时候不是模型不行，是采样参数太“野”。
- 第五，不记录实验参数。过了一周回来看当初的训练结果，完全忘记当时用了什么配置。强烈建议每个实验都写清参数记录。
提示：这里的“踩坑”大多不是环境问题，是认知问题。很多问题只要建立“先查参数、再换模型”的心法，就能少走一大半弯路。
4.4 关于评估：你至少要学会跑通一套评测
最后必须提一嘴评测。很多工程师在开发阶段对模型效果极度乐观，生产环境却接连踩坑，本质是缺了一套可靠的评测方案。评测不是“我觉得输出还行”，而是用一组固定的、覆盖真实业务场景的题目，对模型输出进行结构化打分的闭环。
哪怕只是小项目，我也建议搞一个最简单的评测脚本：准备十到二十条典型问题，记录答案，制定一个简单的打分规则，然后定期重跑。这套机制初期只需半天搭建，却能换来长期的判断基准。后续深入做模型选型时，这套小评测会变成你决策时的天平，比任何论文指标都贴近真实场景。
5. 后续学习路线的规划建议
这篇 Overview 的最后一件事，是帮你规划接下来的路径。基于主线加侧链的地图，我给出的顺序建议是：
- 第一优先级，吃透 Transformer 结构与训练全流程。这是理解一切的基础，后续无论做应用还是做底层，这里的坑迟早要补。
- 第二优先级，掌握推理部署，尤其是量化与推理加速。这是工程价值最直接的部分，也是普通开发者最能建立差异化能力的地带。
- 第三优先级，理解对齐与评测。这是当前研究的热点，也是提升模型可用性的关键环节。
- 第四优先级才是应用开发，例如 RAG 与 Agent。它们很重要，但如果你想做出真技术含量，前几层的基础会决定天花板上限。
系列的第二篇，我会拆解 Transformer 的内部结构，从 Embedding 到注意力头，再到多层堆叠到底在做什么，把“黑盒”拆成白盒，让每个组件都有直觉理解。
最后说点个人体感。我见过不少朋友学了两个月还没有亲手跑过一次模型，见到的全是别人总结的文字，这是最大的学习误区。LLM 学习没有捷径，但有一条平坦的路：先跑通、再拆解、最后修改。本篇给你的是地图和起点，接下来需要你亲手敲下第一行代码。
