这一节标题很简单就三个字大模型。但如果你真的把一门深度学习系列课从头跟到第十节走到这儿会有一种很奇妙的接通感前面讲卷积、讲循环网络、讲词向量时我们一直在为“某一个具体任务”训练一套专用模型而到了大模型这一节目标突然变成了——训练一个巨大的通用底座让它自己学会“理解”各种问题。这节课在大模型方向上属于“建立完整认知”的关键一课它想解决的核心疑问其实就三个大模型到底是怎么造出来的它和前面学到的深度学习知识是什么关系作为开发者和学习者拿到一个模型之后应该怎么把它真正用起来如果你是刚学完深度学习基础知识、正准备转入大模型方向的同学这篇内容几乎可以作为你从“会跑模型”到“理解大模型怎么思考”的一座桥。我不会只摆结论会把整个课里最重要的几条逻辑线彻底拆开包括Transformer在做什么、三段式训练怎么把模型从“会接话”变成“会答题”、以及当我真正在本地加载一个开源基座模型对话时踩过的那些文档不会写明的坑。1. 从深度学习到大模型变化的不是名字是解决问题的路径1.1 为什么说大模型不是“更大的网络”很多初学者容易把大模型理解成“层数更多的神经网络”这个说法对了一半但会带来严重的认知偏差。课里有一个比喻我觉得特别准确以前的深度学习像是给一个学生分别报语文、数学、英语补习班每一个任务训练一个专门的模型图像分类就是一个卷积网络情感分析就是一个循环网络加词向量而大模型的做法是直接训练一个“大学生”它可以同时处理翻译、写作、推理、代码生成甚至图像描述类任务精力不够时靠的不是重训而是“临时给它看几个例子、给它一段好提示”。从技术演进看核心变化有三个。第一架构收敛到Transformer。卷积天然适合局部特征循环网络天然适合序列但Transformer靠自注意力机制把序列里任意两个位置直接关联起来这让“并行计算”成为可能也让长距离依赖不再像循环网络那样受限于时间步累加。它的代价是计算量巨大于是才有了后面规模化扩展的可能。第二训练目标发生了变化。传统监督学习需要人工标注大量“输入-标签”数据而大模型的预训练阶段用的是一个极其简单又极其奢侈的目标预测下一个词。互联网上有海量文本模型读完前半句话尝试预测后半句错了就更新参数。就是这样一个“看起来像填空题”的任务在模型足够大、数据足够多时居然“涌现”出了语法、知识、逻辑甚至某种程度的推理能力。这种效果不是谁故意设计出来的更像是在海量压缩中被迫学会了对世界的抽象理解。第三下游任务的适配方式变了。过去我们要用微调把模型改造成分类器、生成器现在大模型只要在提示词里说清楚任务甚至给一两个示范它就能按你的要求输出。微调仍然存在但已经从“必须做”变成了“选项之一”。这一节给我的第一层启发是大模型的“大”不仅指参数量更指它把“特征提取”这件从前需要人工设计的事彻底交给了数据自己决定。你不需要再关心手写特征只需要注意怎么给模型划定边界。1.2 为什么是“现在”才火数据、算力、算法在三重合流其实Transformer架构公布得比普通人感知到的要早得多预训练范式也不是这两年才提出来。那为什么大模型直到这几年才席卷各个领域课程里给了一个很冷静的解释这是一个“三重合流”的爆发缺一个都走不到今天。首先是算力。大模型预训练需要成千上万张高性能GPU组成的集群跑上数周甚至数月。没有分布式训练技术的成熟没有硬件成本的相对下降单是训练一次的费用就足以劝退绝大多数团队。这里插一句分布式训练的几种基本手段数据并行是“每个人拿一份数据、算同一份梯度”模型并行是“把一个大网络切成好几段放到多张卡上”流水线并行更像工厂流水线每一张卡处理完一批数据就给下一张卡。三者在真实训练中通常混着用这也是为什么你在读技术方案时经常会看到“混合并行”这个词。其次是数据。预训练要吃掉的大文本语料是海量的动辄数万亿个TokenToken可以粗略理解成“词片”一个英文单词可能是一个或几个Token一个中文汉字大概是一个Token。这几年开放数据、网页爬取、电子书、论文仓库、代码仓库这些数据源越来越丰富模型才有足够多“上下文”可学。如果数据不够模型再大也只会重复背诵无法泛化。最后是算法和训练的稳定性。预训练一个千亿参数模型训练中稍有不慎就会出现Loss爆炸、梯度异常早期团队花在“让训练不崩”上的时间远超训练本身。现在常用的做法包括更大规模的词表、更稳定的初始化、动态调整学习率、损失缩放以及越来越成熟的中途中断续训机制。这三股力量汇聚之后还出现了一条经验规律业内叫尺度定律在模型规模、数据量、计算量同步增长时模型能力会平稳、可预测地提升。这件事非常反直觉因为以前做深度学习增加模型规模经常边际效应递减但大模型似乎在很大范围内都保持着“越大越聪明”的甜蜜曲线。当然这并不意味着可以无限加参数后期也会遇到数据墙和算力墙但至少它解释了为什么各团队都在拼命把基座模型往大了做。2. 拆开大模型的“黑盒”架构、训练与范式核心2.1 Transformer的核心部件注意力机制在做什么课程进入实操之前花了不少篇幅把Transformer内部结构过了一遍这部分非常关键。你可以把自注意力机制想象成一个会议室每个人发言时都会一边说、一边观察周围人判断谁的发言和当前话题最相关然后给这些人的信息分配不同权重合并进自己的理解里。落实到网络里每个词都会生成三个向量查询Q、键K、值V。Q相当于“我在找什么”K相当于“我能提供什么”V是“我实际提供的具体内容”。注意力分数就是Q和K做点积数值越大代表这个位置和当前词越相关经过Softmax变成一组和为1的权重再对V做加权求和。多头注意力则是把同一个输入放进多个“会议室”并行处理让模型能同时关注比如语法关系、语义相似、指代关系等不同层面的特征。多头机制的优势在于它不需要人工指定哪种关系重要全部交给数据去学。除了注意力块Transformer还有一个关键结构是残差连接加层归一化。这里也和前面课程里的BatchNorm形成了对比BatchNorm是按一批数据的整体统计量做归一化在序列任务里容易受批次长度和分布影响LayerNorm则是按每个样本自己内部的统计量归一化更适应变长序列也让深层网络的梯度能更顺畅地回传。没有残差连接和LayerNorm几十层、上百层的Transformer根本训不动。这一段原理的重要性在于当你真正去阅读一个开源基座模型的论文或配置时看到的hidden_size、num_attention_heads、num_hidden_layers、intermediate_size这些参数都是上面这些概念的数值化。hidden_size就是词向量和隐藏层的维度num_attention_heads就是多头数量num_hidden_layers就是Transformer块堆叠层数。理解了这些你再看模型配置表就不会是一团乱码了。2.2 从“会接话”到“会答题”预训练、指令微调与人类反馈对齐大模型不是天生就会“像个助手一样回答问题”的。课程把训练过程拆成三段每一段的产出物都不一样。第一段叫预训练。这一步就是前面说的“预测下一个词”。模型在海量通用文本上学习语言规律、知识和推理能力但这个阶段的模型只能顺着你的话往下接你输入“今天天气”它可能接“真不错”而不是完整地回答天气问题。很多第一次接触大模型细节的人会困惑为什么预训练模型还能写诗其实它只是把概率最高的下一个Token接龙出来了。从文本续写里能看出潜力但此时它还不是一个合格的对话模型。第二段叫指令微调SFT。做法是准备大量“(用户指令, 标准回答)”这样的监督数据让模型学会“当用户提问时我应该给出完整的回答而不是继续接龙”。这一步相当于给模型立规矩你是助手用户问你什么你要尽力满足。指令数据集的规模通常从几万到几十万条不等质量远重要于数量。课里特别强调了一条经验宁可要5000条精心整理、格式统一的数据也不要50万条爬下来乱七八糟的数据。因为SFT阶段模型的学习能力非常强你给它垃圾格式它就把垃圾格式当成了标准。第三段叫人类反馈对齐RLHF。预训练模型虽然会回答了但仍然可能输出有害、跑题或令人不适的内容。于是训练过程再加一个奖励模型让人类对同一个问题的多个回答排序打分再用强化学习方式调整模型参数使它的输出更符合人类的偏好。这个步骤的成本是三个阶段中最高的但对一个真正面向用户的产品来说不能省。没有对齐的模型就像一个“知识很多但不看场合说话”的怪人。课程里把三段总结成一句话预训练决定上限指令微调决定形态对齐决定安全。你后续做微调时也要牢牢记住这条链在不同阶段注入数据效果是不一样的。2.3 上下文学习与提示工程大模型的“即插即用”大模型范式最有吸引力的一点是“上下文学习”。你在输入框里塞几个例子模型不更新任何参数就能照着例子做新任务。比如你给它例句1用户说“我要退今天的外卖”回复“好的请提供订单号”。例句2用户说“退款多久到账”回复“预计3-5个工作日请留意账单信息”。然后它就会用同样的口吻回答你新问题。这背后其实就是注意力机制在发挥作用模型在生成时读取了前面所有内容把示例当成了“临时规则”来模仿。这也是为什么提示词里的格式示范、角色设定、边界说明往往能比调整模型参数更快地改变输出质量。课程里对提示工程给出了几条立即可用的建议指令要具体不要写“帮我写个方案”而要写“帮我写一份针对新员工的入职培训方案包含目标、时间安排、考核方式和预算估算预算控制在2万元以内”给模型“思考空间”需要推理时直接在提示里加一句“请先列出你的推理过程再给出最终结论”也就是所谓思维链提示限制它的自由度明确告诉它“如果资料中没有相关信息就回答不知道不要编造”。这几条我每一条都在实际对话中验证过尤其是最后一句效果立竿见影。3. 手把手复现一节“大模型实操课”从加载到对话3.1 环境准备显卡、显存与模型选择的匹配思路从课里进入实操环节那一刻起我建议你先别急着跑代码先搞清楚两件事你的机器有多少显存、你能接受多慢的推理速度。一个开源基座模型的参数如果是70亿那么它光权重在半精度FP16下就约占14GB显存。如果还想留一部分显存给计算时的中间状态一张16GB显存的卡勉强能本地跑但上下文一长就非常吃力。这里有个简单的估算公式权重显存约等于参数量乘以每个参数的字节数。FP16下每个参数占2字节70亿参数就是约14GBINT8量化后约7GBINT4量化后约3.5GB。所以初学者最稳妥的路线是优先选择70亿甚至更小规模的开源模型跑通流程后再上更大模型。课程里演示时用的就是这类中等规模基座模型显存占用被压到了可接受范围效果足够用来完成实验和教学展示。环境配置上有一个容易踩的坑是推理库版本和模型文件格式不匹配。很多开源模型发布时会说明它需要什么样的运行环境但网上的教程版本参差不齐。我的经验是如果你从网上找现成脚本先关注“依赖安装”“模型加载方式”“分词器名称”三个字段版本冲突往往就出在这三处。另外如果你没有独立显卡但想快速体验也可以选择云端算力但更接近课程实操的方法是先在本地把7B级别的模型跑通一次它会给你一个非常宝贵的“效果基线”小模型表现如何、幻觉多严重、速度多慢你后面换大模型就会格外珍惜这些对比数据。3.2 加载模型并完成第一次对话真正到加载模型的环节代码本身反而不长。核心步骤是指定模型路径、初始化分词器、调用生成函数。我这里给出一段示意代码实际运行时要根据你使用的开源推理库做名称上的调整# 示意代码加载一个开源中文基座模型并完成一次对话 # 这里的库名是占位示意实际请替换成你选择的推理库 from model_loader import AutoModel, AutoTokenizer model_path models/base-chat-7b # 本地模型目录 tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModel.from_pretrained( model_path, device_mapauto, # 自动分配到可用设备 load_in_4bitTrue # 如果显存紧张可以开启4bit量化 ) prompt 请用三句话解释什么是大模型。 inputs tokenizer(prompt, return_tensorspt).to(cuda) output model.generate( inputs.input_ids, max_new_tokens256, # 控制生成的最大新Token数 temperature0.7, # 采样温度越低越保守 top_p0.9, # 核采样过滤低概率词 do_sampleTrue # 开启采样让回答更自然 ) answer tokenizer.decode(output[0], skip_special_tokensTrue) print(answer)这段代码跑通后你会得到一段像模像样的回答。但我想提醒你第一印象很可能会带偏你因为现在的开源中小尺寸模型在“简短常识问答”上表现都很好你容易低估它的缺陷。务必继续测试这三类问题带有多个限制条件的复杂任务、需要最新知识的问题、完全超出它训练时间范围的问题。我实际测试过小模型在前两类问题上的失败率会远比想象中高这就是幻觉和数据新鲜度问题后面会专门排查。3.3 量化与低资源部署让模型在普通电脑上跑起来如果本地显卡只有8GB甚至更低显存量化就是绕不开的步骤。量化的本质是把模型权重从高精度数值压缩到低精度数值比如从FP16的16位浮点压缩到8位或4位整数。你可以把它理解成“把一张高清照片压缩成适合手机浏览的版本”肉眼可能看不出太大区别但文件体积和加载速度都受益明显。这里要讲一个很容易被误解的点量化并不一定降低太多效果。对于70亿参数的模型4比特量化通常能保留绝大部分常识和对话能力推理速度甚至可能更快因为显存占用变小后模型能一次加载更多层减少了数据频繁搬运带来的开销。代价是极复杂推理任务的准确性可能下降偶尔会出现“似乎懂但表达拧巴”的情况。实操时我建议的测试组合是同一段提示词分别用全精度、8比特、4比特各跑一遍然后对比回答稳定性。不要只看一两次回答就下结论因为采样过程天然有随机性至少要对比3到5轮。如果你手里的机器没有独显只有CPU也不是完全不能跑。7B量化模型在CPU上不是不能用但生成速度会比较感人可能每秒只能输出几个Token基本只能“慢速问答”。而如果使用GPU同样模型通常能快几十倍。这个差距在你给用户做交互应用时会非常致命。所以课程里反复强调部署预算里显卡的优先级高于一切。4. 把大模型接进真实业务RAG、Agent与工作流4.1 检索增强生成先查资料再回答课程到后半部分开始讲落地第一个重点就是RAG。它解决的核心问题是大模型的知识停留在训练那一刻而且它还会一本正经地编造事实。RAG的思路很朴素——先让模型从外部资料库里检索相关内容再把检索结果和用户问题拼在一起让模型“看着材料回答”。具体流程可以拆成三步第一步把文档切分成小块小到什么程度很关键我一般按每个块200到500字左右切分块之间留50字左右的重叠目的是避免一句话被从中间切断导致检索时丢失关键上下文。第二步用嵌入模型把每个文本块转成向量存入向量数据库。第三步用户提问时把问题也转成向量做相似度检索挑出最相关的Top-K个块连同原始问题一起交给大模型生成最终答案。判断“相似”最常用的是余弦相似度两个向量夹角越小越相似分数越接近1。实操中分数在0.8以上通常算比较相关低于0.6的建议不采纳。这也解释了为什么你在做RAG时经常看到Top-K设置为5或者10K太小容易漏掉关键资料K太大又会把不相关的内容塞进上下文干扰回答。4.2 从问答到行动Agent与工具调用如果说RAG让模型会“查资料”那么Agent让模型会“办事”。一个常见的 Agent 工作流是模型收到任务后先自己拆解任务然后决定要不要调用外部工具比如查天气接口、执行一段代码、调用数据库拿到工具结果后再综合判断如果没有解决就继续思考、再调用直到完成任务。课程里给了一个非常直观的例子用户说“帮我查一下最近三天某地有没有适合跑步的天气”。模型不是直接回答而是先判断需要天气数据调用天气查询工具拿到降水、风速、温度后再对着这些数据“思考”是否适合跑步最后组织成自然语言回复。这种“推理-调用-再推理”的循环是大模型应用里最能体现价值的部分。但Agent也有它自己的麻烦如果不对模型的行为做限制它可能陷入反复调用工具的循环或者调用工具后把中间过程和最终答案混在一起输出。做应用时一定要给Agent设定“最大执行轮数”超过就停下来向用户求助同时要让工具调用的权限尽量小而精确能在沙箱里跑的代码就不要放到真实服务器上执行。这些不是理论而是我用测试用例跑出来的血泪经验——一次失控循环可能比一次直接答错更让人头疼。4.3 用RAG搭一个个人知识库的关键成本很多读者看到RAG觉得很兴奋以为可以立刻搭一个私人助手。实际上搭建本身不复杂但有几个隐藏成本你需要提前心里有数。数据准备是最耗时的环节。你要把散落在文档、笔记、网页里的资料统一清洗成纯文本并决定哪些内容值得入库。嵌入模型的选择也会影响检索效果不同模型的向量维度从几百到几千不等维度越高通常表现越细但也更占存储和计算。如果你的资料有专业术语或小众人名常见嵌入模型可能会召回不准这时需要额外做同义词扩充或自定义词典。推理成本同样要算清楚。每次用户提问你不仅要把问题转成向量做一次检索还要把所有召回文本拼进提示词送给大模型。上下文越长生成越慢、费用越高。我见过很多人在小范围测试时觉得一切都好上线后才发现推理成本远超预期于是不得不做缓存、限制用户提问次数、把大模型换小模型。所以做RAG产品前先用你自己的资料库做一次真实规模压测别只在几十条数据上自嗨。5. 常见问题与排查技巧实录5.1 现象模型回答幻觉严重这是本地部署大模型后被问得最多的问题。模型自信满满地编造事实有时连参考文献都敢伪造。排查顺序我建议这样先降低温度。温度越高输出越有创造性也越容易“放飞”把温度降到0.2到0.5通常能明显减少胡编。看知识时效。如果问题涉及近期发生的事模型大概率不知道因为它的知识截止在训练阶段这种情况别硬靠提示词解决直接上RAG。加护栏提示。在系统提示里明确写“如果资料中没有相关内容请直接回答不知道”。考虑换更大规模的模型或指令微调过的版本。小模型知识密度更低幻觉概率天然更高。有一个很强的判断技巧同一问题跑5次如果5次答案核心事实都一致但表述有差异基本说明模型“确实知道”如果每次给出的细节都对不上甚至自相矛盾那多半是它在“圆”。这个技巧在你不知道模型底细时尤其好用。5.2 现象推理速度太慢、卡顿先说结论性能瓶颈通常不在“生成多少个字”而在“每生成一个字都要做一次全模型的前向计算”所以任何减少单次计算量或提高并行度的方法都能加速。排查步骤第一优先确认模型是否真的跑在显卡上而不是因为没装好对应工具包、退回了CPU模式。第二看上下文长度输入越长注意力计算量越大建议先缩短系统提示词和检索出的文本块数量。第三看量化等级4比特模型通常比FP16更快因为它对显存带宽要求更低。第四看是否开启了流式输出如果你一直在等全部回答生成完再显示体验自然会很差开启流式输出后首字到达时间会大幅缩短。课程里还提过一个概念叫批处理推理多个用户请求打包成一批同时计算GPU利用率和总体吞吐量会大幅提高代价是单个请求的响应时间可能变长。所以做API服务时如果并发高优先考虑批处理而不是单纯加大单次模型能力。5.3 现象输出总被截断或写不完很多人把max_new_tokens设得太小回答长一点就被切掉。但还有一个容易被忽略的点中文Token与字的换算关系。英文一个词可能占一个Token而中文一个字通常要占1到2个Token所以如果只按英文习惯估算中文回答会很快顶到上限。处理办法一是把max_new_tokens调大比如希望模型写500字至少要给1000到1200个Token二是优化提示词让模型先给结论后展开三是开启流式输出让用户在生成过程中就能看到内容即使后续被截断也至少能保留前文。另外如果你用了RAG检索引文太长会挤占生成空间时刻记住总长度是有限制的因此检索出的文本块要精不要多。5.4 现象微调之后并没有变聪明反而变笨了这是把“微调”当“补知识”踩的典型坑。指令微调的正确用途是改变模型的“行为风格”和“响应格式”而不是往模型脑子里灌新知识。如果你只有几百条数据想让它学会回答特定领域问题大概率微调完模型不仅没学会新知识反而把原本知道的通用知识忘了一部分。这种情况叫灾难性遗忘。补救思路是先用RAG把知识外置让模型检索后再回答如果确实必须微调数据量至少按万条起步并且格式要高度统一比如全是“用户指令 系统要求 标准回答”三段。如果资源有限用低秩适配LoRA这类参数高效微调方法它只训练原模型里一小部分低秩矩阵显存占用低也不容易破坏原有能力。学习率不要照搬预训练时的设置微调阶段学习率要低一个量级否则步子太大会把原有参数冲乱。6. 给初学者的进阶路线与大模型影响范围观察6.1 学习路线建议如果你的目标是从这节课走向真正的大模型开发我建议按下面这个顺序走而不是一上来就去读千亿参数的论文。第一步把推理跑通。加载任意一个开源基座模型量化、对话、流式输出、参数调参都亲手调一遍。这一步让你理解模型是怎么运行的建立对速度和质量的直观感觉。第二步理解数据。练手构造指令数据集做清洗、格式转换、按比例拆分哪怕只是几百条也要把流程走一遍。第三步复现一次微调。用LoRA方式在单卡上微调一个小模型观察Loss变化验证它在特定任务上的行为改变。第四步做一次完整RAG项目。从一个只有十篇文档的小知识库起步逐步优化切分、检索和提示词。第五步再回头读论文和实现细节这时你会发现自己能看懂了而不是在逐字硬啃。每一步都要留“实验记录”包括模型版本、参数、数据样例、输出结果和问题现象。因为大模型实验的随机性不小不做记录三天后你根本分不清哪个配置才是真正有效的那个。6.2 大模型带来的影响范围这节课最后讨论的是“影响范围”。在我看来最直接的冲击发生在“知识型工作”的执行方式上。过去写代码是一个词一个词敲出来的现在更像是“描述需求、提供上下文、评审结果、修复边界”过去写方案需要从零搭建结构现在更像是“给模型一个骨架、让它填充、再逐段修改”。这也改变了初级开发者的入门路径以前要背大量API和函数现在更多是知道“有什么、去哪查、怎么校验”。对开发者来说真正稀缺的能力正在变成三种一是“把问题描述清楚”的能力这决定了大模型能不能产出符合预期的东西二是“搭建数据闭环”的能力包括数据清洗、反馈收集、格式规范三是“评估和兜底”的能力能设计测试集验证模型效果并能在模型犯傻时稳住整个系统。这些能力都不是“会调模型接口”就能替代的反而是大模型时代更值钱的护城河。如果只看眼前你可以先把大模型当一个效率工具用起来如果你想把方向做得更深就沿着“数据、评估、推理优化、Agent工作流”这几条线往里挖。技术迭代很快但上面这些底层能力至少在三五年内不会过时。我个人实际跑完这一节之后最大的改变是以前我拿到一个新模型第一反应是“它能答什么”现在第一反应变成了“它在什么条件下会答错”。这个思维转变很关键。模型的能力上限固然重要但它在你具体场景里的失败模式、数据边界和成本曲线才真正决定一个产品能不能落地。如果让我给初学者一个最实在的建议那就是不要满足于跑通官方示例尽快把模型丢进你自己最熟悉的领域里做一百道题测试把每一次错误回答都记录下来。这些记录才是大模型时代最保值的东西。