大模型入门必学：14个核心概念与完整链路解析

如果让我给刚接触大模型技术栈的朋友推荐一份必学清单，我不会从Transformer结构开始，也不会直接甩论文链接。我会先让你弄懂14个核心概念：Token、Embedding、参数量、预训练、微调、注意力机制、损失函数、推理、量化、RAG、上下文窗口、Agent、幻觉、多模态。这些词几乎会出现在所有模型文档、技术讨论和招聘JD里。它们不是孤立的知识点，而是从数据怎么进入模型、模型怎么训练、部署时怎么加速、落地时有什么坑，刚好串成一条完整链路。

我自己也是从“每个词都查过、合在一起就晕”的阶段走过来的。这篇就按我实际的理解顺序来写，不绕弯，也不会堆公式，尽量用能直接上手的视角把这14个概念说清楚。

1. 一张概念地图：先知道14个词缺在哪一格

1.1 我最早犯过的错：把概念背下来，却没打通关系

我刚开始学的时候，特别爱背定义。背了很久之后，仍然答不上来三个问题：Embedding和Token到底是什么关系？微调和RAG是不是二选一？为什么模型参数量明明不大，部署起来却那么吃显存？

后来我复盘才发现，问题不在于哪一个概念难，而在于概念之间没有连接。比如Token是模型读入文本的最小单位，Embedding就是把Token变成数字向量，而上下文窗口又限制了模型一次能塞进多少Token。这三个词本来是一条链上的事，拆开看就成了三团迷雾。

类似这样的情况还有很多：量化不是简单的“文件压缩”，RAG不是prompt里多塞一句话，Agent也不是“高级聊天机器人”。所以这篇我会按“数据表示层、模型构建层、运行部署层、应用边界层”四个层次来组织，先给你一张地图，再逐个讲细节。

1.2 四个层次，一张表理清

这张表不需要背，但建议你每次遇到一个新概念时，先分类：它是属于哪一层？它和同层其他概念是什么关系？这样做的好处是，你再看到“RAG”时就不会把它当成一个独立工具，而是会意识到它的核心价值在于“在推理时给模型补充信息”。

2. 输入链路三件事：Token怎么切、Embedding怎么映射、窗口能塞多长

2.1 Token：模型阅读文本的“乐高块”

Token是模型实际读到的最小文本单位。它可以是词，可以是半个词，也可以是一个汉字或几个字符的组合。很多人第一次接触这个概念时会理所当然地认为“Token就是单词”，这在大模型时代其实不太准确。

不同分词器的切法差别很大。以英文为例，“unhappiness”可能会被切成“un”“happi”“ness”这样的子词；中文里“大模型”可能被切成“大”“模型”两个Token，也可能被整体当成一个Token。具体怎么切，取决于分词器的词表设计和训练数据。

为什么不用“单词”而是用“子词”做基本单位？两个原因：

• 词表可以变小。如果只用单词，英文要收录几十万个词，还要面对拼写变化和生造词。
• 模型能处理没见过的新词。新词拆成已知的子词片段，模型至少能猜出大概。

实操中最需要记住的一点是：Token数量直接决定计费、上下文占用和处理延迟。很多平台的成本都是按Token算的，而不是按字数算的。你写一句很长的中文，真正占的Token数可能比你想象中多。所以做任何应用之前，第一件事应该是用模型自带的分词器去统计Token数。

提示：不要用Python的len(str)估算Token长度，中文尤其不准。每个模型的分词器都不一样，通用规则是“英文约4个字符一个Token，中文通常一个汉字约1到2个Token”，但最终以实际分词结果为准。

2.2 Embedding：语义相似变成距离相近

分词之后，模型需要把离散的Token变成连续的数字向量，这一步就是Embedding。你可以把它理解成给每个Token分配一个“坐标”，放在一个高维空间里。语义相近的词，在这个空间里的距离也近；语义无关的词，距离就远。

拿最经典的感觉来说，“猫”这个Token的向量，和“狗”的向量距离很近，而“汽车”的向量就会离得比较远。当然这只是直观比方，真实向量空间并没有“猫在坐标（1,2）这么简单”，但思路就是让语义关系变成几何距离。

为什么不能用简单的独热编码？独热编码就是把词表里的每个词变成一条很长的向量，只有自己那个位置是1，其余全是0。这种表示虽然能区分不同Token，但完全看不出语义相似性。“猫”和“狗”在这组向量里没有任何相似之处，模型也就很难从它们身上学到“都是宠物”这样的共同点。

Embedding不只是输入层的附属品，它会在模型训练过程中被不断调整。现代大模型的Embedding和后面的Transformer网络是一起训练的，所以模型对语义的理解会随着训练进步。到RAG阶段，Embedding还会单独用在检索上：先把文档切成小块，再把每一块转成向量存起来，查询时把问题也转成向量，然后找最近的文档块。

2.3 上下文窗口：工作记忆而非永久记忆

上下文窗口是模型能同时看到的Token总数量，包括用户输入、历史对话，以及模型即将生成的内容。很多人把它理解成“模型能记住多少东西”，其实更准确地说，它是模型的工作记忆容量。

工作记忆意味着两件事。第一，超过窗口的内容模型完全看不见，你再往前翻对话，它也不会自动“想起来”。第二，窗口越长，计算代价越大。注意力机制需要让每个Token都能关注到窗口内所有Token，所以窗口翻倍时，计算量和显存占用会显著上升，而不是线性翻倍。

很多实际项目都遇到过“长会话越聊越慢”的情况，核心原因就在这里。处理长上下文的常见思路包括：

• 超过一定长度后，把早期内容做摘要，压缩进上下文。
• 把重要信息外置到检索系统，需要时再查进来。
• 用滑动窗口只保留最近N轮对话。

提示：在设计应用时，不要把上下文窗口当“永久数据库”。如果一个业务需要长期记忆，正确方案是外接存储，让模型按需读取，而不是把所有历史都塞进窗口里。

3. 训练核心五件套：参数量、预训练、注意力机制、损失函数与微调

3.1 参数量：看完数字心里要有显存账

参数量指的是模型里所有可学习的权重和偏置的总数，单位通常用K、M、B表示，1B等于10亿参数。大模型动辄7B、13B、70B，说的就是这个数。参数量可以粗略看作模型的“容量”，容量越大，理论上能装下的模式和知识越多，但训练和部署成本也越高。

对于一个写在宣传页上的参数量，你应该快速算出一笔显存账。大多数公开模型用FP16或BF16精度存储权重，每个参数占用2字节。假设你遇到一个7B模型，只是把权重加载进显存就需要：

7 × 10^9 × 2字节 ≈ 14GB

如果一分不剩全部给权重，那你至少要一块16GB的显卡才能勉强加载。实际推理时还有KV Cache、中间激活、框架开销，所以14GB权重通常需要更大的显存才跑得舒服。

训练时就更贵了。优化器会保存模型参数的副本甚至更多状态，光是权重、梯度和优化器状态加在一起，就可能达到权重的16倍以上。这就是为什么很多人能跑推理但跑不了微调。

提示：看到参数量不要只感慨“参数好多”，要立刻估算出三个数：权重占用多少GB、推理需要多少显存、量化后又能省多少。

3.2 预训练：用“接龙游戏”学出语言能力

预训练是大模型能力的主要来源。它做的事情是在海量无标注文本上做自监督学习，最典型的任务就是“根据上文预测下一个Token”。可以通俗地理解为一个巨大的接龙游戏：模型看一长串文本，反复猜下一个词是什么，猜错了就调整参数，再继续猜。

这个过程不需要人工标注数据，因为文本本身就是答案：把一句话遮住后半部分，让模型猜被捕的部分，猜的就是下一个Token。互联网上的文章、书籍、代码等都可以作为训练语料，模型从这些数据里学词汇、语法、事实常识，甚至是推理的“语感”。

预训练模型并不像数据库一样逐字记住所有信息。它学到的是词与词之间的统计规律和分布特征。也就是说，它能答出“巴黎是法国的首都”，不一定是因为记忆里存了一条记录，而是因为相关文本在训练中反复出现，让参数形成了某种规律。

对绝大多数人来说，预训练阶段是不需要自己重做的。开源社区已经有大量预训练完成的模型可以直接下载使用。你真正需要理解的是：预训练决定了模型的基础能力上限，后续的微调只能在这个上限之上做适配，而无法凭空补上训练阶段就没有的知识。

3.3 注意力机制：决定每个词该“看”谁

注意力机制是现代大模型的引擎。它让模型在处理一个Token时，不是只看它前后固定几个词，而是根据当前任务决定要参考上下文里的哪些位置，并给这些位置分配不同的权重。

可以用一个生活场景来理解：当你读到“小明把杯子递给小刚，因为小刚口渴了”这句话时，你会自动把“口渴”和小刚联系起来，而不是把注意力平均分给每个词。注意力机制做的就是类似的事，它让模型学会为当前Token选择最相关的信息。

具体实现时，模型会为每个Token生成三组向量：Query、Key、Value。Query可以理解为“我想找什么”，Key是“每个位置能提供什么标签”，Value是“每个位置实际提供的信息”。模型通过Query和Key的匹配程度决定注意力权重，再按权重去加权汇总Value。

这里有一个非常重要的工程影响：注意力机制要求每个Token都要和窗口内所有其他Token做匹配，所以计算量随窗口长度平方级上升。窗口一长，显存就会吃紧。很多优化技术，比如稀疏注意力、滑动窗口、KV Cache，本质上都是在这条“平方级链路”上做文章。

注意力机制也不是只看语法关系。多头注意力会让模型在不同子空间里分别关注不同的东西，有的头关注语法结构，有的头关注指代关系，有的头关注局部搭配。它们合在一起，才构成了模型理解句子的能力。

3.4 损失函数：模型每轮更新的“分数线”

训练模型的本质是一个优化过程，而损失函数就是这个过程中的“分数线”。大模型预训练和微调中最常见的损失函数是交叉熵损失。

你不需要把公式背下来，只需要理解它衡量的是什么：模型给正确答案分配的概率越高，损失越低；如果正确答案本来应该概率很高，模型却给了它很低的概率，损失就会很大。训练过程就是不断用损失值去更新参数，让下一次预测更准。

工程上有一个容易忽略的点：训练损失降到很低，并不代表模型真的好了。损失只反映模型在训练数据上的拟合程度，如果没做好泛化，模型可能只是把训练样本“背”了下来，遇到新数据就崩。所以训练时除了看训练损失，还要看验证损失。

提示：不同模型之间的损失函数数值不能直接对比，因为词表大小、任务难度和数据分布都不同。看到“损失从5降到1”这种描述，别急着说好，要看它是在什么数据集、什么任务下测的。

3.5 微调：让通用能力适配你的“口吻和规矩”

预训练完成后的模型是一个通用选手，能接话、能写东西，但不一定懂你的任务格式，也不一定符合你想要的语气。微调就是在这个基础上，用一批带标注的数据继续训练，让模型学会具体的行为规范。

微调和预训练的关键区别是：预训练教的是“语言规律和世界知识”，微调教的是“任务格式和执行方式”。比如你想让模型输出JSON格式，或者用更简洁的口吻回答客服问题，只需要准备几百到几千条“问题-标准答案”数据，再做一次有监督微调。

常见的微调方式有全参微调和参数高效微调。全参微调效果上限高，但显存和算力要求也高，前面提到的参数量显存账在这里要再翻几倍。参数高效微调则是只训练一小部分额外参数，代表作是低秩适配，它在保持大部分原有参数不动的前提下，用很小的参数量完成领域适配，更适合个人开发者和小团队。

不过要记住，微调不是万能的。如果你想给模型补充大量新知识，效率很低，而且更新成本高；这种场景更适合RAG，让模型在回答时去查外部资料。微调和RAG不是二选一，越来越多产品会把它们组合使用：先用微调固定模型的行为风格，再用RAG提供实时知识。

4. 部署落地三件事：把推理跑快、用量化塞进显存、用RAG补上知识

4.1 推理：生成是“一个词一个词蹦”的串行过程

推理是大模型真正对外服务时的过程。输入阶段，模型可以并行处理所有输入Token；但生成阶段，模型每输出一个新Token，都要把这个Token拼回序列，然后重新计算一遍预测。所以生成是串行的，这也是为什么长文本生成往往比较慢。

第一次收到用户的输入，模型会计算整段输入的中间结果，这个阶段通常叫预填充；之后逐个生成Token的阶段叫解码。为了提高速度，工程上常用KV Cache把已经算好的注意力键和值缓存下来，避免每生成一个新Token就要把前面所有历史重新算一遍。

即便如此，KV Cache本身也要占显存。上下文越长，缓存越大。社区里经常说的“长上下文跑不动”，很大程度上就是被这个缓存挤占显存的。所以在评估一个模型能不能上线时，不要只看参数量，还要看平均输入长度和平均输出长度。按经验估算，一条请求大约需要：

模型权重显存 + KV Cache显存 + 激活中间值显存 + 服务框架余量

这些数字会根据上下文长度动态变化。上线前一定要用最长的真实请求做压测，而不是只跑一个短样例。

4.2 量化：用更低字节数换模型能装下

量化是部署时几乎绕不开的优化手段。核心思路是把模型里原本用FP16（2字节）表示的权重，换成INT8（1字节）或INT4（0.5字节）表示，从而降低显存占用和计算开销。

还是以7B模型为例：FP16权重约14GB，INT8约7GB，INT4约3.5GB。从一张需要高端显卡的模型，变成一张中端消费级显卡也能加载，这就是量化最直接的价值。

量化不是无损失的。精度下降意味着模型输出的质量可能会有一点波动，尤其在一些推理要求高的任务上。而且不同模型对量化的敏感度不一样，有的模型量化成INT4之后效果依然很好，有的则明显变蠢。

工程上常见两种做法：

• 权重量化：只把权重压成低精度，运算时按需恢复或混合精度，质量损失通常较小。
• 全量化：连激活值也压到低精度，速度和省显存效果更明显，但对算子和框架支持要求更高。

我的建议是，不要因为“量化会损失精度”就拒绝它。先在你的业务数据集上跑一轮量化前后的对比，如果效果差距在可接受范围内，那省下的显存和费用是实打实的。

4.3 RAG：先查资料再回答，让模型不硬编

检索增强生成（RAG）目前是大模型落地最常用的一种技术形态。它的工作流程是：拿到一个用户提问后，先从外部知识库里检索出最相关的文档片段，把这些片段作为参考资料拼进Prompt，再让模型基于参考资料生成回答。

可以把它理解成“考试时允许模型带参考资料进场”。模型不再需要把每条知识都塞进参数里，也不再依赖训练数据里有没有这个信息。你只需要更新外部资料库，模型每次回答前重新检索就能拿到最新知识。

RAG和微调是两种互补的手段。它们的区别可以用一张表概括：

做RAG时最容易被忽略的是检索质量。很多人觉得只要把文档切好、塞进向量库，再接一个大模型就成了。实际跑下来你会发现，模型生成答案的问题往往不在“最后一步生成”，而在“前面的片段没召回”。文档怎么切、Embedding用哪个、召回多少条、要不要重排，这些都会直接影响回答质量。

提示：RAG能显著降低事实错误，但不能彻底消灭幻觉。如果你的业务对错误零容忍，还需要在RAG后面加一层校验或引用强制策略。

5. 进阶才看到的边界：Agent、幻觉和多模态

5.1 Agent：从“会说话”到“会办事”

Agent是大模型应用形态的重要升级。普通聊天是用户提问，模型回答，对话结束。Agent则是一个循环系统：模型理解目标，把目标拆成步骤，选择工具去执行，观察执行结果，再决定下一步动作，直到完成任务。

举个例子，用户说“帮我整理一下这周的会议记录，并按主题发到对应群里”。Agent内部可能会这样做：

• 先定位会议记录文件。
• 读取内容，提取时间、主题和结论。
• 按主题分类。
• 调用发送工具，把整理结果发给对应群组。
• 最后向用户汇报完成情况。

这一系列动作里，大模型负责的核心是“推理和规划”，工具调用和外部操作则交给代码和接口完成。相比RAG，Agent不只是获取信息，它还会改变环境状态，所以工程复杂度要高得多。

做Agent项目比较难的点始终集中在：模型能不能稳定输出正确的工具调用格式、失败后能不能合理重试、有没有设置安全边界。如果这些没想清楚，Agent很容易陷入“看似聪明，实际失控”的状态。

5.2 幻觉：模型再自信也可能出错

幻觉是指大模型生成流畅但不符合事实、或与输入内容矛盾的内容。最迷惑人的地方在于，模型说错时语气往往和说对时一样自信，没有明显破绽。

为什么会产生幻觉？根本原因在于大模型的训练目标是预测下一个Token，而不是“寻找并记忆事实”。它追求的是统计上最连贯的文本，而不是严格符合外部事实。采样过程的随机性、训练数据中的错误信息、上下文不够充分，都可能把模型推向“编造”的方向。

对付幻觉需要组合拳，单靠一句“请只回答确定的内容”效果很有限。一些务实的手段包括：

• 用RAG把外部可靠资料带进上下文，让模型有据可依。
• 要求模型先引用来源，再给结论，没有来源就说不知道。
• 调低采样温度，减少随机性。
• 对重要业务增加独立校验器，验证生成内容是否可信。

这里要说清楚，幻觉不可能被完全消除。哪怕做了RAG和微调，模型依然有概率在边界问题上犯错。做系统设计时，应该把“允许答错”这件事设计成一个可控风险，而不是假设它不存在。

5.3 多模态：让文本、图像、音频共享语义空间

多模态大模型指的不只是“既能读文本，又能看图，还能听音频”的拼接，而是在训练过程中把不同模态的数据映射到同一个或几个相通的语义空间里，让模型能跨模态理解。

举个例子，文本里的“猫”和一张猫的图片，在模型的语义空间中应该距离很近。这样当你给模型一张猫的照片，再问“这是什么动物”时，模型才能把图像里提取到的特征和语言生成对齐。

实现多模态常用的思路是把图像切成若干块，每块转成类似Token的表示，再和文本一起进入Transformer网络。文本和图像在这个过程里相互影响，模型逐渐学会它们之间的对应关系。音频也可以用类似方式处理。

工程上做多模态项目时，不要只关注大模型本身，还要重视输入端的分词策略。图像按什么粒度切块、音频怎么采样、不同模态的输入长度如何截断，都会直接影响效果。很多时候你以为模型“看不懂图”，其实是输入处理环节把细节丢了。

最后说一个我自己实践下来的体会：学完这14个概念后，每接触一个新的模型或框架，我只看四个问题——它的Token是怎么切的？上下文窗口有多大？参数量是多少？部署时需不需要量化或RAG？只要把这四个问题问清楚，大部分技术文档都能快速读进去。希望这张概念地图也能帮你少走一点弯路。