LLM 这个圈子有一种很有意思的现象网上讨论最多的是 prompt 技巧、Agent 玩法、各种花式评测榜单但真到了自己上手写代码的时候很多人连max_tokens和max_context_length的区别都说不清楚服务端返回一个context_length_exceeded直接就懵了。我见过太多朋友把几个月的时间花在调 prompt 上结果连自己用的模型到底能吃进多少字、注意力机制为什么要 O(n²) 都想不明白。这篇是深入学习 LLM系列的第一篇我打算抛开那些花哨的框架和现成工具带着大家把 LLM 从黑盒变成灰盒搞清楚它的运行逻辑本地把环境跑通用一段最朴素的代码验证 Token 是怎么被吃掉的再聊聊那些请求报错背后的真实原因。内容定位在原理 第一个能跑的最小闭环适合两种人一是准备系统性学习 LLM、但不满足于只会调 API 的开发者二是已经在用现成框架做应用、想回头补一补底层认知的工程实践者。1. 先搞清楚 LLM 运行的核心逻辑Token、上下文与注意力很多人对 LLM 的认知停留在输入一句话输出一句话的层面这会导致后续所有排查都无从下手。要深入理解第一件事就是把几个基础概念彻底弄明白它们不是名词解释而是你日常调试中真正会遇到的硬件边界和逻辑边界。1.1 Token 不是词也不是字是分词结果大模型不认识文字本身它认识的是一个词表vocabulary里的编号。文本输入模型之前要先经过分词器Tokenizer切分成 Token。Token 的切分规则取决于分词器的词表设计英文里常见一个词拆成几个 Token中文里通常一个字对应一个到两个 Token标点和空格也算。一个很现实的例子同样是 1000 个英文字符用 GPT 的分词器可能切出 250 个 Token但用 Qwen 的分词器可能切出 300 个。这意味着同样长度的输入在不同模型上占用的上下文空间完全不一样。所以不要问我的文本有多少字要问我的文本有多少 Token。很多刚入门的朋友总困惑为什么我的资料明明只有一万字却说超长了几乎都是因为没算 Token 开销。1.2 上下文窗口决定了一眼能看多远上下文窗口Context Window是模型在生成每一个新 Token 时能回看的最大 Token 数量。它像一个有限的舞台舞台上的演员Token有限新演员上台就必须有老演员被挤下去。这里有个关键认知模型在生成第 N 个 Token 时只能看到前 N-1 个 Token 中、处在窗口范围内的那部分。你的历史对话、系统提示词、检索回来的资料、工具返回的结果全都挤在这个窗口里。窗口不是为你的需求设计的它是模型本身的硬件边界。1.3 注意力机制是模型理解的基石但也是瓶颈注意力机制让模型在生成每个新 Token 时对上下文中的每个已有 Token 分配不同的关注权重。这就是为什么 LLM 能回头关注前面很远的信息也是它能做长文本理解的底层能力。但注意力机制有个致命特性计算量随序列长度呈平方级增长。输入 1000 个 Token 和输入 2000 个 Token注意力计算量不是翻倍是接近四倍。这就是为什么上下文窗口越大推理延迟越高显存占用越大。理解了这一点你就知道无脑加大上下文在工程上有多不靠谱。提示学习 LLM 切忌跳跃。先把这三个概念内化成自己的直觉后面所有代码调试、参数调整、报错排查才有方向。否则遇到问题你连从哪开始查都不知道。2. 本地环境搭建与推理框架选型把第一个模型跑起来原理说完了接下来动真格的。如果你连一个模型都没在本地跑过那你对 LLM 的所有理解都建立在别人的二手经验上。这一节我带你完成环境搭建和推理框架选型目标是让你拥有一套可以随时随地进行实验的基础设施。2.1 硬件条件自查与预期管理先泼一盆冷水本地跑大模型是需要硬件底子的。一个 7B 参数的模型以 FP16 精度加载光权重就需要大约 14GB 显存再加上推理过程中的激活值和 KV Cache你至少需要 20GB 以上的显存才能跑得流畅。如果你只有一块 8GB 显存的消费级显卡也不是不能玩量化就是为这个场景准备的。把模型量化到 INT47B 模型权重降到 4GB 左右加上推理开销8GB 显存勉强能跑速度有点慢但可用。如果你连独立显卡都没有还有两条路一是用 CPU 推理7B 量化模型能跑但生成速度可能只有每秒几个 Token适合调代码不适合做产品二是直接用云端 API把本地环境只当作调试工具。我的建议是本地环境跑不跑得动 70B 不重要重要的是你把链路跑通把概念验证做扎实。2.2 推理框架速览哪个适合当你的实验台现在主流推理框架各有侧重我做了个对比方便你按需选择框架定位主要优势适合场景显存门槛Transformers研究向全家桶与 Hugging Face 生态无缝集成API 标准调试方便学习原理、做微调、跑实验高llama.cpp轻量本地推理支持 GGUF 格式量化完善CPU/GPU 通吃本地部署、嵌入式设备、低显存环境低可纯 CPUvLLM服务化部署高吞吐、PagedAttention 省显存生产环境 API 服务中高Ollama小白友好工具一条命令装模型自动管理模型文件内置 OpenAI 兼容 API快速体验、个人应用中低对于深入学习的目的我强烈建议你选Transformers 作为入门主框架理由有三第一它是 Hugging Face 生态的官方库所有模型的加载、分词、推理接口高度统一你学会一个模型的使用就等于全会了第二它的源码可读性好方便你后续深挖模型内部结构第三它是微调工具的底层依赖你后期做大模型精调时绕不开它。2.3 一步步搭建可复现的实验环境我以 Linux 环境为例Windows 下的操作大同小异。核心是创建一个干净的 Python 环境避免依赖互相污染。# 创建 Python 3.10 环境 conda create -n llm_lab python3.10 -y conda activate llm_lab # 安装 PyTorch根据自己的 CUDA 版本选择对应命令 # 访问 pytorch.org 官网获取匹配命令这里以 CUDA 12.1 为例 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装 Transformers 及配套库 pip install transformers accelerate sentencepiece protobuf # 安装 Jupyter方便做交互实验 pip install jupyterlab这里有两个坑需要提前说。第一个坑是protobuf漏装很多中文模型的 Tokenizer 依赖这个库缺了会在加载分词器时直接报错。第二个坑是accelerate必须装它负责模型在多 GPU 或 CPU 之间的自动分配缺了它大模型加载时容易 OOM。2.4 选择合适的入门模型初学者选模型的标准不是最强而是文档全、社区讨论多、失败时能找到参考。我推荐两个方向Qwen2.5-7B-Instruct 或 Qwen2.5-3B-Instruct中文支持好分词器对中文友好Notebook 上直接能跑 3B 模型做实验。Llama-3.1-8B-Instruct英文生态的标杆社区资料最丰富适合后面学习微调和评测。如果你显存实在紧张用 0.5B 或 1.5B 的小模型也完全没问题。学习阶段跑通链路比追求效果重要得多小模型速度快能让你在单位时间内做更多轮实验。3. 用一段朴素代码验证模型的思考过程环境搭好了这次我们写一段不带任何框架封装的原生推理代码。很多人一上来就用 LangChain、LlamaIndex 之类的高级封装结果内部发生了什么一概不知出了问题只能瞎试。作为深度学习的起点我坚持用最原始的方式跑通一个完整链路。3.1 最小可运行推理代码逐行拆解下面这段代码用 Transformers 加载一个对话模型输入一段文本让它生成回复。请你逐行读不要跳过。from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 指定模型名称 model_name Qwen/Qwen2.5-3B-Instruct # 加载分词器 tokenizer AutoTokenizer.from_pretrained(model_name) # 加载模型 # torch_dtypetorch.float16 用半精度加载省显存 # device_mapauto 让 accelerate 自动分配 GPU/CPU model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) # 构造对话消息 messages [ {role: system, content: 你是一个擅长用生活类比解释复杂概念的技术博客作者。}, {role: user, content: 请解释一下什么是 KV Cache} ] # 使用模板将消息列表转成模型需要的输入文本 text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) # 将文本切分为 Token 并转成张量 inputs tokenizer(text, return_tensorspt).to(model.device) # 生成回复 outputs model.generate( **inputs, max_new_tokens512, # 新生成的 Token 上限 do_sampleTrue, # 开启采样让输出多样化 temperature0.7, # 控制随机性 top_p0.8 # 核采样削减低概率 Token ) # 把生成的 Token 解码回文本跳过输入部分 response tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue ) print(response)这段代码一共做了六件事加载分词器、加载模型、格式化对话、编码输入、生成 Token、解码输出。每一件事都对应一个核心概念你全部理解之后大模型应用的骨架就搭起来了。3.2 三个生成参数背后的采样逻辑代码里我用了temperature和top_p两个采样参数它们对输出质量的影响远超很多人的直觉。temperature控制的是概率分布的尖锐程度。数值越小高概率词被选中的概率越大输出越确定数值越大低概率词也有机会被选中输出越发散。它本质上不是聪明程度而是冒险程度。temperature0时模型做贪心解码每次选概率最高的 Token输出稳定但容易陷入重复。top_p是核采样它动态选择一组概率累计超过阈值的最小 Token 集合然后在这个集合里重新归一化再采样。它的好处是自适应分布尖锐时选很少的候选分布平坦时选很多候选。实践底线写代码任务用低温度0.1-0.3创意写作用高温度0.7-0.9top_p建议固定在 0.8-0.9 区间微调即可。没有一把通用钥匙每个任务的最佳参数要靠实验确定这就是调模型的真实含义。3.3 从 Token 到文字解码的隐藏细节解码环节有个重要选项容易被忽略skip_special_tokensTrue。对话模型生成的文本中可能包含|im_end|、|endoftext|这样的特殊 Token它们不是你想让用户看到的内容而是模型用来控制输出的内部标记。解码时如果不跳过输出文本里会出现奇怪的符号。还有一个细节在decode时我从inputs[input_ids].shape[1]:开始截取的意思是只解码新生成的 Token不包含输入部分。很多人第一次跑代码时直接decode(outputs[0])发现输出里带着一长串用户输入就是这个原因。3.4 真正理解生成一个 Token 一个 Token 地蹦出来大模型生成文本的物理过程是逐 Token 的每次只预测下一个 Token把它拼到输入后面然后继续预测下一个。这意味着可能性是树状的每走一步都在所有候选词上分叉。这也是为什么同样的 prompt 每次输出都不同的原因采样阶段引入了随机性。理解逐 Token 生成这个机制你就懂了三件事第一模型输出的长度与生成步数成正比所以max_new_tokens直接影响推理时间和费用第二长文本生成必然有误差累积一步采样偏差可能被后面无限放大第三真正的流式输出打字机效果本质就是每次把新 Token 追加到缓冲区并显示这也解释了为什么流式场景下第一次返字特别快。4. 上下文窗口的隐形成本亲手验证 KV Cache 与位置编码上一节我们把模型跑通了这一节回答一个更深入的问题上下文窗口到底是怎么被耗尽的为什么同样的内容换个模型就放不下了进入 LLM 内部去看核心是两样东西KV Cache 和位置编码。4.1 KV Cache模型记忆的物理形态在自注意力机制中每个 Token 都要计算 Query、Key、Value 三组向量。模型生成新 Token 时理论上要重新计算之前所有 Token 的 Key 和 Value 向量来做注意力匹配但这个计算太浪费了——前面 Token 的 Key 和 Value 早就算过了为什么不存下来直接复用KV Cache 就是干这个的把已生成 Token 的 Key 和 Value 缓存在显存里。每生成一个新 Token只需要计算它的 Key 和 Value然后跟缓存里的历史 Key 做点积得到注意力分数。这是 LLM 推理性能的核心优化手段但代价是缓存占据显存而且随着生成长度线性增长。这就是你经常遇到生成到一半 OOM的物理原因。模型初始加载只占一部分显存剩下的空间要同时容纳 KV Cache 和前向计算的中间结果上下文越长缓存越大。4.2 亲手做一个显存占用的定量分析我们做一个简单的数学估算搞明白加大上下文的真实成本。假设模型是 Qwen2.5-7B-Instruct隐藏层维度hidden_size3584层数num_hidden_layers28注意力头数num_attention_heads28每个头的维度head_dim128。每层每组 Token 的 Key 和 Value 缓存大小为2K和V× 28注意力头× 128每个头的维度每组 Token 每层缓存是 7168 个浮点数。用 FP16 存每组 Token 每层占7168 × 2 14336 字节。28 层全部算上每组 Token 占14336 × 28 ≈ 401408 字节 ≈ 392KB。这意味着上下文长度为 1000 Token 时KV Cache 占392KB × 1000 392MB上下文长度为 8000 时占392KB × 8000 3.06GB推到 128K 上下文达到近 49GB。一个 7B 模型权重本身才约 14GBKV Cache 可能比模型权重还肥。这就是为什么生产环境里上下文越大单机并发数越低。你问一个大模型服务为什么并发上不去排除了显存总量之后八成就是 KV Cache 占得太满。工程上解决这个问题有两个方向一是用 vLLM 的 PagedAttention 把 KV Cache 分页管理按需分配二是用量化 KV Cache如 FP8 缓存降低显存占用。4.3 位置编码为什么位置这么重要注意力机制本身是无序的它对所有 Token 一视同仁如果没有位置信息模型根本没能力知道昨天和今天哪个在前。位置编码就是把 Token 的位置信息注入到模型里。Transformer 经典做法是三角函数式编码正弦/余弦函数新模型多用 RoPE旋转位置编码。RoPE 的思路很巧妙把位置信息编码成向量旋转的角度让 Query 和 Key 在做点积时自动带上相对位置关系。这种设计的优势在于外推性好、相对位置信息天然保留、数学形式优美。位置编码直接影响模型能看多远。你说模型号称 128K 上下文但如果训练时只训练了 4K 的位置编码你硬塞 128K 的内容进去注意力分数会崩掉模型回复质量断崖式下跌。这也是为什么模型文档里会有训练上下文 4096外推支持 32768这种说法——外推是硬撑质量下降是要付出的代价。4.4 上下文窗口耗尽前的应对策略实践中上下文管理永远要在窗口边界前留出余量。我的经验是推理输入的总 Token 数不要超过模型窗口上限的 75%留出生成空间同时避免注意力质量下降。如果输入实在太长主流策略是检索增强只把相关资料塞进上下文而不是全部文档和摘要压缩把历史对话的核心信息浓缩后接入。这两种手段是 RAG 和记忆机制的基础后面系列文章会展开讲你这里先建立上下文是要省着用的稀缺资源这个意识后面设计 Agent 时受益无穷。5. 请求失败、工具调用失败生产环境里最常见的两类错误排查你拿到一个模型跑通了一个 demo不等于你会用了。我敢说真正把大模型接进业务系统之后你遇到的报错比写代码多十倍。这里我给你两类最高频的真实报错场景每一类都是我或同行踩烂过的坑。5.1 上下文超限类错误不是 bug是边界没算够错误信息形如context_length_exceeded、max context reached、This models maximum context length is 8192 tokens. However, your messages resulted in 9120 tokens。这类错误的特点是逻辑完全正常纯粹是输入塞太满。根因通常是两个一是没做对话历史裁剪用户聊了一个小时后之前的对话累积到了几十万 Token二是检索结果不做截断把整篇 PDF 塞进去当上下文。排查链路是这样的服务端返回错误码先看错误响应体里有没有context_length字段多数兼容 OpenAI 的服务都有用tokenizer.encode(your_content)统计每次请求实际占用的 Token 数把感觉上的长度替换成数值上的 Token 数在代码里加一个前置拦截估算请求 Token 数超过阈值就触发历史裁剪模块。我用的一个通用解法是维护一个滑动窗口最近的 N 轮完整对话保留更早的压缩成一条摘要放最前面摘要放在系统级上下文里。这样既照顾了连续性又控制了 Token 开销。5.2 Schema 校验类错误工具调用的隐含问题近年工具调用Function Calling成为高频功能后出现了一大类极具迷惑性的错误。典型的报错是provider rejected the request schema or tool payload或者llm request failed。这类问题的根源不是网络而是你发给模型的工具定义或调用参数不符合服务端的 Schema 校验规则。很多推理框架对tools参数的格式有严格约束比如 OpenAI 兼容接口要求每个工具必须有type为function且function.parameters必须是 JSON Schema 对象。我踩过的真实场景是某次给模型传了一个工具其中的parameters里直接写了一个示例值而不是 Schema 定义结果服务端返回了一个近乎不可读的内部错误。排查花费了整个下午最后才意识到是工具定义格式不合法。排查链路复制出完整请求体报文里的tools和messages字段全量保存用你调用的框架自带的 SDK 校验函数去检查请求体比如 OpenAI SDK 的client.chat.completions.create会用 Pydantic 模型校验参数本地就能报错做个二分排除先传空工具列表请求是否成功再逐个添加工具直到找到那个坏的检查工具参数里有没有特殊类型如anyOf、allOf很多推理框架对嵌套 Schema 的支持不如官方 API。注意这个经验适用于所有 OpenAI 兼容的推理服务。不要迷信框架会帮你兜底你传出去的 JSON 必须自己保证合规这是工程底线。5.3 能跑通和能用的差距从百分比成功率到业务可用性很多团队的项目在 demo 阶段一切正常一上线就崩溃。原因是一位开发者的一次跑通和业务的99.9% 成功率之间存在巨大鸿沟。真实经验大模型输出天然带有随机性同样的请求可能第一次成功、第二次失败。我把成功率分成三级来看每级都有对应的治理手段一级单次成功能有一次成功输出。这是 demo 水平。二级重复稳定相同输入连续 10 次都成功。需要修掉工具调用参数不合法、输出格式不稳定等系统性问题。做法是固定采样参数、加输出格式校验如 JSON mode。三级异常可恢复出错了程序能自我修正。需要做错误重试、备选模型切换、降级逻辑。比如请求失败自动退避重试三次第三次用低温度参数重新生成。我在项目里最常用的做法是给所有外部模型调用加一层守护中间层拦截请求、记录日志、做参数校验、捕获异常分类处理。别嫌麻烦生产环境的稳定性全靠这层中间件撑起来的。6. 从会调 API到深入理解 LLM给新手的成长路径建议第一节到现在我们走完了从原理到实操的完整闭环。但作为系列开篇我还想跟你说点更宏观的这条路后面怎么走。6.1 基础三件套微调、RAG、Agent 的入坑顺序大模型应用开发的三座大山是微调Fine-tuning、检索增强生成RAG、智能体Agent。我见过的入门错误是按流行度排序上来就追 Agent结果连底层的上下文管理都没搞明白Agent 一跑起来各种乱。我的建议顺序是先学 RAG因为它的核心是检索和上下文管理需要的工程能力是分词、向量、排序跟 LLM 本身结合最紧密然后学微调因为深度定制必须过这一关它能让你理解模型底层的权重更新机制最后学 Agent你会发现前面两个能力全是 Agent 的底层依赖。6.2 每个阶段要过的门槛给你一张路线参考表阶段核心技能验收标准对应工具基础理解Token、上下文、采样原理能解释为什么上下文有上限Transformers推理部署模型加载、服务化、量化能本地部署 7B 量化模型并压测吞吐vLLM, llama.cppRAG 应用文档切分、向量检索、重排能做一个回答准确率可评测的问答系统LangChain, LlamaIndex微调数据处理、LoRA、评估能在单卡上微调 7B 模型并出一份评估报告LLaMA-Factory, TRLAgent 工程工具调用、记忆管理、容错能让 Agent 完成多步任务并处理失败LangGraph, 自研6.3 学习原则一次只改一个变量这是我给所有初学者的最后一条忠告大模型实验的变量太多了模型、参数、prompt、数据、上下文长度、采样配置每一个微小的变化都可能影响结果。如果你一次改三个变量结果变好了你根本不知道是哪个起作用结果变坏了你也无从排查。我个人的实验习惯是每次实验前先写下一行预期只改一个变量跑至少五次取平均记录到实验表格里。看似笨拙但数据积累出来的直觉比任何纸上谈兵都可靠。深度学习听起来玄乎但真正有效的学习方式永远是朴素的经验积累。下一篇我会讲推理服务的性能优化核心覆盖 vLLM 部署和吞吐压测到时候我们稍微往生产环境这个方向靠一点。