大模型入门路线：从部署到微调、RAG与Agent的务实指南

从零开始建立大模型知识体系一份务实到不废话的入门路线身边越来越多朋友问我同一个问题我想系统性入门大模型该从哪开始问的人里有做后端开发的、有做数据分析的、有产品经理甚至还有搞传统工业质检的工程师。他们通常已经看过一堆公众号文章、刷过几个视频但知识停留在“Transformer很厉害”“ChatGPT很牛”这种层面真正面对“该怎么学”“学到什么程度算入门”“本地能跑什么模型”这些问题时还是懵的。我自己从最开始跑通一个7B模型到在公司落地私有化部署中间踩过的坑可以写满一个备忘录。所以这篇我就把当年希望有人直接告诉我的东西整理出来结合大模型学习路线里的那些热搜词从原理、选型、微调、部署、应用五条线展开。不灌鸡汤不讲虚的每条都对应能实操的内容。1. 先把大模型的基本盘搞清楚它到底是什么很多人学大模型有一个误区上来就去念Transformer论文读了两页被注意力机制劝退。这没必要。入门阶段你需要的是先建立正确的物理直觉——知道它是什么、能干什么、边界在哪里然后再去碰原理。1.1 大模型的定义、核心能力与能力边界大模型全称大语言模型Large Language Model, LLM本质是基于海量文本训练出来的概率模型核心任务只有一个根据上文预测下一个最可能出现的词token。听起来简单但当参数量达到数十亿、训练数据覆盖几乎整个互联网文本之后涌现出对话、翻译、总结、代码生成、逻辑推理这些能力。这就像一个小孩子不是有人逐条教他语法规则才学会说话而是在大量语言环境中听多了自然就会表达。大模型也一样它是“泡”在数据里泡出来的语言能力。但必须认清能力边界。大模型本质是“接着编”所以存在幻觉问题——它不知道答案时会一本正经胡说八道它也没有真正的实时知识训练时世界是什么样它的知识就停留在那个时间点这就是为什么用得配合检索或者联网它的数学计算能力不是绝对精确复杂计算经常出错。理解这些边界极其重要因为这直接决定了后面你会选择什么样的技术方案比如要不要引入RAG要不要做微调或者只是提示词工程就够了。1.2 预训练、微调、推理三者之间的关系系统入门大模型必须先理清这个大框架。整个大模型生态实际上分三层预训练用海量文本从头训练一个大模型成本极高通常需要几千张GPU跑几周甚至几个月花费数百万美金。这是大厂玩的游戏绝大多数人不需要碰知道怎么回事即可。微调在预训练好的基座模型基础上用特定领域的数据继续训练让模型适应你的业务风格和格式是我们普通人真正要关注的重点。推理用训练好的模型回答问题的过程也就是部署和调用。推理是离我们日常最近的环节无论是API调用还是本地部署都属于这个环节。像我接触大模型学习路线上不少朋友一上来就想自己做预训练这就像刚学会骑车就想参加环法方向本身就偏了。正确的精力分配应该是理解预训练原理掌握微调技能熟练部署推理最后学会结合应用场景设计系统。1.3 常见大模型系列与各自血统现在市面上的大模型非常多新手经常被各种名字绕晕。我这里按照“血统”梳理一下主流系列方便你建立索引系列代表模型特点与适用场景GPT系列GPT-4o、GPT-4.1综合能力最强API稳定适合做应用层创业Llama系列Llama 2、Llama 3、Llama 3.1开源生态最繁荣社区支持好适合本地部署与微调学习千问系列Qwen2.5、Qwen2.5-Coder中文能力强有不同尺寸版本国内用户友好DeepSeek系列DeepSeek-V3、R1推理能力强数学代码表现出色性价比高视觉多模态LLaVA、Qwen-VL、InternVL支持图像输入适合做OCR、图像理解类应用对入门者我强烈建议从Qwen或Llama的开源版本入手。为什么因为开源模型你能拿到权重文件可以真正在本地跑起来观察它的行为出了问题能查代码、看日志而API调用就像一个黑盒你输入输出中间发生什么完全看不到。2. 本地部署拥有一台真正属于自己的大模型学习大模型最好最快的方式不是天天调API而是在本地实实在在跑通一个模型。本地部署的意义不只是省钱——它意味着你拥有了一个不受网络限制、数据不出内网、可以自由魔改的模型环境。2.1 硬件选型CPU还是GPU显存要多大可能有人跟你说没有4090就学不了大模型这个说法过于绝对了。我的实测经验是纯CPU推理跑1.5B到3B的小模型速度虽然慢但能跑。我拿一台普通的i5笔记本试过Qwen2.5-1.5B的量化版生成速度大概在每秒8到10个token简单对话完全够用。GPU推理显存决定了你能跑多大的模型。一个关键的估算公式是模型权重显存占用约等于参数量乘以每参数字节数。以7B模型为例FP16精度下约需14GB显存4bit量化后约3.5GB到4GB。所以8GB显存的显卡就能跑7B量化模型24GB的显卡可以跑14B甚至更大的量化模型。我做了一张选型速查表当初给公司做部署评估时就是按这个逻辑算的目标模型规模最低显存要求(4bit量化)推荐GPU1.5B-3B4GBGTX 1650及以上7B-8B8GBRTX 3060 12G/4060Ti 16G14B16GBRTX 4080/409032B以上24GB以上4090或A系列/多卡并行注意苹果M系列芯片的Mac也很适合跑中小模型统一内存架构让CPU和GPU共享内存M1 Pro 16G就能流畅跑7B量化模型而且功耗低得多。2.2 部署工具对比Ollama、vLLM、llama.cpp各有什么优劣势本地部署工具有很多入门者最常接触的是这三个Ollama目前最傻瓜化的本地部署工具。它把模型下载、运行、API暴露封装成几条命令装完之后一行ollama run qwen2.5:7b就能跑起来。对新手极度友好也是我建议入门首选。llama.cppC实现的推理框架CPU推理效率极高支持各种量化格式主要是GGUF。如果你要在无GPU的服务器上跑模型或者追求极致的CPU性能选它。vLLM推理届的生产级选手。核心优势是PagedAttention技术极大提升吞吐量支持连续批处理非常适合做高并发的线上服务。当你需要给团队提供API服务的时候vLLM几乎是最优选择。怎么选我的建议是个人学习先用Ollama它让你五分钟内看到模型跑起来建立正反馈研究GGUF量化原理去用llama.cpp正式做服务部署直接用vLLM。三者的关系不是替代而是人在不同阶段的需求变化。2.3 Ollama从安装到跑通模型的全过程这里我以Windows 11环境为例完整走一遍流程非常容易复现到Ollama官网下载对应Windows版本安装包也就几十MB装完会在任务栏驻留一个图标。打开命令行终端执行ollama list验证是否安装成功。运行模型ollama run qwen2.5:7b。第一次运行会自动下载权重文件7B模型大概4GB多根据网络情况等一段时间。下载完成后你就有一个可以在终端里对话的大模型了。查看模型信息ollama show qwen2.5:7b查看本地已有模型ollama list删除模型ollama rm。用Ollama部署的模型默认在本地11434端口提供了OpenAI兼容的API接口调用方式为curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}] }这就是本地大模型标准接口意味着你后续用任何支持OpenAI API的客户端包括一些开源的ChatGPT替代界面都可以直接配置这个本地地址。2.4 模型文件格式GGUF、GPTQ、AWQ到底是什么部署时你会遇到各种模型文件后缀把它们看成不同格式的压缩包就好GGUFllama.cpp/Ollama专用格式主要面向CPU和苹果GPU量化支持极好文件后缀通常带Q4_K_M、Q5_K_M之类的标识表示不同的压缩率。GPTQ主要面向GPU在显存占用和推理速度之间平衡得很好适合用auto-gptq或Transformers加载。AWQ也是一种GPU量化格式比GPTQ有更好的激活感知量化策略在相同压缩率下通常精度损失更小。FP16/BF16未量化的原始半精度权重体积最大精度最高是“标准答案”形态其他格式都是从它转换来的。很多初学者搞不清楚这些格式的区别导致下载了GGUF却用Transformers硬加载报错后一头雾水。记住一个匹配口诀Ollama和llama.cpp用GGUFTransformers和vLLM用官方权重或AWQ/GPTQ。3. 微调实战让通用模型变成你的专属模型本地部署解决了“有模型可用”的问题但很多业务场景需要模型“懂你的业务”比如你有一个客服系统希望模型能回答特定产品问题或者你希望模型按照特定格式输出报告。这时候就需要微调了。3.1 什么场景该微调什么场景不该微调这里必须给新手泼盆冷水微调不是万能的而且很多问题根本不需要微调来解决。知识型问题——比如“我们公司的退款政策是什么”应该用RAG检索把文档切片嵌入向量库检索后拼进提示词。微调解决不了知识更新问题也不适合用来灌文档。风格与格式问题——比如“所有回复必须以JSON格式输出”“报告必须是三段式结构”这是微调的强项通过少量数据就能把钱模型的行为习惯掰过来。特定任务能力——比如从法律文书中抽取案件要素、把口语转成工单结构化描述这类任务的输出模式相对固定微调效果非常明显。一句话知识靠检索行为靠微调。搞清楚决策逻辑你就比很多人强了。3.2 LoRA、QLoRA与全量微调参数量与效果的权衡传统微调需要更新整个模型的全部参数7B模型的全量微调光梯度就要几十GB显存个人开发者几乎不可能。所以现在主流是用LoRA低秩适配这类参数高效微调技术。LoRA的原理可以这样理解它不修改原始模型参数而是在模型旁边“并联”一个小型可训练矩阵。就像一个熟练的老会计师改报表不重写整本账本只夹几张便签说明哪些地方要按新规则来。训练结束后你得到的不是新模型而是一个只有几十MB到几百MB的适配器文件。用的时候把LoRA文件叠加到基座模型上模型的行事风格就变了。QLoRA则更进一步它先把基座模型的参数量化到4bit后再做LoRA训练把7B模型的微调显存需求压到个位数GB普通消费级显卡就能战微调。微调方式显存需求(7B模型)训练速度效果适用人群全量微调60GB慢最佳上限有A100/H100的机构LoRA16GB左右中等接近全量24GB显存用户QLoRA6-8GB中等略低于LoRA8-12GB显存用户3.3 数据准备格式规范、质量问题与数据量要求微调是一门“数据为王”的手艺。模型的效果七分靠数据三分靠训练参数。我从实际项目里总结出的经验包括数据格式一般用对话格式包括系统提示词、用户输入、模型回答三段。以最常见的方式为例每一条数据是一个包含system、user、assistant角色的JSON对象数组。数据量很多人问要多少数据。如果你只需要让模型学会一种输出风格几百条高质量数据就有明显效果。要做复杂的下游任务一般建议至少几千条。数据量不是越多越好同质化数据堆到一定程度边际效用会变得很低。数据质量宁可要500条精心清洗的数据也不要5000条有噪声的数据。我见过一个很典型的反例有人用爬虫抓了上万条问答去微调测试时发现模型回答充满了错误格式和重复啰嗦最后删到一千多条人工标注数据反而效果奇佳。多样性要注意让数据覆盖各种边界情况。客服数据里如果全是常规咨询模型遇到投诉场景就会懵。需要专门构造一些边缘case数据比如用户反复追问、用户提供信息不完整等。3.4 用LLaMA-Factory跑通一次QLoRA微调新手微调最友好的工具之一就是LLaMA-Factory它把数据格式处理、训练参数配置、模型导出都封装好了。一次完整的微调流程只需要准备数据文件格式为以下JSON样式[ { conversations: [ {role: system, content: 你是资深的产品推荐助手。}, {role: user, content: 我想买一款适合长时间戴的耳机}, {role: assistant, content: 你主要是在室内还是室外使用} ] } ]启动界面执行CUDA_VISIBLE_DEVICES0 python src/train_webui.py浏览器打开控制台。选择模型名称、LoRA配置训练集设为你的数据文件点击开始训练。训练过程中需要关注两个关键指标loss值下降是否平滑以及过拟合情况。一个实用的判断方法如果训练loss持续下降到0.1以下但测试时模型反而开始重复数据里的原话而不是泛化那就是过拟合了需要减小训练轮数。3.5 微调后评测只看loss就太天真了在实际业务中我强烈建议你要建立一套基于任务的评测集将指标分为两个维度客观指标比如二分类准确率、实体抽取的F1值、JSON格式的可解析率。这些能自动计算适合做回归测试。主观指标比如回答的相关性、语气是否合适、表达是否自然。这些需要人工打分可以以5分制抽样评估。一个非常容易翻车的情况是loss曲线很漂亮但实际回答连格式都变了。为什么因为loss只能反映模型在训练数据上的拟合程度没有任何语义验证能力。训练完务必用一套和训练数据不同分布的测试问题去验证看到真实表现才算数。4. 检索增强生成RAG给模型装一个即时更新的外挂知识库为什么专门讲RAG因为在实际的to B项目里单纯的通用大模型根本无法直接回答问题企业内部的知识库、产品文档、规章制度这些内容模型训练时根本没见过。RAG是解决这类问题最成熟也最轻量的方案。4.1 RAG的工作流程拆解RAG一句话解释就是回答问题前先从知识库里检索相关内容把它作为上下文塞进提示词让模型有据可依地回答。整个链路分为五个环节文档加载与解析把PDF、Word、网页、数据库中的内容读出来。不同格式解析坑很多后面单独讲。文本切片长文档无法直接全部塞进上下文需要切成若干片段常见的策略是固定长度切片比如每512个token一片相邻重叠50个token。向量化把切好的文本片段通过Embedding模型转成高维向量一个切片对应一个向量。存储与索引把向量存入向量数据库如Milvus、Chroma、Weaviate等。检索与生成用户提问时把问题转成向量在库里找最相似的TopK个片段连同用户问题一起提交给大模型生成答案。向量化召回这部分普通人可以做这样一个场景化类比给所有文档做一套“语义索引卡片”然后面对新问题时去卡片柜里找内容最相近的几张。Embedding模型决定了这个“语义相近”的判定准不准后面的生成效果依赖它上游的检索质量。4.2 RAG中常见的失败点切片策略和召回重排初学者做RAG最容易翻车的地方就在切片这一步。我踩过的坑包括切片打断句子固定长度切分经常把一句话切成两半向量化时语义不完整召回效果差。解决办法是采用递归切分器优先按段落切再按句子切最后才按字符兜底。标题信息丢失文档切片后如果没有携带章节标题模型无法区分“2024年销售数据”是哪个事业部的语义就散了。建议切片时把文档的层级标题作为元数据附加到切片内容前面。召回数量不足默认TopK设置为3到5但复杂问题可能涉及多个知识点需要提高TopK或者分多路召回。重排序缺失向量召回的结果是“按相似度排序的”。但相似度高的片段不一定是真正能解答问题的片段。实践中引入一个重排序模型对候选文档打分效果提升明显。在真正的知识问答应用里单纯用向量召回经常不够业界常用“混合检索”向量召回关键词召回BM25双路并行再用重排序模型融合打分。这样可以兼顾语义相关性和字面命中。4.3 完整可跑的RAG项目参考从文档到问答如果你需要一个具体的参考来搭建RAG我整理了简洁的落地路径用LangChain或LlamaIndex做框架选型LangChain生态丰富但接口变动频繁LlamaIndex在RAG场景更专注。文档加载后做递归切片设置chunk_size512, chunk_overlap50。Embedding模型选择方面中文场景推荐BAAI/bge-large-zh或bge-m3英文推荐OpenAI text-embedding-3-small或本地的BAAI/bge-small。向量库选择个人学习用Chroma最简单数据量上去换Milvus。生成模型本地部署用Qwen2.5-7B-InstructAPI用GPT-4o或DeepSeek。整个流程跑通的关键是端到端测试——不是测每一个模块单独工作正常而是要在最终问答效果上验证。建议准备20个业务真实问题作为测试集反复迭代切片参数和检索策略。5. API调用与工程化从“会跑模型”到“建系统”模型能跑、能微调、能检索之后最后一步就是融入真实业务系统。这一步需要转变思维从“研究模型”变成“建立系统”。5.1 OpenAI兼容接口与主流API服务现在几乎所有大模型服务都在兼容OpenAI的API格式这意味着你在任何一套API写好的代码换一个base_url和API key就能切换服务商。这个标准接口的Python调用方式极为简单from openai import OpenAI client OpenAI( api_keysk-xxx, base_urlhttps://api.deepseek.com # 换成openai或本地ollama地址 ) response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 你好}], temperature0.7 ) print(response.choices[0].message.content)当我把这个代码中的base_url换成http://localhost:11434/v1api_key随便填一个占位符时请求就被我本地Ollama跑起来的模型接住了。所以你现在学到的API调用技巧在本地模型和云端模型之间完全通用。5.2 提示词工程与上下文工程区别在哪大模型相关热词里有两个概念很容易混淆提示词工程和上下文工程。提示词工程设计给模型的指令文本让模型更好理解你的意图。基本技巧包括角色设定、少量示例、思维链等。上下文工程管理喂给模型的全部上下文包括检索结果、对话历史、工具返回信息等。它比提示词更宏观“给模型看什么”是上下文工程的核心决策。在实际系统中上下文工程的重要性常常被低估。上下文太长会超限且减慢速度、增加成本上下文太短则丢失关键信息上下文里混杂噪声会引导模型输出偏离。一个非常有效的上下文工程技巧是“结构化提示词模板”。例如做文档问答时我组织上下文的格式是【任务】你是企业制度问答助手请基于给定参考资料回答问题。 【参考资料】开始 按顺序列出检索到的文档片段标注来源编号 【参考资料】结束 【问题】用户问题 【回答要求】如果资料中没有答案请直接说“资料中未找到相关信息”禁止编造。这个模板在多个项目中反复验证过信息结构清晰、角色边界明确、兜底策略具体总体上比你随便把一堆文档塞给模型要可靠得多。5.3 Agent框架选型从单次问答到多步任务当你的需求不再是“回答一个问题”而是“帮我完成一个复杂任务”比如“分析这个Excel文件并生成月报”“自动从官网抓取竞品价格并整理对比表”这时候需要的不只是提示词而是Agent——让模型自主调用工具、规划步骤、串联动作。目前主流的Agent框架有LangChain/LangGraph生态最成熟LangGraph带图结构编排适合有明确状态流的复杂Agent。AutoGen微软出品多Agent对话协作适合需要多个角色分工的方案。MetaGPT多Agent模拟软件开发团队适合代码生成场景。Dify/Coze低代码平台适合业务人员快速搭Agent应用。我的建议是先不要被框架牵着走。先用简单的ReAct模式理解Agent的核心循环——思考Thought→ 行动Action→ 观察Observation→ 再思考自己写一个几十行的Agent循环跑通之后再引入框架。现在主流的Agent工作流里模型只负责“规划”执行靠外部工具。这个工具选择太多反而成为新手的负担建议一开始只接入两个工具一个网络搜索一个本地代码执行环境然后逐步扩展。5.4 GPU资源调度与多模型管理vLLM部署要点)当你的服务开始面向真实用户时Ollama就有点不够看了这时vLLM才是正式的选择。vLLM部署大模型很方便vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192vLLM的吞吐量比普通推理框架高出数倍因为它引入了PagedAttention可以理解为“操作系统的虚拟内存”——把KV Cache分页管理极大减少显存浪费从而支持更高的并发。实测中在单张4090上用vLLM部署7B模型可以轻松支撑几十路并发对话而传统Transformers直接推理可能并发几路就显存溢出。部署完成后直接在代码里用OpenAI客户端client OpenAI( base_urlhttp://your-server:8000/v1, api_keyEMPTY )之前写好的所有调用代码无缝迁移到vLLM服务上。这是工程上的关键节点本地小流量用Ollama生产大并发用vLLM中间代码不用改。生产环境部署还有几个经验要点7B模型建议用AWQ量化部署显存占用大约6GB能在24GB显卡上留足KV Cache空间持续观测日志量化模型偶尔输出异常token是正常现象做好输出过滤如果服务要做多模型切换vLLM目前对多模型支持一般可以多开几个不同端口的服务在网关层面做路由。6. 少走弯路的实用建议合集文章最后这部分我把这些年带团队带新人过程中反复遇到的问题和思维误区集中写一下。这些不是教科书内容全是实操得出来的。6.1 从哪个模型开始学最容易建立正反馈现在的选择非常多但大模型入门学习请记住一个原则模型越成熟、资料越多、社区越活跃越好不要追求“最新最热”。我的推荐是第一优先级Qwen2.5系列中文文档友好模型尺寸覆盖0.5B到72B从个人笔记本到服务器集群都有对应方案。第二优先级Llama 3.1系列英文生态最强几乎所有工具都优先支持Llama的格式。别碰的刚发布一周内的新模型工具链往往没跟上跑起来全是坑。入门阶段建议先跑通1.5B或3B的小模型半小时内跑通一次推理、一次微调、一次RAG建立完整的闭环感觉。用大模型学习路线中一个很朴素的道理全局体验比局部深入更重要先有全景图再有局部钻。6.2 初学者最容易犯的三个错误第一个错误是“收藏即学到”。资料收藏了几十个G笔记截图上万张但自己没跑过一行代码没部署过一个模型。大模型的学习体验性是决定性的只有亲手把模型跑起来才算是真正入门了一点点。第二个错误是“直接挑战最前沿”。有朋友看了一些训练大模型的视频上来就想微调72B模型甚至想预训练自己的模型。不看显存不看成本不看自己的实际需要。微调永远从小模型开始7B甚至3B跑通了、理解透了再去面对更大的参数规模。第三个错误是“唯参数论”。认为模型参数越大越好、效果越强。真实业务里时延、成本、可控性往往比参数更重要。一个能跑在客户内网里的7B私有化模型比一个只能云端访问的100B模型实用得多。企业私有化部署的关键考量点不是“最强”而是“够用且可控”。6.3 学习路线总结三周从零到实战的参考计划我根据自己的教学经验总结了一个三周入门计划适合有一定Python基础和Linux命令行操作的人阶段时间核心任务验收标准第一周Day 1-2了解大模型基础原理读Transformer通俗解释能解释什么是token、什么是注意力机制第一周Day 3-4本地部署Ollama跑通Qwen2.5-1.5B或3B终端能对话API能调用第一周Day 5-7深度学习API调用实现一个带记忆的聊天脚本代码能跑多轮对话第二周Day 8-10做一次QLoRA微调用LLaMA-Factory能训练出一个行为有改变的LoRA第二周Day 11-14实现一个完整的RAG问答应用能回答自己上传文档中的问题第三周Day 15-16用vLLM部署模型压测并发服务能接受并行请求第三周Day 17-21综合实战做一个垂直场景的Agent小项目完成一个能调用工具的多步任务这个计划不是让你每一分钟都坐在电脑前而是保证每个阶段都有看得见的产出。每完成一个阶段你对大模型的理解都会上一个台阶。6.4 一些可以在实践中反复验证的心法最后分享几条我在多个项目里反复验证过的心法也算是对这个入门过程的一些补充。第一先跑通再优化。初学者特别喜欢纠结“哪个Embedding模型效果最好”“TopK该设多少”对着配置纠结一小时就是不敢跑一次。先看结果如果效果满意不用调了不满意带着问题去调参你会有方向得多。第二问题分解永远是第一步。遇到任何需求先判断属于哪一类问题——知识类问题是检索问题行为类问题是微调问题流程类问题是Agent问题。判断对了框架成功了一半。第三任何参数和配置都可以通过低成本实验找到自己场景的解。当你碰上一个新选择本地小模型两天就能试出结果不必去查“标准答案”不同业务的答案本来就不一样。第四保留一份自己的实验笔记。我在本地专门有一个文件夹记录每次微调的数据、参数、评测结果日期标注清楚几个月后回看会特别有收获。这些一手数据比任何教程都有价值因为你记得当时的坑和最原始的直觉。大模型的入门这条路上没有捷径但有不走弯路的方法。沿着部署、微调、RAG、Agent这条主线一点一点啃每个环节都自己动手跑一遍三个月后你再看现在的自己会觉得那些“看不懂的论文”突然都变得亲切起来。这条主线跑通了之后的进阶就只是顺着它不断加深和加宽的问题了。