llama.cpp 与 GGUF 本地推理
查看所有标签开源模型现在是一周一个的节奏：Kimi-K3 那篇 2.8T 的 MoE 还没消化完，DeepSeek V4 Flash 就以 284B 参数打出了「智能指数 50」的性价比，隔一周又是 GLM-5.3 把编程 Agent 安全做成卖点（见 GLM-5.3 编程 Agent 安全拆解）。对后端工程师来说，选型已经不是一个「调研一次、用半年」的静态决策，而是一个持续跟踪、反复评估、随时切换的工程问题。本文不讲具体某个模型的评测报告，讲怎么建立自己的评估框架：看什么动态、躲什么 License 坑、怎么用自家任务集跑分。
公司那台 K8s worker 是台「三无」机器：无 GPU、4 核 8 线程（AMD EPYC 9754）、30GB 内存，CentOS 7 + nerdctl，还要兼顾集群负载。我在上面用 llama-server 跑了一个给 IDE 用的代码补全/问答服务，模型从 16B 的 DeepSeek-Coder-V2-Lite 到 135M 的 SmolLM2 随意切换。这篇把选型账本和踩坑记录写下来：量化怎么选、KV Cache 每个 token 到底吃掉多少内存、CPU 上 prefill 为什么比 decode 还慢、KV cache 满载时日志长什么样。上一篇讲了 CentOS 7 + nerdctl 编译 llama.cpp 的完整流程，这篇是运行期的优化。GPU 侧的理论对比（Continuous Batching、PagedAttention）见 vLLM 推理面试题，投机解码 是另一条优化路线，这里只谈 CPU 上最现实的三个杠杆：量化、KV Cache、并发槽位。
云服务器上搭 LLM 推理环境，最怕的不是模型本身，而是操作系统太老。本文记录在一台 CentOS 7 + nerdctl（containerd 系容器运行时）的服务器上，从裸系统到跑通 llama.cpp 编译、推理、HTTP 服务的完整过程，包括一个可复现的 Dockerfile 和全部踩坑记录。
开源 LLM 怎么部署，取决于你手里有什么算力、要服务多少人。本文不讨论引擎内部机制（选型见推理引擎选型），只给端到端部署方案：按算力场景分四档，每档给可跑命令、显存预算和踩坑。