大模型知识基础：从Token到Transformer再到微调部署

这两年我经常被朋友问到AI大模型这么火我也想学但该从哪里下手每次我都会反问一句你知道大模型为什么能回答你的问题吗很多人会愣住然后给我一个回答——“因为它训练过很多数据。”这个回答没错但离“基础”还差得远。我见过不少追着热点跑的人今天学提示词明天看微调后天折腾本地部署折腾了几个月还是说不清transformer、上下文窗口、量化这些词之间的关系。问题不在于热点太多而在于知识基础太薄。所以这篇文章我打算把“大模型知识基础”这件事掰开揉碎讲清楚说说这个领域到底在学什么为什么基础比追新更重要以及我实操下来觉得最靠谱的补基础路线。1. 先想清楚大模型这个领域到底在学什么很多人学大模型容易犯一个毛病把“会用API”当成“懂大模型”。这就像开过几天车就觉得自己是汽车工程师结果引擎盖一开全是问号。大模型不是一款软件而是一整套技术栈从用户提问到模型吐字中间隔着数据处理、模型训练、推理部署、应用封装好几个层次。不同的人在不同的层次上工作需要的知识结构完全不同。1.1 从“会聊天”到“会干活”大模型分四个层面我习惯把大模型的知识体系分成四个层面方便刚入门的人对照定位。第一个层面是应用层。这个层面做的事情是“调用现成的模型来解决问题”比如用提示词让模型写文案、做翻译、整理资料或者通过API把模型能力接进自己的产品里。这个层面不需要搞清楚模型内部怎么运行但需要搞清楚怎么提问、怎么设置参数、怎么处理返回结果。第二个层面是模型行为层。这个层面的人已经开始留意“模型为什么有时候胡说八道”“温度调高一点会怎么样”“上下文窗口满了怎么办”这类问题。你需要理解模型的输入输出机制、概率生成逻辑、局限性甚至要会一点提示词工程和上下文工程。这个层面是绝大多数做应用的人需要长期待的地方。第三个层面是训练与微调层。这个层面要做的是“让模型适应特定领域”比如用公司内部的文档微调一个客服模型或者用几千条数据做指令微调。你需要知道数据集长什么样、训练参数怎么设、过拟合怎么办、评估指标怎么看。第四个层面是原理与研发层。这个层面涉及transformer架构、注意力机制、分布式训练、模型并行、量化推理等底层内容。这个层面不是人人都需要但它会反过来帮你理解前三个层面里出现的各种现象。我见过的人里绝大多数都被卡在“想直接从应用跳到原理”这一步。这其实没必要。知识基础的作用不是让你一夜之间变成算法工程师而是让你在任何一个层面都能站稳脚跟往上走的时候脚下不踩空。1.2 为什么知识基础比追热点更值钱大模型领域的热点更新速度非常快。我自己关注过的关键词就有“提示词工程”“RAG”“Agent”“微调实战”“本地部署”“多模态大模型”“vLLM部署”等等。每过几个月就有新概念冒出来看着很热闹但如果你没有基础知识这些热点对你来说就是一堆漂浮的碎片。打个比方热点是树叶基础是树根。树叶每年换一批树根却一直在土里吸收养分。你今天追“上下文工程”明天追“Agent框架”后天追“微调技术”如果说不清预训练和微调的区别不知道token是什么不理解为什么显存不够那你追再多热点也只是在背名词。真正出问题的时候——比如模型输出不稳定、部署环境报错、微调效果不理想——你连排查的入手点都找不到。知识基础还决定了一个人能走多远。我见过很多人用提示词技巧把模型调得很听话可一旦需要换模型、换场景之前攒的“咒语”就失效了。原因很简单他只记住了“怎么做”没理解“为什么这么做”。而理解“为什么”靠的就是基础概念模型是怎么训练的、上下文窗口怎么影响记忆、参数怎么改变生成风格。所以我一直觉得与其每天刷十篇“大模型最新进展”的文章不如花半个月把“模型是什么、怎么来的、怎么跑起来、怎么改”这条主线捋一遍。磨刀不误砍柴工这句话在大模型领域比在哪个领域都适用。2. 绕不开的地基大模型核心知识地图如果让我给“大模型知识基础”画一张地图核心节点不会太多。你别看外面炒作的概念满天飞真正的地基其实就是几块模型架构、训练方式、推理机制、工程化部署。把这几块搞明白后面学什么都快。2.1 Token、Transformer和注意力机制从根上理解模型很多人第一次接触大模型时会问“为什么模型能写出通顺的句子”这个问题如果追到根上答案其实很朴素大模型在做“下一个词预测”。你在对话框里输入“今天天气”模型在内部把它拆成一小段一小段的token然后根据前面这些token去预测下一个最可能的token再把预测出来的token拼回去。它写几百个字本质上是一遍一遍地重复这个“预测下一个词”的动作。这里第一个基础概念就是token。token不是字也不是单词它是模型处理文本的最小单位。中文里一个标点可能是一个token一个常见词可能是一个token一个生僻字可能被拆成多个token。这个概念重要在对上下文窗口的估算你告诉模型“可以处理128k上下文”不是指128k个字而是128k个token。第二个基础概念是Transformer。今天的chat大模型几乎都是基于Transformer架构做的这个架构里最核心的机制是自注意力。自注意力解决什么问题它让模型在处理某个词的时候能够同时“看到”同一段文本里的其他词并自动判断谁跟谁关系更近。比如“小明把书放在桌上然后他走了”模型需要知道“他”指代的是小明而不是书。自注意力机制就是用来捕捉这种长距离依赖关系的。我知道很多人看到“注意力机制”就头疼其实不用怕。你只需要建立一个粗浅的理解模型在处理每个词时会给同一个序列里的其他词分配不同的“注意力权重”权重越高说明这个词对当前词的影响越大。这个机制也是后来很多模型优化工作的基础比如各种稀疏注意力、线性注意力都是在“怎么让注意力更高效”上做文章。2.2 预训练、微调、推理三件事必须分清“大模型”这个词本身特别容易让人误解因为它既指那个训练好的模型文件也指整个训练和使用的过程。我建议把三件事分开否则很多讨论会越聊越乱。第一件事是预训练。这是“烧钱”的阶段用海量文本数据训练一个基座模型让模型学会语言规律和世界知识。这个阶段需要几千张GPU、训练几个月普通人不碰。但在知识基础上你需要理解一个点预训练的目标就是“最大化地预测下一个token”模型从这个目标里学到的是一种概率化的知识而不是像人一样对世界有真正的理解。第二件事是微调。微调是在预训练模型的基础上用更小、更高质量的数据集继续训练让模型学会特定风格或特定领域的任务。比如一个法律大模型可能在通用模型基础上用法律文书做了继续训练。微调不是从零开始它更像是让一个已经读过很多书的聪明人去读行业案例然后学会在这个行业里说话办事。这个阶段的成本比预训练低很多也是很多人实际接触的切入点。第三件事是推理。模型训练完之后真正“回答问题”的过程叫推理。推理也是有大讲究的同样的模型提示词不同结果天差地别同样的提示词参数不同结果也不一样。像温度temperature控制随机性、top_p控制候选词范围、最大生成长度、上下文窗口大小这些参数直接影响输出质量。我见过很多新手连模型为什么总是重复一句话都搞不明白其实多半就是温度设太低、top_p设太小导致的。把这三件事分开之后你会发现很多热点问题的讨论一下就清晰了。比如“微调好还是RAG好”这个问题本质上是在问“你要改模型的参数还是要在模型生成时额外给参考资料”。不懂底层机制的人很容易被这种选择题绕晕。2.3 提示词工程、上下文工程、RAG、Agent一次理清关系这几年“提示词工程”“上下文工程”“RAG”“Agent”这四个词频繁出现在热搜里很多新手被搞得很焦虑以为每出个新词就要学一套新知识。其实它们的核心都在回答同一个古老的问题怎么让模型更好地完成实际任务先看提示词工程。这是最底层、成本最低的手段通过优化输入给模型的指令引导模型输出想要的结果。比如你想让模型帮你总结会议纪要直接问“帮我总结一下”效果可能很泛改成“请提取发言人的结论、待办事项和风险点用列表输出”之后结果会规范很多。提示词工程的门槛低但它解决不了所有问题因为模型的知识是训练时候定的提示词无法注入新知识。再看上下文工程。这个概念比提示词工程更进一层强调的不仅是“怎么写指令”还包括“怎么组织给模型看的所有内容”。因为你发出去的每段对话、每个附件、每条历史消息都会占用上下文窗口。有人在长对话里发现模型“忘了”最开始的要求往往不是模型记忆差而是上下文窗口里的内容被大量新信息冲淡了。上下文工程要解决的就是怎么在有限的窗口里把最重要的信息放在合适的位置、用合适的格式表达。接下来是RAG检索增强生成。它解决的问题很实际模型不懂你私有的文档微调又太重怎么办那就查出来给它看。RAG的基本流程是先把你的文档切块、做向量化存起来用户提问时先从库里检索最相关的几段文本再把“问题检索出来的文本”一起灌给模型让模型基于这些材料回答。虽然RAG在工程实现上要考虑切块大小、向量模型、召回策略、重排等问题但它的核心思想不复杂在生成之前给模型补知识。最后是Agent智能体。Agent不是单个技术而是一种应用架构让模型作为“大脑”通过理解任务、拆解计划、调用外部工具搜索、代码、数据库等来完成更复杂的目标。它比单次问答多了一个“循环决策”的机制所以你会看到现在很多Agent框架都在处理“记忆”“规划”“工具调用”这些模块。把这四个词放在一条线上看就清楚多了提示词工程是管“怎么说话”上下文工程是管“怎么安排记忆”RAG是管“怎么补外挂知识”Agent是管“怎么用工具干活”。它们不是互相替代的进阶关系而是从简单到复杂的应用手段。如果你有这个框架就不会被新概念带着跑了。2.4 部署和硬件常识本地部署最容易被劝退的地方“本地部署大模型”这几年特别火天天有人在社区里晒“我用个人电脑跑起了大模型”。但很多人一照做就翻车因为缺的不是兴趣是硬件常识。首先要理解一个残酷的现实模型文件有多大推理就得有多少显存。一个7B参数的模型如果用FP16精度加载光模型权重就需要约14GB显存13B模型约26GB70B模型约140GB。这还只是把参数放进去没算推理过程中的KV Cache等额外开销。所以有人说“我用CPU跑大模型”不是不行但速度会慢到怀疑人生。为了解决“显存不够”的问题就有了量化。简单说量化就是把模型里的浮点数参数从16位压缩到8位、4位以牺牲一点精度为代价换来更小的显存占用。4bit量化的7B模型可能只需要5GB左右显存很多消费级显卡能跑动。量化的概念不复杂但你必须知道量化后模型尺寸变了输出质量可能会有细微变化而且有些算子对量化格式支持不好会报错。部署还涉及推理框架的选择。现在主流的推理框架有vLLM、nano-vLLM等它们各自在吞吐、显存管理、兼容性上做了优化。vLLM的PagedAttention能减少显存浪费所以同样是7B模型换了推理框架之后并发能力会提升很多。这类框架虽然属于工程层面的知识在我看来也是入门必修的基础——因为你不亲手部署一次模型就永远体会不到“模型结构和推理框架是两回事”这句话什么意思。还有一个经常被Windows用户踩到的点TCC和WDDM。在Windows下配置NVIDIA显卡驱动时会有这两种模式。WDDM是把GPU同时用于显示和计算适合日常办公加偶尔跑模型TCC则把GPU完全交给计算任务使用显存管理更高效适合有独立显卡专门跑计算的机器。如果你总是遇到“程序启动成功后黑屏”或者“显存明明够却无法分配”这类诡异问题可以去查一下显卡模式。这种小常识虽然在书里找不到但它就是典型的“知识基础”。3. 从零开始补基础一份能落地的学习路线每次有人问我“大模型怎么学”我都推荐一套很朴实的学习路线先补底子再会用再拆开看最后动手改。这条路没有捷径但也不需要你变成数学博士只要按顺序走大多数人两三个月就能把基础盘得很扎实。3.1 先别急着学框架把数学和代码底子补齐很多新手会被“基础”两个字吓到以为要把线性代数、概率论、微积分全部学完才能碰大模型。其实不用。你只需要补跟模型直接相关的两小块。第一块是线性代数。不需要会证明定理但你需要知道矩阵是什么、向量乘法怎么回事、为什么参数可以看作一个巨大的矩阵。因为大模型里的“参数”本质上就是一堆数值模型处理输入做的运算大部分可以被理解为矩阵乘法和非线性激活。当你看到“模型参数量7B”时能想象出那是70亿个数字组成的矩阵就够了。第二块是概率统计。大模型生成文本的底层是概率分布模型会为每个可能的token算出一个概率然后按概率采样。理解了条件概率你就能理解为什么同一个提示词会得到不同答案为什么温度参数能影响随机性为什么模型有时候“一本正经地胡说八道”。代码方面至少要会Python。不一定非要成为Python高手但得能看懂别人的推理脚本能改参数量、换模型路径、处理数据格式。我经常建议新手先跑一个最简单的加载模型的Python脚本哪怕只是“加载模型后生成一句话”这个经验比读十篇原理文章都有用。因为你会亲眼看到“模型怎么被加载”这个环节比任何解释都直观。3.2 用起来先会调用再会部署基础知识的检验标准不是“能不能说出概念”而是“能不能让模型跑起来”。我建议按下面这个顺序来。第一步先通过API调用一个商用大模型或者在一个网页对话平台上玩熟。这一阶段不需要写代码主要目的是感受模型的强项和弱点。你要刻意测几个场景让模型总结长文本、让模型推理数学题、让模型处理中文俗语、连续对话二十轮看它会不会忘记前文。把这些现象记录下来后面学概念时你会突然“啊原来就是这个原因”。第二步用Python代码调API。写一个最简脚本把文本发给模型再接收返回结果。这个练习会让你明白“输入”和“输出”到底是什么格式以及temperature、max_tokens这些参数怎么影响输出。你可以试着把temperature调到接近0看输出是不是变得稳定再调到1.5看输出是不是开始发散。这种对比实验比背参数表有用得多。第三步本地部署一个开源小模型。你可以去下载量化后的7B模型用vLLM或nano-vLLM这类框架跑起来。之所以建议本地部署是因为你能更直接地看到模型推理的全过程从加载权重到构建KV cache再到流式输出。这一步会遇到无数坑比如显存不足、依赖库版本冲突、模型路径写错但每个坑都能逼着你多了解一点底层原理。3.3 微调实战从最小的例子开始别一上来就去微调一个庞大的模型。我见过很多人拿着几百条数据就想微调7B模型结果显存爆了、Loss不降、效果还不如提示词调优心态直接崩了。我的建议是先用一个非常小的模型来练习比如参数量在1B以内的开源模型。你可以在它的基础上做一个极简的文本分类任务或者一个“让模型学会特定回复格式”的指令微调。这一步的核心目的不是追求效果而是把数据格式、训练脚本、损失曲线、评估流程全部跑通。数据格式是最容易卡人的地方。指令微调的数据通常要整理成“instruction、input、output”这样的结构稍有不慎就会出现序列长度不匹配、tokenizer截断、标签错位之类的问题。我第一次做微调时就是因为有一条数据里input为空字符串而大部分样本里input都有内容导致数据整理函数报错排查了一个多小时才找到原因。这种事情只有亲手做一遍才会长记性。微调跑起来之后也别急着开心。你要对比微调前后的模型输出看看真的变了吗变好还是变坏。如果微调后模型在通用能力上明显下降这说明过拟合了如果训练集上表现好、验证集上表现差这说明泛化能力不行。能读懂这些现象背后的含义你的基础就算真过关了。4. 一个实操记录我如何用两周补齐大模型知识短板我不想只讲理论也分享一段我自己的实操经历。有段时间我需要给团队做一次大模型应用方案发现自己很多基础概念讲不透于是定了一个两周的“补课计划”。后来这个计划被我总结成一套流程谁想补知识基础都可以参考。4.1 先做能力盘点把目标拆成小任务第一周开始前我花了半天时间做能力盘点把所有觉得“知道但讲不清”的概念写出来token、上下文窗口、注意力、预训练、微调、量化、KV cache、RAG、Agent。每个概念旁边标一个自评分数1分是完全不懂5分是能给别人讲明白。这一盘点让我很尴尬好多东西都只在3分左右。然后我把大目标拆成小任务。两周时间不可能把原理吃透所以我只定了三个任务第一能不看资料解释Transformer的基本流程第二能用代码完成一次本地模型加载和推理第三能用微调框架跑通一次最小规模的指令微调。这三个任务分别对应“理解”“部署”“修改”三个环节既有知识输入也有动手输出。事实证明先明确“这个阶段不需要学什么”也很重要。我主动放弃了深入推导注意力公式、学习分布式训练框架这些看起来诱人但暂时用不上的内容。守住边界才保证了两周内能推进得下去。4.2 我筛选资料的原则官方文档优先论文看摘要代码要跑通现在网上的大模型资料太多了要是不会筛选会越学越乱。我用了三条很笨但很有效的方法。第一条凡是概念解释优先看官方文档和技术博客里带图的那类少看营销号总结贴。官方文档虽然有时候不够通俗但它准确二手转述可能有错误尤其是中文互联网上的“翻译式解读”经常把术语搞得似是而非。第二条论文不追正文先看摘要和结论。要理解一个模型的基本思路摘要和图表通常就够了真正需要精读正文的时候反而是你已经对模型有初步了解之后。第三条看到任何代码示例都尽量复制下来跑一遍。代码跑不通说明理解有遗漏跑通了你才敢说这个知识点真的“会了”。我那一周还给自己定了个纪律不收藏超过十篇的“学习资料”。因为收藏夹里的东西绝大多数永远不会再看。真正有价值的资料应该是一边学一边做笔记甚至转写成自己的话这样才变成了你自己的知识基础。4.3 踩过的坑不是模型难是工程细节折磨人两周里我踩了不少坑最典型的三个现在写出来给正要补基础的人打个预防针。第一个坑是显存估算错误。我一开始打算用一台16GB显存的消费级显卡跑一个13B模型。当时以为13B模型FP16也就需要26GB量化成8bit后差不多13GB够用。但真跑起来发现一部分显存被操作系统和桌面环境占用了可用显存只剩12GB左右模型刚加载进去就报OOM。后来我换成了7B模型加4bit量化显存占用瞬间降到6GB以下。这个教训让我意识到看显存占用不能只看“模型权重大小”还得看环境开销和推理框架的额外占用。第二个坑是上下文被截断。我在做长文本总结时塞了一段几万字的资料给模型结果模型只总结了开头几百字。后来查日志发现我计算的上下文长度时把token数估计少了输入已经超过了模型的上下文窗口上限后面的内容被直接截断。从此我学到一个习惯调用模型或构建数据时要先算token数别拿字数去衡量。第三个坑是微调数据tokenizer不统一。当时我找了一个开源的微调脚本默认使用模型自带的tokenizer但我手工构造的数据里有些字段没走tokenizer预处理。训练过程没有报错可生成的文本里出现了很多奇怪的换行符。这是最磨人的一类问题不报错但效果差。从那以后我坚持在训练前用一小批数据跑一次推理直接看一眼tokenize后的输出很多数据格式问题一眼就暴露了。这些坑本身都不难但如果没有基础知识你甚至不知道报错信息里的“OOM”代表什么也不知道context window怎么调。正因为之前花时间补了基础我才能在踩坑后快速定位问题。5. 常见问题速查新手最容易被卡住的几个问题最后整理几个我经常被问到的入门问题这些问题看起来很小不解决却很影响学习节奏。5.1 要不要先学机器学习看你的目标。如果你只想做应用层面的事比如写提示词、调API、做RAG流程、用Agent框架那你不一定非得学完机器学习课程。但几个基础概念要补什么是分类、什么是回归、什么是过拟合、什么是训练集和测试集。因为微调和评估模型时会反复用到这些词不懂的话连别人的经验帖都看不懂。如果想往算法方向走那就老老实实补机器学习基础。建议按经典教材的前几章看特别是线性模型、决策树、神经网络基础这几个部分能帮你建立“模型是什么”的整体感觉。顺序上先有一些机器学习概念再学大模型原理会比直接啃Transformer论文轻松很多。5.2 提示词工程和上下文工程有什么区别这是一个特别好的问题因为它能检验一个人是不是真懂模型机制。提示词工程的面更窄一些关注的是“怎么写出更好的指令”。你给它一个角色设定、要求它使用某种格式、规定它必须从某几个角度回答这是在优化“话语”。上下文工程的面更宽一些关注的是“你在上下文窗口里给模型喂了什么、以什么顺序喂”。它不只包括你的指令还包括背景资料、对话历史、检索到的RAG结果甚至包括这些内容的先后顺序和格式标记。因为模型无法记住上下文窗口之外的内容所以你“怎么安排它能看到的东西”本身就是一种工程能力。所以我自己的理解是提示词工程是上下文工程里最核心的一环但上下文工程还要处理更多内外部信息的组织和调度。5.3 本地部署到底需要什么配置这个问题没有标准答案但我可以给一个参考下限如果你只想跑7B模型并且用4bit量化显存8GB的显卡有机会跑起来如果要顺畅地跑13B模型建议至少16GB显存想跑70B级别模型基本就要考虑多卡或者高显存工作站了。这还不考虑CPU、内存和推理框架的选择。另一个因素是速度。显存够用只是前提每秒能生成多少token也是关键。我自己在低端配置上跑过模型生成速度慢到像老式打字机这种体验对学习影响很大。所以我不建议完全零预算硬蹭本地部署有条件就组一台显存大于16GB的机器体验会好很多。如果你还没有任何硬件又想学部署可以先在云服务器上租GPU跑几次。按小时付费跑通一次流程就关掉成本比冲动买卡低得多。我见过很多人买了一堆显卡结果发现根本没时间折腾这就没必要了。5.4 API派和开源派怎么选这不是一个谁优谁劣的问题而是两条目的不同的路线。API派的核心价值是效率。你用别人已经部署好的模型把精力集中在产品逻辑、提示词优化、业务数据整合上。如果你的目标是做应用、做产品那API是刚需你不必关心部署细节。但缺点也很明显数据要发给第三方隐私合规上有风险模型能力受限于提供商一旦涉及敏感场景可能连用都不能用。开源派的核心价值是灵活和可控。你可以把模型下载到本地数据不出内网也可以针对业务场景做微调、换推理框架、改采样参数。缺点是必须自己负责环境、硬件、性能优化学习成本高不少。绝大多数人的现实选择是两条腿走路刚入门时用API熟悉模型行为等有了明确需求再基于开源模型做本地部署和微调。这条路把成本和性价比平衡得比较好也是我自己验证过的路径。补基础这件事确实不酷它没有“三天学会大模型”那种刺激感但它给你的是持续迭代的底子。我以前也喜欢收藏各种新概念、新框架后来发现收藏夹里吃灰的东西远不如亲手把一个Demo跑起来的那十分钟有价值。如果你现在正被大模型的各种名词绕得头晕别急着背新词先回到那几个最老、最基础、看起来最不性感的概念上。把Transformer、token、预训练、微调、推理、上下文窗口这些词变成你真正用得上的工具你会发现自己突然能看懂几乎所有大模型相关的文章了。