我经常在社区里看到一种现象很多人一上来就问我“LLM怎么部署”“微调用什么框架”但聊了五分钟就发现他连 token 是什么、上下文窗口为什么有长度限制、temperature 参数调了到底影响什么其实都没搞明白。这就像一个还没学会踩离合的人上来就问怎么跑赛道能跑起来才怪。所以我决定写一个“LLM 0”系列专门给真正零基础、但是想系统地用懂大模型的人补上那层最要紧的地基。本文就是这个系列的第一篇不讲复杂的数学公式不强行搬出 Transformer 架构图只把你在实际使用、部署、调用 LLM 时一定绕不开的那些基础概念一个个掰开揉碎讲清楚。这篇文章适合三类人一是想在企业内部搭一个私有知识库或智能问答系统但之前只停留在“调用 API”层面的开发者二是把大模型产品化、想选型框架但被 RAG、Agent、Workflow 这些名词砸晕的产品经理三是自己折腾过一些开源模型但总觉得推理性能不稳定、输出格式乱七八糟想搞明白“它为什么会这样”的爱好者。1. LLM 到底是什么从“会接话的机器”到“参数洪流”很多教程喜欢直接从 Transformer 架构讲起什么自注意力机制、多头注意力、位置编码……讲得越深初学者跑得越快。我换个方式我们从“它到底在干什么”开始。1.1 把“预测下一个词”当成核心心智模型LLMLarge Language Model大语言模型本质上干的一件事非常朴素给定一段文字预测下一个最可能出现的词是什么。你随便说一句“今天天气真”它内部会计算出一个概率分布下一个词有 80% 的概率是“好”10% 是“不错”5% 是“糟糕”还有一些零零碎碎的低概率词。它选出概率最高的那个词拼到原句后面然后继续预测下一个词。这就是完整生成的底层逻辑。但问题来了如果每次都选概率最高的词模型生成的结果就会非常单调、死板像复读机一样。所以 OpenAI、Anthropic 这些团队在他们的推理服务里加了一个“采样”的步骤不是永远选最大概率的词而是按照概率分布随机抽一个这样生成的内容就会有多样性。这个采样过程的“随机程度”由一个参数控制就是你在各大模型平台接口里几乎都会见到的temperature。temperature 越低模型越倾向选高概率词输出越稳定、越保守temperature 越高输出越跳跃、越有创意但也越容易胡说八道。1.2 模型参数决定“聪明程度”的核心指标我们常听到 7B、13B、70B 这样的说法B 是 Billion十亿的缩写指的是模型的参数数量。你可以把参数理解为“神经元之间的连接权重”模型就是用这些权重来存储它从海量文本中学到的知识和模式。参数越多模型的“内存”越大能记住的关联模式越复杂。所以同样是开源模型70B 的推理能力和知识广度通常明显强于 7B但代价是显存占用更大、推理速度更慢。实际部署时会发现一个很有意思的现象参数的分布并不均匀。模型网络结构里每一层都有注意力权重、前馈网络权重等。推理时所有参数都要参与计算所以参数量直接决定了你需要的显存下限。1.3 预训练、微调、对齐大模型的三个成长阶段一个正式的 LLM 不是拿来就直接能用的它经历了三个典型阶段预训练在海量互联网文本上学习语言规律和世界知识。这一步成本极高需要用几千张 GPU 连续训练几个月。这个阶段完成后模型已经是一个“语言通”但它只会接话不懂问答纪律。微调用高质量的指令-回答对比如“请用一句话解释量子纠缠 → 量子纠缠是……”对模型做二次训练让它学会“别人问什么我就答什么”。这一阶段数据量比预训练小得多成本也更可控也是企业做垂直领域模型时最常用的阶段。对齐RLHF/DPO让模型学会符合人类偏好比如不说脏话、不提供危险建议、承认自己不知道。这个阶段的本质是“塑造性格”。这三个阶段对应不同的技术和成本投入。你在市面上看到的所谓“医疗大模型”“法律大模型”大部分就是基于一个开源底座模型再用大量领域内问答数据做微调得到的。我个人建议刚入门的朋友先不要碰预训练那不是一个团队该干的事但微调、对齐的原理要理解不然连“模型为什么回答风格这么拧巴”都说不清楚。2. Token 与上下文窗口模型“看得见多远的过去”很多用户第一次遇到的问题是为什么我的模型聊着聊着就“失忆”了为什么同一段长文档有时候能总结有时候报错这两个问题的答案都指向同一个概念token。2.1 Token 不是你理解的“字”而是一段文本的碎片Token 是模型处理文本的最小单位它可能是半个词、一个词也可能是一个汉字或几个字符的组合。不同的分词器对同样的文本切出的 token 数量不一样。比如英文里“unbelievable” 可能会被切成 “un”、“believa”、“ble” 三个 token中文里的“生命周期”四个字在很多主流 tokenizer 里就是四个独立的 token。所以中英文的 token 消耗速度差异很大通常同样的语义内容中文需要的 token 数量比英文多不少。这里有个实用技巧当你需要控制长文本成本时可以先对文本做清洗、压缩摘要再扔给模型处理能明显降低 token 消耗。很多刚上手的人直接把几万字的合同全文塞给模型花了几块钱 token 费模型还只能理解一部分——这就是典型的不会算账。2.2 上下文窗口的内容如何影响生成质量上下文窗口Context Window是指模型在一次生成任务中能“看到”的最大 token 数。假如某模型的上下文窗口是 128K token那么你输入的所有内容系统提示词、历史对话、检索到的文档片段加上模型生成的输出加起来不能超过这个数。这里有一个常被忽略的细节上下文窗口里既包含你的输入也包含模型的输出。很多人以为 128K 就是“我能塞 128K 的文档进去”结果生成到一半就报错因为输出的 token 也会占用窗口空间。更微妙的是模型对上下文的利用并不是均匀的。它在生成后文时对前文信息的“注意力”是动态分配的而且普遍存在一个现象位于上下文中间的内容模型关注度相对较低开头和结尾的内容关注度更高。这就是业界常说的“Lost in the Middle”现象。所以当你要给模型提供参考资料时把最重要的话放在开头或结尾比埋在中间要有效得多。2.3 超出上下文窗口怎么办截断、滑动窗口、摘要当你的输入内容超出了上下文窗口实际工程里常用三种处理方案直接截断从中间切掉一部分。实现最简单但会丢失信息适用对完整性要求不高的场景。滑动窗口保留最近的对话丢弃最早的部分。适用于多轮对话场景让模型尽量记住最近讨论的内容。递归摘要把旧的对话先摘要成一小段再和新的问题拼在一起传给模型。信息保留率高但会额外消耗 token且摘要本身可能丢失细节。这三种方案是 RAG、Agent 等高级应用的基础。你如果现在理解了它们各自的优缺点之后学习 LangChain 里的各种 memory 组件时就完全不会懵。3. 部署一个开源 LLM 的最小可行方案学基础概念最忌讳只背名词不用。我建议你在读完前两章之后尽快自己部署一个开源模型哪怕只是一个很小的 7B 模型跑通了之后对“推理”“显存”“量化”这些词才会有血肉感。3.1 显存到底怎么算一个能直接套用的公式部署大模型绕不开 GPU 显存。很多人不知道自己的显卡能不能跑某个模型其实有一个粗略但实用的估算方法模型权重占用约等于参数量 × 每个参数占用的字节数。比如一个 7B 模型用 FP16半精度每个参数占 2 字节表示权重就占 7 × 10^9 × 2 ≈ 14 GB 显存。推理时还要考虑 KV Cache、临时激活值等开销通常再留出 20%-30% 的余量。所以跑 7B FP16 全精度你至少需要 16-20 GB 显存。但绝大多数个人开发者没有这么富余的卡于是就有了量化技术把每个参数的精度从 2 字节降到 1 字节甚至更低。4-bit 量化后的 7B 模型权重占用只有 3.5 GB 左右普通 8 GB 显存显卡就能跑起来。代价是输出质量略有下降但日常对话体验几乎无差别。这里我的经验是刚入门不要追求用最小量化尽量让模型在满足硬件条件的前提下用更高精度格式。4-bit 量化适合“验证功能”真要投入生产环境最好用 8-bit 或 FP16输出质量的稳定性会好很多。3.2 我的推荐组合Ollama 一个小模型本地部署大模型的工具链这几年越来越成熟最推荐新手的有两个Ollama 和 llama.cpp。llama.cpp 适合底层玩家要自己编译功能纯粹Ollama 则把模型管理、下载、启动、交互封装成了一个非常省心的命令行工具官方文档也写得清晰。我的建议是直接装 Ollama然后拉取一个 7B 或 8B 级别的模型。安装完成后只需要两条命令就能跑起来一个服务ollama pull llama3.1:8b ollama run llama3.1:8b跑起来之后在命令行里就能直接对话。如果你想通过 HTTP 接口调用Ollama 默认会启动一个本地服务监听 11434 端口你可以用 curl 测试curl http://localhost:11434/api/generate -d { model: llama3.1:8b, prompt: 用一个比喻解释什么是 token?, stream: false }这个阶段我不建议你急着上 LangChain 或 Dify 这类框架先把“模型是怎么被调用的”这个最简单链路走通。等你对 API 的输出结构、响应时间、模型风格有了直接体感再上框架完全是水到渠成的事。3.3 推理参数初探温度、Top-p、Max Tokens当你已经成功调用模型接口后先别急着做应用把下面这几个参数都调一遍观察输出变化Temperature上面说过控制随机性。我实测下来做分类、提取结构化信息这类任务设 0-0.3 最稳做头脑风暴、创意写作设 0.7-0.9 效果最好。超过 1.0 后输出经常出现逻辑崩坏慎用。Top-p也叫核采样控制候选词的范围。它和 temperature 是两种不同维度的控制temperature 调节概率分布的“锐度”top-p 则直接砍掉累积概率低于某个阈值的低概率词。两者都可以用来控制随机性但一般建议只固定其中一个去调不要同时动两个否则效果难以归因。Max Tokens限制生成的最大长度。这个值很多人习惯性不填或填很大实际会造成两个问题一是响应时间拉长二是模型可能在没说完时就触发了填充让输出尾部出现无意义的重复。如果是做低延迟的在线服务这个值一定要根据业务需要提前卡好。你可以自己写一个简单的 Python 脚本用同一个 prompt 在不同 temperature 下各生成十次就会发现输出差异到底有多大。这种动手实验获得的体感比看十篇教程都有用。4. 为什么模型会答错RAG、幻觉与大模型的“自信”等你部署好模型真正开始使用后很快就会撞上两个让人头疼的问题模型一本正经地胡说八道以及它总觉得自己是对的。这两个问题的背后分别是“幻觉”和“模型本身没有事实校验能力”这两个特性。4.1 用生活类比理解“为什么模型会编造答案”模型做的是“预测下一个词”它没有数据库没有在回答时翻阅任何外部资料。它的所有知识都是以权重形式内化在参数里的。你可以把它想象成一个记忆力超强、但从不查证的老朋友它知道很多“说法”但并不知道哪个“说法”是真实发生的。所以当你问它一个它没学过、或某个领域训练数据中不一致的问题时它能做的仍然只是“顺着语言规律编一个最像样的答案”而且因为它的语言组织能力实在太强这个编出来的答案往往听起来极具说服力。这就是幻觉产生的根本原因。4.2 在什么场景下模型最容易胡说八道总结我踩过的坑以下三类场景最容易触发幻觉开放域提问且无参考资料比如问“2025 年之后某某行业的发展趋势”模型不知道未来只能根据训练数据的统计规律编造一个听起来合理的未来预测。要求提供不存在的精确事实如“某某公司 2024 年第二季度的具体营收是多少”如果没有检索到真实数据模型会按行业平均水平“猜”一个数字。模型“四舍五入”式泛化比如训练数据里见过“A公司 2023 年营收 100 亿”你问它 A 公司过去五年的营收它可能会把 100 亿时代入到每一年而非表示“不知道”。4.3 RAG给模型加一个“可查阅的资料库”解决幻觉最主流、也最直接的技术路线就是RAGRetrieval-Augmented Generation检索增强生成。它的思路不复杂在让模型回答之前先从外部知识库中检索出和问题相关的文档片段把这些片段拼进上下文再让模型基于这些真实材料生成回答。这个逻辑非常好理解一个学生考试的时候如果允许他把教材带进考场他对知识点的记忆压力就大大降低答案是翻书翻出来的准确率自然更高。RAG 就是这个“翻书”的动作。具体到技术链路上RAG 包括四个核心环节文档加载与拆分把 PDF、Word、网页等原始文档解析成文本块再根据语义和长度切成适合嵌入的 chunk。向量化用 Embedding 模型把每一段文本转成一个高维向量把语义相近的文本映射到向量空间中接近的位置。检索把用户的问题也转成向量和库里所有向量做相似度计算找出最相关的 Top-K 个片段。生成把检索到的片段和原始问题拼接成 Prompt交给 LLM 生成最终回答。这里要注意一个初学者常犯的错误RAG 的质量瓶颈大多不在生成而在检索。如果检索回来的片段本身不相关再强的 LLM 也只能基于错误材料生成错误答案。所以做 RAG 应用时优先把时间花在文档拆分的粒度、向量化模型的选择、检索策略的调优上而不是反复调 Prompt。4.4 让模型说“我不知道”系统提示词与安全边界RAG 能解决“被动幻觉”但还有一种情况是模型明明没有检索到相关内容却还是硬着头皮回答。这时需要你在 Prompt 里明确给它“拒绝回答”的许可。我在系统提示词里通常会这样写你是一个严谨的助手。当检索到的资料不足以支撑回答时请明确回复“根据现有资料无法回答该问题”不要编造任何信息。这一条看起来简单实际效果非常明显。因为模型天生倾向于“顺着用户”作答你只有给出显式的指令它才会心安理得地说不会。这个技巧在 Dify、FastGPT 这类低代码平台上也通用直接在系统提示词或“知识库未命中”配置里设好就行。另外一个踩坑经验不要把 RAG 表述成“让大模型连上数据库”。RAG 不是把数据库直接接到模型上而是把数据取出来、塞进上下文里。模型的上下文窗口有限你不能把所有知识都塞进去所以检索策略比存储本身重要得多。5. 推理框架与提示词工程同样一个模型效果怎么差这么多不少人在本地部署一个开源模型兴奋地测了几下发现回答质量没有演示里那么好就开始怀疑“这个模型是不是被阉割了”。其实大概率是你还没有掌握和模型打交道的正确姿势——这在业界叫提示词工程Prompt Engineering以及推理框架的参数到底该怎么配。5.1 系统提示词给模型定规矩的地方系统提示词System Prompt是在正式对话开始前就给模型设定的高级指令它决定了模型的角色、行为风格、约束条件等。你用得最多的普通用户输入User Prompt是“任务”系统提示词则是“纪律”。没有纪律模型的表现就会很飘你问它问题它可能自己先发散出去你希望它用中文回答它可能不时蹦出英文。我写系统提示词有一条黄金法则用“做什么”替代“不做什么”。比如“不要使用被动语态”就不如“请全部使用主动语态保持句子简短”来得有效。模型对“不要”的感知比对“要”的感知弱得多这是 Transformer 的注意力机制决定的——它在生成时更关注正向指令能引导的模式。另外系统提示词里可以嵌入“示例”直接给出一个问-答对业界叫 few-shot模型会立刻模仿示例的回答风格。这个方法在结构化输出场景下特别管用。5.2 模型不知道的“思考过程”与推理框架设置近两年很多模型开始支持思维链Chain of ThoughtCoT即让模型在给出最终答案前先输出一步一步的推理过程。这个机制对复杂问题的数学、逻辑推理有明显提升但也在很多产品里带来了一个困扰模型把它的“思考过程”也一股脑地展示给了用户。拿 Dify 这个开源 LLM 应用平台举例很多人在里面搭了 Agent 或工作流发现模型的输出里带了一段“让我想想”“首先我需要……”这样的东西产品永远没法上线。这时候你要做的是在模型供应商的设置里找到对应的参数开关把思维链输出关掉或者在后处理环节把“思考过程”从回答文本里提取出去。我自己更推荐的做法是把“让模型思考”和“让模型输出”拆成两步。第一步让模型先自己生成推理内容但把它隐藏在内部第二步让模型基于推理内容只输出最终答案。有些平台支持“思维链隐藏”有的需要你在提示词里做文章比如在回答之前先在草稿区写下推理过程但最终输出中只呈现答案本身。不要小看这一步对用户体感的提升是质变级的。5.3 输出格式控制远比你想的更重要很多开发者在调用 LLM 做数据提取、内容分类时被一个问题折磨到崩溃模型输出的 JSON 格式时不时多一个逗号、少一个引号程序直接解析失败。要解决这个问题核心不是靠提示词里写“请输出 JSON”而是用推理框架本身的约束能力。目前主流方案有两种结构化输出Structured OutputOpenAI 等平台直接规定了输出 JSON Schema模型只会按这个格式生成不会多任何东西。外挂校验与重试让模型先输出再用代码库解析解析失败就把错误信息反馈给模型让它修正后重试一次。我实测下来结构化输出是最稳的方案但只适用于官方 API 支持该能力的平台。开源模型部署场景下可以用 Outlines、Guidance 这类库约束采样过程效果也很好。但如果你不想引入额外依赖最简单的兜底方案就是“解析失败时重试一次”实测能把失败率从 20% 降到 2% 以内。5.4 同样是推理为什么模型有时候快有时候慢经常有人问为什么同一个模型有的请求几百毫秒就返回有的请求要卡几秒甚至更久这背后除了网络因素主要取决于生成的 token 数量。Transformer 是逐 token 生成的输出 100 token 的时间大约是输出 20 token 的 5 倍而且是严格串行的没法并行快进。所以如果你要把 LLM 接入到高并发服务里最重要的策略就是让模型少说话。回答太长了就限制 max tokens或者把任务拆得更细、让单次回答更短。有些场景还可以用模型级联先用小模型做分类再根据分类结果调用大模型——这是性价比极高的架构。还有个容易被忽视的点模型服务的首 token 延迟Time to First TokenTTFT在流式输出里体感差异巨大。如果你在做聊天机器人一定要开启流式stream输出否则用户要等全部内容生成完才能看到第一个字体验会非常糟糕。6. 从入门到能做项目LLM 应用开发的框架选择与实践路径基础概念和部署实验都走通之后你会面临一个岔路口接下来用什么东西去构建真正的应用这不只是技术选型问题更是“你想做项目还是做底层研究”的目标分叉。6.1 框架不是越多越好我建议的分类方式现在市面上的 LLM 应用框架大致分成四类低代码/可视化平台Dify、FastGPT、Coze。适合业务人员快速搭建知识库问答、客服机器人等应用界面拖拽即可完成流程编排。开发框架LangChain、LlamaIndex。提供大量组件记忆、检索、Agent适合有编程能力的开发者做定制化应用。轻量工具集OpenAI 官方 SDK、Ollama API、Vercel AI SDK。只做模型调用封装不做复杂编排轻量可控。Agent 开发平台AutoGen、CrewAI 等专攻多智能体协作场景。我见过太多初学者一上来就学 LangChain学了两周发现文档太长、版本更新太快、抽象层级太多最后连一个完整功能都没做出来然后就放弃了。我的建议很直接先根据场景选框架而不是根据框架选场景。如果你只是想快速搭建一个“知识库问答机器人”Dify 两天就能跑通。如果你要在已有的后端系统里嵌入一些 LLM 能力直接用官方 SDK 就够了。等你的需求复杂到需要多个记忆模块、动态选择工具、多轮自动决策时再回头学 LangChain 也不迟。6.2 动手做一个最小闭环从需求到上线以最经典的“文档问答机器人”为例我拆一下最小可行闭环第一步定场景和数据源。选一个单一主题的文档集比如公司内部的产品手册、政策文件。范围越小效果越好验证。第二步准备数据并入库。把文档解析成纯文本按段落或固定长度比如 200-500 字切成 chunk用 Embedding 模型给每个 chunk 生成向量存入向量数据库如 Chroma、Milvus、Qdrant。第三步接好推理链路。用 Dify 或自己写代码配置一个“问题 → 向量检索 → 拼 Prompt → 调 LLM → 输出”的链路。第四步迭代调优。上线后收集用户真实问题观察哪些问题检索不到正确片段针对性调整 chunk 切分、检索 Top-K 数量或 Embedding 模型。这里有一个很实在的提醒第一步和第二步决定了最终效果上限的 70%。很多人把精力都花在“选哪个大模型”上却不愿意花时间清洗文档、优化切分策略。结果换了好几个模型效果还是不行原因根本不是模型不够强而是喂进去的资料本来就烂。6.3 兼容性与可迁移性锁定供应商之前先想清楚最后聊一个没人提但非常重要的点不要把自己的整个应用深度绑定在某一家模型供应商的私有 API 上。我的习惯是在代码或平台配置里先抽象出一层“模型接口层”支持 OpenAI、Anthropic、以及本地 Ollama 随时切换。这样做的原因有三个不同供应商的定价波动很大绑定一家容易被涨价被动挨打不同模型的推理能力迭代很快今天最强的模型三个月后可能就被超越了如果用户群涉及隐私或合规要求可能需要从云端 API 迁移到本地部署。实际上Dify 这类平台已经帮我们做了这个抽象选择模型供应商时只改一个配置即可切换。而如果你直接写代码调用建议优先使用各家平台都兼容的接口规范或者直接装一个统一代理层。这个架构决策一旦做对后期切模型就像换轮胎一样简单否则就是拆发动机级别的重构。我个人做项目时的偏好是先用最便宜、最容易上手的方案快速验证效果确认值得投入后再上重框架。很多项目死在“想得太宏大、搭了三个月架子、然后需求变了”这个循环里。从一个小闭环跑起来再逐步扩展才是玩 LLM 应用的人最健康的姿势。7. 现在该做什么我给你的一个可执行清单很多人在看完类似的入门文章之后会觉得“字都看懂了但还是不知道从哪里开始”。为了避免你也陷入这种“学完即忘”的局面这里我把上面所有内容浓缩成一份可以直接照做的清单顺序就是我个人带新人最常推荐的路径。第一周建立体感注册一个主流大模型的 API或直接用 Ollama 跑起来一个本地模型;用同一个问题在不同 temperature 值下各问十次观察输出差异把一个 5000 字的文档直接粘贴进对话观察模型对中间部分内容的记忆衰减现象。第二周跑通部署与调用用 Ollama 部署一个 7B 量级模型用 Python 写一个最简单的 API 调用脚本实现多轮对话并打印出每次请求的 token 消耗、响应时长把“让模型输出 JSON”和“解析 JSON 失败”全套流程走一遍体会输出约束的重要性。第三周做一个 RAG 最小闭环准备一份自己的文档哪怕是你的个人笔记或产品说明书用 Dify 或 LlamaIndex把这份文档做成一个最简单的问答机器人准备 10 个问题一半从文档里出、一半不在文档里出记录模型的回答表现你会更直观地理解 RAG 的边界在哪里。第四周做一个能给别人用的东西基于第三周的知识库问答加一个前端聊天窗口哪怕是最简单的 HTML 页面把模型的“思考过程”关掉只保留最终答案找五个朋友来试用观察他们的提问方式和你预设的差异然后调整提示词和检索策略。这个清单的主线就是先有体感再懂原理先跑通小闭环再上大框架。大部分人最后学不下去都是因为跳过了“体感”这一步直接进入了“框架文档迷宫”。LLM 入门不是一个需要智商碾压的过程它需要的是好奇心、耐心和一点点动手的勇气。就像我一开始说的你不需要先读完所有论文才能和模型愉快地相处你只需要把“预测下一个词”这个心智模型装进脑子里然后把上面这份清单里的每一步真正做一遍。等这个清单做完你回头再看那些关于 Transformer、注意力机制的深度文章会发现完全不像第一次看时那么晦涩了。