在本地部署大模型最常被问到的一个问题就是“我的电脑配置到底能跑多大的模型”这个问题看似简单但真要回答清楚并不容易尤其是当你不只想“能跑”还想跑得流畅、输出质量还过得去的时候。很多同学一开始就直接把 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.5GB8GB 显存就可以运行还能留出一部分空间给 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半精度浮点数或 BF16BFloat16每个参数占 2 字节FP32 占 4 字节INT8 占 1 字节INT4 占 0.5 字节。以 7B 模型为例FP16/BF16约 7 × 2 14GBFP32约 7 × 4 28GBINT8约 7GBINT4约 3.5GB。这只是权重部分的估算实际推理时还需要为 KV Cache、中间激活值、CUDA context 等预留额外显存。因此如果你想加载一个 7B FP16 模型理想情况下显卡最好有 16GB 显存接近 14GB 则比较勉强。建议你在挑选模型时把量化后的模型权重大小作为“下限”再把显存打七折作为“预算”两者之间留出 2GB 到 4GB 的缓冲空间会更容易跑稳定。2.2 精度与量化FP16、BF16、INT8、INT4PyTorch 和 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 时最好固定一个统一的解码参数比如temperature0或top_p0.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 LTSWindows 10/11 也可参考Python3.10 或 3.11PyTorch2.1 及以上Ollama0.1.x 或更新版本llama.cppmaster 最近版本硬件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_tokens256): payload { model: model, prompt: prompt, stream: False, options: { num_predict: max_tokens, temperature: 0.7 } } req urllib.request.Request( http://localhost:11434/api/generate, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) start time.time() with urllib.request.urlopen(req, timeout600) 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, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) with urllib.request.urlopen(req, timeout300) 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模型精度/量化显存占用(GB)请求耗时(s)生成Token数tokens/sPerplexity备注qwen2.5:7bq4_K_M约5.212.325620.8待测定待补充分数记录时尽量保证每次测试的 prompt 和参数一致。如果两次测试显存占用波动很大检查是否有其他程序占用 GPU建议测试前关闭浏览器和无关应用保证数据干净。完成多组测试后你就能得到一张自己的模型选型表。这张表是以后换电脑、换显卡或者升级模型时的重要依据。5. 评测结果示例与解读这一节用一组示例数据说明如何解读结果。以下数据只是为了展示记录格式并不是固定结论实际结果一定要以自己设备为准。假设我们在同一台设备上测试了三个模型模型量化显存预估tokens/s质量主观分(1-5)结论3B 模型INT4约1.8GB452.5速度快但明显智障7B 模型INT4约3.8GB224.0速度和质量均衡7B 模型INT8约7.2GB164.3质量略高显存接近上限从这个结果中可以看到在 8GB 显存环境下7B INT4 是性价比最高的选择因为它在显存占用和速度之间取得了很好的平衡。如果设备显存提升到 12GB则可以尝试 7B INT8 甚至 13B INT4 的模型质量会有进一步提升。反之如果只有 CPU 环境3B 模型可能在速度上仍然不理想需要进一步降低上下文长度或使用更小的 1B 级别模型。解读数据时不能只盯着 tokens/s 看。如果某个模型的速度特别快但主观回答质量很低那它可能只适合做关键词生成等简单任务不适合做对话助手。最好的做法是把速度数据和质量评分放在同一张表里根据业务需求分配权重。交互式产品更看重速度和首 Token 延迟离线任务更看重吞吐和质量。6. 常见问题与排查思路在实际评测过程中最常见的几类问题如下问题现象常见原因解决思路模型加载后进程被杀死显存或内存不够换更小的量化模型降低上下文长度关闭其他占用程序生成速度极慢模型权重没有完全放进显存回落到 CPU 推理使用 nvidia-smi 确认显存占用选择更小模型或更低 bit 量化Ollama API 连接失败Ollama 服务没有启动或端口被占用运行ollama serve检查 11434 端口占用情况不同模型速度对比不准确没有统一 prompt 和生成长度固定 prompt、num_predict、temperature 参数Perplexity 测试报错输入文件编码或格式不对将文本文件保存为 UTF-8 编码去掉特殊字符显存占用比预期高没有计算 KV Cache 和 CUDA context 开销用更保守的显存估算预留给KV Cache 至少2GB量化模型回答跑偏INT4 量化导致质量下降尝试 INT8 或更高精度或换更大的模型针对“进程被杀死”这种情况优先建议把模型换成更小参数的版本并在启动命令中限制上下文长度。例如 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马上就能知道它是否值得替换。如果本文对你有帮助可以收藏备用。也欢迎在动手测试之后把你遇到的奇怪的显存占用情况或性能瓶颈写在评论区一起讨论排错思路。 本地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.5GB8GB 显存就可以运行还能留出一部分空间给 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半精度浮点数或 BF16BFloat16每个参数占 2 字节FP32 占 4 字节INT8 占 1 字节INT4 占 0.5 字节。以 7B 模型为例FP16/BF16约 7 × 2 14GBFP32约 7 × 4 28GBINT8约 7GBINT4约 3.5GB。这只是权重部分的估算实际推理时还需要为 KV Cache、中间激活值、CUDA context 等预留额外显存。因此如果你想加载一个 7B FP16 模型理想情况下显卡最好有 16GB 显存接近 14GB 则比较勉强。建议你在挑选模型时把量化后的模型权重大小作为“下限”再把显存打七折作为“预算”两者之间留出 2GB 到 4GB 的缓冲空间会更容易跑稳定。2.2 精度与量化FP16、BF16、INT8、INT4PyTorch 和 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 时最好固定一个统一的解码参数比如temperature0或top_p0.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 LTSWindows 10/11 也可参考Python3.10 或 3.11PyTorch2.1 及以上Ollama0.1.x 或更新版本llama.cppmaster 最近版本硬件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_tokens256): payload { model: model, prompt: prompt, stream: False, options: { num_predict: max_tokens, temperature: 0.7 } } req urllib.request.Request( http://localhost:11434/api/generate, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) start time.time() with urllib.request.urlopen(req, timeout600) 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, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) with urllib.request.urlopen(req, timeout300) 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模型精度/量化显存占用(GB)请求耗时(s)生成Token数tokens/sPerplexity备注qwen2.5:7bq4_K_M约5.212.325620.8待测定待补充分数记录时尽量保证每次测试的 prompt 和参数一致。如果两次测试显存占用波动很大检查是否有其他程序占用 GPU建议测试前关闭浏览器和无关应用保证数据干净。完成多组测试后你就能得到一张自己的模型选型表。这张表是以后换电脑、换显卡或者升级模型时的重要依据。5. 评测结果示例与解读这一节用一组示例数据说明如何解读结果。以下数据只是为了展示记录格式并不是固定结论实际结果一定要以自己设备为准。假设我们在同一台设备上测试了三个模型模型量化显存预估tokens/s质量主观分(1-5)结论3B 模型INT4约1.8GB452.5速度快但明显智障7B 模型INT4约3.8GB224.0速度和质量均衡7B 模型INT8约7.2GB164.3质量略高显存接近上限从这个结果中可以看到在 8GB 显存环境下7B INT4 是性价比最高的选择因为它在显存占用和速度之间取得了很好的平衡。如果设备显存提升到 12GB则可以尝试 7B INT8 甚至 13B INT4 的模型质量会有进一步提升。反之如果只有 CPU 环境3B 模型可能在速度上仍然不理想需要进一步降低上下文长度或使用更小的 1B 级别模型。解读数据时不能只盯着 tokens/s 看。如果某个模型的速度特别快但主观回答质量很低那它可能只适合做关键词生成等简单任务不适合做对话助手。最好的做法是把速度数据和质量评分放在同一张表里根据业务需求分配权重。交互式产品更看重速度和首 Token 延迟离线任务更看重吞吐和质量。6. 常见问题与排查思路在实际评测过程中最常见的几类问题如下问题现象常见原因解决思路模型加载后进程被杀死显存或内存不够换更小的量化模型降低上下文长度关闭其他占用程序生成速度极慢模型权重没有完全放进显存回落到 CPU 推理使用 nvidia-smi 确认显存占用选择更小模型或更低 bit 量化Ollama API 连接失败Ollama 服务没有启动或端口被占用运行ollama serve检查 11434 端口占用情况不同模型速度对比不准确没有统一 prompt 和生成长度固定 prompt、num_predict、temperature 参数Perplexity 测试报错输入文件编码或格式不对将文本文件保存为 UTF-8 编码去掉特殊字符显存占用比预期高没有计算 KV Cache 和 CUDA context 开销用更保守的显存估算预留给KV Cache 至少2GB量化模型回答跑偏INT4 量化导致质量下降尝试 INT8 或更高精度或换更大的模型针对“进程被杀死”这种情况优先建议把模型换成更小参数的版本并在启动命令中限制上下文长度。例如 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马上就能知道它是否值得替换。如果本文对你有帮助可以收藏备用。也欢迎在动手测试之后把你遇到的奇怪的显存占用情况或性能瓶颈写在评论区一起讨论排错思路。