大语言模型入门：实用指南（2026 版）

从循环开始。文本变成 token。token 经过 Transformer。注意力机制决定哪些之前的 token 更重要。运行时维护一个 KV 缓存，这样模型就不必每次重新计算整个对话。然后模型挑选下一个 token，重复这个过程。

一份实用指南，讲解大语言模型如何工作、模型如何一次思考一个 token，以及如何在本地运行它们。

一旦理解了这个循环，硬件和软件的选择就更容易理清了。显存、量化、上下文长度、对话模板、解码、RAG、推理引擎和模型选择，都源自同样的机制。

从循环开始：token 输入，概率输出，一次一个下一个 token。权重告诉模型它学到了什么模式。上下文告诉它当前在看什么。KV 缓存是让循环可用的工作内存。硬件、运行时和模型选择只有在理解了模型遵循的内存、上下文和格式化规则之后才有意义。

目标是先让你直观理解本地大语言模型的机制，然后为你提供一条通往硬件、运行时、推理服务和当前（截至 2026 年 5 月 21 日）大语言模型研究的实用路径。

聚焦

这是一份以模型为先的指南。它从机制开始：推理、token、Transformer、注意力、KV 缓存、预填充、解码、解码控制、模型包、对话模板、模型类型、长上下文、RAG、智能体、微调、多模态模型。

之后，进入本地部署层：本地真正意味着什么、量化、显存计算、硬件层级、运行时选择、推理模式、许可证、模型选择、隐私、故障排查、基准测试、设置路径以及实际用例。

这个顺序很重要。你应该在挑选 GPU 之前先理解为什么长提示词会消耗内存。你应该在评价一个模型之前先理解为什么对话模板很重要。你应该在关心每秒 token 数之前先理解为什么解码是顺序的。

关于更深层的硬件和软件路径，我有一系列共三篇文章讲解自托管大语言模型/本地 AI：

• 第一篇：大语言模型 GPU 内存计算（2026 版）。
• 第二篇：本地 AI 硬件内存带宽（2026 版）。
• 第三篇：大语言模型与本地 AI 硬件的推理引擎（2026 版）。

前两篇讲解硬件容量和带宽计算。第三篇讲解软件层，它将硬件转化为可用的推理。本文先为你提供模型层面的基础，然后在机制清晰后，再指向这些部署层。

大语言模型实际上在做什么

运行一个模型被称为推理。对于标准解码器仅大语言模型，推理就是不断重复的同一个循环：

• 将你的文本转换为 token。
• 将这些 token 输入模型。
• 为每一个可能的下一 token 计算分数。
• 使用解码策略选择一个 token。
• 将该 token 追加到序列中。
• 重复，直到模型停止、用户停止，或达到 token 限制。

模型并非一次性写出完整的答案。它是一次生成一个 token。每一个新 token 都成为序列的一部分，影响下一个 token。

数学上，模型是一个学习到的函数：

f(theta, 序列) -> 下一个 token 的概率分布

其中：

• theta 代表模型权重。
• 序列代表提示词加上到目前为止生成的 token。
• Logits 是 softmax 之前的原始分数。
• 概率 是 softmax 之后的归一化分数。
• 解码 将那些概率转化为一个选中的 token。

这就是为什么本地生成速度以每秒 token 数来衡量。你的系统反复执行一次前向传播，挑选或采样一个 token，更新 KV 缓存，然后继续。

感知在这里很重要。长的预填充意味着在第一个词出现之前有长时间的停顿。慢的解码意味着答案流式输出很慢。本地构建者经常痴迷于解码速度，因为这是用户感受到的，但当你粘贴一个 10K token 的文档时，预填充时间才是真正令人痛苦的地方。

Token

大语言模型并不将原始文本视为单词。它们看到的是token：文本的小块，在内部用整数 ID 表示。

一个 token 可能是：

• 一个完整的单词：“hello”
• 一个单词片段：“inter”、“national”、“ization”
• 一个标点符号
• 一个带空格的字符串
• 一个字节级后备
• 一个特殊控制标记，如 <|user|>、<|assistant|>、<|end|> 或 <|tool|>

分词器将文本映射为 token ID，并将 token ID 映射回文本。常见的分词器家族包括 BPE 风格分词器和 SentencePiece 风格分词器。不同模型家族使用不同的分词器，这一点很重要。一个 4000 词的文档在一个分词器中可能是 5000 个 token，在另一个分词器中可能是 7500 个 token。

词汇表大小也很重要。词汇表更大的分词器可以将一些文本压缩成更少的 token，但它也会改变嵌入和输出投影的大小。这是为什么每秒 token 数在不同模型家族之间不能完全比较的原因之一。

Token 很重要，因为它们决定了：

• 多少文本能放入上下文窗口。
• KV 缓存会变得多大。
• 在提示词处理期间你要付出多少延迟。
• 多语言或代码密集型文本是否高效。
• 模型是否能正确看到对话标记符。

一个模型的上下文窗口是指它一次能关注的 token 的最大数量。在 2026 年，常见的本地可运行模型从 8K 和 32K 上下文到 128K、256K，甚至服务器级系统的 1M token 上下文。

但是，支持的上下文长度并不等同于廉价、快速或同样准确的上下文。一个技术上能处理 128K token 的模型可能在 64K 时变得缓慢，在 100K 时失去连贯性。始终测试你实际计划使用的上下文长度。

Token 是工作的单位。 一旦你理解了这一点，长上下文就不再显得神奇，而变得像一张你可以估算的账单。

有用的练习： 尝试我的 Tokenizer 演示应用，看看文本如何实时分解为 token。

Transformer

大多数现代大语言模型基于 Transformer 架构。大多数本地对话大语言模型是仅解码器 Transformer：它们预测下一个 token，同时回顾之前的 token。

上面所有内容，包括 token、权重、配置和对话模板，都是为底层的真正引擎所做的准备。Transformer 是移动数字的骨架。

一个简化的 Transformer 层包含：

• Token 嵌入： Token ID 变成向量。
• 位置信息： 模型需要 token 的顺序。许多现代大语言模型使用 RoPE（旋转位置嵌入），通过旋转表示来编码位置。
• 自注意力： 每个 token 表示回顾之前的 token 表示，并决定哪些是重要的。
• MLP / 前馈块： 一个密集的非线性计算，扩展和压缩表示。参数的一大部分位于这里。
• 层归一化和残差连接： 这些稳定深层网络，帮助信息在多层之间流动。
• 输出投影： 最终的隐藏状态变成词汇表上的 logits。

将这个配方堆叠几十或几百次，你就得到了一个语言模型。

Transformer 总结： Token 变成向量，注意力连接序列，MLP 重塑表示，RoPE 保持位置正确，最终投影将最后的隐藏状态变成下一个 token 的 logits。

注意力

注意力是一个 token 如何决定哪些之前的 token 对下一次预测更重要。它也是本地推理对内存如此敏感的原因之一。

经典的 MHA（多头注意力）为多个头存储独立的键/值状态。它给模型灵活性，但使 KV 缓存变得很大。

现代本地模型通常使用更高效的注意力设计：

• MQA： 多个查询头共享一个键/值头。它内存高效，但可能表达能力较弱。
• GQA： 查询头分组共享键/值头。这是许多当前本地模型中常见的中庸方案。
• MHA： 全多头注意力。它可能很强，但长上下文代价迅速增加。

现代内核如 FlashAttention 和 SDPA 风格实现减少了注意力内存流量，让 GPU 更忙碌。拥有良好注意力内核的运行时即使在相同的模型和硬件上也可能比没有的运行时快得多。

这就是为什么两个 7B 模型在长上下文时表现可以大不相同。参数量并不是全部。一个 7B MHA 模型在 128K 上下文时可能耗尽 24 GB GPU，而一个 7B GQA 模型拥有相同的标称上下文却可能还有余量。

比较模型时，要看注意力类型、KV 头数、上下文长度和运行时支持，而不仅仅是参数量。

KV 缓存

KV 缓存是模型在生成期间的工作内存。它存储之前 token 的键/值注意力状态，这样模型就不必在每次生成新 token 时从头重新计算整个历史。

没有 KV 缓存，生成将极其低效。有了 KV 缓存，生成变得可用，但缓存消耗的内存与以下成正比：

token 数 x 层数 x kv_heads x head_dim x 精度 x 2

x 2 是因为键和值。

对于较老的类似 Llama 的 7B MHA 模型，一个有用的经验法则是 FP16 KV 缓存大约每个 token 0.5 MiB。这意味着 4K token 仅 KV 缓存就可能花费约 2 GiB。在 32K token 时，你可能会看到仅 KV 缓存就达到 16 GiB。

较新的 GQA/MQA 模型大幅减少了这一点。一些运行时也支持 FP8 或 INT8 KV 缓存。这通常是 2026 年我推荐给本地用户的实用压缩下限。

不要将低于 8 位的 KV 缓存视为默认设置。 诸如 KIVI、KVQuant 等研究系统以及更新的压缩缓存内核表明，2 位到 4 位 KV 在仔细的算法、校准和定制内核下可以工作。但这与在桌面运行时随意切换 Q4 KV 选项不同。在 8 位以下，要严格进行基准测试，尤其是在编码、工具调用、JSON、长上下文检索以及精确的先前 token 很重要的任务中。

另外，不要将 KV 缓存量化与投机性解码混淆。DDTree 和 DFlash（通常非正式简称为 DTree）通过草拟未来 token 并验证它们来攻击解码延迟。它们可以提高速度，但不会消除 KV 缓存的内存开销。

这就是为什么一个模型在空提示词时可以运行，但在加载长文档时会崩溃。权重装得下，但工作内存装不下。

预填充与解码

大语言模型推理有两个不同的性能阶段：预填充和解码。

预填充处理你给模型的提示词。如果你粘贴一个 20,000 token 的文档，模型必须先处理这 20,000 个 token 才能产生第一个答案 token。预填充相对可并行化，所以 GPU 可以高效处理，但它仍然可能代价高昂。

你等待第一个 token 出现的时间通常是预填充时间。

解码一次生成一个新 token。每个生成的 token 依赖于到目前为止的序列，所以解码更加顺序化。这就是流式打字效果的来源，通常也是决定一个模型感觉快还是慢的阶段。

长提示词惩罚预填充。长答案惩罚解码。长对话两者都惩罚，因为 KV 缓存会增长。

在一个对话会话中，每一轮都会增加缓存。如果你让一个对话进行到 16K token，那么你在生成每一个新 token 时都要为所有 16K token 支付内存成本。这就是为什么保持无限历史的对话 UI 最终会变慢或崩溃。

解码

模型产生 logits 之后，它还没有写出任何东西。它只是为每一个可能的下一 token 打了分。解码是将这些分数转化为一个实际 token 的策略，将该 token 追加到上下文中，然后重复循环。

运行时或推理引擎可以通过多种方式选择 token。它可以每次都选择概率最高的 token。它可以从一个缩小的可能 token 集合中采样。它可以惩罚重复。它可以在定界符处停止。它可以使用固定种子，使相同提示词的行为可复现。

这些选择并不改变模型权重，但它们会改变模型的语气、确定性、创造性、风险倾向和循环倾向。

重要的旋钮回答三个实际问题：

• 随机性： 允许多少变化？
• 尾部覆盖： 采样器可以深入到多低概率的 token？
• 边界： 什么阻止循环、漫无边际、模式破坏或失控输出？

对于精确工作，从窄开始：低温度、短最大 token 限制、明确的停止序列，以及在输出必须匹配 JSON 或模式时的约束解码。对于创造性工作，给采样器更多空间：更高的温度、top-p，以及之后对多个候选进行排序。对于编码，第一次保持保守，只有在你故意探索时才采样替代方案。

贪婪解码并不总是更准确。它往往很脆弱。贪婪解码器可能陷入循环或产生通用的答案，因为它从不探索替代方案。对于评估，使用确定性设置。对于头脑风暴，让模型呼吸。

一个模型包包含什么

一个可运行的本地大语言模型不仅仅是一个大的权重文件。一个模型包通常包括：

• 架构/配置： 层数、隐藏大小、注意力类型、RoPE 设置、词汇表大小、特殊 token 和上下文长度。
• 权重： 学习到的参数，通常存储为 safetensors、GGUF、GPTQ、AWQ、EXL2 或其他运行时特定格式。
• 分词器： 将文本转换为 token ID 以及将 token ID 转回文本的规则。
• 对话模板： 系统、用户、助手、工具和推理消息的确切标记格式。
• 生成配置： 温度、top-p、停止 token、重复惩罚和最大 token 的默认值。
• 许可证和模型卡片： 法律和操作说明，说明如何可以使用模型。

权重是最大的文件，但它们不是整个模型。如果分词器、配置或对话模板错误，同样的权重可能会感觉坏掉了。

模型包部分告诉你什么必须一起传输。下一部分解释为什么对话模板是人们最常弄错的部分。

对话模板

一个对话模型是用特定的对话格式训练的。例如，它可能期望这样的格式：

<|system|> 你是一个有用的助手。<|user|> 解释 KV 缓存。<|assistant|>

另一个模型可能期望：

[BOS] [INST] 解释 KV 缓存。[/INST]

另一个可能使用 ChatML 风格的标记。另一个可能需要特殊的推理 token。另一个可能需要工具调用的 XML 或 JSON 包装器。

使用错误的格式可能导致乱码、角色混淆、系统提示词被忽略、提示词重复、拒绝异常、工具调用失败、基准测试结果糟糕，以及得出模型很笨的结论，而实际 bug 是模板。

最佳实践：

• 使用分词器的 apply_chat_template（当使用 Transformers 时）。
• 在 Harbor 支持的前端、llama.cpp、LM Studio、vLLM 或 SGLang 中使用模型特定的模板。
• 检查模型是基础版、指令版、对话版、推理版还是工具调优版。
• 确保 BOS/EOS token 正确。
• 除非需要很长的系统提示词，否则保持简短。
• 对于工具使用，遵循模型/运行时期望的确切模式。

如果你正在构建一个允许用户切换模型的应用，你也需要模板切换。硬编码一种模板格式然后加载一个期望另一种模板的模型，是本地模型评估常见的错误来源。

将模板视为 API 契约。如果弄错了，你实际上不是在测试你认为你在测试的模型。

模型类型

并非所有大语言模型都以相同的行为进行调优。

对于大多数用户，默认的起点应该是一个最近的指令/对话调优模型，大小适合你