LLM 101：实用指南（2026 版）

从循环开始。文本变成 token。Token 穿过 Transformer。注意力机制决定哪些更早的 token 重要。运行时保留 KV 缓存，这样模型就不必每次都重新计算整段对话。然后模型选出下一个 token，再重复一遍。

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

一旦这个循环想通了，硬件和软件的选择就更容易推理了。VRAM、量化、上下文长度、聊天模板、解码、RAG、服务引擎和模型选择，全都源自同一套机制。

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

目标是先让本地 LLM 的机制变得直观，然后给你一条实用路径，通向硬件、运行时、服务，以及截至 2026 年 5 月 21 日的当前 LLM 研究。

重点

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

之后，它转向本地部署层面：本地究竟意味着什么、量化、显存计算、硬件分级、运行时选择、服务模式、许可证、模型选择、隐私、故障排查、基准测试、搭建路径，以及实际用例。

这个顺序很重要。你应当先理解为什么长提示词会占用内存，再去挑选 GPU。你应当先理解为什么聊天模板很重要，再去评判一个模型。你应当先理解为什么解码是串行的，再去关心每秒 token 数。

关于更深入的硬件与软件路径， 我有一套三部分系列，讲解自托管 LLM / 本地 AI：

前两篇讲解硬件容量与带宽的计算。第三篇讲解软件层，即如何把那套硬件转化为可用的推理。本文先为你打下模型侧的基础，待机制讲清楚后，再回头指向那些部署层面。

LLM 实际在做什么

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

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

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

f(theta, sequence) -> 下一个词元的概率分布

其中：

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

感知在这里很重要。漫长的预填充意味着第一个词出现之前有很长的停顿。缓慢的解码意味着答案流式输出得很慢。本地构建者常常痴迷于解码速度，因为那是用户能感受到的，但当你粘贴一份 1 万 token 的文档时，真正让人难受的是预填充时间。

词元

LLM 看到的并不是以单词形式呈现的原始文本。它们看到的是词元（token）：在内部以整数 ID 表示的小块文本。

一个词元可能是：

分词器（tokenizer）将文本映射为词元 ID，也将词元 ID 映射回文本。常见的分词器家族包括 BPE 风格分词器和 SentencePiece 风格分词器。不同的模型家族使用不同的分词器，这一点很重要。一份 4,000 词的文档在某个分词器中可能是 5,000 个词元，在另一个分词器中则可能是 7,500 个词元。

词表大小也很重要。词表更大的分词器可以把某些文本压缩成更少的词元，但它也会改变嵌入和输出投影的规模。这正是每秒词元数在不同模型家族之间无法完美比较的原因之一。

词元之所以重要，是因为它们决定了：

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

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

词元是工作量的单位。一旦你理解了这一点，长上下文就不再显得神奇，而开始看起来像一张你可以估算的账单。

实用练习： 试试我的分词器演示应用，实时查看文本如何被拆分为词元。

Transformer

大多数现代大语言模型都基于 Transformer 架构。大多数本地聊天大语言模型是仅解码器 Transformer：它们在预测下一个词元时，会回看之前的词元。

到这里为止的所有内容，包括词元、权重、配置和聊天模板，都是为底层真正的引擎所做的铺垫。Transformer 是搬运这些数字的骨架。

一个简化的 Transformer 层包含：

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

Transformer 回顾： 词元变成向量，注意力连接序列，MLP 重塑表示，RoPE 保持位置正确，最后的投影把最后一个隐藏状态变成下一个词元的 logits。

注意力机制

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

经典的 MHA（多头注意力）为多个头分别存储独立的键/值状态。这赋予了模型灵活性，但也使 KV 缓存变得庞大。

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

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

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

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

KV 缓存

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

没有 KV 缓存，生成会低效得令人发指。有了 KV 缓存，生成才变得可用，但缓存会占用与以下量成正比的内存：

tokens x layers x kv_heads x head_dim x precision 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 缓存量化与投机解码混为一谈。DFlash 和 DDTree（常被非正式简称为 DTree）通过草拟未来 token 并对其进行验证来攻击解码延迟。它们可以提升速度，但并不会抹去 KV 缓存的内存账单。

这就是为什么一个模型可以在空提示下装得下，但当你加载一篇长文档时却会崩溃。权重装得下。工作记忆装不下。

预填充与解码

LLM 推理有两种不同的性能模式：预填充和解码。

预填充处理你提供给模型的提示词。如果你粘贴一份 20,000 token 的文档，模型必须先处理完这 20,000 个 token，才能产出第一个回答 token。预填充相对而言可以并行化，因此 GPU 能高效处理，但它依然可能开销不菲。

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

解码则一次生成一个新 token。每个生成的 token 都依赖于此前的序列，因此解码的串行程度要高得多。流式输出的打字机效果正来源于此，而这一阶段通常决定了一个模型给人的感觉是快还是慢。

长提示词拖累预填充。长回答拖累解码。长对话则两者都拖累，因为 KV 缓存会不断增长。

在一次聊天会话中，每一轮都会往缓存里追加内容。如果你让一段对话跑到 16K token，那么每生成一个新 token，你都要为全部 16K token 付出内存代价。这就是为什么那些保留无限历史记录的聊天界面最终会变慢甚至崩溃。

解码

模型输出 logits 之后，其实还什么都没写出来。它只是为每一个可能的下一个 token 打了分。解码就是把那些分数变成一个实际 token、将该 token 追加到上下文、然后重复这一循环的策略。

运行时（即推理引擎）可以用多种方式选择 token。它可以每次都挑概率最高的 token；可以从收窄后的高概率候选集中采样；可以对重复施加惩罚；可以在分隔符处停止；也可以使用固定随机种子，让同一个提示词每次表现一致。

这些选择不会改变模型权重，但会改变模型的语气、确定性、创造力、风险特征以及陷入循环的倾向。

几个关键旋钮回答三个实际问题：

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

贪心解码并不总是更准确，它往往很脆弱。贪心解码器可能卡在循环里，或给出泛泛的答案，因为它从不探索替代选项。做评测时，使用确定性设置；做头脑风暴时，让模型自由发挥。

模型包包含什么

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

权重是最大的文件，但它们并不是整个模型。如果分词器、配置或聊天模板有误，相同的权重也可能表现得像坏了一样。

模型包这一节告诉你哪些东西必须一起传递。下一节解释为什么聊天模板是人们最常弄坏的部分。

聊天模板

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

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

另一个模型可能期望：

[BOS] [INST] Explain KV cache. [/INST]

还有的模型可能使用 ChatML 风格的标记。有的可能需要特殊的推理 token。有的可能需要工具调用的 XML 或 JSON 包装。

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

最佳实践：

如果你在构建一个允许用户切换模型的应用，你也需要支持模板切换。硬编码一种模板格式，然后加载一个期望另一种格式的模型，是本地模型评测出问题的常见原因。

把模板当作 API 契约来对待。如果搞错了，你测试的就不是你以为的那个模型。

模型类型

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

对大多数用户来说，默认的起点应当是一个较新的指令/对话调优模型，其规模要能轻松放进内存。

除非你清楚原因，否则不要从基础模型开始。基础模型会续写你的提示，而不是回答它。它们对研究人员、微调者和构建自定义流水线的人有用。对其他所有人来说，它们只会让人抓狂。

如果你问一个基础模型法国的首都是哪里？，它可能会接着写那巴黎的人口是多少？，而不是回答巴黎。

实际的分野很简单：

“本地”的真正含义

本地 LLM 是指权重和推理运行时都由你掌控的模型。你决定运行哪个模型、如何运行、它能接触哪些数据，以及输出结果如何处理。

这种自由伴随着代价。你现在就是运维团队。下载、更新、兼容性、内存限制和安全，全都得你来管。出了问题，没有工单可提。只有你、日志和文档。

本地可以指：

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

当你需要隐私、低延迟、自定义行为、离线运行或大规模成本控制时，这种取舍是值得的。当你需要绝对最好的模型质量，却没有与之匹配的硬件时，就不值得。那种情况下，托管 API 才是正确的工具。

当你理解下面这个等式时，本地 LLM 才是切实可行的：

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

其余都是细节。而细节很重要。

量化

量化以更低的精度存储权重，从而减少内存占用，有时还能提升吞吐量。

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

权重量化与 KV 缓存量化不是一回事。权重量化缩小的是模型本身，KV 缓存量化缩小的是运行时上下文的内存占用。

对于 KV 缓存，把 FP16/BF16 视为干净的基线，把 FP8/INT8 视为本地实用的压缩下限。低于 8 位则研究性质浓厚且对工作负载敏感，只有在用你的实际提示词测过质量之后才使用。

量化带来的失效最先出现在数学、多步推理、代码正确性、工具调用的可靠性、JSON/schema 遵循、细微指令遵循以及长上下文检索上。

更高精度的较小模型，可以胜过被压到位数过少的较大模型。不要迷信参数量。在推理任务上，Q6 的 7B 模型可以胜过 Q2 的 13B 模型，同时占用更少内存、运行更快。

文件格式与加载安全

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 checkpoint。TensorRT-LLM 意味着 ONNX 或优化后的引擎。先选运行时，再去找对应格式的模型。

实际部署模式有三种。

单用户本地指的是供一个人使用的桌面应用、CLI 工具栈或命令行服务器。Harbor、LM Studio、llama.cpp server、ExLlama/TabbyAPI，以及小型 Transformers 脚本都属于这一类。目标就是快速迭代：比较行为、速度、内存占用和提示词格式，而不用搭建一套运维平台。

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

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

在生产规模下，我能加载模型吗？ 是简单的问题。难的问题是我能在真实流量下可靠地服务它吗？

本地模型的显存计算

主要有三类内存消耗者：

粗略的权重内存公式是：

weight_memory ~= parameters x bytes_per_parameter

有用的近似值：

然后再加上：

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

一个现实的估算看起来像：

total_memory = quantized_weightsKV_cache_for_context
runtime_overhead
batch_or_concurrency_overhead
safety_margin

陷阱就在这里：一个 Q4 量化的 13B 模型在 8K 上下文下可能轻松装下，到了 32K 却会失败，因为 KV 缓存翻了两番。权重没变，变的是上下文。

留出 10% 到 20% 的余量。把显存占用跑到 99% 就是在自找内存不足错误和碎片化故障。

实践中的硬件档位

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

对 2026 年大多数认真的本地用户来说，16 GB 是舒适的最低 GPU 档位，24 GB 是性价比最高的发烧友档位，而 48 GB 以上才是更强的本地世界展开的地方。

性能取决于内存带宽、GPU 浮点算力、显存容量、KV 缓存大小、注意力实现、量化、批大小、提示长度、生成长度以及运行时的成熟度。

解码往往是受内存带宽限制的：GPU 反复流式读取权重，而每字节所做的计算相对很少。预填充则更受算力限制，因为它可以并行处理提示。这就是为什么两块显存容量相同的显卡，如果其中一块内存带宽高得多，token 速度会截然不同。

最痛苦的本地配置，是模型几乎装得下、却把部分层溢出到 CPU 的那种。它技术上或许能跑，但 token 速度可能崩掉。CPU 卸载用于实验尚可，但它不是一种性能策略。

选择一款合适的模型

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

从一款较新的 instruct/chat 模型入手，让它在你能实际需要的上下文长度下能舒适运行。如果你的显存或统一内存是 8 GB 到 12 GB，从小规模起步。如果是 16 GB 到 24 GB，先测试 7B 到 14B 级别的模型。如果你有 48 GB 或更多，更大的稠密模型和 MoE 模型就变得可行了。

在你对某个 checkpoint 一见钟情之前，先用这道内存门槛把把关：

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

然后让候选模型跑同一组 20 到 50 条提示词。要包含你的真实任务：代码编辑、文档问答、JSON 输出、摘要、工具调用、长上下文，或者任何你实际需要的东西。衡量回答质量、延迟、内存占用、模板可靠性以及失败模式。

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

排行榜适合用来发现模型。它们不能替代你自己的评测。你的工作负载才是真正重要的基准。

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

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

对于私有文档助手，选择一款强大的指令模型、一个本地嵌入模型、一个重排序器、一条 RAG 流水线、引用强制机制，以及中到长的上下文。不要指望把一份 200 页的 PDF 直接丢进去就能了事。

对于推理配置，选择一款经过推理调优的模型，预留额外的 token 预算，使用低到中等温度，加入验证环节，并借助工具处理数学、代码或搜索。推理模型会消耗更多 token。请相应地做好预算。

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

什么决定了速度

每秒 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 系统、多头潜在注意力（Multi-head Latent Attention）、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 对阵其他所有模型。你选择的是一整个生态：权重、许可证、分词器、模板、量化、运行时支持、服务路径、社区工具以及故障模式。

Qwen 27B 稠密模型

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

在运行时为编码、智能体或多语言覆盖正确配置的前提下，Qwen 是 2 块 RTX 3090 配置的强力默认选择。

推理研究

2026 年的前沿不只是模型质量，还包括推理效率。PagedAttention 针对服务中的 KV 缓存内存浪费。FP8 KV 缓存如今已是 vLLM 等系统中实用的运行时特性。DFlash 和 DDTree 探索了使用块扩散草稿模型和草稿树的推测解码。NVFP4 在 NVIDIA 硬件上也值得关注，因为它改变了受支持技术栈的实际部署讨论。

其中一些已可用于生产，一些仍处于研究阶段，还有一些只有当你所用的运行时能干净利落地支持它时才有意义。不要把论文中的加速当作桌面应用里的一个勾选项。

失败模式与修复

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

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

胡言乱语或角色混淆： 聊天模板、分词器、BOS/EOS 词元、推理模式开关或工具 schema 有误。在归咎于模型质量之前，先核对模型卡和运行时模板。

首词元缓慢： 预填充开销大。缩短提示词、使用前缀缓存、改进检索、减少上下文，或使用更快的运行时。

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

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

JSON 或工具调用出错： 使用更低的温度、约束解码、更严格的 schema、更好的示例，以及针对工具使用调优过的模型。

循环重复： 降低 temperature 或 top-p，加入重复惩罚，检查停止 token，并确认模板没有让模型把自己的回答当成新的提示词。

从那些不起眼的检查做起。它们能解决的问题比换模型更多。

如何逐步扩展技术栈

入门：最简单实用的配置

使用 Harbor 或 LM Studio、一个较新的 4B 到 9B 指令模型、Q4 量化、8K 到 32K 上下文，以及内置的聊天界面。下载两三个同一规模级别的模型，用相同的提示词进行对比。

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

进阶：开发者配置

使用 llama.cpp 或 Transformers、GGUF 或 safetensors、兼容 OpenAI 的本地服务器、简单的 RAG 流水线，以及一个小型评估集。从真实的应用程序或脚本调用你的本地服务器，而不是只使用聊天界面。

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

高级：私有化部署配置

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

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

专家：自定义优化

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

目标： 用工程时间换取推理效率、更低的成本和更大规模下的更高质量。

隐私并非自动获得

本地 LLM 之所以能提升隐私性，是因为提示词和输出都可以留在你自己的硬件上。但本地并不自动意味着安全。

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

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

本地 AI 安全主要就是枯燥的运维纪律。这也是你避免下载一个来路不明的检查点、以 root 身份运行它，从而把本地 AI 变成本地沦陷的方式。

真正重要的基准测试

要对你实际会运行的整套技术栈进行基准测试。模型在 BF16 下的排行榜分数，并不等于你在本地 Q4 量化下的真实表现。

衡量质量、延迟、内存、可靠性和运营适配度：

构建一个小型评测集，包含 30 到 100 条有代表性的提示词。纳入预期答案或评分标准、延迟与内存测量、失败类别、RAG 专属的有据可依检查、相关的 JSON 合规性检查，以及对模糊任务的人工复核。

然后比较各个模型。不要让排行榜替你选择本地技术栈。

使用本地模型编程

编程是本地 LLM 最佳的应用场景之一，因为提示词往往包含私有代码、延迟很重要、迭代频繁、API 成本可能迅速增长，而且本地模型可以与编辑器、shell、grep、测试运行器和补丁工作流集成。

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

保持解码确定性或低温度。要求提供补丁，而不是模糊的建议。自动运行测试。保留一组由真实 bug 和任务组成的小型评估集，这样你就能判断新模型是否真的更好。

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

本地智能体需要护栏

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

工具使用改变了安全模型。一个产生幻觉的聊天机器人只是令人恼火。一个拥有文件系统访问权限的智能体可以删除东西。一个拥有浏览器访问权限的智能体可以泄露机密。一个拥有 shell 访问权限的智能体可以在你读完日志之前就损坏机器。

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

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

对于严肃的工具使用场景，把策略检查放在模型之外。

RAG 胜过巨型提示词

RAG 指的是检索增强生成（Retrieval-Augmented Generation）。与其把所有信息塞进提示词，不如从知识库中检索相关片段，只把这些片段交给模型。

一个良好的本地 RAG 系统通常包含文档摄取、解析、分块、嵌入、向量索引、检索、重排序、提示词构建、答案生成、依据校验和评估。每个阶段都是一个故障点。

糟糕的解析会把表格变成垃圾。糟糕的分块会把答案拆散在边界两侧。糟糕的检索会返回不相关的段落。糟糕的重排序会把正确答案埋没在第 20 位。再好的模型也无法可靠地根据它从未收到的证据来作答。

大多数糟糕的 RAG 系统之所以糟糕，原因不在 LLM。它们糟糕是因为分块、检索、重排序和评估。

分块策略是无声的杀手。固定大小且无重叠的分块会切断句子、丢失上下文。语义分块或配合父文档检索的层次化分块通常效果更好，但并没有放之四海而皆准的答案。你必须在自己实际的文档上评估分块大小、重叠量和切分规则。

好的重排序器能挽救平庸的检索。但没有任何重排序器能修复在摄取阶段就丢失了答案的分块。

文档与知识工作

对于私有文档，本地 LLM 大放异彩：会议记录摘要、合同审查、技术文档问答、研究笔记综合、邮件起草、政策检索、内部支持助手以及合规工作流，都能从将源材料保留在拥有它的机器或组织附近中获益。

工作流简单却毫不宽容。仔细解析文档，保留页码和章节元数据，进行语义分块，使用嵌入和重排序器，要求引用，将答案与来源同一般推理分开，并评估引用的忠实度。

不要假设模型知道你的文档里有什么。它只知道你放进提示词或检索进上下文的内容。

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

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

边缘部署

小模型在手机、笔记本电脑、机器人、物联网网关、工厂设备、车辆、医疗设备、离线野外设备和浏览器应用中的用处越来越大。边缘设备并不只是工作站的缩小版。它有着一套不同的约束条件。

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

实际的边缘部署方案通常采用0.5B 到 4B 的模型、激进的权重量化、极短的提示词、固定模式、工具辅助的工作流、本地嵌入、缓存，以及不保留多余的对话历史。

当连接中断时，一个持续工作的本地模型比一个失败的大模型更有价值。本地 AI 的未来不只是庞大的工作站模型。它同样也是小模型在数据近旁完成有用的工作。

本地 LLM 运行手册

在真正信任本地模型用于实际工作之前，请以此作为最后一道关卡。

选型与适配： 选择适合任务的模型系列，阅读许可证，确认硬件要求，选择量化级别，并估算完整的内存开销。不要只停留在权重体积上。要把 KV 缓存、运行时开销、批处理/并发以及安全余量都算进去。

加载与格式化： 优先使用来自可信来源的 safetensors 或 GGUF，避免不受信任的基于 pickle 的文件，验证分词器和聊天模板，有意识地设置上下文长度，并根据任务选择解码参数。如果模板不对，评估就是无效的。

评估与运行： 用有代表性的提示词进行测试，测量首 token 时间和解码速度，跟踪峰值内存，在加入 RAG 之前先评估检索，在加入智能体之前先把工具放进沙箱，只有在更简单的方法失败后才进行微调。

为一切重要事项做好版本管理： 模型、量化、运行时、提示词、聊天模板、适配器、嵌入模型、重排序器、评估集以及硬件配置。只有当你能够复现自己运行过的配置时，本地系统才更容易掌控。

微调

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

LoRA 冻结基础模型，只训练小型低秩适配器权重。这减少了可训练参数，并让你可以维护多个轻量级适配器。QLoRA 在此基础上进一步扩展，通过一个冻结的 4 比特量化模型来微调 LoRA 适配器。

当你需要一致的写作风格、特定领域的输出格式、重复性的分类或抽取行为、工具调用格式的可靠性、专门的助手人设、RAG 无法解决的领域适配，或让小模型在狭窄任务上表现更好时，就该进行微调。

不要一上来就微调。按这个顺序尝试：正确的聊天模板、更好的提示词、更好的模型、更好的解码、RAG、重排序、少样本示例，然后才是微调。

大多数看起来像模型不理解我的领域的问题，实际上是我的提示词太模糊、我的模板错了，或者我的检索坏了。

一个好的微调方案包括干净的数据、训练/验证/测试划分、基线评估、明确的目标行为、安全审查、过拟合检查、回归评估、适配器版本管理、许可证审查，以及回滚方案。

开放权重不等于开源

2026 年，开放模型 这个说法常被滥用。你应当区分 开放权重、源码可见、开源 和 本地可运行。

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

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

开源 AI 模型是一个更强的主张。OSI 的《开源 AI 定义》认为，一个 AI 系统包括架构、参数/权重、推理代码，以及足以推导出这些参数的数据信息和代码。这比权重放在 Hugging Face 上的门槛要高得多。

有些许可证看起来宽松，却含有各种限制：禁止竞争性使用、禁止用输出训练、禁止超过一定规模部署、地域排除、署名要求、专利条款，或对衍生作品施加类似 copyleft 的义务。

规则：在将任何模型用于商业用途之前，先阅读模型卡和许可证。一个模型可能很出色、可下载、可在本地运行，却仍然不适合你的法律或部署约束。

术语表

模型与调优术语

推理机制

检索、文件与服务

结语

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

但基本面并未改变：模型一次预测一个 token，token 不是单词，权重不是整个模型，聊天模板很重要，KV 缓存是隐藏的内存账单，量化是一种权衡，长上下文并非免费，RAG 质量取决于检索，微调需要评估，而本地隐私仍然需要安全纪律。

你不需要神话来很好地运行本地模型。你需要知道什么能装进内存、模型期望哪种模板、运行时如何表现，以及你的评估是否匹配你在意的工作。

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

下次见。

-Ahmad