做了几年开发我见过一个挺有意思的现象大模型概念一开始爆火满屏都是相关文章等热度稍微平静真正愿意静下心来系统学习的人反而变多了。可大多数小白程序员翻开大模型相关的技术帖、开源项目文档第一反应几乎一模一样——术语太多直接劝退。今天这篇东西就是把我这些年反复用到的、也是最基础的一批大模型术语整理出来做成一份能“一次看懂、反复查”的清单。目标很单纯让你花一个晚上把小白阶段最该懂的大模型必备术语一次性捋顺。不指望背完就能理解全部数学原理但至少再去围观技术讨论时看到 Token、参数量、微调、量化、RAG 这些词你不会心虚。适合刚接触大模型 API、准备做应用开发、或者只是想把原理弄明白个七八成的程序员收藏。1. 先把最底层的三块基石钉死Token、参数量、上下文窗口跟大模型打交道绕不开的第一组词永远是 Token、参数量、上下文窗口。这三样东西不是三个独立知识点它们是同一件事的三个侧面模型一次能读多少“字”、模型肚子里有多大“容量”、模型一次能记住多少“内容”。理解它们后面所有概念都更容易落地。1.1 Token模型眼里没有“字”只有“碎片”Token 是模型处理文本的最小单位可以通俗理解成“词的碎片”。模型并不是像人一样按“笔画”或“拼音”来理解文字而是先把一段文本切成一小块一小块再转成数字向量输入网络。比如“大模型真厉害”这句话可能被切成“大/模型/真/厉害”也可能被切成“大模/型/真/厉害”具体怎么切取决于分词器( Tokenizer )的词表设计。这个概念的实用性体现在两个地方计费和窗口长度。几乎所有大模型 API 都按 Token 计费而“上下文窗口”的上限也是按 Token 算的不是按字数算的。一个很反直觉的点中文里 1 个汉字通常对应 1 到 2 个 Token英文里一个常见单词大概是 1 到 2 个 Token。所以中文长文本实际消耗会比直觉上快不少。我实测过的经验是写 Prompt 时让模型“直接给结论”比“先解释再给结论”更省 Token因为每多输出一次复述都是在烧钱。还有个小技巧很多模型在处理结构化内容时让模型输出 JSON 而不是长篇大论能显著降低 Token 浪费解析也方便。对于程序员来说把 Token 当成“模型眼中的前处理单位”就够了类似你给数据库建索引前要做分词一样。1.2 参数量7B、13B、70B到底在说什么参数量指的是模型内部有多少个可学习的权重参数B 是 Billion也就是十亿。7B 就是 70 亿参数70B 就是 700 亿参数。我习惯把它类比成一个仓库的货架总量参数越多理论上能装下的“知识”和“模式”越多但货架大了也意味着你得买更大的仓库、交更多电费。很多人有个误区觉得参数量越大模型越聪明。严格说参数多只是“容量上限高”模型最终好不好用还要看训练数据质量、训练方法、对齐程度。市面上很多小模型在特定任务上完全可以吊打更大参数的通用模型因为它们在某类数据上被训练得更透。参数量的实际参考意义在部署侧。比如一个 7B 级别的模型用 16 位精度推理光权重就要占 14GB 左右显存70B 级别想跑起来就不是单卡能解决的。所以你常会看到“这个模型 7B 可以在本地跑那个模型 70B 需要集群”的说法本质上就是在说资源门槛。1.3 上下文窗口模型的“临时工作台”上下文窗口也叫上下文长度是模型在一次生成中最多能“同时看到”的 Token 数量。我把它比作一张白板窗口大白板就大能写下更多对话历史、参考资料和用户指令窗口少你只能把最关键的信息写在白板上写多了就会把前面的内容挤掉。注意“能容纳”不等于“能充分利用”。窗口拉长之后模型对最前面的内容注意力会明显衰减这个问题在业界也很常见。你在长对话里发现模型“忘了最开始的内容”不是它坏了很可能就是注意力被中间和末尾的内容冲散了。实操习惯重要指令尽量放在 Prompt 的开头或者结尾尤其是系统提示词和最终问题。中段的长篇背景资料有时候会被“稀释”。这个经验在长上下文的场景里特别值得注意。程序员可以把它类比成一个固定大小的缓存缓存满了就得淘汰旧数据所以设计对话系统时要想清楚哪些内容必须留在窗口内哪些可以压缩或外置。2. 模型是“教”出来的预训练、微调、RLHF对齐模型不是天生会聊天它是被“教”出来的。大模型从一张白纸到能正常对话一般会经历几个阶段。理解这些阶段你就知道为什么有些模型“知识丰富但不懂规矩”为什么微调能改变风格却补不进新知识。2.1 预训练先让模型“博览群书”预训练是整个大模型成本最高、耗时最长的阶段。这一阶段模型被扔进海量文本数据里——网页、书籍、论文、代码目标简单粗暴根据前文预测下一个 Token 是什么。它没有明确的任务指令也不需要人工标注答案学的是语言本身的统计规律和“世界知识”。可以把它想象成一个人读了几十万本书但没有老师教他“怎么回答别人的问题”。所以预训练出来的模型能力是“能补全句子”不是“会对话”——你去问它一个百科问题它可能真的会回答但它也完全可能顺着你的话头继续编。它这时候更像一个“接话机器”。预训练阶段的成本高到什么程度需要用成千上万张高性能计算卡连续跑上几十天不是普通团队能玩的。这个阶段属于“基建”普通开发者一般不需要碰。2.2 微调SFT从“通才”变“专才”微调是我们普通开发者最容易接触到的训练环节。它的大概流程是准备一批“指令 理想回答”的格式化数据然后在预训练模型的基础上继续训几步让模型学会“按照人的指令回答问题”而不是只会接话。我常用一个比喻预训练给了模型“通识教育”微调相当于“岗前培训”。比如你想让模型学会客服口吻、编程助手的严谨风格或者某种固定的报告格式都可以通过几百到几千条高质量示例来微调。这里有一个经常被误解的点微调主要改变的是模型的“行为方式”而不是补充新知识。如果你想让模型知道你们公司内部的某个最新产品信息靠微调去“背”是效率很低的做法——它会编而且很容易过拟合只对训练样本里的那几条有用。遇到需要实时信息、私有知识的情况更好的方案是走 RAG或者把知识写进 Prompt 里。2.3 RLHF与对齐从“能答”到“好好答”只做微调的模型虽然知道“要按照指令回答”但回答的质量不一定符合人类偏好。它会说难听的话、输出有毒内容、长篇大论毫无重点。于是又加了一个阶段RLHF人类反馈强化学习。大致过程是先让模型生成一批回答人类标注员给这些回答排序打分再拿这些分数训练一个“奖励模型”接着用强化学习算法去优化主模型让模型学会“哪种回答更讨人喜欢、更安全、更有帮助”。这就是“对齐”一词的由来——把模型的行为拉向人类认可的轨道上。这个阶段对大模型能不能日常使用是决定性的。没有对齐的模型回答能力再强也不敢放出来给人用。但对普通开发者来说你不需要自己去复现 RLHF只需要知道一件事很多时候你觉得某模型“情商高”、知道拒绝不合理请求、知道不说废话那不是它天生懂礼貌而是被这样训练出来的。2.4 三个阶段的关系用生产流程来理解预训练、微调、RLHF 是先后衔接的流水线预训练让模型掌握语言和世界知识微调让模型学会指令跟随和特定输出形式RLHF让模型的输出更安全、更有帮助。你可以把“基座模型”理解成预训练产物它很强但很难直接使用现在市面上大多数人能直接对话的基本都是走完后面两步的“对齐模型”。实际做应用时你自己训练一个完整大模型的场景极其罕见更常见的是拿现成模型做提示词工程、做 RAG或者拿开源基座模型做领域微调。3. 把模型“跑起来”推理、量化、蒸馏这些部署词学会怎么训练之后程序员真正面对的问题是我怎么把模型部署起来我该选多大的模型我手里的显卡到底带不带得动这一部分讲的是模型部署相关的术语。3.1 训练 vs 推理你不是在跑同一个东西“训练”和“推理”这两个词看上去只是过程不同但背后对资源的需求差异巨大。训练阶段需要保存梯度、优化器状态还要做反向传播因此显存占用通常比推理高出好几倍。同一个 7B 模型16 位精度推理时权重约占 14GB如果训练它加上梯度和优化器状态同样的精度可能轻松超过 40GB。所以你会看到很多“云上租卡跑训练”的方案而不是在本地训练。推理阶段虽然不需要保存梯度但也不是只看模型权重大小。推理时要计算并保存上下文相关的 KV Cache也就是存储历史 Token 的注意力缓存它的大小和输入长度、并发数直接挂钩。一个 7B 模型在做长上下文的并发服务时KV Cache 吃掉的显存可能比模型权重还多。内存估算的一个经验公式把模型权重显存加上 KV Cache 预算再乘 1.2 左右的冗余系数才是你在部署工具里应该配置的最小显存。别只盯着“参数量 × 2”来算。3.2 量化给模型“减肥”的实操量化是当前部署大模型最常用的手段核心思路是把模型权重的数值精度降低。原本一个参数用 16 位浮点数存改成 8 位整数显存直接减半改成 4 位则能降到四分之一左右。用图片来类比就是高清原图变成压缩图肉眼看差别不大但文件体积小很多。具体到实际中现在很多开源模型的部署方案默认就是量化版本。量化主要分训练后量化和量化感知训练训练后量化最为省事直接用原模型做权重转换但精度损失可能稍微大一点量化感知训练在训练阶段就模拟低精度带来的误差效果更好但成本也更高。我踩过的一个坑是量化后跑文本摘要、闲聊看起来没问题但一跑代码生成或者结构化输出偶尔会冒出明显不合理的低级错误。所以如果应用场景是严格的代码、数学、Function Calling有条件的话建议用更高精度版本或者在代码里加一层校验和重试机制。3.3 蒸馏小模型“偷师”大模型蒸馏Distillation和量化是两个容易搞混的概念。量化是压缩同一个模型的表示精度蒸馏是“教师-学生”模式拿一个大模型当老师用它的输出作为监督信号训练一个小模型去模仿它的行为。可以理解成老员工带新人新人不需要读完全部业务资料只需要把老员工处理过的问题吃透就能在多数情况下达到接近的效果。这几年做应用落地时蒸馏的思路很有用。比如你想得到一个延迟低、能部署在私有环境的模型与其自己从零训练小模型不如直接拿现成的大模型生成一批高质量问答对用来微调小模型。这样做成本低、效果好而且你还能挑“老师”最擅长的领域去蒸馏让“学生”只学某个垂直方向。3.4 本地跑 vs 在线服务选型时想清楚这几点部署形态的选择本质上是在显存、带宽、并发、延迟之间做平衡。我个人的建议是单用户调试、想快速验证 Prompt用轻量量化模型 本地推理工具就够了对延迟敏感的生产环境用专业的推理服务框架开启动态批处理和持续优化并发量高且输入文本长的场景一定要把 KV Cache 优化能力考虑进去否则显存会爆得非常快。还有一个经常被忽略的点推理对显存带宽的敏感度远高于对算力的敏感度。很多消费级显卡跑小模型慢瓶颈往往不是算力不够而是显存带宽拖了后腿。所以挑卡时别只看算力标称值要多看显存带宽和显存容量。4. 给模型“装外挂”RAG、Agent、Function Calling这一部分是当前大模型应用开发里最热的方向。毕竟模型本身知识有截止时间、会编造、不能动服务器上的数据所以大家想了很多办法给它“装外挂”。4.1 RAG不懂就查资料而不是硬编RAG检索增强生成是“先用向量检索找到相关资料再把资料拼进 Prompt让模型基于资料回答”的完整框架。我把它比作开卷考试模型不靠记忆硬答而是拿着教材查答案。实际链路通常是四步把你自己的文档、知识库拆成片段用嵌入模型把片段转成向量存入向量库用户提问时把问题转成向量做相似度检索取出最相关的几个片段把片段和原始问题一起放入 Prompt让模型生成回答。RAG 最大的优点是更新实时、不污染模型。文档改了重新索引一遍就行不需要重新训练模型。没少见过有人调了半天模型回答质量最后发现是召回的结果根本不对。RAG 链路里召回决定了回答质量的天花板生成模型只是在那个天花板下写好答案。所以做 RAG 的第一优先级永远是文档切分和召回质量而不是反复改 Prompt。4.2 Function Calling 与 Agent从“聊天”到“做事”Function Calling函数调用也是这几年高频出现的词。它做的事情是当你问模型“帮我查询某个订单状态”时模型并不真的去查数据库而是输出一个结构化的调用请求比如{function: query_order, parameters: {id: 123}}。你的程序收到这个请求后再自己调用真实接口把结果返回给模型由模型生成最终回复。这一步非常关键因为它把模型从“聊天机器”变成了“任务调度器”。在此基础上如果再叠加一个循环——模型根据结果决定下一步调用什么工具、多步执行直到完成目标——就形成了 Agent智能体的概念。用一句话概括模型是大脑Function Calling 是手Agent 是把大脑和手串起来反复试错的执行流程。我给团队做 Agent 时最深的体会是Agent 能不能跑通往往不取决于模型有多聪明而取决于任务拆得够不够细、错误恢复机制够不够完善。如果你让 Agent 一步完成“帮我把所有报表整理好发到工作群”它大概率会卡住拆成“导出数据 → 汇总为表格 → 生成摘要 → 选择目标群 → 发送”每一步都配好验证成功率会明显提升。4.3 RAG 和微调怎么选一张判断表在规划应用时很多人会纠结“我应该做 RAG 还是微调”。我给一个非常朴素的判断表场景特征推荐方案理由需要回答实时信息、私有知识、动态文档RAG数据可随时更新不依赖重新训练需要模型学会固定输出格式、语气、术语微调模型行为层面的改变Prompt写不出来的效果用示例数据训练最直接目标场景同时需要“新知识新行为”RAG 微调各司其职RAG负责提供资料微调负责规范表达数据量少、几十条示例优先Prompt工程微调数据不足容易过拟合先靠提示词试需要离线部署、低延迟、模型体积受限微调 蒸馏用蒸馏让小模型继承大模型能力再微调满足垂直场景这张表不绝对但能帮新手避免两个极端一来就微调、遇到什么都想调或者只信 RAG 对模型气质问题不闻不问。5. 真正让程序员头疼的“性子”幻觉、温度、Prompt工程部署跑通了知识库也接上了你以为就稳了结果模型还是会在关键时刻一本正经地胡说八道。这就要聊到模型中几个“反直觉”的行为特性。5.1 幻觉一本正经地胡说八道幻觉是生成式模型自带的毛病指模型说出看起来有模有样、实际上毫无依据的内容。根本原因是模型在推理时不是在“查数据库”而是根据概率逐 Token 生成最像样的回答它天然有“把话编圆”的倾向。缓解幻觉的常用手段有四个在 Prompt 里明确要求“只能根据给定资料回答资料里没有就说不知道”接 RAG给模型提供外部事实依据让模型给出引用来源或者置信度方便你做人工抽查对关键场景做二次校验比如用另一个模型做事实一致性检查。不要指望一条 Prompt 彻底消除幻觉。训过模型的人都知道这是模型底层生成机制决定的能做的是限制它的发挥范围和事后校验。5.2 temperature 和 top_p控制模型的“脑洞”temperature 和 top_p 是推理时最常调的两个采样参数用来控制回答的确定性和多样性。temperature控制概率分布的平滑程度。温度越低模型越倾向于选最高概率的 Token回答更稳定温度越高越容易选到低概率词回答更有“想象力”和随机性。top_p控制候选词的范围。只从累计概率达到某个阈值的词里选范围越小越保守。打个比方temperature 像掷骰子时允许骰子偏多大top_p 像只给前几名候选人投票权。两者可以同时调但新手不需要同时折腾两个参数先固定一个、调另一个更直观。实测经验代码生成、JSON 输出、数学计算这类任务temperature 直接设到 0.1 到 0.2写营销文案、头脑风暴再往上调0.8 左右开始有惊喜做 Agent 的任务规划我习惯保守一点0.3 上下比较稳定。5.3 Prompt工程三板斧角色设定、few-shot、结构化输出很多人觉得写 Prompt 是玄学其实核心就三板斧。第一角色设定。在系统提示词里告诉模型“你是某客服助手”比在问题里临时说“你是个客服”更稳定。系统级指令的优先级通常更高也更容易贯穿全程。第二few-shot给示例。给一两个“输入-输出”的例子比任何抽象的“请用简洁的语言回答”都有用。模型是模式匹配机器示例就是最直接的模式。第三结构化输出。明确要求返回格式比如“严格输出 JSON包含 summary 和 score 两个字段”并在代码里用解析器校验。这比让模型自由发挥一个纯文本回答解析起来省一百倍心。我还养成了一个习惯把“不要做什么”写清楚。比如“不要输出解释不要使用敬语不要提及你是一个语言模型”。诱导模型漏出“作为AI我……”这种话的往往是没做负面约束。6. 给小白程序员的学习路线和收藏建议术语整理得再多如果不知道从哪里开始学、按什么顺序串起来收藏了也只是吃灰。最后这部分我按自己的学习路径给一份“串联地图”。6.1 术语之间的依赖路线我建议按“数据输入 → 模型原理 → 模型使用 → 质量治理”四段来理解几乎每个名词都能放进这条流水线输入侧Token 决定你喂进去多少个“字”上下文窗口决定模型能看到多少模型本身参数量决定容量预训练和微调决定它会什么量化、蒸馏、推理决定它跑多快、跑不跑得动应用侧Prompt工程决定你怎么指挥它RAG 决定它查不查得到外部资料Function Calling 和 Agent 决定它能不能动手做事质量侧幻觉是它天生的小毛病温度是你可以拧的旋钮对齐是它在出厂前被做好的“素质教育”。这不只是按顺序背名词而是让你在面对一个具体问题时知道该动哪一块回答不准先查召回和 Prompt跑太慢先想量化和部署行为不像样再考虑微调。6.2 可收藏的速查表我做了这么一张表平时写方案、写代码时经常回来扫一眼术语一句话解释程序员类比Token模型处理文本的最小单位字符串预处理的分词粒度上下文窗口一次最多能同时看到的 Token 数固定大小的缓冲区参数量模型内部权重总规模模型容量上限预训练在海量语料上学习语言和知识海量数据预训练底模型微调用标注数据调整模型行为领域数据继续训练RLHF根据人类偏好让模型输出更安全用奖励信号做强化学习对齐推理用训练好的模型做预测模型前向计算量化降低参数精度来压缩模型类似浮点转整型压缩蒸馏小模型学习大模型的输出用大模型生成伪标签训练小模型RAG检索资料再组织回答开卷考试检索 拼 PromptFunction Calling模型输出结构化调用指令让模型生成可执行的函数参数Agent模型 工具 多步循环决策带状态机的自动任务流程幻觉生成看起来合理但没依据的内容模型的“幻觉式自动补齐”temperature控制输出随机性采样噪声开关Prompt工程设计输入指令来引导输出给模型“定作用域”6.3 我的两条真实体会分享两个自己的经验可能比前面的所有术语都值钱。第一条别背术语去“用”术语。我见过很努力的同学把几十个名词背得滚瓜烂熟真上手写一个带检索的问答系统时还是无从下手。反而是那些先跑通了一个最简 Demo、然后对着报错和效果回头查术语的人记忆更牢。技术名词只有在你踩坑时查过的那个时刻才算真正属于你。第二条先建立“最小闭环”再系统补理论。入门阶段不需要把大模型的所有原理都搞懂先把“调 API → 写 Prompt → 拿结果”这个闭环跑起来然后试着把一段业务文档接进 RAG 试试效果再试着让模型调用一个你写的函数。每个闭环都会逼你回头补一个术语不知不觉就把整个地图填满了。最后说句掏心窝的话不要收藏完就再也不打开。顶多三天找个下午照着第一到第五章的顺序把你现在做的东西和这些名词逐个对一遍。你会发现原来它们早就在你手边等着你了。