从零开始建立大模型知识体系：一份务实到不废话的入门路线

身边越来越多朋友问我同一个问题：我想系统性入门大模型，该从哪开始？

问的人里有做后端开发的、有做数据分析的、有产品经理，甚至还有搞传统工业质检的工程师。他们通常已经看过一堆公众号文章、刷过几个视频，但知识停留在“Transformer很厉害”“ChatGPT很牛”这种层面，真正面对“该怎么学”“学到什么程度算入门”“本地能跑什么模型”这些问题时，还是懵的。

我自己从最开始跑通一个7B模型到在公司落地私有化部署，中间踩过的坑可以写满一个备忘录。所以这篇我就把当年希望有人直接告诉我的东西整理出来，结合大模型学习路线里的那些热搜词，从原理、选型、微调、部署、应用五条线展开。不灌鸡汤，不讲虚的，每条都对应能实操的内容。

1. 先把大模型的基本盘搞清楚：它到底是什么

很多人学大模型有一个误区，上来就去念Transformer论文，读了两页被注意力机制劝退。这没必要。入门阶段你需要的是先建立正确的物理直觉——知道它是什么、能干什么、边界在哪里，然后再去碰原理。

1.1 大模型的定义、核心能力与能力边界

大模型，全称大语言模型（Large Language Model, LLM），本质是基于海量文本训练出来的概率模型，核心任务只有一个：根据上文预测下一个最可能出现的词（token）。听起来简单，但当参数量达到数十亿、训练数据覆盖几乎整个互联网文本之后，涌现出对话、翻译、总结、代码生成、逻辑推理这些能力。

这就像一个小孩子不是有人逐条教他语法规则才学会说话，而是在大量语言环境中听多了自然就会表达。大模型也一样，它是“泡”在数据里泡出来的语言能力。

但必须认清能力边界。大模型本质是“接着编”，所以存在幻觉问题——它不知道答案时会一本正经胡说八道；它也没有真正的实时知识，训练时世界是什么样，它的知识就停留在那个时间点，这就是为什么用得配合检索或者联网；它的数学计算能力不是绝对精确，复杂计算经常出错。

理解这些边界极其重要，因为这直接决定了后面你会选择什么样的技术方案，比如要不要引入RAG，要不要做微调，或者只是提示词工程就够了。

1.2 预训练、微调、推理三者之间的关系

系统入门大模型，必须先理清这个大框架。整个大模型生态实际上分三层：

• 预训练：用海量文本从头训练一个大模型，成本极高，通常需要几千张GPU，跑几周甚至几个月，花费数百万美金。这是大厂玩的游戏，绝大多数人不需要碰，知道怎么回事即可。
• 微调：在预训练好的基座模型基础上，用特定领域的数据继续训练，让模型适应你的业务风格和格式，是我们普通人真正要关注的重点。
• 推理：用训练好的模型回答问题的过程，也就是部署和调用。推理是离我们日常最近的环节，无论是API调用还是本地部署都属于这个环节。

像我接触大模型学习路线上不少朋友，一上来就想自己做预训练，这就像刚学会骑车就想参加环法，方向本身就偏了。正确的精力分配应该是，理解预训练原理，掌握微调技能，熟练部署推理，最后学会结合应用场景设计系统。

1.3 常见大模型系列与各自血统

现在市面上的大模型非常多，新手经常被各种名字绕晕。我这里按照“血统”梳理一下主流系列，方便你建立索引：

对入门者，我强烈建议从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甚至更大的量化模型。

我做了一张选型速查表，当初给公司做部署评估时就是按这个逻辑算的：

注意苹果M系列芯片的Mac也很适合跑中小模型，统一内存架构让CPU和GPU共享内存，M1 Pro 16G就能流畅跑7B量化模型，而且功耗低得多。

2.2 部署工具对比：Ollama、vLLM、llama.cpp各有什么优劣势

本地部署工具有很多，入门者最常接触的是这三个：

• Ollama：目前最傻瓜化的本地部署工具。它把模型下载、运行、API暴露封装成几条命令，装完之后一行ollama run qwen2.5:7b就能跑起来。对新手极度友好，也是我建议入门首选。
• llama.cpp：C++实现的推理框架，CPU推理效率极高，支持各种量化格式（主要是GGUF）。如果你要在无GPU的服务器上跑模型，或者追求极致的CPU性能，选它。
• vLLM：推理届的生产级选手。核心优势是PagedAttention技术，极大提升吞吐量，支持连续批处理，非常适合做高并发的线上服务。当你需要给团队提供API服务的时候，vLLM几乎是最优选择。

怎么选？我的建议是：个人学习先用Ollama，它让你五分钟内看到模型跑起来，建立正反馈；研究GGUF量化原理去用llama.cpp；正式做服务部署直接用vLLM。三者的关系不是替代，而是人在不同阶段的需求变化。

2.3 Ollama从安装到跑通模型的全过程

这里我以Windows 11环境为例，完整走一遍流程，非常容易复现：

1. 到Ollama官网下载对应Windows版本，安装包也就几十MB，装完会在任务栏驻留一个图标。
2. 打开命令行终端，执行ollama list验证是否安装成功。
3. 运行模型，ollama run qwen2.5:7b。第一次运行会自动下载权重文件，7B模型大概4GB多，根据网络情况等一段时间。下载完成后你就有一个可以在终端里对话的大模型了。
4. 查看模型信息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到底是什么

部署时你会遇到各种模型文件后缀，把它们看成不同格式的压缩包就好：

• GGUF：llama.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用GGUF，Transformers和vLLM用官方权重或AWQ/GPTQ。

3. 微调实战：让通用模型变成你的专属模型

本地部署解决了“有模型可用”的问题，但很多业务场景需要模型“懂你的业务”，比如你有一个客服系统希望模型能回答特定产品问题，或者你希望模型按照特定格式输出报告。这时候就需要微调了。

3.1 什么场景该微调，什么场景不该微调

这里必须给新手泼盆冷水：微调不是万能的，而且很多问题根本不需要微调来解决。

• 知识型问题——比如“我们公司的退款政策是什么”，应该用RAG检索，把文档切片嵌入向量库，检索后拼进提示词。微调解决不了知识更新问题，也不适合用来灌文档。
• 风格与格式问题——比如“所有回复必须以JSON格式输出”“报告必须是三段式结构”，这是微调的强项，通过少量数据就能把钱模型的行为习惯掰过来。
• 特定任务能力——比如从法律文书中抽取案件要素、把口语转成工单结构化描述，这类任务的输出模式相对固定，微调效果非常明显。

一句话：知识靠检索，行为靠微调。搞清楚决策逻辑，你就比很多人强了。

3.2 LoRA、QLoRA与全量微调：参数量与效果的权衡

传统微调需要更新整个模型的全部参数，7B模型的全量微调光梯度就要几十GB显存，个人开发者几乎不可能。所以现在主流是用LoRA（低秩适配）这类参数高效微调技术。

LoRA的原理可以这样理解：它不修改原始模型参数，而是在模型旁边“并联”一个小型可训练矩阵。就像一个熟练的老会计师改报表，不重写整本账本，只夹几张便签说明哪些地方要按新规则来。训练结束后你得到的不是新模型，而是一个只有几十MB到几百MB的适配器文件。用的时候把LoRA文件叠加到基座模型上，模型的行事风格就变了。

QLoRA则更进一步，它先把基座模型的参数量化到4bit后再做LoRA训练，把7B模型的微调显存需求压到个位数GB，普通消费级显卡就能战微调。

3.3 数据准备：格式规范、质量问题与数据量要求

微调是一门“数据为王”的手艺。模型的效果七分靠数据，三分靠训练参数。我从实际项目里总结出的经验包括：

• 数据格式：一般用对话格式，包括系统提示词、用户输入、模型回答三段。以最常见的方式为例，每一条数据是一个包含system、user、assistant角色的JSON对象数组。
• 数据量：很多人问要多少数据。如果你只需要让模型学会一种输出风格，几百条高质量数据就有明显效果。要做复杂的下游任务，一般建议至少几千条。数据量不是越多越好，同质化数据堆到一定程度边际效用会变得很低。
• 数据质量：宁可要500条精心清洗的数据，也不要5000条有噪声的数据。我见过一个很典型的反例，有人用爬虫抓了上万条问答去微调，测试时发现模型回答充满了错误格式和重复啰嗦，最后删到一千多条人工标注数据反而效果奇佳。
• 多样性：要注意让数据覆盖各种边界情况。客服数据里如果全是常规咨询，模型遇到投诉场景就会懵。需要专门构造一些边缘case数据，比如用户反复追问、用户提供信息不完整等。

3.4 用LLaMA-Factory跑通一次QLoRA微调

新手微调最友好的工具之一就是LLaMA-Factory，它把数据格式处理、训练参数配置、模型导出都封装好了。一次完整的微调流程只需要：

1. 准备数据文件，格式为以下JSON样式：

[ { "conversations": [ {"role": "system", "content": "你是资深的产品推荐助手。"}, {"role": "user", "content": "我想买一款适合长时间戴的耳机"}, {"role": "assistant", "content": "你主要是在室内还是室外使用？"} ] } ]

2. 启动界面，执行CUDA_VISIBLE_DEVICES=0 python src/train_webui.py，浏览器打开控制台。
3. 选择模型名称、LoRA配置，训练集设为你的数据文件，点击开始训练。

训练过程中需要关注两个关键指标：loss值下降是否平滑，以及过拟合情况。一个实用的判断方法：如果训练loss持续下降到0.1以下，但测试时模型反而开始重复数据里的原话而不是泛化，那就是过拟合了，需要减小训练轮数。

3.5 微调后评测：只看loss就太天真了

在实际业务中，我强烈建议你要建立一套基于任务的评测集，将指标分为两个维度：

• 客观指标：比如二分类准确率、实体抽取的F1值、JSON格式的可解析率。这些能自动计算，适合做回归测试。
• 主观指标：比如回答的相关性、语气是否合适、表达是否自然。这些需要人工打分，可以以5分制抽样评估。

一个非常容易翻车的情况是：loss曲线很漂亮，但实际回答连格式都变了。为什么？因为loss只能反映模型在训练数据上的拟合程度，没有任何语义验证能力。训练完务必用一套和训练数据不同分布的测试问题去验证，看到真实表现才算数。

4. 检索增强生成（RAG）：给模型装一个即时更新的外挂知识库

为什么专门讲RAG？因为在实际的to B项目里，单纯的通用大模型根本无法直接回答问题，企业内部的知识库、产品文档、规章制度这些内容，模型训练时根本没见过。RAG是解决这类问题最成熟也最轻量的方案。

4.1 RAG的工作流程拆解

RAG一句话解释就是：回答问题前，先从知识库里检索相关内容，把它作为上下文塞进提示词，让模型有据可依地回答。整个链路分为五个环节：

1. 文档加载与解析：把PDF、Word、网页、数据库中的内容读出来。不同格式解析坑很多，后面单独讲。
2. 文本切片：长文档无法直接全部塞进上下文，需要切成若干片段，常见的策略是固定长度切片，比如每512个token一片，相邻重叠50个token。
3. 向量化：把切好的文本片段通过Embedding模型转成高维向量，一个切片对应一个向量。
4. 存储与索引：把向量存入向量数据库，如Milvus、Chroma、Weaviate等。
5. 检索与生成：用户提问时，把问题转成向量，在库里找最相似的TopK个片段，连同用户问题一起提交给大模型生成答案。

向量化召回这部分，普通人可以做这样一个场景化类比：给所有文档做一套“语义索引卡片”，然后面对新问题时，去卡片柜里找内容最相近的几张。Embedding模型决定了这个“语义相近”的判定准不准，后面的生成效果依赖它上游的检索质量。

4.2 RAG中常见的失败点：切片策略和召回重排

初学者做RAG最容易翻车的地方就在切片这一步。我踩过的坑包括：

• 切片打断句子：固定长度切分经常把一句话切成两半，向量化时语义不完整，召回效果差。解决办法是采用递归切分器，优先按段落切，再按句子切，最后才按字符兜底。
• 标题信息丢失：文档切片后如果没有携带章节标题，模型无法区分“2024年销售数据”是哪个事业部的，语义就散了。建议切片时把文档的层级标题作为元数据附加到切片内容前面。
• 召回数量不足：默认TopK设置为3到5，但复杂问题可能涉及多个知识点，需要提高TopK或者分多路召回。
• 重排序缺失：向量召回的结果是“按相似度排序的”。但相似度高的片段不一定是真正能解答问题的片段。实践中引入一个重排序模型对候选文档打分，效果提升明显。

在真正的知识问答应用里，单纯用向量召回经常不够，业界常用“混合检索”：向量召回+关键词召回（BM25）双路并行，再用重排序模型融合打分。这样可以兼顾语义相关性和字面命中。

4.3 完整可跑的RAG项目参考：从文档到问答

如果你需要一个具体的参考来搭建RAG，我整理了简洁的落地路径：

1. 用LangChain或LlamaIndex做框架选型，LangChain生态丰富但接口变动频繁，LlamaIndex在RAG场景更专注。
2. 文档加载后做递归切片，设置chunk_size=512, chunk_overlap=50。
3. Embedding模型选择方面，中文场景推荐BAAI/bge-large-zh或bge-m3，英文推荐OpenAI text-embedding-3-small或本地的BAAI/bge-small。
4. 向量库选择：个人学习用Chroma最简单，数据量上去换Milvus。
5. 生成模型：本地部署用Qwen2.5-7B-Instruct，API用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_key="sk-xxx", base_url="https://api.deepseek.com" # 换成openai或本地ollama地址 ) response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": "你好"}], temperature=0.7 ) print(response.choices[0].message.content)

当我把这个代码中的base_url换成http://localhost:11434/v1，api_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 8192

vLLM的吞吐量比普通推理框架高出数倍，因为它引入了PagedAttention，可以理解为“操作系统的虚拟内存”——把KV Cache分页管理，极大减少显存浪费，从而支持更高的并发。实测中，在单张4090上用vLLM部署7B模型，可以轻松支撑几十路并发对话，而传统Transformers直接推理可能并发几路就显存溢出。

部署完成后直接在代码里用OpenAI客户端：

client = OpenAI( base_url="http://your-server:8000/v1", api_key="EMPTY" )

之前写好的所有调用代码无缝迁移到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命令行操作的人：

这个计划不是让你每一分钟都坐在电脑前，而是保证每个阶段都有看得见的产出。每完成一个阶段，你对大模型的理解都会上一个台阶。

6.4 一些可以在实践中反复验证的心法

最后分享几条我在多个项目里反复验证过的心法，也算是对这个入门过程的一些补充。

第一，先跑通再优化。初学者特别喜欢纠结“哪个Embedding模型效果最好”“TopK该设多少”，对着配置纠结一小时就是不敢跑一次。先看结果，如果效果满意，不用调了；不满意，带着问题去调参，你会有方向得多。

第二，问题分解永远是第一步。遇到任何需求，先判断属于哪一类问题——知识类问题是检索问题，行为类问题是微调问题，流程类问题是Agent问题。判断对了框架，成功了一半。

第三，任何参数和配置都可以通过低成本实验找到自己场景的解。当你碰上一个新选择，本地小模型两天就能试出结果，不必去查“标准答案”，不同业务的答案本来就不一样。

第四，保留一份自己的实验笔记。我在本地专门有一个文件夹记录每次微调的数据、参数、评测结果，日期标注清楚，几个月后回看会特别有收获。这些一手数据比任何教程都有价值，因为你记得当时的坑和最原始的直觉。

大模型的入门这条路上没有捷径，但有不走弯路的方法。沿着部署、微调、RAG、Agent这条主线一点一点啃，每个环节都自己动手跑一遍，三个月后你再看现在的自己，会觉得那些“看不懂的论文”突然都变得亲切起来。这条主线跑通了，之后的进阶就只是顺着它不断加深和加宽的问题了。