当前位置：首页 > news >正文

本地LLM基准测试全流程：量化选型与性能指标实战

news 2026/8/29 16:57:28

很多教程会告诉你：本地部署一个 7B 模型，用 GGUF 量化到 q4_K_M，在笔记本上就能跑起来。这话没错，但真正上手时会发现，问题远不止“能不能跑”这么简单。同一个模型，用不同量化精度、不同上下文长度、不同推理引擎去跑，速度和内存表现可能相差一倍以上；官方 README 里的参数说明也不会直接告诉你，你这台笔记本到底应该选哪个量级的模型。这篇文章，我就从一台普通开发笔记本的视角出发，把本地 LLM 基准测试的完整流程拆开讲透。你会了解该测哪些指标、怎么控制变量、如何用 Ollama / llama.cpp / LM Studio 快速拿到可复现结果，以及拿到结果之后，怎么在模型质量、速度和硬件占用之间做权衡。

1. 背景与核心概念

1.1 什么是本地 LLM

本地 LLM，指的是完全运行在你自己的电脑上、不依赖云端 API 的大语言模型。它和你在网页端使用 ChatGPT、在线大模型 API 最大的区别是：推理过程发生在你自己的 CPU 或 GPU 上，对话数据、上传的文档、生成的中间结果都不会离开本机。常见的落地形式是把模型量化成 GGUF 格式，再配合 llama.cpp、Ollama、LM Studio 这类推理引擎加载运行。

本地 LLM 的优势非常直接：隐私性更好，离线也能用，按需定制的能力更强，没有按 token 计费的压力。但代价也很明显——你的硬件决定一切。模型文件太大，内存装不下；GPU 显存不足，推理会退回 CPU，速度感人；上下文一拉长，KV Cache 又会吃掉一大块内存。所以，在真正把本地模型应用到项目里之前，先跑一轮基准测试，属于必须做的功课。

1.2 为什么要在笔记本上做基准测试

笔记本的硬件资源天然是受限的：CPU 核心数不够多，内存带宽有限，显存容量更是和桌面级显卡差了一截。如果不在部署前做一次完整的性能摸底，很容易出现两种极端：一种是模型选得太大，推理速度慢到不可用，体验非常糟糕；另一种是模型选得太小，虽然飞快，但理解能力和生成质量跟不上业务需求。

所以，benchmark 不是跑分爱好者专属的娱乐活动，它本质上是一次容量规划。你要回答三个问题：第一，这个模型能不能在当前笔记本的内存或显存里稳定加载；第二，它的吞吐速度能不能满足你的应用场景，比如聊天、文档摘要、Agent 工具调用；第三，长时间运行时，温度和功耗会不会触发笔记本降频，导致性能缩水。只有把这三个问题量化了，你才敢把本地模型放进正式项目里。

1.3 普通试玩和 Benchmark 的区别

普通试玩是你执行一条ollama run命令，输入一句话，看模型回复顺不顺眼。而 benchmark 是用可复现的方式去衡量系统表现。同样是生成 256 个 token 的任务，如果有人说“8B 模型速度还行”，这句话其实没有意义，因为不同笔记本硬件的差异可能达到 5 到 10 倍；甚至在同一台笔记本上，不同时间跑的结果也会因为系统负载、温度、降频策略而不同。

一份合格的 benchmark 至少要满足几个条件：同一份模型文件、同样的量化精度、同样的 prompt、同样的生成参数，固定随机种子和温度，多次运行取平均值或中位数。这样你才能在不同模型之间、不同量化级别之间、不同推理引擎之间做横向对比。只有做到可复现，测试结果才有工程价值。

1.4 本地 LLM 的典型场景：RAG、Agent 与 MCP

如果你只是把本地模型当作聊天玩具，性能压力其实不大。但一旦想把本地模型接入 RAG 知识库、Agent 工作流或者 MCP 工具调用，性能指标的差异会立刻被放大。RAG 场景里，系统检索完知识库之后要生成一段有依据的回答，首 token 延迟太高，用户就会觉得“卡”；Agent 场景中，工具调用往往包含多轮推理，每秒生成 token 数直接决定一个任务的总耗时；MCP 生态这两年越来越活跃，本地模型通过 MCP 协议连接数据库、文件系统、浏览器工具，每一步都在产生 token，链条越长，对吞吐的要求就越苛刻。

这也是很多开发者开始做“Obsidian + 本地模型 + LLM Wiki 个人知识库”的原因：先跑通离线推理，再叠加知识管理，再优化检索和生成速度。而所有这些优化的第一步，都是先做一次靠谱的本地 benchmark。

2. 环境准备与版本说明

2.1 先盘点你的笔记本硬件

开始之前，先明确你的笔记本属于哪种类型，这决定了推理路径与测试策略。大方向可以分成三类：第一类是带 NVIDIA 显卡的 Windows 笔记本，优先使用 CUDA 加速，速度和生态最好；第二类是 Apple Silicon 的 MacBook，利用 Metal 和统一内存，跑中小模型的体验也很不错；第三类是只有核显或者弱独显的轻薄本，主要靠 CPU 计算，内存带宽决定上限，模型量级要适当调小。

内存容量是另一个关键因素。7B 到 8B 参数量的模型，用 q4_K_M 量化后大约需要 4 到 6 GB 内存；14B 模型大约需要 8 到 11 GB。如果 GPU 显存不足以放下一整层模型，推理会退回到 CPU 执行，速度会明显下降。所以建议先用系统自带工具确认内存和显卡型号，再决定要测哪些模型。版本信息以你的实际环境为准，本文重点演示的是“怎么测”的方法，而不是某个特定型号的跑分。

2.2 推理工具选型：Ollama、llama.cpp、LM Studio

当前本地 LLM 推理工具里，最常用的三套是 Ollama、llama.cpp 和 LM Studio，它们的定位不同：

Ollama：安装最简单，一行命令下载模型并启动服务，适合快速尝试和 API 调用，也适合做脚本自动化测试。
llama.cpp：最接近底层，提供了专门的llama-bench工具，适合精确对比不同量化级别、不同线程数、不同 GPU 层数下的性能差异。
LM Studio：图形化界面，内置模型下载和参数调整面板，提供本地 OpenAI 兼容 API，适合不熟悉命令行的用户。

对 benchmark 来说，我的建议是：没有特殊需求，先用 Ollama 跑一次拿到基线；需要更细粒度对比时，再用 llama.cpp 的llama-bench。原因在于llama-bench的功能设计就是基准测试，可以自动统计 prompt 处理和生成两个阶段的耗时；而 Ollama 更适合日常使用，它没有内置的基准命令，需要自己写脚本调用 API。两者的结果可以互相印证，但不能直接对标。

2.3 安装与环境验证

先安装 Ollama。Windows 和 macOS 用户直接去官网下载安装包即可，Linux 用户可以用官方脚本：

# Linux 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 验证安装 ollama --version

然后准备 llama.cpp。如果之前没有用过，可以用下面的方式编译。需要说明的是，Windows 用户如果要 CUDA 加速，需要先安装 CUDA Toolkit；没有 NVIDIA 显卡或不想自己编译的，可以直接下载官方 release 版本。

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release -DLLAMA_CUBLAS=ON cmake --build build --config Release -j 8

如果是 Apple Silicon Mac，把-DLLAMA_CUBLAS=ON换成-DLLAMA_METAL=ON，让 llama.cpp 走 Metal 加速。编译完成之后，在build/bin目录下就能找到llama-bench可执行文件。LM Studio 不需要命令行，直接安装，然后在界面里下载模型即可。

2.4 建立测试目录结构

为了避免测试数据散落各处，建议先搭一个简单的目录结构：

benchmark/ ├── scripts/ │ └── run_benchmark.py ├── results/ │ └── benchmark_result.csv └── models/ └── qwen2.5-7b-instruct-q4_K_M.gguf

后续所有模型文件、测试脚本、结果 CSV 都放在统一位置，一方面方便多次运行对比，另一方面也方便把结果分享给团队。

3. 基准测试方法论：测什么、怎么测才可信

3.1 核心指标：TTFT、TPS、内存与能耗

benchmark 不能只看“生成了多少字”，业内常用四个核心指标：

TTFT（Time To First Token）：从发起请求到模型输出第一个 token 的时间。对话机器人和 RAG 场景最关心这个，它决定了用户的第一感知延迟。
TPS（Tokens Per Second）：生成阶段每秒产出的 token 数量。文档摘要、长篇生成、Agent 多轮任务更依赖这个指标。
峰值内存：进程在运行期间占用的最大 RAM 或 VRAM。内存不够会触发 swap，性能会急剧下降。
功耗与温度：笔记本与台式机不同，散热空间有限，长时间高负载会触发降频，TPS 会从峰值掉下来。

在记录结果时，尽量把这几项都记下来，因为同一个模型在不同上下文长度下的内存占用差别很大，只看 TPS 会漏掉关键信息。

3.2 控制变量的测试设计

基准测试的意义在于横向对比，这就要求控制变量。最基本的测试设计要满足以下条件：

使用同一份模型文件，记录文件大小或哈希值。
固定 prompt 的 token 长度，避免“问题简单所以回答快”的干扰。
固定 max tokens，也就是一次生成的最大长度。
固定采样参数，例如 temperature = 0、top_p = 1、固定随机种子。
同一模型和同一场景至少跑 3 次，取平均值或中位数。
测试期间关闭后台下载、视频播放、编译任务等无关负载。

举个例子，如果你想对比 7B 模型的 q4_K_M 和 q5_K_M 两档量化，就应该保证两次运行的环境完全相同，只替换模型文件。如果上下文长度变了，那测试的是“上下文长度对速度的影响”，就不能再和前面的结果直接比较了。

3.3 理解精度与量化：FP16、BF16、FP32 与 GGUF

这是新手最容易绕晕的部分，也是本地 LLM benchmark 最重要的背景知识。FP32 是单精度浮点数，每个权重占 4 字节，精度最高但体积最大；FP16 是半精度，每个权重占 2 字节，显存占用减半，是目前很多 GPU 原生加速的精度格式；BF16 同样是 2 字节，但它的指数位范围和 FP32 一致，只是尾数精度更低，在深度学习场景下更容易保持数值稳定，因此大模型训练和推理中很常见。

在带 GPU 的机器上，常见的做法是用 FP16 或 BF16 做推理；而在 CPU 或混合部署场景下，GGUF 量化格式更常用。q4_K_M、q5_K_M、q8_0 这些名字，表示把权重从 16 位浮点压缩到 4 位、5 位或 8 位整数或低精度浮点，模型体积成倍下降，推理速度更快，但精度会有一定损失。benchmark 的核心目标之一，就是帮你找到“速度、体积、质量”三者之间的平衡点。

3.4 使用 llama-bench 快速测试

llama.cpp 自带的llama-bench是最省事的基准工具。它会在同一个进程里先跑 prompt 处理，再跑 token 生成，最终输出 TPS 和内存占用，不用自己写计时逻辑。基本用法如下：

./llama-bench -m ./models/qwen2.5-7b-instruct-q4_K_M.gguf \ -p 512 -n 256 -r 3

解释一下关键参数：

-m：指定 GGUF 模型文件路径。
-p：prompt 的 token 长度，建议固定为 512 或 1024。
-n：生成的 token 数量，建议固定为 256。
-r：重复次数，建议至少 3 次。
-ngl：放入 GPU 的层数，默认可能为 0，需要根据你的显存手动调整，常见值如 99 表示尽可能全部放 GPU。

执行完成后，终端里会输出类似下面的字段：prompt t/s、generation t/s、mtest等。其中 generation t/s 就是我们要重点关注的 TPS。

3.5 用 Python 脚本做自定义基准测试

llama-bench适合测引擎本身，但如果你想知道“用户实际请求下模型表现如何”，最好直接通过 Ollama 的 API 测，这样更贴近真实应用场景。下面是一个最小可用的 Python 脚本，它向本地 Ollama 服务发送生成请求，然后从响应里解析出 token 数和耗时，计算出 TPS。

# 文件路径：benchmark/scripts/quick_bench.py import time import requests MODEL = "qwen2.5:7b" URL = "http://localhost:11434/api/generate" PROMPT = "请用三句话介绍什么是数据库索引，并举例说明。" MAX_TOKENS = 256 def run_once(): payload = { "model": MODEL, "prompt": PROMPT, "stream": False, "options": { "temperature": 0, "num_predict": MAX_TOKENS, }, } t0 = time.time() resp = requests.post(URL, json=payload) data = resp.json() elapsed = time.time() - t0 eval_count = data.get("eval_count", 0) eval_duration = data.get("eval_duration", 1) load_duration = data.get("load_duration", 0) tps = eval_count / (eval_duration / 10**9) return elapsed, tps, eval_count, load_duration / 10**9 if __name__ == "__main__": elapsed, tps, eval_count, load_sec = run_once() print(f"总耗时: {elapsed:.2f}s") print(f"生成 tokens: {eval_count}") print(f"TPS: {tps:.2f}") print(f"模型加载耗时: {load_sec:.2f}s")

这段脚本里的重点是通过eval_duration计算 TPS，而不是用总耗时去除。因为总耗时里包含了网络请求、模型排队和加载时间，不能代表真实的生成速度。Ollama 返回的eval_duration单位是纳秒，所以要除以 10 的 9 次方换算成秒。

4. 完整实战：在笔记本上跑一份可复现的 Benchmark

4.1 确定测试模型与量化层级

先决定测什么。对大多数 16GB 内存的笔记本来说，建议从 7B 到 8B 级别的模型开始，选择 q4_K_M 和 q5_K_M 两个量化档位对比；如果内存比较大，比如 32GB 或以上，可以再加入 14B 模型测试。下面以 Qwen2.5 7B 和 Llama 3.1 8B 为例。不同模型的精确标签以 Ollama 库的实时列表为准，可以用ollama pull拉取。

# 拉取两个量化版本的模型作对比 ollama pull qwen2.5:7b ollama pull qwen2.5:7b-instruct-q4_K_M # 可选：拉取 Llama 3.1 8B ollama pull llama3.1:8b

如果你不确定某个标签是否存在，可以先执行ollama list查看本地已有模型，或者到模型库页面搜索确认。实测时建议优先使用你已经在用的模型标签，这样测试结果直接服务于你的业务。

4.2 编写可复用的基准测试脚本

单独跑一次脚本只能得到一组数据，为了对比模型和量化，最好把脚本扩展成批量模式。下面这个脚本会遍历多个模型，每个模型重复跑 5 次，最后把所有结果写入 CSV 文件，方便后续用 Excel 或 pandas 分析。

# 文件路径：benchmark/scripts/run_benchmark.py import csv import time import statistics import requests MODELS = [ "qwen2.5:7b-instruct-q4_K_M", "qwen2.5:7b-instruct-q5_K_M", ] URL = "http://localhost:11434/api/generate" PROMPT = "请解释什么是 B+ 树，以及它在数据库中的典型使用场景。" REPEATS = 5 MAX_TOKENS = 256 def bench_model(model): samples = [] for _ in range(REPEATS): payload = { "model": model, "prompt": PROMPT, "stream": False, "options": { "temperature": 0, "num_predict": MAX_TOKENS, }, } t0 = time.time() resp = requests.post(URL, json=payload) data = resp.json() elapsed = time.time() - t0 eval_count = data.get("eval_count", 0) eval_duration = data.get("eval_duration", 1) tps = eval_count / (eval_duration / 10**9) samples.append({ "model": model, "elapsed_sec": round(elapsed, 2), "eval_count": eval_count, "tps": round(tps, 2), "load_sec": round(data.get("load_duration", 0) / 10**9, 2), }) return samples def main(): rows = [] for model in MODELS: rows.extend(bench_model(model)) with open("results/benchmark_result.csv", "w", newline="", encoding="utf-8") as f: writer = csv.DictWriter( f, fieldnames=["model", "elapsed_sec", "eval_count", "tps", "load_sec"] ) writer.writeheader() writer.writerows(rows) for row in rows: print(row) if __name__ == "__main__": main()

脚本的核心逻辑是：先把每个模型的多次采样数据收集起来，再统一写入 CSV。写文件放在循环外面，是为了避免每次请求都打开文件、关闭文件，减少 I/O 对测试结果的干扰。

4.3 执行测试并记录数据

运行脚本前，确保 Ollama 服务已经启动。然后执行：

cd benchmark mkdir -p results python scripts/run_benchmark.py

正常运行时，会在终端看到每一轮采样的打印信息。测试结束后，results/benchmark_result.csv里会保留原始数据。CSV 是文本格式，后续不管是画折线图还是做方差分析都很方便。如果你改动了模型文件或引擎版本，建议把文件名改成带时间戳的格式，比如benchmark_result_20250120.csv，避免覆盖旧数据。

4.4 观察系统资源占用

运行脚本的同时，打开系统监控工具，观察 CPU、内存、GPU 占用情况。Windows 用户可以打开任务管理器，或者单独开一个终端窗口执行：

# Windows / Linux 下监控 NVIDIA GPU nvidia-smi -l 1

-l 1表示每隔 1 秒刷新一次，可以看到 GPU 利用率、显存占用和温度。Mac 用户可以用：

# macOS 下查看内存压力 vm_stat # 安装 htop 后可以看 CPU 和内存实时情况 htop

记录下两个关键点：第一，模型加载完成后，进程占用的内存或显存峰值是多少；第二，生成过程中 GPU 利用率是否跑满，如果 GPU 利用率只有 30% 而 CPU 居高不下，说明模型没有完全放进 GPU，退回了 CPU 推理，这时 TPS 通常不会太理想。

4.5 整理结果表格

测试完成后，可以把 CSV 里的数据整理成一张对比表。下面是一个示例格式，具体数字需要你在自己的笔记本上实测得到，我不建议直接套用别人的结果，因为硬件差异太大。

模型	量化	平均 TPS	首 token 延迟	峰值内存
Qwen2.5 7B	q4_K_M	待实测	待实测	待实测
Qwen2.5 7B	q5_K_M	待实测	待实测	待实测
Llama 3.1 8B	q4_K_M	待实测	待实测	待实测

至少跑三次取中位数，能有效避免偶然波动。建议在表格后面加一列“备注”，记录当时是否开着浏览器、是否处于充电状态、笔记本是否在散热支架上等环境因素，因为笔记本的功耗策略会随这些因素变化。

5. 结果分析：怎样读数据，怎样选模型

5.1 速度不是唯一指标

很多人在跑完 benchmark 后，只盯着 TPS 谁高谁低，这其实不够全面。如果你的显存或内存有限，可能会发现一个残酷事实：某个大模型虽然能加载，但部分层数退回了 CPU 推理，TPS 从几十掉到了个位数。这时与其换更强的硬件，不如降低量化级别，或者换用更小但更适合任务的模型。

内存占用同样重要。同样一个模型，在 4096 上下文和 16384 上下文下的内存占用可能相差好几 GB。如果模型在长上下文下会触发 swap，你再追求 TPS 都没有意义，因为系统会先卡死。所以结果分析的正确顺序是：先看内存/显存是否够用，再看 TPS 是否达标，最后用实际任务验证生成质量。

5.2 模型、量化、上下文的三维权衡

本地 LLM 的选型本质上是在三个维度之间做权衡：模型参数量、量化级别、上下文长度。

模型越大，生成质量和理解能力通常越好，但内存和显存需求更高。
量化越低，比如从 q8_0 降到 q4_K_M，体积更小、速度更快，但精度损失更明显，具体表现为生成内容偶尔会产生“幻觉”或逻辑不连贯。
上下文越长，KV Cache 消耗的内存越多，相同显卡下生成速度也可能下降。

所以不要单独比较“TPS 谁高”，而要在同一场景下比较“谁的组合最优”。比如你的应用是长文档分析，上下文至少 8192，那就优先比较模型在 8192 上下文下的内存和 TPS；如果你的应用是短对话，上下文 2048 就够，那就可以把内存预算省下来，选择更大的模型或更高的量化。

5.3 用数据做容量规划

拿到数据之后，要回到真实场景里去判断。如果做的是聊天机器人，用户期待 3 秒内看到第一个字，那你就重点看 TTFT 是否小于 3 秒；如果做的是批量文档摘要，一次要生成 1000 个 token，那你就重点看 TPS，计算总耗时是否在可接受范围内；如果是 Agent 多轮工具调用，任务可能持续 10 轮以上，你要看的是连续多轮的总耗时是否可预测，以及显存会不会随着对话轮次增长而溢出。

容量规划还有一个技巧：给生产环境预留 20% 到 30% 的内存余量。因为操作系统和其他进程也会占用内存，如果是 Windows 笔记本，后台软件尤其多。千万别把内存算到 99% 满载，否则一旦系统开始换页，TPS 会断崖式下跌。

5.4 相对比较比绝对值更重要

不同笔记本之间的数据差异太大，所以你的实测值只有和你自己的另一套配置对比时才最有意义。比如你测了 q4_K_M 和 q5_K_M，发现 TPS 只下降了 10%，但生成质量明显提高，那 q5_K_M 就更值得选；如果 TPS 下降了 30%，而质量提升不明显，那就继续用 q4_K_M。这也是为什么要把基准脚本固化的原因——靠“体感”很难判断这 10% 和 30% 的差异。

6. 常见问题与排查思路

本地 LLM benchmark 过程中，下面几个问题出现的频率最高。

问题现象	常见原因	解决思路
运行时显存不足，报 OOM	模型太大，或 KV Cache 太长	换更小模型、降低量化、缩短上下文
模型加载成功但速度骤降	GPU 显存不足，部分层退回 CPU	调整`num_gpu`或`-ngl`，或换小模型
TPS 波动非常大	后台进程、笔记本降频、温度墙	关闭无关程序，多次运行取中位数
生成内容前后不一致	temperature 未固定	设 temperature = 0，固定随机种子
上下文一长就变慢或报错	KV Cache 内存不足	调低`num_ctx`或`-c`参数
Windows 下找不到 GPU 加速	CUDA 环境未配置好	重装 CUDA Toolkit，检查驱动版本

第一个 OOM 问题，处理思路是优先降低上下文长度，因为 KV Cache 是线性增长的。比如在 Ollama 里可以设置上下文：

/set parameter num_ctx 8192

设置后，生成时的 KV Cache 按 8192 预分配，内存占用比 32768 小很多。如果你用的是 llama.cpp 的 server 模式，则对应参数是：

./llama-server -m model.gguf -c 8192 -ngl 99

第二个速度骤降问题，在 Llama.cpp 中可以通过-ngl控制放入 GPU 的层数。如果显存只有 6GB，而模型有 40 层，可以先从-ngl 30开始，剩下的层跑 CPU。需要注意的是，层数分配不是越多越好，一旦某层放不进 GPU，整次推理仍然会被 CPU 拖慢，需要根据nvidia-smi的显存监控逐步调整。

第六个 CUDA 环境问题，在 Windows 上尤其常见。llama.cpp编译时指定的LLAMA_CUBLAS=ON要求编译环境能检测到 CUDA，而运行时又要匹配 NVIDIA 驱动的 CUDA 版本。如果两者不匹配，程序会默认走 CPU。最简单的排查方式是在编译完成之后执行llama-bench --list-devices，查看是否输出了 GPU 设备。