学大模型这几年，我见过两种人。一种上来就问“微调用什么框架”“本地部署要多大显存”，环境折腾得飞起，但模型一旦出问题就抓瞎；另一种看起来进度很慢，先啃Transformer论文、搞懂token和训练流程，后面反而一路顺畅，遇到问题自己就能拆解。差距不在天赋，在知识基础。
我自己属于第一种，交了不少学费。早几年直接用在线API做应用，觉得“会调接口=会大模型”。后来转本地部署，才发现70B模型该选什么量化、显存怎么估算、为什么同一个提示词在不同模型上效果天差地别，这些问题全靠重新补课才慢慢想通。这篇就把我理解的大模型知识地基整理出来，适合刚入门想系统学的人，也适合已经会调API但总觉得哪里没搞懂的人。
1. 为什么知识基础决定你在大模型这条路的上限
1.1 三个真实场景暴露的差距
先说部署。同样一个13B模型，基础扎实的人会先算一笔账：模型权重FP16下大约26GB，INT4量化后降到7GB左右，再留出KV Cache和生成缓冲，24GB显卡基本能跑。于是直接选好量化等级，一条命令拉起来。基础薄弱的人呢？装完环境就启动，看到OOM报错，然后开始盲调参数，调了半天也不知道问题出在模型体积还是上下文长度。
再说微调。模型越调越差，基础扎实的人会去看数据格式、验证集loss、学习率和epoch数，能定位到是过拟合还是数据泄漏，甚至是LoRA作用模块没设置对。基础薄弱的人只能重复调参碰运气，跑完一轮发现效果更差，也不知道该往哪个方向改。
最后说应用开发。想让模型稳定输出JSON，前者会想到约束解码或者改提示词结构，后者只能在后端硬写正则，整天跟字符串较劲。这些场景不是个例，是社区里反复出现的共性问题。你可以说“我先跑通流程再补原理”，可以，但代价是每个问题对你来说都是新问题，每次都从零开始查，效率极低。基础是个杠杆，前期投入一点，后期省十倍的力。
1.2 大模型知识体系的三个层次
我习惯把大模型知识分成三层来看：
- 理论层：机器学习基础、深度学习网络结构、注意力机制、训练原理
- 工程层：数据处理、训练框架、推理优化、量化、部署
- 应用层：提示词工程、上下文工程、微调、Agent、RAG、多模态
这三层的更新速度完全不同。应用层三个月换一套最佳实践，今天流行的Agent方案半年后就可能被新范式替代；工程层一年迭代一个主流框架，去年还在讲加载策略，今年都在聊推理优化；理论层则慢得多，Transformer自注意力的核心思想从2017年到现在，依然是所有主流大模型的底座。
所以我给的建议很直接：主要精力放在理论层和工程层的底层逻辑上，应用层保持跟进、亲手做几个项目维持手感就够了。知识基础的重要性不在于考试题答得漂亮，而在于它能让你在大模型应用、调优、排错时，拥有从原理出发定位问题的能力。这件事，越往后越值钱。
2. 理论层地基：绕不开的核心知识清单
2.1 Transformer架构与注意力机制
2017年Transformer架构提出来的时候，没人想到它会统治整个生成式AI领域。到现在，GPT系列、Llama系列、Qwen、DeepSeek，底子全是Transformer。理解Transformer，核心是理解自注意力机制。
自注意力的本质，是让序列中任意两个位置之间可以通信，通信强度由内容相关性决定。传统RNN只能顺序往下传，LSTM虽然改进了长期记忆，但长距离依赖依然吃力；Transformer用自注意力一次看到整个序列，从机制上绕开了这个问题。
用一个生活化类比：你读“小明因为考试没考好所以被妈妈批评了”，处理到“被批评”这个词的时候，自注意力会自动把权重分配给“小明”和“考试没考好”，因为语义上它们最相关。这就是Transformer擅长捕捉长距离依赖的原因。
实际操作中，和自注意力绑定的几个概念必须搞清楚：
- QKV：Query、Key、Value，粗暴理解是“我要找谁、谁最相关、找到后取什么内容”
- 多头注意力：多个头并行，有的关注语法，有的关注指代，有的关注语义相似，表达能力更强
- 位置编码：自注意力本身不区分顺序，必须把位置信息揉进输入
- 因果掩码：生成模型里只能看过去的token，不能偷看未来的内容
这些概念不搞懂，你看工程配置会一头雾水。比如推理框架里的max_model_len参数为什么要设置？因为KV Cache会随序列长度增长，你把窗口调大，显存立刻就来找你讨债。没有理论打底，参数对你来说永远只是“照着填的数字”，出了问题完全不知道该动哪里。
2.2 预训练、微调与对齐：模型能力的三次成型
大模型不是天生就会“对话”的，它的能力是分阶段叠加出来的。
第一个阶段是预训练。模型在海量语料上做自监督学习，最常见的目标是预测下一个token。这个阶段模型学到的是语言规律和世界知识，回答“模型为什么会写句子”“为什么懂常识”都在这里，但成本极高，普通个人和中小团队基本不碰。
第二个阶段是监督微调，简称SFT。用人工标注的指令数据训练模型学会遵循指令，从“会写句子”变成“会回答问题”。你在本地微调玩的大部分场景都属于这一类。
第三个阶段是对齐，常见做法是RLHF或DPO。用人类偏好数据进一步优化，让模型更安全、更有用、少胡说八道。
这里有个常见的认知误区：很多人以为微调是在教模型新知识。其实SFT阶段主要教的是行为模式，不是知识。你想让模型掌握某个垂直领域的新知识，靠几万条SFT数据远远不够，除非数据里明确包含知识内容，否则模型只是学会了怎么组织回答。理解错这一点，你做微调就很容易失望。
2.3 损失函数、梯度下降与学习率
这一块很多人一听数学就头大，我建议先建立直觉再补公式。
损失函数衡量模型预测和真实目标之间的差距，训练就是不断让这个值变小。梯度下降是这么一回事：把损失值想象成一片地形，模型参数是你的位置，梯度告诉你往哪个方向走下降最快，沿着梯度的反方向更新参数，就是一次梯度下降。
再说学习率，它对应“步子大小”。步长太大，可能一脚跨过山谷直接跳进山沟；步长太小，走到天黑也到不了山脚。实际调参时学习率一般在1e-4到1e-5之间，配合warmup（先小步热身后再正常走）和cosine退火（后期逐渐缩小步子）使用。如果你训练时loss一直震荡不降，第一反应就该怀疑学习率过大。
我第一次做LoRA微调时，把学习率设成1e-3，结果loss曲线跟心电图似的。后来降到2e-4，几轮之后稳定下降，输出质量明显提升。这种东西，教程里不会替你踩，但原理懂了就能少走弯路。
2.4 Token、上下文窗口与中文的特殊性
Tokenization是把文本切成模型能处理的最小单位。英文通常一个单词约一个token，中文一个汉字可能是1到2个token。这意味着相同长度的中文内容，token数往往比英文多，显存和推理耗时也跟着涨。
上下文窗口是模型能一次性看到的token上限。厂商宣传的128K、256K听着唬人，实际用的时候要注意三个问题：
- 输入接近窗口上限时，推理性能明显下降，等待时间成倍拉长
- 生成内容也要占用窗口，所以输入不能推满，要给输出留余地
- 超长上下文场景下，模型对中间部分的关注会衰减，行业里叫“lost in the middle”
所以别迷信大窗口，实用派的做法是：长文档先用检索切成相关片段，再喂给模型。这也是RAG存在的意义之一。
3. 工程层基础：从部署到微调的实操细节
3.1 推理框架怎么选：Ollama、llama.cpp、vLLM
本地跑模型第一步就是选框架。我给一个按场景区分的参考：
- Ollama：开箱即用，适合第一次接触本地部署的人。一条命令拉模型、起服务，底层基于llama.cpp，CPU也能跑
- llama.cpp：更偏底层，GGUF量化格式就是它定义的体系，手动控制强，适合做二次开发和深入调优
- vLLM：吞吐量高，支持PagedAttention和连续批处理，适合服务端高并发场景，但对显存要求更高
- TensorRT-LLM：NVIDIA GPU专属，性能优化上限最高，适合生产环境花时间打磨
如果你是新手，我建议的路径是：先用Ollama把模型跑起来，感受一下不同量化等级和显存的关系；再换llama.cpp手动加载，理解-c上下文长度、-nglGPU层数这些参数的意义；最后再上vLLM研究性能优化。这个路径的好处是每一步都能看到因果，不会一步跳到抽象层面。
3.2 量化：显存不够时最实用的技术
量化是把模型权重从高精度压缩到低精度，牺牲一点精度换显存。常见等级和效果差异可以参考下面这张表：
| 精度 | 位宽 | 70B模型近似显存 | 适用场景 |
|---|---|---|---|
| FP16 | 16bit | 约140GB | 效果最佳，基本只能集群部署 |
| INT8 | 8bit | 约70GB | 高质量推理，单卡或双卡可跑 |
| INT4 | 4bit | 约35GB | 个人部署主流，效果仍可接受 |
量化的本质是精度和资源的权衡。日常对话类任务，INT4基本无感；但涉及代码生成、数学运算、长文本结构还原时，降精度的影响会更明显。我的经验是：能上INT8就不勉强INT4，除非显存实在紧张。
另一个常见误区：量化压缩的是权重，KV Cache依然是较高精度存储。所以窗口越大，KV Cache占用越高，这部分在量化之后也不会省。很多人在24GB显卡上部署13B模型，INT4量化后权重只占7GB，但把上下文拉到64K照样OOM，问题就出在缓存上，而不是模型本身。
3.3 一套能落地的LoRA微调流程
微调是大家最想上手的一环，我以LoRA为例讲一套完整流程，你照着走基本能跑通。
第一步，数据准备。把任务数据整理成对话模板，比如instruction和output字段。数量上起步几千条，质量远比数量重要，宁可用一千条干净数据，也不用一万条带噪音的。
第二步，选基座。挑一个评测过的主流开源模型，中文场景优先考虑Qwen系列，英文场景Llama系列也很稳。不要选太小众的模型，社区资料少，出了问题找不到人问。
第三步，配置环境。推荐transformers加peft库，一张至少16GB显存的显卡；没有显卡就上云服务，按小时计费，跑一次实验几十块，比买卡划算。
第四步，设置训练参数。LoRA的r（秩）通常设8到32，学习率2e-4左右，epoch数2到5个，max_length根据任务文本长度设置，通常512或1024。
第五步，训练与观察。重点看验证集loss，训练loss在降、验证loss不降反升，就是过拟合，需要减少epoch或降低重复数据。训练结束后用merge_and_unload把LoRA权重合并回主模型，再量化部署。
这套流程我踩过三个坑：一是数据里有大量空行和漏字段，格式化时直接炸掉；二是tokenizer的padding方向设置不对，训练时警告刷屏；三是LoRA作用模块没设好，结果只微调了embedding和lm_head，调完效果等于没调。你提前知道这些，就能避开大部分新手期的心智损耗。
3.4 提示词工程与上下文工程：两个容易混淆的方向
提示词工程调整的是给模型的指令表达，让模型更懂你要什么；上下文工程侧重的是给模型喂什么信息，典型代表是RAG，把检索到的文档放进上下文，让模型基于这些内容回答。
通俗地说，提示词工程解决“怎么说”，上下文工程解决“知道什么”。它们经常配合使用：RAG检索到文档之后，还要用提示词约定“只基于给定文档回答，不要脑补”，否则模型还是会忍不住自由发挥。
实操里最值得掌握的技巧有三个：
- 明确输出格式：少说“随便写写”，多说“以Markdown列表输出”“只输出JSON”
- 给示例：一个few-shot示例比十句抽象描述更有效
- 把复杂任务拆步骤：让模型先分析、再判断、最后输出，比一次性要结果稳定得多
这些技巧看着简单，但很多人上来就试图用一条提示词解决一切，效果不好就开始怀疑模型能力，其实是技巧没到位。
4. 应用层绕不开的坑：常见问题排查速查
4.1 显存溢出：部署翻车的第一大原因
OOM报错几乎是每个本地部署玩家都见过的。排查顺序我固定是三条：
- 确认模型参数规模和量化精度，先估算权重显存
- 检查上下文长度设置，
max_seq_len设太大，KV Cache超限 - 检查框架额外开销，vLLM需要预留显存做连续批处理和调度
我记得一个典型案例：24GB显卡跑13B模型，INT4量化权重只占7GB，怎么算都够了，但一推理就OOM。最后发现是上下文设置成64K，KV Cache把剩下的显存全部吃光。把窗口降回8K，问题立刻消失。所以部署前先算账，别上来就拉高参数。
4.2 微调之后模型“变笨”了，怎么办
这是微调玩家最头疼的问题。模型本来挺聪明，微调完反而不会说话了。常见原因有三个：
- 灾难性遗忘：全参微调把通用能力覆盖了，解决方式是改用LoRA、降低学习率、在训练集里混入通用数据
- 数据泄漏或格式混乱：训练数据里混入答案、标签错误，模型学的是噪声
- 过拟合：训练集loss降、验证集loss升，epoch太多或者数据重复太多
我自己定了一条规矩：先做小规模验证，用几百条数据、1到2个epoch跑通全流程，确认数据和代码没问题，再扩大训练规模。一次跑几十小时最后发现是数据问题，真的会怀疑人生，慢就是快。
4.3 模型输出格式总是不稳定，怎么治
让模型输出JSON，它非要加一行解释；让模型输出列表，它偏要换行乱排。这个问题在应用开发里特别常见，我的处理优先级是这样的：
- 提示词里写“只输出JSON，不要任何额外说明”，多数模型能听懂
- 使用结构化生成工具，比如Outlines、jsonformer，从解码层锁死格式
- 解析端做容错处理，不要指望模型永远听话，后端正则或者带默认值的解析逻辑要备着
这三个手段可以叠加使用，效果最稳。单靠提示词约束，实测下来总有5%到10%的概率翻车，生产环境必须上第二层甚至第三层保险。
4.4 别把上下文窗口当“内存条”
有人觉得窗口越大越好，拼命拉长，结果又慢又贵，效果还不好。原因很简单：长输入会显著增加推理耗时和显存占用，而且模型对超长输入的中间部分关注度会下降。
所以处理长文档时，我更推荐先检索、再裁剪、再输入，控制送进上下文的信息量。这个思路不仅能省资源，回答质量反而更高。窗口大是你的能力上限，不是推荐用量。
5. 一条实实在在的大模型学习路线
5.1 三步走：从能跑通到能排错
根据我自己和身边人的经验，给你一个可以落地的时间表：
第一步，约1个月。搞懂理论层核心概念，跑通一个最小demo。不用去啃完整数学推导，先把Transformer、token、训练流程过一遍，目标是能解释清楚“模型为什么能生成文本”。
第二步，约2到3个月。本地部署一个开源模型，动手做量化、跑一次LoRA微调、做一个小型RAG项目。这个阶段的目标不是做出产品，而是踩坑，踩过坑才算真正学会。
第三步，长期。持续跟进应用层变化，但每次复盘时固定回到理论层归因。比如看到一个框架新功能，试着问自己“它是不是在缓解某个底层问题”，想通了，技术路线就串起来了。
5.2 几个过来人才会说的实在建议
- 不要只追新模型。模型天天发，但Transformer自注意力这套底层逻辑几年没变过。地基打牢了，新模型无非是参数组合不同，上手成本极低。
- 一定要亲手部署和微调。看一百篇教程不如自己跑一次OOM、降一次精度，真实感受比任何讲稿都深刻。
- 重视数据。大模型的下限是数据决定的，训练、微调、RAG都一样。数据脏了，后面所有环节都是白搭。
最后说点个人体会。我见过太多人花大把时间追新模型、换新框架，结果遇到问题就卡壳；反而是那些肯花一个多月把注意力机制和训练原理啃下来的人，后面无论写代码、调模型还是做产品，都比我这个野路子出身的人轻松得多。知识基础这个东西，前期看不见收益，但它是唯一能陪你走完整个大模型技术周期的资产。别怕慢，地基打得越牢，你后面跑得越快。
