大模型这个领域，现在最不缺的就是"资料"，缺的是"能把资料串成路线的人"。我经常收到私信问"我想入行大模型，该先看论文还是先学Python"，也见过不少朋友把模型API文档当成入门教材，结果学了两个月还在调参数。所以这篇内容，我不打算给你堆一堆链接，而是把"系统性入门"这件事拆成一条可以踩实的路径：先看路线，再补原理，接着上手提示词、微调、部署和评测，最后结合你自己的业务场景选一个方向钻进去。
这篇内容适合两类人：一类是完全零基础，但确定自己未来半年要往大模型方向走的技术从业者；另一类是做业务侧或产品侧，想搞清楚"大模型到底怎么落地、微调和部署到底在做什么"的非算法同学。你会看到完整的知识分层、每一层必须掌握的核心概念、以及我认为最值得投入时间的具体动作。内容偏实操导向，所有经验都来自我自己跑通项目的真实过程，没跑过的东西我不会写进来。
1. 先把路看懂：大模型学习路径的分层地图
很多人的学习计划失败，不是因为不够努力，而是因为把四层的东西混在一起学了。我把"大模型系统性入门"分成了六个层级，每一层解决不同的问题，学习的顺序和投入时间应当完全不同。
- 第一层：模型原理层。核心是Transformer架构、自注意力机制、分词器、预训练目标。这一层决定你对模型行为的理解深度，但不需要一开始就死磕。
- 第二层：使用层。核心是提示词工程、上下文工程、API调用、结构化输出。这一层是门槛最低、变现最快的能力。
- 第三层：微调层。核心是LoRA、QLoRA、全参微调、数据构造、训练脚本。这一层是很多工程师入行的第一份工作内容。
- 第四层：部署与推理层。核心是模型量化、推理加速、vLLM、llama.cpp、显存管理。这一层是企业落地时最缺人的环节。
- 第五层：评测与对齐层。核心是评测集设计、指标计算、幻觉检测、偏好对齐。这一层决定模型能不能上线。
- 第六层：应用架构层。核心是Agent框架、RAG、多模态应用、垂直领域解决方案。这一层是产品落地的形态。
初学者最容易犯的错误是直接从第三层开始——网上全是"LoRA微调实战"的教程，一上来就下载模型、跑到一半显存爆了，然后卡在环境的坑里一个星期，最后放弃。我的建议是：把第一层和第二层作为前两周的主线，把第三、四层作为第一个月的重点，第五、六层放到第二个月再碰。别觉得这个顺序慢，我见过太多人跳过前两层，结果微调完之后根本不知道loss降没降、模型变没变好，只会跑脚本，换个模型就抓瞎。
我给新手推荐的最小知识闭环是这样的：先搞明白"预训练-微调-对齐"这条链路里每一步在做什么，然后在API层面体验一次完整的提示词工程，再用开源小模型跑一次LoRA微调，最后用Ollama或llama.cpp完成一次本地部署。这四步走完，你会对"大模型"这四个字建立起真正的体感，后面再深入任何一个方向都有底气。
2. 底层原理：不懂Transformer的细节，后面全是空中楼阁
我知道很多人对"看原理"有畏难情绪，觉得那是研究员的事。但注意，我不要求你推导出attention公式，也不要求你从零训练一个模型——那确实没必要。但你至少得能回答这几个问题：为什么GPT类的模型能预测下一个词？"自注意力"到底在计算什么？为什么模型有上下文窗口的限制？这几个问题答不上来，你后面做提示词工程时只能靠猜。
2.1 自注意力机制到底在干什么
拿一个生活化的例子来说。你在读一句话"小明把球传给小红，然后她快速跑向球门"，理解"她"指谁，需要把前面的"小红"和后面的"她"关联起来。自注意力做的就是这件事：模型在处理每个词时，会同时看句子里的所有词，计算出每个词对当前词的"重要程度"，然后加权融合。这个过程不像RNN那样一个词一个词地按顺序往后传，而是所有词同时计算，所以它能捕捉长距离依赖，也天然适合并行计算。
大模型为什么强？把海量文本灌进去反复做这个"预测下一个词"的任务，模型内部会形成大量这样的关联模式，于是它学到的不只是词与词的搭配，而是句法、逻辑、常识、甚至某些推理能力的抽象表示。这也是为什么模型规模越大，涌现能力越强——参数多了，能够存储和组合的模式就更多更复杂。
做微调的时候我经常跟人解释：你在微调时改变的是模型表达这些模式的权重，而不是让模型重新学一遍语言。理解这一点很重要，因为它决定了你的微调数据量不需要像预训练那样海量，也决定了为什么LoRA这种"只改一部分参数"的做法能生效——模型底子已经在那儿了，你只需要推它一把，让它在特定任务上更偏向某个方向。
2.2 预训练、微调、对齐的完整链路
从原始文本到好用的对话模型，大模型要经历三个阶段：
预训练阶段。模型学习海量语料的统计规律，目标是预测下一个token。这个阶段产出的模型叫base model，比如你看到的各种不带对话前缀的开源权重。base model擅长续写和补全，但不擅长"做人"——你问它问题，它可能反问一句然后继续编。这个阶段成本极高，个人和中小公司基本不会碰。
监督微调阶段。用"用户指令-标准回答"这种成对的对话数据继续训练，让模型学会"该怎么回答问题"。这一步就是网上最常见的"微调"，也是LoRA、QLoRA发挥作用的地方。很多开源对话模型，本质上就是base model加了一套高质量的对话微调集。
对齐阶段。这一步用RLHF、DPO等方法，让模型的回答更符合人类偏好，比如更有礼貌、更诚实、更少有害内容。对绝大多数应用场景来说，这一步用户不需要自己碰GitHub上开源的对话模型已经帮你做完了，我建议前期不要纠结RLHF的数学推导，先知道它在整个流程里的位置就够了。
2.3 大模型八股文里真正该背的东西
网上流传的"大模型八股文"面试题，很多是又偏又旧的内容。我梳理了一下，真正有长期价值、值得花时间记牢的核心知识点其实就这几个：
- token和分词器的概念：为什么"一个中文词不等于一个token"，为什么token数影响计费和上下文长度。
- 上下文窗口的意义和限制：为什么模型输入长度有限，超出之后为什么回答质量会下降。
- 温度、top-p、top-k这些采样参数的含义：它们控制在生成时选词的随机性。
- 幻觉的产生原因：模型本质都在做概率预测，它没有"事实数据库"可以查。
- 量化是什么：把浮点数权重的精度降低，牺牲一点质量换显存和速度。
这些东西不深，但都是日常工作中每天要碰的概念。你先把这个闭环搞扎实，后面看任何源码、配置和文档都会顺畅很多。
3. 提示词工程与上下文工程：门槛最低、回报最高的能力
提示词工程在很多人眼里"不就是写话术吗"，但真正上手做项目之后你会发现，它其实是有方法论的。我甚至认为，对大多数做应用的人来说，把提示词工程和上下文工程练到极致，带来的收益比盲目做微调要高得多。
3.1 提示词的结构化写法
我建议所有人在写提示词的时候，都按这个框架来组织：角色定义 + 任务描述 + 输入输出格式约束 + 边界条件 + 示例。
举个例子，我在做一个法律文书助手时，初始提示词写的是"你是一个法律助手，请回答以下问题"，效果很一般。后来改成了这样：
角色定义："你是一名有十年实务经验的律师助理，擅长用简洁、准确的语言解释法律条文。"
任务描述："根据用户提供的案情描述，识别其中的法律关系，并给出对应的法律依据和风险提示。"
输出格式约束："请按以下结构输出：1. 案情要点摘要；2. 涉及的法律条文；3. 风险提示；4. 处理建议。总字数不超过500字。"
边界条件："如果案情描述信息不足，无法给出准确判断，请明确说明缺少哪些关键信息，不要自行假设。"
示例："下面是参考输出格式示例：..."
加了这个结构化改造之后，输出的稳定性和可用性提升非常明显。为什么？因为大模型的生成行为是概率性的，你把约束写得越清晰，模型在采样时就越容易落在你期望的区域内。
提示词工程还有一个常被忽略的维度，就是"追问策略"。很多人只写一条系统提示词就想得到完美输出，但实际项目中，我经常会在主提示词后面加一条"如果用户后续追加信息，请结合之前的回答进行修正，不要重复已给出的内容"。这种看似不起眼的小设计，能让多轮对话产品的体验上一个档次。
3.2 上下文工程：让模型在有限窗口里做正确取舍
上下文工程比提示词工程更进一步。它关心的不是"怎么把一句话写好"，而是"怎么把整个对话历史、检索结果和外部知识塞进有限的上下文窗口，并让模型关注最该关注的部分"。
这里有一个核心限制要提醒你：绝大多数模型对中部的信息关注度较弱，对开头和结尾的信息关注度最强。我在实测中试过，把关键指令放在长对话的中部，模型经常"忘掉"，但放在系统提示词开头，或者放在最近一轮用户消息的末尾，命中率会明显提高。
所以上下文工程的标准做法是：把不动的系统指令放在最前面；把本轮要处理的核心问题放在最后；如果中间有很长的检索插入内容，用明确的XML标签或分隔符包起来，并在系统指令里告诉模型"中间被 包裹的内容是检索结果，如果与用户问题无关，可以忽略"。这样等于给模型画了一条注意力路径。
另一个实用的做法是上下文压缩。对话超过一定轮数后，我会启动一个"摘要器"，把早期对话压缩成三五行摘要塞进上下文，替换掉原始轮次。这样既节省token，又避免模型在冗长历史中迷失。这些技巧理论上任何教程都会教你，但能不能在实际产品里用出效果，取决于你对模型注意力的体感是否灵敏，这东西只能靠多测、多对比。
4. 微调实战：从LoRA起步，用低成本跑通第一个微调项目
微调是很多人的"入行仪式"。但我必须先说一句败兴的话：大部分人第一次微调都会失败，不是因为代码写错了，而是因为数据没准备好、评估方式没想清楚就跑脚本。这一节我只讲两条线：一条是技术操作线，一条是"比技术更重要的数据与评估线"。
4.1 为什么LoRA是入门的第一站
先回答那个老掉牙的问题：微调为什么不用全参？全参微调确实效果上限更高，但它需要把整个模型的所有参数都更新一遍，显存需求极高。以7B模型为例，全参微调需要至少几张A100级别的卡才能跑得动，这显然不是入门阶段该碰的。LoRA的做法是在原始权重旁边加一串低秩矩阵，训练时只更新这些增量部分。
你可以理解为：原始模型已经是个经验丰富的老师傅，LoRA不是去改造老师傅的大脑，而是给老师傅递一张"场景便签"——比如"在这个客服场景里，你的措辞要更耐心"。
我建议的入门配置：一个7B或13B模型，一张24GB显存的消费级显卡（比如RTX 3090/4090），用QLoRA或LoRA跑微调。如果显存只有8GB或12GB，就选更小的模型，比如Qwen-2.5-7B量化版、Llama-3-8B的4bit版本。这些配置跑LoRA微调完全可行，而且足够你走通整个流程。
4.2 数据处理比训练脚本更值得花时间
我打个比分：如果把微调比作做饭，训练脚本是锅，超参数是火候，而数据是食材。大多数人失败是因为他们在网上找了一口好锅（抄了一个热门训练脚本），然后随便买了一点菜就往锅里倒——至于菜新不新鲜、切没切好、搭配合不合理，完全没管。
所以我在实操中的顺序永远是先做数据，再碰脚本。数据构造主要有这几种思路：
纯文本续写式：格式是"输入+期望续写"。适合模型对某个领域语言风格的适配。
指令问答式：格式是"指令-回答"对，也就是最标准的SFT数据。适合让模型学会按期望的方式回答用户问题。
对话式多轮数据：格式是一个列表嵌套的user/assistant交替轮次。适合做客服、陪伴类产品。
我踩过的坑是：直接拿几万条公开数据集往下灌，不做清洗。模型回答问题倒是流畅了，但经常输出"收到""好的呢"这类莫名其妙的语气词。后来我逐条检查才发现，公开数据里混杂了大量没用的客服模板。所以在做微调前，至少要做这几步清洗：去重、去除包含个人信息的内容、确保每条数据都是一个完整问题+完整回答、检查回答里有没有明显的逻辑断裂或答案被截断的情况。
我自己定的一个数据质量标准是：每条数据必须能回答出"用户在什么场景下会这么问"以及"标准回答解决了他什么诉求"。如果回答不出来，就删掉。
4.3 微调训练参数的参考与显存估算
我直接给出我常用的LoRA训练参数作为参考，用transformers和PEFT库，模型是Qwen-2.5-7B-Instruct，QLoRA 4bit配置：
- lora_r=64，lora_alpha=128。这个组合在我测过的任务里比较稳。如果你的任务很简单，r可以降到16或32，alpha约为r的两倍。
- 学习率2e-4，用cosine调度，warmup_ratio=0.1。
- batch_size设为1，梯度累积步数设为4到8。这个设置是为了在小显存上模拟出等效的batch效果。
- 训练轮数我一般用3轮，但强烈建议每轮结束后保存checkpoint，分别做评测，取效果最好的那版，而不是默认用最后一版。
- 序列长度不要无脑拉满。7B模型在512到1024这个范围基本够用，长度翻倍显存和训练时间也接近翻倍。
显存估算有个粗公式：LoRA微调时，模型权重本身（7B权重以4bit加载大约占4GB到5GB），加上优化器状态、梯度和激活值。QLoRA的核心优势就是把优化器状态放到了CPU上，所以10到16GB的显存就能跑7B模型微调。
如果你连这些都不想深究，只想跑通流程，我推荐直接找一套PEFT仓库里现成的SFT脚本改一下数据路径和模型路径。但注意，这只是"跑通"，离"能上线"还差得很远。真正决定微调效果上限的还是数据和评估设计，这个前面已经说过了。
5. 本地部署与推理优化：把模型装进自己的电脑
本地部署是另一个入行必须掌握的场景。很多人不理解为什么要本地部署，明明API调用多方便。原因就三类：数据隐私，不能把内部数据发给外部接口；成本，高频调用API的支出可能远超自部署；定制化，私有模型要接入特定服务或离线环境。
5.1 部署选型：llama.cpp、vLLM还是Ollama
我按场景推荐，不按"哪个最先进"推荐。
Ollama：个人电脑体验首选。安装简单，一条命令就能跑起来，支持OpenAI兼容接口。适合学习、测试、做小工具。缺点是并发能力和高级推理优化比较有限。
llama.cpp：追求极致轻量和CPU推理时的首选。它的核心优势是量化支持非常成熟，GGUF格式几乎是本地推理的事实标准。如果你只有MacBook或者一台没有独立显卡的老电脑，llama.cpp配合4bit量化模型，照样能跑。
vLLM：企业级高并发推理的首选。核心能力是PagedAttention，简单说就是显存管理做得更精细，能同时服务的请求数远超常规方案。如果你的部署场景是"对外提供API服务，同时几百个请求进来"，那vLLM基本是绕不开的。
我给新手的建议路径是：先用Ollama跑通一个模型，感受推理流程；然后学llama.cpp的量化方法，理解GGUF是怎么回事；最后再看vLLM的官方文档和性能指标，了解生产级部署需要做什么。这样三站走下来，部署的整个知识面就齐了。
5.2 量化与推理加速的核心逻辑
量化这个点值得单独讲讲。模型权重原本是16位浮点数，占2字节，7B模型光权重就14GB。把精度降到4bit，每个参数只占0.5字节，7B权重缩到3.5GB左右，普通电脑也能跑。代价是精度下降，生成质量会有小幅损耗，但现在的4bit量化算法已经做得很好，很多场景下肉眼几乎无法分辨差别。
我在项目中实际测过，用Qwen-2.5-7B-Instruct的4bit GGUF版本和一个16bit原版对比，在文本分类和摘要类任务上，输出差距很小；但如果你是做代码生成或者长逻辑推理，量化后的退化会明显一些。所以我总结的经验是：简单任务大胆量化，复杂任务留一点精度余量。
推理加速方面，除了vLLM的PagedAttention之外，还有几个常用手段：KV Cache优化，减少重复计算；连续批处理，把一个批次里的不同请求合并计算；前缀缓存，如果多个请求有相同的系统提示词，可以只算一遍。
5.3 从nano-vllm学推理管线，比走马观花读源码强得多
我在相关热搜词里看到"基于nano-vllm学习大模型推理关键功能"，这个思路我举双手赞成。vLLM本身代码量大，新手直接啃，很容易迷失在工程细节里。nano-vllm是vLLM的精简教学版，保留了两三个最关键的推理环节，代码量少得多，适合快速建立"模型推理时计算机到底在做什么"的完整心智模型。
我建议的学习路径是：跑通nano-vllm，找到它处理第一个请求的完整路径；对照vLLM的架构文档，把nano里"被砍掉"的工程细节补回来。这样你学到的不是一个黑盒，而是一条你亲手跟过的数据流。
6. 评测指标与调优方向：别再用"感觉变聪明了"做验收
微调做完、部署跑通，最容易被忽略的就是评测。我见过太多人跑完微调，问效果如何，回答说"感觉更听话了"。这种感觉在开发阶段自娱自乐可以，但你在企业里要上线一个模型，没有评测数据，任何安全或业务负责人都不可能放行。
6.1 指标族谱：不同任务看不同的数
大模型的评测指标分几类，别混着用：
生成类任务：常用ROUGE（摘要类）、BLEU（翻译类），还有基于语义相似度的Embedding距离。它们的共同思路是把模型输出和标准答案对比，看"像不像"。
分类类任务：看准确率、精确率、召回率、F1。我建议分类任务别只看准确率，因为类别不均衡时准确率会骗人。比如98%的样本是"正常"，2%是"恶意"，模型全预测"正常"也有98%准确率，但业务上这就是废物。
偏好类任务：用LLM-as-a-Judge，让GPT-4或Qwen-Max当裁判，给模型的多个回答打分排序。这个做法便宜又高效，但要注意裁判模型的偏见——它可能偏好更长的回答或更华丽的措辞，所以最好在打分prompt里明确"不要因为长度加分、不要因为风格加分，只看任务完成度"。
安全类指标：幻觉率、有害内容率、拒答率。做企业落地时，这些指标比ROUGE更关键。
像我之前在做垂直领域的大模型选型时，就遇到过"TCC还是WDDM"这种具体对比。这种对比不能靠嘴上感觉，必须跑同一组业务评测集。我当时的做法是：准备200条真实业务问题，把两个模型都跑一遍，按"正确率、完整性、格式合规率、幻觉数"四个维度标记结果，最后直接得出分值表。这个方法比看任何跑分榜单都靠谱。
6.2 从指标回到数据：评测驱动的闭环迭代
评测最大的价值不在于"打分"，而在于"发现问题然后改进"。我的标准流程是：
第一步，构造覆盖主要业务场景的评测集，至少200条，每条包含唯一ID。第二步，批量跑出模型输出，记录到表格里。第三步，人工或LLM逐条标注对错和问题类型。第四步，把失败案例归类，看是"理解错用户意图""格式不符合要求"还是"事实性错误"。第五步，针对最高频的失败类型去改提示词、补微调数据或者调部署参数。
这个闭环跑三轮之后，模型的效果通常会有肉眼可见的提升。所以记住一句话：评测集是你对模型最真实的需求描述，花在上面的每一分钟都值。
7. 方向选择与避坑：Agent、多模态、垂直场景怎么选
如果你已经走完了上面的路线，接下来就是选方向的问题。大模型的细分方向太多，比如Agent框架、RAG知识抽取、多模态模型、垂直行业应用和本地私有化部署。我的建议是：方向的选择取决于两个问题，一是你所在团队的资源条件，二是你自己想增强的能力长板。
先说说Agent。Agent框架这两年非常火，但你如果真的用Agent做过项目，就会发现它最大的难点不是调用模型，而是"确定性"。模型可能在第一步思路很清晰，第二步就开始自作主张设计新工具调用。所以我不建议入门者一上来就扎进Agent框架，除非你的目的是了解行业。热搜词里提到的"目前主流的agent框架有哪些"，我建议先看LangGraph、AutoGen、MetaGPT和通义的Agent框架文档，但不要贪多，关键是跑通一个端到端的Agent任务，理解"规划-行动-反馈-再规划"这个循环。
再说垂直场景。比如"如何用大模型分析不同股票的K线图""做CAD解析的大模型"这类，本质上都是"领域数据+RAG/微调+专业评测"的组合。K线图分析，核心是把K线形态抽成结构化描述，然后让模型基于这些描述做判断，而不是直接喂图片或者搓一段行情数字。CAD解析同理，关键是让模型学会读取图纸里的标注和结构。这类项目入手的顺序是：先做小样本的提示词方案验证，再决定要不要加RAG，最后才考虑微调。直接上微调是很多垂直场景失败的核心原因。
关于"大模型知识抽取框架OneKE"这种专项技术，它属于知识抽取这个细分赛道的利器。如果你做的是文档结构化、图谱构建这类任务，可以把它当成一个比自己拼Prompt更强的底座，但注意它可能不是通用最优解，最好拿自己的数据做一轮对比测试。
还有一件事我必须强调：虽然多模态大模型看着热闹，但如果你连文本模型的提示词工程和评测都没做过一轮，不建议直接跳到多模态。多模态的问题复杂度是文本的数倍，你连单模态下的"输入输出边界"都没建立清楚，拿到图像输入之后只会更混乱。
最后一件事：给自己定一个时间盒
大模型的学习最怕的不是难，而是"什么都想学但什么都没走完"。我个人的建议是给自己一个三个月的时间盒：
前两周，完成原理和提示词工程，每天至少做十组结构化的prompt对比实验。第三到四周，跑通一次LoRA微调和一次Ollama部署。第二个月，选一个垂直场景，做一个端到端小项目，比如企业文档问答、法律文书助手或本地私有化客服。第三个月，回到指标评测，把你做的小项目用评测集量化一遍，补齐之前跳过的数据清洗和迭代循环。
三个月结束之后，你会发现很多最初让你困惑的问题已经有了答案。比如"为什么我的输出不稳定"，那是因为你没有理解采样参数；"为什么微调之后效果更差了"，那是因为你的数据里有噪声；"为什么部署显存不够"，那是因为你没搞懂量化和KV Cache的关系。这些都只能靠你自己踩过一遍才真正属于你。
