这两年本地大模型和自部署推理越来越热，圈里也经常会反复提到四个名字：
- Ollama
- llama.cpp
- vLLM
- SGLang
刚开始接触时，很多人会把它们放在一起比较，但实际上，这四个东西虽然都和 LLM 推理 有关，定位却并不完全一样。
有的更适合 个人电脑本地跑模型，有的更适合 对外提供 API 服务，有的偏 轻量和兼容性，有的则明显是冲着 高吞吐生产部署 去的。官方资料里也能看出这种差异：llama.cpp 强调“在广泛硬件上以最小配置实现高性能推理”，vLLM 主打高吞吐 OpenAI 兼容服务，SGLang 则突出 RadixAttention、连续批处理和结构化生成，Ollama 更强调本地启动简单以及本地到云端的平滑体验。
如果你最近也在选型，这篇就尽量讲清楚一个核心问题：
本地运行和服务化推理，到底该怎么选？
一、先说结论：这四个不是同一层的竞争关系
先给一个最直白的判断：
- 想本地快速跑起来，优先看 Ollama
- 想自己掌控模型文件、量化、底层参数，优先看 llama.cpp
- 想做高并发 API 服务，优先看 vLLM
- 想追求更激进的服务性能和复杂生成能力，重点看 SGLang
为什么这么说？
因为它们的产品重心不同：
Ollama：最像“本地大模型的入门层”
Ollama 的强项不是让你研究底层推理细节，而是让你 尽快把模型跑起来。它提供统一的本地使用体验，也有官方仓库和 API，甚至还在官网上直接强调“Start local. Scale with cloud.”。对于很多开发者来说，它是最省心的本地入口。
llama.cpp：最像“本地推理的底层通用引擎”
llama.cpp 的官方定位很明确：以最小配置在广泛硬件上实现本地和云端推理。它更底层、更灵活，也更适合 CPU、本地 GPU、各种量化模型和 GGUF 生态。官方 server 文档还显示，它现在已经支持 OpenAI 兼容接口、embeddings、monitoring、continuous batching 和 schema-constrained JSON 输出。
vLLM：最像“面向服务化部署的主流推理后端”
vLLM 的强项非常聚焦：高吞吐服务化推理。它官方文档里直接提供 OpenAI-Compatible Server，支持 Chat API、Completions API 等，并且其核心优化之一就是 PagedAttention，用来更高效地管理 KV cache。
SGLang：最像“高性能服务框架 + 结构化生成运行时”
SGLang 官方把自己定义为高性能 serving framework / runtime engine，核心特性包括 RadixAttention、连续批处理、prefill-decode disaggregation、speculative decoding、structured outputs、多 LoRA batching 等。它不只是“再做一个服务端”，而是在推理执行模式上做了很多更偏系统层的优化。
二、如果你的目标是“本地运行”，怎么选？
很多人第一需求其实不是上线服务，而是：
- 自己电脑上先跑起来
- 离线可用
- 快速验证模型效果
- 接个本地 API 给别的工具用
这时候，优先要考虑的不是“极限吞吐”，而是：
- 安装难不难
- 模型管理方不方便
- 对硬件要求高不高
- 折腾成本大不大
1）Ollama：本地体验最友好
如果你是第一次玩本地 LLM，Ollama 一般是最省事的选择。
它的优势非常明显：
- 安装简单
- 拉模型方便
- 提供本地服务接口
- 社区接入非常多
官方仓库还直接写到可以连接到很多现有 agent 或应用。这个定位就说明它本质上是在做一个 本地模型运行层 + 统一接入层。
适合谁？
- 想快速本地体验模型的人
- 想在 Windows / macOS / Linux 上尽快跑通的人
- 想给本地工具、IDE、脚本接一个模型接口的人
一句话评价：
本地跑模型，先跑起来，再说优化，Ollama 往往是第一站。
2）llama.cpp：本地掌控力最强
如果你不是只想“跑起来”，而是还想进一步控制：
- 用什么量化格式
- 怎么配上下文长度
- 是否 CPU 跑
- 是否混合 GPU/CPU
- 是否自己转 GGUF
- 是否自己决定服务参数
那 llama.cpp 会更合适。
它本身就是 GGUF 生态里非常核心的一环，官方量化文档也明确介绍了把高精度模型量化成更小格式的流程，而 server 端已经支持 OpenAI 兼容接口、多用户并行、continuous batching 等能力。
适合谁？
- 想研究本地推理细节的人
- 想在低资源机器上尽可能榨性能的人
- 想深度使用 GGUF 模型的人
- 想对模型部署过程更可控的人
一句话评价：
Ollama 更像“拿来就用”，llama.cpp 更像“你自己掌方向盘”。
3）vLLM 和 SGLang 本地能不能跑？
当然能。
但如果你的主要目标只是“我自己电脑上本地体验一下模型”，那 vLLM 和 SGLang 通常不是第一推荐。因为它们更大的价值，不是“个人电脑开个 demo”，而是：
- 多请求并发
- 在线服务
- 高吞吐
- 更复杂的缓存和批处理策略
也就是说：
- Ollama / llama.cpp 更偏本地体验
- vLLM / SGLang 更偏服务后端
这不是绝对划分，但对大多数人来说，这样理解最省事。vLLM 和 SGLang 官方文档都明显把重点放在 serving 和 runtime 优化上，而不是“最友好的本地入门体验”。
三、如果你的目标是“服务化推理”，怎么选？
到了服务化阶段，关注点就完全变了。
你不会再只问“能不能跑”，而是会问：
- 并发高了会怎样？
- GPU 利用率高不高？
- KV cache 管得好不好？
- 能不能 OpenAI 兼容？
- 能不能接现有业务系统？
- 后续扩展和监控方便吗？
这时候，vLLM 和 SGLang 就明显更进入主场了。
1）vLLM：生产服务的通用主力选手
vLLM 之所以现在很常见，就是因为它非常适合作为 标准化 API 推理服务。
它的几个关键点很典型：
- OpenAI-Compatible Server
- PagedAttention
- 面向高吞吐 serving
- 与 Hugging Face 生态集成顺畅
官方文档明确说明可以直接用 vllm serve 起 HTTP 服务，并暴露 OpenAI 风格接口；PagedAttention 的设计则是它高效管理 KV cache 的关键机制之一。
适合谁？
- 想快速搭一个类 OpenAI API 服务的人
- 业务系统已经按 OpenAI API 接口设计
- 主要追求吞吐和服务稳定性
- 团队已经有 GPU 服务化经验
一句话评价：
如果你想给业务系统提供一个“像 OpenAI 一样可调用”的私有模型服务，vLLM 往往是最稳的主流解。
2）SGLang：更激进、更偏性能工程
SGLang 很容易被简单理解成“另一个 vLLM”，但其实它的味道不太一样。
它更强调这些东西：
- RadixAttention
- prefix caching
- continuous batching
- prefill-decode disaggregation
- structured outputs
- speculative decoding
- 多种并行和量化能力
这些能力说明，SGLang 不只是想做一个 HTTP server，而是在试图优化 复杂推理程序 的整体执行效率。NVIDIA 文档里也把它描述成 “高性能 runtime engine 和 structured generation language”。
适合谁？
- 对推理延迟和吞吐特别敏感
- 有复杂 prompt/program 执行需求
- 有结构化输出、前缀复用、多请求共享缓存等需求
- 团队愿意多做一些性能工程和部署调优
一句话评价：
vLLM 更像稳妥主流方案，SGLang 更像高阶性能选手。
3）llama.cpp 能不能服务化？
能，而且现在比很多人想象中更能打。
官方 server 文档显示，llama.cpp 已经支持：
- OpenAI API compatible routes
- Anthropic Messages API compatible routes
- embeddings
- reranking
- multi-user support
- continuous batching
- monitoring endpoints
- JSON schema 约束输出
这说明它已经不只是“本地单机聊天工具”了。
但问题在于：
它能服务化，不等于它最适合大规模服务化。
如果你是轻量服务、边缘部署、资源受限机器、或者就是希望用 GGUF 直接对外供服务，那 llama.cpp 很有价值。
但如果你目标是“单卡/多卡上尽可能榨高并发吞吐”，vLLM 和 SGLang 通常会更靠前。这个判断主要来自它们官方文档对 serving 和注意力缓存优化的强调。
4）Ollama 能不能服务化？
也能，因为它本身就带本地服务接口。
但它更适合的是：
- 本地服务
- 小规模内部调用
- 开发测试环境
- 个人或小团队工具链集成
它不是不能做服务端，而是官方叙事重点明显不是“极限生产吞吐”，而是 本地到云端的平滑使用体验。
所以如果你是：
- 自己电脑跑一下
- 团队内部先搭个 API
- 业务量不大
- 更重视上手快
那 Ollama 完全够用。
但如果你已经在认真考虑：
- QPS
- batching
- cache
- 多租户
- GPU 利用率
那通常就该往 vLLM / SGLang 这边走了。
四、一个最实用的理解方式：按场景选，不要按热度选
我自己更建议这样分：
场景 A：个人本地学习 / 体验 / 演示
选 Ollama
原因很简单：
- 安装省心
- 模型获取方便
- 用起来像一个本地模型服务
- 接其他工具很方便
场景 B：本地设备性能有限，但想把模型榨得更细
选 llama.cpp
尤其适合这些情况：
- CPU 为主
- 想用 GGUF 量化模型
- 想对内存占用更敏感
- 想自己精细调优
场景 C：要给应用系统提供模型 API
优先选 vLLM
因为它本身就是冲着这个目标去的，OpenAI 兼容接口、PagedAttention、高吞吐服务，这条路线非常清晰。
场景 D：对性能和复杂生成流程要求更高
重点看 SGLang
尤其是这些诉求：
- 多请求共享前缀
- 结构化输出很多
- 程序化生成复杂
- 需要更激进的 serving 优化
五、四者怎么理解成一句人话？
给一个非常口语化的版本：
- Ollama：我就想本地先跑起来，别折腾
- llama.cpp：我想本地自己控得更细，硬件吃干榨净
- vLLM：我要把模型变成稳定的 API 服务
- SGLang：我要把 API 服务再往性能和复杂执行上卷一层
如果这样记，就不容易混。
六、一个简化对比表
| 维度 | Ollama | llama.cpp | vLLM | SGLang |
|---|---|---|---|---|
| 核心定位 | 本地模型运行与统一接入 | 轻量高性能本地/边缘推理引擎 | 高吞吐服务化推理框架 | 高性能 serving/runtime 框架 |
| 更适合本地运行 | 很适合 | 很适合 | 可以，但不是首选 | 可以，但不是首选 |
| 更适合服务化 | 轻量服务可用 | 轻量到中等服务可用 | 很适合 | 很适合 |
| 上手难度 | 低 | 中 | 中 | 中到偏高 |
| 底层掌控力 | 中 | 高 | 中 | 高 |
| OpenAI 兼容服务 | 有 API 能力 | 官方 server 支持 | 官方主打 | 官方支持服务化 |
| 典型优势 | 省心、接入快 | GGUF、量化、兼容广 | 吞吐、PagedAttention、标准化服务 | RadixAttention、前缀复用、结构化生成 |
| 典型人群 | 本地体验者、个人开发者 | 本地优化玩家、边缘部署 | 平台研发、推理服务团队 | 高性能服务和复杂生成团队 |
表里这些能力点，主要来自各自官方文档和官方仓库公开说明。
七、再说个很现实的问题：不要一上来就过度选型
很多人一开始其实只有一个需求：
“我想先在本地跑个模型，验证一下效果。”
这时候没必要一上来就研究 vLLM 和 SGLang 的所有细节。
因为真正决定你是否能顺利推进的，往往不是“理论最强框架”，而是：
- 你今天能不能先跑通
- 你有没有足够 GPU
- 你当前是 demo 阶段还是生产阶段
- 你到底要本地聊天，还是要对外服务
所以我更建议：
- 先本地验证：Ollama / llama.cpp
- 再做服务化：vLLM / SGLang
- 资源有限且偏边缘：优先看 llama.cpp
- 追求标准化 API：优先看 vLLM
- 追求复杂高性能执行：重点看 SGLang
这样路线最顺。
八、顺手推荐一个我自己在用的在线工具站
最近在折腾本地模型、推理服务、部署脚本的时候，除了模型框架本身，经常还会碰到很多碎活：
- 图片尺寸调整
- PDF 处理
- Word 文档轻量处理
- 表格转换
- 文本清洗
- 一些小开发工具
这类事情如果每次都开本地软件，其实挺碎的。
所以我平时也会直接用自己做的一个在线工具站：
XLToolLab
它是一个免费在线工具箱，包含：
- 图片处理
- PDF 工具
- Word 工具
- 表格工具
- 文本工具
- 开发者工具
- 单位换算
特点就是：
- 打开浏览器就能用
- 不用安装
- 适合日常办公、学习和轻量处理场景
有时候写技术文章、整理部署文档、做截图压缩、转 PDF、改表格这类零碎需求，直接在线处理反而更省事。
九、最后总结
如果只看一句话结论：
本地运行
- 首选省心：Ollama
- 首选可控：llama.cpp
服务化推理
- 首选通用主流：vLLM
- 首选高阶性能：SGLang
所以题目里这个问题：
Ollama vs llama.cpp vs vLLM vs SGLang：本地运行和服务化推理到底怎么选？
我的答案其实很简单：
不要把四个都当成“谁替代谁”，而要看你当前在哪个阶段。
本地体验阶段和生产服务阶段，选型逻辑根本不是一回事。
