做了一段时间大模型相关的开发，我发现身边很多朋友一开始就卡在同一个地方：手里攥着各种“大模型发展史”的时间线，却不知道这些历史节点和现在选模型、调参数、做评测有什么关系。其实大模型这份“历史”非常短，才七八年，但它几乎等于整个现代AI应用的全部底层逻辑。你搞清楚了GPT为什么能出现、BERT为什么选了另一条路、ChatGPT为什么突然就火了，很多今天看起来特别玄的概念——上下文长度、微调、RLHF、Agent——一下就串起来了。

这篇文章是我自己的学习笔记，按“技术演进”和“工程落地”两条线来写。主线是大模型是怎么一步步变成今天这个样子的，副线是每个阶段留给我们今天能直接用的工具和方法。不堆公式，也不绕弯，适合想系统搞清楚大模型、打算入门做应用开发的读者。里面涉及的模型选型、部署方式、跑分网站，都是我实际用过或者踩过坑之后整理出来的。

1. 大模型的起点：先搞明白“大”在哪里

很多新手最容易犯的错，是把“大模型”当成一种全新的算法。实际上大模型用的核心算法还是深度学习里的Transformer，它的“大”主要体现在模型参数量、训练数据量和算力投入这三个维度同时拉满。这三个维度不是独立变化的，它们之间存在强耦合关系，理解这一点，后面理解各种工程问题会轻松很多。

1.1 参数、数据、算力：三要素缺一不可

先说参数。模型参数量决定了模型的“容量”，也就是它能记住多少模式和规律。早期的BERT-large大概是3.4亿参数，GPT-2最大的版本是15亿参数，到了GPT-3直接跳到1750亿，后来各家开源的模型，比如Llama 3 405B、DeepSeek系列，参数规模也都在这个量级上。参数越多的模型，理论上能覆盖更复杂的任务，但也意味着需要更多的数据和算力来把它训练出来，推理的时候也需要更大的显存。

再说数据。大模型训练需要的文本数据是海量的，而且对质量越来越挑剔。GPT-2时代用的大概是40GB的网页文本，到了GPT-3已经是几千亿个token，后来的模型普遍强调数据清洗、去重、配比，因为研究员们发现“脏数据”会让模型进入崩溃状态，学一堆偏见和垃圾进去。今天做大模型微调的人，都应该记住这个教训：数据的干净程度，比数据的数量更要紧。

最后是算力。拿GPT-3来举例，训练一次的成本在当时大约是数百万美元量级，普通人根本碰不了这个数字。这也是为什么大模型的早期格局非常集中，因为只有少数公司能烧得起这种规模的算力。不过到了今天，推理算力和微调算力已经大幅下沉，单卡或者单机跑一个量化后的70B模型，或者用消费级显卡微调一个7B模型，已经成为常规操作。

1.2 Transformer架构为什么成了“地基”

2017年Google那篇《Attention Is All You Need》提出Transformer，这件事怎么强调都不过分。它把此前序列模型主流的RNN/LSTM路线整个掀翻了，核心原因是自注意力机制可以让任意两个位置直接建立联系，而不是靠顺序一步步传。简单理解就是，RNN像你一个人排队读长句，必须按顺序一句话一句话看；Transformer像你拿了一张关系图，一下子看到句子里所有词互相之间的关联。

这个架构有两个关键优势。第一是并行计算效率极高，因为不再依赖时序递推，GPU可以同时处理所有位置的计算；第二是长距离依赖建模能力强，句子哪怕再长，前面的词和后面的词依然可以直接做注意力交互。这两个特性直接驱动了“更大的模型+更多的数据”这条路能走下去，因为你喂进去的文本越多，并行训练的优势就越明显。

后来的发展里，Transformer衍生出两种变形：一类是只保留编码器（Encoder），代表是BERT，擅长理解任务；另一类是只保留解码器（Decoder），代表是GPT，擅长生成任务。今天大家说的大模型，尤其是ChatGPT这一系，基本都走了解码器路线。原因很直接：生成式模型能直接做对话、写代码、续写文本，应用边界更宽。

1.3 Scaling Law：为什么“变大”真的有用

光说“参数多就厉害”不严谨，真正把大模型推向历史舞台的，是OpenAI在2020年前后发布的Scaling Law研究。这个规律用一句话概括就是：在合理的范围内，把模型参数量、训练数据量、算力投入同时放大，模型的损失（也就是预测误差）会按照幂律关系稳定下降。换句话说，损失函数跟你投进去的规模是高度可预测的，不是玄学，是一条经验曲线。

这背后带来的产业影响非常深远。模型厂商可以通过小规模实验推算大模型的性能，资本市场也因此愿意投入巨额资金，因为“烧钱”已经被证明能带来确定性的能力提升。但Scaling Law也有一个被很多人忽略的“暗面”：它表明单靠扩大规模，收益是边际递减的，想把损失再降低哪怕一点点，可能要翻倍甚至翻几倍的算力和数据。

这也是为什么后来大家开始在全链路优化上下功夫：更好的数据配比、更长的上下文、更强的对齐（Alignmen），这些都是希望在“规模天花板”前面再挤出一些能力空间。对我来说，理解Scaling Law最有用的点在于：当你想自己训练一个大模型时，先预估清楚预算和数据量，再去决定模型规模，不要一上来就追最大参数。

2. 三代模型演进：技术逻辑与关键节点

如果只记时间线，会很容易把大模型发展史背成一串人名和模型名。我的学习方式是按“技术范式”来划分阶段：预训练范式的确立、对齐范式的出现、多模态与Agent范式的崛起。三个阶段之间不是后者推翻前者，而是层层叠加的。

2.1 预训练时代：GPT与BERT的路线选择

2018年前后，NLP领域出现了两个标志性工作：GPT和BERT。它们共同确立了“预训练+微调”的基本范式，也就是先用海量无标注文本训练一个通用模型，再针对具体任务做小规模微调。这个想法后来成为整个大模型时代的地基。

但两条路线有明显的分歧。BERT是双向编码器，它可以同时看到句子前后文，所以在阅读理解、文本分类这类判别任务上表现极强，当时GLUE榜单上一直是BERT系列霸榜。GPT则是单向解码器，只能从左往右预测下一个词，看起来是个“劣势”，但恰好这个特点让它天然适合生成任务。

后来的故事大家也知道了，GPT沿着“解码器+生成”路线一路做大，从GPT-2到GPT-3，模型参数从1.5亿涨到1750亿，并且在这一过程里发现了一个重要现象：当模型足够大，仅仅通过“给几个示例”就能在没经过微调的情况下完成新任务，这就是所谓“上下文学习”。这个现象让研究人员意识到，模型的能力可能远超预期，也为后续ChatGPT的横空出世埋下了伏笔。

2.2 对齐革命：InstructGPT与ChatGPT

很多人以为ChatGPT的技术飞跃是参数量大幅增加，其实GPT-3之后，参数量并没有本质变化，真正的突破发生在一个叫“对齐”的方向上。2022年OpenAI发布InstructGPT论文，核心做法是在GPT-3的基础上，先用人工编写的指令数据进行监督微调，再训练一个奖励模型来模拟人对回答质量的打分，最后用强化学习（PPO）进一步优化模型，这套流程就是后来被反复提及的RLHF。

用大白话说，以前的大模型像是一个聪明但不太听话的学霸，你问它一个问题，它能答，但它不知道什么是“好的回答”，经常跑偏、车轱辘话、甚至胡编。对齐做的就是给这位学霸立规矩：告诉它人类更喜欢简洁、诚实、有用的答案，并且通过人类的偏好反馈反复校准。ChatGPT能火遍全球，不是因为它是第一个生成式大模型，而是因为它第一次让普通用户感觉“AI终于听得懂人话了”。

从工程角度，对齐给我们的直接启示是：大模型应用的瓶颈不只在模型本身，还在“数据-反馈-优化”这个闭环。就算你用开源模型做私有化部署，也应该考虑怎么整理高质量的人机交互数据，或者至少做一套适合业务场景的System Prompt，本质上这就是轻量级对齐。

2.3 多模态与Agent：当前阶段的主线

到了这一两年，大模型明显转向两个方向：一个是多模态，一个是智能体（Agent）。多模态意味着模型不再只吃文本，还能理解图片、音频、视频，典型路径是在预训练阶段或者后训练阶段引入视觉编码器，把图像特征对齐到文本特征空间里。这对应用的影响是巨大的，比如工业质检、医疗影像、会议纪要、视频理解，都能直接用一个大模型搞定，不再需要拼装多个单模态模型。

Agent方向则更偏工程。大模型不再只是“你问我答”的对话机器，而是扮演一个能感知环境、做规划、调用工具的“执行者”。常见做法是给模型接上API、数据库、代码执行器，让它根据用户目标拆解步骤、自主决策。比如最典型的RAG（检索增强生成）场景，模型发现自己的知识不够时，主动去数据库检索文档，再用检索结果生成答案，这就已经带了一点Agent的影子。

这个阶段还衍生出一个很重要的话题：安全。因为模型被赋予了工具调用和自主行动能力，一旦被恶意输入诱导，轻则输出垃圾内容，重则泄露业务数据。所以现在的大模型评测里，指令注入测试、投毒测试、红队攻防越来越受重视。做应用开发的人，从第一天起就该把“安全护栏”放进架构设计里，而不是最后才补。

3. 应用大模型必须理解的几个核心概念

发展史看完，再看具体应用，很多概念就不再是孤立的名词了。这一章我挑四个和实际开发最相关的点来讲：上下文长度、微调与提示工程的取舍、本地部署工具链、评测基准。

3.1 上下文长度：从2K到1M，影响的是什么

上下文长度指的是模型一次能处理的token数量上限。早期GPT-3只有2048个token，这意味着你没法一下子把一整篇论文或者几万行代码丢进去。后来各家的模型都在拼命拉长这个数字，从4K、8K一路干到128K、200K甚至百万级。

上下文变长不只是“能读更多字”这么简单。它直接决定了业务边界。比如客服场景，如果上下文只有4K，你可能只够塞下用户最近几轮对话，超出部分只能截断；如果到了128K，就可以把几十页产品手册直接作为背景知识喂给模型，很多需要外挂知识库的场景可能就不需要RAG了。

但长上下文也会带来两个新问题。第一是推理成本上升，因为每多一个token，注意力计算都会增加，实际操作中KV Cache会吃大量显存，你会发现模型明明能处理128K，但硬件跑不动。第二是“中间遗忘”现象，模型对长文本开头和结尾的记忆通常比中间好，检索出来的关键信息如果落在中间位置，照样容易出错。所以我的经验是：不要无脑依赖长上下文，关键内容尽量前置，或者配合RAG做定向召回。

3.2 提示工程与微调：两条路线怎么取舍

我用一张对比关系来说明这个问题，这是很多入门朋友最纠结的选项：拿到一个开源模型，到底该用提示工程硬调，还是训练微调？

提示工程的优势是快、成本低、不改模型。你把任务描述、示例、约束直接写进Prompt，用上下文学习的方式来引导模型。它适合任务边界不清晰、需求变化快的阶段，今天要提取关键信息，明天要改写风格，写一段不同提示词就行。缺点是效果上限受限于模型本身能力，复杂格式、专业术语、私有知识这些场景，单靠提示词经常撑不住。

微调则是用一批标注好的数据去更新模型权重，让模型在特定领域、固定格式或特定语气上表现稳定。它适合需求稳定、数据量可控、追求高准确率的场景，但缺点是每次调整都需要重新训练和评估，成本明显高于提示工程。

我的建议是：能用提示工程解决的，绝不先上微调。先花时间把Prompt和少量示例打磨好，如果试下来发现模型记不住私有知识的表达格式，或者输出格式不稳定，再考虑微调。微调方案首选LoRA，它能保持基础模型不变，只训练一小部分低秩参数，显存开销比全参数微调低一个量级，效果在很多场景下已经够用。

3.3 本地部署与私有化部署：工具链全景

现在聊“私有化部署大模型”已经不是大厂专属了。个人开发者用Ollama、LM Studio这类工具，可以在消费级电脑上跑7B到14B的量化模型；企业的私有化部署则会基于vLLM、TensorRT-LLM这些推理框架，在专用GPU集群上提供服务。

本地部署的基本链路大概是：先从Hugging Face或者ModelScope把开源模型权重下载下来，转成GGUF这类推理格式，再通过推理工具加载并暴露一个本地API。比如LM Studio自带一个兼容OpenAI的HTTP接口，你完全可以后端写好业务代码，然后调本地地址，数据不出内网，隐私性拉满。

这里最核心的工程问题是显存估算。一个7B模型，用FP16加载大约需要14GB显存，用4-bit量化后差不多只要4GB到6GB；一个70B模型，4-bit量化后也大概需要40GB上下，基本只有多卡或者大显存单卡才能跑。所以选型逻辑很简单：先看你的硬件支撑，再反推能用多大参数模型，而不是先选模型再发现跑不动，再回来找小模型，白白浪费时间。

3.4 评测基准与跑分网站，怎么看得靠谱

大模型跑分网站五花八门，很多新手喜欢直接看综合榜单挑模型。我自己吃过这方面的亏：有次选了一个综合分很高的模型做中文客服，结果真实场景里胡说八道，后来一查，那个榜单大量题目来自它训练数据范围内，等于“开卷考试”。

所以正确做法是关注三类评测：第一类是通用知识类，如MMLU、C-Eval，它们能反映模型的知识广度，适合横向参考；第二类是任务能力类，如代码生成的HumanEval、数学推理的GSM8K，适合根据你的业务场景选择性参考；第三类是偏好类，比如LMSYS Chatbot Arena这种人类盲测排行榜，它更接近真实用户感受，不会被单次开卷刷分干扰。

对做应用的人，我建议测试口诀是：在模型API上加一套本地化评测集，放五组你业务中真实会出现的输入，跑一遍看输出稳定性和质量。任何跑分网站都代替不了这一步，因为业务数据的长尾差异，只有你自己最清楚。

4. 大模型开发学习路线：从零到能干活

最后这部分写给想系统入门大模型开发的朋友。学习路线很多，我不打算给一张看起来很完美的表，而是按我自己觉得最顺的顺序来讲，按这个顺序，每个阶段产出的东西都能直接用起来，学习动机不容易断。

4.1 一条能快速上手的路线

我的建议是先会“用API”，再入门“原理”，最后才碰“训练”。第一步，先用现成的开源模型或者商业API跑通一个最简单的对话程序，理解Prompt、温度参数、上下文长度这些概念，这个过程可能需要两三天。第二步，学一下Transformer的基本结构，不用背公式，重点理解Self-Attention在做什么、Token怎么切分，这一步是后面所有深入理解的地基。第三步，做一个小项目，我强烈推荐从RAG起步，因为RAG几乎包含了大模型工程的所有关键环节：文本切分、向量化、召回、组合Prompt、评估输出。第四步，有余力再碰微调，从LoRA开始，找一个开源数据集做风格转换或领域适配，跑通流程之后你会发现很多理论都能对上号了。

4.2 常见问题与排查技巧

学习和开发过程中，有几个问题几乎是每个人都会遇到的。我列成一张速查表：

这里面我个人觉得最值得细说的是“微调后效果变差”。很多新手第一次微调，巴不得把几万条数据全灌进去，结果模型在特定任务上固化了，反而丢了通用能力。正确做法是先用几百条高质量样本试跑，对比验证集上的表现，确认方向对了再逐步扩数据。微调不是数据越多越好，而是越干净越好。

4.3 一些值得收藏的工程经验

这里分享几个我实际项目中沉淀下来的独门经验，常规文档一般不会写这么细。

第一，大模型应用要提前设计“安全护栏”。不要等到上线前才测试指令注入，你应该一早就假定用户会输入恶意Prompt，在系统层面做好权限管理和内容过滤。做企业私有化部署时，这个点会被无限放大，因为模型能接触内部数据，一旦被诱导越权，风险极高。我习惯的测试方式是把常见攻击输入和“红队话术”固化到回归测试集里，每次更新模型版本都跑一遍。

第二，处理长文档不要迷信“全量塞进去”。哪怕模型支持128K上下文，塞进去的成本都很高。我的做法是把文档切块，先做摘要，再结合向量检索把最相关的块回填到Prompt里。这样做既省钱，速度又快，而且输出准确性往往比全量塞更好。

第三，多模态和Agent方向的落地，别急着上复杂架构。先用一个模型同时处理文本和图片，跑通一条最简单的业务链路，比如“读图提取信息，再写一段报告”，感受一下多模态模型的实际边界。Agent也同理，先给模型接一个工具，比如搜索引擎API，做一个小而完整的“查资料-总结-回复”闭环，你会发现比一开始就设计多Agent协作框架可靠得多。

第四，别忘了关注嵌入式和大模型结合的方向。很多人对“嵌入式开发最好的大模型是哪一家”这个问题感兴趣，我的看法是，嵌入式场景更看重模型的小尺寸、低延迟、离线运行能力，所以参数量集中在1B以下的小模型，配合量化部署才是主线。大模型在边缘设备上跑，核心不是追求能力最强，而是追求在有限资源下完成任务不掉链子。

我自己做这个领域最大的体会，是不要被“发展史”这个词吓住。大模型的历史短到今天最主流的架构依然是2017年那篇Transformer，你完全可以在短时间里把这条脉络梳理清楚，然后迅速转入实践。学历史不是用来背时间点的，是让你在每一次选型、踩坑、排查的时候，知道自己站在哪一步，前面还有哪条路能走。希望这份学习笔记能帮你少走一点我走过的弯路。