想入门大模型的人越来越多我几乎每周都会被问同一个问题有没有一份靠谱、能从头跟到尾的系统性学习资料。网上的资料其实并不少但大多是单点教程——今天讲Transformer明天教部署后天聊微调单独看每篇都对串起来就乱了。这份“大模型的系统性入门资料”与其说是资料合集不如说是一条学习路径它有明确的先后顺序每一阶段解决什么问题、为什么先学A再学B、需要什么硬件和门槛我都会按照自己的实操经验讲清楚尤其适合刚接触大模型的学生、准备转行做AI应用开发的工程师以及公司里被安排去做大模型落地但还没找到头绪的同学。我会按一个项目从零到落地的实际顺序来组织先建立基础直觉再选模型和工具跑通一次对话然后掌握提示词工程和上下文工程进而是微调最后是部署与性能优化。每到一个节点我会把参数、命令、代码、踩坑记录都放进去尽量让这份资料能直接照着操作而不是看过就忘。1. 学习路线总览四个阶段先看清终点再上车系统性学习和刷教程最大的区别在于你知道每一步在整张地图上的位置。我建议把大模型的学习拆成四个阶段每个阶段解决一类具体问题。第一阶段是概念层搞懂大模型是什么、它是怎么做预测的、训练和推理有什么不同、为什么显存不够、为什么有上下文窗口这个概念。这个阶段不碰代码纯建立直觉。第二阶段是工具层选一个模型、用一个框架把大模型跑起来知道API调用和本地部署的差别体验一次完整的对话。第三阶段是应用层在会调模型的基础上学提示词工程、上下文工程、检索增强RAG把模型的能力真正用进业务里。第四阶段是训练层数据整理、微调、对齐、评测理解“为什么通用模型不够”以及“怎么让它更专业”。这个顺序是我实际走下来的体会也是我建议新手遵循的顺序——先动手跑通再回来看原理效率最高。很多人一上来就读论文、啃Attention机制结果半个月后连一个对话都没跑起来热情全耗光了。反过来如果连模型都不会调用直接做微调出了问题你根本分不清是数据问题、参数问题还是框架问题排错成本非常高。每一阶段都有明确的结束标志第一阶段你能用自己的话解释“为什么大模型像在做下一个词的预测”第二阶段你能在本地或云端完成一次对话并且说清楚模型参数、量化、上下文窗口这些概念第三阶段你能写一个带流式输出和中断控制的聊天应用第四阶段你能用一套数据集把开源模型微调成某个垂直场景的助手并部署上线。拿这四个标志当里程碑学习就不会茫茫然。2. 第一阶段把大模型的基本原理吃透不需要推导但要懂机制这一阶段的目标不是让你手推公式而是建立正确的心理模型也就是“脑子里有一个大模型是怎么工作”的画面。很多人在这个阶段走弯路是因为想一步到位把数学全部看懂其实没必要。你只需要理解三个核心机制Token化、自注意力、自回归解码外加两个工程概念上下文窗口和KV Cache。2.1 Token化、词向量与“预测下一个词”大模型不是直接读文字的它先要把文本切成Token你可以把Token理解成模型眼中的“词块”。中文里一个汉字可能对应一到两个Token英文里一个单词可能拆成几个Token这也是为什么同样一段话在不同模型里的Token开销不一样。切完Token后每个Token会被转换成一个向量也就是Embedding。这些向量互相之间有远近关系“猫”和“狗”的向量距离比“猫”和“汽车”近。大模型的绝大部分参数都在做一件事根据已有的Token序列预测下一个Token的概率分布。你问我“什么是大模型”模型不是真的理解了这句话而是根据训练时见过的海量文本里“什么是大模型”后面通常接什么话去逐字生成一个概率最高的答案。生活类比就是输入法你打了一句话输入法根据前面的字猜测你下一个字要什么。大模型就是这个输入法的超级加强版只不过它的“训练语料”大到可以用“整个互联网”来形容所以它的猜测看起来像是理解甚至像在推理。这个直觉一旦建立后面所有概念都顺了——包括“幻觉”幻觉本质上就是模型在概率上自信地猜错。2.2 自注意力与位置编码Transformer是大模型的骨架它里面最核心的模块叫自注意力Self-Attention。自注意力做的事情简单来说是让序列里的每个Token都能“看到”其他Token然后决定自己应该从谁那里吸收信息。比如一句话里“小明放下书因为他累了”“他”指的是谁自注意力机制会让“他”更多地关注“小明”而不是“书”。同时模型还得知道Token的顺序不然“我打你”和“你打我”就分不清了。这就是位置编码的作用。现在绝大多数主流模型用的是RoPE旋转位置编码它的特点是外推性较好能处理比训练时更长的序列这也是很多模型宣称“128K上下文”的原因之一。还有两个工程概念值得单独讲因为它们和后面部署优化直接相关。一个是上下文窗口也就是模型一次能处理的Token总量窗口越大能输入的资料就越多代价是显存和计算量直线上升。另一个是KV Cache——模型生成每个新Token时要把前面所有Token的计算结果Key和Value存下来复用不然每次都从头算一遍就太慢了。这也是为什么长对话会越聊越慢、显存越来越吃紧因为KV Cache在持续变大。理解了这两个概念后面调部署参数时你就会有方向感而不是盲试数字。2.3 训练和推理、多模态的本质区别很多新手分不清“训练”和“推理”这会导致对硬件需求的误判。简单说训练是模型学习参数的过程需要反复看大量数据、反向传播更新权重算力消耗大推理是模型拿着学好的参数对新输入做预测速度快得多。大模型在推理阶段主要吃显存因为要把模型参数加载进去再加上每句话都会增长的KV Cache训练阶段则既要大显存又要高算力因此微调比部署难得多这部分第五阶段再展开。多模态大模型和纯文本大模型的区别也好理解。它相当于在原有文本模型结构外加了一个“视觉编码器”——先把图片切成小块、变成向量再通过一个投影层把这些向量转成文本模型认识的表示空间。所以多模态模型能看图、读图、理解视频帧本质上还是把视觉信息翻译成了“模型能读懂的语言”。现在很多开源模型都支持图文混合输入它们在OCR、截图理解、文档解析这些场景比传统方法强非常多这也是我建议应用开发者优先关注多模态模型的原因——文本能力差异未必大但“看得懂图”这件事在很多业务里是刚需。3. 第二阶段选对模型和工具先跑通一次对话理论直觉够了就该动手了。这个阶段最忌讳的就是“选择困难”——今天看这个模型出来想试试明天看那个框架火又想换结果一周什么都没跑通。我的建议是先选定一个开源模型、一个部署工具、一台能用的电脑跑通一次端到端对话再谈优化和换方案。3.1 主流模型家族怎么选世界上的知名大模型可以分为闭源API型和开源可部署型两条线。闭源代表有GPT系列、Gemini、Claude以及国内的很多商用大模型开源代表则有Llama系列、Qwen通义千问、GLM智谱、DeepSeek、Mistral等。如果你是个人开发者或想做私有化部署优先考虑开源模型如果你只是想快速做产品验证API是最省事的方式。开源模型的选型维度我一般只看四个能力水平、许可证合规性、社区生态、显存要求。能力方面Qwen和Llama是目前开源阵营里综合表现比较稳的两个系列GLM对中文场景的适配也做得不错DeepSeek在推理类任务上表现突出。许可证要额外注意虽然开源但不同模型允许商用的情况不一样落地前一定要查清楚否则后面交付会有法律风险。社区生态指的是周边工具链是否丰富比如是否有大量教程、是否被主流推理框架适配这一点会直接影响你后续开发和排错的速度。一个比较实用的“新手默认配置”本地部署选Qwen2.5-7B-Instruct云端API测试选主流的闭源API。7B级别模型在量化后只要8GB左右显存就能流畅跑是学习性价比最高的尺寸。等到你摸清了门道再按任务特点去尝试更大模型那时你自然知道自己要什么。3.2 API接入与本地部署的成本对比接入大模型的方式主要有三种按成本和门槛从低到高排列云API、本地推理部署、本地微调训练。云API的优点是完全不用管硬件按调用量付费几十行代码就能把大模型接入应用适合产品原型和小流量业务。缺点是按Token计费高频调用成本不低数据要出本地对数据敏感的企业会有顾虑。本地推理部署是用Ollama、LM Studio、vLLM这类工具把模型跑在自己的机器或内网服务器上前期成本是一次性的硬件投入后续调用免费、数据可控适合私有化和高频场景。本地微调则是在本地部署的基础上更进一步通过训练调整模型权重满足特定格式、风格或私有知识的需求对GPU配置要求最高。我把三者理解成API是租车本地部署是买车微调是改装车。新手阶段建议“先租车”熟悉驾驶同时“买一辆便宜车”小模型本地跑练手等真正清楚需求后再考虑“改装”。3.3 本地部署实操Ollama跑通7B模型如果你有一台普通电脑哪怕没有独立显卡也可以先用Ollama把大模型跑起来。Ollama是目前个人本地部署大模型最顺手的工具跨平台支持macOS、Windows、Linux安装完就是一个命令行起服务的“模型管家”。我以Qwen2.5-7B-Instruct为例完整步骤是这样的先去Ollama官网下载对应系统的安装包安装完成后打开终端执行ollama run qwen2.5:7b。第一次运行它会自动下载模型权重如果显存不足或没有GPU它会回退到CPU推理CPU跑7B模型会明显慢但用来验证流程完全没问题。这里提醒几个常见坑。第一Windows下安装后如果无法在终端直接运行多半是环境变量没生效重启终端或手动把安装目录加进PATH即可。第二默认模型是Q4量化格式也就是4比特量化参数文件缩小到4GB左右配合8GB内存也能勉强跑如果你的机器配置更高可以看ollama run qwen2.5:7b-q8_0这种更高精度的版本效果更好但显存占用更高。第三如果需要图形界面可以再装一个Open WebUI用docker启动后浏览器访问本地地址体验和商业产品基本一致特别适合演示给团队看。跑通之后你在本地就有了一个随时可调的模型服务默认监听11434端口支持OpenAI兼容的API格式。这点很关键它意味着你后面写的所有应用代码都可以在“本地模型”和“云API”之间无缝切换只需要改一个base_url。4. 第三阶段应用层开发提示词工程与上下文工程才是重头戏模型会调用了真正的应用开发才刚刚开始。应用层有两大核心技能提示词工程和上下文工程。这两者经常被混为一谈实际分工完全不同——提示词工程解决的是“怎么把任务说清楚让模型照着做”上下文工程解决的是“决策给模型看什么、什么时候看、怎么组织这些内容”。4.1 提示词工程的核心是把任务描述清楚而不是“念咒”提示词工程不是玄学咒语它本质上是一种沟通方法。你和一个聪明但容易自作主张的助手说话想让结果稳定可靠得把角色、背景、要求、示例、输出格式都说清楚。我常用的结构化提示词模板是这样的第一段设定角色和能力边界比如“你是一个资深数据分析师只能根据给定的数据回答不得编造”第二段交代背景和任务把要处理的材料放进来第三段明确约束条件比如“回答不超过200字”“用Markdown表格输出”“如果信息不足直接说不知道”第四段给一两个示例也就是few-shot让模型照着示例的风格和格式输出。很多人写提示词最大的问题是有歧义。你问“帮我总结一下”模型不知道总结成一页PPT还是一句话。你改成“把这篇文章总结成3条不超过30字的要点分别对应背景、问题、建议”输出就会稳定得多。我自己做项目调试时会先写一版提示词然后拿5个不同案例去跑看哪个输出不符合预期再反向修改提示词这个迭代过程比搜教程管用。4.2 上下文工程决定模型“看到什么”比“怎么说”更值钱提示词工程解决“怎么说”上下文工程解决“给它什么”。模型上下文窗口是有限的哪怕支持128K也不能什么都往里塞塞得越多响应越慢、费用越高、注意力越分散。上下文工程的核心是三个动作筛选、组织、压缩。筛选是指从你的知识库或对话历史中找出与当前问题最相关的内容这是RAG检索增强生成的核心环节。最简单的流程是把你的文档切成小块用向量模型转成向量存进向量数据库用户提问时也转成向量检索出最相似的一批片段把“用户问题检索到的片段”组装到提示词里交给大模型回答。组织是指管理多轮对话的历史。长对话不能全量回传要保留近期内容、把更早的内容摘要化或者只提取与当前问题相关的关键信息。压缩则是用模型或算法把长文档先做摘要再进上下文适合超长材料处理。很多团队做大模型应用效果迟迟上不去问题往往不在模型而在上下文管理太粗糙——什么内容都堆进去模型反而抓不住重点。上下文工程里还有一个关键机制是Prompt Cache也就是提示词缓存。重复的上下文比如系统提示词或长篇文档在服务端做缓存后能显著缩短响应时间并降低费用。在有些平台上命中缓存的输入Token费用可以降低到原来的十分之一甚至更低。做应用开发时把不变的内容放在前面、把易变内容放后面是充分利用缓存的一个简单技巧。4.3 API调用实战SSE流式输出与中断控制大模型回答是逐字生成的等全部生成完再返回用户会等得着急所以现在主流做法是用SSEServer-Sent Events流式输出也就是把每一段增量文本分多次推给前端用户看到的是“正在逐字打出”的效果体验好很多。后端代码我用Python的httpx库写一个流式调用的示例假设本地跑着Ollama或vLLM地址是http://localhost:8000/v1/chat/completionsimport httpx import json def stream_chat(messages): payload { model: qwen2.5:7b, messages: messages, stream: True } with httpx.stream( POST, http://localhost:8000/v1/chat/completions, jsonpayload, timeout60, ) as response: for line in response.iter_lines(): if not line or not line.startswith(data: ): continue data line[6:] if data [DONE]: break try: chunk json.loads(data) delta chunk[choices][0][delta].get(content, ) if delta: yield delta except json.JSONDecodeError: continue这段代码看着简单但有个容易被忽略的细节如果响应里每个chunk是完整的增量内容直接解析就行但遇到网络抖动可能会传出半行JSON。所以我在解析前用try...except json.JSONDecodeError兜底宁可丢掉这一个chunk也不能让整个请求崩掉。生产环境中我还建议加一个超时时间避免模型卡住导致连接一直挂着。前端配合流式输出时现代浏览器的fetch可以读取流AbortController则负责中断。用户点击“停止生成”时前端调用controller.abort()就能终止请求这条连接的资源才能及时释放。一个基本的JavaScript示例const controller new AbortController(); const resp await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages }), signal: controller.signal }); const reader resp.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const text decoder.decode(value, { stream: true }); // 把 text 继续交给界面渲染 } // 需要停止时 controller.abort();这里有个后端容易踩的坑客户端断开连接后后端生成进程未必会立刻停止尤其在最终生成还没结束时。如果不做处理每一轮中断都会白白消耗算力。在使用FastAPI这类框架时可以利用Request.is_disconnected()在生成循环里检查客户端是否断开断开后提前中断循环并清理模型请求。多试几次之后你会发现这类“响应快、中断灵”的基础体验恰恰是很多大模型应用和Demo拉开差距的地方。5. 第四阶段微调实战从LoRA到全参别急着把模型喂饱应用层做熟之后你会开始遇到通用模型解决不了的问题输出格式不符合业务要求、回答风格不对、不了解你的私有术语和规范文档。这时才轮到微调上场。但请记住一句话微调是最后手段不是第一选择。5.1 先用提示词和RAG试错微调是最后手段我见过太多团队上来就要微调问原因却说不上来只是觉得“不微调显得没有技术含量”。实际上一个需要特定格式输出的任务提示词里写清楚 给两个示例就能解决一个需要参考内部文档回答的任务RAG就能解决只有当你手里有足够多的“用户问题-理想回答”对且任务表现稳定差、用提示词和RAG都无法改进时才应该动用微调。判断是否该微调的三个信号任务需要固定输出结构比如从文本中抽出来的“关系三元组”必须按统一JSON格式、回答风格极其固定比如客服话术、法律文书、私有术语出现频率高且错误率高。满足其中之一且数据量达到几百上千条对话对就可以考虑微调了。5.2 LoRA为什么能一卡微调显存账要算清楚微调大模型最头疼的是显存。以7B模型为例全参微调使用混合精度训练参数本身在FP16下占14GB梯度再占约14GBAdam优化器还要为每个参数保存两份FP32的动量状态这又超过56GB。也就是说光参数、梯度和优化器状态就要80GB以上显存再加上激活值一张A100 80G都紧巴巴普通玩家根本负担不起。这就是LoRA这类参数高效微调技术出现的原因。LoRA的思路非常简单冻结原始参数不动在每个线性层旁边加一条低秩旁路矩阵A和B用降维再升维的方式模拟权重更新。需要训练和保存的只有这两个小矩阵可训练参数往往不到原模型的1%。比如7B模型LoRA rank设为8只训练attention和MLP的旁路实际可训练参数可能只有几百万。显存大头就剩“加载原始参数”和“少量训练状态”一张24GB消费级显卡就能跑起来。如果再配合4bit量化加载模型也就是QLoRA显存还能进一步降低到16GB左右。我通常建议新手直接走LoRA路线因为效果逼近全参微调但显存和训练时间都低一个量级试错成本低很多。等你把数据、训练、评测这套流程跑顺了再根据业务需要决定是否升级到更大规模的全参微调。5.3 一套能落地的微调脚本用LLaMA-Factory做SFT工欲善其事必先利其器。我第一次做微调是最原始的写脚本方式踩坑无数。后来换用开源的LLaMA-Factory训练流程大幅简化它内置了数据格式、模型加载、LoRA配置、评估接口对新手非常友好。安装并拉取项目后数据准备是第一步。微调数据一般用Alpaca格式也就是一句指令、一段可选输入、一段理想输出[ { instruction: 用一句话解释大模型, input: , output: 大模型是一种通过大规模语料预训练获得的深度学习模型能够生成文本、理解语义并完成各类语言任务。 } ]准备好数据文件后启动训练的命令大致如下llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --dataset alpaca_zh \ --finetuning_type lora \ --lora_rank 8 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --output_dir ./output/qwen-lora这些参数不看文档直接抄大概率出问题但有几个规律可以分享batch size受显存限制显存不够就先调小单卡batch size再用gradient accumulation堆等效步数让梯度更新尽量平稳学习率方面LoRA一般用1e-4到3e-4全参微调则更低用1e-5到2e-5epoch数不要盲目设大小数据集3到5轮就够太多会过拟合表现为训练loss很低但验证集表现反而变差。训练过程中建议开启验证集评估如果没有验证集至少保存最后一次和最佳一次的checkpoint。训练完成后用LoRA merge把旁路矩阵合并回主模型再导出为完整的模型文件就可以丢进Ollama或vLLM里部署了。这里有一个告诫微调最怕的是数据质量差如果你的数据里本身就有大量矛盾回答、格式混乱的样本再好的训练配置也救不回来。所以在跑训练前务必留出时间清理数据数据干净微调就成功了一半。5.4 GPU微调时三个容易翻车的细节GPU微调比推理对硬件和状态敏感得多我有三个印象很深的教训。第一个是显存溢出OOM。训练到一半报显存不足很多人第一反应是调小batch size但更快的排查路径是看激活值——如果序列长度过长比如4096以上激活值会指数级增长。优先缩短max_seq_len或开启gradient checkpointing梯度检查点用计算换显存比一味调batch size更有效。第二个是loss不降或乱跳。这种情况90%是数据问题可能是instruction和output的顺序写反了可能是数据里有大量空输出也可能是不同任务格式混在一起没有加分隔。你可以先挑几条样本人工跑一遍推理看模型在训练前给出的输出长什么样再决定是清洗数据还是调整格式。第三个是训练后模型“变傻了”。比如对话能力退化、说两句就重复。这通常是因为指令数据里纯生成类任务占比过高缺少通用对话数据导致模型对指令的理解被带偏。解决方式是在微调数据里混入一定比例的通用对话数据保持模型的通用能力。做微调不要只盯着训练loss训练后的模型真实对话表现才是唯一标准。6. 推理部署与性能优化模型跑起来只是第一步微调完模型要上线给业务用这时考验的重点从“训练”转向“推理性能”。同一个模型用朴素方式加载和用高性能推理框架加载并发能力和吞吐可以差出好几倍。这部分我重点讲推理框架选型、量化选择和几个容易被忽视的线上问题。6.1 推理框架选型Ollama适合轻量私有化vLLM适合高并发服务本地个人使用或团队小范围试用Ollama仍然是首选它封装完善、模型管理方便、API兼容OpenAI。但如果要做正式的服务并发高、QPS有要求我建议上vLLM。vLLM最核心的优化是PagedAttention你可以把它类比成操作系统里的虚拟内存分页KV Cache不再是一整块连续显存而是按页分配碎片更少、共享更方便显存利用率大幅提升同时它支持连续批处理多个请求的生成可以穿插进行GPU永远在处理有效计算而不是干等。vLLM的部署命令很直接比如我微调完后启动一个服务vllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --served-model-name my-model它会自动监听8000端口提供的接口和OpenAI兼容所以之前写的Python流式调用代码几乎不用改只把base_url从Ollama换成vLLM就行。如果你的模型很大且有多张卡可以通过tensor-parallel-size参数把模型切到多卡并行推理单卡放不下的问题也能解决。6.2 量化怎么选GGUF、GPTQ、AWQ的取舍模型权重动辄几十GB普通机器放不下量化的意义就是把权重从FP16的16bit压到8bit、4bit甚至更低用精度换显存和速度。目前常见的有三种路线GGUF主要用于CPU和边缘设备推理配合Ollama这类工具体验最好GPTQ和AWQ主要用于GPU推理GPTQ适配成熟、AWQ的激活值量化在某些场景下效果更稳。量化级别选择上我个人的经验是4bit量化Q4_K_M或INT4在显存有限时是甜点档位模型质量下降可控8bit量化质量更好但显存占用接近翻倍低于4bit的量化会出现明显的“模型变笨”现象不建议用在生产环境。如果你的显存能放下FP16原版优先跑原版量化是取舍而不是升级。量化里的一个坑是不要拿量化后的模型直接做微调。虽然QLoRA可以在4bit基座上训练但训练完成后要把LoRA权重合并回去再导出再做一次量化或直接用原精度部署。图省事在量化模型上合并再部署容易遇到结果漂移。6.3 线上服务的并发、长文本与优雅降级推理服务上线后除了框架还要处理并发、长文本和降级策略。第一是并发控制不是并发越高越好显存有限时过高的并发会导致请求排队甚至OOM所以要给模型服务加上最大并发限制超出的请求排队等待或直接返回“忙”。第二是长文本处理用户的输入长度如果超过max-model-len必须先做截断或摘要再送入模型否则调用直接报错。第三是超时与重试流式接口要设置合理的超时时间调用方在超时后做指数退避重试同时避免重试风暴。还有一个容易被忽略的点是“用户取消生成”和“服务端流式连接关闭”的配合。前面讲的AbortController只是前端断开了连接服务端能不能感知到、什么时候停止计算直接关系到无效算力消耗。做完这套配合之后线上成本能省下不少也避免了一个用户反复点击“停止”导致GPU一直空转。6.4 安全评测与知识抽取容易被忽略的两个方向模型上线前我强烈建议补一趟安全评测也就是“投毒测试”“越狱测试”这类对抗性测试。大模型面对恶意输入可能被诱导出不该输出甚至错误风险的内容做一个基础的评测列表把典型高风险的输入喂一遍观察输出是否合规、是否东拉西扯比上线后再补救成本低得多。尤其面向公开用户的产品评测报告也应该作为上线材料的必备项。另一个容易被忽略的方向是知识抽取也就是把非结构化文本里的事实、关系、实体抽成结构化知识。做问答、知识图谱、风险合规检查等业务时这几乎是个前置工序。像OneKE这类开源的知识抽取框架能比较稳定地把实体、关系、事件抽取出来配合大模型做抽取再校验比直接甩给模型输出JSON要可靠得多。如果你做的是文档密集、知识密集的业务这个方向值得纳入学习路线里它是大模型从“聊天”走向“干活”的关键能力。7. 常见问题排查速查表把踩过的坑直接对照着修我把这几年在实际操作中反复遇到的典型问题汇总成一张排查表遇到症状先对照“可能原因”找方向再按“解决思路”试大部分问题都能在半小时内定位到根因。症状可能原因解决思路本地推理速度极慢CPU推理且模型未量化换更小的量化版本或接入GPU确认显卡确实被调用而不是默默用CPU跑Ollama启动失败/命令找不到环境变量未配置把Ollama安装目录加入PATHWindows重启终端或重新登录API调用总超时模型生成过长/并发过高限制max_tokens增加超时时间降低并发观察显存占用SSE流式输出缺字、断句网络抖动或chunk解析失败用try解析每个chunk解码时使用stream: true参数避免多字节字符被截断微调loss不降数据格式错误/学习率过大检查数据中instruction和output顺序降低学习率增加warmup训练中显存溢出OOM序列过长激活值爆炸缩短max_seq_len开启gradient checkpointing调小batch size微调后模型变笨数据分布单一过拟合混入通用对话数据减少epoch数保留并对比最佳checkpointvLLM偶发OOMKV Cache占用显存过高调低gpu-memory-utilization开启KV Cache量化限制最大并发前端停止生成但后端还在算未检测连接断开使用request.is_disconnected()在生成循环里检查断开立即终止长文档问答效果差上下文塞太满/检索不准先做分块和相关性筛选再压缩或摘要不要全量塞入除了表格里的问题还有几条容易被忽略的“软经验”想分享。第一数据质量永远大于模型选择微调和训练都是这个道理先把数据做干净比换更大的模型更有效。第二保存每一个实验记录我习惯用一个简单的表格记录“模型数据集训练参数效果”虽然很土但在调参和复盘时救过我好几次命。第三不要追新很多项目失败不是因为模型不够强而是工程细节和稳定性没做好。模型可以换但你的部署、评测、监控体系是可以复用的。8. 写在后面系统学习大模型的心法最后说点掏心窝的话。我见过太多人收藏一堆教程、买一堆课最后仍然没有真正入门。原因只有一个看得多做得少。大模型这个方向信息密度极高但它是工程属性非常强的东西很多细节不亲手跑一遍根本记不住。我的体会是系统学习大模型最稳的闭环是“部署一个最小模型→用它做一个真实小任务→记录问题→微调/优化→再部署”这个循环你完整走两遍就已经超过绝大多数停留在收藏夹阶段的人。遇到未知概念不要怕先用你已经懂的话去解释它再动手验证解释不清楚说明还有盲区这正是下一步学习方向。最后再分享一个小习惯从第一天开始就为自己的每个模型、每份数据集、每次微调写一份简单的变更记录。这个习惯起初微不足道但当你手上的模型超过三个、数据超过十份之后它会成为你最可靠的技术资产。资料永远看不完但沉淀下来的实验记录才是真正属于你自己的系统性知识库。