llama-bench 性能基准测试3 个参数拉满本地 LLM 推理速度【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cppllama.cpp 的性能基准测试工具 llama-bench将一次模型跑分拆为 PPPrompt Processing提示词处理速度和 TGText 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然后指定一个 GGUFllama.cpp 的模型文件格式文件跑默认组合 pp512 tg128./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf典型输出是一张 Markdown 表t/s 后面的 ± 是标准差越小测量越稳定testt/spp5122368.80±93.24tg128131.42±0.59注意 llama-bench 的计时不含分词与采样耗时测的是纯推理计算。实现细节可看 llama-bench 源码。默认表只是基线三种测试模式量的东西并不相同。读懂测试模式与输出参数模式用途-p nPP只处理 n 个 token 的提示词评估长文档理解与首 token 延迟-n nTG只生成 n 个 token评估对话输出的流畅度-pg pp,tgPG先处理再生成模拟一轮真实对话同一份结果可用-o导出四种格式下游用途各异格式适合场景md默认直接贴进 README 或 PR 描述csvExcel 透视表、脚本批量筛选jsonPython 可视化、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,35nglpp512 t/stg128 t/s10373.36±2.2513.45±0.9320472.65±1.2521.36±1.94352400.01±7.72131.66±0.4935 是全量卸载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 16threadspp64 t/stg16 t/s423.18±0.0612.22±0.07832.29±1.2116.71±0.661633.52±0.0315.32±0.05PP 到 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 0n_batchpp1024 t/s1281436.51±3.662561932.43±23.4810242498.61±13.58batch 越大单次矩阵运算越能喂饱 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），仅供参考 llama-bench 性能基准测试：3 个参数拉满本地 LLM 推理速度
llama-bench 性能基准测试3 个参数拉满本地 LLM 推理速度【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cppllama.cpp 的性能基准测试工具 llama-bench将一次模型跑分拆为 PPPrompt Processing提示词处理速度和 TGText 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然后指定一个 GGUFllama.cpp 的模型文件格式文件跑默认组合 pp512 tg128./build/bin/llama-bench -m models/7B/ggml-model-q4_0.gguf典型输出是一张 Markdown 表t/s 后面的 ± 是标准差越小测量越稳定testt/spp5122368.80±93.24tg128131.42±0.59注意 llama-bench 的计时不含分词与采样耗时测的是纯推理计算。实现细节可看 llama-bench 源码。默认表只是基线三种测试模式量的东西并不相同。读懂测试模式与输出参数模式用途-p nPP只处理 n 个 token 的提示词评估长文档理解与首 token 延迟-n nTG只生成 n 个 token评估对话输出的流畅度-pg pp,tgPG先处理再生成模拟一轮真实对话同一份结果可用-o导出四种格式下游用途各异格式适合场景md默认直接贴进 README 或 PR 描述csvExcel 透视表、脚本批量筛选jsonPython 可视化、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,35nglpp512 t/stg128 t/s10373.36±2.2513.45±0.9320472.65±1.2521.36±1.94352400.01±7.72131.66±0.4935 是全量卸载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 16threadspp64 t/stg16 t/s423.18±0.0612.22±0.07832.29±1.2116.71±0.661633.52±0.0315.32±0.05PP 到 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 0n_batchpp1024 t/s1281436.51±3.662561932.43±23.4810242498.61±13.58batch 越大单次矩阵运算越能喂饱 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），仅供参考