vLLM vs Ollama vs llama.cpp：LLM推理引擎终极选型指南

当企业开始把大模型从「调 API」转向「自己部署」，第一个绕不开的架构决策就是推理引擎选型。vLLM、Ollama、llama.cpp 三者在社区里经常被并列讨论，但它们其实服务于三种完全不同的部署场景。这篇指南从推理物理原理出发，拆解三者的技术机制、性能差异和硬件匹配策略。

vLLM vs Ollama vs llama.cpp 推理引擎对比

先理解推理的两个阶段

任何自回归 Transformer 的生成过程都分为两个性质完全不同的阶段，这是理解引擎差异的前提。

Prefill 阶段（提示词摄入）是计算密集型。 引擎一次性并行处理整个输入提示，比如 4000 token 的代码仓库上下文，此时 GPU Tensor Core 被充分压满，性能以 TFLOPS 衡量。

Decoding 阶段（逐 token 生成）是内存带宽密集型。 每生成一个 token，都需要把整个模型权重矩阵从显存读入处理器缓存。因此生成速度的天花板是显存带宽（GB/s），而不是算力。这也解释了为什么消费级显卡跑大模型时，瓶颈往往出现在带宽而非 FLOPS。投机解码等技术正是为了绕过这一瓶颈而出现。

KV Cache 是理解 Decoding 瓶颈的关键。自回归生成时，每生成一个新 token，注意力机制都需要与之前所有 token 的 Key 和 Value 向量做计算。若不做缓存，每步都要重新计算整个前缀的 K/V，复杂度呈平方级增长。KV Cache 把这些中间结果常驻显存，使每步只需计算新 token 的 K/V 并追加，将复杂度降为线性。但代价是显存占用随上下文长度和并发数线性膨胀——一个 70B 模型在长上下文下，KV Cache 本身就可能吃掉数十 GB 显存。这正是 vLLM 的 PagedAttention 要解决的核心矛盾：KV Cache 的显存管理效率，直接决定了单卡能承载多少并发请求。

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

vLLM 源自 UC Berkeley 关于 PagedAttention 的研究（Kwon 等），核心目标是解决传统推理服务中严重的显存浪费问题。

PagedAttention 的关键创新

传统服务系统为每个请求的 KV Cache 预留连续显存块，且按最大可能上下文长度分配。由于绝大多数请求远短于上限，60% 到 80% 的显存被碎片化浪费。

PagedAttention 借鉴操作系统虚拟内存分页的思路，把 KV Cache 切分为固定大小的物理块（page），Key 和 Value 张量动态写入非连续内存位置，将显存浪费压到 4% 以下。这直接带来更大的批处理规模和接近满载的显存利用率。

配合连续批处理（Continuous Batching），vLLM 在 32 并发用户场景下可达 1850+ tok/s 的吞吐，这是三者中唯一面向多租户 API 服务设计的引擎。它的短板也很明确：PagedAttention 内核深度绑定 NVIDIA CUDA 和 AMD ROCm，在 Apple Silicon 上仅有实验性支持。

连续批处理（Continuous Batching） 与传统静态批处理的区别值得展开。静态批处理要求一个批次内所有请求同时开始、同时结束，短请求必须等长请求跑完才能释放资源，GPU 在批次尾部大量空转。连续批处理则在每次迭代（每生成一个 token）后重新调度：已完成的请求立即退出并释放槽位，新到达的请求当步就可加入。这让 GPU 始终维持高占用率，是 vLLM 在高并发下吞吐远超另两者的架构原因，也解释了为何其吞吐随并发数近似线性增长，而顺序请求队列的 Ollama 和槽位批处理的 llama.cpp 则很快触及天花板。

llama.cpp：把硬件性能榨到最后一滴

由 Georgi Gerganov 创建、开源社区维护的 llama.cpp 是底层硬件利用率的标杆。纯 C/C++ 编写、零外部运行时依赖，可在 x86 AVX-512、ARM NEON、Apple Silicon Metal 和 NVIDIA CUDA 上运行。

GGUF 与 K-Quantization

llama.cpp 首创了 GGUF 文件标准，把模型权重、tokenizer 词表和量化缩放系数封装进单一二进制文件。其 K-quants 系列（Q4_K_M、Q5_K_M）采用混合精度矩阵压缩，能让 70B 参数模型在 42GB 以内运行，且推理能力下降可忽略。

在单用户场景下，llama.cpp 的原始速度反而是三者中最快的——8B 模型在 RTX 4090 上约 115 tok/s，首 token 延迟约 12ms，得益于原生 Metal/AVX 路径。代价是并发能力有限，32 并发时吞吐仅约 210 tok/s。

量化是把模型权重从 FP16 等高位宽压缩到 4bit、5bit 等低位宽的技术，直接决定模型能否塞进有限显存。K-quants 的巧妙之处在于混合精度：对注意力输出层等敏感矩阵保留较高位宽，对影响较小的层激进压缩，并按块（block）存储缩放系数以保留动态范围。Q4_K_M 中的 M 表示 medium，是 4bit 混合方案的均衡档。llama.cpp 还支持运行期把部分层卸载到 CPU（--n-gpu-layers），让显存不足时仍能借助系统内存推理，只是速度骤降——这也是它在 Mac 统一内存架构上如鱼得水的原因。

Ollama：开发者体验优先的封装层

Ollama 在 llama.cpp 之上构建了一层 Go 语言抽象，把「跑本地模型」变成类似 Docker 的体验。

单命令启动：ollama run llama3.3:70b 自动下载优化过的 GGUF 权重、分配 GPU 显存层、打开交互终端。
Modelfile 声明式配置：系统提示词、temperature、stop token 都可像 Dockerfile 一样定义。
本地 REST API（11434 端口）：提供 OpenAI 兼容的 /v1/chat/completions 端点，可直接对接 MCP 服务器和 LangGraph、CrewAI、AutoGen 等本地多智能体框架。

性能上 Ollama 与裸 llama.cpp 的差距在 3% 到 5% 之间，因为它本质上就是把 llama.cpp 编译为底层执行二进制。8B 模型约 105 tok/s，首 token 延迟 22ms，多出的延迟来自 HTTP 守护进程。

性能与特性横向对比

维度	vLLM	Ollama	llama.cpp
单用户 8B 速度	~95 tok/s	~105 tok/s	115 tok/s
32 并发吞吐	1850+ tok/s	~195 tok/s	~210 tok/s
首 token 延迟	18ms	22ms	12ms
显存效率	96%	85%	88%
核心语言	Python + C++/CUDA	Go（封装 llama.cpp）	纯 C/C++
原生模型格式	SafeTensors、AWQ、GPTQ、FP8	GGUF	GGUF 全系 K-Quants
并发架构	连续迭代批处理	顺序请求队列	槽位服务批处理
Apple Metal	实验性/有限	完整加速	Metal 性能标杆
目标场景	云 GPU 集群与 API	本地 IDE 编程助手	边缘设备与 Mac 工作站

硬件怎么配：从单卡到集群

单开发者（RTX 4090，24GB 显存）：选 Ollama 或 llama.cpp。8B 模型 FP16 非量化可达 95+ tok/s，32B 模型用 Q4_K_M 量化可塞进 20GB 显存。

多卡工作站：用双卡做张量并行时，需要确认主板的 PCIe 通道拆分策略，PCIe 4.0 x8/x8 与 x16/x16 的实际推理差异值得提前验证。

Apple Mac Studio（128GB 统一内存）：选 llama.cpp 或 Ollama。70B 参数模型（Llama 3.3 70B、Qwen 2.5 72B）以 Q4_K_M 量化可完整跑在统一内存中，速度 22+ tok/s。

企业生产 API 集群（A100/H100 80GB 多卡）：部署 vLLM 并开启张量并行（TP=2 或 TP=4）。上线前建议对比 RunPod、Modal、AWS 等平台的 GPU 成本，其中 RunPod 适合需要稳定 GPU 容量又不想把基础设施管理变成第二份全职工作的团队，Modal 在弹性 serverless 按需扩缩上更有优势，而大规模生产系统出于 SOC2 合规和 VPC 隔离要求通常仍需 AWS EC2/EKS。

搭一个私有编程助手

把代码生成路由到本地 Ollama 实例，既能省掉 SaaS 订阅，也能避免专有代码库外泄。三步即可完成：

终端执行 ollama run qwen2.5-coder:7b 拉取代码模型；
在 VS Code、JetBrains 或 Cursor 中安装开源 Continue 扩展；
在 config.json 中把 provider 设为 ollama、model 设为 qwen2.5-coder:7b。

常见问题

Ollama 比裸 llama.cpp 慢吗？ 差距极小。由于 Ollama 以 llama.cpp 为底层执行二进制，原始 token 生成速度差距在 3% 到 5% 内。

vLLM 能跑在 Mac 上吗？ 存在实验性的 CPU 和 Metal 后端，但其 PagedAttention 内核本质上是为 NVIDIA CUDA 和 AMD ROCm 优化的。Apple Silicon 上 llama.cpp 和 Ollama 仍是明显更优解。

最终选型建议

三个引擎并非互相替代关系，而是各自占据一个运营层级：个人开发者用 Ollama 获得零维护的私有编程助手；Mac 或边缘设备用户用 llama.cpp 榨干统一内存带宽；企业工程团队用 vLLM 在 Kubernetes 或云集群上承载生产 API，靠 PagedAttention 拿到无可匹敌的并发吞吐。先把部署场景想清楚，选型答案基本就唯一了。