llama.cpp vs vLLM vs Exllama
llama.cpp 是适用于个人用途的可移植引擎(支持 GGUF、CPU、Mac 以及各品牌 GPU),也是 Ollama 和 LM Studio 的底层引擎。vLLM 专为在 GPU 上同时服务大量用户而设计,支持连续批处理;Red Hat 在一张 A100 上测得的吞吐量最高为 793 tokens/s,而 Ollama 为 41 tokens/s。ExLlamaV2 已归档,其开发工作在 ExLlamaV3 中继续。
在 Ollama、LM Studio 或 Jan 中,存在一个推理引擎,该引擎决定了支持的格式、可用的硬件以及负载下的行为。本指南基于各项目仓库中的可验证标准,对比 llama.cpp、vLLM、ExLlama 和 SGLang,纠正常见误解,并提供选择规则。文中不包含任何自测吞吐量数据,仅列出注明来源的第三方测量结果。
#推理引擎:它们之间究竟有哪些区别
推理引擎将输入token转换为输出token。我们安装的应用程序(Ollama、LM Studio、Jan)内置了推理引擎;生产环境中的服务端软件(vLLM、SGLang)本身就是推理引擎。有三方面的差异会影响您的使用:支持的模型格式、可使用的硬件,以及同时处理多个请求的方式。
| 引擎 | 许可证 | 已宣布的格式与硬件支持 | 典型用途 |
|---|---|---|---|
| llama.cpp | MIT | GGUF;CPU、Apple Silicon、NVIDIA(CUDA)、AMD(HIP)、Vulkan、SYCL 等 | 个人电脑、笔记本电脑、轻量级服务器 |
| vLLM | Apache 2.0 | Hugging Face 模型;FP8、INT4、GPTQ、AWQ、GGUF(实验性);NVIDIA、AMD、Intel GPU,以及 x86/ARM CPU | 支持大量用户,生产环境 |
| SGLang | Apache 2.0 | Hugging Face 模型;FP4、FP8、INT4、AWQ、GPTQ | 高吞吐量服务器,共享前缀 |
| ExLlamaV3 | MIT | EXL3;面向大众市场的 NVIDIA GPU | 个人 GPU 上使用 TabbyAPI 时的延迟 |
| MLX LM | MIT | 仅限 Apple Silicon | Mac:生成与微调 |
#模型格式决定了可用的引擎
只需 1 小时,即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档,无需云端。
- 在线空间,终身可用
- PDF + 文件
- 30 天内退款
比较速度之前,请确认您想使用的模型以什么格式发布。GGUF 文件可由 llama.cpp 加载,因此也可在 Ollama、LM Studio 和 Jan 中加载。Hugging Face 上的 FP16、FP8 权重,或采用 AWQ、GPTQ 量化的权重,可在 vLLM 或 SGLang 中加载。转换为 MLX 格式的模型可在 Mac 上通过 MLX LM 加载,EXL3 模型则可通过 ExLlamaV3 加载。更换引擎往往意味着需要重新下载另一种格式的模型。
| 格式 | 首选引擎 | 其他可能的引擎 |
|---|---|---|
| GGUF | llama.cpp(因此也包括 Ollama、LM Studio、Jan) | vLLM(实验性模式) |
| Hugging Face 模型权重(FP16、FP8) | vLLM, SGLang | 转换后可在 Mac 上使用 MLX LM |
| AWQ, GPTQ | vLLM, SGLang | 根据引擎情况,需核实 |
| EXL3 | ExLlamaV3 | 无 |
| MLX | MLX LM | LM Studio 和 Jan,均宣称支持 MLX |
#llama.cpp:可跨平台运行的标准方案
llama.cpp 是一个无依赖的 C/C++ 实现,其宣称的目标是在多种硬件上以尽可能少的配置进行推理。它优先支持 Apple Silicon(NEON、Accelerate、Metal),通过 AVX、AVX2、AVX512 和 AMX 支持 x86 CPU,并支持 NVIDIA GPU(CUDA)、AMD GPU(HIP)以及 Vulkan 和 SYCL。它提供 1.5 至 8 位量化和 CPU/GPU 混合推理,可运行大小超过可用显存容量的模型。
需要纠正一个常见误解:llama.cpp 并不局限于一次处理一个请求。其服务器宣称支持多用户并行生成,以及默认启用的连续批处理,并通过 --parallel 参数设置槽位(slots)。因此,它能很好地为小型团队提供服务;它并不追求匹敌 vLLM 的大规模生产功能。
- 优势
- 跨平台运行(Mac、Linux、Windows、Android),GGUF 格式广泛普及,支持 CPU 与 GPU 混合运行,依赖少。
- 限制
- 缺乏与 vLLM 相当的分布式部署功能;需预先了解相关配置参数(上下文长度、槽位、GPU 上的层)。
- 生态系统
- 是 Ollama 和 LM Studio 的底层支撑,Jan 也提到了它。
如需使用 CUDA、Metal 或 Vulkan 进行编译,请参阅编译指南;llama.cpp 完整指南则详细介绍了使用方法。
#vLLM:支持大量用户的服务器
vLLM 是诞生于加州大学伯克利分校 Sky Computing Lab 的推理与服务库。它基于 PagedAttention,按页管理注意力机制中键和值所占用的内存,并采用连续批处理,辅以分块预填充和前缀缓存。它宣称支持 FP8、INT4、GPTQ、AWQ 和 GGUF 格式,提供兼容 OpenAI 的 API,并支持 NVIDIA、AMD 和 Intel GPU,以及 x86、ARM 和 PowerPC CPU。
有两个常见误解需要纠正。首先,vLLM 已不再仅支持 NVIDIA,也不再缺乏 CPU 支持:其代码仓库说明支持多种 GPU 和 CPU。其次,它也已经支持 GGUF:其文档将 GGUF 支持描述为高度实验性、优化不足,主要适用于降低内存占用。对于日常使用 GGUF,llama.cpp 仍是常规选择。
- 优势
- 高负载下的吞吐量、基于页的缓存管理、兼容 OpenAI API、支持张量并行、流水线并行和专家并行、多种格式。
- 限制
- 安装和配置比llama.cpp更复杂;专为GPU服务器设计;GGUF并非其强项。
- 生态系统
- 当多个用户或应用程序同时查询同一模型时的默认选择。
vLLM 指南解释了这个引擎是什么;其生产部署指南则详细介绍了配置调整和监控。
#ExLlama:V2 已归档,V3 正在开发中
ExLlamaV2 仓库中的说明指出,该项目目前已归档,开发工作在 ExLlamaV3 中继续进行。许多对比评测,包括本页面的旧版本,仍将 V2 介绍为最先进的选择。ExLlamaV3 仓库介绍了 EXL3 量化格式、张量并行和专家并行推理、专家模型的 CPU 卸载、连续批处理、推测解码,以及通过其推荐服务器 TabbyAPI 提供的 OpenAI 兼容 API。
ExLlamaV3 面向消费级 GPU,而不是生产服务器或 Mac。如果您有 NVIDIA 显卡,并希望在质量和模型大小之间取得最佳平衡,EXL3 量化值得一试;请先确认您的模型是否在代码仓库的架构列表中。
#SGLang、MLX LM 以及其他
- SGLang
- 这一模型服务框架被描述为旨在实现低延迟和高吞吐量,适用规模从单个 GPU 到大型集群。它宣称支持用于前缀缓存的 RadixAttention、连续批处理、PagedAttention 和推测解码。它在服务器端与 vLLM 竞争;专门的指南对此有详细介绍。
- MLX LM
- 这是一个 Python 包,用于在 Apple Silicon 上通过 MLX 生成文本和微调模型。它无法在 Mac 以外的平台上运行。《MLX 与 llama.cpp》指南对比了两者在 Mac 上的表现。
- TensorRT-LLM
- 这是 NVIDIA 开发的引擎,在其自家显卡上性能非常出色,但部署要求更高;只有在生产环境中使用一批 NVIDIA 设备时,才值得考虑。
#已公布的测量结果说明了什么
吞吐量取决于硬件、模型、量化方式、请求长度以及引擎版本,每月都会发生变化。因此本指南不提供任何自测数据,建议您警惕没有协议支持的每秒令牌数(tokens/second)表格。不过,第三方确实发布了一个完整的协议:Red Hat,发布于2025年8月。
| 元素 | Red Hat发布的数据 |
|---|---|
| 硬件 | 一张 NVIDIA A100-PCIE-40GB 显卡 |
| 模型 | Llama 3.1 8B Instruct(Ollama 端使用 FP16) |
| 版本 | vLLM 0.9.1;Ollama 0.9.2 |
| 测试工具 | GuideLLM 0.2.1,1 至 256 名并发用户 |
| 最大吞吐量 | vLLM达到793 tokens/s,而Ollama仅为41 tokens/s |
| 峰值时的 P99 延迟 | vLLM 用时 80 毫秒,而 Ollama 用时 673 毫秒 |
阅读时需有所保留:这篇文章与 Red Hat AI 产品有关,因此出自该领域的一家商业企业;测试针对 Ollama,而非直接针对 llama.cpp,且使用默认设置;这些测试距今已有数个版本。可靠的结论是定性的:在高并发情况下,采用积极批处理策略的推理服务引擎优于面向单用户设计的应用。单人使用时,吞吐量差异并不是制约您的因素。
#内存:各推理引擎预留多少
模型的内存占用包括权重、上下文缓存(KV)和预留余量。权重的内存占用可以这样计算:一个拥有 80 亿参数的模型在 FP16 下约占用 16 GB(80 亿乘以 2 字节),在 Q4 量化下约占用 5 GB,这是本站给出的参考值。上下文缓存随对话长度和并发请求数量增加而增长。
| 引擎 | 文档中记载的行为 | 实际影响 |
|---|---|---|
| llama.cpp | 由用户设定的上下文;具有统一缓存的并行槽位 | 您设置上下文长度和槽位数量 |
| vLLM | 预先分配 GPU 内存的一部分用于缓存,默认为 92% | 在 24 GB 显存的卡上,约有 22 GB 会立即被预留 |
| ExLlamaV3 | 缓存量化位数为2至8位 | 缓存可以压缩,以便容纳在显存中 |
要记住的是:vLLM 在启动时就预留显存,这使它能高效提供推理服务,但不太适合与其他应用共享显卡。如果显卡还用于其他任务,应调低 gpu_memory_utilization 参数。
#不同用途该选哪种推理引擎
| 您的情况 | 推荐引擎 | 原因 |
|---|---|---|
| 在 Mac、PC 或笔记本电脑上用于个人用途 | 通过 Ollama 或 LM Studio 使用 llama.cpp | 可移植且易于使用 |
| Apple Silicon Mac,追求高吞吐量 | MLX LM 或 llama.cpp | MLX 专为 Apple Silicon 设计;使用您的模型进行比较 |
| 一个团队或应用程序向模型提问 | vLLM 或 SGLang | 连续批处理、缓存页 |
| 一张 NVIDIA 消费级显卡,最高质量 | ExLlamaV3配合TabbyAPI | 量化方式EXL3 |
| 混合硬件、CPU、AMD、Intel | llama.cpp | 广泛的硬件兼容性 |
| 模型仅提供 GGUF 格式 | llama.cpp | vLLM仅以实验性方式支持 |
多个引擎可以共存:Ollama 用于日常聊天,vLLM 按需启动,用于处理一批提取任务。如果用途不同,就没有理由只保留一个引擎。只需为以两种格式存储的同一模型预留磁盘空间,例如用于聊天的 GGUF 文件和用于服务器的 Hugging Face 权重。
vLLM还是llama.cpp?如何选择?+
Ollama 是否使用 llama.cpp?+
vLLM 能运行 GGUF 文件吗?+
ExLlamaV2是否仍在维护?+
哪个推理引擎最快?+
运行vLLM是否需要NVIDIA GPU?+
- Ollama 对比 llama.cpp
- vLLM:完整使用指南
- SGLang 作为本地 LLM 服务器
- MLX 与 llama.cpp 在 Mac 上的对比
- llama.cpp:完整指南
- Ollama, LM Studio, Jan 或 GPT4All
有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。