大模型系统入门：从预训练到微调部署与RAG应用实战

从去年开始，大模型这个词几乎是无处不在了。作为一个在这行摸爬滚打了好几年的开发者，我经常收到一类私信，大意都是说“我是零基础/半路出家，想系统性入门大模型，到底该从哪里开始？”说实话，市面上的教程和资料实在是太多了，但大部分要么是纯理论讲Transformer、注意力机制，看完依然不知道怎么能跑起来一个模型；要么就是教你怎么调API，五分钟就能跟ChatGPT对话，但这种“会用”其实离真正理解大模型还很远。

这篇系统性入门资料，是我结合了自己从跑通第一个模型到做微调、再到开发完整应用这几年的真实经验整理出来的。这篇内容会覆盖大模型的理论基础、主流模型选型、本地部署实战、微调实操、应用开发以及完整的学习路线，适合所有想认真进入这个领域的开发者和学生。我不会只讲概念，我会告诉你每一步为什么要这么做、有哪些坑要注意，以及怎么一步步从零把这件事做出来。

1. 先搞清楚大模型到底是啥

1.1 从“预训练+微调”的范式说起

很多初学者一上来就抱着Transformer论文啃，啃到Q、K、V注意力公式就被劝退了。我的建议是第一遍完全不用死磕数学原理，你先抓住一个核心范式：预训练（Pre-training）加微调（Fine-tuning）。

预训练是什么意思呢？你可以把大模型想象成一个小孩子，它先读了一个天文数字级别的书籍、网页、代码，读了好几轮之后，它就学会了语言的语法、常识、逻辑推理能力以及海量的知识。这个过程在大模型的语境里叫预训练，它非常消耗算力，OpenAI训练GPT-4级别的模型要烧掉数千万美元，这也就是为什么普通人不需要关心预训练，我们直接使用已经训练好的模型就行。

但这个读过万卷书的小孩子并不是一个完美的工作者。你问他“帮我写段Python代码实现快速排序”，他可能能写出来，但他不知道你的项目规范、不知道你公司的代码风格、也不知道你要用在什么业务场景里。这时候就需要微调了。微调就是拿一批你希望模型学会的特定数据，比如“问题-标准答案”对，让模型在这个基础上再学一遍。这样一来，模型在特定领域（比如客服、法律咨询、医疗问答）的表现就会显著提升。

理解了预训练和微调的区别，你就会明白为什么现在行业里有那么多模型——大家都用开源的大模型底座，然后在自己的场景数据上做微调，得到一个属于自己的行业模型。这就是业界常说的“基座模型+领域微调”，也是目前大模型落地最常见的方式。

1.2 Token、参数量、上下文长度这几个关键概念

要跟大模型愉快地玩耍，有几个基础概念必须搞清楚，不然看文章都是云里雾里的。

第一个是Token。大模型不是按字来读文本的，而是按Token来读。一个Token大约对应0.5到1个汉字，英文的话一个单词大概对应1到1.5个Token。这个概念的实操意义在于：模型的计费（API调用按Token计费）、上下文窗口限制（一次能处理多少内容）、以及推理速度都跟你输入和输出的Token总量直接挂钩。你的提示词写得又臭又长，不仅花钱多，响应还会变慢。

第二个是参数量（Parameters）。像7B、13B、70B这样的数字，B是Billion，7B就是70亿参数。参数是做数学运算的时候存储下来的一堆权重数字，参数量越大，通常代表模型的“容量”越大、知识越丰富、推理能力越强，但同时它占用的显存和计算资源也越大，推理速度也越慢。7B模型在普通的消费级显卡（比如NVIDIA的RTX 4090）上就能跑，70B模型则通常需要多张高端服务器显卡（比如A100、H100）才能跑得动。

第三个是上下文长度（Context Window）。Qwen2.5系列可以支持128K的上下文，这意味着你一次可以给它塞一本接近十万字的文档进去。别以为这个能力没啥用，在实际开发场景里，你给模型的提示词可能自带几百KB的检索内容，上下文长了才能处理复杂任务。但是请注意，上下文越长，计算量越大，推理耗时也会明显增加，而且模型对长上下文中间部分的内容经常“记性不太好”，学术上称为“迷失在中间”，这一点在应用设计时要想办法规避。

2. 大模型版图：主流模型怎么选

2.1 全球知名大模型：闭源与开源之争

从2022年底ChatGPT发布之后，全球的大模型生态就像春节的烟花爆竹一样，一下子炸开了。现在市面上的模型基本可以分为两大阵营：闭源商用和开源社区。

闭源阵营里最有名的是OpenAI的GPT系列（GPT-3.5、GPT-4、GPT-4o系列），它是在线API调用最有名的服务。然后是Anthropic的Claude系列，写长文、做代码分析时很多人更喜欢它，因为它的上下文窗口很长、写作风格更自然。Google的多模态开源王炸是Gemini系列，原生就能同时处理文本、图像、音频。以及年初爆火的DeepSeek系列（我经常拿它的API做开发，性价比高、推理能力强），还有国内的文心一言、通义千问、Kimi（月之暗面）、智谱清言等，这些都是在API能力上很能打的选手。

开源阵营则是另一番风景。Meta开源的Llama系列（最新到Llama 3.1）和国内的Qwen系列（通义千问开源版）是最多人用来本地部署的底座。Mistral AI在欧洲推出了性能强悍的Mistral和Mixtral系列，Qwen2.5-7B更新之后在中文能力上表现非常突出，实际测试过中文阅读理解、代码生成，都比我预期好不少。开源的重大意义在于：你不需要向任何人支付API费用，数据也可以留在自己的服务器上，还能自己做微调，真正地把模型拿在自己手里。

2.2 选型建议：什么时候用API，什么时候本地部署

绝大多数公司的第一选择应该是用API，而不是自己部署。原因很简单：自建大模型推理服务涉及显卡采购、环境配置、性能调优、高可用保障、容量规划，这每一件事都是实打实的钱和工程时间。而用API，你只需要几行代码就能把全球最顶级的大模型能力接入到你的系统里，按量付费，不用关心硬件，也不用关心模型更新。

那什么时候必须走本地部署呢？我总结了三类典型场景：

1. 数据敏感型。比如医院、银行、军工单位的内部知识库问答，数据不能出内网，那就只能在内部服务器上部署开源模型。
2. 成本敏感型。如果业务场景是高并发、海量调用，比如每天千万次级别的文本分类、信息抽取，用商用API的费用可能远超自建集群的TCO（总体拥有成本）。
3. 需要深度定制的场景。你要微调模型让它学会你们行业的黑话和业务逻辑，这时候只有开源模型的权重才能做微调，API模型通常不开放权重。

参数规模怎么选呢？我个人的经验是：7B到14B级别的模型配合量化技术可以在单卡（24GB显存左右）上跑，日报级别的文本处理、简单的代码辅助完全够用；32B到70B级别的模型能获得接近商用大模型的体验，但硬件要求陡然上升到多卡；120B以上的模型普通团队基本不建议碰，部署运维成本和交互延迟都太高了。对初学者来说，从7B或14B的Qwen、Llama系列开始动手，是性价比最高的路径。

3. 环境搭建与本地部署实战

3.1 硬件要求与量化：你的显卡到底够不够

开始动手之前，你先得确认自己手里的硬件能干什么。“大模型部署”的第一道坎永远是显存。推理一个模型至少需要把模型参数全部载入显存，以FP16（半精度）来算，7B参数就是大约14GB的权重，加上KV Cache和一些中间计算量，你至少要有20GB左右的显存才能跑得比较流畅。

如果你的显卡是RTX 4090（24GB），那恭喜你，7B模型随便跑。如果你是RTX 3090（24GB）、RTX 4080、A4000这些显卡，也可以尝试。如果你的显卡只有8GB或更少，比如RTX 3070 Laptop、GTX 1660这些，那就需要用到量化技术了。

量化说白了就是给模型参数“减重”。原本一个参数用16位浮点数（FP16）存储，现在压缩成8位整数（INT8）或者4位整数（INT4），模型体积直接缩到原来的二分之一或四分之一。效果会有一定的损失，尤其是复杂度较高的推理任务上能感觉到变笨了一点点，但对于绝大多数生成任务，4位量化后的7B模型在消费级显卡上完全可用。

这里必须提一下GGUF这个文件格式，它是 llama.cpp 项目专用的量化模型文件格式。你从Hugging Face或者ModelScope（国内下载速度快很多）下载到的模型经常会看到q4_K_M.gguf、q5_K_M.gguf这样的文件名，q4就是4位量化，q5就是5位量化，后面的K_M表示具体的量化策略。通常我推荐 q4_K_M 或 q5_K_M，它们是综合了体积、速度和效果的甜点位。

3.2 五种部署方式的实操选型

大模型的本地部署有多种工具，不同工具对应不同的场景，我把主流的方案对比一下：

llama.cpp是爱好者体验者最喜欢的工具，它的核心优化是使用了GGUF格式的量化模型，对CPU做了深度优化，即使你只有一台16GB内存的笔记本电脑也能跑7B量化模型。常用于快速验证、个人终端使用。

Ollama是目前个人电脑里跑大模型最顺手的方案。你安装完成后一行命令ollama run qwen2.5:7b就能把模型下载并跑起来。Ollama还自带了一个OpenAI兼容的API（http://localhost:11434/v1），这意味着你写代码的时候可以沿用请求OpenAI接口的方式，只需修改API的base_url，这给个人电脑智能化开发带来了极大的便利。

vLLM是生产环境部署的首选。它最核心的技术是PagedAttention，这是借鉴操作系统虚拟内存的分页管理思想来管理推理时的KV Cache，能显著提升显存利用率和吞吐量。如果你的任务是给公司做一个内部问答系统，需要接受大量并发请求，那我建议直接上vLLM。

在本地跑出效果之后，想接API却不想被厂商绑定，你可以在局域网里起一个支持OpenAI协议的服务，前端、后端开发团队就可以把它当成一个“免费的OpenAI API”来调，这也是很多公司内部实验的常用套路。

4. 微调实战：让模型说行业话

4.1 微调的原理：为什么LoRA成了主流

很多人天真地以为微调就是把随便找的一堆文本丢给模型训练，让它“记住”这些知识。这是错的，至少是不全面的。微调的核心不是让它记住新事实，而是让它学会特定的输出格式、回答风格和指令遵循能力。当然，如果你有特别高质量的业务问答对，它也能在一定程度上学到领域知识。

全量微调（Full Fine-tuning）会更新模型的所有参数，对硬件要求极高。32B模型做全量微调，动辄需要好几张A100显卡，一天烧掉的电费都是普通人一个月的工资。于是就有了参数高效微调技术，其中最出名的就是LoRA（Low-Rank Adaptation，低秩适配）。

LoRA的原理做个小类比：你不需要重新给一整个图书馆里的每本书改了重印，你只需要制作一份“修正目录”，注明哪里要补哪里要改。LoRA就是在原始模型权重旁边增加了一小批可训练的小矩阵，训练时只更新这些小矩阵。训练完成后，你得到的是一个几十MB到几百MB的LoRA权重文件，使用时要把它加载到基础模型之上，这就是“合并”的过程。所以LoRA权重不能独立使用，必须配合对应的基座模型。

QLoRA则是更进一步，它允许你在4位量化后的模型上做LoRA训练，显存占用直接降一个数量级。我亲测用QLoRA微调一个7B模型，显存占用不到10GB，一张消费级显卡就能完成训练流程，这对预算有限的个人和小团队来说是天大的利好。

4.2 Qwen2.5-7B微调全流程实录

这里我以 Qwen2.5-7B-Instruct 微调为例，把我实际操作过的流程完整地呈现出来。环境默认是Ubuntu 22.04 + CUDA 12.1 + Python 3.10 + 单张24GB显存的显卡。

先准备好训练数据。微调数据的格式可以根据你用的训练框架略有不同，但最通用的是构建一个JSONL文件，每一行形如：

{"instruction": "什么是学习率？", "output": "学习率是深度学习训练中控制参数更新步长的超参数..."}

如果你想分轮次对话，还可以加一个input字段（通常用于输入额外上下文）。但作为第一版，建议先从“指令-输出”这种最干净的QA对开始。数据量上也别迷信越大越好，我见过有人只用500条高质量数据就把7B模型在特定任务上的表现调理得很好。当然，工业级落地最好有上万条覆盖各种边界情况的高质量数据。数据质量的标准是：让模型学你想要的逻辑，而不是重复的废话。

然后写训练脚本，典型框架是transformers+peft+bitsandbytes：

pip install transformers peft bitsandbytes accelerate datasets

训练脚本的关键配置如下：

from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", load_in_4bit=True, device_map="auto", ) model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.1, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config)

这里的几个关键参数我说明一下。**r（秩）**是LoRA矩阵的维度，r越大可学信息越多但也不一定就好，32或64甚至破百是常见尝试；lora_alpha是放缩参数，通常定义为r的2倍左右；target_modules要针对Qwen的解码层中的注意力投影模块来设置。训练时建议使用学习率2e-4到1e-5之间，批量大小看显存调整，用梯度累积保持全局batch size在16到64之间。

训练完成之后，LoRA权重会活在输出目录里。如果你需要合并成完整的微调模型，可以这样操作：

from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") lora_model = PeftModel.from_pretrained(base_model, "./lora_output") merged_model = lora_model.merge_and_unload() merged_model.save_pretrained("./merged_model")

最后再用一行标注语言类型的代码测试效果：

pipe = pipeline("text-generation", model="./merged_model", tokenizer="./merged_model")

微调之后的模型在特定风格或者专业术语上确实会有明显改善，但也要有心理预期，不要期望微调能让模型凭空学会它基座里完全不懂的领域知识。基座模型的知识上限决定了微调的天花板，微调只是让模型在特定方向上表现更稳定。

5. 应用层开发：从模型能力到产品体验

5.1 提示词工程与上下文工程

当模型能跑通之后，你马上就会发现：模型好不好用，很大程度上取决于你怎么“指挥”它。这里就遇到了近两年最火的概念——提示词工程（Prompt Engineering）和上下文工程（Context Engineering）。

提示词工程的实操要诀，我总结为四步：

1. 角色设定：告诉模型你是谁、你要干什么。“你是资深的前端架构师，请用简洁的中文给出代码评审意见”比直接一句“帮我评审代码”要靠谱得多。
2. 任务明确：把你要的结果描述得非常具体。“从以下内容中找出所有的公司名称、人名和金额，并输出为JSON格式，不要输出其他任何文字”。越具体，输出越可控。
3. 给出格式约束：如果你要的是结构化输出，就用框架或者指定例子。
4. 提供输入材料：把相关知识、背景放进提示词的“上下文区”。

很多人忽视上下文工程（Context Engineering），但这一步在实际应用中非常重要。你要做公司的知识库问答，通常的套路是先把大量文档切成小段，做嵌入（Embedding）向量化，建一个向量数据库，用户提问时先用向量检索找到最相关的几段文档，再把用户问题和这几段文档拼起来喂给大模型。这个架构叫作RAG（Retrieval-Augmented Generation，检索增强生成），这是当前大模型落地应用里工程含金量最高、也是见效最快的路径。

5.2 流式输出与SSE：让AI说话不打嗝

大模型推理的速度再快，一次生成几百个字也需要几秒钟时间。如果你让用户等待全部生成完再显示，体验会非常糟糕。解决这个问题的方法就是**SSE（Server-Sent Events，服务器推送事件）**配合大模型的流式输出。

流式输出的原理其实很直接：模型不是一口气生成完整答案，而是每次生成一个Token或一小段文字就立刻推给前端。在HTTP层面，服务端返回的Content-Type是text/event-stream，按一定的格式不断把新的数据分块发送给浏览器。前端用EventSource或者fetch接口分段读取实时渲染，这样用户就能看到文字一个个蹦出来的效果，体感上非常流畅、自然。

前后端的协作方式是：前端发请求时，后端拿着用户的请求调用大模型的stream=True参数，逐段拿结果并通过SSE推回去。有一个小技巧是，当用户觉得生成结果不满意时，要能立刻停止生成，这时要配合前端的AbortController中断请求。否则明明用户已经点了“停止”，后端还在继续消耗你的API额度疯狂生成，体验很糟。实测下来，这个组合是开发AI应用聊天对话时最常用的标准动作。

这里我写一个最简化的后端采集流式数据并转发给前端的示例：

from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app = FastAPI() @app.post("/chat") async def chat(req: Request): payload = await req.json() async def event_stream(): async with httpx.AsyncClient() as client: async with client.stream( "POST", "https://api.example.com/v1/chat/completions", json={ "model": "qwen2.5", "messages": payload["messages"], "stream": True, }, timeout=60, ) as resp: async for line in resp.aiter_lines(): if line.startswith("data: "): yield line[6:] + "\n\n" return StreamingResponse(event_stream(), media_type="text/event-stream")

5.3 Agent框架与多模态：大模型从聊天到动手

只会聊天的模型，价值天花板有限。现在主流的应用形态已经从简单的“问答”晋级为“智能体（Agent）”——让大模型不仅仅是回答问题，还能自主地规划任务、调用工具、操作软件，完成一整个复杂的流程。你现在看到的“旅游推荐智能体”，背后就是一个会搜索天气、查酒店、查交通路线、再聚合生成行程规划的系统。

目前主流的Agent框架我推荐关注这几个：LangChain（生态最丰富，文档多但抽象层次多），LangGraph（由LangChain推出的图状态机框架，适合做有复杂状态流和分支判断的Agent），AutoGPT（老牌全自动任务框架），以及国产的MetaGPT、Dify、FastGPT、Coze（扣子）。如果你问我个人最新的偏好，我建议做生产级项目优先关注LangGraph和Dify，前者适合喜欢用代码控制全部细节的工程师，后者适合快速搭建多模型工作流的团队。

多模态大模型这个概念也值得提一笔。现在的模型不止能吃文本，还能吃图片、音频甚至视频。如果你想给产品加“识图”能力，最简单的方式是直接用支持图像输入的多模态模型API；如果你要本地部署，像Qwen2-VL、Llama 3.2 Vision这些都可以考虑。多模态的应用范围比纯文本广很多：拍照抄表、识别手写票据、分析股票K线截图、视频内容理解，都是可以做的。

6. 大模型系统学习路线与避坑指南

6.1 三个月入门路线规划

总有人问我系统性入门大模型到底要多久、怎么安排。我给一个我认为最合理的三个月规划路线：

这套路线里最核心的原则是“先跑起来再深入”。很多人的毛病是在理论上死磕了一个月，模型一次都没跑过，最后热情被消磨光了。其实你应该第一天就搭好环境，哪怕只是让模型输出一句“你好”，这种正反馈能帮你走完后面枯燥的细节学习。

6.2 常见问题与排查技巧实录

我在带新人做部署和微调时，几乎每天都会遇到重复的问题，整理成长表格直接给你抄作业：

6.3 行业避坑心得：这些弯路你别走

第一，不要在低硬件上死磕中大模型。我在8GB显存的笔记本上的第一次体验是惨痛的，硬跑13B量化模型，生成一句话要一分钟，体验基本没法用。如果你没有好显卡，老老实实先用API，先把应用逻辑跑通，再安排预算买硬件。

第二，不要迷信“模型排名”。大模型评测榜单的分数上下波动非常快，同一个模型在不同评测集上的名次可能天差地别。选模型最靠谱的方法是自己建一个和你业务尽量相似的测试集，里面包含几十条真实业务问题，逐个对比输出质量。我见过团队因为盲目追榜单换了三次底座，最后发现还是原配模型最合适。

第三，不要跳过评估环节。无论是微调还是RAG，上线前一定要建立评估（Evaluation）机制。光看几个例子觉得“不错哦”是不可靠的。简单靠谱的做法是拿几十条标准QA做回归测试，把模型输出和标准答案放在一起打分（可以请GPT-4当裁判来打分，简称LLM-as-a-Judge），只有量化对比之后你才知道版本迭代到底是在变好还是在变坏。

第四，RAG里检索不要小看Embedding模型的选择。国内做中文应用，直接用开源的bge系列中文Embedding模型，不要拍脑袋用什么通用模型。另外向量检索的召回，通常先用比较高的召回数量（比如20条），再靠重排（Rerank）模型把最相关的三条挑出来。初学阶段做RAG就出了问题，我排查来排查去，最后发现是Embedding质量太低导致召回的相关内容根本不对。

7. 写在最后：动手才是最快的入门方式

按惯例聊到最后一节了，分享一点我个人在带学生、带团队时最深的一个体会：大模型入门最稀缺的不是资料，而是完成一轮动手闭环的耐心。

理论、教程、博客固然重要，但只有你自己亲手配置一次环境，下载一个模型，观察GPU显存的占用，设计一个prompt，调试一段流式输出的代码，甚至踩一次微调loss崩掉的坑，你才真正在大模型这个行业里“上了船”。很多人收藏了无数份学习资料，最后依然停在了“看过很多原理，但从未真正运行过一个模型”的阶段，这是最可惜的。

我的建议简单粗暴：今天别再看论文了，先把Ollama装上，跑起一个模型，让它回答你一个认真构思的问题。然后明天再回来把这篇资料里的部署、微调、RAG、Agent一步步走完。等你把这些都亲手过一遍，你会发现自己对大模型的认知已经从“发朋友圈惊叹AI好厉害”升级到了“知道它哪里强、哪里弱、怎么驾驭它”，这时候你就不再是一个看客，而是一个真正能动手的工程师了。

之后如果你在做具体项目时踩到什么新的坑，或者搞出了什么有意思的玩法，欢迎随时来交流。这条路很长，但关键是：先动起来。