本地LLM Benchmark实战：从显存估算到量化选型全指南

在本地部署大模型，最常被问到的一个问题就是：“我的电脑配置到底能跑多大的模型？”这个问题看似简单，但真要回答清楚并不容易，尤其是当你不只想“能跑”，还想跑得流畅、输出质量还过得去的时候。很多同学一开始就直接把 14B、32B 甚至更大的模型拉下来，结果显存不够被 kill，换成 CPU 推理又慢到怀疑人生。反过来，也有人为了迁就低配置机器选了一个特别小的模型，结果生成内容质量肉眼可见地差，几乎没法用。之所以会出现这种“两头踩坑”的情况，根本原因是缺少一个系统化的 Benchmark 环节。换句话说，你需要先搞清楚自己的设备规格（device specs）能够承接什么样的模型参数规模、什么样的精度和量化方案，然后基于同一套标准去测量不同 LLM 在本地跑起来的延迟、吞吐和显存占用，最终才能得到一个可以复现的选型结论。

本文会把这套思路整理成一门可落地的教程，覆盖本地 LLM 评测的核心概念、硬件资源估算方法、常用的评测工具，以及完整可运行的测量脚本。无论是刚接触大模型的新手，还是想给团队做本地化部署方案的开发者，都可以照着本文搭一套属于自己的本地 LLM Benchmark 流程。文章涉及的内容包括 FP16、BF16、INT8、INT4 等精度与量化方案的实践对比，也包括 Ollama、llama.cpp、Transformers 等常见推理框架下的测量方式，以及一份可以直接保存成 Markdown 表格的结果记录方法。学习完本文，你至少能够回答“我这台设备，选哪个模型最合适”这个问题，并且能用数据而不是感觉来支撑结论。

1. 为什么本地 LLM 评测很重要

1.1 本地 LLM 和云端 API 的差异

现在使用 LLM 的方式大致分为两种：一种是调用云端 API，比如各种商业模型接口，另一种是在自己的电脑或服务器上运行开源模型。云端 API 的优势是配置要求低、模型版本新，但数据需要发送到第三方服务，存在隐私和合规风险，而且网络延迟和调用成本也会随业务量上升。本地 LLM 的最大价值则是“数据不出设备”，同时可以在断网环境工作，也不需要按 token 付费，对于团队内部知识库、个人助手、自动化脚本等场景，部署一次之后边际成本很低。

不过本地部署不是免费的午餐。没有云端庞大的算力集群，消费级显卡和普通 CPU 能跑动的模型规模和精度都受到很大限制。同样的一个模型，在云端可以流畅地开很大的上下文窗口，本地却可能因为显存不足频繁触发内存交换，导致速度骤降。更麻烦的是，不同框架对同一模型的优化效果不同，同样一个 7B 模型，用 Ollama 跑和用 Transformers 跑，每秒生成的 token 数可能相差很远。因此，在没有基准测试数据的情况下，很难判断当前卡顿到底是因为模型太大、精度过重，还是框架配置不对。而 Benchmark 正是解决这种不确定性的工具。

1.2 设备规格如何影响模型选择

设备规格里最核心的指标包括 CPU 核数、内存大小、GPU 型号和显存容量，其次是磁盘类型和读速。对大模型推理来说，GPU 显存是最稀缺的资源，因为它决定了模型权重和 KV Cache 能否一次性放进显存；如果放不下，就只能退到 CPU 内存，而 CPU 的算力远低于 GPU，推理速度会掉一到两个数量级。所以，选择模型的第一步不是看模型排行榜，而是先看自己的显存能装下什么精度的模型。

举个例子，一个 7B 参数的模型，如果以 FP16 精度存储，权重文件大约需要 14GB 显存，而一张 8GB 显存的显卡基本无法完整加载；但同一个模型量化成 INT4 后，权重仅需约 3.5GB，8GB 显存就可以运行，还能留出一部分空间给 KV Cache。如果你没有独立显卡，只靠 16GB 或 32GB 内存运行，虽然也能用 CPU 推理，但延迟会显著上升，通常只适合对速度要求不高的小模型。除此之外，内存带宽比内存大小更影响 CPU 推理速度，因为大模型推理是访存密集型任务，内存带宽越高，token 生成越快。所有这些因素都说明，脱离设备规格去讨论“什么模型最强”没有意义，必须先有一套明确的“设备规格 → 模型容量 → 推理性能”映射关系。

1.3 评测目标拆解：质量、速度、显存占用

本地 LLM 评测不能只看一个指标。通常至少需要从三个方面拆解：

• 输出质量：这决定了模型回答是否可用。常见的替代指标是 Perplexity（困惑度），简单理解就是模型对真实文本的不确定程度，数值越低一般表示模型拟合语言规律的能力越好。但 Perplexity 不能完全替代真实任务评测，实际业务中还需要用固定问题集进行人工评分。
• 推理速度：包括首 Token 延迟（TTFT）和生成速度（tokens/s）。前者影响“打字机”式的交互体验，后者影响批量处理任务的整体耗时。对于聊天助手，用户更容易感知首 Token 延迟；对于离线批处理，生成速度更重要。
• 硬件资源占用：包括 GPU 显存峰值、CPU 内存占用、显存和内存之间的交换情况。这部分数据决定了你的设备在长期运行时是否稳定，也决定了你是否还能同时开启其他应用。

把这套目标拆解清楚后，再来设计评测流程就会很有针对性。你不需要在一次测试中全部覆盖，但至少应该把这三个维度的数据记录下来，形成自己的设备基线数据库。

2. 评测前必须理解的关键概念

2.1 模型参数规模与显存估算

大模型名字里的 7B、13B、70B 指的是参数量，B 是 Billion，也就是十亿。参数量越大，模型通常知识越丰富、推理能力越强，但模型文件也越大，推理所需的资源也越多。为了估算显存，有一个非常粗的公式：模型权重占用 ≈ 参数量 × 每个参数占用的字节数。

如果使用 FP16（半精度浮点数）或 BF16（BFloat16），每个参数占 2 字节；FP32 占 4 字节；INT8 占 1 字节；INT4 占 0.5 字节。以 7B 模型为例：

• FP16/BF16：约 7 × 2 = 14GB；
• FP32：约 7 × 4 = 28GB；
• INT8：约 7GB；
• INT4：约 3.5GB。

这只是权重部分的估算，实际推理时还需要为 KV Cache、中间激活值、CUDA context 等预留额外显存。因此，如果你想加载一个 7B FP16 模型，理想情况下显卡最好有 16GB 显存，接近 14GB 则比较勉强。建议你在挑选模型时，把量化后的模型权重大小作为“下限”，再把显存打七折作为“预算”，两者之间留出 2GB 到 4GB 的缓冲空间，会更容易跑稳定。

2.2 精度与量化：FP16、BF16、INT8、INT4

PyTorch 和 Transformers 框架中常见的精度有 FP32、FP16、BF16，其中 FP16 和 BF16 都能把存储和计算量减半，但两者的数值范围不同。FP16 在训练和推理时容易出现数值溢出，BF16 保留了更大的指数范围，因此大模型训练和推理中更受青睐。不过对消费级显卡来说，FP16 的硬件支持往往更成熟，所以很多推理框架默认使用 FP16。

量化则是把浮点数权重从 FP16 压缩到 INT8 或 INT4 等低比特格式。INT8 量化通常可以让模型体积减小一半，推理速度提升明显，质量损失一般不大；INT4 量化进一步把模型体积压到原来的四分之一左右，但质量下降会更明显，非常小的模型可能会出现“胡言乱语”的情况。评测的本质就是在“文件更小、速度更快”和“生成质量更高”之间做权衡。

2.3 吞吐量与延迟、每秒 Token 数

推理速度通常有两种测量单位：延迟和吞吐。延迟指的是一次请求从发出到返回最后一个 token 的耗时，适合评估交互式场景；吞吐量则指单位时间内处理的 token 数，多见于并发批量场景。普通用户更关心的指标是每秒 token 数（tokens/s），它表示模型每秒能生成多少个 token。简单算一下，假如模型生成速度是 20 tokens/s，那么生成一段 200 token 的回答大约需要 10 秒，用户就会觉得比较流畅；如果只有 3 tokens/s，那基本就是“挤牙膏”式体验。

测量每秒 token 数时，要注意别把“输入预处理时间”和“模型生成时间”混在一起。更精确的做法是用解码生成时间来算，不包含 prefill 阶段。不过对于应用层评测，我们通常用整个请求的时间除以生成的 token 数，得到一个综合速度，也能反映实际体验。

2.4 Context Window 和解码策略的影响

上下文长度（Context Window）也是影响本地 LLM 表现的重要因素。当输入文本较长时，模型需要缓存更多的 KV Cache，显存占用会明显上升。不同模型的 KV Cache 计算方式不同，但总体规律是上下文越长，显存占用越大。有些模型支持 32K 甚至更长上下文，但实际在本地可能因为显存限制只能使用几 K。

解码策略同样会影响速度。比如使用num_beams大于 1 的 beam search 会比贪心解码慢很多，temperature和top_p主要影响随机性，对速度影响相对较小。在做 Benchmark 时，最好固定一个统一的解码参数，比如temperature=0或top_p=0.9、固定输出长度，否则不同参数的对比结果没有意义。

3. 环境准备与工具选择

3.1 硬件信息采集

在开始评测之前，先把设备规格摸清楚。Windows 上打开任务管理器切到“性能”即可看到 CPU、内存和 GPU 信息；Linux 下可以使用lscpu、free -h、nvidia-smi等命令。推荐把以下信息记录到一份文件中：

• 操作系统版本；
• CPU 型号、核心数；
• 内存总量；
• GPU 型号、显存容量；
• CUDA 版本或 PyTorch 版本。

如果你使用的是 NVIDIA 显卡，可以先运行：

nvidia-smi

输出里会显示 GPU 型号、驱动版本、显存总量和当前占用。这个信息不仅是选模型的基础，也是后续排查显存溢出问题的关键。

接下来可以用 Python 快速采集设备信息：

import platform import torch print("操作系统:", platform.platform()) print("PyTorch:", torch.__version__) print("CPU核数:", 平台可用CPU核心数) print("CPU核数:", torch.get_num_threads()) if torch.cuda.is_available(): print("GPU:", torch.cuda.get_device_name(0)) print("显存总量(GB):", round(torch.cuda.get_device_properties(0).total_memory / 1024**3, 2)) print("当前显存占用(GB):", round(torch.cuda.memory_allocated() / 1024**3, 2)) else: print("当前环境未检测到可用的NVIDIA GPU")

注意：如果你的机器没有 GPU，上述代码中torch.cuda.is_available()会返回 False，后续评测只能使用 CPU 模式。不同机器采集到的数据会不同，本文示例以常见 NVIDIA GPU + Linux 环境为主，思路同样适用于 Windows 和 Mac。

3.2 评测工具链：Ollama、llama.cpp、Transformers

本地 LLM 推理工具很多，比较常用的有 Ollama、llama.cpp、Hugging Face Transformers、vLLM 等。作为个人电脑和入门项目，优先推荐 Ollama 和 llama.cpp。

Ollama 的优点是安装简单、命令友好，自带模型下载和管理功能，适合快速跑通和日常交互。llama.cpp 则是一个专注于本地推理的 C/C++ 实现，支持多种量化格式，资源占用控制得非常好，同时还提供了 benchmark 和 perplexity 等工具。Transformers 是偏研究或微调场景的库，做实验更灵活，但对本地推理性能的优化不如前两者，适合需要自定义模型的场景。

建议你在同一台设备上安装一个推理框架，不要同时混着多个框架跑同一模型，避免占用冲突和结果混乱。如果只需要最快速的验证，Ollama 是最低门槛的选择；如果想要更全面的量化方案和性能数据，llama.cpp 更值得推荐。

3.3 示例环境与版本说明

本文后续示例使用的环境如下：

• 操作系统：Ubuntu 22.04 LTS（Windows 10/11 也可参考）；
• Python：3.10 或 3.11；
• PyTorch：2.1 及以上；
• Ollama：0.1.x 或更新版本；
• llama.cpp：master 最近版本；
• 硬件：NVIDIA 显卡 8GB 或 12GB 显存，内存 16GB 以上，CPU 8 核以上。

这些版本号只是为了方便说明，实际环境请根据自己的机器调整。大模型相关工具更新频繁，如果安装时遇到 API 变化，优先查阅官方文档，而不是强行套用旧命令。本文的重点是评测方法和思路，命令细节只需要按需替换即可。

4. 一套完整的本地 LLM Benchmark 流程

4.1 确定设备规格边界

评测的第一步是确定当前的资源上限。假设你的设备是 8GB 显存的 NVIDIA 显卡加 16GB 内存，那么根据前面提到的显存估算，你可以把候选模型控制在 3B 到 9B 参数范围，并优先考虑 INT8 或 INT4 量化版本。如果显存是 12GB，则可以考虑 7B 到 13B 的量化模型。按照这个思路先筛选出 2 到 3 个候选模型，不需要一开始就下载大量模型，减少等待时间。

同时，你还要确定本次评测的固定参数，包括：

• 输入提示词；
• 输出 token 数上限；
• 解码温度；
• 最大上下文长度。

例如固定输出 256 个 token，温度设为 0.7，上下文长度设为 2048。所有候选模型都在这套参数下进行测试。

4.2 下载合适精度的模型

以 Ollama 为例，你可以通过标签名下载不同量化等级的模型。对于同一系列模型，Ollama 会提供不同精度的 tag，常见的有q4_K_M、q8_0、fp16等。q 后面的数字表示比特位数，K_M 是较常用的混合量化方法。例如：

# 查看本机已下载的模型 ollama list # 下载 7B 模型的 4bit 量化版，具体标签以官方为准 ollama pull qwen2.5:7b-q4_K_M # 下载后运行 ollama run qwen2.5:7b-q4_K_M

这里需要提醒一下，Ollama 模型标签在不同版本中可能会有变化。如果你不确定某个 tag 是否存在，可以先执行ollama show <模型名>查看支持的格式，或者在模型库页面确认。

4.3 用 Ollama 快速测吞吐量

最简单的性能测试是直接调用 Ollama 的 HTTP API，记录一次生成请求的耗时和生成 token 数。下面是一个 Python 脚本，使用标准库urllib完成请求，避免额外依赖：

import json import time import urllib.request def benchmark_ollama(model, prompt, max_tokens=256): payload = { "model": model, "prompt": prompt, "stream": False, "options": { "num_predict": max_tokens, "temperature": 0.7 } } req = urllib.request.Request( "http://localhost:11434/api/generate", data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"} ) start = time.time() with urllib.request.urlopen(req, timeout=600) as resp: result = json.loads(resp.read().decode("utf-8")) elapsed = time.time() - start output_text = result.get("response", "") eval_count = result.get("eval_count", 0) tokens_per_second = eval_count / elapsed if elapsed > 0 else 0 print(f"模型: {model}") print(f"请求耗时: {elapsed:.2f}s") print(f"生成 token 数: {eval_count}") print(f"综合速度: {tokens_per_second:.2f} tokens/s") print(f"生成内容前 80 字: {output_text[:80].replace(chr(10), ' ')}") return { "model": model, "elapsed": elapsed, "eval_count": eval_count, "tokens_per_second": tokens_per_second } if __name__ == "__main__": benchmark_ollama("qwen2.5:7b-q4_K_M", "用一段话介绍贝叶斯定理。")

这段脚本会把加载状态、输入输出整体耗时都算进去，所以结果会比纯解码速度慢一些，但更接近用户实际感知。如果你想测量纯生成速度，可以看 Ollama API 返回里的eval_count和eval_duration字段，用eval_count / (eval_duration / 1e9)计算每秒 token 数。这里不展开，你可以根据需求调整。

4.4 用 llama.cpp 测量纯推理性能

如果你想获得更细粒度的性能数据，建议安装 llama.cpp，使用其自带的 benchmark 工具。一般步骤是：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build && cd build cmake .. cmake --build . --config Release -j $(nproc)

不同版本的 cmake 参数可能有差异，编译过程中如果缺少依赖，可以按提示安装对应开发包。编译完成后，会在build/bin目录下生成多个可执行文件，其中与评测相关的有llama-bench和llama-perplexity。

llama-bench会直接加载模型并运行多个测试，输出 prompt processing 速度和 generation 速度。执行示例：

./llama-bench -m /path/to/model.gguf -p 512 -n 128

这里-p表示输入 prompt 的 token 数，-n表示生成的 token 数。运行后可以看到类似下面的输出（具体数值依设备而定）：

| model | size | param | CPU | GPU | test | t/s |

llama-bench的好处是统一了 prompt 长度和生成长度，多模型对比时非常方便。但要注意，这个工具只测性能，不测质量，所以它应该和 Perplexity 工具一起使用。

4.5 用 Perplexity 评估模型质量

质量评测不一定要复杂的下游任务，Perplexity 是一个相对轻量的参考指标。在 llama.cpp 中，可以使用llama-perplexity工具：

./llama-perplexity -m /path/to/model.gguf -f /path/to/text.txt

-f参数指向一个纯文本文件，里面最好是领域内或者通用领域的长文本，比如新闻、维基百科段落等。程序会统计模型在该文本上的 Perplexity。数值越低，代表模型对文本的预测误差越小。不过 Perplexity 不是万能的，它不能直接反映“回答是否准确”，但可以用于快速筛掉质量离谱的极端量化模型。

对于更加贴近业务的质量评测，建议准备 10 到 20 个固定问题，让候选模型分别回答，然后人工打分。你可以使用下面的 Python 脚本，把同一个问题发给多个 Ollama 模型，并保存答案：

import json import urllib.request questions = [ "列举三种提高Python代码可读性的方法。", "解释一下数据库索引的原理和适用场景。", ] models = ["qwen2.5:7b-q4_K_M", "llama3.1:8b-q4_K_M"] def ask(model, question): payload = { "model": model, "prompt": question, "stream": False, "options": {"num_predict": 300} } req = urllib.request.Request( "http://localhost:11434/api/generate", data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"} ) with urllib.request.urlopen(req, timeout=300) as resp: result = json.loads(resp.read().decode("utf-8")) return result.get("response", "") for model in models: print("=" * 20) print("模型:", model) for idx, question in enumerate(questions, 1): print(f"问题{idx}: {question}") print("回答:", ask(model, question)) print()

跑完这组脚本后，你可以结合输出速度数据一起归档。例如速度很快但答案全是废话的模型，在业务中基本不可用；速度稍慢但回答准确的模型往往更值得部署。

4.6 记录并对比结果

评测数据必须记录成可对比的结构化格式，推荐使用 Markdown 表格或 CSV。下面是一个示例表，你可以保存为benchmark_result.md：

记录时尽量保证每次测试的 prompt 和参数一致。如果两次测试显存占用波动很大，检查是否有其他程序占用 GPU，建议测试前关闭浏览器和无关应用，保证数据干净。

完成多组测试后，你就能得到一张自己的模型选型表。这张表是以后换电脑、换显卡或者升级模型时的重要依据。

5. 评测结果示例与解读

这一节用一组示例数据说明如何解读结果。以下数据只是为了展示记录格式，并不是固定结论，实际结果一定要以自己设备为准。

假设我们在同一台设备上测试了三个模型：

从这个结果中可以看到，在 8GB 显存环境下，7B INT4 是性价比最高的选择，因为它在显存占用和速度之间取得了很好的平衡。如果设备显存提升到 12GB，则可以尝试 7B INT8 甚至 13B INT4 的模型，质量会有进一步提升。反之，如果只有 CPU 环境，3B 模型可能在速度上仍然不理想，需要进一步降低上下文长度或使用更小的 1B 级别模型。

解读数据时，不能只盯着 tokens/s 看。如果某个模型的速度特别快，但主观回答质量很低，那它可能只适合做关键词生成等简单任务，不适合做对话助手。最好的做法是把速度数据和质量评分放在同一张表里，根据业务需求分配权重。交互式产品更看重速度和首 Token 延迟，离线任务更看重吞吐和质量。

6. 常见问题与排查思路

在实际评测过程中，最常见的几类问题如下：

针对“进程被杀死”这种情况，优先建议把模型换成更小参数的版本，并在启动命令中限制上下文长度。例如 Ollama 中可以通过环境变量OLLAMA_CONTEXT_LENGTH调低最大上下文，或者在使用 API 时传入num_ctx选项。不要一开始就把上下文设置成 32K，这在消费级显卡上几乎不可能完成。

7. 最佳实践与工程建议

7.1 建立自己的基准数据集

评测如果没有统一数据集，就像考试没有统一考卷。建议你维护一个固定的问题集，包含 10 到 20 个问题，覆盖业务常见场景，比如“总结一段文章”“写一封请假邮件”“解释一个技术概念”等。每次评测都用同一份问题集，这样模型之间的对比才有可信度。

7.2 先测小模型，再逐步升级

不要一上来就下载最大模型。建议先在目标设备上跑通 1B 或 3B 的小模型，记录基础性能数据，确认推理链路没有问题后，再逐步测试更大的模型。这样做可以快速暴露显存不足、依赖缺失等问题，避免浪费大量时间等待大模型下载和加载。

7.3 优先考虑量化模型的平衡点

量化精度不是越高越好，也不是越低越好。建议每个候选模型至少对比 INT4 和 INT8 两个版本，关注显存占用和生成质量的差异。如果两者速度差距不大但质量差异明显，优先选择高精度版本；如果高精度版本触碰到硬件瓶颈，则退回低量化版本。

7.4 注意隐私与安全边界

本地运行 LLM 的一个主要优势是数据安全，但也要注意模型文件本身可能携带未知风险。不要下载来源不明的模型文件，尽量使用官方模型库或可信渠道。如果要在生产环境提供服务，建议将模型服务放到独立进程或容器中，并设置访问认证，避免 11434 等端口被公网直接暴露。

7.5 监控运行时资源

长期运行本地 LLM 时，建议使用nvidia-smi的循环监控命令，或者接入简单的监控脚本：

watch -n 1 nvidia-smi

这样可以看到显存、温度、功耗的实时变化。如果发现 GPU 温度过高，需要检查散热和功耗限制；如果显存一直处于接近满载的状态，建议降低上下文长度或切换更小模型，避免服务不稳定。

8. 总结与下一步

本地 LLM Benchmark 的核心不只是测一个跑分，而是建立一套“硬件资源与模型能力”之间的可量化关系。通过本文的学习，你已经了解了模型参数量、精度量化、显存估算、推理速度和 Perplexity 等基本概念，也掌握了 Ollama、llama.cpp、Transformers 等工具下的常见评测方法。接下来要做的，就是去自己的设备上采集一份真实的硬件报告，选定几个候选模型，然后跑一组固定参数的测试，最终形成一张属于自己的模型选型表。

在大模型快速迭代的今天，各种新模型和新量化方案层出不穷，与其每次都跟着热门模型下载试用，不如沉淀出自己的评测基线。以后遇到新的模型，只要跑一遍同一套 Benchmark，马上就能知道它是否值得替换。如果本文对你有帮助，可以收藏备用。也欢迎在动手测试之后，把你遇到的奇怪的显存占用情况或性能瓶颈写在评论区，一起讨论排错思路。