把“本地大模型能不能跑”的答案从“听说能跑”变成“实测数据证明能跑”核心就是做一次针对设备配置的 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 看内存和 CPUtime 或自写脚本看耗时。先确认 GPU 驱动和 CUDA 版本。llama.cpp 如果用 GPU 编译需要匹配的 CUDA 环境Ollama 一般会自动处理依赖。如果机器没有 GPU直接用 CPU 推理这时候不需要 CUDA但一定要关注内存带宽和模型量化等级。另外评测前把其他占用显存的程序关掉。浏览器、剪辑软件、另一个模型服务都可能影响评测结果。评测的数据要能重复就必须控制环境干扰。2.2 模型格式和量化版本的选择本地模型评测最常用的格式是 GGUF。它把模型权重压缩成不同精度体积、速度和效果三者之间有不同的取舍。常见量化级别如下量化级别常见命名体积适用场景Q2_Kq2_k最小只用来验证流程不建议日常使用Q4_K_Mq4_k_m较小入门首选平衡体积和效果Q5_K_Mq5_k_m中等显存有富余时优先考虑Q8_0q8_0较大需要较好保留原模型能力时使用F16fp16最大显存非常充足时才考虑具体体积要按模型参数量和词表大小计算。大概经验是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 延迟生成速度一般用 本地大模型实测指南：从能启动到能用，一套可复现的Benchmark流程
把“本地大模型能不能跑”的答案从“听说能跑”变成“实测数据证明能跑”核心就是做一次针对设备配置的 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 看内存和 CPUtime 或自写脚本看耗时。先确认 GPU 驱动和 CUDA 版本。llama.cpp 如果用 GPU 编译需要匹配的 CUDA 环境Ollama 一般会自动处理依赖。如果机器没有 GPU直接用 CPU 推理这时候不需要 CUDA但一定要关注内存带宽和模型量化等级。另外评测前把其他占用显存的程序关掉。浏览器、剪辑软件、另一个模型服务都可能影响评测结果。评测的数据要能重复就必须控制环境干扰。2.2 模型格式和量化版本的选择本地模型评测最常用的格式是 GGUF。它把模型权重压缩成不同精度体积、速度和效果三者之间有不同的取舍。常见量化级别如下量化级别常见命名体积适用场景Q2_Kq2_k最小只用来验证流程不建议日常使用Q4_K_Mq4_k_m较小入门首选平衡体积和效果Q5_K_Mq5_k_m中等显存有富余时优先考虑Q8_0q8_0较大需要较好保留原模型能力时使用F16fp16最大显存非常充足时才考虑具体体积要按模型参数量和词表大小计算。大概经验是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 延迟生成速度一般用