本地部署大模型选型指南：别再盯着参数和排行榜

在自己的机器上跑大语言模型有着显而易见的吸引力：数据不出本地、没有按 token 计费的账单、还能离线工作。但大多数人的选型从一开始就走错了方向——他们从参数量或某个排行榜开始挑模型。

问题在于，一个擅长代码补全的模型，用来总结长文档可能表现糟糕；而一个在纸面上「装得下」的模型，往往对话一长就直接爆内存。真正可靠的做法不是看谁的分数高，而是用一套结构化的流程把需求、硬件和模型匹配起来。

第一步：从任务出发，而不是从模型出发

在对比模型之前，先定义清楚你到底要它做什么。四个问题基本能圈定范围：

隐私：数据到底能不能离开本机？
延迟：你需要交互式的即时响应，还是这是一个批处理任务？
质量：哪种错误会让结果彻底失去价值？
模态：只处理文本，还是也要处理图像、音频和文件？

不同场景需要衡量的指标也完全不同。原文给出了一张清晰的对照表：

场景	优先级	衡量什么
聊天与写作	感知延迟	首个 token 时间、一致性
长文档处理	可用上下文	细节检索与引用准确性
编程	正确性	通过的测试数、无谓的改动
批处理	吞吐量	每秒 token 数、能耗成本

本地大模型选型流程

把任务和衡量标准想清楚，后面的每一步才有判断依据。否则你只是在用别人的基准测试替自己做决定。

第二步：预算内存，并留足余量

可用内存（RAM 或 VRAM，取决于你怎么跑模型）通常是真正的瓶颈。最常见的错误，是把模型文件的大小当成全部的内存开销。

实际上，上下文、注意力缓存和运行时本身都需要额外空间，操作系统也要占用一部分。换句话说，一个 8GB 的模型文件绝不意味着 8GB 内存就够用。

合理的规划顺序是：先定义输入和质量要求，设定一个真实的内存预算，再选择能装进这个预算的尺寸和格式，最后用你自己的用例去测试。关键原则是——不要卡着上限规划，一定要给系统留出余量。否则对话稍微长一点，就会触发内存溢出或疯狂的交换，体验直接崩溃。

第三步：量化是权衡，不是免费的捷径

降低数值精度（量化）能让模型更小，往往也能加速推理。但很多人误以为这是「纯赚」的操作，实际上量化对质量的影响并不均匀。

两个量化后体积相同的模型，在你的具体任务上可能表现差异巨大。有的量化等级在数学推理上几乎无损，却在长文本一致性上明显退化；反之亦然。

一个简单可行的规则：用相同的问题和相同的设置，至少对比两个量化等级。更重要的是把输出结果保存下来，这样你可以逐条比对真实差异，而不是凭「感觉好像还行」做决定。印象会骗人，存档的输出不会。

量化的本质是用低位整数替代高精度浮点数来表示模型权重。常见的精度等级从 FP16（16位浮点）到 Q8、Q5、Q4，甚至 Q2，位数越低，文件越小、推理越快，但信息损失也越多。目前本地部署中最流行的格式是 GGUF（由 llama.cpp 引入），它将量化信息和模型元数据打包在一起，方便跨平台使用。同一个基础模型通常会提供多个量化版本，例如 Q4_K_M 和 Q5_K_S 中的字母后缀代表不同的量化策略——K 系列使用混合精度，对关键层保留更高精度，因此在同等体积下通常优于早期的均匀量化方案。对于大多数用户，Q4_K_M 是在质量与体积之间较为平衡的起点，但"较为平衡"本身就说明它是一个均值，具体任务上的表现仍需实测验证。

第四步：最大上下文窗口不等于可用上下文

厂商宣传的上下文上限，描述的是模型「能接受」多少输入，它并不告诉你模型能否准确使用这全部输入，也不告诉你这些输入能否塞进你的内存。

一个容易被忽视的事实：注意力缓存会随着对话变长而增长，甚至可能成为内存的最大消耗者，即使模型权重已经加载完毕。宣传的 128K 上下文，在你的硬件上也许根本跑不满。

原文建议从能解决任务的最小上下文开始。对于长文档，要对比两种方案：把整个文件丢进去，还是只检索相关段落。然后系统性地测量：

内存预算：分别记录权重、缓存、运行时和系统余量。
检索效果：检查返回的段落、重叠度和引用质量。
退化点：把关键事实分别放在输入的开头、中间和结尾，检测注意力在哪里开始「掉链子」。
延迟：在真实长度下分别测量预填充（prefill）和生成时间。

记住一句话：一个流畅的回答，并不能证明模型真的正确使用了全部输入。

注意力缓存通常以 KV Cache（键值缓存）的形式存在。Transformer 架构在处理每个 token 时，需要保存该 token 对应的 Key 和 Value 向量，以便后续 token 在计算注意力时复用，而不必重新计算整个历史序列。这意味着对话越长，KV Cache 占用的内存就越大，且增长是线性甚至超线性的。以一个使用 Q4 量化的 7B 模型为例，权重本身约占 4GB，但在 32K 上下文满载时，KV Cache 可能额外消耗 2-4GB，直接压缩了可用于权重和系统的空间。预填充（prefill）阶段指模型一次性处理输入 prompt 的过程，这一阶段的计算量与输入长度成正比，因此长文档场景下首个 token 的等待时间（TTFT）会显著拉长，这与交互式对话的体验预期是直接冲突的。

第五步：核查许可证、来源与安全性

在把一个权重文件集成进项目之前，务必阅读该特定模型及其变体的许可证。「开源」这个词有很大的模糊空间——能拿到权重，不代表你有同样的权利去做商用、再分发、修改或训练衍生模型。保留一份记录：仓库地址、版本号、以及你核查过的许可证文本。

更进一步，应该把模型、提示词模板和下载文件都当作外部依赖来对待。验证它们的来源，警惕那些可能执行代码的文件格式，限制进程能访问的范围，并且在早期测试阶段不要把拥有宽泛权限的工具连接进去。本地运行确实让你对数据有更强的掌控，但它并不能消除生成内容的风险，也不能消除供应链的风险。

一份最小化的安装前记录应包含：文件标识与哈希值、许可证、作者或仓库、格式、兼容的运行时、下载日期、进程权限，以及如何卸载它。

第六步：跑一个可复现的测试

直觉不是评估。要让测试真正可信，必须让它可重复：

冻结测试集：对每一个变体都使用同样的约 20 个真实任务。
记录环境：标注硬件、运行时版本、上下文大小和参数。
盲评打分：评分时隐藏模型名称，避免先入为主的偏见。

如果你用 Ollama，可以在运行前先查看模型的详细信息：

ollama show model-name
ollama run model-name

如果需要更底层的控制以及对 GGUF 格式的支持，llama.cpp 是通常的参考项目。

GGUF 是目前本地部署生态中事实上的标准权重格式，由 llama.cpp 项目定义并维护。它将模型架构描述、量化参数、词表和权重数据统一存储在单个文件中，无需额外的配置文件即可加载。Ollama 在 GGUF 之上提供了更高层的抽象：它在后台管理 llama.cpp 运行时，通过统一的 REST API 暴露模型能力，并负责模型的下载、版本管理和进程生命周期。ollama show 命令可以在不实际运行模型的情况下查看其量化等级、上下文长度、参数量等元数据，是在正式测试前快速核实模型配置是否与预期一致的实用手段。如果需要更细粒度的控制——例如调整 KV Cache 精度、绑定特定 GPU 层数或测试不同的采样策略——直接使用 llama.cpp 的命令行工具能提供 Ollama 默认不暴露的参数。

把这一切串起来

最好的本地模型，是那个能在你的内存预算内解决你的任务、使用一个你能接受的许可证、并且在一个你能重复运行的测试中稳定表现的模型。

参数量和排行榜排名只是这个决策的输入，而不是决策本身。与其纠结某个模型在公开榜单上领先几分，不如老老实实用自己的 20 个真实任务跑一遍——答案往往和榜单给的不一样。