llama.cpp 本地推理提速：三条优化路径实战

llama.cpp 本地推理提速三条优化路径实战【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp你刚把一个 GGUF 模型拉下来用 llama.cpp 跑了第一句 prompt然后盯着终端等它一个字一个字地吐3 token 每秒。你见过别人的 8B 机器跑出 30 t/s知道这里头不对劲。这篇文章写给会用命令行、但从没系统调过本地推理性能的开发者读完你知道慢在哪、量化等级怎么选、层数怎么卸第一波提速十分钟就能拿到手。十分钟跑通第一句输出最快路线是装预编译包conda install -c conda-forge llama.cppMac/Linux 还有 brewWindows 有 winget包里已经编好 CUDA、Metal 后端不用碰 CMake。需要改代码或自己编译的话git clone https://gitcode.com/GitHub_Trending/ll/llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j编出来是一组 llama-cli、llama-bench 等可执行文件。第一句输出甚至不用自己下模型-hf直接指向 GGUF 仓库默认拉 Q4_K_M 量化版./build/bin/llama-cli -hf ggml-org/gemma-3-4b-it-GGUF:Q4_K_M -p 打个招呼 -n 64卡在这一步时先看日志里loaded N backend(s)那一行如果只有 CPU说明 GPU 后端没编进去跑一下llama-cli --list-devices看它认出了什么设备安装和编译问题查安装文档。慢在哪先做三层归因慢的原因不是一类是三类。先算账再谈药方。算力层矩阵乘法吃掉了大头。Transformer 的前向传播像一间大厨房矩阵乘法是那口炖主料的锅归一化、激活函数都是调味动作。锅的效率和锅旁边搬东西的路线都取决于数据在内存里怎么摆CPU 内核就是为这个调过的。量化的好处之一是主料本身变紧凑了。内存层两样东西占着你的带宽。权重是员工花名册每一层前向都得把花名册从存储里翻一遍翻的速度由内存带宽这条走廊的宽度决定。KV缓存模型记下前面说过什么的会议记录则每多聊一句就多几页长上下文直接把它撑大。数据通路层卡在门口。模型拆一半在 CPU、一半在 GPU每个 token 都要在两处之间跑一趟像一道菜在两个厨房间来回传每步都要对暗号。CPU 侧多个线程抢同一撮核心也会互相拖慢。三层对应下面三条主线按收益从高到低排。主线 A选量化等级——没动过参数就先做这个一句话结论还在用 F16/BF16 文件的话换成 Q4_K_M 是单点收益最大的一步Q4_K_M 是多数场景的默认选择别纠结了。体积缩小约 4 倍花名册薄了每轮翻得就快。三个判断正在用 F16/BF16直接换 Q4_K_M-hf的量化后缀默认就是它或下载对应文件。换完还嫌慢通常不是量化的锅先看主线 B。想压到 Q3_K_M、IQ3_XXS先生成重要性矩阵llama-imatrix -m model-bf16.gguf -f 你的语料.txt -o imatrix.dat量化时喂给它精度损失明显更低。自己量化时用这条核心命令高精度 GGUF 进Q4_K_M 出./build/bin/llama-quantize --imatrix imatrix.dat model-bf16.gguf model-q4km.gguf Q4_K_M更多参数见量化文档。⚠️ 两个高频坑一对着已经量化过的文件再压不加--allow-requantize会让损失叠加二别迷信低比特掉到 Q4 以下困惑度衡量模型对文本意外程度的指标陡升省下的体积往往不值。任务偏代码或数学建议停在 Q5_K_M 或 Q8_0。量化解决搬多少下一个问题是搬去哪——这就是层卸载。主线 BGPU 层卸载——只肯动一个参数就动 -ngl一句话结论-ngl auto默认已经会自动裁剪到装得下的层数最大的坑不是没卸够而是卸了一半。显存够就上all显存严重不够时纯 CPU 反而比来回折腾快。场景起步配置理由单卡显存装得下-ngl all全上 GPU最快单卡显存紧-ngl auto默认自动裁层不用手算单卡显存严重不足-ngl 0-t 物理核心数纯 CPU别半卸多卡--split-mode layer-mg 0按层拆分主卡扛 KV单卡推荐命令./build/bin/llama-cli -m model-q4km.gguf -ngl all -t 8 -fa on-t给物理核心数超线程的逻辑核不提速-fa on开 FlashAttention注意力时少搬 KV 数据。⚠️ 坑点① 最典型是卸了 40 层比纯 CPU 还慢正是半卸场景要么减-ngl、要么干脆--no-kv-offload全留 CPU②-t别大于物理核心数线程越多内耗越狠。模型摆好之后剩下的变量是上下文。主线 C上下文与 KV 缓存——撞到墙再动一句话结论-c默认别改0 表示用模型自带值确实要长文本才调大显存吃紧时用 KV 缓存的数据类型换空间。什么时候动塞长文档、长对话撞到context 已满的墙 → 调大-c比如-c 8192。调大后 OOM 或变慢 → 把--cache-type-k和--cache-type-v从默认 f16 降到 bf16 或 q8_0。副作用说在前面KV 缓存内存随-c线性增长生成速度也跟着掉缓存量化省显存但精度略降超出模型原生长度还依赖 RoPE/YaRN 缩放否则长文本质量滑坡。./build/bin/llama-cli -m model-q4km.gguf -c 8192 -ctk q8_0 -ctv q8_0 -fa on⚠️-fa默认 auto 会自己尝试开启不支持的卡回退 off 即可别硬开。决策树你的硬件走哪条路不用背参数对着下面这张图找你的机器拿起步配置就行先跑起来再说纯 CPU 路线多一步 NUMA多路机器加--numa distribute让线程和内存节点别跨节点伸手。集显路线记住它是和系统共享内存的-c开小一点。建立你自己的数字llama-bench 一条命令任何网上的速度数字都不要信。用自带的 llama-bench最小命令就一条llama-bench -m model-q4km.gguf -p 512 -n 128它测两件事处理 512 token 的 prompt预填充再生成 128 token各跑多轮取平均。完整参数见llama-bench 文档。方法论只有一句先测基线 → 改一个参数 → 再测 → 对比。一次只动一个变量否则数字没有解释力。你的记录表长这样只改一个变量t/s prompt 512t/s generate 128默认基线填你自己的数填你自己的数-ngl all填你自己的数填你自己的数-ctk/-ctv q8_0填你自己的数填你自己的数数字只有落在你自己机器上才有意义别人的 4090 上 38 t/s你的 M 系笔记本可能就是 12。三件现在就能做的事跑一遍 llama-bench把默认配置的输出存下来——这是你的基线没基线就不要做任何优化。还在跑 F16/BF16 文件的立刻换成 Q4_K_M这一步的收益比任何单个参数都大。有独立显卡的llama-cli --list-devices确认认出了 GPU然后设-ngl all再测一次和基线对比。速度还嫌慢的话下一步可以去试投机解码小模型打草稿、大模型验收见 docs/speculative.md把生成阶段再往上抬一截。【免费下载链接】llama.cppLLM inference in C/C项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考