大模型学习路线图：从Transformer到微调部署的完整笔记
这两年只要聊技术，绕不开三个字：大模型。不管是写代码的、做产品的、跑数据的，还是学校里的学生，都在问同一个问题：这东西到底怎么一步步变成今天这样的？我花了不少时间整理了一份学习笔记，把从统计语言模型到 Transformer，再到 GPT、LLaMA 这些路线的来龙去脉都梳理了一遍。这篇博文就是那份笔记的完整版，适合刚入门想建立全局认知的人，也适合已经在用大模型但是对底层演进脉络一知半解的开发者。
这篇笔记不堆公式、不贴论文长段摘抄，而是围绕几个核心问题展开：为什么之前那么多年语音识别、机器翻译都在做，但直到 Transformer 出现才真正爆发？为什么 OpenAI 走的是“大力出奇迹”的路线，而 Meta 却偏要把 LLaMA 开源出来？上下文长度、多模态、MoE 这些词到底解决的是什么具体痛点？以及当你自己动手微调、量化、部署一个大模型时，最常踩的坑都在哪里。这篇笔记适合当作你的第一份大模型学习地图。
1. 从统计语言模型到Transformer：大模型的前世今生
很多人以为大模型是 ChatGPT 出来之后凭空冒出来的，其实它的根很深。语言模型这个方向至少已经走了七十年，今天我们看到的一切，都是这条长线里一茬一茬积累出来的结果。
1.1 语言模型的老祖宗：n-gram 到神经网络语言模型
最早的语言模型叫 n-gram 模型，核心逻辑非常简单：一个词出现的概率，取决于它前面 n-1 个词是谁。比如二元模型（bigram）里，"学习"后面接"笔记"的概率，就是通过统计大量语料中"学习笔记"这个片段出现的频率来估计的。
这套思路在机器翻译、语音识别里统治了很多年，但它有一个致命的问题：数据稀疏。如果一个词组在训练语料里压根没出现过，模型就只会给出一个零概率，整个句子就被判了“死刑”。为了解决这个问题，研究者们折腾过平滑技术、回退模型，但本质上还是在同一个框架里打补丁。
到了 2003 年，Bengio 那篇《A Neural Probabilistic Language Model》算是打开了新大门。它把词映射成低维向量，也就是现在常说的词嵌入（word embedding），然后丢进一个前馈神经网络里去预测下一个词。这看起来只是把“离散符号”变成了“稠密向量”，但背后是一个很大的思想转变：相似语义的词在向量空间里距离更近。这样一来，即便某个词组没出现过，如果它的词向量跟另一个常见词组接近，模型也能给出一个合理的概率估计。
不过那个年代算力太弱，神经网络模型的规模也就几百万参数，效果并没有把 n-gram 彻底按在地上摩擦，所以神经网络语言模型在很长一段时间里只是学术界的小众爱好。
1.2 Word2Vec 带来的转折点
如果你去翻大模型的学习资料，几乎绕不开 2013 年的 Word2Vec。这东西不是语言模型本身，而是一种高效的词向量训练方法，但它把“词的向量表示”这个概念彻底带火到了工业界。
Word2Vec 有两种训练思路：CBOW 用上下文预测中心词，Skip-gram 用中心词预测上下文。它的厉害之处在于训练完的词向量有很强的语义规律性。最经典的一个例子是：国王 - 男人 + 女人 ≈ 女王。这说明模型的向量空间里，语义关系以“方向”的方式被编码了。
我当初第一次跑 Word2Vec 的时候，有一次把“北京”和“上海”的向量差值拿去算了一顿，发现羽果往“首都”的方向偏移明显，当时最大的感受是：原来机器“理解”语言的方式和人类完全不一样，它是一种几何式的理解。这个认知对后来理解 Transformer 的注意力机制很有帮助，因为本质上它们都是在高维空间里做“方向”和“位置”的运算。
1.3 2017 年 Transformer 横空出世，一切开始加速
真正让大模型成为可能的分水岭，是 2017 年那篇《Attention Is All You Need》。Google 团队提出 Transformer 架构的时候，本来是为了做机器翻译，但它的设计让训练和推理都有了质的改变。
Transformer 最大的特点是完全依赖注意力机制（Attention）来建模词与词之间的关系，不再需要 RNN 那种顺序结构。这意味着两件事：
- 可以并行计算。RNN 必须一个词一个词地往后推算，Transformer 可以把整个序列一次性丢进去做矩阵运算，训练效率直接起飞。
- 可以建模长距离依赖。RNN 处理长句子的时候，早期信息会被逐渐“稀释”，而 Attention 机制里，任何一个词都可以直接“看到”序列里任意位置的词，长距离依赖不再是问题。
这三个特性——语义向量化、并行化、长距离建模——凑在一起，给后来的“规模扩展”铺平了路。如果说 Word2Vec 证明了“向量能表示语义”，Transformer 则证明了“这种表示可以随着规模变大而持续增强”。从此以后，大家都开始往同一个方向疯狂加参数、加数据、加算力，大模型的军备竞赛正式开始。
2. 那些被反复刷新的关键概念：参数量、上下文长度与多模态
大模型发展的历史，本质上也是几个关键指标被不断刷新的历史。参数量从亿级涨到万亿级，上下文长度从 2K 扩到 1M，输入从纯文本变成图文音视频混合，每一步背后都有明确的工程或产品驱动力。
2.1 参数量到底意味着什么
很多刚接触大模型的人会问：参数量越大是不是一定越聪明？这里需要拆开看。参数量（Parameters）可以理解为模型的“记忆容量”和“建模能力”的综合体现。一个 7B（70 亿参数）模型能装下的知识量，肯定比 1B 模型大得多，但“更大”不等于“更好”，还要看训练数据和训练方法的匹配度。
GPT 系列的发展特别直观。GPT-1 有 1.17 亿参数，效果只能用“能生成通顺句子”来形容；GPT-2 跳到 15 亿参数，已经可以生成有一定连贯性的文章；GPT-3 直接干到 1750 亿参数，才出现了“零样本学习”这种让人眼前一亮的能力。OpenAI 在这条路上验证了一个朴素但有效的规律：当模型规模跨过某条线之后，会涌现出小模型不具备的能力。
不过这里有个容易被忽略的细节：不是所有公司都有能力训练千亿参数模型。训练一个 175B 模型的算力成本，对绝大多数团队来说是天文数字。所以后来业界分化出了两条路线：要么堆超大模型追求极致能力，要么用 7B、13B、70B 这种“中等规模”模型配合精细训练，在特定领域做到够用。
我自己的经验是：70B 的模型在推理质量上确实比 7B 强不少，比如在代码生成、长文本理解这些场景里差别很明显，但 7B 模型经过好的微调，在垂直领域也能打得过没有微调的 70B 通用模型。参数量的价值，必须结合训练数据的质量和针对性来判断。
2.2 上下文长度：从 2K 到 1M 的工程突破
上下文长度（Context Length）是另一个被疯狂内卷的指标。最早 GPT 系列只有 2048 个 token，这就意味着你扔给它一篇文章，它只能“看到”前两千来个 token 的内容，再往后就直接忽略了。对于问答、摘要这类场景还好，但如果你让它读一本书、分析一份财报、理解一个大型代码仓库，那完全不够用。
后来各家开始卷上下文窗口：Claude 从 100K 干到 200K，Gemini 宣称 1M，国产模型也有不少直接标配 128K。这个数字从 2K 涨到 1M，表面上是“能读的东西变多了”，本质上其实是工程上的巨大胜利。因为 Transformer 的注意力机制是 O(n²) 复杂度，序列长度翻一倍，计算成本涨四倍。想要支持超长上下文，必须在注意力计算上做优化，比如稀疏注意力、滑动窗口、KV Cache 压缩等。
这里我建议所有做大模型应用的人，一定要把“上下文长度”当成一个成本参数而不是“能力参数”来看。因为你的 prompt 越长，模型推理的时间越长，API 费用也越高。我在实际做 RAG 应用的时候，就经常遇到“明明模型支持 128K，但塞太多 token 之后首字延迟高得离谱”的情况。上下文长是能力上限，但不是让你每次都顶着上限用的。
2.3 多模态：人类输入方式的回归
大模型最早只能处理文本，因为训练数据主要就是网页文本。但现在你打开任何一个主流大模型产品，都可以直接上传图片、音频、视频，这就是多模态化。
多模态的路线有两种主要做法。一种是“拼接式”，也就是把图片切成块之后也转成 token，跟文本 token 一起丢进模型；另一种是“统一式”，从一开始就用一个模型同时处理多种模态的数据。
2025 到 2026 年这段时间，多模态大模型的进展特别夸张。图片问答已经不是简单的“这是什么”，而是可以帮你分析图表、识别流程图、看图写代码。语音交互也做到了端到端低延迟。这背后的核心问题是：不同模态的信息如何在同一个向量空间里对齐。文本里的“猫”和图片里的“猫”，怎么让模型意识到它们是同一个概念，这是多模态研究的核心难点。
对于普通开发者，多模态带来的直接机会是：以前需要接一堆 OCR、语音识别、图像识别服务才能完成的任务，现在一个模型全搞定。比如我最近在做的一个票据识别工具，以前是“OCR 提取字段 + 规则解析 + 人工校验”三步走，现在直接丢一张票据图片给多模态模型，json 结构就出来了，准确率还不低。这就是多模态大模型在工程上最直观的价值。
3. 从论文到工程：微调、量化、部署与私有化落地
光会看论文、刷跑分，不算真正理解大模型。无论你是做产品还是做研究，迟早会走到这一步：拿到一个开源模型，想办法让它适配自己的数据，再把它部署到自己的服务器上。这个过程里踩过的坑，比想象中多得多。
3.1 微调：让通用模型变成行业专家
大模型训练分两大阶段：预训练（Pre-training）和微调（Fine-tuning）。预训练是花几百万美元，在几千亿 token 的通用语料上训练基础模型，让它学会“语言的一般规律”。微调则是在基础模型之上，用更小规模的高质量数据做进一步训练，让它学会某种特定风格或特定领域的知识。
现在提到微调，绝大多数时候指的是参数高效微调，最主流的方法是 LoRA（Low-Rank Adaptation）。LoRA 的思路不是去改原始模型的全部参数，而是训练一个低秩矩阵作为“补丁”，挂在原始模型旁边。这样做的好处非常明显：
- 显存占用低，一张消费级显卡甚至都能跑。
- 训练速度快，不用动底层的几十亿参数。
- 微调完只是一个几百 MB 的小文件，随时可以热插拔。
在实际操作中，我建议刚上手的人不要一开始就微调。先用提示工程（Prompt Engineering）试试，不行再考虑 RAG（检索增强生成），最后才轮到微调。因为微调虽然效果好，但它需要准备数据集、调参数、防过拟合，一份高质量的训练集可能就得准备两星期。我的经验是：数据质量远比数据量重要。一份十万元的精品数据，效果可能比一万条从网上爬来的杂数据还好。
做微调的时候有四个核心超参很值得反复实验：
- 学习率（Learning Rate）：一般从 1e-5 到 2e-5 起步，太大容易训崩，太小效果不明显。
- 训练轮数（Epoch）：3 到 5 轮是常见区间，轮数太多容易过拟合。
- 批次大小（Batch Size）：受显存限制，一般 1 到 8 之间，梯度累积可以弥补小批次带来的不稳定。
- LoRA 秩（Rank）：通常 8 到 64 之间，秩越大能学到的信息越多，但显存和过拟合风险也越高。
3.2 量化与推理优化：小显卡也能跑大模型
微调完模型之后，如果你打算在本地部署，遇到的问题往往不是“效果行不行”，而是“跑不跑得动”。一个 7B 模型，如果用 FP16 精度加载，光权重就要占 14GB 左右显存，很多人的显卡只有 8GB、12GB。这时候就得用量化（Quantization）。
量化的核心思想是把模型权重从高精度（FP16/BF16）压缩到低精度（INT8/INT4），让模型体积变小、推理速度变快，代价是精度稍微损失一点。实际用下来，INT8 量化在大多数任务上跟原始精度几乎没有区别，INT4 会有轻微损失，但可用性依然很高。
目前最流行的量化工具是 llama.cpp 和 Ollama。llama.cpp 支持跑 GGUF 格式的量化模型，Ollama 则把模型管理、量化、API 调用全部封装好了，一个命令就能跑起来：
ollama run qwen2.5:7b说实话，我第一次用 4GB 显存的旧笔记本跑通 7B 模型的时候，挺惊讶的。虽然每秒只能输出几个 token，但至少能跑通了。这说明量化对于个人开发者来说是刚需技术。
推理阶段还有一个重要组件叫KV Cache。它缓存了历史 token 的 Key 和 Value 矩阵，这样每次生成新 token 的时候不需要重新计算所有历史信息。代价是它会占用额外显存，上下文越长，KV Cache 越大。所以你会发现，模型可以支持 128K 上下文，但如果你真塞满 128K，显存可能直接爆掉。
3.3 企业私有化部署：数据安全才是第一优先级
很多企业不直接用公共 API，是因为数据敏感性。比如医疗病历、金融交易记录、内部代码，这些数据绝对不能离开企业的边界。所以“私有化部署”成了大模型落地最核心的场景之一。
私有化部署的架构通常长这样：
- 模型层：找一个开源基座模型（Qwen、DeepSeek、LLaMA、GLM 等），按需微调。
- 推理引擎层：vLLM、Ollama、LM Studio 或者 TensorRT-LLM 来把模型跑起来。
- 应用层：FastGPT、Dify 这类平台负责做知识库上传、工作流编排和 API 封装。
- 外围服务：向量数据库（Milvus、Chroma、pgvector）做 RAG 的检索，再叠加一个权限管理。
这套组合拳的好处是：模型完全在自己手里，数据不出内网，同时还保留了对模型行为做审计的可能性。
我提醒过很多人一个容易忽略的问题：私有化部署并不等于“一劳永逸”。模型是要迭代的，数据是要更新的，安全补丁也是要打的。你以为私有化就没人能攻击你了，其实针对本地模型的“投毒攻击”（data poisoning）和“越狱攻击”（jailbreak）都是真实存在的。做私有化，不只是跑一个容器那么简单，它是一个需要持续维护的系统工程。
3.4 免费 API 与本地部署的取舍
现在市面上有大量免费的模型 API 可以白嫖，比如 DeepSeek、通义千问、智谱等，各家都有自己的免费额度政策。对于程序员来说，想快速做一个 Demo，直接调免费 API 是最快的方式，几分钟就能拿到返回结果。
但“免费 API”有几个限制需要注意：
- 限流：每分钟请求次数有限。
- 上下文限制：免费档一般比付费档短。
- 数据政策：有些免费 API 会声明数据可能被用于模型训练。
- 模型版本滞后：免费档通常跑的不是最新最强的模型。
所以我的建议是：开发调试阶段用免费 API 最划算，生产环境要么买付费 API 拿 SLA，要么私有化部署核心流程。不要把一个业务的命脉绑在免费 API 上，哪天服务商改政策，你连哭都来不及。
4. 大模型评测、常见问题与避坑经验
等你真正开始用大模型、做大模型，会发现“能跑通”和“用得好”之间隔着一条巨大的鸿沟。下面是我在实际操作中总结出来的评测方法和高频踩坑记录。
4.1 大模型怎么测才靠谱
大模型的评测是个很微妙的事情。外行看跑分，内行看场景。如果你只是拿着标准 benchmark（比如 MMLU、GSM8K、HumanEval）去对比两个模型，很容易得出一个和实际体验完全不符的结论。
原因很简单：标准 benchmark 测的是“通用能力”，但你的业务场景是具体的。比如你做一个法律文书生成工具，一个模型在数学考试里拿 99 分，另外一个只拿 70 分，但后者对法条的引用准确性高很多，那它在你的场景里就是更好的模型。
我在评测一个模型的时候，通常会搭一套“私有评测集”：
- 从真实业务数据中抽 50 到 100 条代表性问题。
- 把同一个问题分别丢给多个模型，拿到输出。
- 请业务方同学（或者领域专家）人工打分或者按规则自动打分。
这套流程看起来土，但比任何公开跑分都管用。跑分只能给你一个初筛的方向，真正做决定还是要落在业务数据上。而且要注意，评测集的答案最好做成“参考答案 + 评分规则”，因为大模型的输出往往不是唯一解，太死板的校验规则容易误杀。
另外，现在有一些专门做模型评测的平台（比如 OpenCompass、LMSYS Chatbot Arena），它们收集大量用户的匿名投票来给模型排名。这种“真人盲测”的口味有时候比跑分更接近实际体验，因为用户不会关心你用了什么技巧，他们只关心“这个回答我用起来顺不顺”。
4.2 数据标注与数据污染问题
做微调或者评测的时候，数据质量永远是首要问题。很多初学者直接去开源数据集上爬数据，结果训练出来的模型不仅效果差，还容易出现“答非所问”的情况。
数据标注的时候，我踩过几个大坑，这里集中说一下：
- 标注者不作为：让非专业人员瞎标，数据里全是错误答案，模型越训越笨。
- 格式不统一：有人用“问题：... 回答：...”这种格式，有人用 JSON，模型训练完连指令都识别不利索。
- 缺乏困难样本：训练集里全是简单问题，模型学不到真正的推理能力，一遇到稍微复杂的任务就崩。
大模型数据标注还有一个特别的骗局：用大模型标注大模型数据。比如你用 GPT-4 生成了一万条微调数据，再拿这些数据去微调一个 7B 模型，效果会和“蒸馏”有相似之处，但如果你不加筛选就直接用，往往会把 GPT-4 的幻觉也一并学了过来。正确的做法是要对生成的数据做人工抽检和清洗，尤其是那类涉及事实性知识的问题，必须人工核实答案的准确性。
4.3 上下文长度与代码开发的实操问题
许多开发者在用大模型辅助写代码时，会遇到“模型上下文不够用”的情况。比如你想让它重构一个类，但这个类有一百多行，你还想让它参考另一个文件里的工具函数，这加起来可能就超过上下文限制了。
我常用的几种应对方案：
- 拆分任务：把大任务拆成小任务，每次只给模型一个文件的上下文。
- 使用 RAG：把代码库做索引，让模型先通过检索找到需要的代码片段，再拿去问答。
- 优先选用支持长上下文的模型：如果你确实需要让模型一次看完整份代码，建议选 128K 以上的模型，或者本地部署一个长上下文版本。
还有一个小技巧：写代码提示词的时候，尽量让模型“先解释再写”。让它先说清楚思路，再给代码，比直接让它输出代码更能稳定拿到高质量结果。
4.4 一个真实的避坑清单
我在社区分享过一份“大模型落地避坑清单”，这里挑几条最常被问到的展开讲讲。
模型总是“一本正经胡说八道”，怎么缓解？ 幻觉是当前所有大模型的通病。最有效的手段是让模型学会说“不知道”。你在系统提示词里明确写“如果信息不在提供资料中，请直接回答‘未找到相关信息’”，能明显减少胡编答案的情况。另外，把答案的“出处”抓出来，要求模型给出引用来源，也能大幅提升可信度。
模型越狱攻击怎么防？ 任何对外提供服务的模型，都要考虑提示词注入（Prompt Injection）的问题。攻击者会在输入里塞一些恶意指令，试图覆盖系统提示词。一个比较笨但有效的方法是：对输出做校验，确保模型输出的内容符合预期格式，同时对输入做敏感词和异常模式过滤。涉及 RAG 的场景还要小心“检索结果投毒”，攻击者把恶意文本排在检索结果前面，诱导模型输出有害内容。
用了 API 但响应特别慢，是模型差吗？ 这是非常常见的问题。响应慢可能不是因为模型性能差，而是因为：你喂的上下文太长（前面说过 KV Cache 的问题）、服务器排队、或者你的网络出口有问题。排查顺序应该是：先看 API 延迟指标，再看输入 token 数量，然后考虑切换到更快的推理引擎。
本地跑模型总是 OOM（显存不足），怎么办？ 有三个方向：换更小的量化版本（比如 4bit），调小最大生成长度，或者切换到 CPU 推理（虽然慢，但至少能跑）。如果你用的是 vLLM，还可以开启“prefix caching”和“chunked prefill”来降低显存压力。
4.5 国外开源生态与国产模型的互补
目前开源大模型的生态已经相当丰富，国外有 LLaMA、Mistral、Gemma 这些，国内则有 Qwen（通义千问）、DeepSeek、GLM（智谱）、Baichuan 等。国产模型这几年的进步非常快，尤其是在中文理解、长文本和代码生成这几个维度上，很多开源版本的表现已经和国际一线模型处于同一梯队。
我自己比较常用的组合是：
- 通用对话：Qwen 系列，中文好，指令泛化能力强。
- 代码生成：DeepSeek 系列，代码推理和补全效果非常突出。
- 私有化部署：7B 和 14B 级别的模型，加 INT4 量化，单卡就能跑。
- 低成本高并发：硬实力不够就搭配 vLLM 做吞吐优化。
如果你有条件用国外模型做对比，建议不要只看规模，要多看具体任务上的实测效果。有些 7B 模型在代码场景的推理速度和质量，真的比 13B 的通用模型还好。模型选型不是一个“越大越好”的单选题，而是一个根据场景做匹配的多选题。
5. 大模型学习路线：从新手到上手的进阶路径
最后这部分聊一聊“怎么学”。我经常看到有人一上来就买一堆大模型深度学习的课程，或者直接去找论文原文，结果不到两周就放弃了。原因是这条路太陡，缺乏一个渐进的过程。
5.1 新手期：先会用，再懂里
如果你的目标是能上手做应用，我建议第一步就是用 API。找任何一家支持免费额度的模型服务，注册一个账号，把官方文档里的第一个示例代码跑通，你会获得第一次正向反馈。之后再尝试改改 prompt，让它帮你写周报、翻译文本、总结文档，慢慢建立对模型表现的直觉。
这个阶段不用管什么微调、量化，那些都属于工程优化问题。你需要理解的是“大模型能干什么、不能干什么、什么样的输入能得到什么样的输出”。至少要知道“上下文窗口”这个概念，知道为什么同一个问题换个问法结果完全不同。
当你能熟练使用三四个主流平台的 API 时，就可以开始了解 Token 是怎么计算的、为什么计费按 Token 算而不是按字数算。这一步虽然简单，但它会帮你建立对后续所有工程优化的基本意识。
5.2 进阶期：本地跑模型，感受工程的“重量”
当你对 API 的调用已经非常熟练，下一步是尝试本地部署一个开源模型。你可以从 Ollama 开始，它几乎把所有的环境配置全部封装掉了，几条命令就能跑起来一个模型：
ollama pull qwen2.5:7b ollama run qwen2.5:7b跑通之后，你会立刻遇到第一个现实问题：我的显存不够。这个时候再引入量化、推理引擎等概念，会比纯粹看文档理解得深得多。如果说调用 API 能让你学会站在岸上看游泳，那本地部署就是让你真正下水扑腾，感受水的阻力。
这个阶段，如果有余力，建议自己动手把 vLLM 部署起来，或者用 FastGPT/Dify 搭一个简单的知识库问答系统。这样你就把“模型 + 推理 + 应用”的完整链路都打通了，真正进入大模型工程的世界。
5.3 开拓期：微调一个属于你自己的模型
再往后，就是微调。我不建议新手一上来就微调大模型，但当你已经积累了足够多的“任务判断经验”，比如你知道自己的业务场景里模型为什么回答不好、差在哪里，这时候微调的价值才会真正体现。
动手前，先问自己三个问题：
- 我的任务里，模型当前的失败点是什么？
- 提示词工程和 RAG 都已经试过了吗？为什么还不够？
- 能不能拿出至少一两百条高质量的训练样本？
都确认了，再去跑 LoRA。刚开始可以不用自己写训练代码，用一些已经封装好的框架就行，比如 LLaMA Factory、Axolotl。
顺带提一嘴，现在市面上的免费课程和 PDF 资源非常多，找一套口碑好、更新及时的教程作为主线，比零散地到处看博客效率高得多。但不管看什么教程，记得一定要动手跑代码。大模型的学习，本质上是在“踩坑中长出来的”。
5.4 一点个人的经验总结
写了这么多，最后聊几句真心话。大模型发展史这条线，看起来是各种技术名词的堆叠，但真正理解它之后你会发现，每个阶段的转折点都源于一个简单的追问：“现在这个方案，痛点到底在哪里？”
以我个人实际操作来看，最有用的学习方法不是背熟多少篇论文，而是“带着问题去看历史”。当你被长上下文显存问题折磨过一遍，再去看稀疏注意力的论文，会有一种豁然开朗的感觉。当你被模型幻觉坑过一次，再去理解 RAG 的设计思想，立刻明白那才是解决幻觉的第一优先级。所有的理论学习都要落到“能支撑你做出更好的工程决策”上，这才是大模型笔记真正的意义。