最近后台收到一堆私信很多人看到大模型LLM相关的新闻感觉自己再不学就掉队了但点开教程却发现满屏都是“注意力机制”“Transformer”“微调”“RAG”这些词每个字都认识连起来却不知道在说什么。这篇文章我想用尽量人话把LLM入门需要的基础知识串一遍它到底怎么工作的、常见的术语在说什么、如何从零开始跑一个能玩的Demo。适合完全零基础也适合已经用过ChatGPT但想深入理解的人。我不打算搬教科书也不会一上来就甩一堆数学公式。大模型这东西很多概念用生活经验就能理解真正难的是把“模型”和“场景”对上号。你把这篇文章当一张地图用遇到不懂的词回来查一查至少能知道下一步该往哪走。1. 先搞清楚LLM是什么从猜词游戏到概率模型1.1 LLM的核心机制预测下一个词很多人以为LLM是像搜索引擎一样去“查资料”其实不是。LLM的核心能力用一句话概括就是根据前面的内容预测下一个最有可能出现的词token。我习惯把它类比成手机的输入法。你用“我想吃”三个字开头输入法会推荐“饭”“水果”“火锅”等候选词。它并不真的知道你的真实意图只是根据海量语料算出哪个词跟在后面最自然。LLM的原理类似只不过它预测的不是一个词而是一整段话并且是“预测一个词 - 拼到输入里 - 再预测下一个词 - 再拼接”一句一句循环生成出来的。这里有个关键点LLM本身并没有一个“事实数据库”它没有真的把知识整理成表格放进去。它只是把人类文字里蕴含的模式、逻辑、事实哪怕有错的都压缩到了模型参数里。所以它有时候会“一本正经地胡说八道”这不是偶然而是这种生成机制天然的副作用。明白了这一点你对后面所有概念的理解都会顺畅很多。比如为什么要设计Prompt提示词因为输入决定输出你给的前文越清晰模型预测下一个词的方向就越明确。为什么有上下文窗口限制因为输入长度有上限超过之后模型“看不见”更早的内容。为什么会有幻觉因为模型在“编”下一个词的时候并不区分“事实”和“想象”。1.2 Token模型眼里不是字是碎块你和我看到的是“字”LLM看到的是“Token”。什么是Token就是把文本切成一块一块的小碎片模型拿这些碎片做计算。英文里一个单词通常是一个到几个Token比如“Hello”可能被切成一个Token“ChatGPT”可能被切成三个Token。中文比较吃亏因为很多字词需要拆开有时一个字就是1到2个Token。你随便找一家大模型厂商的Token计算工具测一下会发现同样长度的一段中文Token数量通常是英文的1.5到2倍。为什么搞清楚Token很重要因为它决定了三件事计费绝大多数API按Token收费输入和输出都算。上下文窗口窗口单位是Token不是字数。你感觉没写多少可能已经占了几千Token。性能与成本模型处理速度、显存占用都和Token数量直接相关控制Token数量就是控制成本。所以你在调参数时看到max_tokens这个字段意思就是“最多生成多少个Token”别把它当作“最多生成多少字”。1.3 为什么叫“大”语言模型“大”体现在两个维度。第一是参数规模常见的有7B70亿参数、13B130亿参数、70B700亿参数甚至更大。参数可以粗略理解为模型内部用来调节输入输出关系的“旋钮”旋钮越多它能拟合的复杂模式就越多。第二是训练数据规模。为什么LLM好像什么都知道一点因为它在训练时“读”了互联网级别的文本可能是几十TB甚至上百TB的数据。你可以把训练过程理解成给模型不停地出完形填空每次猜错就微调内部的旋钮反复几万亿次最后它学到了文字的统计规律和一定程度的逻辑知识。小模型比如3B、7B适合本地跑速度快但复杂推理能力弱大模型比如70B以上聪明很多但推理慢、显存要求高。这也引出了“端侧模型”和“云端模型”的选择问题实在没显卡就调API有显卡可以跑本地小模型手机端也有离线AI聊天应用近年有不少Local AI App适合纯离线场景。2. LLM生态全景图模型端、推理端、应用端别傻傻分不清我见过太多新手卡在一个问题上明明在聊LLM聊着聊着突然混了。比如“Qwen ”是模型“vLLM”是推理框架“Dify”是应用平台“LangChain”是开发框架它们不在同一个层级。这里我习惯把整个生态分成三层模型端、推理端、应用端。2.1 模型端基座模型、指令微调、对齐模型端就是“权重”本身也就是模型文件。你可以从Hugging Face、ModelScope等平台下载开源模型。开源模型主要有几类基座模型Base Model只做了“补全”训练你问它“中国的首都是”它会补“北京”但不会像一个助手一样好好聊天。指令微调模型Instruct/Chat在基座模型基础上专门用“指令-回答”数据做微调学会了听话比如“帮我写一份周报”。平时说的Qwen2.5-Instruct、DeepSeek-Chat都属于这类。对齐模型Alignment进一步用人类偏好数据RLHF/DPO优化让回答更有礼貌、更安全。为什么要区分因为很多人第一次下载开源模型下了个Base版本发消息却得不到正常回复还以为模型坏了。实际上你日常想玩对话认准名字里带Instruct、Chat、Assistant后缀的版本就行。2.2 推理端怎么把模型跑起来模型下载下来之后你需要一个“推理引擎”来运行它。推理端解决的问题是怎么让模型高效地根据输入生成输出。常见的推理工具有Ollama、llama.cpp、vLLM、LM Studio等。它们各有侧重Ollama适合新手一条命令就能把模型拉下来并启动API服务跨平台默认做了量化显存要求低。llama.cpp纯CPU/GPU混合推理对老显卡友好很多人用来在MacBook上跑模型。vLLM适合高并发、生产环境吞吐量大但配置门槛稍高。LM Studio图形界面适合完全不懂命令行的用户。推理端还有一个重要概念叫量化。简单说就是用更少的位数来表示模型的权重比如从16位压缩到8位、4位。代价是精度轻微下降但显存占用大幅降低速度也可能更快。本地跑大模型量化几乎是必选项。2.3 应用端Agent、RAG、Workflow模型和推理搞定了才轮到“应用”。应用端要解决的是怎么让模型完成实际任务。这里有几个高频词你一定会遇到RAG检索增强生成在让模型回答前先从你自己的知识库里检索相关内容把检索结果拼到Prompt里再让模型回答。这是目前解决“模型不知道你的私有资料”最主流的手段。Agent智能体让模型不仅仅聊天而是能调用工具、执行动作。比如你让它查天气它会先调用天气API再把结果整理给你。核心是“模型做决策工具做执行”。Workflow工作流把复杂任务拆成多个步骤比如先意图识别再调用业务API最后让模型生成总结。Dify、Coze这类平台就是让非程序员也能拖拽搭建这种流程。你还会看到LangChain这个框架它是用来写LLM应用的工具箱封装了Prompt管理、记忆、工具调用、向量数据库对接等能力。但说实话新手不建议一上来就啃LangChain先用原生API或低代码平台跑通一个Demo再回头看框架会轻松很多。下面这张表可以帮你快速定位层级常见代表解决什么模型端Qwen、DeepSeek、Llama、GLM提供语言能力推理端Ollama、llama.cpp、vLLM把模型跑起来应用端Dify、LangChain、Coze对接业务、做产品3. 入门必会的五个基础概念上下文、温度、采样、Prompt、幻觉3.1 Context Window上下文窗口上下文窗口决定模型一次能“看到”多少Token。好比人类做阅读理解时文章太长会忘记开头LLM也有这个限制。以常见的模型为例有的支持8K有的支持128K甚至更长。窗口越大越好吗不一定。第一窗口越大计算量和显存消耗越高第二位置太远的内容模型其实不一定“注意”得到。所以实践中不是无脑把整本手册都丢进去而是只塞最相关的片段。当你调用API时通常有一个“max_tokens”输出上限和“context_window”总体上下文。如果超出窗口上限不同模型处理方式不同有的直接报错有的自动截断有的会遗忘中间部分。最简单的应对方法是只保留关键信息或者用压缩/摘要工具。3.2 Temperature与Top-p控制随机性这两个参数决定模型回答的“胆量”。Temperature温度数值通常0到2之间。越低越保守、固定适合写代码、做计算越高越随机、有创意适合头脑风暴、写文案。Top-p核采样控制候选词的概率累计阈值。比如p0.9表示从概率累计到90%的那批词里随机选剩下低概率词被排除。Top-p和Temperature可以同时调但一般建议先固定一个主要调另一个。我自己的经验代码和API参数场景设temperature0.2左右日常闲聊设0.7左右创意写作再往上调但太高会跑题甚至胡言乱语。这两个参数是整个LLM调试里最常碰的旋钮值得花时间试一遍。3.3 Prompt提问本身就是技术Prompt乍一看就是输入给模型的话但同样的模型用不同Prompt效果天差地别。官方文档里通常把一段对话切分成system、user、assistant三部分system设定角色和全局规则比如“你是一个严谨的代码审查助手回答必须简洁”。user是用户输入。assistant是模型之前的回复多轮对话时会把历史记录也传进去。写Prompt有很多套路核心是“给角色、给任务、给约束、给示例”。比如你让它润色直接说“润色这段话”效果一般改成你是一名资深编辑请把下面这段文字改成更口语化的表达风格像朋友聊天不要使用被动语态 原文...效果会明显好很多。别嫌麻烦Prompt至少占LLM应用效果的50%。甚至有人总结了一套“Prompt Engineer”方法论虽然这个职位有争议但“会提问”本身确实越来越值钱。3.4 幻觉Hallucination幻觉是指模型生成看似合理但实际错误或虚构的内容。为什么会有幻觉因为LLM本质是在做“文字接龙”它并不真正理解对错只是它在拟合训练数据时见过太多说法。当训练数据不足、用户问题超出知识范围又或者模型为了“组织一个像样的回答”而强行生成时幻觉就会产生。缓解幻觉的办法用RAG把可验证的参考资料塞进上下文让模型“有据可依”。要求模型给出依据比如在Prompt里写明“如果信息不在上下文中请直接回答不知道”。降低Temperature减少随机性。事后校验对关键事实做规则校验或二次查询。你要明白幻觉不可能完全消除只能尽量降低。任何用LLM做决策、做医疗或法律建议的场景都必须带人工审核环节。3.5 Embedding与相似度让模型“记住”知识的基础前面提到RAGRAG离不开一个技术Embedding嵌入。Embedding可以理解成把一段文字转成一串数字向量这串数字能表示文字的“语义方向”。比如“苹果”和“香蕉”向量距离近“苹果”和“汽车”距离远。有了向量就可以做语义相似度搜索你把用户的问题也转成向量再去知识库里找最相近的片段。主流Embedding模型有OpenAI的text-embedding-3-small、BGE-M3、智源的bge系列等。本地跑RAG时Embedding模型一般很小几百MB甚至更小CPU也能跑不用特别担心算力。在实操中Embedding有两个坑第一不同Embedding模型的向量维度不同900多到2000多都有用哪款模型就统一用哪款别混用第二Embedding模型也需要分词器中文场景建议选专门优化过中文的模型否则检索效果差得明显。4. 从0到1动手实验本地搭建一个LLM聊天环境说了这么多不动手等于白看。下面我带大家从零搭一个本地LLM聊天环境不训练模型只做推理和API调用30分钟内能跑通。4.1 环境准备不需要自己训练先跑推理要跑LLM你需要一个能运行推理的环境。最简单的是用Ollama它支持Windows、macOS和Linux。硬件方面如果你只是实验CPU也可以跑只是速度慢如果追求流畅建议有8GB以上显存的NVIDIA显卡或一台内存16GB以上的Apple Silicon Mac。我推荐先选一个小模型开始比如Qwen2.5-3B或Llama 3.2-3B。为什么不是7B因为小模型下载快2GB左右显存占用低反馈速度块让你先建立起“能跑通”的成就感。等你调整好Prompt、跑通API后再换更大的模型。注意第一次拉取模型前确认磁盘空间至少5GB。Ollama默认会把模型放在用户目录下占空间较大建议提前清理。4.2 安装与运行安装Ollama很简单到官网下载对应安装包装好后打开终端ollama pull qwen2.5:3b ollama run qwen2.5:3b第一条命令是下载模型第二条命令是进入交互式聊天界面。你可以在终端直接提问比如“用一句话解释什么是微调”。如果一切正常你应该能收到流式输出。在交互界面里有几个常用命令/bye退出/clear清空上下文/?查看帮助。你还可以在启动时指定参数比如ollama run qwen2.5:3b --num-ctx 8192 --temperature 0.3--num-ctx是上下文长度--temperature就是上面讲的随机性参数。放在启动命令里能让你快速对比效果。4.3 通过OpenAI兼容API接入本地模型跑通终端还不够我们还要把它变成可调用的API这样才能接入到Dify、LangChain等应用框架中。Ollama本身支持OpenAI兼容接口。启动服务ollama serve默认监听http://localhost:11434。你可以用curl测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:3b, messages: [ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 你好} ], stream: false }如果返回一段JSON里面包含choices.message.content说明API已经通了。注意这里用的是/v1/chat/completions和OpenAI一样所以很多现成的OpenAI SDK可以直接改base_url接入本地模型。我用过Dify接Ollama操作很直观在“设置-模型供应商”里选Ollama填上模型名和API地址即可不用改代码。这种方式特别适合产品原型验证。4.4 第一个RAG Demo把文档变成问答知识库RAG是LLM落地最火的场景下面给一个最小可跑通的思路。要做RAG你有三条路线零代码使用Dify或Coze上传文档自动做分段和向量化创建一个聊天应用。半代码用LangChain或LlamaIndex写几十行Python调用Ollama和Embedding服务。纯手工自己调Embedding API、自己管理向量库比如Chroma。如果你是第一次做我建议走路线1因为Dify已经把“文档导入 - 分段 - Embedding - 检索 - 对话”串好了你只需要传文档、建应用。简单描述一下背后的流程把文档切成固定大小的块chunk比如每块300-500字块与块之间重叠50字。对每一块调用Embedding模型生成向量存入向量数据库。用户提问时把问题转成向量用余弦相似度/内积检索最相关的k个块。把这些块和用户问题一起塞进Prompt让模型基于资料回答。我在实践中最常踩的坑是分段大小。分段太小语义容易断裂太大检索噪声多且浪费上下文空间。具体切多大要看你的文档类型。如果是一问一答格式可以按条目切如果是长文建议600-800字符一档重叠100-150再根据效果调整。用LangChain做也很简单核心逻辑示意如下需要先安装langchain-community、chromadbfrom langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 使用Ollama中的embeddings模型生成向量 embeddings OllamaEmbeddings(modelbge-m3) # 加载文档并切分text_splitter 可以选 RecursiveCharacterTextSplitter from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import TextLoader loader TextLoader(knowledge.txt) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, separators[\n\n, \n, 。, , , , ] ) docs text_splitter.split_documents(documents) # 存入向量库 vectorstore Chroma.from_documents(docs, embeddings) # 创建检索问答链 llm Ollama(modelqwen2.5:3b) qa RetrievalQA.from_chain_type(llm, retrievervectorstore.as_retriever(search_kwargs{k: 3})) print(qa.run(这份资料里提到了哪些关键技术))这段代码只是为了展示全链路并不复杂生产环境还要考虑增量更新、检索重排、多路召回等但入门阶段跑通它就是胜利。5. 常见问题与排查技巧5.1 显存不够怎么办本地跑模型最常见的痛点是显存。以7B模型为例FP16精度大概需要14GB显存4bit量化后大概4GB。所以你至少准备模型规模4bit量化后显存需求约3B2GB7B4-5GB14B8-9GB70B35GB如果还是不够有三个办法换更小的模型、进一步调低量化位数、干脆用云端API。不要有“非得在自己电脑上跑大模型”的执念很多场景API更适合成本和速度都更优。5.2 模型回答不听话或一直不结束有时模型会无视System指令或者回答停不下来。排查顺序是看是否设了temperature过高随机性太强时更容易偏。看上下文有没有被冗长示例污染把无关历史清掉。检查是否设置了stop参数。比如希望回答到“结束”就停可以加上stop: [\n\n]。如果是API调用确认max_tokens没有设太小否则回答会被截断看起来像没说完。还有一个很多人忽略的点System提示词要用正面语言不要写“不要说废话”而应该写“直接给出结论”。模型对“不要”的遵循一般不如对“要”的遵循。5.3 RAG检索不到答案RAG最常见的失败原因是“没检索到”而不是“模型不会回答”。判断方法很简单把你Prompt里拼进去的资料单独拿给人看人能不能从里面找到答案如果找不到说明检索环节出问题。可能的原因和改进方向问题原因解决检索结果全跑偏分段粒度不对调整chunk_size / chunk_overlap问题抽象检索不到关键词/语义不匹配换更强的Embedding模型结果太乱覆盖不全面top_k太小或检索策略单一调大k加多路召回资料里根本没有答案知识库不完整先补齐资料另外不要忘了给RAG加“查不到就承认不知道”的Prompt策略否则模型还是有可能用幻觉硬编一个答案。5.4 整体速度太慢速度慢通常体现在Token产出速率低。可以先看你的硬件利用率GPU是否跑满还是带不动CPU推理是否内存带宽不足。如果是API调用可能是限制了并发或网络问题。本地推理调优经验用Ollama/vLLM之类的专用推理框架而不是直接用原始Transformers Pipeline后者效率差不少。考虑量化4bit量化后速度常常提升30%-50%。如果显卡支持Flash Attention在vLLM或者其他支持它的框架里显式开启。检索、Embedding这些步骤如果频繁调用可以提前缓存别每次现算。对于生产环境建议并发请求使用vLLM它支持Continuous Batching能显著提升吞吐。本地单用户场景Ollama已经很够用。最后几个实在的建议入门LLM最重要的不是立刻记住所有算法名词而是动手把一个最小的闭环跑通先装Ollama跑一个对话模型再用Dify接上知识库做一个RAG问答应用。这个过程中你对模型、Token、Prompt、上下文、RAG这些词的理解会远超读十篇教程。我个人的习惯是把学习过程记录下来尤其是遇到的问题和参数调优心得。你可以用Obsidian这类笔记工具维护自己的“LLM知识库”把官方文档、API参数、踩坑记录都存进去。很多社区里流传的“LLM wiki”就是这么沉淀出来的边学边记过几个月回头看你会发现自己已经比绝大多数人走得远了。最后再分享一个小技巧遇到问题先读官方文档再看开源项目源码实在不行再问社区。大模型的迭代太快任何二手教程都可能过时只有第一手资料和持续动手才是你最可靠的老师。