大模型零基础考点全解析：从Token、LoRA到本地部署与RAG实践

大模型技术这两年热到什么程度呢？这么说吧，连我身边不写代码的朋友都在问"大模型到底怎么学"。真去钻技术文档又会被一堆术语劝退：Token、微调、LoRA、上下文长度、RAG、Ollama、多模态……每个词单独看都认识，连在一起就不知道在说什么。

这篇内容就是给零基础读者准备的考点精讲。我不打算从Transformer的数学推导开始吓唬你，而是站在一个在实际项目中反复折腾过大模型的从业者角度，把最核心、最常考、也最实用的知识点串一遍。学完你会知道大模型是什么、能做什么、怎么选、怎么跑起来、什么时候需要微调、本地部署到底要什么配置，以及常见的坑在哪里。适合准备面试考点、准备上手做毕设或项目、或者单纯想系统搞懂大模型的同学。我尽量说人话，配合实际场景去讲。

1. 零基础先搞懂：大模型的核心考点到底是什么

1.1 一句话理解大模型：会续写文本的超级概率模型

很多人一上来就背定义：大模型是基于Transformer架构的大规模预训练语言模型。背完还是不懂。我换个说法：大模型本质上是一个做"文字接龙"的系统。你在对话框里输入"今天天气真"，模型会根据学习过的海量数据，计算下一个字最可能是什么——"好"的概率最高，于是输出"好"。

这个"预测下一个字"的能力，配合庞大的参数量和训练数据，就衍生出了对话、总结、翻译、写代码、分析文档等能力。所以很多考点都围绕一个底层逻辑展开：模型学到的不是知识点本身，而是文本之间的统计规律和语义关联。这也是为什么有时候模型会一本正经地胡说八道——它是在"编概率上合理的答案"，不是在"查数据库里的真相"。

零基础阶段，你只需要记住：大模型 = 大规模参数 + 海量预训练 + 文本生成能力。后面所有微调、部署、应用开发，都建立在"先理解这个模型本质上是概率续写器"的基础上。

1.2 五个必考概念：Token、上下文、参数、温度与注意力

考点清单里最常出现的五个词，我逐个拆：

Token（词元）：模型处理文本的最小单位。模型不是逐字读，而是把文本切成Token。英文里一个单词往往是一个或几个Token，中文通常一个字或一个词对应一个Token。实际使用中，你买API按Token计费、模型的输入长度限制也以Token为单位。估算文本量时记个大概：1个汉字约等于0.6到1个Token，英文1个单词约等于1到2个Token。

上下文长度（Context Length）：模型一次能"看到"的Token总量，包括输入和输出。比如上下文长度4K，意味着你最多给它约4000个Token的内容。常见的有4K、8K、32K、128K甚至更长。上下文长度不是越大越好，因为计算量和成本会随长度增加，很多场景下几K的上下文就够用。这是面试和实际开发中很容易被问到的参数。

参数量（Parameters）：模型内部可调整的权重数量，单位通常是十亿（B），比如7B、13B、70B。参数量越大，模型越"聪明"，但推理需要的显存和算力也越大。零基础记住一个判断：7B级别的模型可以在普通消费级显卡上跑，70B级别基本就要多卡服务器了。

温度（Temperature）：控制输出随机性的参数。温度越低，输出越保守、越稳定，适合代码生成和事实性回答；温度越高，输出越多样、越有创意，适合头脑风暴和文案创作。实际调参经验：代码和结构化输出用0到0.3，对话用0.7左右，创意写作可以开到0.9以上。

注意力机制（Attention）：Transformer的核心模块，本质上是让模型在生成每个字的时候，知道应该"关注"输入文本的哪些部分。生活化类比：你在做阅读理解时，看到某道题会回头定位到原文某一段，注意力机制就是让模型学会这种"回头定位"的能力，并且为每个位置分配不同的重要程度。这也是后面讲的长上下文处理、RAG技术的地基。

2. 大模型的应用形态与选型：先学会挑合适的模型

2.1 通用、推理与多模态：模型分类是考点重灾区

很多零基础同学分不清"大模型"到底有哪些种类。按照最常见的应用形态，至少记住三类：

通用对话模型：主打对话和通识问答，比如Qwen系列、Llama系列、DeepSeek系列。这类模型覆盖面广，适合写文案、做问答、当助手。零基础起步首选这类模型，因为生态成熟、资料多、上手快。

推理模型：近两年很火的一类，特点是在回答前会进行"思考"，擅长数学、逻辑、代码疑难问题。典型特征是输出时会先展示一段思考过程。适用场景是复杂任务拆解，但对简单问题反而显得啰嗦，实际选型时按任务复杂度决定。

多模态大模型：输入不再局限于文本，还能处理图像、音频、视频。比如"看图说话"、把一张产品图转成描述文本、根据语音生成文字等。注意多模态与单模态选型的核心差异在于：输入编码方式不同，需要的预处理管线也不一样，部署时对显存的压力通常更大。

考点里容易被问的是"什么场景用什么模型"。我的建议是：先选任务类型，再选模型规模，最后看部署条件。不要盲目追求大参数，7B或14B级别的模型在多数实际业务中已经够用，关键是做针对性优化。

2.2 开源私有化与商用API：两种路线怎么权衡

这是每个做应用的人都绕不开的选择题。先给结论：如果数据必须不出内网、或者要长期控制成本，走开源+本地部署；如果快速验证、不想管理硬件，走商用API。

开源模型（如Qwen、Llama）可以免费下载权重，部署在自己的服务器上。企业私有化部署大模型就是这种路线，优点是数据安全可控、没有按量计费、可以深度定制；缺点是硬件成本高、需要自己维护、模型更新要自己跟进。

商用API则是直接调用云端接口，按Token付费。优点是不用管硬件、效果通常更好、接入快；缺点是数据经过第三方、长期用量大时成本高、对特定场景的可定制性弱。

一个实际经验是：很多团队先商用API做概念验证，跑通之后再根据成本和合规要求，决定要不要换成开源模型私有化部署。很多免费的模型API也提供了不错的额度，适合学习和原型开发。考点里只要你能说清楚"开源闭源、自建与API"的取舍逻辑，基本就能拿分。

2.3 场景化选型案例：工业检测、语音转写与代码生成

结合几个真实场景说一下选型思路，这也是网上常被搜的问题，比如"工业AI检测、服装检测这类AI用的是云联网还是单机，用什么大模型足够"。

先说结论：工业检测和服装检测这类任务，绝大多数不需要联网调用大模型。原因很简单：产线环境网络不稳定、数据涉密、实时性要求高。大模型在其中往往不是"眼睛"，而是"翻译器"——检测本身靠传统视觉算法或专用小模型完成，大模型负责把检测结果转成自然语言报告、回答维修人员的提问、或者做异常原因推理。所以单机部署一个7B到14B的开源模型完全够用，重点是稳定、离线、可控。

再比如讯飞这类语音转写场景，前端适配实时流式识别时，大模型负责的是"转写后的语义理解"而不是"语音转文字本身"。语音识别模型把声音变成文字，大模型再把文字整理成会议纪要、提取待办事项。很多团队会在前端做流式接口适配，把增量识别文本实时送入大模型做后处理，这时要考虑的是低延迟和上下文拼接策略。

代码生成场景则要注意：IDE里的AI助手通常需要快速响应，本地部署小模型（7B级别）配合代码库索引就能有不错的体验，也有人直接用VS Code或Visual Studio的插件接Studio类本地推理工具的API，把代码补全能力接进编辑器。这类应用的考点在于"延迟"和"上下文"，代码文件往往是长文本，怎么把相关代码片段窗口化地塞进上下文是关键。

3. 本地部署大模型实操：从Ollama到企业私有化

3.1 为什么零基础首选Ollama

本地部署大模型的工具不少，常见的有Ollama、LM Studio、vLLM等。零基础阶段我最推荐先学Ollama。原因很直接：它把"下载模型、运行模型、暴露接口"这三件事压缩成了极简操作。

传统部署流程要装Python环境、配置CUDA、安装推理框架、手动下载模型权重、再写一段调用的代码，任何一个环节出问题新手都会卡半天。Ollama则设计成"一键式"：安装完成后，一条命令就能拉取模型并启动本地服务，自动管理模型文件、GPU加速、API接口。实际上它把很多工程细节都藏在底层了，非常适合做学习和原型验证。

有人问"Ollama安装的大模型到底是一个什么文件"。这个考点其实不难：Ollama使用的模型格式叫GGUF（GPT-Generated Unified Format的缩写，是一种专门为本地推理优化的量化模型格式）。它把模型权重、分词器、配置信息打包成一个或多个文件，支持4-bit、8-bit等量化方式，能大幅压缩体积、降低显存需求。你通过Ollama拉取的模型，本质就是下载了GGUF格式的模型文件。理解这一点后，你对"离线版模型"也就有了概念：只要把模型文件下载到本地，即使没有外网，Ollama也能正常加载推理。

3.2 部署全流程：安装、拉模型、启动服务、调用API

以Windows 11环境为例，完整走一遍：

第一步，安装Ollama。到官网下载对应系统安装包，双击安装即可。安装完成后命令行输入ollama -v能输出版本号就说明装好了。

第二步，拉取模型。在命令终端执行：

# 拉取Qwen 7B模型（默认版本） ollama pull qwen:7b # 或者拉取Llama 3 8B ollama pull llama3

注意国内网络环境下载大模型文件可能较慢，建议在网络条件好的时候一次拉取，或者从可信任的镜像站点获取模型文件后手动导入。模型文件体积动辄几个GB，下载时要留意磁盘空间。

第三步，启动服务。拉取完成后，执行：

ollama serve

服务默认监听在11434端口。你会看到类似listening on 127.0.0.1:11434的输出。如果想全自动，Ollama安装后本身会把服务注册为后台进程，通常不用手动每次启动。

第四步，调用接口。最简单的验证方式是新开一个终端：

ollama run qwen:7b

这会在终端里直接进入对话模式。如果想通过HTTP API调用，可以用curl测试：

curl http://localhost:11434/api/generate -d '{ "model": "qwen:7b", "prompt": "用一句话介绍大模型" }'

返回的JSON里response字段就是模型生成的文本。应用开发里一般用/api/chat接口做多轮对话，请求里带上messages数组即可。你会发现本地模型的使用方式和商用API几乎一致，差别只是URL指向本地。

3.3 上下文长度与推理性能的关键设置

本地部署最容易翻车的是"跑是跑起来了，但回答质量差或者直接内存爆掉"。这里给两个关键考点：

上下文长度设置。Ollama中可以通过Modelfile设置模型运行的上下文长度，比如：

FROM qwen:7b PARAMETER num_ctx 8192

然后执行ollama create mymodel -f Modelfile创建自定义模型。如果不设置，很多模型默认只使用较小的上下文，可能导致长文档输入被截断。注意：上下文调大之后，显存和内存占用会显著上升。经验估算：7B模型在4-bit量化下，4K上下文约需5GB显存，8K约需6GB，再往上翻倍增长。机器只有8GB显存的话，老老实实把上下文控制在4K左右。

推理延迟。本地模型的生成速度取决于GPU算力。7B模型在消费级显卡（如RTX 3060 12GB以上）上每秒能生成十几到几十个Token，体感还行。纯CPU推理也不是不可以，但速度会慢到让人崩溃，只适合做非实时场景。企业私有化部署时，常用vLLM这类高性能推理框架替代Ollama，因为vLLM支持Continuous Batching（连续批处理）、PagedAttention（分页注意力）等优化，能在高并发场景下把推理吞吐量提升数倍。你好理解成：Ollama是把服务跑起来，vLLM是把服务跑得快且扛得住并发。

3.4 硬件选型：GPU、NPU与显存到底怎么算

零基础最常问的就是"我的电脑能跑吗"。我给出一个简化判断公式：

推理所需显存 ≈ 模型参数量（GB）× 每参数字节数

7B模型如果FP16精度加载，每参数占2字节，约需14GB显存。但量化后显存需求骤降：4-bit量化下每参数约0.5字节，7B模型约需4到5GB显存。所以主流建议是：消费级显卡优先选显存大于等于8GB的型号，这样可以舒服地跑7B到14B的量化模型。

没有独立显卡，只有CPU和内存的机器，也不是完全不能跑。用Ollama让模型跑在CPU上，7B量化模型大概需要8GB以上可用内存，速度虽慢但能跑通流程，学习原理完全够用。很多新电脑带NPU（神经网络处理单元），低功耗跑小模型有优势，但目前生态还在完善，兼容性和性能释放不如NVIDIA的CUDA生态，零基础不建议把NPU作为第一选择。

企业私有化部署大模型则要另行评估：并发用户数、响应时间、模型规模、是否需要微调训练。并发推理的场景下，单卡3090或4090能支撑小规模应用，几十路并发就需要A系列服务器显卡甚至是多卡集群了。这块如果没底，先用Ollama搭一个单机原型测压，再把性能数据作为扩容依据。

4. 大模型微调精讲：多数场景用不上，但考点必考

4.1 先判断：到底要不要微调

大模型微调是热搜榜常客，也是很容易被误解的概念。很多零基础同学以为"模型回答问题不够好，就得微调"。其实大部分场景下，先用提示词优化和RAG解决问题，最后才考虑微调。

原因很实际：微调需要准备高质量数据集、需要GPU训练环境、需要调试和评估，成本远高于写提示词或做检索。如果问题只是"模型不知道最新资料"或"模型不知道公司内部文档"，做RAG（检索增强生成）就能解决，完全不用动模型权重。只有当模型的"行为模式"需要改变时——比如让它输出固定JSON格式、学习特定领域的书写风格、或者在一个窄领域里大幅提升准确率——微调才值得做。

这个判断逻辑面试中经常被问到。标准回答思路是：先分析失败原因，区分"知识缺失、格式不对、能力不足"三种情况；知识缺失走RAG，格式不对走提示词与后处理，真正能力不足再走微调。把这个流程说出来，比单纯背微调步骤更能体现理解深度。

4.2 LoRA微调：用极少资源改出专属模型

全参微调意味着更新模型全部几十亿参数，训练成本极高，零基础基本不用考虑。现在工业界最常用的是LoRA（Low-Rank Adaptation，低秩适配）。

LoRA的核心思想很巧妙：冻结原始模型参数，只训练一小部分额外的低秩矩阵。类比来说，原始模型是一个装了海量知识的大脑，LoRA不是在重塑大脑，而是在旁边加一个小插件，这个插件只负责调整模型输出方向。实际效果上，用一个很小的可训练参数量（通常只有原模型的不到1%），就能在特定任务上逼近全参微调的效果。

实操角度，常用的是peft库（Parameter-Efficient Fine-Tuning，参数高效微调）配合transformers库。核心流程：

1. 加载基础模型，设置load_in_4bit=True做量化以便在消费级显卡上训练。
2. 用LoRA配置，指定r（低秩维度，常见8到64）、alpha（缩放系数）、target_modules（要适配的模块列表）。
3. 准备数据集，格式化为指令输入输出对。
4. 训练若干epoch，保存LoRA权重（通常只有几十到几百MB）。
5. 推理时把LoRA权重合并或叠加到基础模型上。

显存需求随模型变大：7B模型用LoRA，配合量化，在12GB到16GB显存的卡上可以训练。这就是"GPU微调大模型"的现实可行性。注意训练时batch size要调小，或者用梯度累积，否则显存容易爆。

4.3 微调数据准备与关键避坑

微调效果的上限不是模型，而是数据。我见过太多人把大量时间花在调参上，结果效果差是因为训练数据质量不行。几条实际经验：

数据量不需要很大。对垂直领域风格对齐，几千条高质量样本往往就够了；要显著提升某个任务能力，几万条也够。比数量更重要的是覆盖度和一致性。

指令格式必须统一。所有训练样本的输入输出格式要完全一致，比如统一用"指令（Instruction）+ 输入（Input）+ 输出（Output）"结构。格式混乱会让模型学不到稳定模式。

一定要分验证集。不要拿所有数据训练，留出5%到10%做验证和评估，不然你根本不知道模型是不是过拟合了。

谨慎处理原始数据里的脏内容。用知识抽取框架（比如OneKE这类实体关系抽取工具）可以把非结构化文本清洗成结构化三元组，再整理成训练语料。这一步能有效提升数据质量，属于微调数据工程的加分项。

先做小型实验再全量训练。用一个小子集训练几百步，观察loss是否下降、生成结果是否合理，再决定是否投更多算力。微调训练里的灾难性遗忘问题也很常见——模型学到了新任务却忘了通用能力。解决办法是混合一部分通用数据继续训练，或者降低LoRA的学习率。

5. 大模型应用开发考点：提示词、RAG与智能体

5.1 提示词工程：和模型高效沟通的基本功

零基础最容易上手的就是提示词工程。模型本身能力再强，提示词写得含糊，输出也含糊。反过来，好的提示词能让小模型发挥出大模型八成效果。

几个核心套路：

角色设定+任务描述+输出格式。比如"你是一名资深技术编辑（角色），请把下面这段内容改写成通俗易懂的公众号文章（任务），输出包含小标题和表格（输出格式）"。比起只说"帮我改一段话"，这种结构化提示词命中率高得多。

给示例（Few-shot）。在提示词里放一两个"输入-输出示例"，模型会模仿示例风格。这是稳定输出格式最有效的手段之一，尤其是在做数据结构化时。

用分隔符隔离内容与指令。用###、<content>等符号把待处理的文本与指令区分开，避免模型混淆。在很多大模型实战中，这种"标签化"的做法能显著降低指令困惑。

提示词为什么有效？本质上是在引导模型的条件概率分布。模型不是理解了你的意图，而是在你的文字范围内缩小了"续写"的空间。想通这一点，你就知道提示词不是"魔法咒语"，而是"搜索约束条件"。对同一任务反复测试不同的提示词写法，效果可能差出几个档次，这就是积累经验的过程。

5.2 RAG技术：给模型装上一个可以更新的外挂知识库

RAG（Retrieval-Augmented Generation，检索增强生成）是大模型应用课程里含金量最高的考点。它的作用一句话就能说清：让模型在回答问题之前，先去知识库里检索相关资料，再基于检索到的内容作答。

完整链路一般分四段：

1. 文档切分：把长文档切成若干片段（chunk），通常是几百个Token一段，注意保留语义完整性。
2. 向量化：用嵌入模型（Embedding Model）把每个片段转成向量并入库。
3. 检索：用户提问时，把问题也转成向量，在库里做相似度检索，找出最相关的Top-K片段。
4. 生成：把检索到的片段和用户问题一起塞进大模型上下文，让模型基于这些材料回答。

为什么要用RAG而不是微调？因为知识库里内容每天在变，RAG只需更新向量库和文档索引，模型权重完全不动，成本和时效性都好得多。实际开发中常用的向量数据库有Milvus、Chroma、FAISS等。RAG的效果瓶颈通常不在模型，而在检索质量——能检索到相关文档，大模型答对率自然会高。做一个好RAG，文档切分策略和检索Top-K的选择（常见5到10）往往比换更大的模型更重要。

5.3 AI智能体与知识抽取：从"回答问题"到"完成任务"

最新的考点方向是AI智能体（Agent）。大模型只负责"生成文字"，智能体则把大模型当作"大脑"，让它能调用外部工具、执行多步任务、根据结果动态调整计划。比如让它查天气、订日程、调用企业API完成审批流程等。

智能体的核心机制是"工具调用"。模型输出一个结构化的调用指令（比如指定函数名和参数），程序解析后执行并返回结果给模型，模型再基于结果继续推理。零基础学习时，可以先从简单的ReAct模式（推理+行动循环）入手，理解"思考-行动-观察"的三步循环。

知识抽取是另一个实用考点，典型场景是从大量业务文书中抽出实体和关系，构建结构化知识库，再供RAG或人工分析使用。现在有专门的知识抽取框架（如OneKE）可以一键实现实体识别与关系抽取，大幅降低开发成本。知识抽取与大模型结合的思路是：大模型负责"阅读理解"和"结构化输出"，提示词里定义清楚要抽取的实体类型和输出JSON格式，然后对批量文档执行抽取。这类应用在金融、法律、政务领域非常普遍，是很好的项目方向。

6. 零基础避坑手册：常见问题排查与学习路线

6.1 高频问题速查表

结合我踩过的坑，整理一张高频问题排查表：

排查问题的核心方法论是"分层定位"：先确认是模型问题、数据问题还是工程问题。模型乱答先换提示词，提示词无效再看是否有知识缺失（考虑RAG），还不行才考虑微调。工程上先查资源占用（显存、内存、磁盘），再查API请求参数，最后查服务日志。按照这个顺序走，80%的问题都能快速定位。

6.2 零基础学习路线：先跑通再深入

最后给出一个适合零基础的学习路线，按照"先用、再懂、后改"三阶段安排：

第一阶段：跑通应用闭环（1到2周）。用Ollama在本地跑通一个7B模型，学会通过API调用，用提示词完成一个实际任务，比如让模型帮你整理笔记、写周报摘要。目标是消除对大模型的恐惧感，建立"模型就是个能聊天的程序"的直觉。

第二阶段：理解原理和微调（2到4周）。把注意力机制、Token、上下文、温度这些考点逐个搞懂，用现成工具对开源模型做一次LoRA微调。数据规模不用大，1000条样本、跑两三个小时，重点体会"数据对效果的影响"。配合阅读一些图解Transformer的文章，把黑盒变灰盒。

第三阶段：做一个完整项目（4到8周）。建议选一个RAG应用，比如"基于公司文档的问答机器人"。需要部署模型、实现文档切分与向量化、做检索与生成、写一个简单前端页面。这个项目做完，RAG、部署、API调用、提示词工程这些核心考点全串起来了。如果时间有余，再往智能体和多模态方向扩展，做一个能识图并生成结构化描述的小应用。

很多人学大模型最大的问题是贪多求快，资料收藏了一堆却始终没跑通过一个完整例子。我的个人经验是：先用最简单的方式让模型跑起来，哪怕只是本地生成了一句"你好"，那种感觉和只看不动手完全不同。大模型技术发展极快，但基础框架不会大变，值得浇点时间打牢。把上面这条路线走完，你已经超过大多数停留在"了解概念"阶段的人了，面试和实战都不会慌。