Ollama 与 vLLM：生产环境中应选择哪种 LLM 运行时？

在Ollama与vLLM之间作出选择，就是在部署的简便性与并发负载下的原始吞吐量之间进行权衡。如今，无论是为内部智能体提供服务，还是对外提供多租户API，这两者的比较都在很大程度上影响着围绕开放权重LLM的自托管基础设施决策。本文将从架构、NVIDIA GPU上的可测吞吐量、内存管理（KV缓存、PagedAttention）、支持的许可证和格式以及运维成本等方面比较这两个运行时，最后按模型规模给出建议，并解答技术常见问题。我们的目标是让平台工程师通过不到十五分钟的阅读作出选择。

架构与理念：两个运行时，两个世界

Ollama封装了 llama.cpp，用 Go 编写，提供简单的 HTTP API，并管理 GGUF 模型的下载、缓存和动态加载。其最初面向的是开发者的机器（Mac M 系列、配备 RTX 显卡的台式 PC）以及轻量级单租户部署。底层运行时会自动将部分计算卸载到 CPU，从而可以运行一个 Qwen 2.5 72B Instruct （Q4 量化下所需显存约 42 GB）在显存为 24 GB 的 RTX 4090 上配合系统 RAM 交换运行，但会牺牲吞吐量。

vLLM, 由加州大学伯克利分校发布，是一个针对高并发推理优化的Python服务器。其核心贡献是 PagedAttention，它像操作系统管理虚拟内存一样管理 KV 缓存：使用固定大小的块、分页以及请求间共享。具体而言，简单的运行时会因内存碎片浪费 60–80% 的 KV 缓存，而 vLLM 将这一比例降至 4% 以下。根据负载不同，总吞吐量可达到原来的 2 至 24 倍，但也有使用门槛：不原生支持 GGUF 量化、严格依赖 CUDA，而且整个模型必须放入显存。

要深入了解 llama.cpp 与 vLLM 在服务端实现上的差异，请参见我们的 llama.cpp 与 vLLM 全面指南.

吞吐量与延迟：数据说明了什么

公开测量结果在一点上是一致的：在并发负载下，vLLM 大幅领先。在 Llama 3.3 70B Instruct (70B，上下文128 000) 在FP8精度下运行于4×A100 80GB显卡上，通常可观察到（具体需根据批次大小确认）：

在MoE模型方面差距进一步扩大，例如 Mixtral 8x22B Instruct （141B，Apache 2.0，上下文长度 64K），vLLM 在这些模型上利用多 GPU 张量并行，实现了 llama.cpp 难以达到的效率。对于规模非常大的 MoE 模型，如 DeepSeek V3 671B 或 Qwen 3 235B-A22B，vLLM仍是多用户生产环境中唯一现实可行的选择，尤其得益于其对专家并行的原生支持。

不过，在单流负载且采用激进量化（Q4_K_M、Q5_K_M）的情况下，Ollama 在首 token 延迟（TTFT）方面足以与之相比；得益于轻量的运行时，在 7B–13B 模型上有时还更胜一筹。关于消费级 GPU 的详细基准测试，请参见我们的 RTX 4090 与 RTX 5090 在大语言模型应用中的对比.

量化、格式与实际显存占用

两个运行时在这一点上存在根本差异。Ollama 仅使用 GGUF (Q2_K 至 Q8_0，支持 FP16)。这种灵活性使得能够容纳 Llama 3.1 70B (约 40 GB，Q4) 单张 RTX A6000 48 GB 显存即可运行。vLLM 支持 HuggingFace 原生权重（FP16、BF16），并现已支持 AWQ、GPTQ 和 FP8，但在稳定的生产部署中不支持 GGUF。

以下是一些 Q4 量化下的显存占用参考值，数据来自 哪个LLM 目录 :

对于规模较小的部署，gpt-oss 120B 和 Mistral Small 4 提供了合理的折中方案：模型大小可控、许可证宽松，并且支持这两种运行时。参见我们的模型介绍 Mistral Small 4，了解详细的基准测试结果。

许可证与合规性

运行时的选择不影响许可条款——决定这些条款的是 模型 决定具体的许可条件。以下是欧洲生产环境中的一些典型情况：

如需完整概览，请参阅我们的 开源 LLM 许可证指南 以及以下平台上的社区跟踪信息： HuggingFace模型.

使用场景：不同用途该选择哪一个？

在以下情况下，选择 Ollama： - 您在开发人员工作站或单台 GPU 工作站上部署内部助手 - 您希望快速迭代多个模型（通过 API 热切换） - 您的并发用户数少于 5 人 - 您的目标硬件是 RTX 3090/4090/5090 或 Mac Studio M3 Ultra - 您希望测试 dots.llm1 Instruct (142B，MIT，Rednote) 或 Hunyuan-A13B Instruct 无需配置集群

以下情况下请选择vLLM： - 您在负载均衡器后提供 API，每秒处理超过 20 个请求 - 您在 2、4 或 8 张 GPU 上使用张量并行 - 您希望使用分页注意力（PagedAttention）、推测解码（speculative decoding）和连续批处理（continuous batching） - 您的目标是大规模 MoE 模型： DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - 您需要 Llama 4 Scout 109B 及其在多租户推理服务中使用的 1000 万 token 上下文窗口

第三个选择值得特别提及： Text Generation Inference 由 HuggingFace 提供，介于两者之间，原生支持 Mistral Medium 3.5 128B 以及其系列 Llama。要编排 vLLM 集群， Ray Serve 仍是标杆。

如需按 GPU 预算获取推荐，请参阅我们的 配置指南 和该页面 最适合 GPU 服务器的 LLM.

运营成本与可观测性

Ollama 在运维简便性上更胜一筹：单个二进制文件、极少的遥测数据、一条命令即可更新模型。隐性代价是缺乏细粒度指标（近期稳定版本没有原生 Prometheus 支持，尚待确认）。vLLM 原生提供 一个 Prometheus 监控端点 ，包含首个 token 延迟、每个请求的吞吐量、KV 缓存使用情况等指标，并可直接与 Grafana 集成。

在 GPU 成本方面，经过良好调优的 vLLM 集群将每百万 token 的成本降低 3 到 8 倍，相比同等多实例部署的 Ollama 集群——差异源于连续批处理以及几乎无 KV 片段化。在 Qwen3-Coder-Next 80B-A3B （MoE，Apache 2.0），据我们的读者报告（有待确认），使用 vLLM 在 2 张 H100 上可达到约 14 000 token/秒的聚合吞吐量，而使用 Ollama 搭配一张 RTX 6000 Ada 时，单流吞吐量约为 80 token/秒。

如需进一步了解调优，请参见 vLLM官方博客 和我们的 vLLM 与 TGI 的对比.

FAQ

Q：Ollama 是否可以在生产环境中同时服务于多个用户？

技术上可以，但有一定限制。Ollama 通过内部队列处理多个请求，没有高效的连续批处理机制。使用 70B 模型、并发用户超过 3–5 人时，例如使用 Llama 3.3 70B Instruct，p95 延迟会显著恶化。对于要求较高的多租户生产环境，vLLM 或 TGI 仍然是有技术依据的选择。

Q：vLLM 是否支持类似 Q4 GGUF 的激进量化？

原生 GGUF 格式不行。vLLM 优先采用 FP8、AWQ 和 GPTQ，它们在质量与显存占用之间提供不同的权衡。在 DeepSeek R1 671B, HuggingFace上提供官方AWQ 4位版本，支持vLLM运行。对于严格的GGUF Q4_K_M版本，建议使用Ollama或直接采用llama.cpp——这是它们的专长领域。

Q：像 Qwen 3 235B-A22B 这样的MoE模型需要什么运行时？

vLLM，毫无疑问。MoE模型充分受益于vLLM原生实现的专家并行和连续批处理。 Qwen 3 235B-A22B （Apache 2.0，上下文 131K）达到的总吞吐量，即使在 8× H100 集群上，Ollama 也无法接近。参见我们的模型介绍 Qwen 3 235B-A22B.

Q：能否在 Kubernetes 集群上使用 Ollama？

是的，社区存在 Helm 图表，但 Ollama 并未设计用于无状态水平扩展。每个 pod 都需重新加载模型，GGUF 缓存不共享。对于原生 Kubernetes，vLLM 通过 KServe 及其专用 Operator。

Q：为 Llama 4 Scout 109B 及其10M上下文选择何种运行时？

启用稀疏注意力的 vLLM。拥有 10M 上下文的 Llama 4 Scout 109B 需要对 KV 缓存进行管理，而只有 PagedAttention 才能使这种管理在经济上可行。技术上，Ollama 可以加载该模型，但在没有分页机制的情况下，1000 万 token 的 KV 缓存会导致显存需求暴增。仅适合使用 vLLM 或 TGI。

问：对于搭载 Apple 芯片的 Mac，有没有能替代这两者的方案？

是的： MLX 由 Apple 开发，针对 Metal 进行了优化，在 M3 Ultra 上运行某些模型时表现优于 Ollama，例如 DeepSeek R1 Distill Llama 70B。不过，在 Mac 上提供多用户推理服务仍属小众。参见我们的 在 Mac M3 Ultra 上部署 LLM 指南.

结论

关于Ollama与vLLM的争论，关键在于目标负载：Ollama适用于原型开发、单用户场景及Mac设备；而当涉及多租户API、大规模MoE模型或张量并行时，应选择vLLM。为确定最适合您VRAM配置和目标许可的模型与运行时组合，请使用我们的 配置工具 或浏览收录了 249 个模型的 哪个LLM 目录.

文章发表于 由 Mohamed Meguedmi · 数据来源： /api/models.json · 内容许可协议： CC BY 4.0.

有错误或更新需要反馈吗？ 参与贡献.