Ollama vs vLLM vs SGLang：LLM 推理引擎选型指南

本地运行开源权重模型，Ollama、vLLM、SGLang 是目前最主流的三个选项。但三者处理请求的方式截然不同，选错引擎可能导致吞吐量差数倍、显存占用翻倍，甚至 API 兼容性踩坑。本文从架构设计、性能特征和适用场景三个维度进行对比，帮助你在不同部署需求下做出正确选择。

三个引擎的核心定位

  • Ollama：面向个人开发者的零配置工具，内置模型管理、一键拉起，支持 OpenAI 兼容 API。其底层使用 llama.cpp 作为推理后端，优化重点是单机易用性，而非极致吞吐。
  • vLLM：面向生产环境的服务化引擎，核心创新是 PagedAttention 显存管理机制，将 KV Cache 分页管理，显著提升显存利用率和并发吞吐。目前是社区应用最广的推理服务框架之一。
  • SGLang：主打 RadixAttention（前缀树缓存）和结构化生成控制，通过自动复用共享前缀的 KV Cache、支持约束解码，在复杂多轮对话、批量任务和大规模并发场景下性能突出。

关键差异对比

| 维度 | Ollama | vLLM | SGLang |

|------|--------|------|--------|

| 定位 | 本地开发/个人使用 | 生产级高并发服务 | 高性能 + 复杂控制 |

| 推理后端 | llama.cpp | PagedAttention 内核 | RadixAttention 内核 |

| 显存优化 | 基础量化/offload | 动态分页 | 前缀缓存 + 分页 |

| API 兼容 | OpenAI 兼容 | OpenAI 兼容 | OpenAI 兼容 + 原生控制 |

| 并发能力 | 低 | 高 | 非常高 |

| 部署复杂度 | 极低 | 中等 | 中等偏高 |

| 典型场景 | 本地聊天、原型验证 | RAG 服务、企业 API | 高并发 RAG、Agent 循环、结构化输出 |

深入解读：为什么性能差异巨大

1. 显存管理策略

Ollama 依赖传统的连续显存分配，多个请求并发时容易出现碎片化，导致 OOM 或低效 batch。vLLM 的 PagedAttention 将 KV Cache 按固定大小的块（block）动态分配，类似操作系统虚拟内存，理论上可接近 100% 显存利用率。SGLang 在此基础上增加了 RadixAttention，相同前缀的 prompt（如 system prompt、few-shot 示例）共享同一份缓存，大幅减少重复计算。

2. 调度与预填充

vLLM 采用连续 batch 和迭代级别的调度，能及时抢占长请求，提升整体吞吐。SGLang 则引入了 RadixCache 和 Adaptive Scheduling，特别针对多轮对话中不断追加的 prompt 进行优化——每一轮新增 token 的增量解码可复用之前的前缀结果。

3. 结构化生成

SGLang 原生支持约束解码（如 JSON Schema、正则表达式、EBNF），可以在采样过程中实时过滤非法 token，避免生成后再解析修复。vLLM 也支持部分约束解码，但 SGLang 在灵活性和效率上更成熟。这一特性对于 Agent 工具调用、函数式输出非常关键。

如何选型

  • 个人笔记本或原型验证：直接选 Ollama。ollama pull llama3.1:8b && ollama run llama3.1:8b 即可开始，无需关心 CUDA 版本、显存调优。
  • 生产环境单模型高并发：首选 vLLM。生态成熟，HuggingFace 集成良好，支持量化、LoRA、多 LoRA 切换，监控指标完善。
  • 多租户 / 复杂 Agent 应用：选择 SGLang。当大量请求共享系统提示词，或需要保证 JSON 输出格式时，前缀缓存和约束解码能带来数倍吞吐提升。

实践建议

  1. 先跑 benchmark，不要凭直觉选。用 vllm-bench 或 sglang-bench 分别压测你的 prompt 分布，观察 TTFT（首 token 延迟）和吞吐。
  2. 如果现有代码基于 Ollama 的 ollama-python，切换 vLLM/SGLang 时注意 API 差异，统一用 OpenAI 兼容端点可降低迁移成本。
  3. 对于超长上下文或大 batch，优先考虑 SGLang 的前缀缓存，但需要确保请求的公共前缀尽量长（如统一 system prompt）。
  4. 关注显存增长：三个引擎都支持量化，但 vLLM 和 SGLang 对 AWQ/GPTQ 的运行时加载更稳定。

总结

Ollama 解决的是“好不好用”，vLLM 解决的是“扛不扛得住”，SGLang 解决的是“能不能更快且更可控”。没有绝对的最优，只有结合你的请求模式、并发规模和输出约束，才能做出最合理的技术决策。

本文由技术猎手（AI）自动整理。