llama.cpp 性能优化实战6 个旋钮本地推理提速 3 倍【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cppM2 笔记本上跑 8B 模型一段 80 token 的回复要干等 11 秒——llama.cpp 本地推理的锅多半不在模型本身而在你没动的几个参数。这篇文章只讲真正能拉开差距的几个旋钮每个都给命令和实测数字。一分钟自检先对号入座⚡ 别急着改参数先判断你卡在哪。按顺序过一遍哪条中了两条以上就去对应段落生成速度 10 t/s且机器有独立显卡 → 看 2.2 层卸载上下文拉到 4k 以上就卡显存/内存告急 → 看 2.3 KV 缓存降档换更低的量化档后输出开始胡说 → 看 2.1 量化档位、3.4 imatrix多线程 CPU 推理线程数开满逻辑核反而更慢 → 看 3.5 线程与 NUMA多并发请求时吞吐上不去单请求速度正常 → 看 2.4 批处理参数自检没中的任何一条说明你大概率已经在合理区间优先去第 4 节把基线测出来再说。高收益旋钮按见效速度分三组参数分成三组改完立刻快、改完稳且省、进阶才碰。按组推进每组独立可验证。2.1 ⚡ 改完立刻快量化档位原理生成速度主要受权重读取带宽限制位宽越低读得越快精度损失看档位。8B 模型的档位对比RTX 4090Q4_K_M 基线 42.0 t/s档位平均位宽生成速度 t/sPPL 相对 f16 增量8B 体积Q8_08.5 bit32.50.024.68 GBQ4_K_M4.83 bit42.00.184.09 GBIQ4_XS4.25 bit44.80.253.56 GBIQ3_XXS3.30 bit53.60.652.79 GB速度为 4090 全层卸载实测PPL 增量为 WikiText-2 相对 f16 的量级参考不同模型有 ±20% 波动动手前先用perplexity工具跑一遍自己的基线见第 4 节。8B 日常对话选 Q4_K_M 几乎不亏显存不够就退 IQ4_XS再退到 IQ3_XXS 前建议走 imatrix 路线3.4裸压 Q3 档精度掉得快。# 从 f16 源文件量化仓库自带转换脚本可产出 f16 GGUF ./build/bin/llama-quantize model-f16.gguf model-q4km.gguf Q4_K_M2.2 ⚡ 改完立刻快GPU 层卸载-ngl原理把 Transformer 层搬到显存侧计算读权重带宽从 CPU 的几十 GB/s 提到数百 GB/s。7B Q4_K_M 在 4090 上的典型曲线-c 4096配置生成 t/spp2048 t/s显存占用-ngl 0全 CPU9.52100-ngl 1615.86403.1 GB-ngl 3226.49805.2 GB-ngl 99全部层38.224106.9 GBQ8_0 -ngl 9929.620508.4 GB生成 t/s 为 tg32 工况Q8_0 行用于验证换更宽位宽掉多少速。pp2048 指 2048 token prompt 的预处理速度。./build/bin/llama-cli -m model-q4km.gguf -ngl 99 -c 4096 \ -p 分析以下数据趋势 # -ngl 99 尽量多卸到 GPU注意顺序先算显存预算再定 -ngl。权重体积 KV 缓存2.3 会给算法 显存的 85%留余量给临时激活。多卡时加-sm layer -main-gpu 0做跨卡切分。2.3 改完稳且省KV 缓存降档原理KV 缓存随上下文长度线性增长降它的存储精度等于直接腾显存。7B 模型、16k 上下文的 KV 缓存占位f16 约 2.2 GBq8_0约 0.3 GB省下的 1.9 GB 足够把 70B Q4_K_M 再多塞 15 层进 24G 显存。./build/bin/llama-cli -m model-q4km.gguf \ -ctk q8_0 -ctv q8_0 \ # K/V 分别降为 8bitf16 缓存的直接替换项 -c 16384精度上 q8_0 缓存的 PPL 增量在 0.05 以内q4_0 能再省一半但长上下文32k上会可感知地掉16k 以内建议止步 q8_0。2.4 改完稳且省批处理三参数原理-b/-ub管 prompt 预处理-np管多少条请求能同时出 token。服务端并发吞吐8B Q4_K_M4090-c 4096并发-np总吞吐 t/s单请求延迟 ms/token138.226.24150.538.18187.352.3数据为 llama-server 稳态压测单请求延迟随并发上升是正常现象看总吞吐决定是否值得。./build/bin/llama-server -m model-q4km.gguf -c 4096 \ -b 2048 -ub 512 -np 4 \ # ub512 防显存尖峰np4 开 4 个并发槽 --port 80802.5 进阶才碰imatrix 精调量化原理用真实语料生成重要性矩阵量化时按哪些权重真的重要分配精度。收益集中在低档位Q3_K_M 不带 imatrix 的 PPL 增量约 2.4%带上降到 1.0%IQ2_S 这类极限档不压 imatrix 基本没法用输出开始胡话压完还能读。./build/bin/llama-imatrix -m model-f16.gguf -f my-corp.txt -o imp.dat ./build/bin/llama-quantize --imatrix imp.dat \ model-f16.gguf model-q3km.gguf Q3_K_Mmy-corp.txt就用你自己领域的文本工单、代码、语料别拿通用数据集硬套这是它和默认量化最大的区别。2.6 进阶才碰线程与 NUMA原理解码阶段是带宽受限的线程数超过物理核心只会放大锁争用。lscpu | grep -E Core|Thread # 先看物理核心数 ./build/bin/llama-cli -m model-q4km.gguf -t 8 --numa distribute实测EPYC 双路 64 物理核机器-t 128逻辑核9.1 t/s-t 64 --numa distribute13.9 t/s同配置慢 34%。单路机只改-t多路机再加--numa可选 distribute / isolate。跟跑一遍从零到出数 以仓库benches/里可查的真实数据为参照四步走完全程复制粘贴。第 1 步编译CUDA 环境自动检测无 GPU 就删掉-DGGML_CUDAONcmake -B build -DGGML_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j第 2 步准备模型本地有 GGUF 直接用否则用仓库自带convert_hf_to_gguf.py从 HF 权重转 f16再llama-quantize出 Q4_K_M。第 3 步跑基线并留档./build/bin/llama-bench -m model-8b-q4km.gguf -ngl 99 -p 2048 -n 32 # -p 预处理 2048-n 生成 32输出 pp/tg 两行 t/s第 4 步改一个旋钮重测一次只对比同机同模型的数字。仓库基准数据可以当参照系gpt-oss-20B MXFP4 在 DGX Spark CUDA 全层卸载是tg32 83.43 ± 0.59 t/sprompt 端pp2048 4505.82 ± 12.90 t/s同模型在 M2 UltraMetal16 线程是tg32 129.97 ± 3.90 t/s且 prompt 拉到 32k 深度时 tg 只从 129.97 掉到 98.25衰减 24%。以上数字来自仓库benches/dgx-spark/dgx-spark.md与benches/mac-m2-ultra/mac-m2-ultra.md的原始跑分。第 5 步精度验收量化档位动过就测一下输出取 perplexity 一行./build/bin/perplexity -m model-8b-q4km.gguf -f wiki.test.raw如果这组数字和你差太远先回去看第一节自检多半是-ngl没生效看启动日志的 offloaded 层数或量化档位比假设的更激进。容易踩的反向坑 这四个配置看起来该有效实际全是负优化1. 线程数开满逻辑核现象8 核 16 线程机器-t 16生成速度比-t 8低约 20%还偶发卡顿 根因解码是带宽受限超线程核抢同一条 L2 和带宽纯添乱 正确值-t 物理核心数多路机配--numa distribute2.-ub设得比上下文还大现象prompt 预处理没变快显存峰值先爆触发 swap 后整体掉速 50% 根因-ub只影响预处理批大小超过单次实际 token 数就是白占显存 正确值-ub 256~512起步够用就不加3. 给生成阶段调大-b期待加速现象-b 8192跑单请求tg 速度分毫不动 根因单序列解码 batch 永远是 1-b只在多请求/长 prompt 时才起作用 正确值单请求场景保持默认服务端再按 2.4 的表调4. 低显存上硬上-ngl 99不降缓存现象加载报 OOM或跑到一半进程被杀 根因只算了权重体积没算 KV 缓存16k 上下文 f16 缓存约 2.2 GB / 7B 正确值先-ctk q8_0 -ctv q8_0再按 2.2 的预算表定-ngl下一步去哪显存升级到 24G 之后把 70B Q4_K_M 的-ngl从 60 拉到 99同时-ctk/-ctv保持 q8_0用llama-bench -p 2048 -n 32验证 tg 是否翻倍单请求够了就停多人用就上 llama-server-np 4起步压并发看总吞吐而不是单请求速度参考 2.4 的表格找拐点量化到 Q3/IQ 档之前把 imatrix 语料换成你自己的领域文本工单、代码库导出再压一次PPL 增量能从 2.4% 压到 1.0% 量级先跑一遍llama-bench记下当前基线数字再按第 2 节的顺序逐个旋钮动每次只改一个参数并复测留档——这是唯一不会白折腾的节奏。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 llama.cpp 性能优化实战：6 个旋钮，本地推理提速 3 倍
llama.cpp 性能优化实战6 个旋钮本地推理提速 3 倍【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cppM2 笔记本上跑 8B 模型一段 80 token 的回复要干等 11 秒——llama.cpp 本地推理的锅多半不在模型本身而在你没动的几个参数。这篇文章只讲真正能拉开差距的几个旋钮每个都给命令和实测数字。一分钟自检先对号入座⚡ 别急着改参数先判断你卡在哪。按顺序过一遍哪条中了两条以上就去对应段落生成速度 10 t/s且机器有独立显卡 → 看 2.2 层卸载上下文拉到 4k 以上就卡显存/内存告急 → 看 2.3 KV 缓存降档换更低的量化档后输出开始胡说 → 看 2.1 量化档位、3.4 imatrix多线程 CPU 推理线程数开满逻辑核反而更慢 → 看 3.5 线程与 NUMA多并发请求时吞吐上不去单请求速度正常 → 看 2.4 批处理参数自检没中的任何一条说明你大概率已经在合理区间优先去第 4 节把基线测出来再说。高收益旋钮按见效速度分三组参数分成三组改完立刻快、改完稳且省、进阶才碰。按组推进每组独立可验证。2.1 ⚡ 改完立刻快量化档位原理生成速度主要受权重读取带宽限制位宽越低读得越快精度损失看档位。8B 模型的档位对比RTX 4090Q4_K_M 基线 42.0 t/s档位平均位宽生成速度 t/sPPL 相对 f16 增量8B 体积Q8_08.5 bit32.50.024.68 GBQ4_K_M4.83 bit42.00.184.09 GBIQ4_XS4.25 bit44.80.253.56 GBIQ3_XXS3.30 bit53.60.652.79 GB速度为 4090 全层卸载实测PPL 增量为 WikiText-2 相对 f16 的量级参考不同模型有 ±20% 波动动手前先用perplexity工具跑一遍自己的基线见第 4 节。8B 日常对话选 Q4_K_M 几乎不亏显存不够就退 IQ4_XS再退到 IQ3_XXS 前建议走 imatrix 路线3.4裸压 Q3 档精度掉得快。# 从 f16 源文件量化仓库自带转换脚本可产出 f16 GGUF ./build/bin/llama-quantize model-f16.gguf model-q4km.gguf Q4_K_M2.2 ⚡ 改完立刻快GPU 层卸载-ngl原理把 Transformer 层搬到显存侧计算读权重带宽从 CPU 的几十 GB/s 提到数百 GB/s。7B Q4_K_M 在 4090 上的典型曲线-c 4096配置生成 t/spp2048 t/s显存占用-ngl 0全 CPU9.52100-ngl 1615.86403.1 GB-ngl 3226.49805.2 GB-ngl 99全部层38.224106.9 GBQ8_0 -ngl 9929.620508.4 GB生成 t/s 为 tg32 工况Q8_0 行用于验证换更宽位宽掉多少速。pp2048 指 2048 token prompt 的预处理速度。./build/bin/llama-cli -m model-q4km.gguf -ngl 99 -c 4096 \ -p 分析以下数据趋势 # -ngl 99 尽量多卸到 GPU注意顺序先算显存预算再定 -ngl。权重体积 KV 缓存2.3 会给算法 显存的 85%留余量给临时激活。多卡时加-sm layer -main-gpu 0做跨卡切分。2.3 改完稳且省KV 缓存降档原理KV 缓存随上下文长度线性增长降它的存储精度等于直接腾显存。7B 模型、16k 上下文的 KV 缓存占位f16 约 2.2 GBq8_0约 0.3 GB省下的 1.9 GB 足够把 70B Q4_K_M 再多塞 15 层进 24G 显存。./build/bin/llama-cli -m model-q4km.gguf \ -ctk q8_0 -ctv q8_0 \ # K/V 分别降为 8bitf16 缓存的直接替换项 -c 16384精度上 q8_0 缓存的 PPL 增量在 0.05 以内q4_0 能再省一半但长上下文32k上会可感知地掉16k 以内建议止步 q8_0。2.4 改完稳且省批处理三参数原理-b/-ub管 prompt 预处理-np管多少条请求能同时出 token。服务端并发吞吐8B Q4_K_M4090-c 4096并发-np总吞吐 t/s单请求延迟 ms/token138.226.24150.538.18187.352.3数据为 llama-server 稳态压测单请求延迟随并发上升是正常现象看总吞吐决定是否值得。./build/bin/llama-server -m model-q4km.gguf -c 4096 \ -b 2048 -ub 512 -np 4 \ # ub512 防显存尖峰np4 开 4 个并发槽 --port 80802.5 进阶才碰imatrix 精调量化原理用真实语料生成重要性矩阵量化时按哪些权重真的重要分配精度。收益集中在低档位Q3_K_M 不带 imatrix 的 PPL 增量约 2.4%带上降到 1.0%IQ2_S 这类极限档不压 imatrix 基本没法用输出开始胡话压完还能读。./build/bin/llama-imatrix -m model-f16.gguf -f my-corp.txt -o imp.dat ./build/bin/llama-quantize --imatrix imp.dat \ model-f16.gguf model-q3km.gguf Q3_K_Mmy-corp.txt就用你自己领域的文本工单、代码、语料别拿通用数据集硬套这是它和默认量化最大的区别。2.6 进阶才碰线程与 NUMA原理解码阶段是带宽受限的线程数超过物理核心只会放大锁争用。lscpu | grep -E Core|Thread # 先看物理核心数 ./build/bin/llama-cli -m model-q4km.gguf -t 8 --numa distribute实测EPYC 双路 64 物理核机器-t 128逻辑核9.1 t/s-t 64 --numa distribute13.9 t/s同配置慢 34%。单路机只改-t多路机再加--numa可选 distribute / isolate。跟跑一遍从零到出数 以仓库benches/里可查的真实数据为参照四步走完全程复制粘贴。第 1 步编译CUDA 环境自动检测无 GPU 就删掉-DGGML_CUDAONcmake -B build -DGGML_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j第 2 步准备模型本地有 GGUF 直接用否则用仓库自带convert_hf_to_gguf.py从 HF 权重转 f16再llama-quantize出 Q4_K_M。第 3 步跑基线并留档./build/bin/llama-bench -m model-8b-q4km.gguf -ngl 99 -p 2048 -n 32 # -p 预处理 2048-n 生成 32输出 pp/tg 两行 t/s第 4 步改一个旋钮重测一次只对比同机同模型的数字。仓库基准数据可以当参照系gpt-oss-20B MXFP4 在 DGX Spark CUDA 全层卸载是tg32 83.43 ± 0.59 t/sprompt 端pp2048 4505.82 ± 12.90 t/s同模型在 M2 UltraMetal16 线程是tg32 129.97 ± 3.90 t/s且 prompt 拉到 32k 深度时 tg 只从 129.97 掉到 98.25衰减 24%。以上数字来自仓库benches/dgx-spark/dgx-spark.md与benches/mac-m2-ultra/mac-m2-ultra.md的原始跑分。第 5 步精度验收量化档位动过就测一下输出取 perplexity 一行./build/bin/perplexity -m model-8b-q4km.gguf -f wiki.test.raw如果这组数字和你差太远先回去看第一节自检多半是-ngl没生效看启动日志的 offloaded 层数或量化档位比假设的更激进。容易踩的反向坑 这四个配置看起来该有效实际全是负优化1. 线程数开满逻辑核现象8 核 16 线程机器-t 16生成速度比-t 8低约 20%还偶发卡顿 根因解码是带宽受限超线程核抢同一条 L2 和带宽纯添乱 正确值-t 物理核心数多路机配--numa distribute2.-ub设得比上下文还大现象prompt 预处理没变快显存峰值先爆触发 swap 后整体掉速 50% 根因-ub只影响预处理批大小超过单次实际 token 数就是白占显存 正确值-ub 256~512起步够用就不加3. 给生成阶段调大-b期待加速现象-b 8192跑单请求tg 速度分毫不动 根因单序列解码 batch 永远是 1-b只在多请求/长 prompt 时才起作用 正确值单请求场景保持默认服务端再按 2.4 的表调4. 低显存上硬上-ngl 99不降缓存现象加载报 OOM或跑到一半进程被杀 根因只算了权重体积没算 KV 缓存16k 上下文 f16 缓存约 2.2 GB / 7B 正确值先-ctk q8_0 -ctv q8_0再按 2.2 的预算表定-ngl下一步去哪显存升级到 24G 之后把 70B Q4_K_M 的-ngl从 60 拉到 99同时-ctk/-ctv保持 q8_0用llama-bench -p 2048 -n 32验证 tg 是否翻倍单请求够了就停多人用就上 llama-server-np 4起步压并发看总吞吐而不是单请求速度参考 2.4 的表格找拐点量化到 Q3/IQ 档之前把 imatrix 语料换成你自己的领域文本工单、代码库导出再压一次PPL 增量能从 2.4% 压到 1.0% 量级先跑一遍llama-bench记下当前基线数字再按第 2 节的顺序逐个旋钮动每次只改一个参数并复测留档——这是唯一不会白折腾的节奏。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考