把“本地大模型能不能跑”的答案，从“听说能跑”变成“实测数据证明能跑”，核心就是做一次针对设备配置的 benchmark。最近社区里讨论本地 LLM 选型的人越来越多，大家真正想问的往往不是“哪个模型能力最强”，而是“我这台机器到底能稳定跑哪个”。这个问题光看参数量回答不了，必须把模型量化、显存、内存、上下文长度、生成速度和任务准确率放到一起实测。这篇文章就按实际落地顺序，讲清楚怎么为自己的设备建立一套可复现的本地模型评测流程。内容不绑定某个特定模型或框架，目标是让你在自己的机器上跑通同一套流程，并拿到能指导选型的数据。
1. 先理解“适合设备规格”到底指什么
设备规格不是只指显存。很多人选模型只看显存大小，实际跑起来才发现还有其他瓶颈。要评测“适合”，至少要看四个指标。
第一个是显存，决定模型权重和 KV Cache 能不能放下。第二个是内存，纯 CPU 推理或者显存不足做部分卸载时，内存大小和速度直接影响能不能跑。第三个是内存带宽，这个最容易忽略。CPU 推理时，token 生成速度很大程度上由内存带宽决定，而不是 CPU 核心数。第四个是磁盘，GGUF 模型文件动辄几个 GB 到几十个 GB，磁盘剩余空间不够，模型都放不下；读取速度慢则会拉长加载时间。
我见过有人在 8GB 显存的机器上跑 13B 模型。模型能启动，但生成速度只有每秒两三个 token，上下文稍微拉长就直接内存溢出。这个状态不叫“能跑”，只能叫“能启动”。所以评测的第一步，是把“能启动”和“能正常使用”分开。
1.1 设备规格不只是显存，还有内存带宽和磁盘
上面说的四个指标，实际影响逻辑是这样的：模型权重和 KV Cache 加起来超出显存时，推理框架会把一部分层卸载到内存，生成速度立刻下降。内存带宽越低，下降越明显。磁盘则决定首次加载模型的耗时，HDD 和 SSD 在几十 GB 模型上的加载差距可能是几分钟和几十秒的区别。
所以在评测之前，先把自己的设备信息完整记下来，不要只记显卡型号。建议记录：显存大小、内存大小、CPU 型号、磁盘类型和剩余空间、操作系统、GPU 驱动版本。这些信息后面排查问题时都要用到。
1.2 模型能否运行和能否好用是两件事
判断模型是否适合设备，我习惯分成四层：
第一层，能不能启动。模型文件加载成功，推理进程不崩溃。第二层，能不能稳定生成。连续跑十条或二十条任务，中途不 OOM、不卡死、不输出截断。第三层，能不能完成任务。在评测集上达到可接受的分数。第四层，能不能日常使用。交互延迟在忍受范围内，批量任务的总耗时可控。
Benchmark 的目的，就是把每一层都验证一遍。只验证第一层，或者只验证第三层，都会踩坑。比如一个模型准确率很高，但每跑三次就崩一次，这种结果不能直接用于生产。再比如一个模型速度很快，但回答质量完全不可用，速度也没有意义。
2. 搭建本地评测环境前，先列好硬件和依赖清单
评测环境不需要很复杂，但要把依赖关系理清楚，否则后面报错都不知道找谁。
2.1 最小运行环境怎么准备
我建议按下面这个组合准备，足够覆盖大多数本地评测场景。
- 操作系统：Windows 或 Linux 都可以，Linux 下查看显存和进程信息更直观。
- 推理框架：llama.cpp 或 Ollama。llama.cpp 适合精细控制参数和编译选项，Ollama 适合快速起服务和切换模型。
- 模型格式：GGUF 量化模型。这是本地评测最常用的格式，兼容性好。
- 评测工具：可以用 lm-evaluation-harness，也可以自己写脚本批量调用推理接口。
- 监控工具：nvidia-smi 看显存，htop 看内存和 CPU，time 或自写脚本看耗时。
先确认 GPU 驱动和 CUDA 版本。llama.cpp 如果用 GPU 编译，需要匹配的 CUDA 环境；Ollama 一般会自动处理依赖。如果机器没有 GPU，直接用 CPU 推理，这时候不需要 CUDA，但一定要关注内存带宽和模型量化等级。
另外，评测前把其他占用显存的程序关掉。浏览器、剪辑软件、另一个模型服务，都可能影响评测结果。评测的数据要能重复，就必须控制环境干扰。
2.2 模型格式和量化版本的选择
本地模型评测最常用的格式是 GGUF。它把模型权重压缩成不同精度，体积、速度和效果三者之间有不同的取舍。常见量化级别如下：
| 量化级别 | 常见命名 | 体积 | 适用场景 |
|---|---|---|---|
| Q2_K | q2_k | 最小 | 只用来验证流程，不建议日常使用 |
| Q4_K_M | q4_k_m | 较小 | 入门首选，平衡体积和效果 |
| Q5_K_M | q5_k_m | 中等 | 显存有富余时优先考虑 |
| Q8_0 | q8_0 | 较大 | 需要较好保留原模型能力时使用 |
| F16 | fp16 | 最大 | 显存非常充足时才考虑 |
具体体积要按模型参数量和词表大小计算。大概经验是：7B 模型 Q4 量化约 4GB 左右，13B 模型 Q4 约 8GB 左右，70B 模型 Q4 约 40GB 左右。注意这是权重部分，上下文窗口的 KV Cache 还要另占显存。原始材料没有给出精确体积，落地时建议直接看模型仓库的文件大小，再乘一个余量。
我一般从 Q4_K_M 开始测。能跑通之后，如果显存有富余，再换 Q5_K_M 或 Q8_0 跑一轮对比。不要一上来就装 F16，大概率显存不足，而且新手不好判断是模型问题还是环境问题。
3. 一次完整的本地模型评测流程怎么走
评测流程我建议分四步，每一步都有明确的验证标准。跳步是最常见的翻车原因。
3.1 先跑单条测试，确认能启动
不需要评测集。准备几条简单指令，比如“用一句话解释什么是递归”“把下面这段文字翻译成英文”“用 Python 写一个冒泡排序”。
单条测试要记录五个点：启动耗时、是否生成完整输出、每秒生成 token 数、显存峰值、是否出现 OOM 或崩溃。只要这一层没过，后面都不用做。单条能过，再进入下一步。
3.2 用标准评测集做任务打分
能启动之后，才进入真正意义上的 benchmark。标准评测集的作用，是提供一个稳定、可横向对比的任务集合。常见方向包括：
- 通用知识问答，比如 MMLU 风格的多选题。
- 数学推理，比如 GSM8K 风格的应用题。
- 代码生成，比如 HumanEval 风格的函数补全。
- 中文任务，可以自己准备摘要、翻译、分类、改写等样例。
不要迷信单一评测集。本地选型更关注“你拿它做什么”，所以评测任务建议拆成两块：一块是通用能力，另一块是你自己业务场景的样例集。
自己构造样例集时，20 到 50 条就够。每条任务要包含明确的输入、期望的输出类型和打分方式。可以先用 JSON 记录：
{ "task_id": "math_001", "type": "数学推理", "input": "一个苹果 3 元，小明买了 4 个，付了 20 元，应该找零多少？", "expected_type": "数字答案", "score_rule": "结果完全匹配计 1 分" }这样后续统计分数时，可以自动判断，不用人肉看输出。
3.3 连续跑多轮，记录资源占用
评测不能只跑一次。同一个模型同一批问题，两次结果可能有差异，原因可能是采样随机性，也可能是资源竞争。
我建议每个模型至少跑两轮。第一轮记录首轮结果、峰值显存和总耗时。第二轮固定采样参数和随机种子，观察结果波动。如果两轮差异明显，优先怀疑采样参数和上下文长度，而不是直接判断模型能力。
3.4 输出一个可对比的结果表
评测完，把结果整理成一张表。字段至少包括：
| 模型 | 量化 | 上下文长度 | 生成速度 | 峰值显存 | 任务准确率 | 失败次数 |
|---|
选型时先看失败次数是不是 0，再看生成速度和显存是否可接受，最后才看准确率。准确率最高但连一次完整输出都跑不完的模型，不适合当前设备。
4. 关键指标解读：不能只看“跑得动”
跑得动只是及格线。真正决定一个模型能不能用，要看下面几组指标。
4.1 生成速度与首 token 延迟
生成速度一般用
