大模型这个词，从2023年火到现在，已经不算什么新鲜概念了。但真正能把"预训练→微调→对齐→Agent"这条链路讲清楚的人，其实没想象中那么多。我见过太多人一上来就冲着"微调实战"去，结果连基座模型是怎么来的、为什么要做指令微调、Agent和普通LLM调用到底差在哪都说不明白，最后调出来的东西要么答非所问，要么根本没法上线。
这篇东西我想换个讲法。不按论文综述那种"先定义再分类"的路子走，而是按一个从业者真正会经历的路径来拆：一个模型从零到能用、再到能自己干活，中间到底发生了哪些事，每一步为什么必须存在，以及在实际项目里哪些环节最容易翻车。不管你是刚入门想搞明白大模型学习路线，还是已经在做Agent开发想回头补基础，这篇应该都能给你一些能直接用的东西。
1. 预训练：大模型能力的"地基"到底是怎么打的
1.1 预训练的本质是压缩，不是记忆
很多人对预训练有个误解，觉得模型是在"背"互联网上的内容。实际上预训练干的事情更接近有损压缩：把海量文本里反复出现的语言规律、事实关联、推理模式，压缩进几百亿甚至上千亿个参数里。它记住的不是某句话，而是"什么样的词在什么语境下大概率会一起出现"。
这就解释了为什么预训练语言模型（比如BERT、RoBERTa这类）能理解语义，也能解释为什么模型有时候会"一本正经地胡说八道"——它是在按概率生成最像答案的东西，而不是在数据库里查。理解这一点非常关键，因为后面所有的微调、对齐、Agent设计，本质上都是在跟这个"概率生成"的特性打交道。
预训练阶段的核心目标函数其实很朴素，就是下一个token预测。给定前面的词，预测下一个词是什么。听起来简单，但当语料规模到了万亿token级别、模型参数到了千亿级别，这个简单目标就涌现出了上下文学习、指令遵循、多步推理这些能力。这也是为什么大家说"规模本身就是一种方法"。
1.2 数据、算力、架构：预训练的三根支柱
预训练能不能成，取决于三件事配合得好不好。
数据这块，质量比数量更重要。早期大家拼的是token总量，后来发现重复数据、低质网页会拖垮模型。现在主流做法是经过多轮清洗、去重、质量过滤，再按领域配比混合。中文预训练尤其要注意，纯中文语料往往不够，通常会用中英混合来提升模型的通用推理能力。
算力这块，预训练是典型的"烧卡"环节。一个中等规模模型的预训练动辄需要几百张GPU跑几周。这里有个常被忽略的点：并行策略的选择直接决定训练效率。数据并行、张量并行、流水线并行怎么组合，取决于模型大小和集群拓扑。选错了，GPU利用率可能只有30%，等于白烧钱。
架构这块，现在基本是Decoder-only的Transformer一统天下。但细节上仍有讲究，比如位置编码用RoPE还是ALiBi、注意力用MHA还是GQA、激活函数用SwiGLU还是GeLU，这些选择会影响长文本能力和推理成本。GQA（分组查询注意力）现在几乎是标配，因为它能在几乎不损失效果的前提下大幅降低推理时的显存占用。
1.3 预训练模型的"拿来主义"：什么时候该用现成的
绝大多数团队和个人根本不需要从零预训练。原因很简单：成本太高，收益不确定。更务实的做法是拿开源基座模型做起点，比如Qwen、Llama系列，或者用RoBERTa中文预训练模型做NLU类任务。
这里有个选型经验：看你的任务离基座模型的能力分布有多远。如果只是做文本分类、情感分析这类判别任务，一个小一点的预训练模型加微调就够了，没必要上大模型。如果要做生成、推理、多轮对话，那才需要考虑大参数量的基座。选型时可以参考Open LLM Leaderboard这类公开榜单，但别迷信榜单——榜单测的是通用能力，你的业务场景可能完全不在它的考察范围内。
提示：预训练阶段产生的基座模型（Base Model）只是"会续写"，不会"听指令"。你直接问它问题，它可能给你续写出一堆类似问题的句子。这就是为什么必须有后面的指令微调。
2. 微调：把"会说话"的模型变成"会干活"的模型
2.1 全量微调、LoRA、QLoRA：三种路线的取舍逻辑
微调是大模型落地最核心的环节，也是热词里出现频率最高的部分。但很多人一上来就问"用哪个框架"，其实应该先问"用哪种微调方式"。
| 微调方式 | 显存需求 | 效果上限 | 适用场景 |
|---|---|---|---|
| 全量微调 | 极高（需多卡） | 最高 | 数据量大、任务与基座差异大、有充足算力 |
| LoRA | 中等 | 接近全量 | 大多数业务场景的首选 |
| QLoRA | 低（单卡可跑） | 略低于LoRA | 个人开发者、显存受限、快速验证 |
全量微调是更新模型全部参数，效果最好但代价最大。一个7B模型全量微调，光优化器状态就要占掉大量显存，通常需要多卡并行。
LoRA的思路很巧妙：不动原模型参数，而是在注意力层旁边挂两个小矩阵，只训练这两个小矩阵。这样可训练参数能降到原来的百分之几甚至千分之几，显存需求大幅下降，效果却能接近全量微调。这也是为什么LoRA微调实战教程满天飞——它确实是性价比最高的方案。
QLoRA更进一步，把基座模型量化到4bit再挂LoRA，让单张消费级显卡也能微调大模型。代价是训练速度慢一些，效果可能略打折扣，但对于验证想法、做原型来说完全够用。
选型逻辑其实就一句话：先看显存，再看数据量，最后看效果要求。显存够就LoRA，不够就QLoRA，数据量特别大且任务特殊才考虑全量。
2.2 数据质量决定微调上限，这话不是鸡汤
我见过太多人把精力全花在调参上，结果数据一塌糊涂。微调的数据量不需要很大，几千到几万条高质量样本往往就能出效果，但质量必须过硬。
什么叫高质量？三个标准：指令清晰、回答准确、格式统一。指令清晰是指用户会怎么问，你的训练数据就要怎么问，别用书面语去训练一个要应对口语提问的模型。回答准确是指答案本身不能有错，模型会学到你数据里的错误。格式统一是指如果你希望模型输出JSON，那训练数据里就全是JSON，别混着来。
还有一个坑：数据分布要贴近真实使用场景。如果你训练数据全是单轮问答，上线后用户问多轮，模型表现会断崖式下跌。所以构造数据时要有意识地覆盖多轮、带上下文、带干扰信息的场景。
2.3 微调工具框架怎么选：别被工具绑架
主流微调工具框架现在主要有几类：HuggingFace的PEFT+Transformers、LLaMA-Factory、Axolotl、Unsloth等。选哪个？
- PEFT+Transformers：最灵活，适合要深度定制训练逻辑的场景，但代码量大，新手不友好。
- LLaMA-Factory：开箱即用，配置文件驱动，支持大量模型和微调方式，适合快速上手和标准化流程。
- Unsloth：主打速度和显存优化，单卡微调体验很好，适合个人开发者。
- Axolotl：配置灵活，社区活跃，适合有一定经验的团队。
我的建议是：先用LLaMA-Factory跑通一个LoRA微调，理解整个流程，再根据需求换工具。别一上来就追求最先进的框架，工具是为你服务的，不是反过来。
基于Ollama的模型微调代码现在也很流行，因为Ollama把模型管理和推理都封装好了，微调完直接能跑。但要注意，Ollama更适合推理部署，微调还是得用专门的训练框架，两者配合使用。
2.4 微调规模减少：小数据也能出效果的技巧
热词里有个"微调规模减少"，这其实是个很实际的问题。数据不够怎么办？
几个实用技巧：数据增强（同义改写、回译）、课程学习（先易后难）、参数高效微调（LoRA本身就是减少可训练参数）、利用基座能力（把任务拆解成基座已经会的子任务）。还有一个常被忽略的点：微调不一定要覆盖所有能力，你可以只针对某个特定技能做微调，其他能力靠提示词工程补。
3. 对齐与提示工程：让模型"说人话、办人事"
3.1 从SFT到RLHF：对齐到底在解决什么
指令微调（SFT）之后，模型已经能听懂指令了，但还不够"讨人喜欢"。它可能生成有害内容、可能啰嗦、可能不按人类偏好来。这时候就需要对齐。
对齐的经典路线是RLHF（基于人类反馈的强化学习）：先训练一个奖励模型来模拟人类偏好，再用强化学习让模型去最大化这个奖励。后来出现了DPO等更简单的方法，直接用偏好数据优化，省掉了奖励模型和强化学习那套复杂流程。
对齐解决的核心问题是：让模型的输出分布向人类偏好靠拢。但这里有个微妙的平衡——对齐过头会让模型变得"过于安全"，什么都不敢说，反而丧失实用性。所以对齐数据的设计非常讲究，既要覆盖安全边界，又不能把有用性压没了。
3.2 提示词工程与上下文工程：不是玄学，是接口设计
很多人把提示词工程当成"咒语"，觉得是碰运气。其实它本质上是在跟一个概率模型做接口设计。你给的上下文越清晰、越结构化，模型越容易命中你想要的输出分布。
上下文工程比提示词工程更进一步，它关注的是整个上下文窗口里放什么。包括系统提示、历史对话、检索到的文档、工具返回结果等等。这里有个关键认知：上下文窗口是有限资源，放什么比放多少更重要。塞一堆无关信息进去，反而会稀释关键信号。
LLM的token机制这里值得展开说一下。热词里那个"key我是谁、query我在找什么、value我能提供什么"其实是对注意力机制的通俗解释。每个token会生成query、key、value三个向量，query去和所有key算相似度，决定该关注哪些位置，然后加权聚合对应的value。理解这个机制，你就明白为什么关键信息放在上下文开头或结尾效果更好——中间位置容易被"注意力稀释"。
3.3 LLM as Judge：用模型评估模型
当你的微调模型或Agent上线后，怎么评估效果？人工评估太慢，传统指标（BLEU、ROUGE）又测不准生成质量。这时候LLM as Judge就派上用场了：用一个更强的模型来给输出打分。
但这里有个坑：Judge模型本身有偏好偏差。它可能偏爱更长的回答、更华丽的措辞，而不是真正准确的回答。所以用LLM as Judge时，评分标准要写得非常具体，最好给出正例和反例，并且定期用人工评估校准。
4. Agent：让大模型从"回答问题"到"完成任务"
4.1 Agent和普通LLM调用的本质区别
普通LLM调用是"一问一答"，Agent是"给个目标，自己想办法完成"。区别在哪？
普通调用：用户问→模型答→结束。 Agent：用户给目标→模型规划→调用工具→观察结果→调整计划→再调用→...→完成。
核心差异在于循环和工具使用。Agent会反复迭代，每次根据环境反馈调整下一步动作。这就要求模型具备规划能力、工具调用能力、以及从失败中恢复的能力。
热词里问"harness和agent区别"，简单说：harness更像是给模型套的一层执行框架，负责调度和约束；Agent则强调自主性，能自己决定下一步做什么。实际项目里两者往往结合使用——用harness保证可控性，用Agent提供灵活性。
4.2 Agent框架选型：别为了框架而框架
现在Agent框架很多，LangChain、LlamaIndex、AutoGPT、CrewAI等等。选型时问自己三个问题：
- 我的任务需要多复杂的规划？简单任务用轻量框架甚至手写循环就够了。
- 我需要多少工具集成？框架的价值很大程度在于工具生态。
- 我对可控性要求多高？越自主的Agent越难调试，生产环境往往需要更多约束。
吴恩达的Agent教程里有个观点我很认同：Agent的核心不是框架，而是工作流设计。把任务拆解成清晰的步骤，定义好每步的输入输出和失败处理，比选什么框架重要得多。
4.3 AI Agent怎么扛并发：工程问题比模型问题更棘手
这是热词里一个非常实际的问题。Agent扛并发难在哪？
第一，每个请求可能触发多次模型调用和工具调用，延迟叠加。第二，Agent有状态，多轮对话的上下文要维护。第三，工具调用可能成为瓶颈，比如数据库查询、外部API。
应对思路：异步化（模型调用和工具调用都异步）、缓存（相同或相似的中间结果缓存）、限流与降级（高峰期降级到简单模式）、状态外置（把会话状态放到Redis等外部存储，让Agent服务本身无状态可水平扩展）。
还有个容易被忽略的点：Agent的并发瓶颈往往不在模型，而在工具。一个慢查询就能拖垮整个链路，所以工具层要有超时和熔断。
4.4 多模态与Spatial LLM：Agent的下一个前沿
多模态大模型让Agent能"看"和"听"，Spatial LLM则让它理解空间关系。这些能力在机器人、自动驾驶、AR/VR场景里非常关键。
CLIP模型微调是连接视觉和语言的经典方案，通过对比学习让图像和文本在同一语义空间对齐。实际做多模态Agent时，通常是视觉编码器+LLM的组合，视觉部分负责感知，LLM负责推理和决策。
但多模态Agent的工程复杂度比纯文本高一个量级：数据标注成本高、推理延迟大、错误传播链更长。所以我的建议是，先把纯文本Agent做扎实，再考虑加多模态。
5. 部署与落地：从Demo到生产之间隔着什么
5.1 本地部署大模型：个人电脑智能化的现实路径
本地部署大模型现在越来越可行，Ollama、llama.cpp、vLLM这些工具把门槛降得很低。个人电脑上跑一个7B或14B的量化模型，日常问答、写作辅助、代码补全完全够用。
关键决策点是量化。4bit量化能把显存需求降到原来的四分之一左右，效果损失通常在可接受范围内。但要注意，量化对不同任务的影响不一样，生成任务通常比判别任务更敏感。
本地部署的价值在于数据不出本地和无API成本，代价是能力上限受硬件限制。所以务实的做法是混合：敏感任务本地跑，复杂任务走云端。
5.2 大模型部署的显存与并发计算
部署时最常被问的就是"我这卡能跑多大模型"。粗略估算：推理显存 ≈ 参数量 × 精度字节数 + KV Cache。7B模型FP16推理约需14GB，4bit量化约需4GB。KV Cache随上下文长度和并发数增长，长上下文场景要特别留意。
并发方面，vLLM的PagedAttention是个关键优化，它把KV Cache分页管理，大幅提升显存利用率和吞吐。如果你的场景并发高，vLLM基本是首选。
5.3 大模型选择：TCC还是WDDM这类问题的本质
热词里"大模型选择tcc还是wddm"其实问的是Windows下GPU计算模式的选择。TCC模式专用于计算任务，WDDM是图形驱动模式。做训练和推理，TCC通常性能更好，但WDDM兼容性更好、能同时驱动显示。这个选择取决于你的机器是专用计算节点还是日常工作站。
这类问题的本质是：部署环境决定了你的技术选型边界。别脱离环境谈最优方案。
6. 一条务实的大模型学习路线
说了这么多技术点，最后落到学习路径上。我的建议是按项目驱动，别按知识图谱驱动。
第一阶段，跑通推理。用Ollama或类似工具在本地跑起一个模型，理解token、上下文、温度这些基本概念。
第二阶段，做一次LoRA微调。用LLaMA-Factory或Unsloth，拿几百条自己的数据，微调一个小模型，感受数据质量对结果的影响。
第三阶段，搭一个简单Agent。手写一个"规划-调用-观察"的循环，接一两个工具，理解Agent的工作机制。
第四阶段，做部署优化。学vLLM、量化、并发处理，把前面的东西推到能用的状态。
这条路线的好处是每一步都有可交付的成果，不会陷入"学了一堆概念但什么都不会做"的困境。大模型这个领域变化快，但底层逻辑相对稳定，把预训练、微调、对齐、Agent这条主线吃透，新东西出来你也能快速接上。
我在实际项目里最大的体会是：别追新，追透。一个LoRA微调做扎实，比浅尝辄止试十个框架有价值得多。模型能力是概率给的，但工程能力是自己练出来的。
