llama.cpp vs vLLM：深度解析与选型指南

原创于 2026-06-16 07:49:45 发布 · 499 阅读

本内容遵循CC 4.0 BY-SA版权协议

标签

#llama #vllm

作为当前最受关注的两大LLM推理引擎，llama.cpp和vLLM分别代表了极致轻量与高效生产两种截然不同的设计哲学。它们并非简单的“谁更强”的关系，而是面向不同场景、解决不同问题的专业工具。本文从原理、性能、适用场景全维度深入解析。

一、核心定位与设计哲学

llama.cpp：一切从“能跑”开始

llama.cpp 是由 Georgi Gerganov 用纯 C/C++ 实现的推理引擎，初衷是让大模型在普通笔记本、甚至树莓派上运行。它的核心追求是极致的硬件兼容性和资源效率，采用自定义的 GGUF 格式实现模型的高效存储和加载，支持从 INT2 到 INT8 的几十种量化级别，让 7B 模型只需 4GB 内存即可运行。可以说，llama.cpp “解决能不能跑的问题”，将大模型的硬件门槛降到了最低。

vLLM：为生产环境的“能跑多少”而生

vLLM 是一个 Python 编写的生产级推理服务框架，由 UC Berkeley 开发，其设计目标是最大化 GPU 利用率和高并发吞吐。核心创新是 PagedAttention 技术——像操作系统管理虚存一样管理 KV Cache，统一分配固定大小的 Block，彻底解决显存碎片化和冗余预留问题。vLLM “解决能跑多少的问题”，让单块 GPU 在密集并发下达到传统方案 24 倍的吞吐提升。

本质区别

llama.cpp 是 推理引擎库（C++ 核心，可嵌入任意应用）
vLLM 是 推理服务框架（Python 服务 + HTTP/OpenAI API）

它们不直接竞争，而是解决不同层面的需求。

二、关键技术原理对比

2.1 内存管理：分页 vs 量化

vLLM - PagedAttention

PagedAttention 将 KV Cache 切分为固定大小的块（默认 16 tokens/块），按需动态分配。这和操作系统虚拟内存的页面管理如出一辙：

消除了传统方法必须预留连续内存空间的浪费
支持请求间的内存共享（如 prefix caching），相同前缀仅需存储一次
显存利用率从传统方法的 40~60% 提升至接近 100%

llama.cpp - 量化与内存映射

llama.cpp 不涉及复杂的内存管理算法，它的低内存占用主要靠两点：

GGUF 量化：将模型权重从 FP16 压缩到 4-bit 甚至 2-bit，内存占用降至原来的 1/4 甚至更低。例如 Llama-3-8B Q4_K_M 仅需约 4.9GB
内存映射（mmap）：模型文件直接映射到虚拟内存，无需完整加载即可开始推理，且支持零拷贝访问，加载速度和内存效率极高

结论：vLLM 通过优化缓存利用提升有效容量，llama.cpp 通过压缩模型大小降低需求。当模型刚好放不进显存时，llama.cpp 可以用 CPU 卸载一部分层继续运行，而 vLLM 可能会直接 OOM。

2.2 批处理：连续批处理 vs 单请求

vLLM - 连续批处理

vLLM 在 GPU 上同时处理多个请求，且允许批次动态变化——当一个请求完成生成后就立即退出，新请求立即加入，GPU 流水线始终保持满载。这种机制使 vLLM 在 32+ 并发场景下吞吐是 llama.cpp 的 2-3 倍。

llama.cpp - 基本插槽批处理

llama.cpp 的批处理能力较弱，其 server 模式虽然支持多请求，但本质上采用简单的 slot 轮转方式，一旦某个请求处理结束，slot 释放后才能被复用。在高并发下，等待队列会急剧拉长，导致 TTFT（首 token 延迟）飙升。

关键指标：在单块 RTX 6000 Pro 96GB 上，Llama 3 8B 模型，64 并发场景下 vLLM 达到 12,000 tok/s，而 llama.cpp 约 4,500 tok/s。但单用户场景下，llama.cpp 的首 token 延迟（18ms）反而低于 vLLM（25ms），因为全 C++ 链路避免了 Python 的开销。

2.3 硬件支持差异

维度	llama.cpp	vLLM
GPU 必需	否，纯 CPU 即可运行	是，必须依赖 NVIDIA GPU（CUDA）
CPU 推理	顶级优化，支持 AVX2/AVX512/NEON	不支持
混合 CPU+GPU	支持，`-ngl` 参数控制 GPU 层数	不支持
跨平台	Linux/macOS/Windows/Android/FreeBSD	Linux 为主（WSL2 有限支持）
多 GPU 并行	仅支持层拆分（分摊显存）	完整张量并行（提升吞吐）

llama.cpp 的杀手锏：70B 模型通过 Q4 量化 + 部分层卸载到 CPU，可以在 16GB 内存的笔记本上运行，这在 vLLM 看来几乎是天方夜谭。

三、性能表现：数据说话

3.1 吞吐量（Output Tokens/s）

高并发（≥32 用户）：vLLM 碾压。Red Hat 在 H200 GPU 上的测试显示，vLLM 的 RPS 随并发数线性增长，而 llama.cpp 保持稳定（单用户性能），两者在 64 并发时差距达 2.7 倍
低并发（≤4 用户）：两者差距不大，llama.cpp 在单请求时由于无 Python 调度开销，甚至在部分场景略快

3.2 延迟

首 Token 延迟（TTFT）：llama.cpp 在低并发时更优（纯 C++），但高并发时因队列等待急剧恶化；vLLM 通过连续批处理在并发场景下保持低 TTFT
Token 间延迟（ITL）：vLLM 在 GPU 上生成 token 更平滑，llama.cpp 受 CPU/GPU 混合影响可能略高

3.3 显存占用

在同模型同精度下，llama.cpp 通过量化可节省 35% 以上的显存。例如 13B 模型 FP16 需要 26GB，vLLM 需要 28+GB（含缓存），而 llama.cpp Q5 量化后仅需 12GB。

3.4 综合交叉点

业界经验指出，并发用户数 16 是典型分界线：低于 16 选 llama.cpp 性价比更高，高于 16 选 vLLM 吞吐更佳。当然，这也取决于模型大小和 GPU 能力。

四、适用场景与选型建议

选择 llama.cpp 的场景

场景	原因
边缘设备 / 嵌入式	纯 CPU 运行、树莓派、老旧笔记本
隐私敏感应用	全离线，数据绝不出本地
个人开发者实验	快速换模型、低成本尝鲜
无 GPU 环境	只有服务器 CPU 或廉价 ARM 设备
超长上下文测试	GGUF 量化 + 内存映射使大模型在有限内存中运行
快速原型验证	无需安装 Python 环境，一个二进制文件+GGUF 即可运行

选择 vLLM 的场景

场景	原因
生产 API 服务	高并发、需要 OpenAI 兼容接口
企业级多用户 Saa	vLLM 的吞吐能力降低每 token 成本
长文档处理 / RAG	PagedAttention 高效支持 128K+ 上下文
多 GPU 集群	张量并行扩展 linear（TFLOPS 对等放大）
需要函数调用 / 结构化输出	vLLM 原生支持 guided decoding

组合使用的最佳实践

很多团队采取开发测试用 llama.cpp，生产部署用 vLLM 的策略：

本地用 llama.cpp 快速验证模型效果和参数
确认后，将模型转换为 HuggingFace format 或 AWQ/GPTQ 量化，部署到 vLLM 生产服务

这种模式兼顾了开发的灵活性和生产的性能。

五、生态与社区

llama.cpp：社区极其活跃，GGUF 格式已成为量化模型的业界标准，几乎每天都有新模型适配。但它本身不提供模型仓库，通常与 Ollama（基于 llama.cpp 的包装器）配合使用实现模型一键管理。
vLLM：有商业公司支持，与 HuggingFace 生态深度融合，支持的模型架构超 200 种，官方提供 Docker 镜像和 Helm Chart，运维部署文档完善。其 OpenAI 兼容 API 使得迁移成本几乎为零。

六、总结

维度	llama.cpp	vLLM
本质	轻量推理引擎库	生产推理服务框架
最大优势	跨平台，CPU 也能跑，极低硬件门槛	高并发吞吐，GPU 利用率极致
最大劣势	高并发性能差，无 GPU 时延迟高	必须 GPU，不支持纯 CPU 推理
量化支持	GGUF（Q2-Q8，K-quants）	AWQ、GPTQ、FP8
API 兼容	基础 OpenAI 兼容	完整 OpenAI 兼容，含 Streaming、Function Calling
部署复杂度	低（单文件运行）	中等（Python 环境 + GPU 驱动）
一句话建议	个人本地实验、边缘部署	企业生产、高并发 API

最终选型逻辑：问自己三个问题——① 有 GPU 吗？② 需要同时服务多少人？③ 追求吞吐还是灵活性？如果答案分别是“有”“16+”“吞吐”，选 vLLM；如果“没有/有但不够”“1~2”“灵活性和低门槛”，选 llama.cpp（或它的包装器 Ollama）。大多数情况下，两者并存使用才是最优解。