如何选择适合自己的本地 LLM

0X00 首先来看 Qwen 3.6

如果你现在打算在本地部署一个 Qwen 3.6，打开 Hugging Face 搜索 Qwen 3.6 至少会看到下面这些模型，大概率会对这些“乱七八糟”的名字感到迷茫。你说你对这些名字门儿清？那你大概率并不能从这篇博客中获得什么有价值的知识/信息了。 🤔

好了，我假设你看到这些东西是迷茫的。要不然这篇文章没法写了

1Qwen/Qwen3.6-35B-A3B
2Qwen/Qwen3.6-35B-A3B-FP8
3Qwen/Qwen3.6-27B
4Qwen/Qwen3.6-27B-FP8
5RDson/Qwen3.6-27B-MTP-Q4_K_M-GGUF
6HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive
7nvidia/Qwen3.6-35B-A3B-NVFP4
8unsloth/Qwen3.6-35B-A3B-MTP-GGUF
9unsloth/Qwen3.6-27B-GGUF

整体的命名方式和 GitHub 仓库是一样的，作者名和仓库名用 / 分开，这里是作者名和模型名用 / 分开。所以可以看到前 4 条是 Qwen 名下的模型，自然就是官方的了，其他几个就是个人或者其他组织搞的第三方模型了。真正麻烦一些的是后面这些东西。接下来就尽我所能逐一拆解这些相对来说常见一些的组成部分，搞清楚这个逻辑之后对于后面选模型会大有裨益吧。

0X01 参数量和激活参数量

参数量是一个模型最好理解的参数，在通俗的理解下“大就是好，好就是大”。但实际上也并非如此，其中最大的变量还得看是你模型本身，所以接下来的讨论全都基于一个基本前提：同一家同一个同一代模型。现在这里公布一组数据，让大家对参数量有一个基本概念：当前业界顶尖的 Claude Opus 4.8 和 GPT-5.5 模型，通常认为它们的参数量已经超过了 1T，猜测在 1T 到 10T 的范围内（毕竟没有开源也没有官方公布，数据是业内人士估算/猜测的）；开源界明星 DeepSeek V4 Pro 的总参数量是 862B；个人计算机上能跑的模型一般是在 8B~32B 之间；Google 前段时间开源的可以跑在手机上的 Gemma 提供了最小到 0.4B 的版本。

这里的 B 指的是 Billion 十亿，T 指的是 Trillion 万亿，也就是 1000 Billion

细心的你可能已经发现了，模型名字上不仅有 27B 和 32B 这种，还有 A3B 这种参数。这种参数指的是“激活参数量”，要理解的话需要先区分一下现在比较常见的模型类型：稠密型和MoE（混合专家）型。其中纯写 27B 的指的是稠密模型，意味着每次对话模型都会调动全身能力（27B的参数）来回答问题，而 35B-A3B 指的是总参数量虽然有 35B 但每次只激活 3B。

这个表里能清晰看出 Dense( 稠密) 和 MoE(混合专家) 之间的区别。

细心的你可能又发现了一个问题：为什么 A3B 的激活参数量命名只有 3B，和 27B 比起来效果只是“略差”？可以这么理解这个问题：参加高考的你，如果是 Dense 版本，在解算数学物理压轴大题的时候脑子里还想着赤壁赋和长歌行，虽然你脑子在飞速旋转，但实际上多出来的这些知识很有可能是用不上的。但如果是 MoE 版本，你就只调用有关数学物理和逻辑学相关的知识，虽然裁减了一些，但不是什么大问题。

0X02 各种常见的量化方式

如果你的设备性能有限（尤其是显存有限），还想跑大一些的模型，那么量化是不可避免的。量化可以理解成是对模型的有损压缩，不同的量化方法就像是不同的压缩算法。经过量化的模型对设备性能参数的需求会降低，但模型的效果也会由于“有损压缩”而降低。

首先来说我们最常见的两种量化：INT 和 FP 量化。前者是整型量化，后者是浮点量化，在量化位数相同的情况下浮点量化的效果要优于整型量化（FP4 > INT4）；在同一个类型的量化方法下量化位数越大效果越好（INT8 > INT6 > INT4）；量化方法和位数都不同时，基本不具备直接可比性。

我们日常情况能接触到的 INT 量化几乎都是 Q 系列量化，比如常见的 Q4 和 Q6。Q 量化是 INT 量化的一种常见实现。

另外需要注意的是，FP4 量化需要 Blackwell 级别或以上的显卡（也就是家用的 RTX50 系）。

Q 量化还可能会出现上面 Q4_K_M 的形式，其中 K 意味着 k-quants 量化算法（混合精度处理），通常来说比普通的纯 Q4 好一些；M 则是混合精度挡位，分为 S/M/L，其中 M 属于甜品挡。

0X03 其他优化方式

最开始提到的一堆模型里有一个带有 MTP 标签的，指的是 Multi-Token Prediction，是一种推理加速技术，可以一次预测多个 token，提升吐字速度，并发生成多个 token，再回头验证。使用 MTP 的优势是在生成结构化内容（比如代码）或者简单内容（比如日常对话）时，可以实现约 1.5~3 倍的 token 吐出速度的提升。但代价是针对非结构化或者创意类的内容时，由于要大量的“回头验证”，可能会导致效率不增反降。并且该方法也需要推理框架支持。

推理框架指的是 llama.cpp/vLLM/MLX 这些，其中大家在 Windows/Linux 上常用的 Ollama/LM Studio 都是 llama.cpp 框架，在 Mac 上常用的则是 MLX 。

0X04 模型的文件格式

常见的模型格式有 SafeTensors(.safetensors), PyTorch(.bin/.pt), MLX(.npz/mlx), GGUF(.gguf)。

• SafeTensors 是 Hugging Face 主推的形式 ✅
• PyTorch 是 SafeTensors 之前的格式，很少用了 ❌
• MLX 是苹果 M 芯片专用的格式，配合 MLX 框架使用 ⚠️
• GGUF 本地部署的标准格式，N卡和M芯片都能用 ✅

简单来说，如果要上生产环境跑在服务器上，就选 SafeTensors；如果是苹果的 M 芯片，最好用 MLX；如果是其他情况，就选 GGUF；如果你明确直到自己需要 PyTorch 格式那就用 PyTorch。

0X05 微调

模型还能进行微调，但是微调不是为了性能而是场景特化。这个没什么标准，基本上就是看模型名称里出现了哪些看起来像是微调信息的来自行判断。

1-Instruct   → 指令微调，能对话，日常用这个
2-Base       → 预训练基座，不能直接对话，给研究者用
3-Chat       → 同 Instruct，不同厂商的叫法
4-Coder      → 专门针对代码任务微调
5-Math       → 专门针对数学任务微调

0X06 选择模型的方法论

好了，模型名称里常见的组成部分都搞清楚了，现在整理一个模型选择的方法论。首先我们看一下一个模型运行起来之后我们关注的性能参数：

然后我们来看一下计算方式。通俗来说可以认为你想跑 32B 的不量化的稠密模型，就需要 64G 的显存。但我们本地部署的话多半是需要量化的。根据量化的基本算法，在运行 32B 模型的前提下可以得到下面这张表格

但是需要注意的一点，这个表里指的是运行这个模型需要的显存，要是真的开始继续对话就得考虑 KV Cache 和运行时的各种开销，所以如果你的显卡真的刚好有 16G 显存，运行 32B-Q4 其实还是吃力的。尤其是当你想拿来做些事情的时候又不得不考虑上下文，所以实际操作的时候还是要比表格里标注的所需显存再大一些才行。

最后我们再来看一下现在顶级的 M5 Max 和 RTX 5090 之间的性能参数。根据这个表我们可以得到一个结论：一个模型只要 5090 能跑得动，速度就会比 M5 Max 快很多；但 M5 Max 能跑很多 5090 跑不动的模型，或者支持更大的上下文。

0X07 最后

细心的你又双叒叕发现了，前面提到的模型名字里还有几个没提及含义的：Uncensored-HauhauCS-Aggressive，这些其实就不是标准命名方式了，中间的 HauhauCS 其实指的就是作者，前后两个词看不懂的就翻译一下吧，自然能明白了 :)