大模型系统入门：从预训练到微调部署与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是Billion7B就是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你只需要几行代码就能把全球最顶级的大模型能力接入到你的系统里按量付费不用关心硬件也不用关心模型更新。那什么时候必须走本地部署呢我总结了三类典型场景数据敏感型。比如医院、银行、军工单位的内部知识库问答数据不能出内网那就只能在内部服务器上部署开源模型。成本敏感型。如果业务场景是高并发、海量调用比如每天千万次级别的文本分类、信息抽取用商用API的费用可能远超自建集群的TCO总体拥有成本。需要深度定制的场景。你要微调模型让它学会你们行业的黑话和业务逻辑这时候只有开源模型的权重才能做微调API模型通常不开放权重。参数规模怎么选呢我个人的经验是7B到14B级别的模型配合量化技术可以在单卡24GB显存左右上跑日报级别的文本处理、简单的代码辅助完全够用32B到70B级别的模型能获得接近商用大模型的体验但硬件要求陡然上升到多卡120B以上的模型普通团队基本不建议碰部署运维成本和交互延迟都太高了。对初学者来说从7B或14B的Qwen、Llama系列开始动手是性价比最高的路径。3. 环境搭建与本地部署实战3.1 硬件要求与量化你的显卡到底够不够开始动手之前你先得确认自己手里的硬件能干什么。“大模型部署”的第一道坎永远是显存。推理一个模型至少需要把模型参数全部载入显存以FP16半精度来算7B参数就是大约14GB的权重加上KV Cache和一些中间计算量你至少要有20GB左右的显存才能跑得比较流畅。如果你的显卡是RTX 409024GB那恭喜你7B模型随便跑。如果你是RTX 309024GB、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纯CPU/低端GPU环境极轻量、无GPU也能跑、支持GGUF高并发能力一般GPU利用率不高Ollama本地个人日常使用一条命令启动、内置模型库丰富、给开发者提供了OpenAI兼容API自定义部署选项少底层细节被隐藏vLLM生产环境高并发PagedAttention极快、吞吐量高、兼容OpenAI API格式需要较大显存、配置门槛稍高LM Studio小白图形界面开箱即用、GUI操作、支持聊天和API服务不适合服务化部署TGI / Triton规模化生产企业级功能齐全支持多模型管理运维复杂度高llama.cpp是爱好者体验者最喜欢的工具它的核心优化是使用了GGUF格式的量化模型对CPU做了深度优化即使你只有一台16GB内存的笔记本电脑也能跑7B量化模型。常用于快速验证、个人终端使用。Ollama是目前个人电脑里跑大模型最顺手的方案。你安装完成后一行命令ollama run qwen2.5:7b就能把模型下载并跑起来。Ollama还自带了一个OpenAI兼容的APIhttp://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显卡一天烧掉的电费都是普通人一个月的工资。于是就有了参数高效微调技术其中最出名的就是LoRALow-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模型在特定任务上的表现调理得很好。当然工业级落地最好有上万条覆盖各种边界情况的高质量数据。数据质量的标准是让模型学你想要的逻辑而不是重复的废话。然后写训练脚本典型框架是transformerspeftbitsandbytespip 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_4bitTrue, device_mapauto, ) model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_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。提示词工程的实操要诀我总结为四步角色设定告诉模型你是谁、你要干什么。“你是资深的前端架构师请用简洁的中文给出代码评审意见”比直接一句“帮我评审代码”要靠谱得多。任务明确把你要的结果描述得非常具体。“从以下内容中找出所有的公司名称、人名和金额并输出为JSON格式不要输出其他任何文字”。越具体输出越可控。给出格式约束如果你要的是结构化输出就用框架或者指定例子。提供输入材料把相关知识、背景放进提示词的“上下文区”。很多人忽视上下文工程Context Engineering但这一步在实际应用中非常重要。你要做公司的知识库问答通常的套路是先把大量文档切成小段做嵌入Embedding向量化建一个向量数据库用户提问时先用向量检索找到最相关的几段文档再把用户问题和这几段文档拼起来喂给大模型。这个架构叫作RAGRetrieval-Augmented Generation检索增强生成这是当前大模型落地应用里工程含金量最高、也是见效最快的路径。5.2 流式输出与SSE让AI说话不打嗝大模型推理的速度再快一次生成几百个字也需要几秒钟时间。如果你让用户等待全部生成完再显示体验会非常糟糕。解决这个问题的方法就是**SSEServer-Sent Events服务器推送事件**配合大模型的流式输出。流式输出的原理其实很直接模型不是一口气生成完整答案而是每次生成一个Token或一小段文字就立刻推给前端。在HTTP层面服务端返回的Content-Type是text/event-stream按一定的格式不断把新的数据分块发送给浏览器。前端用EventSource或者fetch接口分段读取实时渲染这样用户就能看到文字一个个蹦出来的效果体感上非常流畅、自然。前后端的协作方式是前端发请求时后端拿着用户的请求调用大模型的streamTrue参数逐段拿结果并通过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, }, timeout60, ) as resp: async for line in resp.aiter_lines(): if line.startswith(data: ): yield line[6:] \n\n return StreamingResponse(event_stream(), media_typetext/event-stream)5.3 Agent框架与多模态大模型从聊天到动手只会聊天的模型价值天花板有限。现在主流的应用形态已经从简单的“问答”晋级为“智能体Agent”——让大模型不仅仅是回答问题还能自主地规划任务、调用工具、操作软件完成一整个复杂的流程。你现在看到的“旅游推荐智能体”背后就是一个会搜索天气、查酒店、查交通路线、再聚合生成行程规划的系统。目前主流的Agent框架我推荐关注这几个LangChain生态最丰富文档多但抽象层次多LangGraph由LangChain推出的图状态机框架适合做有复杂状态流和分支判断的AgentAutoGPT老牌全自动任务框架以及国产的MetaGPT、Dify、FastGPT、Coze扣子。如果你问我个人最新的偏好我建议做生产级项目优先关注LangGraph和Dify前者适合喜欢用代码控制全部细节的工程师后者适合快速搭建多模型工作流的团队。多模态大模型这个概念也值得提一笔。现在的模型不止能吃文本还能吃图片、音频甚至视频。如果你想给产品加“识图”能力最简单的方式是直接用支持图像输入的多模态模型API如果你要本地部署像Qwen2-VL、Llama 3.2 Vision这些都可以考虑。多模态的应用范围比纯文本广很多拍照抄表、识别手写票据、分析股票K线截图、视频内容理解都是可以做的。6. 大模型系统学习路线与避坑指南6.1 三个月入门路线规划总有人问我系统性入门大模型到底要多久、怎么安排。我给一个我认为最合理的三个月规划路线阶段时间核心任务参考路径第一阶段第1-2周理论奠基理解预训练/微调、Token、注意力机制等核心概念不用钻数学推导但要看懂模型输入输出的流转过程第二阶段第3-4周动手部署用Ollama在本地跑起Qwen2.5-7B、Llama 3.1理解GGUF量化和模型参数在本地如何加载试过llama.cpp命令行和OpenAI兼容API调用第三阶段第5-6周API应用开发熟悉OpenAI官方SDK掌握提示词工程完成一个基于大模型API的小型聊天应用学会用SSE流式渲染回答第四阶段第7-8周RAG与Agent实现一个带本地知识库的RAG问答应用体验LangChain/LangGraph的Agent编排理解向量数据库、Embedding、检索策略第五阶段第9-10周微调实战用QLoRA微调自己的7B模型掌握LoRA的配置、训练、合并、测试全流程第六阶段第11-12周综合项目找一个真实业务场景做端到端落地微调部署vLLMAgent/RAG前端集成这套路线里最核心的原则是“先跑起来再深入”。很多人的毛病是在理论上死磕了一个月模型一次都没跑过最后热情被消磨光了。其实你应该第一天就搭好环境哪怕只是让模型输出一句“你好”这种正反馈能帮你走完后面枯燥的细节学习。6.2 常见问题与排查技巧实录我在带新人做部署和微调时几乎每天都会遇到重复的问题整理成长表格直接给你抄作业问题现象核心原因解决方案启动时CUDA Out of Memory模型权重大于显存或KV Cache分配过多换更小量化级别的GGUF模型q4→q2、降低max_length、开启流式输出后减小batch_size、用多卡张量并行CPU推理极慢内存带宽不足或模型未正确AVX优化确认llama.cpp编译时开了AVX2/FMA尽量用GPU减小上下文长度模型说中文夹杂英文/胡说八道基座模型中文质量不够或 prompts 没有强调中文优先用Qwen这类中文语料充足的模型提示词里加“请始终使用简体中文回答”微调损失下降但效果反而变差数据质量差或学习率过大导致灾难性遗忘精简数据量、提高数据多样性、学习率降到5e-5左右、Warmup比例提高、LoRA的r值从16降到8生成的JSON不稳定模型输出飘不遵守格式规范用response_format强制JSON、few-shot示例给足、推理温度降到0.2以下SSE前端不渲染后端不是在切分Token而是缓存全部才发送前端用fetch读取ReadableStream后端必须逐段flush长文档问答总是漏中间信息模型对长上下文注意力偏弱把文档做RAG分块检索只给模型喂最相关的2-3段而不是把所有内容全塞给它显存还有剩余但推理速度上不去可能瓶在CPU与GPU之间的传输或未并发调度上vLLM的continuous batching合理配置max_num_seqs6.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好厉害”升级到了“知道它哪里强、哪里弱、怎么驾驭它”这时候你就不再是一个看客而是一个真正能动手的工程师了。之后如果你在做具体项目时踩到什么新的坑或者搞出了什么有意思的玩法欢迎随时来交流。这条路很长但关键是先动起来。