llama.cpp 还是 vLLM？2026 年本地 LLM 推理引擎选型指南（附实测基准）

原文来源：llama.cpp vs. vLLM: Choosing the right local LLM inference engine — Red Hat 官方技术博客，用实测基准数据对比两大开源推理引擎，帮你按场景选型

想本地跑 LLM，绕不开两个名字：llama.cpp 和 vLLM。它们解决的是同一个问题——自己运行开源权重模型——但设计哲学截然相反：一个为"你手头已有的硬件"而生，一个为"生产环境的高并发"而生。Red Hat 的这篇官方文章用实测数据把两者的边界画得很清楚，本文翻译整理核心内容，末尾附选型总结。

为什么本地推理会存在

一切要从 2023 年 Meta 发布 Llama 2 说起。作为第一批可商用开源权重模型，Llama 2 第一次让"下载模型"和"拥有模型"划上等号——ChatGPT 这类托管服务早就有了，但那是租来的。Llama 2 你可以下载，可以拥有。

小问题只有一个：你大概率跑不动它。 Llama 2 有 7B、13B、70B 三个尺寸，最小的 7B 用原生精度跑也需要不小的 GPU 显存。而大多数开发者根本没有独立 NVIDIA GPU。"能下载"和"能运行"之间的这道鸿沟，催生了 llama.cpp 和 vLLM——它们各自解决了一半问题。

llama.cpp：消费级硬件的效率之王

llama.cpp 的出发点是一个朴素的问题：与其问"怎么搞到更大的 GPU"，不如问"怎么让模型在现有的硬件上跑起来"。

这个 C++ 写的轻量项目最初只是用来跑 Llama 模型的，如今已经成了消费级硬件上跑 LLM 的主流方式，靠的是几项关键优化：

量化：30GB 模型缩到 4GB

量化把模型权重从 16 位或 32 位浮点压缩到 4 位甚至 2 位整数。实践中，一个原本要 30GB 内存的模型可以缩到 4GB 左右——小到能塞进笔记本内存。代价是输出质量略有损失，但现代量化技术对大多数场景保持得相当好。Red Hat 自己的 FP8 和 INT8 基准测试显示，DeepSeek R1 量化后精度几乎无损。

llama.cpp 支持广泛使用的量化 GGUF 模型，部分后端（CUDA、Vulkan）搭配兼容的 int8 权重还能做激活量化。vLLM 也支持 FP8、INT8、INT4 等多种量化流程——两边的量化能力都够用，区别在应用方式。

GGUF：模型分发的实际标准

llama.cpp 项目引入了 GGUF（GPT-Generated Unified Format）——一种把模型权重和所有元数据（tokenizer 配置、架构细节、量化参数）打包进单个文件的格式。加载和切换模型变得飞快，它已经成为本地模型分发的事实标准。你在 Hugging Face 上翻量化模型时看到的 .gguf 文件，全是这个格式。

CPU 优先：让没有 GPU 的人也能跑

绝大多数个人电脑没有独立 GPU。llama.cpp 天生为 CPU 高效运行设计，有 GPU 时可选加速。这一个决定让本地 LLM 对几百万开发者敞开了大门，影响远超项目本身——你用的 Ollama 和 LM Studio 底层引擎就是 llama.cpp。

vLLM：为高并发生产环境而生

笔记本上跑一个模型很棒。但 10 个用户同时打你的模型接口呢？部署到 Kubernetes 呢？这就是 vLLM 的主场：面向生产推理，支持 NVIDIA GPU、Google TPU、AMD GPU、Intel 加速器等硬件，核心解决两个问题——KV cache 管理和 GPU 利用率。

连续批处理：不再让 GPU 空等

传统推理服务用静态批处理：一批请求要么等满一起跑，要么逐个排队。vLLM 的连续批处理按 token 粒度交错处理请求——10 个请求差不多同时到达时，它把它们的 token 生成交织在一起跑，而不是让 9 个干等。GPU 的每一刻都在干活。

PagedAttention：像操作系统管内存一样管 KV cache

每次模型处理提示词都会计算 KV cache（模型的"短期记忆"），供后续生成每个 token 时引用。这个缓存膨胀得很快——长对话或复杂提示词下，单个请求的 KV cache 能吃掉几十 GB 显存。而大多数硬件只有 10、40、80GB 显存，模型权重 + 并发用户的 KV cache 是实打实的内存挑战。

vLLM 的 PagedAttention 机制管理 KV cache 的方式，和操作系统管理虚拟内存一模一样：动态分配和释放块，最大化 GPU 利用率。这是 vLLM 吞吐优势的核心来源。

进阶能力：投机解码和 prefill/decode 分离

两个引擎都能配合投机解码：用一个小而快的"草稿"模型生成候选 token，大模型一次前向验证。草稿模型猜对了（可预测的 token 经常如此），一个验证步骤就拿到多个 token。

单节点部署终究会遇到内存上限、吞吐瓶颈和负载延迟。加 n+1 台推理服务器有时也不够——于是有了 llm-d 项目：把推理的 prefill（处理提示词）和 decode（生成 token）两个阶段拆分到不同硬件上，各自在 Kubernetes 上独立优化和扩缩容。

实测基准：单张 H200 上的正面对决

Red Hat 用自家的 GuideLLM 开源评测工具，在单张 NVIDIA H200 上用 Llama 3.1 8B（16 位全精度）实测了两个引擎，并发从 1 到 64 个用户。

先泼盆冷水：这份基准是数据中心 GPU 上的高并发服务场景，天然偏向 vLLM 的优势区间。llama.cpp 的典型场景是本地、单用户、CPU 优先、消费级硬件。结果应该读作"生产服务场景的对比"，而不是"一个引擎全面碾压另一个"。

吞吐：并发越高差距越大

单并发时两个引擎的 token 生成速率相当。差距从并发上升开始拉开：64 并发时，vLLM 每秒生成的 token 约为 llama.cpp 的 44 倍。

响应性：首 token 延迟的指数级分化

首 token 时间（TTFT）决定用户要等多久才看到第一个字，对交互式应用尤其关键。实测 vLLM 的 P99 TTFT 在所有并发级别都保持低且稳定；而 llama.cpp 的 TTFT 随并发指数级增长——64 并发时，用户要等 3 分多钟才收到第一个 token。原因是 llama.cpp 的顺序排队模型：请求一个一个处理，后来的排队。

选型指南：该用哪个？

好消息是：两个引擎都通过 OpenAI 兼容的 API 端点提供服务。无论你在做 RAG、AI Agent 还是任何和 LLM 对话的应用，在 llama.cpp、vLLM 或 OpenAI 托管 API 之间切换，本质上只是换个 URL，代码一行不用改。这给了你极大的选型自由度——先用本地引擎开发，上线再切生产服务，完全无痛。

具体怎么选，按场景对号入座：

一句话总结：单用户、本地、消费级硬件，选 llama.cpp；多用户、生产、GPU 集群，选 vLLM。两者不是竞争关系，而是覆盖了本地推理光谱的两端——而且因为 API 兼容，你完全可以两个都装，按需切换。

Red Hat 原文 | 详细基准对比 | llama.cpp 仓库 | vLLM 文档