vLLM 和 llama.cpp 怎么选：一个负责高并发，一个负责本地自由

vLLM 与 llama.cpp 分工示意图

很多人第一次接触本地大模型部署时，会把 vLLM 和 llama.cpp 放在同一个问题里比较：我到底该用哪个跑模型？

这个问题本身有点误导。vLLM 和 llama.cpp 都和推理有关，但它们解决的是两类不同问题。简单说：llama.cpp 让模型更容易在本地和边缘设备上跑起来；vLLM 让模型更适合在服务端高吞吐地跑起来。

如果你把这两个工具的边界理解清楚，很多部署选择会立刻变简单。

llama.cpp：本地自由的代表

llama.cpp 最初火起来，是因为它把 LLaMA 这类模型带到了普通开发者的机器上。CPU、Mac、消费级显卡、量化模型、GGUF 文件，这些关键词背后都是同一个目标：尽可能降低运行大模型的门槛。

它适合这些场景：

llama.cpp 的价值不是追求最大吞吐，而是给开发者“模型可以在我手里跑”的自由。对于个人开发者、小团队、教育场景、本地知识库和离线工具，这个自由非常重要。

vLLM 的问题意识完全不同。它关心的是服务端推理效率：高并发、低延迟、高 GPU 利用率、OpenAI-compatible API、多模型服务、prefix caching、speculative decoding 等。

如果你要把模型能力提供给多个用户、多个应用或内部服务，vLLM 的价值就会明显出现。

它适合这些场景：

vLLM 不只是“能跑模型”，而是更接近“模型服务基础设施”。它的核心问题是：同样一张 GPU，怎样服务更多请求，怎样更稳定地承载线上负载。

很多部署问题，来自工具选错层级。

如果你只是想在 Mac 上试一个模型，却上来研究 vLLM 的分布式部署、CUDA 配置、服务参数，复杂度会不必要地升高。这个时候 llama.cpp 或 Ollama 往往更快。

反过来，如果你要给团队提供统一 API，却用本地推理工具临时起服务，后面会遇到并发、观测、限流、弹性和资源利用率问题。这个时候 vLLM 更合适。

可以这样判断：

实际选型时，还会遇到几个常见名字。

Ollama 更偏开发者体验：模型拉取、启动、管理都很简单，很适合本地使用。它常常和 llama.cpp/本地推理生态一起出现。

LM Studio 更偏桌面体验：适合非工程用户或想用图形界面管理本地模型的人。

SGLang 和 vLLM 更接近同一层级：都面向高性能推理服务，适合服务端和生产负载。

所以你可以把它们分成两组：

为什么这件事和 Agent、RAG 有关？因为 Agent 应用最大的成本之一就是推理调用。

一个复杂 Agent 任务可能会多轮调用模型：规划、检索、调用工具、验证结果、生成报告。如果每一步都依赖昂贵 API，成本会很快上升。

这时有两种优化路线：

很多企业最后会走混合路线：关键任务用闭源强模型，普通任务用自部署模型，本地工具处理隐私和边缘场景。

如果你是个人开发者，先从 Ollama 或 llama.cpp 开始。目标是熟悉 GGUF、量化、本地 API、模型差异和硬件限制。

如果你是团队负责人，应该尽早评估 vLLM 或 SGLang。目标不是炫技，而是建立一个可控的模型服务层：限流、监控、日志、成本、模型版本、调用权限都要纳入管理。

如果你在做面向用户的产品，不要只看 demo 的单次响应速度。要看真实并发、上下文长度、显存占用、缓存命中率、失败恢复和升级成本。

vLLM 和 llama.cpp 不是谁取代谁，而是负责不同战场。

llama.cpp 负责把模型带到更多设备上，让开发者拥有本地自由。vLLM 负责把模型变成稳定服务，让团队和业务能高效调用。

如果你在追大模型基础设施，这两个项目都值得长期关注。一个决定模型能不能低门槛跑起来，一个决定模型能不能低成本服务起来。