1. 入门之前先想清楚你要走哪条路1.1 大模型不是一门课而是一张网先说个现象这两年我见过太多人硬盘里囤了十几个T的“大模型学习资料”收藏了50篇《30天精通大模型》的文章最后连一个本地模型都没跑起来。为什么因为大模型学习根本不是一条直线它是一张网——理论、工程、应用三者交织在一起。你只啃Transformer论文不会写代码你只会调API不懂模型原理你只会部署不懂微调都走不远。所以这篇内容不是给你一份“从入门到放弃”的书单而是一条我实际走通的路。我前后折腾过QA、多轮对话、Agent、本地部署、微调各种方向踩过不少坑。现在回头看入门大模型最忌讳的事情就是“贪多嚼不烂”——什么都想学结果什么都没学透。你需要的不是把所有模型跑一遍而是先把一条路走通再横向扩展。1.2 三条主流路径怎么选我习惯把入坑大模型的朋友分成三类你可以对号入座第一类是应用开发者。你本来就会写代码想做基于大模型的智能应用比如客服机器人、文档问答、AI写作工具。这类人的重点是API调用、提示词工程、上下文工程、Agent开发、流式输出不太需要深挖模型内部的数学原理但必须懂“模型能做什么、不能做什么”。第二类是算法工程师或者想转算法的人。你需要深入理解Transformer架构、训练目标、微调原理、数据构建至少要知道Loss是怎么算的LoRA为什么能用少量参数微调。这类人动手走一遍微调流程是必须的。第三类是本地部署玩家。你对隐私敏感或者想免费白嫖算力想在自己的电脑上跑一个私有模型。这类人的重点是量化、推理框架、显存管理、硬件选型。说实话这条路门槛最低也最容易获得成就感。我不建议你一上来就订“我要当大模型工程师”这种目标而是用一个月跑通一个小项目比看一百篇理论文章都有用。下面我按“理论 → 部署 → 微调 → 应用 → 资料”的顺序讲你可以根据自己的路径跳过某些段落但建议至少把理论和部署看完因为这是公共底座。2. 基础理论先把关键概念讲透再谈跑模型2.1 大模型到底在做什么事很多人以为大模型“什么都知道”其实说破天大模型的本质就是一个超大规模的“猜词游戏”。你给它一段文字它预测下一个词是什么预测完了把这个词接上去再预测下一个词循环往复。这就是所谓“自回归生成”。你看到的一大段回答其实是模型一个字一个字“挤”出来的。这个“猜”的能力来自两个阶段预训练和微调对齐。预训练就是喂给模型海量文本让它学会语言的统计规律相当于“读万卷书”对齐就是进一步让模型学会“好好说话”比如理解指令、拒绝有害内容这一步对你日常使用大模型体感影响最大因为预训练出来的模型根本不会聊天只会续写。这个概念你必须刻在脑子里因为后面所有内容都围绕它展开提示词工程是在“引导模型往你希望的方向猜”上下文工程是把更多背景信息塞给它微调是在特定领域增强它的“猜测能力”Agent是让模型先猜“我该调哪个工具”再猜“这个结果是啥”。2.2 Token、上下文窗口与注意力机制接下来三个词是面试必问、也是你们实际调优必碰的Token是模型处理文本的最小单位不是一个字也不是一个词而是一种“按频率切分”的单位。比如英文一个单词可能拆成1到3个Token中文一个汉字可能占1到2个Token。你花钱买API是按Token算的比如输入500个Token输出500个Token收费和速度都跟Token挂钩。所以写作时如何减少Token浪费是应用开发的重要话题。上下文窗口就是模型一次性最多能“看到”的Token数量。对用户来说就是“模型能记住多长的对话”。当前主流模型一般是128K到200K Token听起来很长但实际用多了你会发现模型对长上下文的中间部分注意力很容易“衰减”这就是所谓“ Lost in the Middle”问题。所以不是塞得越长越好关键信息最好放开头和结尾。注意力机制是Transformer的核心通俗理解就是模型在生成每一个词的时候会回头“看”一下上下文里哪些词跟当前这个词最相关。比如我说“它咬了我一口”“它”指代什么模型就是靠注意力机制去关联前文的“狗”。你提示词里信息密度越高、指代越清晰模型注意力就越容易聚焦。2.3 参数、量化与“B”到底代表什么你在各种模型下载页面看到的“7B”“72B”“8x7B”B是Billion代表模型参数数量——可以粗浅理解为模型的“神经元权重”总量。参数越多模型越聪明、知识越广但推理需要的显存/内存也越多。7B模型一般需要约14GB的FP16精度权重而72B模型动辄需要140GB以上。这就是为什么普通人跑不动大模型的直接原因。为了解决这个问题业内搞出了量化把权重从16位浮点压成8位整数甚至4位整数牺牲一丢丢精度换来大幅缩小体积。你经常看到的Q4_K_M、Q5_K_M、Q8_0这些名字就是量化等级。实测下来4bit量化模型在普通聊天场景下与16bit几乎无感知差异但体积只有原来的四分之一到五分之一。用一台16GB内存的MacBook或主流PC跑7B或13B的4bit模型完全没问题。2.4 提示词工程与上下文工程的区别其实很多人搞混这两个概念。我的理解很简单提示词工程管“怎么说”上下文工程管“给什么”。提示词工程的核心是给模型明确角色、任务、约束、输出格式。比如你写“你是一个资深律师”这不是玄学而是让模型把参数分布调整到法律领域的“状态”。但更实用的技巧是明确步骤告诉模型“第一步做什么第二步做什么”给定示例Few-shot比你说一百句“请专业一些”都管用约束格式要求输出JSON、Markdown表格比放手让它自由发挥稳定得多让模型“一步步思考”对推理类任务是有效果的因为它给模型更多“内部计算”的Token空间上下文工程则是你主动构造塞进对话里的“材料”。比如你做文档问答就要把用户检索到的资料片段拼到请求里再让模型基于这些资料回答做Agent的时候要把工具清单、当前时间、用户历史偏好都拼进去。上下文工程的实际工作量远大于提示词工程。3. 本地部署让大模型跑在你自己的电脑上3.1 为什么非要在本地跑我始终觉得本地部署是初学者建立信心最快的路径。原因是它看得见、摸得着而且以后你会频繁用到公司不允许把业务数据传到外部API你开发阶段反复测试API调用来调用去烧的是钱你想离线用、断网也能聊天你想微调一个专属模型总得有推理环境验证效果。我见过很多教程上来就让你装CUDA、装Python环境、克隆一堆代码库结果把新手直接劝退。其实现在本地部署的工具链已经非常成熟了根本不需要你手动编译推理引擎。我最推荐的路线是先用Ollama把流程跑通等有进一步需求再换更底层的东西。3.2 主流工具怎么选Ollama、llama.cpp、vLLM我做一个直观的对比表看完你就知道选什么了工具最适合的场景上手难度资源占用特点Ollama个人PC/Mac快速部署实验极低低一句话下载模型、自动管理模型、自带兼容OpenAI的APIllama.cpp低配置机器CPU推理中极低纯C/C实现对CPU/Apple Silicon优化极好vLLM生产环境高并发推理服务高高吞吐量可达普通方案数十倍但需要足够显存我的建议是个人电脑一律先上Ollama。它把下载模型、量化转换、加载推理、提供API全包了一行命令就能跑起来。vLLM适合你有多张卡、想对外提供稳定推理服务的场景后面等你玩深了再学不迟。3.3 一步一步在Windows/Mac上部署一个本地模型我以Ollama为例手把手跑一个Qwen2.5-7B。这套流程我在Windows和Mac上都验证过差别不大。第一步去Ollama官网下载对应系统的安装包安装完成后打开终端Windows用PowerShellMac用Terminal输入ollama --version能看到版本号说明安装成功。第二步拉取模型。Qwen2.5-7B-Instruct的4bit量化版本有一条非常稳的命令ollama run qwen2.5:7b第一次运行会自动下载体积大概4.7GB。如果你的电脑内存低于16GB建议换成ollama run qwen2.5:3b或者qwen2.5:1.5b照样能玩。下载完成后它会自动进入交互式聊天界面你直接打字就能对话。第三步了解模型的存储位置。Ollama下载的模型默认放在用户目录下的.ollama/models里Q4_K_M是默认量化格式。如果你想去ModelScope或Hugging Face手动下载GGUF格式的模型文件可以放到指定目录通过ollama create导入。3.4 显存/内存不够怎么办本地部署最先卡脖子的是显存。我给出一个我的经验公式7B模型FP16大概需要14GB显存/内存7B模型4bit量化大约需要4~5GB13B模型4bit量化大约需要8~9GB33B模型4bit量化大约需要18~20GB所以一台16GB统一内存的MacBook Air跑7B完美流畅32GB内存的Windows本无独显也可以靠CPU慢慢跑小尺寸模型但如果你敢用16GB内存机器跑70B模型系统会直接卡死甚至自动杀进程。还有一个隐藏经验用Ollama跑模型时模型是常驻内存的。你跑完一个大模型要释放内存需要运行ollama stop qwen2.5:7b或者简单粗暴重启Ollama服务。很多人电脑卡死不是跑的问题是连着跑了三四个模型没释放。3.5 本地模型联网搜索从朴素方案到函数调用很多人问“本地模型没有实时知识怎么联网搜索”。这本质上是给模型接上搜索工具。我做过最简单版本前端把用户问题发给模型同时调用一个免费搜索API拉取结果然后拼到提示词里让模型总结。这个思路叫“先检索再回答”最直白。更高级的做法是让模型自己决定要不要搜索定义好一个search_web函数把参数和说明传给模型模型在回答之前判断“这个问题超出我知识范围需要搜索”然后返回一个函数调用请求你的程序再真正执行搜索把结果回传给模型生成最终回答。这个模式就是函数调用Function Calling也是后续Agent开发的核心本地模型可以配合搜索API实现。但要注意本地小模型的工具调用能力不如商业大模型7B模型经常会把参数格式搞错你需要设计好容错逻辑。4. 模型微调从通用模型变成你的行业模型4.1 微调到底解决了什么问题先说结论微调不是让你模型“变聪明”而是让模型“更懂你的领域和你的脾气”。预训练模型已经具备通用能力但它在具体任务上表现一般它不熟悉你的行业术语输出格式不符合你的要求不会按照你公司的规范回复。举个例子我给人做过一个法律咨询项目单纯靠提示词告诉模型“你是专业律师”效果是有但偶尔还是会一本正经胡说八道。我用了一批真实的问答对做了微调之后输出的严谨度和用词风格立刻变了这个变化是提示词工程难以达到的。不过在微调之前先问自己三个问题提示词是不是已经榨干了检索增强RAG是不是更便宜、更合适你手头有没有足够的优质数据微调不是万能的它是一个成本相对较高的手段。如果只是想让模型回答几个固定知识点那RAG明显更适合——改数据不用重新训练模型成本低得多。我用一个表总结方案优点缺点适用场景提示词工程零成本、见效快能力上限有限通用任务、临时任务RAG检索增强知识可更新、可追溯依赖检索质量知识库问答、实时信息监督微调真正改变模型行为数据贵、需要算力领域风格、输出格式、专业能力强化学习对齐人类偏好工程复杂、不稳定对话质量、价值观对齐4.2 LoRA微调原理为什么微调7B不需要“亿级显存”如果你看过别人的微调教程应该听说过Lora这个名词。全量微调需要把整个模型的权重都更新7B模型在FP16精度下光优化器状态就要占用几十GB显存普通显卡根本玩不动。LoRA的核心思路是冻结原有模型权重不更新只在模型旁边额外加一组小型的低秩矩阵来“记录”微调过程中学到的变化。打个比方原来的模型是一本字典你很满意它的 99% 内容只想在“法律表达”这一页上做点批注。LoRA不重新印整本书只插入若干便利贴。这些便利贴占用的参数量大约只有原模型的0.1%~1%所以显存需求骤降一张消费级显卡就能微调7B模型。实际训练时的显存大概规律是24GB显存可以微调7B模型16GB显存比较勉强但也能用LoRA跑需要配合梯度累积和混合精度12GB基本放弃7B建议用1.5B或3B模型。4.3 微调一个行业模型的完整流程我以常用的LLaMA-Factory为例这是目前最省心的微调工具免去了写训练脚本的麻烦。第一步准备Python环境并安装git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .[torch,bitsandbytes]*如果你只有国内网络环境建议把HuggingFace下载改为ModelScope的镜像下载速度会快很多。第二步准备数据。数据格式是JSON数组每个元素包含“指令、输入、输出”三段有自己的前缀。举个例子[ { instruction: 你是资深保险理赔审核员请判断以下案例是否属于理赔范围。, input: 用户投保意外险在游泳馆游泳时抽筋溺水身亡。, output: 属于意外险理赔范围。根据条款抽筋导致的溺水属于意外伤害且非疾病原因。 } ]数据量建议至少1000条高质量样本少于100条微调效果非常不稳定。宁要500条高质量、标注规范的数据也不要5000条网上乱爬的垃圾数据——这一步直接决定微调效果。第三步启动微调。使用LLaMA-Factory的WebUI或者命令行llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset your_dataset.json \ --finetuning_type lora \ --output_dir output_qwen_insurance \ --num_train_epochs 3 \ --learning_rate 2e-4 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --lora_rank 64这些参数里lora_rank越大微调表达能力越强但过大会导致过拟合。learning_rate在LoRA中一般用2e-4左右比全量微调高很多。gradient_accumulation_steps 8是模拟更大的batch size显存不够时这样凑。第四步微调完成后用WebUI或命令行合并模型导出成完整的模型文件。然后重复第3章的部署方法把微调后的模型加载起来做推理测试。4.4 微调过程中最容易翻车的三个点第一是数据格式不一致。模型训练时的输入格式和推理时不一样但很多人的测试代码没改问题格式导致效果看起来很烂其实是格式问题。第二是过拟合。训练loss降到0.1以下但测试集上回答开始重复这就是过拟合了。可以减少训练轮数或者增大LoRA rank并加大dropout。当前主流微调1~3轮即可轮数多不代表效果好。第三是灾难性遗忘。模型微调后连“11等于几”都不会了说明只关注目标数据而丢了通用能力。解决方案是微调数据里混入10%~20%的通用数据或者用小学习率。5. 应用开发从模型能力到稳定的产品5.1 免费API和本地API从哪里来做应用开发时你可以使用各厂提供的API也有一些完全免费的API但稳定性和速率限制要自己摸清。我通常的搭配是开发调试用本地APIOllama生产环境换商业API。Ollama自带一个兼容OpenAI格式的接口零配置启动ollama serve然后你的程序就可以用原生OpenAI SDK来调用本地模型了。这一点非常实在因为它意味着你写的代码不用更换SDK只需要换一下base_urlJavaScript调用示例import OpenAI from openai; const client new OpenAI({ baseURL: http://localhost:11434/v1, apiKey: ollama // 本地服务不需要真实密钥占位就行 }); const completion await client.chat.completions.create({ model: qwen2.5:7b, messages: [ { role: system, content: 你是一个严谨的技术文档工程师。 }, { role: user, content: 请把下面这段代码的报错原因总结一下。 } ] }); console.log(completion.choices[0].message.content);要是想用免费云端API搜索“免费大模型API”能找到国内外的供应商但注意免费的东西一般在速率上有限制比如每分钟只能请求5次不适合做高并发产品。我的建议是不要在产品环境依赖免费API它今天能用明天可能就停了。5.2 SSE流式输出把“打字机效果”做出来你有没有好奇过ChatGPT界面的文字是一个字一个字蹦出来的那就是流式输出。它的底层原理是SSEServer-Sent Events服务器单向推送事件。大模型生成一段话可能耗时十几秒。如果你让用户傻等全部生成完才显示体验极其糟糕。流式输出的思路是模型每生成一个Token就立刻推送给前端前端一边等一边渲染用户体感就是秒回。后端用FastAPI示例from fastapi import FastAPI from fastapi.responses import StreamingResponse import asyncio def generate(): for token in [你好, , 今天, 天气, 真, 不错]: yield fdata: {token}\n\n asyncio.sleep(0.1) app FastAPI() app.get(/chat) async def chat(): return StreamingResponse(generate(), media_typetext/event-stream)前端用JavaScript接收const response await fetch(/chat); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const text decoder.decode(value, { stream: true }); console.log(text); // 把 text 追加到界面上 }这里还有个隐藏细节用户点击“停止生成”怎么办前端必须用一个AbortController来取消请求const controller new AbortController(); fetch(/chat, { signal: controller.signal }); // 用户点击停止时 controller.abort();如果你不做这个处理用户按了停止按钮模型还会在后台继续生成浪费电也浪费Token。5.3 Agent到底是在做什么说到“大模型智能体”“Agent框架”很多人觉得玄乎。其实Agent的核心思想非常朴素让大模型自己决定要调用什么工具然后根据工具返回结果再决定下一步动作。传统的人机交互是人找功能Agent是功能找人。你告诉它“帮我规划一个去云南的旅行”它自己判断要不要查天气API、订酒店API、查航班API然后规划行程。现在主流的Agent框架我按风格列一下方便你挑LangChain/LangGraph最老牌、生态最丰富组件化设计。缺点是抽象层级太多初学者容易不知道它在干嘛。Dify/RagFlow偏低代码平台可视化编排工作流适合快速搭一个Demo。MetaGPT把Agent当成不同的“角色”比如产品经理Agent、程序员Agent、测试Agent模拟软件开发小组适合体验多Agent协作。AutoGen微软出品主打多Agent对话。多个Agent之间可以互相“开会讨论”比如一个Agent负责写代码一个Agent负责执行一个Agent负责审查。如果你刚开始学我的建议是不要先啃框架源码而是先用LangChain或Dify搭一个“工具调用”的Demo给模型一个“计算器工具”和一个“搜索工具”然后让模型自己根据问题选工具。这个过程跑通之后Agent的神秘感就消失了。5.4 RAG让模型学会“查资料”RAG全称检索增强生成是我在所有落地项目里用最多的技术。核心思路就三步先把文档切碎、嵌入成向量存进向量数据库用户提问时把问题也转成向量检索最相似的片段把这些片段拼进提示词让模型基于片段回答。为什么这个模式好用因为大模型的知识有截止时间而企业内部知识库是实时更新的。RAG可以做到“答案来自当前数据库内容”所以更可信、可溯源。本地部署RAG的话我推荐两条路线简单路线用LlamaIndex或LangChain自带的向量库生产级路线用Milvus或Qdrant。嵌入模型建议用BGE系列中文嵌入模型在中文检索上的效果比OpenAI的Embedding在成本上划算不少。别忘记一个关键点RAG的效果上限取决于“检索到的内容准不准”。切分策略很讲究按固定长度切分经常把语义断开按段落切分虽然语义完整但容易超长。实践中最稳的是“按Markdown标题层级切分段落合并”让每个片段在300~500字之间兼顾语义完整性和检索精度。6. 学习资料与练手项目的参考清单6.1 模型和平台去哪儿找这里整理一下给想动手的朋友指个路Hugging Face全球最大的模型社区。找模型、看论文复现、下数据集都在这。国内访问可能慢可以配合镜像站。ModelScope魔搭社区阿里出品国内访问速度快中文模型资源非常丰富Qwen系列模型的官方权重基本都会同步发布在这里。Ollama库个人电脑部署首选内置了大量量化好的模型直接ollama run就能用。Ollama官网可查看所有支持的模型列表和大小、参数要求。找模型的时候有个技巧不要盲目下载最大的模型。先确定你的显存预算再看模型的量化格式标注最后看模型的许可证商用场景下务必确认授权范围。6.2 值得看的资料网上资料多如牛毛但真正值得花时间研究的不多。我推荐以下几类第一类原版论文Transformer原始论文《Attention Is All You Need》是必读的虽然数学部分难啃但概念框架值得花一周时间去磨。大模型发展后续的GPT系列论文、DeepSeek的技术报告观点具有很强参考价值。第二类在线课程实战与其看纯理论的视频课不如找一个“从零搭建一个问答机器人”的实操教程边做边学。我见过有人刷了一百小时网课最后还是不会自己写一个调用API的程序。动手才是王道。第三类社区博客很多人低估了博客的价值。Hugging Face官方博客、各个模型的发布公告都是紧跟技术前沿的一手资料。6.3 练手项目由易到难我建议按这个顺序练每个项目指向一个核心能力项目一做一个本地聊天机器人。用Ollama跑一个模型然后用Python写一个像样的命令行对话程序。练的是API调用和基础交互。项目二给文档做问答。找一份公司产品手册切分成向量库做一个“文档问答助手”。练的是RAG全套流程。项目三做一个带联网搜索的小助手。让模型自己判断什么时候调用搜索API再总结搜索结果。项目四微调一个能识别你朋友圈风格的文案机器人。收集你自己的写作风格数据用LoRA微调一个小模型。项目五做一个多Agent小组。模拟“产品经理程序员测试”三个Agent协同工作完成一个小需求。6.4 到底要不要追“大模型最新版”每次有个新模型发布总有人急得不行“是不是我学的东西又过时了”说句实话模型的更新换代确实快但大模型的核心技术栈已经趋于稳定Transformer在短时间内依然是底座LoRA微调的方法论没有变RAG的架构范式变动也不大。新模型只是更强、更大、更便宜但底层逻辑还是那些。真正值得追随的是“推理范式”级别的变化比如思维链、多模态融合、端侧推理这些方向。所以基础知识学扎实了新模型出了只是换一个模型名字而已。7. 附我的避坑清单帮你省掉三个月的弯路7.1 环境与工具相关我踩过的最痛一个坑装依赖把所有包都装上结果版本冲突TensorFlow、PyTorch、CUDA互相打架最后只能重装系统。现在我的原则是用conda或venv创建干净的虚拟环境每套项目独立环境绝不共用。Python版本上很多框架还没适配最新的版本。偶像级稳妥组合是Python 3.10或3.11PyTorch装官网对应的CUDA版本。你要是装好驱动之后仍然报“CUDA not available”大概率是PyTorch的CUDA版本和显卡驱动不匹配也可能是没装CUDA ToolKit反正先查驱动再查Torch版本最后查环境变量。Windows用户搞开发时我建议直接用Windows Terminal把PowerShell或WSL配置好别在CMD里折腾。WSL跑模型的时候GPU直通配置稍微繁琐但一旦成功体验会比原生Windows好很多。7.2 模型选择相关个人电脑先尝试小模型不要上来就追求70B。很多人一上来就下一个200GB的大模型结果发现推理速度慢如蜗牛然后就放弃了。我建议能跑得动、跑得快比跑得大重要得多。还有同一个模型存在多个版本Base版本是预训练底座它只会续写不是聊天不能直接拿来对话Instruct或Chat版本才是调教好的对话模型。下载时注意别拿错了。7.3 数据与评估相关做微调和RAG前先建一个固定的评测集——收集20~50个你关心的真实问题每次跑完一个版本的模型都用这一组问题测一遍记下好坏的对比。否则你会陷入“一直在调模型但不知道有没有变好”的泥潭。单独说一句评估大模型不能只看几个“感觉还行”的样例。我倾向于人工评分多个维度相关性、准确率、格式规范度的组合。对量化指标比如回答是否包含关键词、长度是否合理可以做规则判断但整体质量还是得靠人肉看。建立一个稳定评测集是让你不至于原地打转的最有效投资。7.4 我这段时间的体会在最开始的一两个月里我也经常怀疑自己是不是不适合干这行因为每天刷到的内容都是“零基础入门大模型”“三天做出GPT应用”而自己连API都调不明白。后来我慢慢想通了不要跟那些标题党比速度要跟自己的昨天比进步。今天搞懂了一个Token是什么意思明天跑通了一个本地模型后天把流式输出渲染出来了这就已经比90%只收藏不行动的人强了。这套内容里的每一条路我都走过代码也都实际跑过。如果你能照着至少把“本地部署”和“提示词工程”这两块走一遍你对大模型的理解就比大部分只刷文章的人扎实得多。剩下的边做边学比什么都快。