LLMs 101：实用指南（2026 版）

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

一份关于 LLM 工作原理、模型如何一次一个令牌地思考以及如何在本地运行它们的实用指南。

一旦你理解了这个循环，硬件和软件的选择就变得更容易推理了。VRAM、量化、上下文长度、聊天模板、解码、RAG、推理引擎和模型选择，都源于同样的机制。

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

目标是先让你直观理解本地 LLM 的机制，然后为你提供一条进入硬件、运行时、推理服务以及截至 2026 年 5 月 21 日的 LLM 研究现状的实用路径。

焦点

这是一份以模型为先的指南。从机制开始：推理、令牌、Transformer、注意力机制、KV 缓存、预填充、解码、解码控制、模型包、聊天模板、模型类型、长上下文、RAG、Agent、微调和多模态模型。

之后，进入本地部署层：本地到底意味着什么、量化、VRAM 计算、硬件层级、运行时选择、服务模式、许可证、模型选择、隐私、故障排除、基准测试、设置路径和实际用例。

这个顺序很重要。在选择 GPU 之前，你应该先理解为什么长提示会消耗内存。在评判模型之前，你应该先理解为什么聊天模板很重要。在关心每秒令牌数之前，你应该先理解为什么解码是顺序进行的。

对于更深入的硬件和软件路径，我有一个三篇系列文章教你自托管 LLM / 本地 AI：

• 第 1 部分：LLM 的 GPU 内存计算（2026 版）
• 第 2 部分：本地 AI 硬件的内存带宽（2026 版）
• 第 3 部分：LLM 及本地 AI 硬件的推理引擎（2026 版）

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

LLM 实际上在做什么

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

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

模型并不是一次性写出整个答案。它一次只生成一个令牌。每一个新令牌都会成为序列的一部分，并影响下一个令牌。

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

f(theta, sequence) -> 关于 next_token 的概率分布

其中：

• theta 表示模型权重。
• sequence 表示提示加上迄今为止生成的令牌。
• Logits 是 softmax 之前的原始分数。
• Probabilities 是 softmax 之后的归一化分数。
• Decoding 将这些概率转化为一个选定的令牌。

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

这里的感知很重要。长预填充意味着在第一个单词出现前会有长时间停顿。慢解码意味着答案流式输出缓慢。本地构建者经常执着于解码速度，因为这是用户能感受到的，但当你粘贴一个 10K 令牌的文档时，预填充时间才是让你难受的。

令牌

LLM 不会将原始文本视为单词。它们看到的是令牌：在内部表示为整数 ID 的小文本块。

一个令牌可能是：

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

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

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

令牌之所以重要，是因为它们决定了：

• 上下文窗口中能容纳多少文本。
• KV 缓存会变得多大。
• 在提示处理过程中你需要支付多少延迟。
• 多语言或代码密集型文本是否高效。
• 模型是否正确看到了特殊的聊天标记。

模型的上下文窗口是它一次可以关注的最大令牌数。到 2026 年，常见的本地可用模型范围从 8K 和 32K 上下文到 128K、256K，甚至服务器级系统的 1M 令牌上下文。

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

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

有用的练习：试试我的分词器演示应用，看看文本是如何实时被拆分成令牌的。

Transformer

大多数现代 LLM 都基于 Transformer 架构。大多数本地聊天 LLM 是仅解码器的 Transformer：它们预测下一个令牌，同时回顾之前的令牌。

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

一个简化的 Transformer 层包含：

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

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

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

注意力机制

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

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

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

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

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

这就是为什么两个 7B 模型在长上下文下表现可以截然不同的原因。参数量并不是全部。一个 7B 的 MHA 模型在 128K 上下文下可能会耗尽 24 GB 的 GPU，而一个具有相同宣称上下文长度的 7B GQA 模型可能还有富余空间。

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

KV 缓存

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

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

令牌数 x 层数 x KV 头数 x 头维度 x 精度 x 2

x 2 是因为键和值。

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

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

不要将低于 8 位的 KV 缓存视为默认选项。像 KIVI、KVQuant 等研究系统以及更新的压缩缓存内核表明，2 位到 4 位的 KV 缓存可以通过精心设计的算法、校准和自定义内核工作。这与在桌面运行时随意切换 Q4 KV 缓存开关不同。低于 8 位时，请仔细进行基准测试，特别是对于编码、工具调用、JSON、长上下文检索以及精确的早期令牌很重要的任务。

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

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

预填充和解码

LLM 推理有两个不同的性能阶段：预填充和解码。

预填充处理你提供给模型的提示。如果你粘贴一个 20,000 令牌的文档，模型必须处理这 20,000 个令牌，然后才能产生第一个答案令牌。预填充相对可并行化，因此 GPU 可以高效处理它，但它仍然可能很昂贵。

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

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

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

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

解码

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

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

这些选择不会改变模型权重，但它们会改变模型的声音、确定性、创造力、风险特征和循环倾向。

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

• 随机性：允许多少变化？
• 尾部覆盖：采样器可以深入到多低概率的令牌？
• 边界：什么防止循环、胡言乱语、模式破坏或失控输出？

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

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

模型包包含什么

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

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

权重是最大的文件，但它们不是模型的全部。如果分词器、配置或聊天模板错误，相同的权重可能会感觉有缺陷。

包部分告诉你要一起旅行的是什么。下一节解释为什么聊天模板是人们最常破坏的部分。

聊天模板

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

<|system|> 你是一个乐于助人的助手。 <|user|> 解释 KV 缓存。 <|assistant|>

另一个模型可能期望：

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

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

使用错误的格式可能导致胡言乱语、角色混淆、忽略系统提示、重复提示、拒绝奇怪、工具调用失败、基准测试结果不佳，以及得出模型很蠢的结论，而实际上模板才是真正的错误。

最佳实践：

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

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

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

模型类型

并非所有 LLM 都针对相同的行为进行了调优。

对于大多数用户，默认的起点应该是一个最近的指令/聊天调优模型，其大小能舒适地放入内存。

除非你知道原因，否则不要从基础模型开始。基础模型会补全你的提示，而不是回答它。它们对研究人员、微调者和构建自定义管道的人有用。对其他人来说，它们令人沮丧。

如果你问一个基础模型“法国的首都是什么？”，它可能会继续“以及巴黎的人口是多少？”而不是回答“巴黎”。

实际的区别很简单：

• 基础模型：适用于预训练研究、微调和自定义管道。
• 指令模型：适用于直接遵循指令。
• 聊天模型：适用于带有角色格式的多轮对话。
• 推理模型：适用于任务受益于额外思考令牌和验证。
• 工具调优模型：适用于结构化调用、JSON 或函数使用很重要的情况。

本地到底意味着什么

本地 LLM 是指其权重和推理运行时受你控制的模型。你决定运行什么模型、如何运行、它看到什么数据以及输出如何处理。

这种自由伴随着工作。你现在是运维团队。你处理下载、更新、兼容性、内存限制和安全。当出现问题时，没有支持工单可提交。只有你、日志和文档。

本地可以意味着：

• 在手机上运行的 2B 参数模型。
• 在消费级 GPU 上运行的 7B 到 14B 模型。
• 在高端工作站上运行的 30B 到 70B 模型。
• 在一个或多个数据中心 GPU 上运行的稀疏 MoE 模型。
• 使用 vLLM、SGLang、TensorRT-LLM、llama.cpp、Harbor、LM Studio 或自定义 PyTorch 堆栈的私有部署。

关键点：本地并不自动意味着离线、私有、安全、便宜或开源。它只意味着你自己在运行模型。一个本地应用仍然可以回传数据。一个模型可以是开放权重但不开源。一个模型可以是本地的但不安全加载。一个量化模型可以装入内存但回答很差。

当你需要隐私、低延迟、自定义行为、离线操作或大规模成本控制时，这种权衡是值得的。当你需要绝对最佳的模型质量并且没有相匹配的硬件时，它就不值得。在这种情况下，托管 API 是合适的工具。

本地 LLM 在你理解一个等式时才是实用的：

本地 LLM 成功 = 模型适配 + 正确的提示格式 + 良好的运行时 + 现实的评估。

其他一切都是细节。细节很重要。

量化

量化以较低精度存储权重，以减少内存并有时提高吞吐量。

2026 年本地用户的经验法则：

• FP16/BF16：当内存充足时质量最佳。将其用作评估的基线。
• Q8 / INT8：对许多任务几乎无损，但仍然较大。当你有 VRAM 并且希望最小化质量损失时很好。
• Q6 / Q5：质量极好，节省适中。这是一个强大的中间地带。
• Q4：许多聊天和文档工作流程的默认消费者甜区。
• Q3 / Q2：仅当你必须容纳更大的模型时使用。数学、代码、结构化输出和工具使用首先会降级。

权重量化不同于 KV 缓存量化。权重量化缩小模型。KV 缓存缩小实时上下文内存。

对于 KV 缓存，将 FP16/BF16 视为干净的基线，FP8/INT8 视为实用的本地压缩下限。低于 8 位是研究密集型且工作负载敏感的。只有在测量了实际提示的质量后才使用。

量化失败首先出现在数学、多步推理、代码正确性、工具使用可靠性、JSON/模式遵循、微妙的指令遵循和长上下文检索中。

一个较小但精度更高的模型可以击败一个被压缩到过少位数的较大模型。不要崇拜参数量。一个 7B 的 Q6 模型在推理任务上可以击败一个 13B 的 Q2 模型，同时使用更少的内存并运行得更快。

文件格式和加载安全性

safetensors 是一种安全的张量序列化格式，旨在存储张量而不使用 Python pickle 行为。尽可能使用 safetensors，特别是对于 PyTorch / Transformers 模型。

避免来自不可信来源的随机 .bin 文件。基于 PyTorch pickle 的加载可能会在反序列化期间执行任意代码。本地 AI 安全规则第一条：不要让陌生人的模型文件变成陌生人的代码执行。

GGUF 是 llama.cpp 生态系统的二进制模型格式。当你想要 llama.cpp、CPU 推理、Apple Silicon 推理、简单的本地服务器、可移植的量化模型或 LM Studio 等桌面工具时，使用 GGUF。

ONNX 适用于标准化部署和硬件特定加速，特别是在常见的 PyTorch 堆栈之外。如果你部署到 Intel NPU、ARM 设备或自定义加速器，ONNX 通常是阻力最小的路径。

TensorRT-LLM 是 NVIDIA 面向生产 GPU 部署的高性能推理路径。它功能强大，但比 llama.cpp 或 Harbor 更复杂。你通常需要将检查点转换为 TensorRT 引擎，这需要时间和 GPU 内存，但一旦构建完成，会产生极好的吞吐量。

EXL2 / GPTQ / AWQ 格式在专注于 GPU 的本地推理社区中很常见，特别是用于将更大的模型塞入单个 GPU。

文件格式的选择并非表面功夫。它决定了哪些运行时可以加载模型，你可以使用哪些量化，以及它运行得有多快。

运行时和服务模式

运行时是加载模型并执行推理的软件。到 2026 年，本地 LLM 运行时生态系统已经成熟、有用且分散。

对于个人实验，从 Harbor、LM Studio 或 llama.cpp 开始。当你想要一个完整的本地堆栈，包括前端、后端和支持服务时，Harbor 是最佳选择。LM Studio 是最简单的桌面优先路径。llama.cpp 是可移植的低级主力。

对于团队或私有服务，考虑 vLLM 或 SGLang。为了获得最大的 NVIDIA 生产性能，研究 TensorRT-LLM。对于浏览器或移动部署，查看 MLC 或 WebLLM。

运行时的选择通常将你锁定在一个格式生态系统中。llama.cpp 意味着 GGUF。vLLM 和 SGLang 通常意味着 safetensors 或 Hugging Face 检查点。TensorRT-LLM 意味着 ONNX 或优化引擎。先选择运行时，然后找到正确格式的模型。

有三种实用的服务模式。

单用户本地意味着一个桌面应用、CLI 堆栈或命令行服务器，供一个人使用。Harbor、LM Studio、llama.cpp 服务器、ExLlama / TabbyAPI 和小型 Transformers 脚本都属于这一类。目标是快速迭代：比较行为、速度、内存使用和提示格式，而无需构建一个运维平台。

团队或私有 API 意味着在工作站或服务器上提供一个兼容 OpenAI 的端点。vLLM、SGLang、TensorRT-LLM 和 llama.cpp 服务器都会出现在这里，具体取决于模型大小和吞吐量需求。一旦多人或多个任务共享一个模型，你就需要监控、提示/版本管理、路由和现实的延迟测量。

生产级服务是另一回事。现在，对话涉及连续批处理、前缀缓存、推测解码、分页注意力、张量并行、流水线并行、量化服务、结构化输出、负载均衡、GPU 利用率、延迟百分位数、提示缓存、准入控制、日志记录、故障转移、隐私以及成本控制。

在生产规模下，模型能否加载？是简单问题。真正的问题是：在真实流量下，能否可靠地提供服务？

本地模型的 VRAM 计算

主要有三个内存消耗者：

1. 模型权重
2. KV 缓存
3. 运行时开销

粗略的权重内存公式如下：

weight_memory ~= 参数数量 x 每参数字节数

有用的近似值：

• FP16/BF16：每个参数约 2 字节。
• INT8/Q8：每个参数约 1 字节。
• Q4：每个参数约 0.5 字节，外加格式开销。

然后加上：

• 运行时开销：框架缓冲区、CUDA 开销、内存碎片和临时张量。
• KV 缓存：随着活动上下文中的每个 token 而增长。
• 批处理/并发内存：每个并发请求都需要自己的缓存。
• 视觉编码器内存：图像也会变成 token。
• 推测解码内存：草稿模型、草稿头或额外的验证结构都不是免费的。
• 适配器内存：LoRA 适配器虽小，但确实是真实开销。

MoE 模型还会多一个变量。一个模型可能每个 token 只激活其参数的一小部分，但未激活的专家通常仍需要在内存中某处存放。活动参数影响计算成本。总参数数仍影响加载和容量规划。

一个实际的估算看起来像这样：

total_memory = 量化后权重 + KV 缓存（上下文） + 运行时开销 + 批处理/并发开销 + 安全余量

容易踩的坑是：一个 13B 模型在 Q4 量化下可能轻松适用于 8K 上下文，但在 32K 上下文中失败，因为 KV 缓存翻了四倍。权重没变，但上下文变了。

留出 10% 到 20% 的余量。VRAM 利用率达到 99% 是在自找内存不足错误和碎片化故障。

实际硬件层级

以下是 2026 年实用的经验法则，假设使用量化推理和合理的上下文长度。确切结果取决于运行时、量化方式、模型架构、注意力类型、上下文长度以及操作系统/驱动开销。

对于 2026 年大多数严肃的本地用户来说，16 GB 是最低舒适 GPU 层级，24 GB 是性价比最高的发烧友层级，而 48 GB 以上则开启了更强的本地世界。

性能取决于内存带宽、GPU FLOPs、VRAM 容量、KV 缓存大小、注意力实现、量化方式、批处理大小、提示长度、生成长度以及运行时成熟度。

解码阶段通常是内存带宽瓶颈：GPU 反复加载权重，而每字节计算量相对较小。预填充阶段则更偏向计算密集型，因为可以并行处理提示。这就是为什么两块 VRAM 容量相同的显卡，如果内存带宽相差很大，token 速度也会截然不同。

最痛苦的本地设置是模型几乎放不下而将部分层卸载到 CPU。技术上是能运行的，但 token 速度可能暴跌。CPU 卸载可以用于实验，但绝不是性能策略。

选择适合的模型

实际问题不是“最好的模型是什么？”，而是“在你的硬件上，能胜任你实际工作负载的最小模型是什么？”

从适合您实际所需上下文长度的最新 instruct/chat 模型开始。如果您有 8 GB 到 12 GB VRAM 或统一内存，从小模型开始。如果您有 16 GB 到 24 GB，先测试 7B 到 14B 类模型。如果您有 48 GB 或更多，则更大型的密集模型和 MoE 模型变得可行。

在爱上某个检查点之前，先使用这个内存门槛：

权重 + KV 缓存 + 运行时开销 <= 可用内存的 80% 到 90%

然后，在候选模型中运行相同的 20 到 50 个提示。包括您的实际任务：代码修改、文档问答、JSON 输出、总结、工具调用、长上下文等。衡量答案质量、延迟、内存使用、模板可靠性和失败模式。

实际的模型选择通常归结为五个检查点：

• 任务匹配：聊天、编码、文档、智能体、多模态、边缘设备或微调。
• 内存匹配：权重、KV 缓存、运行时开销和余量。
• 接口匹配：分词器、聊天模板、停止 token、工具模式和推理模式。
• 运行时匹配：您的运行时是否良好支持该架构、量化、上下文长度和服务模式？
• 许可匹配：您能否在计划使用的场景中实际使用该模型？

排行榜有助于发现，但不能替代您自己的评估。您的工作负载才是最重要的基准。

对于简单的本地助手，选择最新的 7B 到 14B instruct 模型、Q4/Q5 量化、正确的聊天模板、8K 到 32K 上下文，以及 Harbor、LM Studio 或 llama.cpp。优先考虑响应速度，而不是一味追求大尺寸。

对于本地编码助手，如果有足够 VRAM，选择具备编码能力的 14B 到 32B 模型。使用低温度、仓库检索、测试执行和基于补丁的工作流程。没有工具的代码模型只能算半个产品。

对于私人文档助手，选择强大的 instruct 模型、本地嵌入模型、重排器、RAG 管道、引用强制功能以及中长上下文。不要直接粘贴一份 200 页的 PDF 并指望它。

对于推理场景，选择经过推理微调的模型，预留额外 token，使用低到中温度，添加验证步骤，并使用数学、代码或搜索等工具。推理模型消耗更多 token，请相应规划预算。

对于低资源场景，选择 1B 到 4B 模型、Q4/Q5、短提示、结构化任务、检索或工具，以及严格的输出模式。当任务受约束时，小模型也能变得有用。

什么控制速度

每秒 token 数并非由单一因素决定。它是模型大小、内存带宽、计算能力、注意力内核、上下文长度、量化方式、批处理以及运行时的综合结果。

主要杠杆有：

• 内存带宽：解码阶段通常重复加载模型权重，因此带宽主导单用户 token 速度。
• GPU FLOPs：预填充和大批量处理需要更多并行计算，因此 FLOPs 在那里更重要。
• VRAM 容量：如果模型或 KV 缓存溢出到 CPU，性能会崩溃。
• 注意力实现：FlashAttention、SDPA、分页注意力以及运行时特定的内核会同时改变速度和内存行为。
• 量化方式：更小的权重减少内存移动，但激进的量化可能损害质量，有时会增加反量化开销。
• 批处理大小和并发：批处理提高吞吐量，但每个活跃序列都需要 KV 缓存。
• 提示长度：长提示增加预填充时间。
• 生成长度：长答案暴露了解码速度。
• 推测解码：当支持时，EAGLE 风格的方法、MTP、DFlash 和 DDTree 可以在一次目标前向传播中验证多个草稿 token。

最痛苦的设置是“几乎放不下”的设置。一个将层或缓存卸载到 CPU 的模型，技术上是能运行的，但 token 速度可能从可用沦为糟糕。

请针对计划使用的确切运行时、量化、上下文长度、提示形状和工作负载进行基准测试。一个 BF16 排行榜数字并不能告诉您 Q4 本地堆栈的实际体验。

长上下文

长上下文听起来很神奇：128K、256K 甚至 1M token 的单个提示。它很有用，但也有实际代价。

更多的上下文意味着更多的 KV 缓存内存、更慢的提示处理、更多的注意力计算、更难的评估，以及更多无关文本分散模型注意力的方式。质量也可能随距离衰减。一个模型可能很好地处理长文档的末尾，却遗漏了开头附近的关键细节。

在以下场景使用长上下文：整文档分析、代码库切片、法律或技术审查、转录总结、多文件推理，以及当检索漏掉上下文时作为 RAG 的备用方案。

不要将长上下文视为检索的替代品。它是补充。对于大型语料库使用 RAG，对于最终选择的证据使用长上下文。

一些实用的习惯：

• 将关键指令放在开头附近和末尾附近。
• 使用章节标题和分隔符。
• 要求引用关联到源块。
• 压缩无关历史。
• 使用摘要记忆而非无限聊天历史。

将长上下文视为昂贵的注意力，而不是免费的笔记本。

多模态

多模态本地模型除了文本外，还可以处理图像，有时包括音频和视频。现代开放权重生态系统越来越多地包含这些模型。

隐藏的代价是非文本输入也会变成 token。视觉编码器增加内存。图像块消耗上下文。音频和视频可能使输入预算爆炸。多模态模板也比纯文本模板更容易出错。

一张高分辨率图像可能消耗数千个上下文窗口中的 token。如果您在本地运行多模态模型，请像计数文本 token 一样计数图像 token。它们来自同一个预算。

小型 VLM 可能会产生视觉细节的幻觉。OCR 可靠性参差不齐。图表和表格仍然困难。对于严肃的文档或图像工作流程，请使用真实样本进行评估。不要相信一张简单照片的演示就能证明发票提取的质量。

2026 年的本地模型格局

模型格局变化很快。截至 2026 年 5 月 21 日，本地 LLM 用户应该根据系列和生态系统来思考，而不是一个最佳模型。

Qwen 3.5 / Qwen 3.6 是一个重要的开放权重系列，因为它覆盖了完整栈：适用于笔记本电脑的小模型、适用于工作站的密集中型模型、适用于多 GPU 服务的 MoE 模型、FP8 变体、长上下文、多语言工作、编码、工具和智能体工作流程。实际要点很简单：当您需要一个横跨笔记本电脑实验和严肃本地服务的生态系统时，Qwen 是一个强大的默认选择。

Gemma 4 很重要，因为 Google DeepMind 正在推动该系列走向实用的本地部署：高效的边缘模型、更大的密集和 MoE 选项、多模态、更大模型上的长上下文、广泛的语言支持、更强的编码/智能体行为，以及 Apache 2.0 许可。这种组合使其在商业使用和设备端部署非常重要的情况下值得测试。

Kimi / Moonshot AI、GLM / Z.ai、DeepSeek、MiniMax 和 Mistral 也是需要追踪的核心系列。Kimi 与长周期编码、多模态推理、工具使用和智能体工作流程相关。GLM 对于编码智能体、长周期任务、MoE 系统和面向部署的模型发布很重要。DeepSeek 由于大型 MoE 系统、多头潜在注意力、DeepSeekMoE、FP8 服务路径、稀疏注意力和高吞吐量自托管而保持影响力。MiniMax 值得关注，因为它面向实用的智能体工作负载和推理高效的 MoE 模型。Mistral 仍然重要，因为其产品线覆盖通用、编码、推理、多模态和专业用例，并具有强大的部署支持。

Nemotron 3 是 NVIDIA 的开放模型系列，用于在 NVIDIA 硬件上进行生产级智能体系统。该系列包括 Nano、Super 和 Ultra 尺寸，采用混合 Mamba-Transformer MoE 设计，并与 TensorRT-LLM、NIM、Dynamo、Blackwell NVFP4/FP8 路径和企业智能体部署紧密相关。不要把它当作一个随意的桌面聊天系列，而应视为 NVIDIA 希望开放权重服务栈未来走向的一个信号。

开放权重 AI 不再是 Llama vs. 其他一切。您在选择一个生态系统：权重、许可、分词器、模板、量化、运行时支持、服务路径、社区工具和失败模式。

Qwen 27B 密集模型

Qwen 3.5 / 3.6 27B（密集）是本地用户最实用的公开权重选项之一，尤其适合关心编码、多语言工作、工具使用、思考/非思考模式以及长上下文的用户。Qwen 3.5 27B 和 Qwen 3.6 27B 的模型卡描述了兼容 OpenAI 的服务路径、思考模式默认值、工具使用以及最高 262,144 token 的上下文长度，通过 YaRN 在支持框架中可扩展更长上下文。

对于 2 块 RTX 3090 的设置，当运行时针对编码、智能体或多语言覆盖正确配置时，Qwen 是一个强大的默认选择。

推理研究

2026 年的前沿不仅在于模型质量，还在于推理效率。PagedAttention 解决了服务中的 KV 缓存内存浪费问题。FP8 KV 缓存现在已成为诸如 vLLM 等系统中的实用运行时功能。DFlash 和 DDTree 探索了使用块扩散草稿模型和草稿树进行推测解码。NVFP4 在 NVIDIA 硬件上也值得关注，因为它改变了受支持栈的实际部署对话。

其中一些已可生产使用，一些仍是研究，还有一些只有在您的运行时干净支持时才有意义。不要将论文中的速度提升视为桌面应用中的一个复选框。

故障模式与修复

大多数本地 LLM 故障并不神秘。它们通常来自内存适配、格式化、运行时支持、解码设置或检索质量。

内存不足：权重、KV 缓存、运行时开销或批处理大小不匹配。使用更小的模型，减少上下文，降低批处理/并发，选择更好的量化，或留出更多余量。

胡言乱语或角色混淆：聊天模板、分词器、BOS/EOS token、推理模式切换或工具模式错误。在归咎于模型质量之前，先验证模型卡和运行时模板。

首 token 慢：预填充代价高。缩短提示，使用前缀缓存，改进检索，减少上下文，或使用更快的运行时。

流式输出慢：解码是瓶颈。检查内存带宽、量化、CPU 溢出、注意力后端、推测解码支持，以及模型是否对于硬件来说过大。

文档回答差：检索可能失败。检查解析后的文本、分块边界、元数据、top-k 检索、重排和引用溯源。

JSON 或工具调用差：使用更低温度、受约束解码、更严格的模式、更好的示例，以及针对工具使用微调的模型。

重复循环：降低温度或 top-p，添加重复惩罚，检查停止 token，并确保模板不会导致模型将自身答案视为新提示。

从枯燥的检查开始。它们比更换模型能解决更多问题。

如何升级堆栈

初学者：最简单实用的设置

使用 Harbor 或 LM Studio，一个最新的 4B 到 9B instruct 模型，Q4 量化，8K 到 32K 上下文，以及内置聊天 UI。下载两三个同尺寸类别的模型，并在相同提示下进行比较。

目标：学习提示编写，比较模型，理解速度和内存，并避免一开始就写自定义代码。

中级：开发者设置

使用 llama.cpp 或 Transformers，GGUF 或 safetensors，兼容 OpenAI 的本地服务器，简单的 RAG 管道，以及一个小型评估集。从真实应用或脚本调用您的本地服务器，而不仅仅使用聊天 UI。

目标：构建本地应用，测试检索，衡量质量，并从 localhost 提供服务。

高级：私有服务设置

使用 vLLM 或 SGLang，一块或多块 GPU，兼容 OpenAI 的 API，监控，提示/版本管理，评估套件，带重排的 RAG，以及工具沙箱。

目标：为真实用户或内部工作流提供服务，优化吞吐量和延迟，并保持安全和可观测性。

专家：自定义优化

使用 TensorRT-LLM，自定义内核，专用运行时，量化实验，推测解码，多 GPU 并行，微调，蒸馏，以及生产级评估。

目标：用工程时间换取推理效率，降低成本，并在规模上提高质量。

隐私不是自动的

本地 LLM 改善了隐私，因为提示和输出可以保留在您的硬件上。但本地并不意味着自动安全。

威胁包括：恶意模型文件、pickle 权重加载、不可信的 trust_remote_code、检索文档中的提示注入、工具调用滥用、通过日志泄露秘密、桌面应用的遥测、浏览器扩展或插件、高风险场景中的模型幻觉、许可违规，以及微调期间的数据污染。

一个可行的本地 AI 安全基线有四个习惯：

• 小心加载：优先选择来自可靠来源的 safetensors 或 GGUF，避免不可信的 .bin 文件，不要随意启用 trust_remote_code。
• 限制运行：使用非特权用户，为智能体使用容器或沙箱，并在离线隐私重要时禁用网络访问。
• 保护秘密：避免在提示和 RAG 索引中包含凭据，检查桌面应用遥测设置，并在执行前验证工具调用。
• 版本控制重要的东西：跟踪模型、提示、适配器、运行时和量化版本，并记录足够用于调试的信息，同时避免造成隐私灾难。

本地 AI 安全主要是枯燥的操作纪律。这也正是避免下载随机检查点、以 root 身份运行，并将本地 AI 变成本地入侵的方法。

真正重要的基准测试

请对您实际运行的堆栈进行基准测试。模型的 BF16 排行榜分数并非您的 Q4 本地现实。

衡量质量、延迟、内存、可靠性和操作适配性：

• 质量：在您的真实任务上的正确性，而不仅仅是通用基准。
• 延迟：首 token 时间、解码 token 每秒速度、端到端时间。
• 内存：权重内存、KV 缓存增长、峰值 VRAM 以及负载下的余量。
• 格式化：聊天模板正确性、JSON/模式成功率、工具调用可靠性、停止 token 行为。
• 检索：引用忠实度、答案溯源、缺少证据时的行为、重排器影响。
• 运维：启动时间、预热行为、崩溃恢复、日志记录、隐私、版本跟踪。

创建一个包含 30 到 100 个代表性提示的小型评估集。包括期望答案或评分标准、延迟和内存测量、失败类别、RAG 特定的溯源检查、JSON 合规性检查（如果相关），以及针对模糊任务的人工审查。

然后比较模型。不要让排行榜为您选择本地堆栈。

使用本地模型进行编码

编码是本地 LLM 的最佳用例之一，因为提示通常包含私有代码、延迟很重要、迭代频繁、API 成本可能快速增长，并且本地模型可以集成到编辑器、shell、grep、测试运行器和补丁工作流中。

最强大的本地编码设置不是裸聊天机器人。而是一个具备编码能力的 instruct 模型，连接到有针对性的仓库上下文、代码库检索、文件路径、相关片段、测试执行和补丁循环。

保持解码为确定性或低温度。要求补丁而非模糊建议。自动运行测试。保留一个包含实际错误和任务的小型评估集，以便判断新模型是否真的更好。

不要让本地模型在未经审查的情况下重写大型代码库。本地化并不能让编码智能体变得明智。它只是让上下文私有、循环更便宜、集成更容易控制。

本地智能体需要护栏

当本地 LLM 能够使用工具时，它会变得更有用：文件搜索、shell 命令、浏览器自动化、数据库、代码执行、日历、工单系统、内部 API、向量数据库、家庭自动化、机器人或边缘设备。

工具使用改变了安全模型。一个会幻觉的聊天机器人很烦人。一个有文件系统访问权限的智能体可以删除东西。一个有浏览器访问权限的智能体可能泄露秘密。一个有 shell 访问权限的智能体在您读到日志之前就可能损坏机器。

本地智能体安全有四个层面。对智能体进行严格的范围限定，只给它真正需要的目录、API、网络访问和凭据。通过沙箱、容器、最小权限用户、对破坏性操作进行确认以及模式验证的工具参数来约束执行。将输入视为敌对，因为检索到的文档、网页、工单和电子邮件可能包含提示注入。保留审计跟踪，记录工具调用、模型版本、提示和批准，同时避免将秘密倾倒到日志中。

结构化输出有帮助，但它们不是安全边界。JSON 模式、受约束解码和函数签名使工具调用更易于验证。它们并不能证明模型理解了请求、选择了安全操作或避免了注入指令。

对于严肃的工具使用，将策略检查放在模型外部。

RAG 胜过巨型提示

RAG 代表检索增强生成。它不是将所有信息塞进提示，而是从知识库中检索相关块，只将这些块提供给模型。

一个良好的本地 RAG 系统通常包括文档摄入、解析、分块、嵌入、向量索引、检索、重排、提示构建、答案生成、溯源检查和评估。每个阶段都是一个失败点。

糟糕的解析会将表格变成垃圾。糟糕的分块会将答案切分到边界之外。糟糕的检索返回不相关的段落。糟糕的重排将正确答案埋在排名 20 的位置。一个好的模型无法从从未收到的证据中可靠地回答。

大多数糟糕的 RAG 系统并非因为 LLM 而糟糕。它们是因为分块、检索、重排和评估而糟糕。

分块策略是无声的杀手。固定大小且无重叠的分块可能拆分句子并丢失上下文。语义分块或带父文档检索的分层分块通常效果更好，但没有通用答案。您必须根据实际文档评估块大小、重叠和拆分规则。

一个好的重排器可以挽救平庸的检索。但没有重排器能修复摄入期间丢失答案的块。

文档与知识工作

对于私有文档，本地 LLM 表现出色：会议记录总结、合同审查、技术文档问答、研究笔记综合、电子邮件起草、政策搜索、内部支持助手和合规工作流，所有这些都受益于将源材料保留在拥有它的机器或组织附近。

工作流程简单但严苛。仔细解析文档，保留页面和章节元数据，语义分块，使用嵌入和重排器，要求引用，将答案与来源以及一般推理分开，并评估引用忠实度。

不要假设模型知道文档中的内容。它只知道您放入提示或检索到上下文中的内容。

对于会议记录，保留说话人标签和时间戳。对于合同审查，按条款或章节分块，而非任意 token 计数。对于技术文档问答，在检索块中包含页码或章节锚点，以便模型准确引用来源。

对于文档工作，您的解析器和检索器与模型同等重要。

边缘部署

小模型在手机、笔记本电脑、机器人、IoT 网关、工厂设备、车辆、医疗设备、离线现场设备和浏览器应用上越来越有用。边缘不仅仅是工作站的缩小版。它有一套不同的约束条件。

边缘部署受限于低内存、低功耗、热限制、间歇性连接、隐私要求、实时延迟、小上下文窗口和可预测的回退行为。在这些设备上，一个小的可靠模型胜过一个大而脆弱的模型。

实用的边缘设置通常使用 0.5B 到 4B 模型、激进的权重量化、极简的提示词、固定模式、工具辅助工作流、本地嵌入、缓存，以及不必要的聊天历史。

当连接中断时，一个能持续工作的本地模型比一个会失败的大模型更有价值。本地 AI 的未来不仅仅是巨大的工作站模型。它还包括在数据附近完成有用工作的小模型。

本地 LLM 操作手册

将此作为信任本地模型进行实际工作前的最后一道关卡。

选择与适配：选择适合任务需求的模型系列，阅读许可证，确认硬件要求，选择量化级别，并估算完整内存占用。不要只关注权重大小。包括 KV 缓存、运行时开销、批处理/并发以及安全余量。

加载与格式化：优先从可靠来源选择 safetensors 或 GGUF，避免不可信的 pickle 文件，验证分词器和对话模板，有目的地设置上下文长度，并根据任务选择解码参数。如果模板错误，评估结果将无效。

评估与操作：使用代表性提示进行测试，测量首 token 时间和解码速度，跟踪峰值内存，在添加 RAG 之前评估检索，在添加 Agent 之前对工具进行沙盒测试，只有简单方法失败后才进行微调。

为所有重要内容进行版本控制：模型、量化、运行时、提示词、对话模板、适配器、嵌入模型、重排序器、评估集和硬件配置。只有在能够重现运行结果时，本地系统才更容易控制。

微调

微调通过在额外数据上训练来改变模型行为。对于本地用户，最重要的方法是 LoRA 和 QLoRA。

LoRA 冻结基础模型，并训练小的低秩适配器权重。这减少了可训练参数，并让你能够维护多个轻量级适配器。QLoRA 在此基础上，通过冻结的 4 位量化模型微调 LoRA 适配器。

当你需要一致的写作风格、特定领域的输出格式、重复的分类或提取行为、函数调用格式的可靠性、专门的助手角色、RAG 无法解决的领域适配，或者小模型在狭窄任务上性能不佳时，可以进行微调。

但不要首先进行微调。尝试以下顺序：正确的对话模板、更好的提示词、更好的模型、更好的解码、RAG、重排序、少样本示例，然后才是微调。

大多数看起来像是“模型不理解我的领域”的问题，其实都是“我的提示词模糊”、“我的模板错误”或“我的检索坏了”。

一个好的微调计划包括：干净的数据、训练/验证/测试拆分、基线评估、清晰的目标行为、安全审查、过拟合检查、回归评估、适配器版本控制、许可证审查和回滚计划。

开放权重不等于开源

在 2026 年，“开放模型”这个说法经常被随意使用。你应该区分开放权重、源码可用、开源和本地兼容。

开放权重通常意味着你可以下载权重。但这并不自动意味着你可以商业使用模型、自由修改、在其输出上训练、任意规模部署，或者忽略署名要求。

源码可用意味着代码或权重是可见的。但不一定意味着许可证是开源的。

开源 AI 模型是一个更强的声明。OSI 的开源 AI 定义将 AI 系统视为包括架构、参数/权重、推理代码，以及用于导出参数的足够数据信息和代码。这比“权重在 Hugging Face 上”的门槛高得多。

一些许可证看似宽松，但包含限制：禁止竞争用途、禁止在输出上训练、禁止超过一定规模的部署、地域排除、署名要求、专利条款，或对衍生品的类似 Copyleft 的义务。

规则：在商业使用任何模型之前阅读模型卡片和许可证。一个模型可能很优秀、可下载、可本地运行，但仍然不适合你的法律或部署限制。

词汇表

模型与微调术语

• 活跃参数：在 MoE 模型中，只有部分参数用于给定的 token。一个模型可能有数千亿总参数，但每个 token 的活跃参数要少得多。
• 适配器：添加到基础模型上的小型可训练模块，通常通过 LoRA 实现。
• 基础模型：未专门针对对话或指令跟随进行微调的预训练模型。
• 微调：通过额外训练改变模型行为以适应目标领域或输出风格。
• 指令模型：经过微调以遵循指令的模型。
• LoRA / QLoRA：使用低秩适配器的高效微调方法，QLoRA 通过量化基础模型进行训练。
• MoE：混合专家。一种稀疏架构，其中每个 token 仅激活选定的专家子网络。
• 权重 / 参数：模型内部学习到的数值。

推理机制

• BOS / EOS：序列开头和序列结尾 token。
• 对话模板：用于表示系统、用户、助手和工具消息的格式化方式。
• 上下文窗口：模型一次性可以处理的最大 token 数量。
• 解码：模型逐个生成新 token 的阶段。
• DFlash：2026 年的一种推测解码方法，使用块扩散进行并行草稿。
• DDTree / DTree：一种推测解码方法，从块扩散分布构建草稿树并高效验证。
• GQA / MQA：减少 KV 缓存大小并提高推理效率的注意力变体。
• 推理：运行模型以产生输出。
• KV 缓存：存储先前 token 的键/值注意力状态。
• 预填充：模型在生成之前处理输入提示的阶段。
• RoPE：旋转位置嵌入，现代 LLM 中常见的位置编码方法。
• 推测解码：一种加速技术，其中更便宜的草稿模型提出 token，目标模型验证它们。
• 分词器：将文本转换为 token ID 和反向转换的组件。
• Top-p / Top-k / 温度：用于 token 生成的采样控制。

检索、文件与服务

• AWQ：激活感知权重量化。
• 嵌入模型：将文本转换为向量以用于搜索/检索的模型。
• FP8 KV 缓存：某些运行时支持的一种实用的 8 位 KV 缓存压缩模式。
• GGUF：llama.cpp 广泛使用的模型文件格式。
• PagedAttention：vLLM 风格服务使用的一种 KV 缓存内存管理技术。
• 量化：降低数值精度以节省内存并提高效率。
• RAG：检索增强生成。检索相关外部上下文并将其提供给模型。
• 重排序器：根据相关性重新排序检索到的段落的模型。
• Safetensors：一种更安全的张量序列化格式，避免了基于 pickle 的执行风险。

最后的话

本地 LLM 生态系统包括紧凑的边缘模型、强大的 7B 到 32B 消费级模型、大型 MoE 开放权重系统、多模态模型、长上下文模型、本地推理模型、成熟的推理运行时以及日益强大的私有服务栈。

但基本原则没有变：模型一次预测一个 token，token 不是单词，权重不是整个模型，对话模板很重要，KV 缓存是隐藏的内存开销，量化是权衡，长上下文不是免费的，RAG 质量取决于检索，微调需要评估，本地隐私仍然需要安全纪律。

你不需要神话来运行好本地模型。你需要知道什么能装进内存，模型需要什么模板，运行时如何运行，以及你的评估是否匹配你关心的实际工作。

本地 LLM 主要是内存计算加格式加评估。把这些做对，栈的其余部分就会变得容易推理得多。

下次再见。

——Ahmad