llama.cpp 本地推理性能优化实战：从默认配置到带宽极限的四步路径

llama.cpp 本地推理性能优化实战从默认配置到带宽极限的四步路径【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp用 llama-server 默认参数部署 gpt-oss-20b4096 个 token 的 prompt 预填充要 0.9 秒一次 32 token 的生成还要 0.4 秒几个并发请求就能把显存吃满。这些数字不是模型造成的是你从没动过的默认配置造成的。本文按 llama.cpp 本地推理性能优化的完整路径走一遍基线、压缩、调度算力、扩上下文所有数据都能在项目 benches 目录的实测记录里复现。你将拿到什么用llama-bench建立可复现的性能基线附可直接执行的命令用 imatrix 控制 4-bit 量化质量损失并把体积压到 bf16 的 1/4用-ngl扫描找出层卸载的速度悬崖位置用 KV cache 数据类型压缩上下文内存并测出 32K 上下文的真实代价一张参数决策表什么场景先动哪个参数1. 建立基线用 llama-bench 测出 pp/tg 起点不做基准测量的调参全是猜测。llama-bench 把 prompt 处理pp和文本生成tg拆开独立测量默认重复 5 次输出均值和标准差还内置了-d参数用于预填充 KV cache 模拟长上下文是这套优化路径的起点也是终点。# 基线测量512 token 预填充 32 token 生成 ./llama-bench -m gpt-oss-20b.gguf -p 512 -n 32 # 模拟 32K 上下文下的生成速度-d 预填充 KV cache ./llama-bench -m gpt-oss-20b.gguf -p 0 -n 32 -d 32768效果如何以仓库 benches/dgx-spark/dgx-spark.md 的实测为参照gpt-oss-20b MXFP420.91B 参数11.27 GiBGB10 显卡flash_attn120 线程基线是 pp2048 达 4505.82 t/stg32 为 83.43 t/s。同一个模型在 M2 Ultra 上MetalBLAS16 线程记录见 benches/mac-m2-ultra/mac-m2-ultra.mdtg32 反而更高129.97 t/s。这说明两件事pp 和 tg 是两种不同的瓶颈前者偏算力后者偏内存带宽跨硬件对比必须分开看tg 快的那台机器瓶颈在带宽而不是算力。项目设置模型gpt-oss-20b MXFP420.91B 参数11.27 GiB硬件 ANVIDIA GB10CUDA20 线程flash_attn1硬件 BM2 UltraMetalBLAS16 线程flash_attn1基线 pp20484505.82 t/s / 2713.40 t/s基线 tg3283.43 t/s / 129.97 t/s2. 压缩模型先做 imatrix 再量化直接对 16-bit 文件做 4-bit 量化精度损失取决于哪些张量侥幸被保留k-quant 系列如 Q4_K_M默认按重要性混用多种块类型--pure可以关掉混合强制单一类型。imatrix 文件记录了真实语料下的激活分布让量化误差集中到不重要的权重上这是低成本量化质量的第一保障。# 1) HF 权重转 16-bit GGUF python convert_hf_to_gguf.py --remote meta-llama/Llama-3-8B-Instruct --outtype bf16 --outfile m-bf16.gguf # 2) 用代表性语料生成重要性矩阵 ./llama-imatrix -m m-bf16.gguf -f wikitext-103-raw-v1.train.txt -o imatrix.dat # 3) 带 imatrix 量化并保留输出层精度 ./llama-quantize --imatrix imatrix.dat --leave-output-tensor m-bf16.gguf m-Q4_K_M.gguf Q4_K_M效果如何6.74B 参数模型 Q4_0 版文件 3.56 GiBllama-bench 实测记录值同参数 bf16 约 13.5 GiB体积压缩 3.8 倍加载时的显存压力同比例下降。两个容易踩的坑从已量化文件再量化时必须加--allow-requantize但质量损失明显大于从 bf16 起步output.weight是最值得单独保精度的张量--leave-output-tensor或--output-tensor-type q8_0二选一即可。选项细节见 tools/quantize/README.md。3. 调度算力用 -ngl 扫出层卸载的速度悬崖混合 CPU/GPU 推理中每一层留在 CPU 上每个 token 都要走一次 CPU↔GPU 往返。tg 速度在混合模式下不是线性下降而是断崖式的——最后几层留在 CPU 上的代价最高。# 扫描层卸载数10/20/30/32/35其余参数保持不变 ./llama-bench -m llama-7b-q4_0.gguf -p 512 -n 128 -ngl 10,20,30,32,35效果如何tools/llama-bench/README.md 的实测llama 7B Q4_03.56 GiBCUDA显示 tg128 从 ngl10 的 13.45 t/s 升到 20 层的 21.36、30 层的 40.04而最后几层进 GPUngl32/35后跳到 54.78131.66 t/spp512 同区间从 373 涨到 2400 t/s。结论很直接显存不够时宁可全放 GPU 后换更小的量化也不要做半吊子卸载中间态最差。多卡场景用-sm layer/row选分割模式-main-gpu指定主卡。纯 CPU 机器要调的是线程和批大小同一份 README 里有现成对照pp64 在 t8 时 32.29 t/s、t16 时 33.52、t32 时 59.00但 tg16 在 t8 是 16.71 t/s、t16 反而回落到 15.32——tg 是带宽瓶颈线程多了只有争用没有收益物理核心数是起点而非上限。批大小决定 pp 上限7B Q4_0 的 pp1024 从 b128 的 1436.51 t/s 提到 b1024 的 2498.61 t/s74%-ububatch默认 512内存峰值吃得下就先提它。CPU 侧性能优化的主战场是 GEMM 的访存模式下图解释了为什么不同数据排布会导致数量级的速度差如果目标设备是手机examples/llama.android/ 提供现成 CMake 工程可以直接在 Android Studio 里构建构建日志会显示按 ARMv8.6 / armv9.2 自动启用 SME、SVE2 内核4. 扩展上下文KV cache 量化与 flash attentionKV cache 随上下文线性增长默认 f16 时它的体积在长上下文下会超过权重本身注意力计算还会让 tg 速度随已缓存 token 数持续下滑。# KV cache 用 q8_0 存储内存约减半开 flash attention ./llama-cli -m m-Q4_K_M.gguf -c 32768 -ctk q8_0 -ctv q8_0 -fa on-ctk/-ctv允许 f32、f16、bf16、q8_0、q4_0、q4_1、iq4_nl、q5_0、q5_1默认 f16见 tools/completion/README.md。q8_0 是精度损失与内存减半之间的平衡点q4_0 再省一半但长对话下累积误差会变大谨慎使用。效果如何同一 GB10 上 20B 模型 tg32 随上下文深度的衰减是 83.43d0→ 79.224K→ 75.228K→ 70.3616K→ 61.65 t/s32K32K 上下文吃掉约 26% 的生成速度且这是在 flash_attn1 下的数字。120B MoE 同区间从 58.72 掉到 42.76-27%。需要 32K 上下文时q8_0 KV -fa on是起点再用-c和-ub控制内存峰值最后用第 1 节的-d 32768命令验收。5. 验证一条命令复现改进优化路径的终点不是感觉变快了而是同一模型、同一测试项的前后数字差。# 对比同一模型在 ngl0 与全卸载下的 pp/tgJSON 归档便于回归 ./llama-bench -m m-Q4_K_M.gguf -p 512 -n 32 -d 0,32768 -ngl 0,-1 -o jsonJSON 输出包含完整配置快照线程、批大小、数据类型、设备信息和 5 次重复的原始样本适合存进版本库做回归对比。四步跑完后如果你无法用基线命令复现第 3、4 节的改进说明中间某步被环境吞掉了常见于驱动版本和后端选择变化。6. 速查表参数决策一览参数默认值起步建议什么时候动它-ngl-1全卸载显存吃满为止不做半卸载混合模式下 tg 断崖下跌-t系统相关物理核心数线程加倍后 tg 反而下降-b/-ub2048 / 512内存允许就提高 ubatchpp 速度上不去-ctk/-ctvf16q8_0长上下文 OOM-faautoon上下文 ≥8K 且 tg 衰减明显--imatrix无代表性语料生成低比特量化的精度要求高整条优化路径收敛到一个标准数字可复现。改完任何参数跑一遍第 1 节的基线命令确认差异再归档。 下一步用你自己的硬件和模型把-ngl、-t、-ctk三组参数各扫一轮得到只属于你的那张决策表。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考