高级 11 分钟Backends

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,纠正常见误解,并提供选择规则。文中不包含任何自测吞吐量数据,仅列出注明来源的第三方测量结果。

作者: Mohamed Meguedmi·更新于 2026-09-29·已在 Windows、macOS 和 Linux 上测试

#推理引擎:它们之间究竟有哪些区别

推理引擎将输入token转换为输出token。我们安装的应用程序(Ollama、LM Studio、Jan)内置了推理引擎;生产环境中的服务端软件(vLLM、SGLang)本身就是推理引擎。有三方面的差异会影响您的使用:支持的模型格式、可使用的硬件,以及同时处理多个请求的方式。

引擎列表(官方仓库,2026年9月)
引擎许可证已宣布的格式与硬件支持典型用途
llama.cppMITGGUF;CPU、Apple Silicon、NVIDIA(CUDA)、AMD(HIP)、Vulkan、SYCL 等个人电脑、笔记本电脑、轻量级服务器
vLLMApache 2.0Hugging Face 模型;FP8、INT4、GPTQ、AWQ、GGUF(实验性);NVIDIA、AMD、Intel GPU,以及 x86/ARM CPU支持大量用户,生产环境
SGLangApache 2.0Hugging Face 模型;FP4、FP8、INT4、AWQ、GPTQ高吞吐量服务器,共享前缀
ExLlamaV3MITEXL3;面向大众市场的 NVIDIA GPU个人 GPU 上使用 TabbyAPI 时的延迟
MLX LMMIT仅限 Apple SiliconMac:生成与微调
i
Ollama 和 LM Studio 并不是与这些引擎竞争的推理引擎
Ollama 的仓库在“Supported backends”下列出了 llama.cpp,LM Studio 的首页则说明其引擎基于 MLX 和 llama.cpp。比较“Ollama vs llama.cpp”,相当于比较一个应用程序与它的引擎:专门介绍 Ollama 与 llama.cpp 对比的指南讨论了这一情况。

#模型格式决定了可用的引擎

本地 AI 套件

只需 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 加载。更换引擎往往意味着需要重新下载另一种格式的模型。

格式及兼容的引擎
格式首选引擎其他可能的引擎
GGUFllama.cpp(因此也包括 Ollama、LM Studio、Jan)vLLM(实验性模式)
Hugging Face 模型权重(FP16、FP8)vLLM, SGLang转换后可在 Mac 上使用 MLX LM
AWQ, GPTQvLLM, SGLang根据引擎情况,需核实
EXL3ExLlamaV3无
MLXMLX LMLM 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月。

红帽测试:vLLM对比Ollama在A100上的表现(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,且使用默认设置;这些测试距今已有数个版本。可靠的结论是定性的:在高并发情况下,采用积极批处理策略的推理服务引擎优于面向单用户设计的应用。单人使用时,吞吐量差异并不是制约您的因素。

!
本页不提供每秒 token 数的对照表
本指南的旧版本提供了三个推理引擎的吞吐量和首次响应时间。这些数据未注明任何来源,因此已被移除。要在您的机器上进行比较,请使用您自己的模型和请求进行测量。

#内存:各推理引擎预留多少

模型的内存占用包括权重、上下文缓存(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.cppMLX 专为 Apple Silicon 设计;使用您的模型进行比较
一个团队或应用程序向模型提问vLLM 或 SGLang连续批处理、缓存页
一张 NVIDIA 消费级显卡,最高质量ExLlamaV3配合TabbyAPI量化方式EXL3
混合硬件、CPU、AMD、Intelllama.cpp广泛的硬件兼容性
模型仅提供 GGUF 格式llama.cppvLLM仅以实验性方式支持

多个引擎可以共存:Ollama 用于日常聊天,vLLM 按需启动,用于处理一批提取任务。如果用途不同,就没有理由只保留一个引擎。只需为以两种格式存储的同一模型预留磁盘空间,例如用于聊天的 GGUF 文件和用于服务器的 Hugging Face 权重。

关于推理引擎的常见问题
vLLM还是llama.cpp?如何选择?+
个人使用或使用多种硬件(包括 CPU 和 Mac)时,选择 llama.cpp。在 GPU 上为多个用户提供服务时,选择 vLLM,它具备连续批处理和内存分页管理功能。如果只有您自己使用这台机器,通过 Ollama 或 LM Studio 使用 llama.cpp 几乎总是足够的。
Ollama 是否使用 llama.cpp?+
Ollama 的代码仓库在“Supported backends”下列出了 llama.cpp。Ollama 在其基础上增加了模型管理、API 和应用程序。因此,比较 Ollama 和 llama.cpp,就是比较一个应用程序及其引擎,两者的默认设置、格式和功能有所不同;详情请参阅专门介绍这一对比的指南。
vLLM 能运行 GGUF 文件吗?+
是的,但其文档将这项支持描述为实验性很强、优化不足,主要有助于减少内存占用。目前这项支持通过独立插件提供。使用 vLLM 时,建议选择 Hugging Face 上的 FP16、FP8 权重,或采用 AWQ、GPTQ 量化的权重,并将 GGUF 留给 llama.cpp 使用。
ExLlamaV2是否仍在维护?+
没有。其仓库显示,目前已归档,开发工作在 ExLlamaV3 中继续进行。ExLlamaV3 提供 EXL3 格式,并推荐使用 TabbyAPI 服务器。如果您原本打算按照 ExLlamaV2 和 EXL2 格式的教程操作,请先找到对应的 V3 教程,再开始。
哪个推理引擎最快?+
这取决于硬件、模型和并发用户数。在高并发情况下,Red Hat 的测试显示,vLLM 相比 Ollama 有明显优势。一次只处理一个请求时,差距较小,并且取决于硬件。做决定前,请使用您自己的模型进行测量。
运行vLLM是否需要NVIDIA GPU?+
不。vLLM仓库宣布支持NVIDIA、AMD和Intel的GPU,以及x86、ARM和PowerPC架构的CPU,并提供对其他加速器的扩展支持。功能覆盖范围因硬件而异:在投入使用前,请务必查阅您平台的安装文档。
这份指南对您有帮助吗?

有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。