经常有人拿着“大模型的系统性入门资料”这个需求来找我，开头通常还会补一句：“我收藏的课程都吃灰了，到底应该按什么顺序学？”我太理解这种状态了。这个领域最不缺资料，缺的是一条能走通的路线：先学什么、后学什么、学到什么程度可以停下来，以及怎么判断自己是真学会了而不是“看懂了”。这篇文章就是把这套路线完整写出来，从概念地图开始，经过提示词工程与上下文工程、原理学习的四个阶段、微调避坑，一直讲到本地部署和资料库建设。它不是某个单一教程的替身，而是一份可以直接照着执行的学习方案，适合零基础想入门的人，也适合已经会调 API 但对后续路径感到茫然的开发者。

1. 先把“大模型”这个词拆清楚：LLM、多模态与Agent到底指什么

1.1 LLM的本质：一台见过海量文本的概率预测器

第一次接触大模型，很多人的第一反应是“它什么都知道，所以它是一本百科全书”。这个直觉会带来一连串错误预期：模型答错了，你觉得它“坏了”；模型胡编，你觉得它“不靠谱”；模型记不住上次聊了什么，你觉得它“没脑子”。

其实 LLM（Large Language Model，大语言模型）的本质，是一台见过海量文本的概率预测器。它学习的不是客观知识，而是语言片段之间的统计规律。你给它一段上文，它根据训练时见过的模式，预测下一个 token 最可能是什么。所谓“知识”，只是这些统计规律在特定问题上的副产品。

打个比方：它像一个特别擅长接话的聊天对象，没有实时网络，也不会主动去查资料，它只是根据你给的前文和自己记忆里的语料，把最像样的下一句接出来。这就解释了为什么它偶尔会一本正经地胡说八道——因为“听起来像真的”本来就是它的优化目标，而事实正确性只是附带结果。

入门阶段，你需要建立三个基础认知：

• token 是模型处理文本的最小单位，一个汉字可能对应一到多个 token，英文单词通常会被切成词根；
• 自注意力机制让模型在生成每个 token 时，都能回头“看”上下文里所有位置，并决定哪些词更重要；
• 温度参数（temperature）控制输出的随机性，温度越高，回答越发散，温度越低，越倾向概率最高的答案。

这个认知框架建立起来之后，后面再谈提示词、微调、部署，你才知道每一步到底在改动什么。

1.2 多模态与Agent：大模型生态里的两个高频词

多模态模型是最近两年绕不开的概念。它把文本、图像、音频、视频统一映射到一个语义空间，所以你给模型看一张图片，它能描述画面内容；给它一段录音，它能转写甚至理解语气。技术实现上通常是“视觉/音频编码器 + LLM 主干”的组合方式。入门阶段不需要深抠细节，知道两点就够了：第一，多模态建立在 LLM 的语言能力之上；第二，选型时如果业务里必须处理图片，才需要特意考虑多模态模型，纯文本场景直接用 LLM 更轻量。

Agent（智能体）则是 LLM 之上的应用范式：让模型扮演“大脑”，通过工具调用、任务规划、记忆管理去完成多步骤任务。比如让模型根据用户指令判断该调用天气接口还是日历接口，再按步骤组合结果。入门阶段同样不必急着实现 Agent，但要理解它和大模型本体的区别：大模型只负责“想”，Agent 负责“想 + 做”。

我把这个生态用一张表整理出来，方便你对号入座：

这张表也是一个学习地图：你不需要同时精通所有概念，但至少要知道它们各自解决什么问题。下面，我们从最不需要显卡、最适合立刻上手的部分开始讲。

2. 入门第一站：提示词工程与上下文工程，先学会“使用”再谈“实现”

2.1 提示词的内核：把任务拆成模型能接住的形状

很多人以为提示词工程是“咒语大全”，换几个词效果就天差地别。其实它的内核是任务拆解：模型对模糊指令的完成度，远低于对它明确指令的完成度。你可以把模型想象成一个极其聪明、但有点“死板”的新实习生。你告诉它“帮我写个方案”，它只能给你一个泛泛的模板；你告诉它“你是市场专员，请针对大学生用户写一份 500 字的新媒体推广方案，要求包含三个传播话题和一个预算分配表”，它交付的东西就立刻有可用性。

我平时写提示词遵循一个固定结构：

• 角色设定：你是一名资深数据分析师；
• 任务目标：请根据以下销售数据完成季度趋势分析；
• 输入内容：把需要处理的数据或文本放进来；
• 输出要求：结论控制在 200 字内，先给结论再写依据；
• 输出格式：用 Markdown 表格展示月度对比。

这个结构看起来很基础，但实操中能解决 80% 的回答太泛、格式不符、逻辑混乱问题。尤其是“输出要求”和“输出格式”，它们是在帮模型缩小解空间——模型不需要猜你要什么，它只需要执行。

另外要养成一个习惯：给模型“思维链”机会。遇到复杂问题时，在提示词里写明“请先列出解题步骤，再逐步计算”，或在推理类任务中允许模型分步输出。这不是什么神秘力量，而是在降低模型一次生成完整答案的压力，让它在中间步骤上多一些纠错空间。

2.2 上下文工程：窗口是有限的，内容是策略

提示词工程解决的是“单次请求里怎么说话”，上下文工程解决的是“在有限上下文窗口里，放什么内容才是最优解”。现在的模型上下文窗口动辄几万甚至几十万 token，看起来很大，但实际使用时并不是塞得越多越好。

原因有三个：

• 窗口越长，计算成本越高，响应速度越慢；
• 模型对长上下文中段的注意力会衰减，插在中间的关键信息容易被忽略；
• 无关内容会稀释有用信息，导致回答跑偏。

所以上下文工程的核心动作是筛选和压缩。最典型的方案是 RAG：当问题需要外部资料时，先把资料切分成小块，通过向量检索找最相关的几段，再拼接到提示词里。相当于给模型布置考场时，不是把整座图书馆搬到桌面上，而是只摆上几页重点笔记。

具体落地时可以这样操作：

1. 将文档按 300-500 token 左右切块；
2. 用 Embedding 模型给每块生成向量；
3. 用户提问后，先把问题转成向量，检索相似度靠前的几块；
4. 将检索结果拼进提示词的上下文区域。

实操中我最常用的调优手段是调整“切块大小”和“召回数量”。切块太大，信息太杂；切块太小，语义割裂。不同文档类型需要不同的参数，建议从 400 token、召回 3-5 块开始，再根据效果上下浮动。

2.3 一套能直接抄的提示词模板

下面这个模板是我在日常工作里反复用的，你直接复制就能用：

你是一名{角色}。 请根据以下内容完成{任务目标}。 【输入内容】 {需要处理的数据、文本或问题} 【输出要求】 1. 先给出核心结论，再展开依据； 2. 控制在{字数}字以内； 3. 如果信息不足，直接说明，不要编造； 4. 使用{Markdown / JSON / 表格}格式输出。

这套模板的关键在于把“角色、目标、输入、限制、格式”五要素一次说全。它不会让模型突然变得无所不能，但能明显减少来回追问和重新生成的次数。等你熟练之后，还可以进一步加入 few-shot 示例——给一两个输入输出样例，让模型模仿你的风格。这是提示词工程中性价比最高的进阶技巧。

3. 学习路线的主干：从“会用”到“懂原理”的四个阶段

3.1 阶段一：当API消费者，跑通完整闭环

不管未来想做算法还是做应用，第一步都应该先当一个重度 API 使用者。建议你尽快用商用大模型 API，或者开源模型的在线 Demo 跑通一个完整的小项目。目标不是搞懂模型内部原理，而是熟悉一套交互范式：消息由 system、user、assistant 三部分组成，请求参数里有模型名、temperature、top_p、max_tokens 等关键项。

我推荐第一个任务是“批量文档总结”：准备 10 篇不同主题的文章，写一个脚本调用 API，逐篇输出摘要并保存到文件。这个任务训练的不是模型，而是你——你会自然掌握怎么组织请求、怎么处理返回结果、怎么控制成本，也才能真正体会到“上下文长度不够用”“输出截断”“格式不稳定”这些实际问题到底长什么样。

完成这个阶段后，你应该能回答三个问题：

• temperature 越低，输出的确定性越高，但会不会导致创造力下降？
• 同样的任务，换一个模型，结果为什么会差很多？
• 输入内容太多时，响应变慢和成本上升的临界点在哪？

3.2 阶段二：补基础，读论文只读关键段落

很多初学者一上来就抱着《Attention Is All You Need》硬啃，结果在数学公式里败下阵来。我的建议是：不追求完整推导，只建立“工作原理直觉”。

你需要掌握的知识点可以压缩成一条链：tokenizer 把文本切成 token，embedding 把 token 变成向量，自注意力机制让每个位置都能融合全局信息，多层堆叠提取更高层语义，最终通过 Softmax 输出下一个 token 的概率分布。

数学方面，有高中数学和本科初等微积分基础就够用。重点理解三个概念：向量点积用于计算相似度、Softmax 把分数变成概率、交叉熵用于衡量预测与真实的差距。不用急着补全线性代数和概率论的全部内容，用到哪补到哪。

论文阅读从这三篇入手效果最好：

• 《Attention Is All You Need》：只需要看第 3 节“Model Architecture”，理解 Q、K、V 和 Multi-Head 的直觉即可；
• 《QLoRA》或《LoRA》:重点看“为什么只训练少量参数也能有效”，这是微调的基础；
• 《LIMA》：看实验设置，它告诉你少量高质量数据也能达到不错效果。

每次读论文的时候，给自己一个输出要求：读完能用 300 字向别人解释这篇论文解决了什么问题、用了什么方法。说不出这两点，说明还没真正读进去。

3.3 阶段三：动手微调之前，先学会“不微调”

这是我最想强调的一个阶段。大模型圈子最流行的动作是微调，但绝大多数场景其实不需要微调。你需要先学会判断，什么情况用什么手段：

判断的逻辑很简单：微调改变的是模型底层的概率分布，成本高、周期长、且有遗忘风险。如果问题出在“信息不够”，那是检索的问题；如果问题出在“表达方式不对”，那是提示词的问题。只有当你已经尝试过提示词、RAG，且确定需求是稳定的行为模式转换时，微调才值得入场。

3.4 阶段四：部署、评估、形成一个闭环

学习路线的最后一站是本地部署。你不需要一开始就买昂贵的显卡，但至少要掌握一个完整技能：把模型权重加载起来，封装一个 API，然后用真实请求测试它的性能与效果。

推荐的第一个部署方案是“Ollama + 开源模型”。它可以自动管理模型权重、提供 OpenAI 兼容接口、还能在 CPU 上运行小模型。你花半小时就能把 7B 级别的模型跑起来。跑通之后，再用 vLLM 或者 llama.cpp 去替换后端，体会不同推理框架的差异。

到了这个阶段，学习的闭环就形成了：

需求分析 -> 模型选型 -> 提示词调优 -> 上下文/RAG -> 微调决策 -> 本地部署 -> 效果评估

以后遇到任何新项目，你都可以快速定位问题出现在链条的哪一环，而不是盲目地“上个微调再说”。

4. 微调实战前的三条弯路：数据、显存与评估

4.1 微调不是炼丹，是数据工程

如果看完上一节你仍然决定要做微调，那我要先泼一盆冷水：微调项目里 80% 的时间都花在数据清洗上，而不是训练参数上。

最经典的错误是网上找一份开源指令数据集，直接跑训练脚本，发现 loss 降了，但模型输出质量没有提升，甚至出现复读机现象。原因多半是数据本身有问题：指令重复、输出质量差、格式不统一、answer 里混着大段无关广告、翻译语料语义错乱。

一套基础清洗流程至少包括：

• 去重：相同或近似的 instruction 只保留一份，防止模型过度拟合到固定句式；
• 格式统一：统一转成 instruction + input + output 结构，或 chat template 结构；
• 过滤垃圾：删除空输出、纯标点、明显乱码、长度过短或过长的样本；
• 平衡配比：领域数据不能占比过高，否则会灾难性遗忘通用能力。我见过把 100% 数据都做成法律问答的，模型最后连“你好”都不太会接。

以指令微调的标准格式为例，一条训练样本长这样：

{ "instruction": "请把下面的句子翻译成英文。", "input": "大模型入门最重要的事情是动手实践。", "output": "The most important thing in getting started with large language models is hands-on practice." }

看起来简单，但真实项目里，你拿到的原始数据可能是 Excel 表格、PDF 报告、客户聊天记录，需要花费大量精力把它们统一成上述格式。请一定做好这个心理准备。

4.2 显存与 batch 的换算关系：先算清账再租卡

微调最让人困惑的就是显存。为什么一张 24GB 的卡，别人的 7B 模型能跑，我的就 OOM（显存溢出）？因为微调不只是加载权重，还需要额外的空间保存梯度和优化器状态。

按最常见的情况估算一下：

• 一个 7B 模型，用 FP16 精度保存权重，约需 14GB；
• 全参数微调时，梯度需要同样规模的显存，约 14GB；
• AdamW 优化器还会保存动量等状态，约 28GB；
• 再加上中间激活值，总占用量轻松超过 70GB。

所以全参数微调 7B 模型，单张 24GB 消费级显卡基本没戏。这也是 LoRA 和 QLoRA 流行的根本原因——它们不是一种“更牛的训练技巧”，而是一种“把显存需求打下来”的工程手段。LoRA 只训练注入的少量低秩矩阵，其余参数冻结，显存需求大幅下降；QLoRA 再把基础权重做 4bit 量化，内存占用进一步压缩。

注意，这只是训练阶段的粗略估算。序列长度越长、batch size 越大，激活值占用的显存也越高。如果你在本地跑 QLoRA 仍然 OOM，优先做两件事：把序列长度从 2048 降到 1024，把 batch size 降到 1 并用梯度累积。这两招解决 90% 的显存问题。

4.3 微调之后怎么评估，才算有效

许多新手只看训练 loss：loss 从 1.2 降到 0.3，就觉得“微调成功”。但训练 loss 下降只能说明模型记住了这批训练数据，不能说明它变聪明了。

我常用的评估方式是“三件套”：

1. 保留集效果：划分一部分数据不参与训练，用它测试模型在这些未见样本上的表现；
2. 回测能力：准备一组微调前就答得很好的问题，测试微调后是否仍然答得好，这是检测灾难性遗忘的手段；
3. bad case 排查：每批模型输出里手动抽 50-100 条，找出系统性错误。比如模型总是把日期格式写错、总在代码块结束少收一个反引号，这些信息会告诉你下一步该优化数据还是优化提示词。

最容易被忽略的是“对比实验”。微调后模型效果变差不等于微调失败，也可能是因为原始模型本身在这个场景上就不行。你需要在完全相同的提示词下，拿微调前、微调后两组输出做盲评，才能确认微调是否真的带来正向收益。

5. 本地部署：把模型跑在个人电脑上的硬件账与软件栈

5.1 先算清参数、精度、显存三笔账

本地部署大模型之前，第一件事不是下载权重，而是先算清楚自己电脑能不能跑。核心公式很简单：模型权重的显存/内存占用 ≈ 参数量 × 每个参数的字节数。

常见的精度对应关系如下：

但上面的表只是模型权重，实际运行还需要额外的 KV Cache 和上下文缓冲区。所以我的经验是：把上面的估算值乘以 1.3 到 1.5，才算比较稳妥的最低要求。

举例来说，一台 16GB 显存的消费级显卡，跑 7B 模型 INT4 量化版本是比较从容的；如果跑 13B 模型量化版，接近极限，建议关闭部分上下文长度；70B 级别的模型量化后也需要 40GB 左右的内存，个人电脑基本要用 Apple Silicon 的大内存版本或多卡方案。

如果完全没有 GPU，也别急着放弃。7B 以下的小模型在 CPU 上也能跑，只是速度更慢。可以考虑使用 GGUF 格式的量化模型，在纯 CPU 环境下跑 1.5B 或 3B 模型做实验，依然能完整理解大模型的交互逻辑。

5.2 主流推理框架与量化方案选择

本地部署的软件栈，我推荐按用途分成三类：

• Ollama：最适合入门的封装方案。它内置模型管理、自动下载权重、提供 OpenAI 兼容接口，几乎零配置。缺点是定制空间有限。
• llama.cpp：CPU 推理和高性能量化的首选。模型以 GGUF 格式存储，你手动控制加载参数、线程数，对底层逻辑的理解帮助最大。
• vLLM：GPU 高并发服务的最佳选择。它使用 PagedAttention 技术提高吞吐率，适合小团队做内部服务。需要 N 卡且配置稍复杂。

以 Ollama 为例，跑一个 7B 模型只需要两步：

# 拉取模型权重 ollama pull qwen2.5:7b-instruct # 启动并对话 ollama run qwen2.5:7b-instruct

如果你在 GPU 环境想用 vLLM 提供 API 服务，命令大概是这样的：

# 以 OpenAI 兼容接口方式启动本地模型 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --port 8000

启动之后，任何支持 OpenAI SDK 的代码都能直接指向本地地址调用模型。这个“兼容接口”设计极大降低了迁移成本，强烈建议你优先选择支持这种协议的框架。

5.3 部署之后还需要什么：API封装与性能观察

模型跑起来只是第一步，部署的价值在于被别人调用。你至少要能回答三个问题：响应时间多长、并发能撑多少、模型输出有没有被截断。

用 curl 测试一下 API 是最快的验证方式：

curl -s http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b", "messages": [{"role": "user", "content": "你好，请用一句话介绍你自己。"}] }'

我实际部署时重点关注两个指标：

• 首 token 耗时：用户发出请求到收到第一个 token 的时间，决定“感觉快不快”；
• 吞吐量：每秒生成多少 token，影响多人使用时的并发能力。

vLLM 本身提供了日志和统计信息，llama.cpp 则可以用--verbose参数观察 token/s。如果发现响应太慢，优先做两件事：把上下文长度限制到业务实际需要的最小值，以及考虑用更小规模的量化模型。

有一类问题经常在部署后爆出来：模型会“忘”了 system prompt。明明在系统提示里规定了输出格式，跑着跑着就开始不遵守。这是上下文被聊天记录占满导致的。处理方法很简单，在 API 层面对输入长度做限制，或者定期清空聊天历史。

6. 一个可持续更新的学习资料库清单：我的收藏夹目录结构

6.1 资料按四维组织：概念、论文、代码、项目

系统性入门到最后，考验的是资料管理能力。很多人的浏览器收藏夹几百个链接，真到用时一个也想不起来。我的做法是用一个本地仓库，把所有学习资料拆成五个目录：

LLM-Learning/ ├── 00_inbox/ # 临时收集，每周清理一次 ├── 01_concepts/ # 概念笔记：token、attention、RAG 等 ├── 02_papers/ # 论文笔记：每篇 300 字精华 ├── 03_code/ # 可运行的代码实验 ├── 04_projects/ # 完整小项目，对应学习路线各阶段 └── 05_assets/ # 图片、数据、模型下载链接汇总

00_inbox是缓冲池，刷到好文章先丢进去，周末统一整理。整理不是把链接复制一遍，而是用自己的话写一条笔记，再归入对应目录。没有经过自己表达过滤的资料，都不是有效学习。

6.2 必读论文、文档与代码仓库

入门阶段我不建议囤几十篇论文，下面这个清单已经足够支撑前三个月的学习：

论文方面，先读《Attention Is All You Need》第 3 节、QLoRA 论文前 4 页、LIMA 论文的实验部分。它们分别对应基础架构、高效微调、数据质量三个核心话题。

文档和课程方面，最实用的三份是：

• Hugging Face 官方 LLM Course：手把手带你跑推理、微调、部署，代码全部可运行；
• OpenAI 和 Anthropic 的提示词工程文档：虽然是英文，但例子非常经典，至今仍然受用；
• 各类开源模型的技术报告（model card）：比如 Qwen、Llama 等模型卡里的“使用建议”部分，往往比教程更贴近实战。

代码仓库方面，优先关注四个项目：

• transformers：通用模型加载与微调的主库；
• vLLM：GPU 高吞吐推理框架；
• llama.cpp：CPU 推理与量化方案；
• 各类微调工具框架（如 LLaMA-Factory 等）：把数据处理、训练、评估封装成一条命令，适合快速试验。

我不建议一上来就把所有项目代码都读一遍。先跑通官方 README 里的示例，再带着问题去看代码，效率高得多。

6.3 用“最小验证”检测学习效果

资料库攒得再多，不输出等于没学。我给自己定了一个规则：每学一个概念，必须在 48 小时内做一个最小验证。

比如，学完 RAG 后，我写了一个从本地 PDF 中提取答案的小工具；学完微调后，我用 100 条客服数据做了 QLoRA 实验，并对比微调前后的回答风格；学完本地部署后，我搭建了一个内部问答服务，让同事用网页实时提问。

这个习惯的价值在于：它能把“我感觉我会了”变成“我确实做到了”。当你积累了三到五个这样的小项目之后，再去看真实企业里的大模型需求，心里会非常有底。

我个人的经验是，做到这里基本就算真正入了门。剩下的任务，就是保持每周动手一次、每月产出一个完整小项目的节奏，不断把 00_inbox 里的新资料消化成 01_concepts 里的结构化笔记。大模型的技术演进不会停，但只要你手里的路径和资料库始终在迭代，就不怕跟不上。