企业官网建设流程全解析

用 llama-bench 测出本地 LLM 推理的真实速度

【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp

把同一个 7B 模型丢到两台配置一样的机器上，一台能跑出 130 t/s，另一台只有 40 t/s——你很难说哪台"该快"，因为手测的速度混杂了加载、预热、后台进程等各种干扰。llama.cpp 自带的llama-bench工具就是为这个设计的：固定测试流程、自动预热、每轮重复多次，专测 LLM 推理速度这一件事。

它测两类指标：pp（Prompt Processing，模型"读题"的速度）和 tg（Text Generation，逐字往外吐的速度）。两者瓶颈不同，调参方向也不同，所以分开测才有意义。下面按"跑通基线 → 扫参数找拐点 → 结果入库留痕"三步来。

📐 确认后端后，跑出一组可信基线

基线要可信，前提是加速后端真的生效了。跑测试前先用--list-devices看一眼 llama-bench 当前看到的设备，确认后端是 CUDA 还是只能落在 CPU 上：

./llama-bench --list-devices

再跑一次默认基线（默认处理 512 个 prompt token、生成 128 个，每个测 5 轮取平均）：

./llama-bench -m models/7B/ggml-model-q4_0.gguf

输出是一张 Markdown 表，列包括模型、backend、ngl（卸载到 GPU 的层数）、test 和 t/s：

注意两点：一是±后面的标准差，数值越小说明这几轮越稳定；二是 pp 和 tg 差一个数量级属正常现象——tg 每个 token 都要把整个模型权重过一遍，受显存带宽钳制，而 pp 是把多个 token 拼成矩阵一次算完，吃的是算力。

上图就是"批量"的本质：prefill 阶段把 512 个 token 的嵌入拼成大矩阵 A，和权重 B 一次乘完，GPU 自然吃得很饱。后面要调的-b参数，调的就是这块矩阵的切片大小。

🔁 扫 -ngl 找拐点：tg 从 13 t/s 到 131 t/s

默认-ngl -1表示把全部层丢给 GPU，但如果你只想把部分层放显存（比如留空间给 KV cache），就得逐档试。用逗号列出多个值，一条命令扫完 4 档：

./llama-bench -m models/7B/ggml-model-q4_0.gguf -ngl 10,20,30,35

两个结论都藏在数字里：只要还有一层留在 CPU 上，每步推理就要在主机内存和显存之间搬一次权重，tg 就被钉在 40 t/s 以下；35 层全卸载后，pp 从 881（34 层时）跳到 2400，说明最后几层的跨设备搬运代价远比想象中重。

纯 CPU 场景换成扫-t（线程数）：

./llama-bench -n 0 -n 16 -p 64 -t 1,2,4,8,16,32

pp 随线程线性上涨，但 tg 在 8 线程到峰值 16.71 后，16 线程反而回落到 15.32——逐字生成是内存带宽型任务，线程越多，核与核之间抢带宽越厉害，"线程越多越快"只对 pp 成立。

📊 把结果灌进 SQLite，每次升级自动对账

一次性对比靠表格就够了，但要追踪"换量化 / 换版本 / 换驱动"之后速度是涨是跌，得把结果留下来。-o sql会输出带建表语句的 SQL，里面包含 CPU 型号、GPU 型号、线程数、批大小等完整配置，直接喂给 sqlite3 即可入库：

./llama-bench -m models/7B/ggml-model-q4_0.gguf -o sql | sqlite3 bench.db

以后每次升级 llama.cpp 或换模型，跑同一条命令，再对比表里avg_ts一列，哪个版本引入了性能回退一目了然。llama.cpp 的 CI 就是用-o jsonl这套流程持续记录每次提交的性能数据，原理和你本地留痕完全一样。

一个小提醒：llama-bench的计时不含分词和采样时间，所以它测出的 tg 会比客户端实际体感略快一点，横向对比没问题，别拿它当绝对值。

跑完这三步，你手上就有了"设备 + 模型 + 参数组合"对应的可复现速度基线。下一步自然是把这份基线带上：换量化档位对比体积与速度的取舍，或者用-d预填充上下文，专门测长对话里生成阶段会不会掉速。

【免费下载链接】llama.cppLLM inference in C/C++项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp