llama-bench 性能基准测试:3 个参数拉满本地 LLM 推理速度
【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp
llama.cpp 的性能基准测试工具 llama-bench,将一次模型跑分拆为 PP(Prompt Processing,提示词处理速度)和 TG(Text Generation,文本生成速度)两个 tokens/s 指标,每项默认重复 5 轮,输出均值与标准差。它是本地大模型推理提速的第一手数据源:调参、选量化、追回归,都以这张表为准。
🚀 跑通第一次基准
llama.cpp 编译完成后,确认 llama-bench 可用即可(单独编译它只需一条 make 命令):
git clone https://gitcode.com/GitHub_Trending/ll/llama.cpp cd llama.cpp && make llama-bench然后指定一个 GGUF(llama.cpp 的模型文件格式)文件,跑默认组合 pp512 + tg128:
./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf典型输出是一张 Markdown 表,t/s 后面的 ± 是标准差,越小测量越稳定:
| test | t/s |
|---|---|
| pp512 | 2368.80±93.24 |
| tg128 | 131.42±0.59 |
注意 llama-bench 的计时不含分词与采样耗时,测的是纯推理计算。实现细节可看 llama-bench 源码。默认表只是基线,三种测试模式量的东西并不相同。
读懂测试模式与输出
| 参数 | 模式 | 用途 |
|---|---|---|
-p <n> | PP | 只处理 n 个 token 的提示词,评估长文档理解与首 token 延迟 |
-n <n> | TG | 只生成 n 个 token,评估对话输出的流畅度 |
-pg <pp,tg> | PG | 先处理再生成,模拟一轮真实对话 |
同一份结果可用-o导出四种格式,下游用途各异:
| 格式 | 适合场景 |
|---|---|
| md(默认) | 直接贴进 README 或 PR 描述 |
| csv | Excel 透视表、脚本批量筛选 |
| json | Python 可视化、CI 系统解析 |
| sql | 灌入 SQLite,跨版本长期追踪 |
完整参数清单见 llama-bench 参数文档。模式定了,真正左右 t/s 的是三个参数。
⚙️ 三个旋钮:把速度拉满
GPU 层分配(-ngl)
它控制模型有多少层权重卸载到 GPU,剩下的层留在 CPU 上计算。GPU 层分配调优从扫一组值开始:
./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf -ngl 10,20,35| ngl | pp512 t/s | tg128 t/s |
|---|---|---|
| 10 | 373.36±2.25 | 13.45±0.93 |
| 20 | 472.65±1.25 | 21.36±1.94 |
| 35 | 2400.01±7.72 | 131.66±0.49 |
35 是全量卸载,tg128 从 13.45±0.93 升到 131.66±0.49:显存装得下就直接给-ngl 99,逐层扫描只用于显存吃紧时找平衡点。
CPU 线程数(-t)
它控制 CPU 推理时并行参与矩阵运算的线程数,对纯 CPU 后端尤其关键:
./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf -t 4,8,16 -p 64 -n 16| threads | pp64 t/s | tg16 t/s |
|---|---|---|
| 4 | 23.18±0.06 | 12.22±0.07 |
| 8 | 32.29±1.21 | 16.71±0.66 |
| 16 | 33.52±0.03 | 15.32±0.05 |
PP 到 16 线程还有微增,TG 却从 8 线程的 16.71 回落到 15.32:线程数超过物理核心后,内存带宽成为瓶颈,生成阶段收益递减甚至转负。从物理核心数起步最稳。
批处理大小(-b)
它控制 PP 阶段每批并行送入模型的 token 数,是提示词处理速度优化的主要旋钮:
./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf -b 128,256,1024 -p 1024 -n 0| n_batch | pp1024 t/s |
|---|---|
| 128 | 1436.51±3.66 |
| 256 | 1932.43±23.48 |
| 1024 | 2498.61±13.58 |
batch 越大,单次矩阵运算越能喂饱 GPU 算力,代价是激活值占用的显存更多;显存不足时,这是第一个该调小的参数。单模型调到位后,更常见的需求是一次比完多组配置。
📊 多模型对比与自动化
多个-m会自动做组合测试,每个模型 × 每个生成长度各出一行:
./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf -m models/7B/ggml-model-q8_0.gguf -p 0 -n 128,256 ./build/bin/llama-bench -o json > performance.jsonJSON 里每条记录都带构建与硬件元数据,以及每轮原始采样:
{ "build_commit": "8cf427ff", "cpu_info": "AMD Ryzen 7 7800X3D 8-Core Processor", "gpu_info": "NVIDIA GeForce RTX 4080", "model_type": "qwen2 7B Q4_K - Medium", "avg_ts": 119.844681, "stddev_ts": 0.699739, "samples_ts": [120.038, 120.203, 118.624, 120.377, 119.982] }脚本按model_type和avg_ts分组,就能画出量化方案对比图;嫌脚本麻烦,-o csv丢进 Excel 做透视表同样顺手。跑得越多,几个高频问题越值得提前知道。
🛠 排错与避坑
| 现象 | 原因 | 处理 |
|---|---|---|
| GPU 利用率低、TG 速度上不去 | 部分层还留在 CPU,计算被劈成两半 | -ngl 99全量卸载,--list-devices确认后端 |
| 线程加多后 t/s 反降 | 线程数超过物理核心,锁与内存带宽争用 | -t回到物理核心数 |
大 batch 或大-p时 OOM | 激活值与 KV cache 超出显存 | 先降-b,再考虑换更小的量化 |
| 同配置多次跑结果波动大 | 后台进程抢资源、降频 | 关后台任务,看 ± 标准差,必要时加大-r |
下一步
- Metal / SYCL 后端:同一套参数在 Apple 芯片和 Intel 核显上也能跑分,做跨后端对比
- 推测解码(speculative decoding):搭一个小的 draft 模型,用 TG 实测真实加速
- 回归追踪:
-o sql定期灌库,盯住每次代码或驱动升级后的速度曲线 - 上下文扫描:
-d 0,512,1024观察长上下文下 PP/TG 的衰减拐点
把这些基线攒成趋势,下次换硬件或升级驱动时,一眼就能看出涨跌。
【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考